Good afternoon, ladies and gentlemen, welcome to our equipping and call webinar identity is security avoiding the pitfalls of an authentication centric security architecture. This webinar is supported by sale point. The speakers today are Darren rolls, whose CTO M C of sale point and me Martin cooking, or I am founder and principle Analyst could a call before we start some quick information about keeping a call and some housekeeping information for the webinar. And then we'll directly dive into the topic of today's webinar. So Ko a call is an Analyst company.
We are headquarter in Germany, but have teams in the us and the Asia Pacific region as well, providing neutral advice, expertise, or leadership on a variety of topics, centers around information, security, identity, access, governance, risk, and compliance, and all the other areas where security and digital transformation are tied together. We do this by delivering research like our leadership documents, where we compare vendors and their products and services in certain market segments, like our events conference and webinars and others.
And like with our advisory services, which I'll touch in a minute, we have a couple of upcoming events. One is our consumer identity world to which will be run in us in September or Europe in October and Asia Pacific November. And the other is our cybersecurity leadership summit tour, which we will do in the Europe, in, in Europe and in the us as well.
Our advisory areas focus on benchmarking and optimization. So where do you stand with what you are? What are the things you should do on strategy support?
So looking at your strategy for identity management, for security and for larger areas and providing support on this architecture and technology and project guidelines, these are the things where we support you in your projects regarding the webinar itself, some guidelines for a webinar, you are muted centrally, so you don't have to mute unmute yourself. You're controlling these features. We will record the webinar and this recording will be available most likely by tomorrow. And there will be a Q and a session at the end.
However, you can enter questions at any time using the questions features in the go to webinar control panel, which usually at the right side of your screen, the more questions, the better, because then we have a very lively Q and a session for the agenda of today.
I'll start as usually in our webinars, I'll talk about identity at the center of your security strategy. It is not only us indication, but more in the second part, their own roles. We'll talk about the potential pitfalls of adopting an authentication centric architecture without the appropriate support of identity governance there.
And we will be ready for your questions and try to provide good answers on that. So let's continue from here. The question for today, maybe a little oversimplified, but the question is, is authentication the main challenge of identity and access management. And we see a lot of solutions which focus on we provide single on experience cloud services to other services to the user. And this is the key thing, and there's some reason for it because authentication is something which is very close, sort of to the, the, the first impression, the direct interaction with the user.
But when we look at it from a little bit broader perspective of what makes up identity and access management, what do we have to do to protect the corporate information, to protect the corporate trial tools? The answer might be a little bit more complex than yes or no.
So let's start with authorization because at the end, authorization is what we need to do to allow someone access to certain types of applications, to certain types of tasks and functions within applications, et cetera, that might be done by dynamic authorization management that might be done by other types of authorization management, like things we do at an application level, like things we do within web access management and Federation, where we also have usually some more cost grain authorization. So authorization is factually the one thing where we decide about who is allowed to do what.
So we in fact decide about what, or is market equipping or really allowed to access that application to do that within the application performed that a function of a in the application, etcetera, I see allowed to view the document, whatever else.
So it's, in fact, it's about access as one of the big challenges we have and accesses obviously to some extent also indication it's about adaptiveness in the oration, supporting strong authentication, having password, self service, different forms of single on like traditional web access management to web applications that don't support Federation standards, identity Federation, federated singles, and on to the applications which supported the privilege management share account password management and the author education and authorization, which is in therefore certain specific use cases.
The enterprise single sign on for access more to the downstream legacy applications have client applications, things like that. So access is a very essential thing and authentication is a piece of it, but it's not all of it particular when we look at web access identity Federation, this span, in fact, authentication and authorization. What we frequently need is some form of fine crane authorization.
So not only saying, okay, you're allowed to access that service, but what are you allowed to do within the service?
And it's relatively simple to provide access to let's say, say it's for com or service now, or something like that, but controlling the authorization. So the entitlements and mapping the user in the right way, that's a far more complex task and we need to do it to restrict what someone can do within an application. Well then there's the piece of audit. So access governance flows into that area of audit and analytics. So when we started with these a at the beginning, when I started Metron identity management, it was, we were only three, as it was administration authentication authorization.
Then first one audit has been added right now we have a fifth one, which is analytics, and we need to do this as well. We have the access governance piece where we review entitlements, where we look at are they, as they should be, but also the sod controls management things we need to do here in that space.
And when we look at a journey of someone, then it's authentication, yes, that's something we do once we might do multiple authorizations for someone who is authenticated.
So you log onto your client and it uses this windows authentication to authenticate to a variety of backend services over time. Then we have the access. The accesses are the things which you do all the time permanently in the application. We need to understand what you're doing. So you might be authorized, but you still might do things you shouldn't do. You might be author indicated because you're an operator. You might be authorized to perform a backup. You might do multiple backups of the same data. And then we might have a problem. We need to audit to governance to protect all those things.
And we need some underlying administration. So administration is another important piece in that where we have things like directory services, provisioning, access governance, identity proofing at the beginning services, really Martin COER delegated admin and some other stuff.
And so it are a couple of elements. Whether you work as four or five pillars, it doesn't matter. It's really looking at administration analytics, authentication and authorization.
And when we put this together, we are at what we recently published in the, in this new form as a reference architecture for identity management, looking at it here from a building block perspective. So what are the, the functional elements, identity and access management can comprise of an, you might not necessarily need all of them, but in most cases you need multiple of them to ensure that you have the user management.
You can enable the users to authenticate in a convenient way to access applications for single sign on important for convenience purposes to have the authorization and all the audit analytics, which comes into place. So for instance, in this red box, which is sort of a little bit, the extended perspective on identity management, also user behavior analytics stuff.
So what are the people doing at runtime? Is this really what they should do? Is are there changes? Are the anomalies, are the outliers, all these things together, really form identity and access management.
And when we look also at the astronom of identity and access management over the past years, so modern identity management should look at not only prevent, but prevent, detect, respond, and not only at administration, but as a bigger thing, which integrates with other domains of security. So we had, when I started back many, many years ago, it was about media directory services, things like that. And it was very administrative centric, view, identity management. And in the early nineties identity provisioning start in early two thousands.
It was their identity provisioning, started administration plus a little bit of business use of workflows for the business. Then we added access governance back in the days when the act came, came up other regulations and, and asked for, for regular reviews of entitlements, more business involvement, some integration of identity management to steam systems to get locks be analyzed.
And right now it's, it's more, it's only this preventive thing, but it's really understanding, detecting what is happening.
Other things really going wrong, or are they done the way they should and respond also by getting more active on that. So enabling things like adaptive authorization based on risks, we have identified integrating it with the real time security intelligence, where we react on, on external and internal threats, where we work with the anomalies we might have detected. So it's provisioning, acts, governance, access, intelligence, analytics, it's bigger than it has been before. And that's the way we should look at that anti management.
And over time, I'm quite confident that we will move to approaches where authentication systems are highly adaptive and authorization systems are highly adaptive as well. They adapt to a variety of things. So we have our policies for authentication and for authorization. So who's allowed to authenticate to a surgeon service or system, what is the authorized to do, but this will be far more driven by external information.
So it's the identity we already use, but it's the context, the credential sort of level of a assurance or authentication we bring into play here as well as then specific requirements of the application, which then might provide information about which business task is sort of requested to be, to be performed by a user. And is that user Martin could really allowed to do that certain task, for instance, doing whatever an approval of a, of something at a certain amount of money. And this also will be far more driven by external information. So access risk information, other types of risk.
We collect from our realtime security intelligence tools from our security operation center. And that then really allows us to, to control authentication and authorization based both on static entitlements and dynamic information.
We, we receive from various external sources. So I expect that we are, I see that we are increasingly moving to these scenarios, which also allows us to better react on things which are happening.
And when we just look at standard GSE framework, so just detect, respond, recover, and, and the reactions very important. Also when we have these incidents, when we need to decide about what shall we allow a certain user to do at a certain point of time. And if there's an incident part of this incident plan executions or the red area, the execution, it's not only reporting, okay.
There was an incident it's also about closing down the, the critical areas, reducing the risks on, so on the fly. So really reacting on certain incidents. And so from my perspective, it's very important that we understand we need to be good in all of these areas of event and access management to be secure. We need to be good in authentication.
We need to be adaptive in authentication, very flexible, supporting different types of authentications, doing this in the context of, or doing this risk and context where the same with authorization, we need to analyze what is happening, goes from a static and runtime perspective.
And then we can react on the ever increasing attacks and be far more responsive to that.
And that means my perspective is identity management is, is a bigger thing, and it's very tightly related with other things we are doing in security and not to go into detail on the next two slides, but to just give you a little bit more of, of detailedness and insight and all the slide X will be shared. So you will get access to the slide X to look at particular next two slides, maybe more in detail. But when we look at what is happening in access management, we can look at it from a design time perspective. So in a design time perspective, we are have business processes.
We have business roles. We have applications with expose entitlement entitlements, which might be system roles. We might have sod rules. We have the entitlements, we create identities.
We grant entitlements, we have the management over time. We have to recertification of the audit. So this is more the design time perspective for the static entitlements. On the other hand, we have an equally complex flow and, and scenario where we need a variety of elements when we look at the run time. So what happens? The authentication, the authorization of the user in the audit at runtime.
So what is happening there? Do we need to restrict access at runtime? How do we react on this? And those things must be carefully and mapped to what you need in your organization for the different purposes. And it becomes very clear. This is a bigger thing than authentication. Authentication is super important. And adaptive authentication definitely is of high importance. Adaptiveness is key to success, but it's goes beyond that. It's really more than that. And that is what we definitely need to look at.
Understand keep in mind when we plan our journey into identity access management.
So what do we need? And, and when I look at it, particularly from this perspective of cloud services, but not only of cloud services, but the entire hybrid it, so I am for the hybrid, it, yes, we need a single sign on no doubt. We need identities with our passwords attributes and all that stuff. We need to manage these identities, the groups and roles, and other constructs we use to grant access that needs to be managed also dynamically. We need well sorted China removal, lever, and other processes.
So when you look at a complete process framework, it's far bigger than trust China removal lever, but we also need the access governance. We need to access intelligence, the analytics, we need a privilege management and other things as well. So we need a bigger thing, a bigger perspective on that to really serve the needs of protecting our corporate information.
So the requirements are managing also, I think an important thing when we move into the cloud requirements on managing and governing identities and access will not disappear when we move something to the cloud.
In fact, it becomes more complex because we don't need to solve all these challenges. We have solve sometimes quite well for our internal business and internal it. We need to solve it for the hybrid. It the same way with that I hand over to Darren.
So Darren, it's your part right now talking about the potential pitfalls of adopting an authentication centric architecture without the appropriate support of I think evidence. So I'll make you the moderator and it's your
Turn. Hopefully you can hear me.
Well, I must apologize for the potential for background noise. I'm actually sitting here at San Francisco airport in a conference room and I'm looking at a jet sitting right outside the window. So I'm sure there's gonna gonna be a giant roar at some point.
I, you wouldn't usually do this, but travel has put me here. So, but it's a great pleasure to be on. Thank you for that introduction, Martin. I think I always, I very much appreciate your perspective on that big picture, cuz that's really what is the, my theme here as well.
And I, I think the title kind of says it all avoiding the pitfalls and authentication centric, security architecture, as I've spent the, you know, many years now, visiting folks of varying degrees of sophistication in security, I observed, I would say probably last year, a trend that sparked to this thought in my mind.
And, and that was the, almost an authentic authentication centric, design paradigm, really starting to drive too much of the overall security architecture. And that's really what, what it's here today.
And I think I really wanna just kick it off by coming back to this idea of the death of the perimeter. Not because that's a particularly novel thought. I think that's one we've seen in the press for some considerable time, but really just to get back to some of the misconceptions that, that fell here that really led to the place where we are today. So let's start by reminding ourselves maybe why perimeter defenses alone really haven't met the bar that's needed. And I think it all starts with this notion of a growing threat sophistication.
I think when you dig into the vulnerabilities that are, are out there today, it it's actually quite breathtaking as a, as a C S O myself.
It's certainly something that keeps me up at night. There's just so many ways to get, you might say in over and around our defenses, that it it's as say it's just unreal and, and short, every vendor is finding what we call bugs, right? Vulnerabilities, but it's more how they're being exploited these days. It's really become quite an impressive. You can only really say science.
And it's also the nature of the adversary that changed upon us here, particularly, I'd say over the last five years, obviously the bad guys are no longer script kiddies as we used to call them. You know, basically board people pulling scripts from the internet. It's now obviously much more sophisticated. It's a nation state it's professional crime syndication. That is the adversary. I think maybe more alarmingly this picture here, you know, this sort of dark, mysterious threatening cloaked individual.
The problem is it's probably this guy more often than not the adversary we might say looks pretty normal.
They're just, you know, clean living, trusted advisors. You might say employees, contractors, staff with legitimate access, true insiders that are basically making mistakes frequently. And I think this changes the way we look at security and means we have to understand behavioral norms and heuristics before we're able to truly understand the, that adversary.
And of course the idea of the firewall that protection point has changed considerably what we used to do simple north south, you know, just keep people on the outside is now, as we say, east west, we really now have to be stately inspecting all of our traffic on the inside as well as its egress ingress and egress points. And, and so the very nature of inspection if you like, has moved from the network to up to the application. And I would say the user level as well.
And this really means that the overall focus has to change, to be from pure prevention to detection and remediation as, as Martin highlighted there.
And I think that's exactly the point.
It, it's no longer a case of if there's gonna be a breach. We quite often now say when there's gonna be a breach. And so the focus of the security professional really has to move toward that detection and remediation. And I think most CSOs will not be judged by their inability to prevent an incident. They will be judged by how they respond and recover from that incident. And that is just an unfortunate state of the union, I think.
And so much of the security industry at large now seems to agree with both Martin and myself, that the way forward is a user-centric approach that puts identity at the center. A and that really is the boundary point. The applications have moved into the cloud in many cases. And so all we're left with is the user and the account. And as I said, the, the perimeter really has retreated if you like back to the account and the user itself. And in every sense, that puts identity at the center of security.
Now, as we look at the technologies in identity quite frequently, and, and quite rightly, we focus on authentication and authorization for, they are the actual control points. In some ways they are the actual filtering that's happening at the firewall. You might say the protecting of the access.
This is, this is a great thing in lots of ways, but there are some potential pitfalls here when an authentication and authorization system is seen as a, a flawless wall, a firewall, we fall back into the same age, old problem of assuming protection and not focusing on the things that can help support that. So that brings me to the point of looking at some of the common authentication pitfalls.
And these are really some of the misconceptions you might say that are often hear when speaking to my colleagues and, and in some cases, my customers, when they're looking at an identity centric architecture in general, and the first pitfall first issue really is the authentication panacea. When there is too much focus, too much budget and too much dependence placed on authentication. It often spells trouble, strong authentication is essential.
I agree completely with Martin statements earlier on that, and the fact that it is a piece of the jigsaw, the problem here comes most board members now understand the word strong authentication.
They actually use it themselves.
They, they are challenged and are used and are using that authentication paradigm themselves. But when the board sees that and thinks they're done, gee, we, we bought that SSO thing, right? We security is fixed. We've taken an identity centric approach, right?
We, we are treating that as a, you know, a, a, a flawless point of control. And, and that really is, is never, is never good because it can only lead to misconceptions. The second thing I, I hear and see quite frequently is, you know, we might say here, rather, trite leave more IDPs than fingers and toes. How many people have a single identity provider today? How many people have a single point for authentication? We would like to paint a picture for the novice in this space that it's, Hey, one, you know, one, one ring to rule them all as it were, but that is unfortunately not the case.
And it raises the question, how do you manage and monitor these? How are they coordinated? How are they controlled and how are they individually audited? And so that can be a problem. I'd love us to have one IDP, but it doesn't seem to be often the case. Another common authentication pitfall is when scopes attributes and context are set at the authentication stage. A very good example here is O I D C scopes, a scope that can be set at authentication. Time is authorization. It really is the authorization model.
And that raises a lot of questions about how that's administered in ordered over time. And as a, as an governance guy, I guess I could say, as a governance practitioner, these things bother me. They really do another one that I, I see quite often in deployment is this idea of just in time, we are using our authentication layer and authentication action to drive the actual authorization function, the creation of accounts.
And what we often see here is, you know, say just in time stuck in time, you know, we, we find that just in time provisioning happening as part of authentication, often doesn't deal with the removal of those accounts. And, and that in itself can be a significant order issue over time, of course. But I guess what bothers me most is when authentication feels like authorization.
Again, you know, I would have to highlight, obviously I'm a subject matter expert on the notions of governance, but it's becomes very, very hard to govern an access control model when it's too heavily merged with the authentication layer. So I like to say I support the separation of church and state something that, although these are both, I believe both English pictures here, something obviously that is constitution relevant in the us.
And, and I guess what I mean by that is the separation of authentication and authorization.
So I'm a strong advocate.
It, it, you know, really isn't from a self-serving product perspective. It really is from a, a practice viewpoint to separate these two things.
I mean, authentication that I think described by Wikipedia is the process of determining whether someone or something is in fact who it declares to be. Whereas authorization is the function of specifying access rights and privileges to resources. When we push those two things together, it can create a number of issues. So a set of potential pitfalls, therefore authentication on the other side of it, there are some for authorization as well.
I think as Martin explained quite accurately there, you know, authorization at a fine grained level is pretty much a driving remit today, but there are some problems here and the first is the complexity. So we often now talk about effective access and effective access blind spots.
And what I mean by that is when you think about a, a basic assignment model and an authorization model being separate from each other.
So for example, I might put you in an active directory group and that active directory group will be being used by an authorization system to provide access that can work fine when those two things are connected together, but when they're highly separated and when they're separated through Federation again, as a governance guy, put that audit hat on, it becomes really, really hard when the assignment of a group in active directory is being bound to a dynamic authorization model in a downstream system. Wow.
It's just really, really hard to understand that fundamental question of who has access to what, and when that's dynamic, when there are dynamic rules being assigned for the group membership, and there are dynamic mappings happening on the authorization side, I understand the administrative reasons for wanting that dynamic filtering, but boy, does it make it hard to govern it and answer that question?
Who has, what, why do they have it and what are they doing with it? And they are how driving, you know, remits for, for identity governance.
So effective access can be a real problem for us if we're not careful. And I guess you might say, entitlement has always been complicated. Let's go right the way back to the days of, of RF, the authorization system that's going away still seems to be here in large numbers.
But, you know, it was very much about understanding entitlement. This was one of the driving goals for identity governance was being able to understand that TPZ four 40 was a friend and colleague in Glaser, which GCU see use that example of what's TPZ, you know, who knows, but it has to be understood by the business. And when it's complicated, that's difficult. And I have to say, it's no better in the cloud.
I'll often have somebody say, Hey, but we've, we're in the cloud now, how hard can it be?
Well, unfortunately it isn't a lot easier in the cloud. If you look at some of the more complex authorization models like we see in inservice, now it send in salesforce.com in many authorization systems in the cloud. Those systems are, are definitely hard. And often federated, again, as to say that's a problem. And the bottom line is it has to be managed and audited. If you can't audit and you can't answer that question of who doesn't, who should have access, it's gonna be really, really hard to say that you have control.
And so, as Martin highlighted, I would again, come back to the A's and whether it's four or five, really what we're saying here is that whereas authentication is sometimes it's the first part of the use case.
And it's often the first place that we go for technology behind that is authorization. But behind the three of those are administration analysis and audit, whichever audit you look at them. And in order to truly have control, we have to have span across those. We have to be able to accurately manage the process, the join and move lever process.
We have to be able to audit it over time, and we have to be able to analyze it in order to understand exactly what is happening. So that is the remit of identity governance is to try and span that out, but let's maybe give a little bit more of a definition around identity governance supply to this space. First of all, as we often say the who, the, what the why and the, when of access, our job in identity governance is to be able to attach to that authentication, understand who somebody is, understand what they have access to by virtue of the authorizations they're given and why they have those.
It's no longer enough to say that I have a certain high level access. I have to be able to explain why I have it. I have to be able to prove the authorization, the approval processes that gave me those authorizations. And then I also have to be able to understand when, when that access is being used and those, those W's are, are particularly important. Maybe we go to the A's. It really is then about administration audit and, and analysis and analytics. It's with complexity embedded in fine grained authorization that we see today. It's no longer just enough to produce a report.
We actually have to be able to analyze the entitlement, understand peer groups, understand relationships in order to be able to truly give us a consistent lifecycle. Our job in identity governance is to, as we say, join a mover lever, the complete lifecycle that includes compliance at the in today's world.
So giving out administra privileges and access and being able to track and that over time, that really is the, the, the driving goal, but making it the business of managing access. And I wish I'd underlined the word business, because that's really what we're trying to do.
We're trying to make entitlement and security, a business practice and a business concern. And I think as we say here, not all authentication or, or authorization, we are not in that space in identity governance.
And again, to that church and state thought, I personally believe that we have to have lines that separate our authentication, our authorization and our administration lifecycle for basic good, best practice and sustainable use over time in order to, to get where we need to now, no surprise the, our, our Analyst agree with this here. If you, if you read Martin a very well written coverage in this space, identity governance is and ID independent discipline.
And we, we do well in that space ourselves. I guess that's the, the one and only marketing slide I'll put up there for it. But I do want to now sort of come down to a little bit more specific guidance if you like and thought on what it actually means to govern authentication. And I think in some ways I would like to say a mandate authentication in my view is yet another form of access that should be governed through its lifecycle. So I want to perhaps give you what might look like a shopping list of, of best practices. If you like. The first is, as I said, authentication requires governance.
It should be in no one's question in no one's mind that the authentication process be it through a single sign on of a launcher, on a tile, on a desktop or through a device, a third factor, a multifactor, it requires governance.
We have to attach it to our birthright provisioning and we have to manage it throughout its life cycle. Just like every other permission. That's the point, connect it to our joiner mover lever processes. I see so many architectures where those things are separated. The SSO cycle seems to operate on its own with one vendor.
And the expectation is that the rest of the joiner move lever cycle will be disconnected from it. And that is almost impossible.
And, and joining the two together is something I'll look at here and give some definite guidance on. And it really comes down to integrating things like request and fulfillment. If we have a fine grained access request function for our SAP functions in one area and our request functions for new SSO launch points in another, that is a very, very confusing and difficult paradigm for the end user.
So it's important that we do something there to make the life easier and integrate that request and fulfillment.
So our SSO and our authentication access can be granted and controlled in the same life cycle as the rest of our entitlements. And that gives us a chance to carry out our governance, governance functions, our certification, our sod, our reporting, and our analytics, all functioning for our authentication layer as well. So we can look for trends. We can look for baseline set baselines, and we can look for anomalies in its usage, in its assignment and in its life cycle.
And that really lets us take a single approach to audit and controls that can span the authentication layer, the authorization layer and the rest of our access. Now that governance mandate turns out actually very easy to do for us at SalePoint. It means integrating and providing access management integrations across the core governance platform, how into the leading authentication and SSO platforms that are out there for us, that means providing it in the platform, not something that you actually have to go and customize it it's there in the product.
And it's there to provide some very, very simple capabilities. And these look very much like the rest of our governance needs, right? Full visibility into the assignment, the ability to automate the join a mover lever for a tile, for some access when somebody joins in Workday and are given a business role that that can automatically be detected by the governance platform. And we can provision all the access out that includes the base SSO capabilities out the gate and extends into, as I said, tiles is requestable units of access, and that's really about normalizing that request flow.
So is that we don't have two places for the business user to go in order to request access and integrating our password management. Gee, that one quite often clangs off people's heads.
They say, well, I, I don't have a password management problem if I have a single authentication layer, right?
Well, the truth is you do, there are always passwords and systems that live outside of that SSO boundary. If you like quite often see an, a, a pitfall with an SSO architecture being, we've just got the, the, the cloud apps covered. So the cloud apps have multifactor authentication on them and rack S left wide open.
Our SAP on-prem is left wide open, and we can do some things to integrate the password reset function for the single account back down into the rest of the systems that are out there. And with that pull together preventive and detective controls, and really drive end to end governance across both the authentication and authorization layers.
Now, it turns out that, you know, this really is not rocket science. In fact, it's, it's so much the same across all access management layers that I'd love to see a standardization here, a standard way of identity governance, managing access management.
The use cases are quite simple. We need to be able to share context and identity to synchronize them between the two layers. We have standards for it, right? Skim. Hopefully everyone's aware of this system across domain identity management, basic restful synchronization.
Very, very simple to do. We need to have some sharing of SSO and session management. If we're deploying SSO, we have to integrate it with the identity governance session as well. And then as said, things like launchpad provisioning and governance, and some interesting things in login event, information exchange as well, that can, we can bring these things together. We can really create what is a single platform, a single approach for managing access management, wherever it's provided. And I would come back to a, a brief summary.
And the first is to say that linking authentication to administration and audit is, and should be a mandate.
And it helps us keep things in their swim lanes. If we keep a separation between our authentication and authorization and our administration just said, there are very, very simple usage patterns which can help us do that and help us normalize effective access wherever possible. That's a big one. I think we'll see some audit issues here in, in future, in the near future. So much that effective access picture that I drew so much of the access can be hidden if it's not properly managed.
And, and that can be a, a real problem and something we definitely need to look at governing the authentication layer, as I said, and asking for open standards, wherever you can to offer to do that is certainly the way forward. And we believe will, will allow for a more balanced and managed overall identity infrastructure. So that's it. Let me pause there, try and keep us on time. We've got another 15 minutes for Q and a, so I'll hand back to you Martin for managing that.
Okay.
Thank you, Darren. Let's directly move to the Q and a and look how many questions we have here. So currently we have a few questions here.
I, I wanna start with one question, Darren. So my observation is that when I look at many of the cloud services, it's still also a challenge of interfaces. So implementing identity governance for these types of services is pretty challenging because many of them like adequate interface or just have proprietary APIs. And I think you touched with the, with one of your final slides regarding the need for standards. So is it what you observed as well?
Yes, it is. It's, it's still, I strange to me, to be honest with you, the a, a SAS provider would not look for a standard account administration API, obviously skim is continuing to GRA to gain traction, but why not use a standard? We have that in, in our own company.
You know, if you don't say to a developer, Hey, you will use this standard. They probably won't. They'll probably write their own API.
And, and that is, you know, there's no need for that. I'd love to see a much clearer support for skim across all SaaS applications. And there's some simple extensions in order for us to pick up the rest of those use cases. An interesting one is log. I know that's something that you and I have spoken about many times in the past that it's kind of, yes, this log is out there, but there are some very specific use case log and audit artifacts that could vary very simply be standardized and exchanged between those layers. So I don't see any reason why we don't do it to be honest with you.
Okay.
Another question you mentioned effective access. How do you handle that in your solution?
That's a good question.
As I said, effective access is something of, of great concern for us in governance. When the, if you like the provisioning unit is not the same thing as the access unit, we, we generally have a problem. Great example of that is in, in AWS, if you're using Federation, which is incidentally Amazon's recommended approach today, you authenticate to a directory and you are given a set of group entries. Those group entries are then mapped to roles dynamically in your session. And that's what gives you, you know, fine grained access into the AWS administration environment.
Gee, that's a problem. So what we do is we, we, we have a, a governance module for it that basically flattens all that out and allows you to answer the question who does have access. And that often means looking at two sets of resources at once, we have to look at the active directory group infrastructure. We have to look at the mapping rule and we have to in effect, say at this point in time, these five people would have this access, you, you in effect flatten it and turn it into, you know, sort of a current state.
What if so we do that across the board in many areas, we do it for file access and we do it for any, any place we see effective access, basically.
Okay. Another question we have here, can you explain a little more about how you integrate this Microsoft Azure, maybe also, oh, 365 today?
Yeah. That probably was prompted by a picture. We're very fortunate that the, the Azure API is, is, is very mature. It isn't a skim API. They do have skim support in areas of their product. So no true disrespect there, but well articulated APIs. And so we follow that same pattern.
We can synchronize with the Azure ad premium SSO environment, much as we do for Okta and, and VMware and a number of other platforms where we are able to synchronize the identities. And then we're able to provision tiles.
We, we really treat the Azure ad premium access environment as a provision entitlement. You can attach it to roles and do birthright access and, and access requests. So great. A great integration all through the standard APIs, basically.
Okay. So it looks like we are done with all the questions we have here.
So, okay. With that, I think we are the end of the webinar, Darren. Thank you very much for your deep dive into the needs for identity governance beyond authentication and all the insights you provided. Thank you. And thank you very much to all the attendees of this webinar. Hope to have you soon again, as an attendee, one, one of our webinars or events. Thank you very much.
