Well, good afternoon, welcome to this webinar. And we're going to be discussing cloud identity governance over the next 45 minutes. And we're going to look specifically at a product that helps us in that space and a use case that illustrates how identity governments can be achieved. So Shane day from unified solutions is going to provide an overview of the identity broker version five. And Ryan Newington from Monash university is going to describe the university's issues in moving to the cloud. We do have a webinar rules. The at the moment, you, you will all be muted. It's not possible to have audio feedback for a webinar of this size, but you are encouraged to put in your questions. In fact, we do need questions so that we can gauge the effectiveness of the particular, this particular webinar. And so that we can make sure that we do answer questions that come up as you listen to and watch the, the presentation.
We need to know what those questions are so that we can clarify those issues with you. The webinar will be recorded and will be available to those that have registered for the webinar. Just have one slide on caping call for those of you who are not familiar with us. There's three legs to the stool research services is, is one. And Kaka Cole has very rich repository of research information going back over 10 years covering just about every aspect of identity and access management. There's also advisory services. Advisory services are provided by the senior advisors that kaing Cole has. They can advise in just about every aspect of identity and access management, particularly as it pertains to movement to the cloud and in support for mobile devices. And then finally, there's the events, the big event coming up shortly in Munich. So every may, the European identity and cloud conference happens in Munich. It's four streams over three days of all of the pertinent detail and pertinent requirements on the identity and access management issues. In terms of the agenda for today, I'm going to start briefly with an introduction to governance issues. When it comes to migration to the cloud, then Shane will tell us about the identity broker service provided by unify solutions. And Ryan will tell us about Monash's universities move to the cloud and issues that arose there.
This slide on cloud services identity was put together by Martin Kuppinger to illustrate the breadth of cloud services. On the left hand side, we have a very basic situation where a company with identity and access management capability is moving their on premise into the cloud, alongside that they then need to come up with an identity as an service solution that services their cloud requirements in the middle there's the company that has more sophisticated operations. They probably have single sign on premise. They need that in the cloud. They probably have multiple identity providers, so they need some type of Federation service and they need a good authentication model. Particularly as we move more into supporting mobile devices and all cloud service providers. Now give us good capabilities in that space. So they're looking for an enterprise cloud user and access management requirement. Then on the right hand side, we have the industry solutions.
So we need to keep in mind that there are a number of industries that have very good clouds that are specifically are geared towards the participants in those industries. So airlines, for instance, or the aircraft maintenance. The there's a very good industry network that allows participants and partners in that space to communicate together. So suffice to say that most cloud implementations are quite unique and we need to make sure that we have the flexibility and the agility to support those particular requirements. There was an interesting document done by Emma, one of these KuppingerCole Analyst, and he's come up with 10 security mistakes that every C, C S O might make from time to time. We don't have time to go through all 10, but I would like to focus on just two. The first is we often find clients moving into the cloud without doing a proper risk analysis.
In our opinion, there should be no cloud service provider engaged until there's been a, a proper risk management analysis performed. The second item there is looking at the instant management activities. We've observed companies with good S I EEM event, monitoring solutions, letting that go as they move into the cloud and not requiring their cloud service provider to communicate to their monitoring systems not necessary anymore. In fact, our observation is many cloud service providers now have better monitoring capabilities than many on-prem situations that we come up with. So you need to make sure that that that is handled as well. Mike Small from the UK did an interesting document. In fact, it's actually two documents, one on AWS and one on Microsoft's year, looking at their security and assurance offerings. And it, it clearly illustrates that the cloud service providers are well up the curve when it comes to supporting our cloud governance requirements.
Obviously cloud service cloud service providers keep their equipment up to date. So all of the patching is already done for us. We have good anti antivirus and, and possibly better anti-malware in the cloud than we have on, on premise Dido protection is, is there. We can have private connections into our cloud service provider. We don't have to rely on the internet. So the express route from Azure and, and the AWS partners, they have good offerings allowing us a private connection into the data center, data encryption, all of the database databases have very strong, not just the databases, the data storage solutions from cloud service providers have good encryption capability. They'll run a key vault for us in terms of identity and access management. Most of the cloud service providers will give us a solution there. And what we'll see in a moment is we need to take control of that solution.
And we need to make sure that we solve that as I call it the, the elephant in the room when it comes to cloud migration. And lastly, as mentioned earlier, the access monitoring and cloud analytics are all available to us. Now, we just need to avail ourselves of that in terms of a risk management approach. KA Cole has a rapid assessment tool that actually evaluates nine different risks that were identified by the European information security association of those as loss of compliance is one it's most important that if you do have say, PCI compliance, that you don't lose that as you migrate into the cloud, in terms of cyber risks, you need to make sure that we don't run afoul of the various regulations in the jurisdictions that we're in. We need to make sure that if we've got strong privacy legislation, as we have in Australia, that we don't start storing sensitive information externally from the, the, the, the national boundary, we need to make sure that we we've got good availability to our service and data.
So we need to tell the CSP what our requirements are there and make sure that their service capabilities meet that and, and like finally lock in lock in needs to be addressed. Let's face it. If we're moving into a Azure, we're probably locked into a Azure. We need to make sure that we're happy with that. If we are not, we need to look at some of the controls that can be put in place like DACA, for instance, giving us abstraction from the under underlying compute services. So we do, we do recommend that you look at all of the risks, you do an analysis of them, and any that come up high in extreme, you put in some sort of mitigation or control in place for that.
There's, there's Mike Small in the, in the UK came up with four stand sort of pillars of that are important as we move into and adopt cloud services. First is getting that service level definition, correct? We need to know what we want so that we can match it up with what the CSP provides. We need to know what our standards are, what standards we adhere to and, and whether they're or not, they are supported in that cloud environment. We need to know where our responsibility starts and ends and where the CSP responsibilities at start and end. Mike tells a horrific story of an organization in the UK that had a large database associated with one of their applications on a weekend. It became corrupted. And they said, well, no problem. Monday morning will roll back to Friday and just reapply the journal. Well, unfortunately when they called the CSP on Monday morning, they found out they hadn't purchased the backup service.
So these are the sorts of, of, of horror stories that we must avoid. And finally monitoring an audit. Let's make sure that we don't throw out that requirement as we move into the cloud, let's make sure that we do make sure that the, the account service provider performs for us in that particular space. As mentioned, we do believe that in the moving to the cloud, the elephant in the room is identity. In many cases, we are seeing clients that are simply synchronizing their ad into the cloud. And so they end up with multiple instances of their identity data spread across multiple service providers in the cloud. And, and that's definitely a major risk. All of the major cloud service providers have an identity solution and some good ones. What we are talking in this particular webinar is taking control of that. And the identity broker service gives us the capability of making sure that, that we do handle the security requirement we want.
So we, we have our information stored, securely provisioned securely. And secondly, that we now are able to leverage that regardless of what the, the software as a service application might need. We need to make sure that we can work with the API that they publish, and that's where the identity broker service comes in. So maybe I can hand over to you Shane, and you can tell us then about how the identity broker performs this and what we need to do in terms of making sure that we satisfy the, the requirement. So I'll just click to you and you should have control of the mouse. So take it away, Shane.
Yeah, there we go. Thanks very much, Graham. And thank you everyone for attending this seminar and particularly thank Ryan for his participation later on in this, this webinars pretty much appreciated just recently. I was happy to announce the release of identity broker version five from unified solutions. And this particular piece of software comes about from our 10 years of experience of being identity and access management experts, identity and access management is all unified does and everything with, you know, comprehensive service within that field of information technology throughout our 10 years, we've invested heavily in research and development and also developed comprehensive service for our customers in a number of a number of verticals. And we've located mostly within Australia, but we've also got presence in Southeast Asia, New Zealand. And since that slide was produced, we've also got presence in Seattle on the west coast of the us, but enough about unify.
We'll talk about the problem space that Graham was talking about previously. And the problem comes from, from traditional on-premise type solutions. If you have a look at, you know, in the center there, we've got identity management provisioning platform, and these have traditionally worked really well with directories. I mean, that's what directories were invented for is to work really well with, with our user related information. And the protocols have been in place and well established for that. When you wanted to integrate sources of information or other types of, of platforms or systems into your traditional solution, you would typically do that by using a CSV or flat file report or connecting directly to a database. This has, this creates always created a few problems, but these were such a great problem on premise. You know, if you want to respect the integrity of applications, it's usually not a good idea to go directly to their databases.
Yeah, because you are circumventing a whole layer of, of business and security logic. That's built into these, these applications, but a lot of organizations that that was okay. But if we start introducing cloud based solutions, which you don't necessarily have access to their underlying infrastructure, in fact, you know, if you look through the risk profile of using cloud services, you probably don't want access to the underlying infrastructure. If you're using using software as a service, particularly infrastructure as a service may be slightly different, but you get an end point that you can control the identity and roles within new, within that application, through that particular endpoint. And it's, this will commonly be a soap interface or, or more commonly these days, rest API. How do the, how do the traditional platforms deal with this? Well, they don't really they're it, doesn't not really something they do.
They do have extensibility endpoints, but you are limited to the concepts of, of data structures and the types of conversations you can have with the application. From those, if you are looking at more modern style cloud based identity and access management solutions, they do deal really well with standard. So I've just put skim as a, as an example up there, you know, other examples, Sam, or, or open ID connect or two, you know, they're, they're all based on these particular standards, but you know what, there isn't a standard. I mean, I think, I think we've all grown old waiting for the latest and greatest standard to become great. And wouldn't the world be better if it was that when you look at particularly line of business solutions, even though that have been offered as a cloud service, they're not geared around that. They're geared about being good at servicing that line of business and not necessarily good at servicing the identity or I C T needs of integration with them. And you end up with a, what kind of conversation can you have with these guys? You particularly, if you're having that conversation through the cloud, you can become quite difficult.
What unify has done is we've taken an approach of what we call application driven approach. We've turned the model on its heads. And instead of having a look at the system integration issue for identity management, from the identity management platform perspective, we've looked at it from the application perspective and said, how can we, how can we honor what the applic, how the application deals with the rest of the world and provide a bridging lamb to the way that identity management platforms look cause the world, whether that be an on-premise one or cloud based identity management solution. And that's where our identity broker solution fits in. It provides that layer and the capability for us to commercialize connectivity to particular types of applications and particular applications, and provide either a piece of software that can be used for a company can purchase to do, to use that.
Or we can actually provide it as a service, as a cloud service to provide the, to provide that access to it. And what does, what does this look like or from the identity management provisioning platform? And it actually looks like a directory. So as of den broker version five, the connectivity endpoint for on-premise stuff is, is LDAP version three. And we will be implementing a skim endpoint for, for cloud-based solutions that can't use LDAP as a source for that very soon. So in this instance, the application looks like it looks like a directory to it, and you can, you can abstract away the complexities of the types of API conversations you have to have with the target application. So I'll, I'll just go through a couple of really common use cases we have for this. The first one is a large enterprise, a large enterprise will have a number of applications.
I mean, if this is a very simple large enterprise, because real large enterprises have potentially hundreds of applications on the right hand side, but some of our largest customers with over a million identities being, being managed through it, they've actually used identity broker as a common connectivity point, so that they, when, when they build the identity management provisioning solution and their access management solution, there's a common endpoint for the, to access their applications. And no matter whether the application we're talking about is male, male, or collaboration service as a so software as a service or collaboration or knowledge base services, or any other type of service, or on premise service that they all come through that endpoint and they get, they get shown as one, one directory.
The addition of the elder version three endpoint allows this also to be used for other purposes. I mean, you could have a, a, an at reporting engine that that's uses the information contained within that identity broker instance to create at reports, you know, and because it's an D version three endpoint, almost any engine can use that as a source for that, that, that kind of outcome. The second use cases for small enterprises who can't afford the big, the big ended solutions of, of being able to control their user base from author sources, you, they don't don't have the, the capital to invest in the provisioning engines to do that. We've actually provided this capability from a cloud service where we can source information from an authority source, such as an HR system and from our cloud service interact with the clients, clients active directory or E directory, or even in some cases start doing that directly into a cloud directory where enterprise that's particularly small enterprises are moving away from having a corporate authentication directory on, on premise.
And just a quick side of why would you wanna do this? If we talk from a business perspective, there's a quantifiable return return on investment, which we've had some research done into what that does, how that plays out, you know, it could facilitate a single source of truth for employee identity, no matter where that, that, that information is coming from. It can also reduce the workload and complexity of your identity management and access management system by aggregating information from different types of, of, of data models and presenting them in a way that requires much less processing within your identity management solution allows the seamless aggregation of multiple data sources.
You can collect information from multiple, multiple sources if you have multiple HR sources, and you can be able to present that as one, that this point reads a little bit funny. These, these are actual responses to a survey that I sent out about why customers would want to use identity broker or why our implementation partners or staff own staff would want to use it. And, you know, we're able to, to emulate a lot of capabilities that make identity management solutions work a lot better. And even if the end system is, is unable to provide that system. And I finally, you know, the, the point that I made in the enterprise use case, that's why you can use that source, that identity information for things other than just provisioning. Okay. Thank you very much, Graham. And I believe that that hands over to, to Ryan.
Very good. Thanks Shane. Appreciate your input there. And for that presentation, we'll hold questions until Ryan has told us about this, the use case that Monash has. So Ryan, you should have control of the mouse now. So if you would like to go into your presentation.
Thanks Shane. Thanks Graham. So a little bit about Monash university. If slide comes up, there we go. We're Australia's largest university or one of Australia's largest universities. We've got campuses and, and research centers and affiliations across the globe where owners and partner owners of many organizations focused on teaching and research. So a fairly large organization with about 250,000 identities that we're managing. So we're, we're, we're using the identity broker product to, to connect with some of our, our cloud and, and non-premise systems. So we'll be talking a little bit about that today. And some of the challenges, I guess, that we've we've had there Monash is an organization, I guess, where the, the traditional model of users just doesn't, doesn't kind of fit very nicely with us. We, we normally have to cater for our staff and students that our affiliates, alumni researchers, both from within and outside of Monash.
So at leads to quite a complex system of, of, of, of managing identities that, that we're dealing with. So for us, any opportunity to reduce some of that complexity is, is, is highly valued. Having a little bit of a look at, at our architecture, we've got four systems of, of, of truth, the university's HR system and it's student management system where the bulk of identities are, but also an international HR system and a, an affiliate student system that we, we pull identities from. They go into our IDM system, which consists of Microsoft forefront, identity manager, as well as the event, sorry, identity, broker product, and that provisions and synchronize out to an on-premise active directory and, and LDAP as well as two cloud services, being Google apps for, for mail and collaboration. And as Azure active directory, our, our cloud services, as well as our internal services authenticate and perform authorization against assemble endpoint, we've got using active directory Federation services. So they federate back to from our cloud services back to those local on-premises directories for authentication there.
So some of the challenges that we have are probably not uncommon in many environments. I'm gonna talk about some of the main ones we have here, and as well as some of our learnings that are quite specific to the cloud, but before getting our identities out into the cloud, we need to make sure that we're solving the, the challenges that are, that are core to our identity. Specifically, we have a very complex system of entitlements identities appearing in more than one system. People having multiple roles within an organization, common problems that many organizations will invariably come across. But when you start multiplying those issues by the number of users that we manage and the loosely coupled nature, I guess, of some of our organizational engagements, that complexity can really skyrocket. So part of our environment is that a custom rules engine that we develops that basically brings together the, the organizational relationships, the, the different roles and, and, and attributes that we build up for people.
We, we have about 800 different attribute changes that are evaluated under about 3000 different conditions within that rules engine. And it allows us to map out those relationships, develop unit tests for pretty much any imaginable scenario and keep the complexity of the decision making outside of the core RDM system. I think that's a really important point. FIM for us is fantastic at transforming and transferring knowledge between connected systems when it comes to generating new knowledge, based on organizational knowledge, we already have. It's not an easy thing to do without code guess if most organizations, the identity team is, is an operations team. I don't have developers personally in my team. So coding every business rule, wasn't really an option. So maybe something that could be managed in our updated by systems, systems, administrators, and not developers. So this gives us our consistent, predictable and testable data set that we can push out to the cloud and, and our on premise services as well.
The first big challenge for the cloud was the size of our identity. We would spend hours or days trying to push our into some of our cloud providers. We have some SLAs around our, our peak provisioning times, and we, we, we open up for enrollments at the start of the year and we need to be outta provision accounts within about an hour. So when we get our simulations for our key intake time, we couldn't get that under about nine hours. And that was primarily because of the Google API. There's a fair bit of latency there. It takes about three seconds for a request to fulfill. And there are multiple objects that we need to send as well, not just a single user. So we work with unified to implement some, some multi-threaded support with, for the, the Google apps connector that allows us to buffer the performance delay we're able to, to then achieve our targets within about 40 minutes. So pretty significant jump there. So the main lesson there is, is, is to make sure we plan for performance. You know, don't expect the same speed that you'd get from an on-premise directory service when dealing with things in the cloud.
Complexity is another thing that, that sort of surprised us. The Google app on particular is an interesting beast. I guess it makes a lot of sense for a, a web-based adjacent type data structure and API, but it's very different to, to a traditional provisioning target like a directory. There are objects inside objects, inside object arrays, that and things that you don't normally think of as an object in, in the identity space. We think of them as attributes like a telephone number in Google. It's actually an object array, cuz they want to know if it's a primary phone number or not. If it's a work, if it's a home, if it's a mobile phone number. So this whole lot of structure that comes with that data that's we don't necessarily have in the format that's expected there. So part of, I guess the beauty of identity broker as, as Shane was talking about before, was that we were able to keep our identity system, I guess, quite flat and, and hide the complexity of that API from our identity system.
We didn't need more objects to manage. We always want less to manage in our identity systems and we can abstract that complexity with identity broker and keep our IDM system in a more native and natural structure for it. You know, at the end of the day, given the vast difference in, I guess, the physical exercise of provisioning to say an active directory versus Google at the moment, as far as identity system is concerned, it's exactly the same thing. So there is no difference between between provision for one of those two systems, as far as the identity system is concerned. So the, the, the learnings for us is it's, it's very important not to let the downstream systems complexity force the IDM system to be any more complex than it than it is.
The last one for us is, is sort of around authentication rather than provisioning. As everyone knows, email based logins are becoming more and more the norm for cloud based services, everything from Facebook to LinkedIn office 365 Google, they don't really have a concept of a username stink from your email address. So that presents an interesting challenge for Monash, cuz we have about 180 different email domains. We manage every partnership affiliation, acquisition tends to result in more of these domains. It's not one that's easy to solve. You know, in some cases we have to register all those hundred 80 domains with Google to say we manage mail for all of them. In some cases it's not an option to, to have that many domains within a, a cloud provider. And we have to do some, some, some trickery at our, at our login pages or things like that to get around the particular issue.
The, the, the lesson here, as much as I'd like to, to tell my organization to stop buying other companies or spinning them up, it's not really realistic, but there also isn't a one size fits all solution. There's something you need to be aware of and planned for and determine what's right for the organization. It may be, you know, having a standard primary mail address and using aliases using the IDP, the authentication endpoint to, to do some of that translation for you and getting organizational report support to have, I guess, some, some consistent branding across your emails, cuz they're not just emails anymore. They're starting to become user user names and, and logins. And that about covers up all I had Graham, I think it's back to you.
Super thanks, Ryan. Really appreciate that insight. It's always good to be able to talk to somebody in here them to say, you know what the, the, the, what the issues are there in terms of making a product work and real life situations that you know, we focus on. So appreciate all that you've done in helping us understand what Monash went through. Now. Questions we've come to the question and answer session. So questions here look. Okay. One on, on performance. How do you prepare users for slower cloud? Okay. Ryan, you mentioned that working with, with Google required patients. Can I put it that way? I think it was a three second response time. You were, you were experiencing now, is that a, that's not a user it's not exposed to the user. Is it, have your users experienced any slow performance issues when it came to the cloud?
Not, not from a user perspective? No. I think we went from a pretty old on, on, on premise system that wasn't that great to something that was cloud based. But I guess the benefits that they got outta moving to the cloud was, you know, that was available from anywhere and, you know, common interface that they, they knew with their, their Gmail accounts and those kind of things already being able to share calendars and those kind of things publicly. So if, if, if there was a delay, I'd say from our perspective, there would be a lot that we'd be able to cell from the flexibility of moving something to the cloud and the increased feature set that they got from it. But speed wise. Yeah. We didn't really see much difference there.
Okay. So you, and
Certainly from a provisioning point of view that didn't see that that was all sort of backend stuff.
Right. But you just needed that performance through put to make sure it all got done within a reasonable timeframe.
Yeah, that's right. When a, when a new student came in and enrolled with us, we wanted to get them their access to their accounts straight away. So they could get in there and start registering for courses and those kind of things, you know, having to, to send them an, a message saying, check back in 24 hours or something like that is, you know, not really ideal. So it's nice to be able to say, Hey, check back in an hour and your account will be ready. So that's where our SLAs are driven around there.
Do you, do you typically have a zero day start? Do when a student starts on campus? Are they provisioned?
No. No, we don't because we, the way off enrollments work here is we actually make an offer to X number of students, but not all of them will accept it. So it's the process of accepting your offer that actually gets you the accounts. And that's what we're able to turn around within one hour, an hour, as opposed to the old system was, was a couple of days. Cause it's also batch and overnight processing. So it's a big improvement for us there, but it's not quite zero day, but, but probably as close as we can to it without unnecessarily provisioning accounts that people that aren't never gonna come to Monash.
Okay. Okay. So another one looks asked for you too, Ryan, how does the university maintain unique usernames? Okay. I guess you you've talked about 180 domains. Yep. Are there any contention on usernames in that space?
So for usernames, we used to have a, a system where we'd kind of take first letter of first name and then four or five from the surname to make for staff and students were a couple letters and then a few numbers. We've just moved to a standard model of full letters from their name pretty much anyway, we can take it. And then in incrementing, full numbers, starting it one and going up, that's all done by our rules engine automatically. And once username been issued, it's never reissued email addresses because I said, it's becoming blurry. The difference between the two these days, that's a bit more complex. We, we also never reissue email addresses, cuz we may have a researcher published a paper 10 years ago, who has since left the university, but we wouldn't want that, that, that emails destined for that person going to someone that may have had the same name.
So there is a, a, a bit of a structured algorithm that we go through to, to try and generate unique names with combinations of first names, referred names, middle names and surnames until we get to a point where the identity system will kind of just Chuck a number on the end and say, right, that's your email address? If someone doesn't like it, a human needs to go in and work out what to do, cuz there's only obviously a certain number of combinations that an automated system can do. So the fallback in, in all circumstances, there's a, a number at the end of the, the local part of the mail address.
Right. Okay. What about though? Somebody who like, where is it possible for someone to have an email address in both domains in more than one domain? I mean, could there
Be no, we actually, so when we generate the username because we have so many, so many domains, so when we generate the email address, the first part of the email address before the app is what we look at to make unique. There are lots of circumstances where the domain part may change. So we consider the first part only to be unique. That
Idea's the important bit. Okay. Another question here. How does IB, I guess this must be for you Shane, how does identity broker work with APIs? I guess it's okay. You mentioned Jason or what do you support in terms of APIs?
Yeah, so I think that's a very good question. Well, we, we, our product is based on the net framework, so it can pretty much interact with any API methodology that comes in any, any particular framework. So that will be soap or rest or, or, you know, any, any other thing that there's a framework out there for. We can always write our, our own if necessary. But what I think is is important to, to recognize is that the problem doesn't come from, from the identity management platforms or, or access management platforms, not being able to communicate using those, those methods. You know, when you talk about soap and rest and, and LDAP, they're actually delivery mechanisms, they're, they're the enablement to have a conversation. So it's, it's much like, you know, the difference between between the post system or telephone system. Again, it's a delivery mechanism.
What, what identity broker really brings to the table is the ability to, to talk in conversations that are understandable by the, the target applications. So the Microsoft terminology for this is they call it service contract. And I think it's actually a very good term because it describes it quite well. When you, when you list in a contract about things services that you may be offering, there's, there's ways of communicating them and you there's parameters involved in them. And you have particular types of conversations that that enable actions to occur. And as, as Ryan was saying, Google apps is a prime example. I mean, when, when you have a look at an architectural diagram of integrating Google apps, the architectural diagram looks pretty simple. It's a rest API. It's not so simple when you have to look at a layer above the, the technical architecture and actually think about what the functional requirements of, of interacting with that are because the, the, the function and the data model are not things which are easily, easily translatable into things that come outta the box for identity and access management solutions, which are trying to, to interact with as as many things as possible and the planet, because they, they want, they don't want a competing solution to be able to, to perhaps to have a, an extra tick on the box for them.
So what the identity breaker modeling engine allows us to do is to have conversations around data objects in Google labs about a contact object, but we, we have our modeling engine ties that back to ties that back to a particular identity or a user object. And when that's the, when that's presented to the identity management solution, it's presented as that particular as a whole, a whole user object, which has got that the telephone number actually attaches an attribute to, to that object. So when, when the identity management engine issues and instruction using LDAP to ID broker, that gets translated into the appropriate API calls with the right objects on, on Google apps. So that was a bit of a long-winded explanation.
I hope that actually, okay. No,
It does actually provide a good explanation of what happens.
Okay. For those of us who are not aware though, what, how do we actually talk to, to, to Google apps? Is it through Jason? Do we pass Jason or array?
Yeah, you do. Yes.
Yeah. Okay. And, but
When you have to tell, when you pass Jason an object, though, you have it's part of it as part of a conversation it's it's can you please do this with this object?
Okay. Yeah. So that's where the service contract comes in understanding that conversation is an important part of it.
Yes, that's right. I mean, people that don't have an understanding of English would have to really understanding this conversation. For example, even though they could still hear it.
Right. Yeah. Okay. Well, look, we, we don't have any, any other questions at the minute? So I just wanted to finish up with a comment on the related research, the three of the, the three top documents I, I mentioned during my part of the presentation, they are all on the KAA call site. You can go up on onto the main capol.com site. You register on the top right hand side, and you can get access to the document repository for a period of 30 days. So please avail yourself of that and make sure that you stay across the research. That's been, that's been published there. Okay. I'd like to thank Shane very much. And for Ryan too, for his participation, it's been a very enlightening webinar. And we look forward to doing this again, when we, we get an opportunity to, to, to take a look at the identity broker product in further detail. So thanks guys. Appreciate that.
Thank you. You're welcome. Thanks very much, Chris.
