Good morning, good afternoon or good evening. This is Ann Mulk. I'm from KAA coal, and I'm joined by Nils. Milman the city of trust builder for this webinar on policy based access management and how a policy based access management can be a reliable foundation for your unified IAM.
Before we get into the discussion today, I would like to take you through, I like to take you through what cupping a call is and a quick introduction on, on the company cupping, a call is founded in 2004, and we are an independent international Analyst organization of Frank neutral advice, expertise, thought leadership and practical relevance. We also support companies, corporate users, indicators, as well as software manufacturers and provide them with technical and strategic advice.
There are certain areas that we specialize in information security, particularly access management, as well as governance, the GRC, as well as mostly all the areas that concern organizations with digital transformation.
There are three key pillars, or I would say business areas for copping a call. The first one being the research we provide independent vendor neutral, relevant, and independent advice on mostly all topics which are tailored to your requirements.
The market trends, there is, there are events that copy and co organizes across various geographies, including conferences, webinars, and special events targeted at leadership. Future proof approaches as well as networking opportunities. And finally, we provide advisory as well, and we try to be the best in class, just advisory partner for you offering you trend advice in the, you know, of distill transformation.
We, we just finished EIC couple of weeks back and upcoming events from coming. A call is focused on consumer identity, which is a consumer anti world event going to be hosted across USA, Europe, as well as Asia in Singapore, and also a cybersecurity leadership summit, which will be coming up in Germany and USA. We also have got GDPR readiness assessment.
Well, I think the is already out in the market, but if you think that you need to go through a proper assessment for your GDPs GDPR readiness, then you must use this tool to assess your, your preparedness and readiness. We stand today, how compliant you are with the, with the GDPR compliance, as well as here we are to some of the guidelines for the webinar. So you will be muted centrally, so you don't have to really mute or unmute yourself. The webinar is recorded and the podcast will be available tomorrow.
If somebody wants to send to it as well as there will be a Q and a session to the end of this session. And if you have any questions you can enter manually using the questions features in the go to webinar control panel, coming to the agenda for this webinar, I will talk about, you know, the, the trends in the IM market, especially, especially drive driven by the market requirements.
I will also talk about what is the policy based access management, what changes it is bringing to the market, to the technology vendors, how attribute based access control as well as role based access control are governing in the market and impacting the overall access management policies organizations in the second part, those will talk about, about the benefits and particularities of policy based access IM, and some of the capabilities that trust build is offering in the market as well. And suddenly we'll have a quick Dawn of Q and a.
So don't forget to enter questions if you have any, there we go. So we are going to having a quick, deep dive into the enterprise IM trends. So I try to, I try to highlight the enterprise IM trends here, which are obviously very different from the consumer entity and access management trends. These are very much focused on workforce based identity and access management.
The first trend as we see in the market is really the identity in the cloud.
So we, we see that more and more organizations are getting interested into moving their identity and access management in the cloud and not really managing everything on prem. There are reasons for that, obviously more and more has applications that they have adopted as well as other strategic initiatives in the organizations to move operations as well as applications in the cloud, which makes it easier for automations to manage both identity as well as access from the cloud itself.
Not only it has got several benefits associated in terms of, I would say cost as well as time to value factors, but it also gives sort of the benefits in terms of operational management, as well as skills that are required by an organization to run a complete IM infrastructure on premise. So overall we see that more and more work workforce based RD access management is moving in the cloud. There are vendors which are providing services, or I would say capabilities for example, IDAs and access manager service, which is getting traction because of this trend.
The other key trend that we see in the market is, is moving away from the traditional role-based access control model. So attributes is the new way how we roll. So I think this is very clear in the meaning that we are trying to move away from existing role-based access control model to a more dynamic, to a more relevant access control model, which is possible using various attributes, both for policy management, as well as access control.
So we'll talk about this in the details as well by other sites are predominantly focused on a comparison of role-based access control versus attribute access control, and how should organizations prepare themselves to transition from role-based access control to attribute based access control model, if they think they find Arabic model increasingly inefficient for managing access in the organization, tive and risk based decision making. I think that has been talked about a lot during last couple of years.
We think that it's really important for organizations to now start thinking in the lines of making risk based decisions instead of just compliance based decisions. So most access policies that we that design today are, are inspired or motivated by the compliance initiatives that we have from the organization, from the security policies or even the regulators.
I think it's time that we move away from that approach to build our access management access control policies, more adaptive in nature that can, that can factor in dynamic risk as well as take realtime decisions based on the risk assessment of Al activity. So OB obviously, adaptiveness building adaptiveness in your access management decisions is very important and is an increasing trend in the enterprise IM market consumerization. All of your employees, your workforce may not be consumer for you, but they are a consumer elsewhere outside organization.
And when they, when they come to work, they expect the same level of consumerization that they are habitual of today. So I think it's very important that we provide audit and access management, as well as the services, which originate from IM in a more consumerized fashion, which are easy to consume, easy to understand and more user friendly. So consumer consumerization is an increasingly important trend in the workforce. I am that engages not only the users, but also keeps the stakeholders happy and engaged in your IM program.
Behavioral analytics is another key trend.
As we see in the enterprise IM space, we have been talking about user and behavior analytics for a long time. There are certain areas, certain use cases where this makes a lot of sense, especially around privileged access behavior, for example, where you can baseline the users activities to form standard baseline and any anomalies based on actions can be detected and red flag for various reasons, as well as behavioral can help you in several other initiatives. For example, understanding the roles in an organization.
So role mining, the usage patterns, which can provide some great insights into how you should be designing roles in an organization for more efficient and optimized role with access control. But again, that's more, that's more going in the direction of, again, again, strengthening a role with country model if you choose to, or if you prefer to.
But yes, there certain use cases where behavioral a can be very important. And then I talked about privileged access behavior is, is an emerging and very relevant use case as we see in the workforce IM space today.
And finally IM for IOT is another key trend.
I think, I think some of, some of the, some of you might, some of you might argue on the fact that IM for IOT is more, is more relevant to consumer space, but I think there are a number of industry verticals where, where we are using IOT in the workspace, especially, especially healthcare, as well as telecom industries and increasingly audit access management for managing those devices in such industries is very important. And therefore, I think there are requirements for extending existing and access management controls to manage access for those ID devices in the, in the workspace as well.
So IM for IOTs also equally important for enterprise IM as it is for consumer based IM space.
I think I'm, I'm missing on one key trend as well here, which is, which is microservices based IM delivery.
I think, I think increasingly we are seeing that more and more enterprise, our enterprises are getting interested into microservices based delivery architecture, where they can, where they can deliver IM based on certain microservices, they can groups certain services as microservices and publish them to the enterprise bus, for example, for other business units, Axel parties to consume. And that is, that is again, more of an operational trend or I would say delivery IM trend, but yes, that is something which is also gaining importance and relevance in, in the enterprise IM space, right?
So we come back, we come back to today's topic, which is policy-based access control. And I think, I think when we talk about policy-based access control, we directly think about a role-based access control model because that's how, that's how we have been defining policies in organizations to manage access
Role-based access control still is a very, very strong vehicle, or I would say model for managing access today.
But for a lot of organizations, if you see managing role-based access control is getting overly very difficult to an extent that organizations really want to move away from role-based access control and are looking for other ways of managing access, which is more flexible, more scalable as well as has better visibility. So what really went wrong with the traditional role with access control model? I think the first, the first challenge which most operations today have with our back model is the lack of business and it coordination.
There is obviously lack of lack of business then text when, when the roles are designed and implemented by it. In fact enterprise roles that are designed by it, doesn't, doesn't take care of the, the business logic behind those roles.
There is, there is really a poor alignment of, of, of these roles to the business process logic. So it's very important for our nation to really go back, understand if the roles are still relevant to the business processes or the business logic that they have been designed for. Eventually the goal for IM is to support business and not to not to be, not to excise some specific access controls around roles.
The other challenge that we have with our back model is the rule coercion. And then I say rule coalition, it's really about the complexity, the aging, the bloating.
And I would say the irrelevance of rules with time. So we think we, we have all, all seen that besides the complexity in managing the rules, which can actually grow humongous in, in, in, in size, they are very difficult to, to change. They're very difficult to, to update. And some of these roles hardly ever get decommissioned. They stay in operations forever. As time goes by. These rules create access creep in the organization.
What we also call as rule bloating, these rules can grow really toxic in nature with segregation of duty conflicts and many of the policy violations around them and with no consistent role reviews happening or solidification processes, these toxic roles, or I would say access combinations, they stay in organizations forever.
In fact, if you look at some of some of the occupational frauds or internal frauds in organizations, they leverage the, they leverage this inefficiency, or I would say the, the improper design of roles or distribution of access entitlements across these roles.
Finally, a poor visibility. I think these roles provide very poor visibility across an organization in terms of understanding of responsibilities with people. They are very rigid in nature and don't offer the flexibility to modify the roles and the pace of change in today's dynamic organizations. I think if you look at the responsibilities for people, they will always change. And so the real rules should change, but these rules are very rigid. They do not com I would say reflect the dynamism in an organization.
And because of our role based access control model is, is existing across various channels. In fact, creates channels of access and authorizations.
It is very difficult to have an appropriate access governance across all these channels and in standing, what kind of, what kind of state across a role based access control model that you have quickly, I'll talk about the attributes access control model, and what's, what's really the promise that the aback offers.
So one attribute based access control model can be really dynamic in nature because it is depending on all those various context that can be evaluated and using some technologies, they can also deliver you a dynamic decision based on, based on the policies that you might want to implement. So we have got dynamic authorization management, for example, which can remind the use of certain contacts to derive, undertake dynamic decisions.
A based access control can also make you better in terms of risk awareness.
So it can help you take risk based decisions on the fly, using all those contacts associated with risk scoring, for example, and yes, AAC can also help you to centralize your access control or access management across all the various applications that you have.
In fact, if you are going to have authorization management taken out of all these applications and centralize them using an attribute based access control model, that is something ideal scenario that we talk about, but yes, there are automations who have done that, and they have seen immense benefits in terms of externalizing, their authorization management and attribute based access control can be a very effective instrument in helping you do that.
Finally, I'll come to the recommendations and how you should be making a transition from a role based access control model to an attribute based access control model, work with the business to assess the use cases that can use attributes to define access logic more effectively.
I think you don't want to go across the board in one, go instead, identify the use cases where attributes really make sense they are meaningful, and they can really define access logic effectively than it is today.
So identify those use cases and try to start building policies, using attributes for those access control use cases, don't aim at eliminating the roles entirely instead take a gradual approach that helps you to reduce the dependency on roles. If, if that means starting with a, with a mix of attribute based access control with role BIS control model, then that be it. And in fact, that should be the starting point for you on how you should be transitioning from our back model to an Ebet model. Don't forget the rules. They really make great attributes.
So if you're looking for an Abe model, make sure that you also use roles to start with because they make great attributes. Also use this opportunity to centralize the authorization management. As I talked about, there are products, and in fact, Nelson talk about some of those capabilities from trust builder, how you can use this opportunity to centralize authorization management and take that pain away from the developers of coding business logic, around authorization in individual applications,
And finally insist on AAC to be present on your access management vendors, product roadmap.
If you're using a product access management vendor, make sure that they consider EAC on their roadmap in, in upcoming few years or, or I think it's time for you to move away from, from what you are, what you're dealing with. And finally encourage attribute based access control awareness training for your developers, as well as architects, making sure that they understand the benefits of attribute access control and, and how it aligns with your, with your distal business and secure initiatives in the organization.
With that, I would like to hand it over to Nils to talk about the benefits and particularities of policy based access control, and also about trust builder bills about you.
Okay, thanks more for your introduction. And I have to say, I really liked your comparison between our back and a back and the way we should move forward. That was a great story. Thanks a lot. And it really sets the scene for my presentation.
Now, just as an introduction, my name is Neil Mermans. I'm the CEO of trust builder corporation. And I'm pretty sure that most of the people out there have no clue what trust builder corporation is about. So let me first try to introduce us shortly trust builder corporation was created as a Belgian company in 1999 as security. We had an entire focus on identity identity and access management have to admit that initially we were just an integrator and we were a partner of IBM dealing with the implementation of IBM solutions around identity and access management.
Now, what we noticed over the years is that these systems, and I'm not only focusing on I on IBM solution and I'm not fired and I'm not shooting on IBM either.
Cuz I think they have a wonderful offering in the field of identity and access management. But what we felt we saw in the, in the field is that these systems were lacking functionality on flexible, authentication and authorization. So we started developing our own extension modules for authentication authorization, allowing the solution of IBM to be more flexible in the field of, of authentication authorization.
We've been pretty well successful on this. We've been extending the functionality of the modules we provided, but after a while, we sort of ran into a problem because, because we were extending the functionality in both these areas quite a lot, and there seemed to be a bit of an overlap with the solution that IBM was providing. So last year in 2017, we decided, okay, we had to do something about it. And we decided to sort of split up the company secure.
It still exists as an independent, independent integrator of identity and X management solutions.
But by the end of last year, we started up trust builder corporation, which is entirely focusing on our own product, which we call trust builder identity hub. I'll get back into this a bit more later. I'm not trying to make this a commercial presentation that I really want to focus on the philosophy and everything we learned in, in 20 years of identity and access management that actually drove our development. Our headquarters are based in Belgium where all the development is happening.
We also have an office in Netherlands, which is basically still the old secure it office that is doing a lot of services for us. But apart from that, we present in, in several European countries and also in India in the us. But it should be clear that our focus is really on, on Europe today.
We have about 55 IM specialists on board. I think 10 to 15 are related directly to development. The other ones are related to engineering and, and consultancy. And even though we're a small company, only 55 people.
If you look at our customers, we really have close to, or even over 40 million end users on board, which are registered in our system. Now you might be wondering why I'm showing you this picture of a football stadium.
I, I know we're all pretty much convinced that Belgium is going to become world champion in football, but that's not the reason why I'm showing you this picture. It's a picture of the football stadium of Kent, which is one of the major cities in, in Belgium. And actually this is where our offices are located. So really in the corner, that's where we're sitting.
We, we can look at this guy mowing the grass, but basically we cannot look at any of the matches because the blinds are closed. So, okay. But that's, that's enough for our company. I've got here, slide on our customer base. I'm not going to dwell on this because as I said, I don't want to make it a commercial presentation, but there is at least one company that I'm sort of like proud of, which is on the left 10 top corner. You can see that the Vatican is customer of first builder corporation.
I can't tell you whether the, the Pope really has an account in our system.
And even if I would know, I would probably not be allowed to tell you, but I think that's a good reference please. Okay. Where are we coming from?
Basically, we are a traditional identity and access management vendor with a main focus on access management. We hide ourself behind the term single sign on. So you as a user, try to sign on to the applications of some organization. You get single sign on the authenticate ones. You get single sign on to all the other applications, but we should all be aware that behind single sign on there is a lot more, there, there is registration, there is authorization and all that stuff.
So even though we use the term single sign on there is more behind it now where we came from, and this is really the story of 15 years.
Be 15 years ago, we as employees, partners and customers were all trying to sign onto applications on premise, which were either hosted, which were either of the shelf of applications.
Like, like SAP might even be SharePoint, but we also might have developed our own in inhouse applications on WebSphere, J Don, get you name it. And we wanted signal, sign these applica to these applications. And we also wanted to leverage several of our internal repositories like ad for our internal users that our customers could be. But if our customer base was, was really large with lots of relational data, it would store them on data within a database. But we've been there. We all know that. So this is like history years ago.
Now what we see these days is that we are no longer addressing local application on premise applications, but we also want to address cloud based applications like Salesforce office 365, but don't forget that these are probably not the most important cloud based applications, applications, at least that we see that our customers are using are applications from partners.
So you partner with somebody, the partners hosting application, the application cannot be proxy behind your traditional access management system like we did 15 years ago. So we need some Federation support there.
We also might have private cloud environments. So what I'm addressing here on the, on, on the bottom right hand side is all kinds of applications that we can somehow integrate with Federation protocols like or, or open ID connect w Ws Federation and, and, and then to take it one step further, like we used to only authenticate users with local on-premise identities. We now allow users to identify or authenticate with cloud-based identities, potentially with a, a lower sensitivity level, but still we allow to do it.
And, and especially for marketing reasons, that could be an interesting model. We see here cloud identity providers like Facebook and Google. We all know them Facebook and a Google connect, but in the context of AI, that the initiative in Europe, where we sort of want to provide single sign on with all country based identity providers, we see authentication provider identity providers like it's me, which is Belgium initiative.
And this ID, which is a Dutch initiative popping up. And I'm sure that the more of these identity providers all over Europe, and this is really where we're focusing on.
And again here, the integration model is not rocket science, as long as you support Federation semi open ID connect or, or it's all possible. So where is the real difference? Is that in the center where we, where it's your single identity experience is that we provide a solution that ties all of these things together. And you have a policy as a customer on deciding which identity to use, to access which service provider. And that is really our focus. So this is really sort of like illustrating what our product is about.
And that's about the last thing, except for one more slide that I'm going to tell about our product from now on. I really want to focus on the policy that was behind our product.
Now, what we learned over the last 20 years, because really we've been involved in identity access management for 20 years. What we've learned is there are three aspects that are really very important, which is attribute based access control, leveraging, leveraging existing technologies and flexible user interaction. And I'm going to address these in the next few slides. So let's start with attribute based access control. And we already set that.
We started up from our back row based access control, where we assume that all users at roles and groups, and we would apply access control based on these roles and groups. True. But even 50 years ago, really believe me, even 50 years ago, when we were doing implementations of access management solutions, we were confronted with environments where roles and groups were not sufficient, and I'm not talking about the context BA based authentication, where we are using things like geolocation and IP, IP range and stuff like that.
But really we had customers who had tight attributes to applications and attributes tied to users and could only access these applications if the attributes match. And when I was preparing this presentation, I was really wondering how can I, I address this, but really it is very specific. There are no generic attributes that you can define. So if you're talking about attribute based access control, you should be extremely open on what these attributes mean. Now I've tried to summarize a few, like you might have accounts.
If you are in a banking environment, your account might be an attribute saying that you're only allowed to access the accounts you own yourself, which cannot be represented by a role or a group. Because if you ha would have 2 million customers, you would have 2 million groups, contracts you have signed and stuff like that. Those are application based attributes.
We also have identity based attributes. So your access control rules might have, might imply rules on, on your mail address.
Like, okay, you can use any social media to sign on because this is not a critical application, but we have to make sure that if you sign on with your Facebook or Google account, we can get access to your mail address. And if not, you're not allowed access.
And if, if we allow you to get access, we've got your mail address and we can now start of semi all kinds of marketing information. Date of birth applications might be protected under over 18 years, 21 years, and stuff like that, your gender might be, might have an impact on the attribute based access control. So that might be an attribute. And then if we're looking at the hype of the last years, we're talking about context based attributes.
So yes, you're allowed to access the application. If you are within a specific IP range, if you are geolocation indicates that you're closer to like 10 kilometers from your home location or business location, very popular these days is fingerprinting.
So yes, sure. You're allowed to sign on with username password, but only if you sign on from a device that we used before and other attributes could be like risk, risk scoring.
So what, what we, what we recommend here, if you, if you go for an identity and access management identity and access management solution, is that you go at least for a system that supports an aback engine, forget about our back. And ASMO set a role, makes a good attribute.
Yeah, that's true with aback, you can implement, rback no problem, but also go for a solution that has an open set of attributes. We've often been asked by customers and even Analyst, not by keeping your goal, but by other Analyst, like what attributes do you support?
It is not important. You have to provide an aback engine in which you can spec specify regular expressions that they can take into account. Any attribute, any attribute we can collect from the user signing on from his location, from the application is trying to access.
So any attribute which you think is important for your policy, it should be able to be used in your aback rules. Also make sure if you go for an aback engine that it supports integration with policy information points.
Now I I'm, I'm sure that most of the users present here are aware for of, of the RFC 2, 9 0 4, which deals with a authorization framework, which specifies the things like PDP and B and P IP and all that stuff. A P IP approach information point is, is a system that holds information about the user. You cannot hardcode information about the user in a rule.
So you should have actually a system that allows to call out to external systems when applying a regular expression to fetch information about that user. Let me give you an example.
You're in the hospital environment, you've got a patient and you say that this patient can only be treated or the patient record can only be accessed by the doctor. That's really dealing with this patient. This is not something you can store statically in a rule. This is something you have to, for which you have to apply the real data. You have to access the real data from external system. And finally, you have to make sure that if you implement an ABEX system, that they can support you with hints.
Now, this is not something again that we invented ourself. Although we're not based on the exact system we've used this model, we've sort of like borrowed this model from the system. If the user is not allowed to access any resource, for what reason ever, you should be able apart from saying yes or no, you should be able, no, but if you would have these attributes or if you would step up or would on the reach condition ever, you would actually have access to that resource. So this is really something you have to look at.
Let's go.
The next thing is, what we learned is that you have to leverage existing technologies, okay? We're a provider of an identity and access management solution, but we are distinct from many of our competitors in the sense that we do not provide all of the authentication authorization and whatever systems out of the box. The main reason is based on our experience, we know that customers already have systems on board, or they have other preferences. As far as authentications. For instance, I could, I could come up with an identity and access management system that supports out of a box.
Let's say Vasco, open span these days. But if you are arriving on a customer says, well, I've already already spent like resources to make sure that my 2 million end users have a Gemalto device or whatever, or a soft token for Gemalto or RSA. How can I deal with this?
So what I'm saying here is, okay, you might provide some solutions outta the box, but you always have to make sure that you can integrate with a, with what a customer already has available.
And that is really where our focus is, is also, and this is not only meaningful in, in the sake of authentication, where you have using a password, a one time password and integration with social media. But it's, it's also valid in the, in the area where you want to collect information about users. Like once you have AED, the user, you might want to collect extra data about the user from several repositories. We don't want have a closed system on this. You want to be able to retrieve information, made these systems, LD dev system databases, really a collection of all kinds of systems.
And then again, as far as we talk about fraud detection, use analytics after admit we don't have any solution on board.
Again, for the same reason, we believe we have to tie into the system that the customer has already selected, whether it's an in-house system or a cloud-based service.
So our recommendation in, in this case is that as far as usual authentication identification is concerned, you should go for a system that allows directory chaining, which means if you have a large range of, of ad systems or develop system or ID systems, you should be able to scan over these systems and find the user in the right repository and record data about that user. So if you, if you have like 10, a ADSS, you find the user in the fifth ad system, the next, next time you try to authenticate the user. You should remember that he's in the fifth ad system.
As, as far as integration of social media are concerned. You should go for a system that supports all the Federation standards and really all the extensions, like all IDC, several Ws Federation, but not only the basic standards, but all the variations on this. If you want to go for open system that can support any authentication mechanism, please look at things, specifications like Al and, and Fido. And if you want to tie into external systems for fraud detection and use analytics, make sure that you have a, a solution that has an open backend rest interface that is all protected.
And then finally, and this is really where I'm, I'm, I'm going to go close my, my presentation. It's all about user interaction. And this is really where we actually sort of started off with our solution.
Whenever, whenever we were talking about talking with customers about their expectations, they had expectations on user interaction because that's all they care about. They don't care about how strong your authentication mechanism is. They care about how you present it to the user, and it's all about registration, authentication and authorization.
So whenever you sign onto an environment, how are you invited to register for that application? Can you leverage an existing identity? Can you leverage a social media identity whenever you have to prove your identity? Can you do it out of band using mail as a mess or a, an application mobile application and, and it's safer authentication. Like when you authenticate, when you're trying to access an application, what are you going to present the user, like a simple username password screen?
Or are you going to present the user with an authentication catalog, showing all the options the user has to sign onto that particular application?
What, how are you going to interact with the user when you need something like re authentication, step out, step up application multi-step authentication, stuff like that.
It's, it's all about interaction with the user. Now, if you, if you go to most of the identity and access management management vendors, they will tell you, oh yeah.
If you, if you want to customize the interaction with the user, you better set up an application server to get WebSphere or whatever.net. You just make a custom implementation of that. What we say is that, no, that's not the way it works. The technology might be different, but you have to provide a framework in which you can actually allow the, the customer to design the interaction with the end user.
And, and in the sake of time, I'm just going to, to jump ahead. This is what we provide with trust builder.
We allow you to design the interaction with the end user, with a workflow engine. And this is okay. I'm not going to give you all the details on this. This is a scenario that we've implemented for one of our customers. And this is scenario that allows the user to authenticate with user password username password, when it's coming from a, a redefined device.
But if you're coming from a device that you've never registered before you go to before to authenticate with the username password, if you want to implement this with any of the solutions from the IM vendors out there, you probably probably are forced to go into customization on any application platform. We from with our product, we provide a framework in which you can graphically design the interaction with the end user. And of course under the coverage, you might want to integrate with some APIs, but the in general, the overall is really it's visualized.
So have no clue how the is working, can actually use this interface.
I'm going to summarize now with the last slide. So conclusion, you have to go for a system. You have to realize that IM requirements are in constant motion because of the mergers and acquisitions and restructuring. You can come up with a policy of interaction with the user user today, as far as authentication registrations concerned, but you have to realize that this could change in half year or a year from now.
You have, you might have new new insights. There is new technology popping up. So even if a vendor is promising you, that he will deliver everything out box, like all the authentication mechanisms and fraud detection systems and user behavior analytics systems, you might be sure that one day a third party vendor is popping up with even a more interesting solution. So you have to be sure that you are always able to interact with other technologies.
That's really what the next next topic is about.
When a vendor provides you with a solution, don't adapt to the technology the vendor is providing because it might only cover 80% of your requirements go for a vendor that is able to tie into your requirements that can adopt to your requirements. And finally, it's policy, policy, and policy. There is policy around registration, authentication, authorization, and access requests.
Make sure you go for a solution that without too much customization is able to tie into your policies to that can align with your policies in a way that you can understand that you don't need customization and mechanisms mechanism that allow you to adapt to your new policies if they're here. And that is really what I want to end this session with. If there's any questions, please fire back to you and more,
Thank you, ELs. Right. So I think I have a couple questions here.
The first one I have is how can trust builder manage attributes across multiple channels are devices that people use to access applications?
Okay. I see.
Well, a as I said before, we've, we've got an aback engine on board that can deal with all kinds of, of, of attributes and where the source of the attributes is. Doesn't really matter to us. What we do provide out of the box is the, the browser channel where we provide some. And let me clear about it, little bit clear about it. We provide some Java script code eLog page that collects a lot of data off parameters of your device and your browser.
But if you have like an native application running on a mobile platform, if you want to use any third party as to collect attributes, that's first as fine as well. Because in the end, the only thing we do is when you register device, we save a hash of the data. And once you come again with that device, we just compare the hash. So we don't provide the hashing functionality ourselves or the, the, the attribute collection ourselves, but we can work with any solution out there.
Perfect. Thanks. I have also had a question.
What is your experience with customers asking for fine grained authorization based on a, we want traditional IM and cm in one solution. What aspects should we look at from making a decision?
Okay, well, we, we, we, as I mentioned before, we do have an aback engine on board and we do expose all the functionality of the aback system externally. Like you can use it to make fine grain authorization decisions. We ourselves don't really promote that. Not that not that that we're against it, but it's not part of our product strategy. There's other companies out there that actually really are in that field companies like axiomatic and, and so on.
But what we see is that most of our customers use that not really for fine grained access control, but for course, course grain access control to the applications. Can, can you really provide the attributes to access the application? But once you have accessed the application, we don't really care anymore. All the fine grain decisions are taken within the application. And of course, lately in the context of, of context based authentication, where you have to make decision based on IP, arranges, your location, all that stuff. Yeah.
We see customers having a requirement for, for Abe, but not really for fine grain access control. No, no.
Right. And I would like to add to Neil's answer here, the right approach for you to, to really, to really combine traditional IAM and cm in one solution, which also helps you to manage access using fine grain authorization would be, would be to maximize your authorization management logic. There are solutions out in the market which can help you to really manage or externalize various authorization controls using Zall and, and other dynamic authorization mechanisms.
The policies that you can define within these tools can help you to, to evaluate the decision based on, based on the, the resource requirements for that particular application. So for example, the application a which is, which is a high risk application, and for that, you really need to have a very fine grained, authorization, defined policies where you like to have various authorizations based on, you know, asset based on resource types, based on obligation requirements like privacy management, et cetera.
And there are several other attributes that can be used to determine that policy.
So for those highest applications, you might want to use various attributes using the, using the logic that you have really code for the Zal policy for, for the application. As I said, you know, there are, there are various vendors and technologies over in the market that can help you to integrate with applications, to provide you fine grain authorization at, at both administrative static, as well as runtime level. So that might be an approach for you to, to go ahead and segregate authorization logic based on the risk of the applications.
I think
What, what I would like to add to that is that yeah, you're referring to, and really was the basis for fine, great authorization, but it's been around for like 10 years and it really never picked up. So really be careful find great authorization is yeah. Something you might have require requirement for. But if you go for a solution, really trying to find a solution that finds some sort of an abstraction layer towards the second specification, because second itself is, is too heavy, too slow to cumbersome. That's my opinion.
Sorry,
That, that, that's a good, that's, that's a good point that you have brought. Thank we don't see any for the questions here. So last call for any, any questions. All right. I think then with that, we like to end this session and thank you for attendance. As we said, the podcast will be available for you to listen again. And once again, thank you for joining me and Neil, have a good day. Bye.
