Webinar Recording

The Evolution of Access Control

Name: The Evolution of Access Control
Uploaded: 2021-01-27T12:00:00+01:00
Duration: 57 min 29 s

Posted on Jan 27, 2021

The purpose of an identity management system is to support access control to an organization’s sensitive systems and protected resources. Contemporary access control has progressed from static entitlements, still used in many organisations. Not only manual interventions are necessary to change roles, also provisioning, reconciliation, recertification and auditing are laborious tasks, which complicate each business process.

Webinar presentation, KuppingerCole

Webinar presentation, Syntlogo

Lead Sponsors

Video Description

Show Transcript

Good morning if you're in the Americas. Good afternoon, if you're in Europe. Good evening, if you're in the Asia Pacific. My name is Graham Williamson. And in this webinar, we are going to be talking about access control, specifically the evolution of access control. I have with me Dr. Giovanni Baruzzi from Syntlogo who's going to explain about the token based access control methodology. Syntlogo is a member of the Login Alliance. And I would just like to mention that the Login Alliance is very keen on having additional partners.

If you're interested in being a partner of the Login Alliance, please contact contact Dr. Baruzzi after the webinar. Now we have one slide here on KuppingerCole events coming up. Just take a couple of minutes to tell you about that. The events are called the KC live events, and you'll see coming up on your screen, the events particularly February the third, don't miss this. This is really digging in to what decentralized identity is all about. A very important topic for us today, then on the 17th, I'm making zero trust to reality.

And in beginning of March identity fabrics, another important topic, not to miss you're muted. It sounds not possible with this number of attendees to have audio availability, but the slides are being the whole presentation is being recorded and the slides are going to be available to the email you use to register for the webinar. You will be sent a link, most importantly questions and answers. Okay.

Do, as we go enter your questions in the question box on your control panel, in your go to webinar control panel, and we will at the end, get to those questions and answer those that we can and get back to you electronically for those that we don't get to. So do answer your questions because that's a very important component. Number one, it makes sure that we do address the issues that you're interested in. And number two, it gives us some feedback to make sure that we are indeed connecting with the, with our audience.

I'm going to start with an introduction to access control, bringing us up to speed, to a common level of, of what we mean when we say authentication or authorization. And then Dr. Baruzzi is going to take over and explain the token based access control methodology. And then we'll move into our question and answer session.

Okay, very briefly. The whole point of doing identity and access management is to make sure that we can control access to our protected resources. We don't need access control. We don't need identity and access management. So the focus to this webinar is on access control. I've mentioned governance there because you need to make sure that we, whenever we, we, we deploy an IAM environment that we have the governance we need, that we have done the monitoring that we need to do.

And also in the access control space, we need to know who is accessing resources, who is being given entitlement to access those resources. So governance is a very important component of our identity and access management and our access control environment, identity fabric. For some time now KuppingerCole has been discussing, developing this concept of an identity fabric. And this is in response to the realization that increasingly now enterprises call on their identity information to support the whole organization.

So we need to make sure that we take a unified approach to our identity and access management to make sure that we're not doing one thing in marketing. Another thing in manufacturing, another thing in the administrative side of our enterprises, we need a unified approach. We need to keep in mind that we're talking about a concept and apparent in here a whole new paradigm shift. In some cases we're not specifically talking about identity and access management tool. Increasingly we've got support API APIs and microservices.

Now, as we increasingly move into the cloud environment, we need to make sure that our, the software that we deploy is segmented into its component parts and that those segments can talk to each other. So the components need to have APIs that we can develop a monitor. We need to make sure we have comprehensive capabilities just as an illustration of how important our identity information is. A few years ago, I worked on a project for a chemical company. The chemical company in one area made explosives.

They were used by the mining industry, and we had a mining client who wanted to get access to the information that was in the system about their contractors and their staff who had completed training on the explosives information. What, at that point in time, they, the, the mining company wasn't able to take advantage of that information. Now there's no need for that to happen anymore. We have the ability now to make sure that we, our identity fabrics supports all of the capabilities that we needed to support.

And when we get to token based access control, that's, that's an important component to that. Lastly, need to make sure that we understand the use cases that we have within our organization. We can't put in a comprehensive solution unless we understand the various use cases.

So we, we, we need to take a corporate wide view of our identity requirements. Dr. Baruzzi is going to give you a much more detailed journey for the access control development, but I just wanted to mention at a high level where we've come from. Okay. So those of you, my age, remember when network authentication was all we had, if we could get into the corporate facilities and we could log onto a corporate PC, we could access the corporate resources within the organization.

That of course wasn't good enough for some applications and some systems, particularly financial management systems said, look, we need to segment it more than that. We need to know who is the accounts payable clock. We need to know who the financial manager is, and we will give them different levels of access. And so still today, there are financial management systems that maintain their own database of users to give that more fine-grained authorization. Okay. Not just authentication. We have to be authorized to specific facilities within the application.

We moved on to role based access control, and still, I would say most organizations are in this space, the most common level of role-based access control, a group memberships used within ID or within another directory environment. So that if a user is in, within a particular group, they get access to the resources that that group has access to. One of the problems with that is the mess is controlled very closely.

We can have a role explosion, a situation where we have in some cases, more roles and users we've recently over the last 5, 5, 10 years have moved into the attribute based access control. By what we do now is re remove the control logic from the application itself. And we rely on a, an external authentication authorization service that's providing real time access based on policies. We can now establish policies across the organization to control the access to our protected resources. In this webinar.

We're talking now about token based growth preservation and how we can take that to the next step and deploy a simple and secure authorization environment. Okay. This is on the screen, a typical type of authorization, caterpillar, where we have a user accessing an application, the resource, it provides an authorization token to the user that's venues to buy the authorization server, to provide an access token that defines the access that the is required to the resource. And then that access token is used to pull the user to get access to the access that they require. What we're talking in.

The token based authorization data flow is something that's quite a bit more simple. We have an application, we have a user registry and user registry controls. The w the role that a user will have within a particular application. And that will allow the resource to the server, the resource to be provided to the user. The user will get the level of access that they require for the role that they're actually providing.

Now, there's three takeaways that I hope will come through the webinar today. The first is that we're talking a simple authorization mechanism with the teabag, simplifies the granting of access at a fine grain level to the resource requirement.

Secondly, it's a very agile solution. So the big advantage here is that we can support diverse requirements. As we look at what is required within our organization, we, we can make sure that the identity fabric supports the corporate requirements that come from the various groups within the organization that need to get access to identity information. So we can support a diverse applications. It's not just applications, it's access to restricted data, so on and so forth. And thirdly, it's secure because it uses a claims-based technology.

We can make sure that those claims are signed, and we can verify, verify that signature and make sure that we have, we remove any capability of a hacking environment. And now Giovanni is going to be going into some more detail on that within this presentation.

So like, finally, I'd just like to emphasize that number one, we need to design our identity and access management environment to support those, the access control that we require. We have to go through that design phase. I recommend we have a solution architecture approach to that.

Secondly, we need to implement the, the system and that remark requires us to properly test and deploy it. And so, as we do that implementation, that test program is exceedingly, excuse me, saving the important. And lastly, we now need to make sure we empower. So we put the governance around the access control and requirements that we have there.

And, and, and part of that will be the security that we put around that. So with that brief introduction, I would now like to turn over to, do you have any to explain to us a token based access control, Thank you to everybody. I hope that you hear me and you can see my panel. We are talking about the evolution of access control. My name is Giovanni Baruzzi and I'm general manager of central role. Syntlogo is member of a Login Alliance, a few German companies specialize in the area of identity access control.

We cover different areas like consulting, architecture projects, software development compliance, and we do projects. Graham said before, we will be pleased to whoever requirements and inquiry from other companies all over the world, because we want to let go this Alliance. So we are going to have a very, very look about the evolution of fiscal control. I'm going to be slightly more tactical than Graham. Graham did a very fine work introduced at that high level to be able to explain what is the talking Bezar access control. I need to be a little bit more tactical.

I hope that these four simple too, and that's understandable for everybody. So the first slide is time AXA depicting the evolution of a few mice on during this evolution for access control. The first success, always in the seventies as a trust system, we're able to share that resource among the many users and the administrator at the time had the day idea to have a, a Lista access control is well, they simply listed the user that they could have access over the last 40 years or the app, actually 50 years, there was two forces driving devolution. One is the need to keep the thing manageable.

And the other side, the increasing complexity needed the development, the technology and automatic process and keep all this information secure. So over the years, we saw a lot of technology in this reaction, not only the air back in the 92, the force, IAM system in 2003 and following year a year. And now we have the cloud computer cloud computing, of course not access control, but it's an event. We let the mix the cards again, and we need something better.

We are going to face million of user and possibly the technology developed for the big enterprises are not yet fit for this huge amount of users. We need reliable, stable and scalable technology. We think that we did talk embezzle tokenization. We have a solution, a technique that may answer many questions this area. Okay. So we come back to the beginning. We have a short loop about the evolution, because then is clear on what, in which direction we are moving. We are back in the 70 years and we have a beautiful system having one application, two user.

And then let me say, to put the information which uses this accessing information in the user registry, use it registered as a general name can be a file, can be a database, can be whatever you have to manage it. At that time, the Dumbo of it system grew considerably. And after a few months, you have another nice application, possibly develop it, a completely different platform.

And again, you have a place where you store your user. And again, again, you have a third application.

And well, at that time at the work of that means that it becomes really demanding. Every system requires password, user ID, different security, and you need administrator. Their work is nearly unbearable. At the end of the, we are in the year 2000. Somebody got the idea how well we can centralize all these. We have a sun central identity and access management solution. We put the user there and we share, we granted exercise there centrally and department is that once you have the centralized grant, you have then to these would this information to application.

And this is the time of provisioning. And you know, is the experience of everybody who has really to do with provisioning is a daunting task because all the technology of the application are all different. Sometime you find active directory. Sometime you find a database. Sometime you find a legacy solution and is demanding. And just to make sure that the information arrived correctly, you have to add another process called reconciliation. Yeah. And as everybody knows in this field, such a complexity will never be free of problems.

So we make short slide about the issue that we have today with a problem with the scalability, possibility the solution developed for the enterprise enough to perfectly fit to the large number of, of the waving internet thinker, consumer governmental agencies. And we have been making benchmarking some enterprise solution. Our work in Bedwell until a hundred thousand users above data, they begin to sign sign of fatigue. Then we have a provisioning. You have to provision the, the information to the application and over the cloud is another layer of complexity.

So Aviva is already complex on internet, on trusted network. Jesse mentioned the additional complexity of DPN new protocols to purview over internet or to another data center. My idea to choose an a case. There was a verified data center. You have to go there, you have a bridge to get. There is not simple. It's not that it's doable, of course, but it's another problem. And then the security model as Graham cited before today, we have some time, a very, very simple model to typically our assessment, either a group. Yeah. A list of user.

And sometime as you say this reality, we have more groups and actually users. So we need the, what is coming slowly in the technology. We need fine-grained capability to control the access. So put it all together. I think the time is why for new technologies. And I may remember Leah that completely on call will start at the Paul on your left and kindly ask the, to feel DePaul, because you impression you question are very important for us. Please tell me when I should go forward. Okay. Okay. So still content Palmer. Yes. So do you know that token base access control?

Actually, we already knew token think to a simple credit card is a brilliant idea. The shop owner doesn't know you. It's not waiting to give you goods if you're not paying immediately. But if you show him the token, that credit card, he understand it faster, the issue of the credit card and gives you the goods that you want. And the credit card is a good example. You have some information, the owner, and some liability indication and everything. And another example of a token and digital token this time is the new boarding pass. Yeah. Everybody flies today.

Well, we are stopped at the moment, but I think in one year we're going start to fly again. You will have the boarding pass on your mobile phone. And the pass is now a QR code.

Of course, a digital object. You showed these digital objects to the employee of the airport. The employee checks this digitally. And if the check is good, it's positive, you're allowed to board the plane. So it's fairly, very nice technology. And the idea is it would be very nice if we can use this technology for our application. So meaning I have a digital object. I showed this object to the application and the application grants me access to my information. Yes. And this was the both of, at the idea, of course, an idea cannot be implemented in five seconds.

You have to start thinking, what are the security policy of your application? And so the application have to define the roles as to load the holes in that identity muni system. We don't want to replace completely their identity management system. We want to implement this and said, of course, the application architecture who is going to define their goals, possibly even find granola characteristic parameters that may make the, the control more fine.

Now let's say if you're having access for cost on cost center, responsible, you may add as a parameter, they ID of the cost center of ID in the explosion of the number of groups will be politic to all the cost center possible. This information is been loaded in the identity management system, and it's confirmed. Now we go to the second phase, the user needs to use an application. He ways he pays for that. We are not going to discuss in detail how they access will be granted.

We, we be approved. We know that our fantastic team, a system to do this somehow automatic, automatically, somehow wall flow based some manual. It's not the topic of our discussion today. We take four down and yes, it is again, the same. The user apply for the use of an application, which was the identity manager system checks and provides the for that. And at this time, the very important point, these information is being stored in the local user registry and digital sign it by Delta witty, which is granting the access manager. This is a small detail.

We're going to see later, how important is this? Okay. Yeah. This is a small example, how this is implemented. What do you see on your left on your whiter is a Jason object, Venus standard journal bags. And this has advantages. Libraries posts as a general being available everywhere in this object, we inserted all needed information to understand what is this access wide?

So the entity or the user ID who granted the access, they use style to stop data option on tomato pomade indicating the trust level and a D enter the digital signature to of the granting out targeted and people that knows that technology recognize this simply a jiver token, and he's already an Atlantic. We don't need to reinvent the wheel. We use available technology for available technology. Yes. Now we are in the use of it. On one day, the user makes login to the application, wants to get some information.

The application doesn't know him as no information about him, but a max login over a standards. As soon as on your protocol, which can be Samara or the connector and these pothole use claims. Now we are going to see what happens. The user try to access the application. Our number one and application recognize that the user is not yet logged in, redirecting it to the single sign-on the user authenticate it. Come back to the application. The application receive the claims of the user. We know this is a back channel, but this detailed technical teacher has all the information about the user.

We may call this even just in time. Provisioning is equivalent passes. This information, normally in an application, you have a so called user context. Composite application has everything in control and delivers the application. After the core, the application, after the session can forget every information about the user and being cleaned and agnostic.

Again, let's come back to the slide that we saw before that complex convoluted slide that we saw with the provisioning user graduates. We wait continuation and so on. Think we place this provision in an ecosystem by adjusting time session. And a mechanism are already present in open IDC connect and Sama, the claims and all these is not needed.

You see, we have a patentable simplification in that without losing nothing in functionality and possibly add in some capability like the capability you have additional Trimble or indication of the authentication straining that first level. Yeah, we said that the are not needed anymore. They all can be used seconds after being granted because the data is there and you don't need to wait at the next day or few hours to get a wait for the provisioning. We may use this over the cloud.

So you are, if you are accessing connected application over the cloud, you don't need to prove your data. You just go there with a standard protocol of single sign-on. You get everything. And even is GDPR compliant. Because if I use a goal as a way, you don't have need the need to go to every application and delete the data of this user. There is simply no data for this user.

Of course, there are complex scenario where you need customer data, but it's another matter we try our basis to simplify the things that can be simple. Yeah, no provision nano conciliation. And I'm working always with the mind of compliance and Garvin answer where certification is just a report on you, local user agency. And we try to put all needed information just in this token. Yeah. Outlook.

We have two very interesting message to give there, but first best search is a short loop back to what happened at the beginning of December and of November with a SolarWind case, a title case, the colleagues in USAA, I'm not yet completely sure of what damage has been done. And basically this was possible because they were able to steer the private key of the single sign on having a private view of the single sign-on. They may forge session two application introducing themselves as a privilege user. Okay. This was the basic, very simplified basic of this attack.

And unfortunately they didn't knew, and they didn't set in the base out of recession because now the small difference that I noticed with you before that the entity sickening the talk and for that notarization is a different one from the entity signing the authentication. So the single sign-on is one history. The token for the organization is completely other different SOE. You may say I'm the autonomous right of this application. But if the application checks you a token of the concession discover that something is not okay, remember that in target itself is within the ID of the thingy.

And it's impossible to get an anthro token without having this properly, certain digital signage. So security is a very town hotel task, complete security doesn't exist, but this token bears out tokenization is an additional layer of security. And we think that they may be useful.

Yeah, what we can do in, in the future, we don't want to keep this a technology for us. We would like to share this technology where we're walking to the idea to publish this open. So we have Lima that easily, the implementation Java adopting is available is mostly standard-based.

As I said, the Java Java token. And it's possible to introduce with a modest effort in the existing identity management system and the application.

Of course, you have to have a better application. We have to still provision all the programming to use strange technology legacy. I know I work in this audience CCS, so, and the early version now already being used in telecommunication area in financial information, service and public sector. Thank you very much for your attention. And now I am going to try to answer your question.

Thanks, Giovanni. I really appreciate that input and explanation of Quebec. We're now going to go on to the question and answer session. So please enter your questions in the, under the question section of your go to webinar screen.

So, okay. We have a question on tokens.

So, so maybe do you have any, you could just help us understand what's the difference between this token based access control system and what we're used to now, like we were using SSO single sign on tokens now for, for transfer or roll information. So what, what difference are you recommending in terms of this? The claims based token access control? The difference is very small, but a vital one. If you are putting everything on the singles and Yon, the sequencing, your make, the secretor has only one signal.

And this is sent to over to the, to the application in our poacher Dow to sign in ID I entities. The one is the single sign-on who grants for the out indication and then Nando entity, which grants the access control and science, the object. So two different signatories. And I would say even for the compliance point of view, this really convenient. So the entity who grants an access wiser, make sure that the information comes as it is to the application and takes responsibility for that. And the same time you have a Dabo and this adds a layer of security. Okay.

Can you explain how a claim is signed? How, how is the signature verified?

Yes, it's very simple. It's really based on standards. So you put all this information in a Jayson object and you use a way the standard libraries available in all possible developing environments. You use the Java web token technology, which to define which seeking Neto, how you apply the signatory is again, a standup body available libraries control and so on. And you put this object is a long binary object, the inside and of the user object. These are two, both is transported with the complete use of objects to this .

And at the time of the session, the single sign on just need to be recomputed to tech. Even this attribute in a claim is a normal configuration positive by the SSO. And so this is being transmitted to the application.

So we, we didn't want it to invent anything new. We have a soul such a wealth of technology over there is fantastic. Okay. Thank you. Another question. Are there commercial applications using this token technology now an open apartment? Yes. We have a tool called the login master and there's identity access management system provided designer for the internet. And we use this technology early version of that available in, in operations is more than 10 years at a bigger telecom nation telecommunication company in Germany. And since five years in a financial company in Germany.

And since a couple of years in a small governmental agency. Okay. Now it's using login master. Yes. Early version of Logan Masa or the current version of all login master the things developed over the year. Okay. Okay. We've got a question in regard to use user agnostic state. The question says won't there be user action. Logging requirements will not be the logging that which will require retention of the user ID within the logs. No. Can you please repeat the question? Okay. It's in regard to the app, an app, not needing to store user information.

So you've got, you mentioned that once the session's finished, it's all gone, right? The user there's an agnostic, it's actually agnostic in terms of the, but the question is about like the we'll also be logging requirements and that will require retention of the user ID within the logs, correct? Yes. But all this information is needed only in the center system, they in the user registry. So the application just receive the session token and guests.

So the user information knows, can compare the user ID with the user ID in the token and checks the Cigna network and then can use the information store there. The information is all possible optional parameters, define definition, time by the architecture. It should be quite easy to use new information that you ever ease on your application.

And after the session, the application doesn't need even to save an user ID, the fall agnostic application, of course, but there are cases where the application has user data and of course there will be need of a user ID and father information, but we did our job of providing access management and information. Okay.

And, and, and, and meeting the GDPR requirements. Yeah. Yeah. Minimize them for the information. Yeah. Okay. Coming back to the application roles, how is the teabag approach different from the role based access control that we've been doing for many years? It's an evolution of would say, first of all, we are perfectly able to support the models of existing airbags.

I put the, the biggest effort, making sure that the things is evolutionary and not revolutionary. So you have a pamphlet splendid, the concept of working on air backer. You may implement one to one, but sometime you have for the DDA to be more fine granola. And so that you have the option to implement, this is something that you may use. I'm sure it's going to be used perhaps not on the first day. Understood. Okay. We have a question on risk-based authentication using risks scores. How does T back support the use of a risk management approach to granting of access control? Yes.

Wherever two aspects of the risk. So first is the time where you grant an access, an access whiter, and the entity who is granted at all. So you has to evaluate the whisker. I know that, for example, in some system you have a cigarette segregation of duties is the, the best point to process that. But you have to take a mind, you decide, should I take the risk or doubt at the time of decision, you store the information you sign it, you take the responsibility, use it, use a time. We introduce a parameter in this block of information, the trust level.

So there may exist holes, highly critical, and you may require, for example, two factor authentication for that. So this parameter is accepted there for this cope. If you are just logging in with parcel and all requires two factor authentication to be exercised, the application knows that. And then as to react, asking the user to log in again, or step up authentication is, is outside our scope. We deliver the information to the application, Right? Yeah. Okay. I just wanted to mention one of the questions mentioned, showing your slides again, is part of the explanation.

That's not technically possible at the moment, but the users, those who are attending this webinar will get the slides. So they will be able to look at that. What your slide do you have any that, that showed the content of the token, right? And so it's it within that one of those parameters can indeed be using the discussing of determining the risk based whether we need multi-part multifactorial, whatever. Yes. It is a parameter called T a R S T in the style of Java web token. The demons of the boats are very, very short, a few letters.

And I invented the permit of myself is that trust level. Okay. Thank you. Next one. How is cheap act different from a back using model?

So, Yes. So, you know, Baca is space. Mostly I have to say mostly on a passer, so wanting centrally and checking the policy. So the policy decision pine and the policy has been pint is in the application. We moved the policy decision point it an earlier time, not at the session time at granting time. So in the moment, well, an entity grants and access wide, this is that access, the access decision once done. This is stalled sent over the system and the application has to implement the policy enforcement point. How you Grant or assign a, an access wide is open.

We may use all the technology used today. Today you may use attribute based ranting or wall flow paste or anything in the direction is up to the identity access management system. But once you decide to assign access, certain weight is signed and stored, of course, being so flexible. It invites you to have a short time for this reason we put immediately that validity dates is an additional measure for secure. You can use very short ability to times the validity, the date is until the seconds. Of course. Okay. Yeah.

So that does bring up another question without that central policy control, would you recommend and T back environment in terms of a, having a common approach across an organization, how would you see as you're defining the roles within applications and putting together the user repository, how do you recommend maintaining a corporate wide policy to access control? Yes, it's thinkable. I've been thinking too, that later on, I'm going to talk you about a few aspects that are still on my mind, making the things better. Flexible.

If you have application is let's say an application posted by a provider and you assign a few tokens access token to employees, your company, and the employees go get down to the cloud to this application. It is enough that the cloud application and knowledge you seek signatory in this time, they can receive the resources that they need. So it's opening this direction tool. Yeah. My concern is just about the size of the claims. And I'm working already to try now not to let them explode because at the moment we have a few kilobytes and the size and the digital sign or bags is about one kilobyte.

So we have to be very, very careful in this, in this area, but for our style, I think we, we can do this. Another topic is that we had the experience about the number of tokens that an application and our user has in the security and a potential disaster. If an application received a token provider for another application, but we made development for data and application, we receive only token, which are deemed for this application. We are the beginning with this, sorry, as you see, and we will be keen about criticism implementation, cause track the is, is, is the best that we can have.

Very good. Yeah. And if others would, like on this webinar would like to explore a partnership. I'm sure that would be of interest to you. Yeah. Okay. A question here, can we use a T back in for a highly secure application in something like a trading system or even a cryptocurrency where the risk is huge?

Yes, I think so. Because we would use it to our development. Other commercial name is called secure wall. And as you have seen, we tried at every level to make the things more secure. So is our solution is decidedly most secure that just ABAC. Okay. And we have a question on evolution slides is T back really a step after our back or a bag for administering privileges. The comment is it looks more like a separate layer dealing with the runtime of all administrative models.

What's your view of, are we talking a replacement of existing access control systems or are we talking in adjunct to those? I Always say is an adjunct at the D edition. So the well, very interesting insight to the way we work together or based. And at the beginning of 92, I think had the idea. We have defined the goals in an organization.

We give the access related to this was they easily after signed that sometime we have all based on their organization, a hierarchy, but mostly are based on application we're agnostic on that we can implement application roles and leave the business holder, really organization oriented the so to the identity management system. So is clearly application roles inside these, we structured the name of the goal in three powders, or the pros is a domain.

We had experience with microservice based application and we define a domain for data so that the goal for one application can be even to another application inside the same domain. So we have already some practical experience expertise in the field.

So we, this flexibility, domain name, application name, and role name. We can design very, very clear security policies, but definitively is an addition to existence. Very good. Okay. We come to the end of our questions. Now I do have a chat here in regard to the poll. So we put up post poll event poll sharing results. Very interesting. Okay. May I comment the answers and what surprised me a little bit better? Can you show again the result of the power? Yes. Thank you. So being active.

So since so long in the identity access management technology, I know that the provisionary consume a lot of our energy. So the first part is clear to me implement a formal fine-grained access control is a problem that I had personally, but I didn't expect that this is so much need over the, the network. The surprise for me is very, very interesting and GSEs certification goes on a par with the first point is, is really a cumbersome task. And over the cloud, I've shown that, that this possible two episode notion and even a little bit better control and insecurity. Okay.

Do you have any I'm afraid our time has gone by, I thank you very much for the presentation and for this introduction to token based access control. Thank you very much. Bye-bye.

Like this?

Don't like this?

Why don't you like this?

The Evolution of Access Control