Mans Hakansson: Modernizing IAM - Implementing Policy Based Access Management & Governance

So thank you for having me here today. So the topic of this discussion is to modernize. I am by implementing policy based access control and it follows and is likely quite aligned with one of the presentations from earlier this morning, given my, my Reinwarth talking about policies and how policies can be used in, in, in, in, I am to actually sort of enrich and extend and most likely also break silos of identity technology, identity teams.

So we, we are offering a way to rethink and redesign I am. And the discussion I will have will be mainly about principles and architecture and somewhat not touching on products. Even though there will be a little glimpse of that, as well as I, I started with with saying, what plain ID does. We are an authorization company and we, we sort of provide a strategy or a concept that we call policy based access control. And it's, it's a way to centralize authorization. Being able to at the lower level of this slide, being able to sort of consume and enforce access control from a single source.

It doesn't have to be sort of centralized always, but the, the, the definition and the administration and management is always centralized, but allowing for different types of platforms, systems, services, infrastructures, to be able to consume authorization for one from one single source on the, on the upper side of this slide. We also see the, the business aspects of this, that we all, we often talk about this as a it's a business matter to deal with authorization, and it truly is.

And we are with our tooling offering ways to actually sort of allow business people to take responsibility, to become accountable, to be able to define, for instance, the business process controls the IP protection controls, the privacy controls, and be able to understand those security and information security, the policy. So this is what we preach a, a strategy towards centralizing policy. And I promise not to talk too much about products and I, I will not, but I will.

I need to say this, that the reason for we are in this industry and sponsoring this event is of course that we have certain tooling that is available to customers. We have three set of products. They are all focused on authorization and they, they all provide a very rich policy management policy governance capabilities, somewhat equivalent of what you would find in IGI tooling. So workflows dashboards, reporting capabilities, and such. We also say that this, this, these tools are built for business people and it professional to collaborate because it's actually a joint effort to do so.

And not only focusing on one single use case or one single scenario, there are, there are a PLA of, of authorization pattern and authorization styles. And we, we, we think we have a pretty good sort of platform to provide this. And by this, we are re reinventing access control, but, but if we skip the tooling and the products at, at the heart of our solution, there is a policy, okay. We think of policy as a way to define connectivity or access if you like between users and the resources and this resources of obviously of kinds. And I have with me a set of examples.

So a couple of these examples, for instance, in banking, this can be as this, this policy indicates on the left hand side, we see the identities. And on the right hand, we see the resources and we, we can obviously sort of define basic access, which branch clerks can access, which customers and all that. But we can also define very fine grain policies saying that a branch clerk is only allowed to do financial advice, meaning many helping customers to invest if they have a active certification. And that is, that is one of the dynamics and parties.

It's also very, sort of a fine grained way of defining who can actually perform financial advisory services to customers. This may be captured in a product in, in, in a policy also switching to, to another industry where we have healthcare. We define policies for doctors and nurses accessing medical records and patient information. This can basically on which, which hospital you are working or things like that, but it can also be about emergency access.

Someone, sometimes a, a doctor need access to things that he does not have access to in general. So he can declare emergency to actually gain access. And if we switch to a third industry insurance, it might be an agent working for the insurer, being able to view claims. And this claims are not technical claims. These are insurance claims, and he can view all view, all, all claims covered by his agent where he works, but it could also be. So if this agent is a customer of the insurer, he cannot access his own claims being, being segregation of duties, the principles in place.

So these are sort of business, examples of policy. And the last example I have with me is, is a policy around sort of database that this is, it could easily be around APIs or anything else, but, but this is allowing like, like DBA privileges, classified, or tagged as data center Frankfurt is available, available to the team that actually works in Frankfurt. So if we look to policy and if we take a step back from policy and look to this in a, in a generic way, we would see that this is, is, is, is quite visible. It is mostly natural language defined.

It can define very fine grain and dynamic scenarios, but it's here to capture logic, okay. It's access control logic. And we think that we have an excellent way of actually doing this, that, so with, with, with, with policy based access control, we sometimes see that policies are sort of the, the last evolution of authorization.

And, and we sometimes talk about how to get from static to dynamic and how to get from cores going to fine and how to enable local control to enterprise control. But the truth is as talking with customers that not all customer are at the far end of this far right of this meaning that there are different styles, there are different of already existing legacy that exist. And to be able to support this is really, really important.

And, and that is why we have sort of start to talk about a new pattern. We are starting to help customers that thinks that we have a brilliant idea of, of defining policy.

That, that, that should definitely be a way forward, but this customer has a little bit of hard time to actually find and define how they should go enterprise with this.

Because what we are saying is that that most, what we are seeing is that most companies or organizations, they, they obviously want to get to a run position where everything is smooth and, and fine, and Danny and sort of the processes are working really nice, but without understanding how to get to crawl, walk and run, there is there is easily a way to define policy based access control to only help one single use case, meaning that we have created yet another silo.

So, so what we are talking about now is, is trying to engage with identity and access management specialists, architects, running major IM transformation projects to see how can policy based access control actually reduce complexity in, at a, at a higher state, meaning that not only supporting. And I go back to this, the, the run scenario where we have a new initiative that has a very sophisticated requirements, but actually be able to help and, and, and, and, and, and take advantage of policy across the different IM technologies.

So what we have identified, or, or, or defined I would say is a, is it's an architectural patent, and this is the, the last slide that I will have. It has some animations with it, but still, I was just saying that this is at the heart of what we are trying to is how can we as plain ID help organizations to modernize their, I am, and we have defined four different types of applications.

And these, these types of applications are sort of, they are, they are grouped by how they are consuming and enforces enforcing access control. The first type is, is quite a modern type of application.

It's it, it's an application that can consume authorization from an identity provider. This can be through channel or, or open ID connect.

What, what have you, it is it's mainly consuming sort of access control using tokens claims, scopes. What have you? The second application type is, is, is the one that we primarily target.

It's, it's, it's an application that can delegate authorization to one single source and actually consume access decision from a PSI. The third type is, is perhaps for this topic and this event, the IDI style of, of, of application, the applications that consume authorization through provisioning through a local or assembly repository. And we have the third one, obviously the ones that are disconnected, the sources that need some sort of manual fulfillment. So what we look at this is that we see silos.

We, we see that these are different types of products, different types of teams, different types of technologies, how they, they consume modernization. So what we are are offering, we are offering a view to this, where we can say, okay, we can modernize your IM at least when it comes to authorization.

So by, by expanding a little bit about sort of the policy engine and not focusing so much about the engine, but focusing much more around the governance and management and the repositories of the engine, meaning the policies here, we have a way to define policy and access, and we can engage with new people and provide new and rich features, dashboards, and functionality to these types of users by, by expanding the use on policy. So what we are saying, and, and I, I, I, I, I need to run through a little bit of the, the animations going forward.

We need to make this platform enabled to the identities, the roles and the entitlements. These are artifacts that normally traditional is handled by the, the IDI tooling. Okay. This information also should be available to the policy based access control system to be able to authorize and consume the, the information. Obviously we can also include, add other attribute sources that are not, I related, these are much more in, in, in line with understanding with which patients do we have, which medical records do we have, which APIs do we have?

So, so attribute sources where we actually can get to resource data and describe, and handle that information and allow the policy ending to know about them. Risk services is, is one example of sort attribute sources. Risk is what many our organization is trying to, to get into the policy evaluation. And we could easily find ways to integrate a risk service. Either from a user point of view can be the authentication provider. It can be actually a risk service that evaluating risk when it comes to financial transactions for what have you.

So this sort of complement the, the, the things that we need to connect to, but now the important part, the two arrows that are missing the two arrows, one arrow going from the policy engine to the identity provider, and one arrow going from the policy engine to the IDI tooling. And obviously, what is this? Okay. So in our term, it's, it's, it's one of the ways dealing with identity provider, for instance, providing dynamic claims to the identity provider.

So the identity provider can ask the policy engine, please provide for this given user, give me the claims that the users should be, be have. This can be based on groups and entitlements. What have you to the IDI? We have the same possibilities that in a provisioning process or an approval process, we can query it from the IDI query, the Indian, okay. Given this context, which are the entitlements that this user actually should be permissioned. And both of these things are, are quite interesting.

We are, we are, we are talking with a lot of organizations and, and, and, and IM specialists of how we can integrate. And we have simple patterns. Obviously these are integrations. It's not really plug and play, but obviously integration it's, it's, it's simple rest based APIs that the identity provider or the IGI solution can issue against the Indian and actually receive rich information back, meaning which entitlement should I provision at this given context?

So, so with that sort of, we are, we are saying that we would like to have a larger stake in the access control definition, and be able to use those across channels in, in the IM landscape, meaning that we can break this silos from, from being just supporting one single application, but actually supporting more multiple application and multiple services. Okay. This might be a little bit too fast for a very large concept, like, like this, but I'm finally reached to the, the, the, the, the conclusion of this.

And to, to me, it's, it's important to say that, okay, use policies to define access control, integrate with what you have break those silence silos and, and consume authorization a service. I, I will just leave this little slide at the back of the presentation if we have any questions coming from, from the audience or from you, Man. Thank you so much for bringing us through that. And yeah. Also walking us through this complicated idea.

So at the time there are no questions from the audience, but perhaps you could take a little more time, perhaps one or two minutes to walk us through this diagram and, and point out those things, which are really good to, to hold onto and, and take away from us that the audience should hold onto. Okay.

So, so, so you keep the time then, because I need to be at the family a Couple. Yeah. I will let you know. All right. Alright.

So, so specifically from, from an IGI point of view, so what we have seen so far is that the discussions we are having is how can we consume a policy to dynamic, dynamic, a calculate, for instance, birthright policies for a, a, a user that is not really created yet. So we have the possibility to, to allow the IDI tooling, to, to, to ask whenever it needs a policy for more information. So that will actually give us a Jason document coming back to the IDI tooling and the IDI experts need to take this pars, that information, and then provision that information to the sources that they have.

We also send use cases about automating approvals, meaning like if there are requests in the, in the IDI tools for access, we can evaluate by a call to the PDP, again, to find out if this request is in line with policy, if it's in line with policy, then it's an automated approval in the IDI system. But if, if, if the request is outside of policy, then it goes to a, a, a, a, a workflow approval process inside the IDI tool. And just to, to, to, to lastly say we do the same thing.

And if I wasn't clear on that for the identity provider, meaning like the Okta and the, for shock and the ping, if they would like to have dynamic entitlements, dynamic scopes provided through this engine, since it's, it's aware of a lot of different things, perhaps more than, than other tooling, it's, it's like a brain for access control. So that's why we can enrich those decisions or how I should, how I should describe it in the, in the authorization.