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 Trust Builder. I am Na Dede Research, Analyst Analyst at Cooking Role, and today I'm joined by Kurt, product Manager at Trust Builder. In today's webinar, we'll go through the traditional and the current architecture of policy-based access controls, the benefits of policy-based access controls from security and business point of view, also concept of personas and delegation of rights using self service from a trust builders point of view. Before we begin, we have some instruction for today's webinar. First is audio control. You all are centrally muted and we are controlling it from here so you don't need to mute or unmute yourself. Next is poll. As always, we wanna keep these webinars interactive, so we'll be running few polls during the webinar and discussing the results in the final q a session. So I would encourage everyone to take part in this poll and select your answers. Next is the question and answers. What's the end of the webinar? We'll have a dedicated q a session, but you can enter your question at any time using the C and control panel and we'll address as many questions as possible in our in the given time. Finally, the recording and the slides. We are recording this webinar and the recording in the slides will be made available in the coming days.
So first, we'll 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 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 phone and I would encourage everyone again to answer questions. The question is, how many, 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? Then we give everyone around 15 to 20 seconds answer the question. Thank you everyone. Thank you for your answers. I look forward to see the results in the final session. So stay tuned. And I would like to begin first with support of your policy based access control and what it allows us. So policy based access control is, is the 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 grain access controls. It can be based on context or attributes. It's also allows ease of integration into 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 a policy decision point which makes the DEC decision if the user should have access or not. Next, we have the enforcement point. This one is located near the resource of 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 what are the, there are five key components. First is subject is the user identity that is requesting access. Next, we have object, it's asset or resource that is being accessed or that is being request to access. Third, we have the action that is should the user get the access or not? So the task carried out in this context. Final fourth is the context. So there should be additional information provided for making decisions based on the attributes and all of these falls under policies. So the policies needs to be well defined and so this can help in processing or granting access.
So we just take a, has just seen the traditional architecture of evac, but what, what's the current state of policy based access control and what is the future of policies in im, let's first take a look at the current Norman. That is the cloud native policy based architecture. Similarly through traditional architecture, you have user existing access to a resource component, but there is an API and it could be a service mesh type of situation that sends a G S O N query to open policy agent. Now you, you can see there is a policy store and a data store. That 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'll be everywhere. They're in identity management, they're in access management, they're also in other domains such as firewall and even even in our normal day-to-day activities. And policies are defined by four components, which we just discussed. This subject, which is, is requesting access action is the if the user should have access or not. Then we have the object which is the asset on the context, which is it could be the location of the user or any other attributes. And what this does is that policies allows us for better roles and lesser recertification. You know, you can derive rules and entitlements from policies and this will help in recertifying policies. Instead of manually recertifying rules, it also allows automating static entitlements. Then we have authentication. We are already using r p authentication in using policies for risk based and authentication. Then we have dynamic authorization enforcing policy based access management with current term decision authorization can be achieved by a policy. And finally, policies helping enforcing zero trust. If you look at the NI zero trust diagram policies that are at the core of the diagram and core of the architecture and via there, there're therefore a reason that is continuous verification based on policies.
Now what, what can we achieve via policies? And there are triple of benefits. So we have classified them in business and security benefits. First. On the left side we can see the business benefits and she can achieve via feedback. First is regulatory compliance feedback and policies. That helps us in meeting the evolving requirements. Next is automated access decisions. You can automate provisioning and provisioning by policies and this can help in saving time and manual effort as well. That is for auditing and reporting purposes. Feedback track all the changes with access requests and log them. It can be used for auditing. Both is reducing over provisioning only Those who require access will be given based on policies. Thus you will save costs on over provisioning. And on the right side it can see the security benefits. First is renew access control. E bank allows fine grain definition of policies as implementation.
This fine grain definition is ontech space attribute based. Next is using attack surface if you can only if policies can help us in providing access to only those who require, we can mitigate arising unauthorized access. Third is we're 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 real time based on any changes in the attributes and any other external factors, however are, this brings us to see how policy can be used to simplify identity management with identity centric personas. And for that you meet personas. We work with policy-based access management. And to make this work you need four components. First is postpones. You need to identify the key persons, define the attributes and assign unique identifiers if profile can have multiple postpones. So it's important to assign unique identifiers to between different personas.
Next year is policy mapping. Map the personas to the existing policies. We should do this via carefully reviewing the current existing policies. Then you, the policy enforcement engine. This is the one which will decide, evaluate the policies and make access decisions based on the information about each persona. So this is, this is where the context information comes in place and helps in making the decisions. And finally we have monitoring, review and update of policies. We should regular review access logs and update policies to meet the demands of the changes in personal attributes. That brings us to now second poll. And what you want to ask her right now is, is delegation of rights using self-service available in your organization? Is it a yes, B? No. Again, we'll give you question 20 seconds to answer this question. Oh, I think that's it. Thank you everyone for your answers. We'll again, discuss this results in the final session. That brings us now to Kurt part fine. Good. Are you here?
Thank you for for the introduction of the presentation. So my name is, I'm a VP product marketing of at at Trust builder. And I'm gonna explain one of the thi things that we do is how to simplify identity management with PE as well as bebe. But maybe I'll first start a bit about trust builder. Trust builder, it's a European company. Oops, it's a European company. And we started the solution, which was already discovered by he Decar in 1673. I think. Therefore I am so trust builder. We're a European company. We're based in France, Belgium, Dan, as well as in Italy and in in Spain. And we have, we are a company, we, we with about a hundred 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, and customer applications.
And how do we do this? We, we did an investigation based on a survey, the 300 CIOs of, of large customer focused organizations within Europe. And we discovered that we could categorize them in five stages regarding the, their IM strategy. At first starts, there was a big category all having issues with co 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 Im, how can we connect all those different systems Once that was done, they want to give more convenience towards their users and, and give them a better customer experience by adding Passwordless authentication, single sign on, multifactor authentication and, and what have you. Next stage that we can find a lot of companies being there is, 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. And especially in the, in the consumer facing markets, we noticed that people or or our customers are expanding their traditional services with new services and and are starting to create ecosystems or becoming a part of an ecosystem to offer those services through 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 the end goal for those customers is to find new ways of finding revenue. Also on the, on the model that they, 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 finally intention is that they go to a cloud-based SaaS solution. All these things and all that vision that is where trust can help you with. And we do that on a couple of use cases that we support and basically we try to support the complete digital journey of 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 trust builder offer offers without having to do it Tableau, Raza 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, on PEs. To give you an intro about this and how this work, I will give you a couple of examples based on AEC systems and where they will fill, I do not want to diminish the value of AEC systems. They're 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 the more complex business environments, AEC systems don't have that required flexibility. So maybe a first example of that complex complexity is a is a telco organization. So within a telco organization you have different types of roles or or business roles for, 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 type of parcel 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 ae can be for example a shop manager, but he can be an independent shop manager. So he is 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 that makes it difficult cause 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 he is, if he is the 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, he's not in the HR system themselves, so they need to set up a second HR system or 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 the username and passwords. And if you would like to secure those accounts with, for example, strong authentication, then it becomes even more difficult to to secure all those excesses with one authenticator towards those different applications. The second pain point of arbe is that, is is what is commonly known known as role explosion. And we have here an example where simple example of of a company, an insurance company in this case where you have a couple of roles applications that, that the employees need to access like the fire insurance, the the, the life care insurance, the car insurance.
You have risk managers, you have also department offices and and so on. So if you have like, like 15 of those applications spread over 20 locations, you will see that you will very easily come to 300 roles. But that's a, that's of course a very simplistic vision of of that role explosion. When I was talking to in another real life insurance customer and they, they were talking to me about having 9,000 employees and having 21,000 different roles for those 9,000 e employees. And last week even I was talking to, to another company with 40,000 employees that were complaining to me that they had 24 million entitlements to, to manage for those 40,000 employees. And so that's an on average 600 different entitlements for each employee. So that's a very complex system which is very hard to handle within Arabic system. And then the last last example of that complexity where I don't even know how to begin on, on solving this with role-based access is where you have companies working together, companies from different locations and different countries with d different regulations where people might work for a combined project or a com combined project working in the different roles that they, in different roles than that they have at their mother company like in construction or or engineering.
You have these type of of applications. So for a role-based environment that would mean that for each application you will have, you need to create a set of roles for those users and these roles need to be added to the different users across the different organizations that might not even speak the same language. And also it's an administrative administrative nightmare with a lot of security role risks if, for example, people leave or change roles or, or no longer work on that pro project, very difficult in a role-based in an ABE system to to manage. Whereas if you look at a 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 the different attributes for that for users to ac 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 is is in such a complex organization and this is where we have sometimes the confusion, when do you want to need personas and when do 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 cuz of course and me as a user, I just have this one particular role now in real life as well. Like it could be that you have multiple hats that you need to carry, 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 personas onto technical roles, technical roles or groups in, in applications, in in, in an ad for example, captured in attributes so that they can match the existing systems technical role which is available in an S A P or an 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 Jra or something, you would need to have to have technical role. But that allows you to play if you have both hats to access both systems with that one single identity. So the roles, technical roles, they reflect the technical concept context of applications with their different rights. So what is the advantage of persona? Say you have one person, you have one profile.
So each user receives just one and only one profile where you can add his 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 on there that reflects the relationship that you have with 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, within banking I can be, this person is on snit, all that personal information will be the same of course for the whole of the company has one year u i d 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 con consumer, which bank account that he has, the contract that is related to this when it starts and 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 can gonna add now a new persona, a business persona to that one within the different attributes specifically for his business. So the name of his company or the company, if there are multiple that he can access the different bank accounts that he can access and link to where, where it's that contract as well. He can even have a third persona if he wants to manage somebody else's account, it's called a caring proxy, then we can add that one as well and there we can a ask permission to get access to it, that personal or that third party account to access. So in this case the persona type is a caring proxy, the bank account involved is, is specific towards the third party in this case.
And the valid validity can be limited to a certain period of time. That, that period of time that 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, as a visitor of the university to check if you want to study there, you become a student, you go a bit 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 in two ways. First of all, it can be delegated from top to bottom. So in this case and the payroll administrator in this case will want to, will go on leave for example. And he wants one offer subordinates to, 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. Cuz of course the worst situation ever cause you know that that password will also be used for, 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, as a substitute would've ended. So how do we solve that with persona? We are going to delegate that payroll towards supporting it and we'll say, okay, this user will now be an administrator for two weeks, so you 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, if these persons are now the sales manager and, and, and the salesperson and that salesperson needs to access this CRM system, meaning that usually and a normal, a normal organization, they will need to go to it, ask it to give them access.
It needs to check with the 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 while actually it's much easier if that employee wants to access that system. He just asked the CRM administrator to get access to that system, adding that persona to his user profile, the CM 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, into the feedback system? So we have all these persona and, 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, that policy.
I will give you now some, 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, sir, a retail application for example or or when you're selling subscriptions to towards a user and that user has two different roles, business roles, customer and a and a and a business account for example. And they are both in, 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 this same username and passwords 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, who is as an email address, which will be your user id and then some some personal stuff off her. And for the personal persona, attri persona, we will give these attributes with the correct cr IDs, the email address that you need to so send their emails to for that specific subscriptions or that specific accounts. And then we can add a second professional identity towards with a different email address and a different CM ID with all the logins and so on, stay the same. Which will does also mean that if has access to your system as a, as, for example with her personal persona or, 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 on your application between the different personas without the needs of having to re-authenticate or re-log in and switch between those, between those different personas, making it a lot flexible, more flexible and much more user-friendly for your customers.
Second use case on, on the delegation, and in this case we're going to do delegation between consumers. So we have, I'm gonna 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 who has a personal account with a bank as well. Now the mother of Anne is becoming is, is becoming, is having troubles with that bank account, it's digital and, and she doesn't really understand what to do. So what Anne 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 to request access to that specific account of her mother. The advantage is on the one hand that of course credentials are not need, don't need to be shared anymore.
And secondly, you can also segregate different accounts of her mother and limited time that has access to those applications. So she already had a personal account and a professional account and now she is asking to get also the, the proxy account and she has to ask it and that goes of course out of bend towards the mother allowing her to that, that she can access those accounts and if the mother agrees to it and she will approve it and once it's approved and will also have access towards that application. This was a simple, simple example in retail because there's not that many app users involved, but the main advantage is once you're working with with partners, with partners, partners have multiple accounts that need to access your, your applications or your your resources. So what I did here was create a, an example, in this case it's a school, a lecture business that that gives courses and I've got here Paul, Paul Jones who wants to access one of these trainings that the company is giving that that third party company is giving.
So he's gonna register and he's gonna 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 per participant linked towards that user and then that user can access all those resources where he has rights to as participants. Now since Paul is also the the financial manager and he wants to train his team and he thought he course was in interesting, he will ask the company the, that 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 or the training center to become a company administrator so he can start managing his own users and then Anna will say, okay, that's fine.
I'm gonna 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 Mika in this case. So I want you to add M as a customer for for this course and then Paul or who's Rena, but Paul will ask his two roles, the company administrator and a participant and he will give, create a task for that user to also become a company per participant. So by registering that user, we will create a new user profile for MICA on the one end as well as adding a persona, being the company participant for that user in this case in the status spending.
So what in, in real life will happen is Paul will access our self-service Porwal created for that, 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 service Porwal 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 he can start there creating a new user and then adding the different personas being a finance manager and employee or whatever that he he needs her to be, to get access towards towards those trainings. And you can also set other things like end the scope of which companies that Paul has access to, the sub the the department is 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 the notification will be sent form in this case of an email towards Mika who will then activate her user profile. So by doing all this, you have no 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 as well.
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 Im Thank you so much. Thank you Kurt for your presentation. It was quite insightful and as you know we'll take a look at some of the results from the poll, which we take to 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 identities to organization, almost 80% has said it's role-based access controls and it's 0% for policy-based access controls. So what, what do you think of this, this result?
It's, I think it's normal especially cuz major, all the major EM systems are working role based still and, and yeah, the difficulty lies in indeed how how are we going to go from, from those role-based systems and can we manage all those different attributes, sorry, all those different 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 cause a lot of development and, and additional resources to, to manage that which is not like in the core of that system.
Perfect, thanks. Thanks Kurt. I think we can also take a look at the answers from the result from second poll, we'll just bring that up. Is delegation of rights using sales service available in your organization and half of the audience have mentioned no, but there is some still that we have said yes and partially so this is what aligns with what you have also seen in the market. I think that's that's indeed, yeah. Not everybody does it. It's, it's good that some are doing it partially already 22%. So one out of five do have it. It's, it's very important to, to get this in in most organizations I think especially in the larger organizations that we noticed that there is a big risk when people are from partners are moving or leaving their organization. If that's not done through self service, it's usually done through internal IT people who know way too late that those people are moving and so on. So it's important that that that you look at that delegation of of self-service availabilities. Yeah. Okay, thanks. I think, okay, so we have a few questions already. I'll start with the first one.
So there are, there's a comment any question as well. So it says there used to be philosophical or almost religious battle between Abbe and RBAC and now it seems Abbe is the new religion isn't correct to say that either of these three can be used depending on the situation and, and we just saw the results right now. So it kind of think similar to what we're saying in the question. Yeah, it's religion has its own truth, it's nice to have philosophical thing in there as well. It's, it depends on the use case you're trying to solve. Of course it's not that feedback is is like the holy grail of, of everything, especially in in, in the easier use cases then APEC system will definitely be be good.
I'd be be interesting because it's, it's clear and it's, I it's easy to manage. It's, it's also linked towards the application. So especially in those cases that that's where a bank definitely will help. It's when when, when you come in more complex business situations that feedback can add on to our ABE and it's even best to to mix them all together or to have them both Abe, Abe and so on ab Yeah, I forgot to tell tell about Abbe. There's also really interesting about Abbe is the flexibility that you get from that. The flexibility that, that you can literally use any type of attribute and decide whatever, however that you want to do that, access that application based on the attributes that you have. We've seen systems even where account numbers and, and all kinds of different information are being used as attributes to decide whether a user can access a certain resource or not.
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 you can still take all the different attributes in there as well. So, and, and on top of it that it also helps you with those policies to increase the level of security and, and, and match those security requirements that you could have for different types of applications. Ok. 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, 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. It, it all depends on, on, on the business role that you have and, and I always that that's the one thing about about the soon as it really matches your real life situation. Me, myself, I've always had a couple of 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 or or doing both at the same time or during the same period of time at least. And then persona is really interesting because then for example, if you want to add, if you want to access the sales application, the sales Salesforce application and you can put on your hat as being a sales administrator using same authentication and you can for example create a new accounter or new opportunity and so on.
But I'm also a product manager and then I need to access the whole system. I need to know who is buying my products, where are there 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 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, as a, as a product manager, I can see everything but I cannot for example create an account or, or adapt an account which is not related to me as a salesperson.
Okay. I guess hopefully that answers the question. We have one more question. It's more focused on Trust Builder. So it's starts saying we have implemented I am a couple of years ago, but can you apply personas to any IM system or is this exclusive to Trust Builder? I would like to say that it's exclusive to Trust Builder, but we're indeed one of the, the few vendors that have that persona con concept that baked into the core of our system. Meaning that you do not have to develop additional stuff to, to work on that I to 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 that, that looks like the, the persona and the feedback concept. The advantage, what we bring as trust builder 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. Good thing is even if you are already have an AM system that only supports a a, you can add trust builder and and use, just buy the persona module on top of it and match that in combination with the existing AEC system that you have so you can benefit from those personas and from that pbac and the strength of feedback on top of your existing a a 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 I D P 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 or the personnel. So feedback you be used to give access to external R using IDP and I'll, I'll assume that it's 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 cause you're talking about an external I D P.
Yeah, yeah. I'm thinking more like the external id, the federated I d P applications, but while I'm, 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 wants to, needs to access your applications. What you can do with the PBAC system then is depends of course on, and, and that's a bit 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 correct full authenticated within that third party system so that for example, the ad of, 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 he, that we received a successful authentication from that third party, a d p or from your partner i d P, that is sufficient to give him access according to that policy.
Okay, thanks. And one more question. It's, it's starts you mentioned both ebe and personas and this attendees organization, they don't see much value in using personas and so they're asking if EBE alone can still provide sufficient benefits without incorporating personas? Ah, yes, of course, of course. Persona is is mainly about the, the identity of the user and and identifying who that user is. While feedback is really how are you going to access which rules are required to access a certain application persona. So, so the role, the business rule that you have is one thing, but if you, you're not working with business rule, 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 that you log on with the username and password or with the two fa, which type of two f a, is it a strong two FFA or a a very simple o tp.
And depending on all that, even what you could also add is, is like the, 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 for with two f a, but it's been two hours ago and this is a highly critical application, so I'm gonna limit the time that your M F A is is valid until a couple of minutes maybe even to decide on that. And that's very easy to, to set up within a, within a BBA system because it, it's, it's really like based on tur mode 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 go. So we'll take two more questions. How can, it's more related to towards Citrus Builder is how can you integrate a solution like yours with active directory?
So yeah, we work, 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 then that they have. So we can fetch that information from 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, on the application decide whether he has the right technical roles to access a certain application.
Okay, there's one more. So it says in large in large organizations there is a risk of explosion of rules. Like 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, of accessing those applications. And, and the entitlements that is required is that's just one policy. Now the, the personas, these are linked to the business rules and you will never have as many business rules as you will, will need technical rules. For example, the example that I always give is if you want to have, if you want to give access towards salespeople towards Salesforce and that that's one role that you have. So then your company starts growing and you are are growing outside of, of your region. So you have, for example, a French and a Belgium salesperson and the French can only see, you know, the, the French opportunities, the Belgium only the Belgium ones.
So you need to create two roles already for those two different persons. Then there could be a, a rule which says what, whether you want to have, if if you log on outside of the of the company, you have to use two fa inside of the company, you can just use your ad password. So that's again, a new role that you need to, to create whether you are inside the company or if you're allowed to log on outside the company. So for those two persons, it's all already four rules. If you want to add additional rights and rules and so on, you see that it explodes very quickly towards that could be any type of overall.
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, have I been here for what 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, and the policy-based access is available since version 11, which was released last year or a year and a half ago. Before that we were an abex system, abex 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 that was the, and that that is really the new thing because now we can combine all these attributes onto a user profile and add that profile to as, as, as a rule within the policy based access. Thank you. Thank you so much. The question? Yeah, hopefully. So thank you Kurt, so much for your time today and presentation and also everyone thank attended and ask questions. As mentioned earlier, the recording and the slides will be made available later, so please check later for the slides in the recording. Thank you again and have a nice day. Thank you.