Hello and welcome to this latest webinar from KuppingerCole. My name is Paul Fisher and today we are joined by Ranavan Simancic from Evolvium Software who also are today's supporter of the webinar and we're going to be looking at access controls and more specifically how to find a way out of the maze that access control has become. So that's what we're doing today. So just a little bit of housekeeping. You don't have to do anything. Just sit back, relax and listen. We control everything here. There isn't any polls so you're either happy about that or you're sad but there will be questions at the end for you to question us, particularly Ranavan about what we've been talking about. And finally everything is recorded and backed up so that you colleagues can take a listen if they wish. So let's start with the quick agenda. So I'll be talking first of all about some basic choices for access for multiple identities and of course multiple operating systems or environments that we have today. Then Ranavan will continue with a much more granular look at a dynamic, sorry, dynamic policy driven RPAC and that'll hopefully become a lot. If you don't know what that is just yet you should do by the end of this webinar I hope and then we'll have some questions and wrap up. So let's see where we are. So I always like to start my presentations with this slide which basically says everything works with everything else and that kind of sums up the world of IT, the world of business IT and the world of everything frankly because right now we live in a world where everything indeed does work. It might not necessarily work very well but everything is connected to everything else and it means that many many more people, many more identities, many more machines are also trying to work with everything else and that's a trend which is clearly not going to stop. So let's break that down a little bit into something we can understand and I think that we have now a range of devices and people and software and automation which have created this everything everywhere world that I was talking about and obviously we have the devices that we all use. So we have our computing devices or compute devices as they are now rather horribly described as our mobiles. No one is complete without a smartphone these days and then extending that into robots, sensors, smart meters, the whole internet of things. So physical things are connected and we use those physical things to access other things particularly through our identities and then of course we have administrators who have become a kind of almost like a mythical sort of entity these days because what exactly is an admin because some admin is automated, some admin is still run by humans. With the advent of AI tools we're now seeing automatic admin and stuff but those administrators are desperately trying to keep a track of everything else which is happening between the devices and then in the software world we have this whole mixture of new stuff, containers, microservices, APIs are everywhere, code, workloads, etc. and all of those are adding to the mix. The devices, the admins are trying to access software applications or resources and finally you know coming back to AI then this slide actually predates EA so I didn't call it AI, I called it automation but whatever the hype is or anything else we do have to deal with bots, RPA, particularly manufacturing, so analytics is becoming automated, machine learning and search tools are all becoming more sophisticated but to make those things work and this is pertinent to artificial intelligence and the way that those tools that have emerged in the last 12 months or so work is obviously through access so we have quite a complicated mixture of things going on and behind that is what I call sort of unstoppable forces in identity because you just go back to the last slide all of these are creating identities and within this identities are everywhere so going back to this, so this world of business IT which is now very much to the fore, it's sucking in at the same time all these identities because identities are moving faster, they want faster access so that's our velocity but they're wider spread, they're wider spread so they're much more, you know, once upon a time identities could be safely enclosed in a perimeter, now they're everywhere and everywhere outside of the business IT and the actual number, the density of them is hard to quantify because with every new development that we have the number of identities seems to increase again and those forces are kind of are being pulled into the business IT because the business needs that velocity, it needs a dispersion, it needs a density of identities but it's much harder and we'll come on to how access control but all this plus what is happening elsewhere means it's much harder now to control access so this is, I call it identity flow and management in the cloud but in a sense it is identity and management everywhere and if you take your, breaking down this slide into a more granular look, so we have our core business infrastructure and I've broken down the kind of key number of identities or most common types of identities that you're going to find and so we have our admins in whatever form they are, they might be human or they may be machines these days, we have developers, developers, DevOps are increasingly important in any organization now and vendors in the access space understand that and which is why we are seeing, excuse me, why we're seeing solutions being developed purely for developers etc and then we have end users, end users of course are always going to be there in one form or another, they might do less actual computing but it's still, despite the scares about AI taking away all these jobs, we're still going to have people doing stuff and they're still going to need access to machines and machines themselves are identities and then adding to the wide dispersal of identities, we have third parties or in the sense of supply chain increasingly a part of this identity everywhere, everything everywhere world and endpoints, customers and so on and they're looking on the right for using cloud services predominantly, even on-prem is now can be seen as kind of a cloud to go with the actual clouds and whilst cloud isn't everywhere yet, there's no doubt that at one point will be the dominant way, dominant piece of infrastructure and they're looking for all those things on the right, all those resources or things that they want to get hold of but to get back to what we're talking about and what Radaban will talk a lot more about is this access control zoo, we have within, we have sort of three platforms, key platforms right now so we have privilege access management, we have identity access management and then recently we've seen the emergence of cloud infrastructure entitlement management and all those three platforms are what we have right now pretty much to somehow control the access of identities into everything that they want to get in and it's within those that we need to somehow create better forms of access control and at the bottom then I've added some foundational elements so zero trust design is something that has sort of come in and out of fashion, it's back in fashion right now, everyone's talking about creating zero trust networks and Pam, Kim and IAM are ways potentially of doing that but do remember that zero trust is a design, it's not a thing, it is increasingly standard subject to some kind of standard so you know if you work for the US government you have to prove that you've passed certain standards to try and create a zero trust and then we have again IRM, integrated risk management and finally data governance, privacy compliance and another thing that's recently emerged is the widening of the detection and re-remediation so identity threat detection and reduction has now emerged as something else which is sort of part of EDR so it's all becoming kind of an XDR and DR tools in general are being added to this whole infrastructure so to help with identities moving through this identity flow, whether they do or not is a subject for another webinar but there's certainly anything that can help is welcome so let's within the access control zoo we have right now we have sort of three types of access control so we have RBAC, EBAC and ABAC which sounds a little bit if you say it sounds a bit like piggyback but it is not so it's role-based access control, policy-based access control and then a recent emerging is attribute-based access control. What are the differences? Role-based access control is the oldest and most traditional form of access of controlling access. It is now fashionably out of fashion if you know what I mean. People are saying that our role-based access control is too limited, it's not suitable for today's dynamic environments, it's only associated with a single set of permissions and the role is the the why people don't like it so much is because it's not based on the identity, it's based simply on the role that identity is associated with so if I'm say the manager of the car fleet in a company, say the company cars, my role would be written down pretty much as it is in a job description which is quite a you know backward-looking slightly old-fashioned way of doing identity and it's fixed so my access control will always be based on that job description. People like it, I mean large corporations do like stuff which you know people like things which are listed, they like things which are easy to look at and manage and you know it does simplify management and it's scalable in large organizations when many users have similar needs. So it's suitable for very well-defined job functions so if that person and that job function never changes then their access control probably never changes and everything is okay. The problem is though that we increasingly people's roles change almost on a daily basis in some places, people need access to stuff that they didn't need yesterday and so on and it's very difficult for them suddenly your car manager is told that they need to do something which isn't normally in their job description to use that not in my that's not in my job description you know people say that. So the limitation to RBAC is it may not be flexible enough to deal with complex or dynamic environments where it needs change and more particularly the needs of the business may change you know like I said the person who is doing that job is expected to do something differently. So that brings us on to a more sophisticated approach so policy-based where instead of the access control being tied expressly to a fixed linear job description it is tied more to policies and these can be based on security policies, business policies etc. So you then bring in a much more wider set of parameters into the identity and but also the type of resource they're looking at some environmental factors and more. So when PBAC works well is in things where decisions can be made in real time and based on those policies it allows for more granular control over access and it should in theory give access in context awareness or rather in a context aware basis. So for example if the car fleet manager was working from home or in a different location suddenly the robot RBAC may not be able to deal with that sudden change of circumstances. So you add a policy that that person can access from a different location or you can add a further policy that they can only access from these locations and so on. So it's much more suitable for the world that we are living in right now in terms of business. It's much more suitable perhaps not for jobs that I've been using as a car fleet manager but perhaps for jobs or roles where things do change quite quickly on it on a maybe not a daily basis but a weekly basis. However, and this is the biggest downside, unlike RBAC it is much more complex to or at least it has been to date and it's complex to implement, it's complex to manage, it potentially means more time spent on administration and it has potentially a higher overhead in terms of performance and as I said administrative effort. So it does the job of providing more flexibility but it doesn't necessarily as it stands make the business any more efficient. It doesn't necessarily mean that all threats are removed. So finally we have now this kind of hybrid thing called, and not everyone uses this term, but I brought it in anyway, so that we have attribute-based control decisions. And again this is really a mixture of everything. So we have the roles, we have the resources they're looking at, the environmental conditions and it can make decisions more dynamic, it can take into account the context as I mentioned before. But it's kind of the way access control is heading so that we are gradually shifting away from roles, shifting more in to what works with the policy, but also crucially which now the attributes of that identity, and don't forget that the attributes of the identity can be attached to not just human identities but machine identities. If we have an AI bot for example, it could be, it's feasible that in the future that AI bot will also behave more like a human identity in that it does different things at different times, accesses different resources. So we need access controls that can take account of much wider attributes of the identity, the attributes of what they're looking for as well, and the context in which they're doing it. So it's basically taking the best of role-based and taking the best of policy-based and calling it attribute-based. And I know that Radovan is going to talk more about this as well, and so hold your horses if you're feeling a little confused. So just to show you, basically this is policy-based flow of policy-based access control and how it works. So your users, or we could call it identities, they're looking to access resource. The admin point then reads the policy enforcement or, sorry, the access gets to the policy enforcement point before they're allowed either a decision to allow access or not. The policy decision point looks for the policy information and that's where everything is stored and finally allows access to the resource which they may be looking for. So that's a very simplified version or schematic of how a PBAC workflow works. It's very similar for RBAC, but as you're about to find out, it's quite different when we start talking about attributes and how those work. And on that point, I will hand over now to Radovan. Thank you. So let's get into the access control zoo. So yeah, you're talking about the RBAC and ABAC and PBAC and there are a couple of other access control models from, well, including some very exotic and, for example, CBAC has two different definitions from two different vendors and so on. So there is kind of access control models like panopticum of different things. The problem is that none of them is perfect. Some of them actually may be quite good, but they are unproven or limited to certain use cases and so on. We know about role-based access control and that is probably still the one that is most used and there's policy-based access control and attribute-based access control that are used as well. But, you know, if none of them works for you, so what we can really do at that point? So let's have a look at where we actually started. So there is this traditional role-based access control that we are living with for several decades. It is a NIST standard and, well, we know that it is already outdated. We know that this does not work for the new and dynamic environment because it is quite static. It is not as static as many people believe, but it is quite static and it is not very practical anymore. Anyway, it is still the king of access control and many, many deployments start with role-based access control and that's where they have the data. They are pretty much locked in this model and they need to do something to migrate to other business, other access control models. So we know that role-based access control does not work. There are many reasons for this. I will not go into the details here. Some of these reasons are inherent to role-based access control, but others are more like bad practices, like things that are not fault of the role-based access control per se, but things that are people doing and abusing the module to get the job done. But the bad news is that policy-based access control and attribute-based access control are not perfect either. And there are some public secrets to share. Probably the most important public secret is that nobody really knows what access an employee should have. It is quite specific to employees. So if you look at the employee, at the job description, at company policies and all these documents and everything, you still cannot figure out what the privileges that employee should have. So the privileges are actually gained through some kind of access request and approval processes and assigned by administrators and negotiated at the meetings and so on. So they are actually not part of any written policy. On the other hand, policy-based access control and attribute-based access control relies on a policy to be executable code, to be very specific, very exact, up-to-date and in a machine-processable form. So now we have this kind of workforce identity problem that nobody really knows what access an employee should have. And we need to express that in executable code. So how realistic is that? How realistic is that feedback policy will work for a workforce? So policies, they look like they are easy. But in fact, if you go into creating a complex policy, it's a very, very hard problem. The other public secret is that your data are wrong. The data, everybody that works in identity management and governance knows that if you deploy your identity management deployment, there are always data errors. I'm working in identity management for more than two decades. And in all that my time, I haven't seen a single deployment where all the data were completely correct. Well, but that's another bad news for policy-based access control engines, because you know, garbage in, garbage out. If the data are wrong, the decisions will be wrong as well. These data errors were not that apparent in existing deployments because they do not rely on the data to be correct so much. The roles are again acquired through approval processes, and they are requested and static and so on, and they are somehow disconnected from the data. But that's not the case in policy-based access control. Policy-based access control relies on the data. And now if the data are wrong and you have algorithm that is automated, you know, automation can do a lot of harm in very, very short time. So many things can go very quickly and very wrong. And then there is third public secret. There is always an exception to every rule. So even if you have written policy on organizational level, you will still have some exceptions. For example, the CEO will have different access rights than stated by the policy. Or there will be work positions that are not like anything else. There will be temporary privileges assigned and so on. So there is always some kind of exception. Ideally, the exception should be temporary. Something like a testing account being created in state of emergency that should be deleted the next day. Well, you know, usually forgets to delete it. But there are exceptions. But the policy-based access control, it is not allowing, it is not meant to have any exceptions. So if exceptions needs to be there, they need to be incorporated into the policy, which makes the policy quite complicated. Also, it means that the policy needs to be recertificated, reviewed with attestation processes and so on that we are used to do withdrawals. Now we will need to do it with policies as well. And as policies are dependent on the data, and there may be exceptions in the data as well, the data needs to be recertified as well. So we are actually not going away from certifications. There will be just different types of certifications. Well, policy-based access control is supposed to be dynamic, but dynamic means changes. And this means that the policy-based access control policy will be changed quite frequently. So one big global policy is probably not going to work, because it's like one big piece of computer code that is not maintainable. The developers are not going to be able to The developers know that the code needs to be divided to smaller parts that are ideally independent to have the code maintainable. So that's probably what needs to happen to policy-based access control as well. But even if it is divided to smaller parts, how quickly can the policy be changed? It is like changing the computer code that needs to do simulations and so on, that the policy-based access control tools are not very good at the moment. So the deployment of policy-based access control may actually have the opposite effect, that the change is slower and more difficult than the role-based access control, at least at the beginning. So what can work? Role-based access control does not work, and the replacements do not work that well either. So what worked for us? Our approach was to base our approach on bottom-up method. So we start with existing access control data, which usually means role-based access control data. They were requested and approved, and they are their aesthetic privileges. These are actually very precious data. They were accumulated through years and years of company practice. So, well, yeah, there is some noise in the data. There is over-provisioning and so on. But there is also policy embedded in the data, policy that nobody really knows, but it is hidden there. So our approach is to start with the data, clean them up, find out the policy, and then use the policy that is hidden there. What we need to do is to use practices of artificial intelligence and machine learning. We know about data mining practices that are used in other fields. So in identity management field, there is role mining that is used to extract the business roles from role-based access control data. So similar practices could be used for policies as well. And that's the goal. And that's the goal. So our goal is to work from the bottom, to build up the policies slowly using artificial intelligence-assisted tools, and to keep the policy in smaller and manageable pieces. So what can work? We have actually two options. One option is use policy-based access control or attribute-based access control, but heavily extend it, add the missing pieces. And the missing pieces are request and approval processes, exception management, policy divided in manageable pieces, compliance management, tooling and simulations, and debugging and developer tools, and so on. So there's actually quite a lot of things that are missing there. And then there is another option. We can stick with role-based access control ideas, at least some of them, but enrich the roles with policies. So actually make a hybrid between policy-based access control and role-based access control. And that's what we have chosen to do. Our assumption or, well, our expectation is that role-based access control is here. And many people are locked into a role-based access control because the data are there. It is not going away anytime soon. So we need to deal with it. So we've chosen to add the dynamic policies into the roles. And there's a practical solution that is available in Midpoint today. So a few words about us. Our company is called Evolvium. It is a company that is developing an open source identity governance and administration platform. There is a very, very powerful platform with a lot of flexibility in it. It is recognized by analysts and appreciated by many customers worldwide. And Evolvium is dedicated to maintain the product and develop it further and providing professional support for it. So how it works for Midpoint. Midpoint is based on quite a traditional role-based access control. So we have roles in a classical way that the user has a static assignment to roles, which has a static assignment to permission and so on. But in Midpoint, there is a possibility to add dynamic policy-based assignments in addition to the static ones. So, for example, we can add a policy that will automatically assign a certain role based on the job positions or organizational structure membership and so on. Automatically assigning the role also means that the role is automatically unassigned when the initial condition changes. So this is very, very alike to attribute-based access control. And then there is yet another flexibility point, and that's in the role itself. So the role definition can be dynamic. The set of permissions given by the role can be again determined dynamically by the policy. So let's have a look at this using an example. So now on the left-hand side, we have a user with the name Jack. User with the name Jack. And this user has two roles. There is a role supervisor that is automatically assigned based on the job code. So you can notice that the job code of the role and job code of user Jack is the same number. And there is a policy that if these numbers match, then the role is automatically assigned. So this role is assigned based on the work position of the user. And then there is another role, employee, that is assigned to the user Jack as a birthright. So that means that the user type is employee. Then this role employee is automatically assigned and unassigned. What is interesting on the role is that here inside the role is a logic. And the logic specifies that the user should be assigned to the active directory group that has the same name as the user's location. In traditional role-based access control, you will need many roles to do the same thing, one role per location. And that you need to combine it, which usually leads to role explosion. But we have addressed the role explosion using this, like putting expression and logic inside the roles. It has several advantages. One is that you have much lower number of roles, like you will have a traditional role-based access control. And you still have policies that can be used to automatically assign, unassign the role or validate the existing role assignment. This all originates from the fact that there are too many existing deployments with role-based access control with static privileges. Well, it is now believed that the static permissions needs to go. And well, yeah, I agree they need to go. But what we do not probably agree is on the method how to get rid of them. So one way would be to create new policy from scratch that does the same thing as your existing role-based access control model. But that will be a huge amount of work and it will be like a disruptive process. So we have chosen a way how to start with existing role-based access control assignment and slowly improve the policies, discover the policies and make them more flexible. So this is a process that we have discovered. So start with ordinary role-based access control. That's what we are doing all anyway. And we are going anyway to start with that. Then use analytic capabilities to find the business roles out of that. Then you need to, then you can use the policy base to automatically assign and unassign the business roles. And the next step, you can make the role smarter. So for example, add expression and logic inside the roles. So make them better, make them like more close to the policy-based approach than the role-based access control approach. And then you probably find that there are some roles that are not used and just decommission them and remove them from the system. And then repeat that as necessary, because this is going to be a long and iterative process. And as we are hoping later in the future, we can get policy mining capability. So instead of administrators specifying the policy on a green field, we could be able to mine the policy from the data. So for example, we can find out that this specific business role is used by 99% of this organizational unit. So just assign this role automatically to the organizational unit. So to wrap up, this capability is already present in Midpoint 4.8, which is the most recent version of Midpoint. The Midpoint itself is very powerful and very flexible identity governance and administration platform. And it is probably one of the first examples that have the policy-driven RBAC mechanism as I have described here. The Midpoint already has organizational structure mechanism that is also very sophisticated and can be easily interconnected with the policy-driven role-based access control. What Midpoint has for last two versions is a simulation capability. So you can predict what the specific configuration change will do before you apply the change. It is a very important capability to have the transition to policy-based approach really safe, because you can simulate what the policy changes do before you apply them. And the latest Midpoint version has a role mining capability. So it is like the last piece that we were missing on the bottom-up approach from role-based access control to something more smarter and policy-based. And of course, there are much more features, too many to list here. So the policy-driven role-based access control as we call it, is here. It is practically Midpoint 4.8. You can use it today. It is well-designed to be iterative in incremental process. So you do not need to change your approach in one day. Our approach is compatible with static role-based access control. So actually, you can mix these two together. You can continue with static role-based access control and slowly improve the situation to the point where you are able to switch to the policy-based approach completely. If you have some exceptions to the policy and so on, they still can be handled with traditional role-based access control, but they can be marked and tracked and monitored and eventually phased away. Thanks to the simulations, it is a very safe approach. And we believe it is sustainable in the long term because the policy is divided into small manageable pieces. So to conclude, as we know, both traditional role-based access control and policy-based access control, and activity-based access control in its current form is very likely to fail. We know how role-based access control fails and we can predict what will be the problems of current policy-based approaches. Both of them need to evolve to really solve the problem. And it looks like the real solution to the problem is a combined approach that allows policy-based approach to fit into real-world scenarios and for role-based access control to be more dynamic and policy-based. What we believe is the right approach is bottom-up approach. So start with existing data, start with what you have and incrementally improve your policies. And the solution is available at midpoint today. And that's it from my side. Okay, thank you so much, Radovan. I mean, I was talking about RBAC and PBAC and then I mentioned attribute-based, which is a little bit wishy-washy because it actually seems to be a kind of version of PBAC really, except it adds a little bit more to it. But what you're saying is there are good things in RBAC and there are obviously good things in PBAC, but what's key to... Is it the policy mining bit that is the key to what you're offering so that you get the best of PBAC and RBAC? Or is it something else? Well, eventually it will be policy mining when we get there. But for now, it is the capability to assign the roles using policies. So one of the biggest problems with roles is that they are static, they will be assigned or they are assigned in sometimes very questionable ways. And the biggest problem is to remove the assignments to reduce the over-provisioning that the role-based control is very prone to. Yeah, sorry, go ahead. So if you change to policies, then there is a way how to control the over-provisioning because if you assign something algorithmically based on the policy, you can remove it based on the same policy as well. So that's the key that is feasible today. Yeah, and the role mining is a tool how to make this efficient. So you are not assigning application roles or low-level privileges, but you are actually assigning business roles that are a result of the role mining. Okay, you mentioned all those other BACs. I mean, there's a question just come in actually. It seems sort of pertinent to this. It says ABAC works in some cases, but you say it's flawed. How is that possible? So how can it be flawed and work? I think is what that question is. Yeah, it can. Actually, ABAC is very, very efficient tool in some cases. So if you have a user population that is where the permissions are very regular, you can use ABAC or PBAC with a lot of success. So for example, consumer identity management is a very good example for that because then the permissions are assigned in a very algorithmic ways based on locations and customer levels and then discount classes and so on. So in these cases, it works and it's very scalable and very good. But it fails in a situation where the access control patterns are very irregular. So workforce identity management is a prime example of that. It's sometimes it's as irregular as it gets. And you cannot put that policy into algorithmic language. So it won't work in these cases. Yeah, because I mean, what policy base or role base is very static at the moment and it is based, like I said, almost on job descriptions and it's attached quite often to active directory and things like that. But one thing that you mentioned, which I thought was very interesting is that people have more than one role. So an identity can do one job, but these days they can also do another job, maybe more than two jobs. So that's where ABAC on its own is vulnerable. Well, yeah, if ABAC is used in this way that one user has one role, then yes, and that's usually case for the roles that are like roles based on the job code and so on. So even in my example, I have two roles already. So, you know, the problem is that you can have many roles assigned to a user in ABAC, but the problem is how they are assigned. They are usually assigned that the user is requesting the role that gets approved, assigned and never removed. So they accumulate and there is a lot of noise in the data and that's dealing with that noise is a big problem in ABAC. Okay, I've got another interesting question. How can we implement policy-based approach if the policy is not known? Very, a bit of a conundrum. Yeah, the policy is not known to any single person. The policy is not written down in any single document, but the policy is there in the data. So it is hidden. It is like covered with this noise, but it is there. So for example, what we are doing with Midpoint 4.8 is we have a role mining capability and we can discover business roles that nobody really knew were there, but they are in the data. And if we discover them and suggest them to the administrators, then they suddenly realize that, this is what we need to put in the role and it will save us like a lot of trouble with management down the road. Or the policy is there, but it is hidden. Yeah, I mean, this is a... Do you know what? Before I started doing this webinar, I thought I kind of understood access control, but the more you look into it, the more complex it is and just basing access on a single thing seems to be difficult. Do you think... I mean, I mentioned when people talk about attributes, sometimes they also bring in the type of resource they're trying to access, whether it's privilege or whether it's high risk or whether it's valuable. Is that an area we should look at or should we just concentrate still on R's and policies, roles and policies? Certainly, yeah. We need to look at the resource and the target in the case of traditional R, but in the permission and the application that the permission belongs to and so on. So for example, risk-based marking of the permissions seems to be a very efficient way how to determine the priorities where to look at, especially when cleaning role-based access control data. We should prioritize these that are higher risks. So yes, the policies usually say about attributes of the user, but the attributes on the other side, on the permission level, on the permission side and application side are as important as well. Yeah, that's what I was kind of getting at. So I think we might see that developing in the future as an extra risk reduction layer. Someone's actually said, why do we need roles? Why are roles necessary? Why don't we just have completely policy-based without any role? Well, there are cases when we can go completely policy-based like this consumer identity management case. However, the roles are very practical as a unit of independent policy pieces, I would say. So if we divide the policy into smaller roles that are ideally independent of each other, then we can manage these policies in quite a predictable way. So for example, in role-based access control, when I assign a role to a single user, I know that only thing that will get affected by this operation is that single user. So the impact of this operation is limited. In policy-based access control, I'm never sure because I'm writing a policy that can interact with other policy pieces. But if we combine the role-based access control and policy-based access control, we can still have this locality encapsulation, I would say. So if we modify one role or policy in one role, we can be pretty sure that only the users that have that role will be affected. Okay, well, I mean, we still tend to think of roles and identities, obviously, as human-based and with good reasons. You know, there's still quite a lot of people left that have jobs. But there will come a time when identities will be attached to machines that are not fixed, as in, like, a bot that just does one thing and has access to one thing that will have kind of AI bots that behave more like human identities. So will your solution be able to cope with those as well? We hope so. It's not saying until we get there, eventually. But yeah, we have designed for that. Midpoint can handle machine identities even today. So the processes are similar in some way. But subtly different. So yeah, we have a special kind of object for that, we call it service, that can be subtyped to a specific use case, yeah. Okay. Oh, we are seeing quite a, wow, suddenly a whole sudden rush of questions just come in. I don't know if we have time for all of them. So, okay. How is Midpoint different from all existing IGA tools? These policies could easily be incorporated into an existing IGA tool. What is new here? What is new, they're saying? Actually, these policies cannot be easily incorporated in many existing tools. The ability to automatically assign an unassigned role, it's pretty common. Midpoint makes it much more powerful with a lot of flexibility. But this is quite a common feature. What is not really common is to have a logic inside the roles. So the other side is not that common. And Midpoint makes it manageable and an integral part of the policy from day one. So when we designed the role-based access control model, we have already expected that this will be there. And this functionality is in Midpoint for many years already. Okay, I mentioned AI just now, but that was more in the context of an identity. But you said that AI and ML is applied in Midpoint at the moment. Can you just maybe enlarge on that a little bit? Yeah, for now, the prime feature for machine learning is role mining. So that's where we started with putting the AI tools in it. So we are using clustering mechanism and pattern detection mechanism to make recommendations for new business roles. We have plans to expand that more. We need to develop this into policy mining. And the policy mining is like an ultimate goal with respect to access control. And do you see AI capabilities in being able to discover hidden policies within the kind of complex environments that I described, as in everything is everywhere, you know, everyone's accessing from different places from different companies, et cetera. Do you see a role there for AI? Of course, we are confident that it will help quite a lot. We have seen the results with the role mining capability. So extend it to some kind of policy mining. Well, it won't be straightforward. I won't lie here, but it should be feasible. At least the automatic assignment of roles should be feasible than the expression in the roles we will see. But definitely that's a part that we will take. Yeah. OK, so if an identity has a temporary role assigned or is on a secondment, how would this segregation of duty be handled within each policy or an overarching policy? Is this toxic combination, it says here, this is the question, discoverable in policy discovery? Do you understand that question? Yes, yes, yes. Well, I'm glad you do. OK. Well, there are actually two questions in there. One is the segregation of duties and temporary assignment of privileges. Well, at least in Midpoint, if there is a strict segregation of duties policy in place, Midpoint won't allow even a temporary assignment of that will violate the segregation of duties. In a slightly milder configuration, this is subject to approval process. So it may allow it. Subject to approval. However, segregation of duties is much trickier than it seems, because it is especially difficult is how to enforce it, how to put it into action, because there may be existing violations already in place. So there needs to be some kind of process that will just detect the violation, slowly remove them and then enforce them and enforce their role. So that's already in Midpoint. But the second part of the questions is whether the role, or I assume it is, is whether the role mining will handle the temporary assignment of privileges. And for now, it is not exactly built for that purpose. The purpose is to find the patterns in indefinite assignment of the privileges, where in practical deployments, these are the vast majority of all the privileges there. And the core of the policy is hidden there. Current ambition of role mining is not to discover all these roles. It is probably beyond the practical limit that is really efficient for organization. The current ambition is to discover the prime roles, the most lucrative roles that will make the process efficient by, I don't know, 60% or 80%. Make the process efficient to 100% is probably not feasible at all. Okay. Well, we're nearly at the end. That's all the questions that I have. It's a fascinating area, actually. Like I said, I thought I knew about our access controls and our back, et cetera. But clearly I need to go back to and learn a bit more because it's particularly in the world that we're now working in. So I'm sure we'll return to this topic on other webinars and probably at our conferences as well, I'm sure. And hopefully, Radovan, I'll get to see you at one of our conferences. In the meantime, it's been a pleasure having you with us today. Radovan Semenchik from Evolvium. Also, thanks to you for listening in and watching. And as I said, don't forget, this will be downloadable quite soon from our website. But for now, thanks again and see you the next time on one of our webinars. Thank you and goodbye. Goodbye.
