Simplify Identity Management With User Centric Personas and PBAC

Hello everyone. Welcome to today's webinar, Simplify Identity Management With User Centric Personas and Policy-Based Access Control. Today's webinar is supported by TrustBuilder. I am Nitish Deshpande, Research Analyst at KuppingerCole and today I'm joined by Kurt Berghs, Product Manager at TrustBuilder.

In today's webinar, we will go through the traditional and the current architecture of Policy-Based Access Controls, benefits of Policy-Based Access Controls from security and business point of view, also first concept of personas and delegation of rights using self-service from a TrustBuilder point of view. Before we begin, we have some instructions for today's webinar. First is audio control. You all are centrally muted and we're controlling it from here so you don't need to mute or unmute yourself. Next is polls.

As always, we want to keep these webinars interactive so we'll be running a few polls during the webinar and discussing the results in the final Q&A session. So I would encourage everyone to take part in these polls and select your answer. Next is the question and answers. Towards the end of the webinar, we will have a dedicated Q&A session but you can enter your questions at any time using the C event control panel and we will address as many questions as possible in the given time. And finally, the recording and the slides.

We are recording this webinar and the recording and the slides will be made available in the coming days. So first, we will begin today with some definition of policy-based access controls, the key components of policy-based access controls, and the benefits.

Next, we have Kurt who will give an overview on personas, personal consolidation, and delegation of rights via self-service. And finally, the discussion in Q&A session. Let's first start with the poll and I would encourage everyone again to answer questions. The question is, how is managing access for multiple overlapping identities done in the organization?

Is it A, role-based access controls, B, attribute-based access controls, or C, policy-based access controls? We will give everyone around 15 to 20 seconds to answer the question. Thank you everyone. Thank you for your answers. I look forward to see the results in the final Q&A session, so stay tuned. And I would like to begin first with some overview of policy-based access controls and what it allows us. So policy-based access control is a critical cybersecurity component of organizations. It allows centralized policy management.

It provides real-time decision-making using the current data instead of the old data. Policy-based access control also provides fine-grained access controls. It can be based on context or attributes. It also allows ease of integration in group organizations. Policies are given by personas, so there will be different policies based on different personas. If you take a look at this diagram of traditional feedback architecture, there are four key components.

Of course, you have the user who is requesting access, but we have one policy decision point, which makes the decision if the user should have access or not. Next, we have the enforcement point. This one is located near the resource or the asset which the user is trying to gain access. Then you have the information point. This provides the context and more information to make the decision if the user should have access or not. And finally, we have the policy administration point. This is mainly for adjusting, managing, and updating policies from admin point of view.

So that brings us to some of the key components of feedback. So what are they? There are five components. First is subject. It's the user identity that is requesting access.

Next, we have object. It's an asset or resource that is being accessed or that is being requested access.

Third, we have the action. That is, should the user get the access or not? So the task carried out in this context. And finally, the fourth is the context. So there should be additional information provided for making decisions based on the attributes. And all of this falls under policies. So the policy needs to be well-defined, and so this can help in processing or granting access. So we have just seen the traditional architecture of EVAC, but what's the current state of policy-based access control, and what is the future of policies in IAM?

Let's first take a look at the current normal, that is, the cloud-native policy-based architecture. Similarly, through traditional architecture, you have user requesting access, or resource component. But there's an API, and it could be a service mesh type of situation that sends a JSON query to open policy agent.

Now, you can see there is a policy store and a data store. The open policy agent interacts with the policy store and data store to make the decision, and that is sent back to the component if the user should have access or not.

Now, what's the future for policies? Policies are everywhere, and they will be everywhere. They are in identity management, they are in access management, they are also in other domains, such as firewall, and even in our normal day-to-day activities. And policies are defined by four components, which we just discussed. The subject, which is user requesting access, action is if the user should have access or not. We have the object, which is the asset, and the context, which will be the location of the user or any other attributes.

And what this does is that policies allow us for better roles and lesser recertification. You can derive roles and entitlements from policies, and this will help in recertifying policies instead of manually recertifying roles. It also allows automating static entitlements. Then we have adaptive authentication. We are already using adaptive authentication in using policies for risk-based and context-based authentication. Then we have dynamic authorization. Enforcing policy-based access management with front-end decision authorization can be achieved via policy.

And finally, policies help in enforcing zero-trust. If you look at the NIH Net Zero-Trust Diagram, policies are at the core of the diagram, at the core of the architecture. And by that, they are there for a reason, that is continuous verification based on policies.

Now, what can we achieve via policies? There are a couple of benefits. We have classified them in business and security benefits.

First, on the left side, you can see the business benefits which you can achieve via feedback. First is regulatory compliance. Feedback imposes policies that helps us in meeting the ever-evolving regulatory requirements. Next is automated access decisions. You can automate provisioning and deprovisioning via policies, and this will help in saving time and manual effort as well. Third is for auditing and reporting purposes. Feedback will track all the changes related to access requests and log them, which can be used for auditing. Fourth is reducing over-provisioning.

Only those who require access will be given based on policies. Thus, we will save costs from over-provisioning. And on the right side, you can see the security benefits. First is granular access control. Feedback allows fine-grained definition of policies as well as implementation. This fine-grained definition can take place at an attribute base. Next is reducing attack surface. If policies can help us in providing access to only those who require, we can mitigate the risk arising out of unauthorized access. Third is we are protecting sensitive information behind defined policies.

Only those who have access to sensitive information will be allowed via policies. And fourth is dynamic policy adaptation. Policies can be updated and adjusted in real-time based on any changes in the attributes and any other external factors.

However, this brings us to see how policies can be used to unify identity management with identity-centric personas. And for that, you need identity-centric personas to work with policy-based access management. And to make this work, you need four components. First is personas. You need to identify the key personas, define their attributes, and assign unique identifiers. Each profile can have multiple personas, so it's important to assign unique identifiers to distinguish between different personas. Next is policy mapping. Map the personas to the existing policies.

You should do this via carefully reviewing the current existing policies. Then you have the policy enforcement engine. This is the one which will evaluate the policies and make access decisions based on the information about each persona. This is where the contextual information comes in place and helps in making the correct decisions. And finally, you have monitoring, review, and update of policies. You should regularly review access logs and update policies to meet the demands of the changes in persona attributes. That brings us to now the second poll.

And what we want to ask right now is, is delegation of rights using self-service available in your organization? Is it A, yes?

B, no? Or C, partial?

Again, we'll give you 15-20 seconds to answer this question. Okay, I think that's it.

Thank you, everyone, for your answers. We will again discuss this in the final session. That brings us now to Kurt's part.

Kurt, are you here? Thank you for the introduction and the presentation. So my name is Kurt Beiss. I'm VP Product Marketing at TrustBuilder. And I'm going to explain one of the things that we do is how to simplify identity management with persona as well as feedback. But maybe I'll first start a bit about TrustBuilder. TrustBuilder, it's a European company. It's a European company. And we started the solution, which was already discovered by Rene Descartes in 1673. I think therefore IAM. So TrustBuilder, we're a European company.

We're based in France, Belgium, Ghent, as well as in Italy and in Spain. And we are a company with about 100 employees. We have 350 customers, a bit across every different vertical, going from finance, health, insurance, public towards consumers. And we're really focusing there on those consumers and customer applications. And how do we do this? We did an investigation based on a survey with 300 CEOs of large customer-focused organizations within Europe. And we discovered that we could categorize them in five stages regarding their IAM strategy.

At first start, there was a big category, all having issues with connecting digital assets, digital identities towards their customers in web-based applications or mobile applications. And they need to be connected, making sure that they can all work together.

That's, of course, the course of IAM. How can we connect all those different systems? Once that was done, they want to give more convenience towards their users and give them a better customer experience by adding passwordless authentication, single sign-on, multi-factor authentication, and what have you. Next stage that we can find a lot of companies being there is that they want to connect with other companies, other IDPs, external IDPs, external applications, to make sure that they work all seamlessly together.

And that's where we have solutions like federated identity, secure APIs, and adaptive security. Especially in the consumer-facing markets, we noticed that people or customers are expanding their traditional services with new services and are starting to create ecosystems or becoming a part of an ecosystem to offer those services to other parties or offering other party services through their applications. That's where we have an ecosystem with applications as well as IDPs that you can seamlessly connect together.

And the goal is, of course, not to just make it easier to access these applications, but the end goal for those customers is to find new ways of finding revenue. Also, on the deployment model, we noticed that lots of companies are still on an on-premise or started with an on-premise, going through hybrids more and more. And the final intention is that they go to a cloud-based SaaS solution. All these things and all that vision, that is where TrustBuilder can help you with. And we do that on a couple of use cases that we support.

Basically, we try to support the complete digital journey of a user, and we support organizations in every step of their customer journey with a modular concept that fits right into their existing organization. So you can benefit from the feature that TrustBuilder offers without having to do a tabula rasa of your existing infrastructure, which would, of course, disrupt your business.

And we can do that for onboarding, for identification of users, the authentication and strong authentication of those users, as well as the fine-grained authorization making it possible for those users to access different applications. And it's about that authorization that this session will go a bit deeper into. We solve this with policy-based access management based on personas. To give you an intro about this and how this works, I will give you a couple of examples based on RBAC systems and where they will fail. I do not want to diminish the value of RBAC systems. They are easy to set up.

And from an IT perspective, it's very clear in segregating the different access rights that users are entitled to have. But in more complex business environments, RBAC systems don't have that required flexibility. So maybe a first example of that complexity is a telco organization. So within a telco organization, you have different types of roles or business roles for your users. And you have internal employees, external employees. They can be based in the headquarters or in one of those distribution centers. They have partners, different types of partners.

And, of course, they have customers and prospects. Now, if you're an employee of one of those telcos, it's very seldom that you just have one role. You will have multiple of those roles. So a user A can be, for example, a shop manager, but he can be an independent shop manager. So he's also a non-office interim.

And, of course, if you're selling that product, you will also be a customer and probably also a business customer for that telco. So in a digital context, that makes it difficult because it is that one user who has multiple business roles. And this is where it becomes difficult, not only for the internal people, but also for the user himself, because that user will have multiple accounts based on what he needs to access which application.

So if he is a shop manager, he will be in a dedicated AD linked towards receiving an account and a role specifically for all the people who work for that telco. But since he's also a non-office interim manager, so he's not in the HR system himself. So they need to set up a second HR system or a dedicated system, LDAP system, where that user will get another account to access certain resources. And then the third, if you are a business customer and maybe a fourth, if you're also a consumer customer from that company, you will have, again, another account, again, with a username and password.

And if you would like to secure those accounts with, for example, strong authentication, then it becomes even more difficult to secure all those accesses with one authenticator towards the different applications. The second pain point of RBAC is that this is what is commonly known as role exclusion.

And we have here an example where, a simple example of a company, an insurance company in this case, where you have a couple of roles, applications that the employees need to access, like the fire insurance, the life care insurance, the car insurance, you have risk managers, you have also department offices and so on. So if you have like 15 of those applications spread over 20 locations, you will see that you will very easily come to 300 roles. But that's, of course, a very simplistic vision of that role exclusion.

And when I was talking to another real life insurance customer, they were talking to me about having 9000 employees and having 21,000 different roles for those 9000 employees. And last week, even I was talking to another company with 40,000 employees that were complaining to me that they had 24 million entitlements to manage for those 40,000 employees. And so that's on average, 600 different entitlements for each employee. So that's a very complex system, which is very hard to handle with an RBAC system.

And then the last example of that complexity, where I don't even know how to begin on solving this with role-based access, is where you have companies working together, companies from different locations and different countries with different regulations where people might work for a combined project or combined project, working in different roles than that they have at their mother company, like in construction or engineering, you have these type of applications.

So for a role-based environment, that would mean that for each application, you will have need to create a set of roles for those users. And these roles need to be added to the different users across different organizations that might not even speak the same language. And also it's an administrative nightmare with a lot of security risks if, for example, people leave or change roles or no longer work on that project. Very difficult in a role-based and an RBAC system to manage.

Whereas if you look at a PBAC system, what you will do is for each of those applications of the combined project, you will need to create a policy. And that policy will hold different attributes for users to access, that the user is required to access that specific application, making it a lot more simple to give that access. But like I said, not every company is required to have such a complex organization. And this is where we have sometimes the confusion, where do you want to need personas and when you want to have roles?

Basically, how we explain it is that if you have one user, we always say that that one user will have one single identity. Because of course, me as a user, I just have this one particular role.

Now, in real life as well, it could be that you have multiple heads that you need to carry and different business roles that you have. And it's these business roles that we map onto those personas. So personas is the real life context of a person where you can have multiple responsibilities or roles or heads or however you want to call it, but we call it personas.

Now, on a technical environment, we can map those persona onto technical roles, technical roles or groups in applications in an AD, for example, and captured in attributes so that they can match the existing systems and technical role which is available in an SAP or Active Directory Salesforce and so on. And there, if you are a salesperson, if you have the role, technical role sales, that reflects also on your business role as a sales.

If you want to access a technical application like Jara or something, you would need to have the head technical role, but that allows you to play if you have both heads to access both systems with that one single identity. So the roles, technical roles, they reflect the technical context of applications with their different rights. So what is the advantage of personas?

Say you have one person, you have one profile, so each user receives just one and only one profile where you can add these different authentication methods on so that he can use that same method of authentication towards all applications. But then if he wants to access an application in a different business role, we add that persona on there because that reflects the relationship that you have with that organization. And that way you can switch between the different business roles or the different personas very easily depending on how you want to access a certain application.

To give you an example, within banking I can be, and this person is Ansmit, all that personal information will be the same of course for the whole of the company. It's one UUID, one user ID, and the name and the first name and so on will always be the same.

Now then depending on what he wants to access in that bank, if he wants to access his personal retail or his consumer account, we add a persona called consumer to it and we put the persona specific attributes within that persona so that it is the type of consumer, which bank account that he has, the contract that is related to this, when it starts and if it's valid or not. And we can add multiple of those attributes towards that persona.

That same user also has a business account, so we're going to add now a new persona, a business persona to that one with then the different attributes specifically for his business, so the name of his company or the companies, if there are multiple that he can access, the different bank accounts that he can access and link to where works that contract as well.

You can even have a third persona if he wants to manage somebody else's account, it's called a carrying proxy, then we can add that one as well and there we can ask permission to get access to that personal or that third party account to access. So in this case the persona type is a carrying proxy, the bank account involved is specific towards the third party in this case, and the validity can be limited to a certain period of time.

That period of time, that validation period, is also very important because in a real world as well, roles change and the way you have to access applications that can change as well.

For example, if you take a university and specifically a medical university, roles can change over time, so you start there as a visitor of the university to check if you want to study there, you become a student, you go a bit further, you can become a nurse or whatever and finally a professor or if you don't want to go there but you are very specialized in what you do, you can become a guest lecturer or a researcher, but at the same time you can also become ill of course and then become a patient or during your internship or during your student you can become an intern on different locations and so on.

So the advantage of having that validity makes it possible to give that user certain rights for a certain period of time towards those different applications. Now adding to the personas, we can also add delegation and delegation can work in two ways. First of all, it can be delegated from top to bottom, so in this case the payroll administrator in this case will go on leave for example and he wants one of her subordinates to take over to give her access.

What usually happens in a company then is that people will just give around their username and password so that that person can access for the time that they are accessing or need to access an application that they can access the application and do the work for her. That's of course the worst situation ever because you know that that password will also be used for other applications and who knows that user once he has that password it probably doesn't change that often so he can keep on accessing those applications even after his role as a substitute would have ended.

So how do we solve that with persona? We are going to delegate that payroll towards a support unit and we will say okay this user will now be an administrator for two weeks so he can do the payments for that one for that period of time. The user needs to accept it and then we can add the persona payroll administrator to that employee for a limited amount of time in this case two weeks. So they can be added delegated temporary or permanently to one person following in this case a top-to-bottom approach.

But it's also possible the other way around for example if these persons are now the sales manager and the salesperson and that salesperson needs to access this CRM system meaning that usually in a normal organization they will need to go to IT, ask IT to give them access. IT needs to check with the HR system or with the CRM administrator to see if he can get access to that application whole process that needs to be implemented.

Well actually it's much easier if that employee wants to access that system you just ask the CRM administrator to get access to that system adding that persona to his user profile. The CRM administrator will then need to approve it and then because of that the user will have access towards that application. So how does that persona now go into the feedback system? So we have all these persona and all the attributes that we have and then we can create policies. Policies that will include those personas to give access or block access and put timelines on within that policy.

I will give you now some use cases and some practical examples of how this will look at. So the first one is persona within applications. So if you have an application, a CRM, a retail application for example or when you're selling subscriptions towards a user and that user has two different roles, business roles, a customer and a business account for example and they are both in both situations she's interested in your subscription that would mean in a regular situation that you need to create two accounts for that one user with again two usernames and two passwords.

With the persona concept we can add two twins a personal account and a professional account to that one user so we can use the same username and password logging into the application and link within your application the correct ID towards the personal persona or the professional persona with its own subscriptions. So that works like this.

So I've got the identity of in this case Ann who has an email address which will be your user ID and then some personal stuff of her and for the personal persona we will give these attributes with the correct CRM IDs, the email address that you need to send her emails to for that specific subscriptions or that specific account and then we can add a second professional identity towards Ann with the different email address and a different CRM ID with all the logins and so on stay the same which will does also mean that if Ann has access to your system as a as for example with her personal persona or with the personal account you don't need to she doesn't need to log out and log in anymore you can very easily switch by adding a button somewhere on on your application between the different personas without the needs of having to re-authenticate or re-login and switch between those different personas making it a lot flexible more flexible and much more user-friendly for your customers.

Second use case on the delegation and in this case we're going to the delegation between consumers so we have and I'm going to take the example of a retail banking delegation where we have two retail customers the digital twin of Anna which has a personal account and a professional account each with their own CRM system CRM ID for that those accounts and then we have the mother of Ann who has a personal account with that bank as well now the mother of Ann is becoming is becoming is having troubles with that bank account it's digital and she doesn't really understand what to do so what Ann needs to do is she wants to access that application so rather than asking the credentials of her mother to access that application we can just allow on to request access to that specific account of her mother the advantage is on the one hand that of course credentials are not you don't need to be shared anymore and secondly you can also segregate different accounts of her mother and limit the time that Ann has access to those applications so she already had them a personal account and a professional account and now she is asking to get also the proxy account and she has to ask it and that goes of course out of bent towards the mother allowing her to that she can access those accounts and if the mother agrees to it she will approve it and once it's approved Ann will also have access towards that application this was a simple example in retail because there's not that many users involved but the main advantage is once you're working with partners with partners and partners have multiple accounts that need to access your applications or your resources so what I did here was create an example in this case it's a school lecture business that gives courses and I've got here Paul Jones who wants to access one of these trainings that the company is giving that third-party company is giving so he's going to register and he's going to register and automatically he doesn't need to do anything but by registering on that application the company will automatically create a company a persona as a person participant linked towards that user and then that user can access all those resources where he has rights to as a participant now since Paul is also the the financial manager and he wants to train his team and he thought the course was interesting he will ask the company that runs the courses to become a company administrator so that he can also manage the accounts or the users from that belong to them so what he will do is he will first ask the the university or the training center to become a company administrator so he can start managing his own users and then Ann will say okay that's fine I'm going to give you the rights to get to do this and by agreeing to this a new persona a new role for business role for Paul will be added being the company administrator of the company PepsiCo in this case once he's done this so now he can start adding users and the first user that he wants to add this is Mickey in this case so I want you to add Mickey as a customer for for this course and then Paul or Sven who's renamed but Paul will ask as two roles the company administrator and a participant and he will give create the task for that user to also become a company participant so by registering that user we will create a new user profile for Mickey on the one end as well as adding a persona being the company participant for that user in this case in the state of spending so what in real life will happen is Paul will access our self-service portal created for that training center he will have a new new section here called users and in there he can manage the users for for his company to access these different resources now the self-service portal is managed by the training center but this section is specifically for the user of of PepsiCo the administrator of PepsiCo where he can see and access his different users so we can start there creating a new user and then adding the different personas being a finance manager employee or whatever that he needs her to be to get access towards towards those trainings and you can also set other things like in the scope of which companies that Paul has access to the the departments he's responsible for and the validity like mentioned before how long that user can access these these resources so we've created now that user and what happens then is a notification will be sent in the form in this case of an email towards Megan who will then activate her user profile so by doing all this you have now used personas to delegate administration towards third parties people who are not part of your company and where you where it administrators do no longer need to manage the whole users and the user identities of of those of those people and you can redirect that responsibility to the people that know best best these users and so on so that was a bit some examples of the personas I hope I made you think a bit about it if you're in doubt you're in the right place because if you doubt you're into IAM thank you so much thank you for your presentation it's quite insightful and now we will take a look at some of the results from the poll which we take in a few earlier so if it's possible we can now see the results yes so here it is the first one how is managing access for multiple overlapping organization almost 80 percent has said it's role-based access controls and it's zero percent for policy-based access controls so what what do you think of this this result it's uh I think it's normal uh especially because major uh all the major IAM systems that are working role-based uh still um and and yeah the difficulty lies in indeed how are we going to go from from those role-based systems like can we manage all those different attributes uh sorry all those different uh business requirements that we need to to fulfill as long as as the business is simple then it's easy and there are of course also tools to to to work around it but they cost a lot of development and additional resources to to manage that which is not like in the core of that system okay thanks thanks sir um I think we can also take a look at the answers from the result from second poll we'll just bring it up is delegation of rights using self-service available in your organization and half of the audience have mentioned no but there is some still that will say yes and partially so this is what aligns with what you have also seen in the market I think that's uh that's indeed uh yeah not everybody does it um it's it's good that some are doing it partially uh already 22 percent uh so one out of uh five uh do have it it's it's very important to to get this in in most organizations I think um especially in the larger organizations that we notice that there is a big risk when people are from partners are moving or leaving uh their organization if that's not done through self-service it's usually done through uh internal it people who know way too late that those people are moving and so on so it's important that uh that that you look at that delegation of self-service availabilities yeah okay thanks I think okay so we have a few questions already I'll start with the first one um so there's a comment and a question as well so it says there used to be a philosophical or almost religious battle between ABAC and RBAC and now it seems EBAC is the new religion um isn't it correct to say that either of these three can be used depending on the situation and and we just saw the results right now uh so it's kind of similar to what we're seeing in the question yeah it's uh whatever religion has its own truth it's nice to have that philosophical in there as well um it's uh it depends on the use case you're trying to solve of course it's not that EBAC is is like the holy grail uh of everything especially in in the easier use cases um then RBAC system will definitely be be good um it'd be interesting because it's it's clear and it's uh it's easy to manage it's also linked towards the application so uh especially in those cases that that's where RBAC definitely will help it's when when when you come in more complex business situations that EBAC can add on to our RBAC and it's even best to to mix them all together or to have them both RBAC ABAC and so on ABAC yeah I forgot to tell about ABAC that's also really interesting about ABAC is the flexibility that you get from that um the flexibility that that you can literally use any type of attribute and decide whatever uh however that you want to do that uh access that application based on the attributes that you have which in systems even where uh account numbers and and all kinds of different information are being used as attributes to decide whether a user can access a certain uh resource or not um the advantage of PBAC is that it can have a bit of both so you can like I said in that one slide you can use PBAC to match the technical roles as well and give access towards those applications but they have the flexibilities of attributes that you can put in the scopes and within that Paxova you can still take all the different attributes in there as well so and on top of it that it also helps you with those policies to increase the level of security and match those security requirements that you could have for different types of applications okay and there's one more it says for switching for personas can it be more than work personal and rather be multiple personas within within their work identity so if you could have multiple personas within one identity and how do you work identity so it says like can there be more the more personas multiple personas within their work identity yes yes of course um it all depends on on the business role that you have um and I always uh that that's the fun thing about uh about personas it really matches your real life situation um me myself I've always had a couple of uh business roles a couple of hats within the organization I've been a product manager a developer a sales and sometimes you have to do both by uh or doing both at the same time or during the same period of time at least um and then this one is really interesting because then for example if you want to add if you want to access uh the sales application uh the sales salesforce application and you can put on your hat as being a sales administrator uh using same authentication and you can for example create a new account or a new opportunity and so on but I'm also a product manager and then I need to access uh the whole system uh I need to know uh who is buying my products uh where are their issues and so on things that I cannot do as a sales so I can just easily switch from persona stay on the same application uh and then get different access rights towards that CRM system giving me more information or at least the information that I need and as a um as a as a product manager I can see everything but I cannot for example create an account uh or adapt an account which is not uh related to me as a salesperson okay I guess hopefully that answers the question um we have one more question it's more focused on trust builder so it starts at the commencing we have implemented IEM a couple of years ago but can you apply personas to any IEM system or is this exclusive to TrustBuilder I would like to say that it's exclusively TrustBuilder but we're indeed one of the few vendors that have that persona concept baked into the core of our system meaning that you do not have to develop additional stuff to to work on that uh uh to have that persona based approach I do see other systems that have a similar approach or from a user perspective that it looks like it's being persona but it's actually role-based and then it's baked into the core of the application so that means that you have to develop something within that application to get the same result as you have here and as long as you have one application that's fine especially if you own that application and you can adapt it then it's very easy to to build something or develop something that is uh that looks like the persona and the feedback concept the advantage what we bring as TrustBuilder is that we can decouple it from the application so you can have the persona concept not only for that one application that you have that you are developing but you can do it across all the applications that you have.

The good thing is even if you already have an AM system that only supports RBAC you can add TrustBuilder and use just by the persona module on top of it and match that in combination with the existing RBAC system that you have so you can benefit from those personas and from that feedback and the strength of feedback on top of your existing RBAC system. Perfect, we are receiving many more questions so I'll pick the one at the top. An external identity wants to authenticate with an external IDP and wants to use an application within your own company. How is feedback used and given access?

And the person who has asked is not interested in the delegation part or creating the identity of the personal. So feedback used to give access to external identity using an external IDP. And I'll assume that it depends if it's an open system or a closed system. For example, if you have a retail system you don't want to block access because you're talking about an external IDP. I'm thinking more like the external IDP, the federated IDP applications.

But while I'm saying this I think it's more in an employee context that he wants to ask the question where you want to give access towards a third party, a vendor or a partner that needs to access your applications. What you can do with the feedback system then is depends of course on and that's the strength. If you say anybody from that company can access that application, what you can do then is say okay I am going to create a policy and that user needs to be correctful authenticated within that third party system.

So that for example the AD of your partner and if that is correct then he has access towards that application. So you do not need to create them within your own system, just the fact that we received a successful authentication from that third party ADP or from your partner IDP that is sufficient to give him access according to that policy. Okay thanks and there's one more question. It's a start.

You mentioned both feedback and personas and this attendees organization, they don't see much value in using personas and so they're asking if feedback alone can still provide sufficient benefits without incorporating personas. Yes of course. Persona is mainly about the identity of the user and identifying who that user is. While feedback is really how are you going to access and which rules are required to access a certain application.

Persona, so the role the business role that you have is one thing but if you're not working with business role, the feedback engine can also give additional security like for example from what location is that user logging into, what's the IP address, what's the geolocation, what's the authentication method, and did he log on with the username and password or with 2FA, which type of 2FA, is it a strong 2FA or a very simple OTP. And depending on all that even what you can also add is like the session and the session timing within that policy the session and the session timing within that policy.

So you can give access and the policy could decide well you've authenticated and yes you have authenticated with 2FA but it's been two hours ago and this is a highly critical application so I'm going to limit the time that your MFA is valid until a couple of minutes maybe even to decide on that.

And that's very easy to set up within a feedback system because it's really like this based on TACMO technology where you just say create some rules and if those rules match, if the attributes on those rules match and you get the attributes from the source systems then you can give access towards these applications. Perfect, thanks. We just have five minutes left but we still have many questions to so we'll take two more questions. How can you integrate a solution like yours with Active Directory? So yeah we can work together with Active Directory.

For us Active Directory is one of the IDPs where we can get the source of information and that source of information could be of course the user information but also the different roles, technical roles that they have. So we can fetch that information at the moment that a user wants to access so we can have him authenticate on AD, get the user groups back that is linked towards that profile and then on the application decide whether he has the right technical roles to access a certain application. Okay and there's one more.

So it says in large organizations there is a risk of explosion of roles but what about the number of personas and policies? Well the policies are always linked towards the application and you will set the rules of those of accessing those applications and the attachments that is required. That's just that's just one policy. Now the personas these are linked to the business rules and you will never have as many business roles as you will need technical roles.

For example the example that I always give is if you want to have if you want to give access towards sales people towards Salesforce and that's one role that you have. So then your company starts growing and you are growing outside of your region. So you have for example a French and a Belgian salesperson and the French can only see the French opportunities, the Belgian only the Belgian ones. So you need to create two roles already for those two different persons.

Then there could be a rule but which is whether you want to have if you log on outside of the company you have to use 2FA inside of the company. You can just use your AD password. So that's again a new rule that you need to to create whether you're inside the company or if you're allowed to log on outside the company. So for those two persons it's all already four roles. If you want to add additional rights and rules and so on you see that it explodes very quickly towards that could be the example for parole. Okay I think we have still two minutes so one more question.

This concept was born in your last release. It says version 11 but have you implemented this before that? Sorry have I been here for what? The question is slightly unclear. It says the concept was born in your last release. Did you implement this concept before that? Yeah so indeed the persona concept and the policy-based access is available since version 11 which was released last year, a year and a half ago. Before that we were an ABAC system. ABAC system allowing those attributes and so on to work also with those policies of course but then those policies were more difficult.

The persona concept that was and that is really the new thing because now we can combine all these attributes onto a user profile and add that profile towards as a rule within the policy-based access. Okay thank you so much. Hopefully yes. So thank you Kev so much for your time today and presentation and also thank you for attending and ask questions. As mentioned earlier the recording and the slides will be made available later so please check later for the slides and the recording. Thank you again and have a nice day. Thank you.