Ingy Youssef - Top Identity & Access Management Standards & Protocols that You Should Know for 2020

uh hello everyone i'm angiosa and i wanted to share with you today some protocols standards and schemes that will be absolutely awesome and important for this very special year 2020. think of this as the harvest pick for identity access management for the year so uh before we get started when we say add any access management that's huge so that's not only authentication or authorization or at any life cycle that's like a huge huge space with tons of stuff but you know what the most important thing that is coming across all this is that there are two things that we really care about and usually we really need to work really hard to balance them these are the customer

experience and security risks and threats and you know what the idea here is that this is no longer balancing this is no longer a luxury and i'll tell you why nowadays there are i want to draw your attention to these four main blocks and the reason why i bring up those is that it is a two-way street for both for those and identity access management you know why because at any access management have a direct effect uh the majority of identity access management programs in enterprises have direct effect on them on each of those and also these things have challenges of a very uh special type for identity access management programs across enterprises so let's just get those uh

those awesome stuff uh get around round about for these awesome stuff and learn more about them but the first one is really digital transformation so when we're talking about identity access management digital transformation uh enterprises wanting to meet teams where they are enterprises wanting to open up their business and provide their services accessible um in different platforms accessed through apis and their data as well all these things these are the root and the heart of digital transformation and with all this comes very important considerations of how the identity access management experience should be in order to enable those kinds of very different services than what we used to do before in our enterprises closing down on data closing down in

services now we're opening up now so if the identity access management uh uh services here are uh uh have are heavyweight it's friction has also friction with them and stuff it's not gonna help and vice versa digital transformation across all the different enterprises going through it now have a very special type of challenges that it introduces for identity access management it's a different model you literally have to look and think of things differently and go more fine green and so on so forth now moving on to the next one and that is the cloud so uh right now we're really anticipating that most of the organizations will have their data in the cloud like uh really really soon like i mean

lots of data we're talking about like hundred percent uh my you know next year or something so uh we're really uh uh talking about operating fully in the cloud and and the thing here is that in order for cloud journeys to be uh successful it needs to have really um a an identity access management program that's based on automation and that is capable and that is modern and that is cloud friendly right uh and so uh with that comes it comes that's the success of this journey can't be without this and also vice versa cloud is by itself has lots of uh puts a great emphasis on iem identity access management is the new parameter

ford for uh enterprises because of the cloud where everything is the new parameter is the identities and the access management and the access rules that are governing the access for those identities it's no longer networks in physical errors right there's no insider outside now moving on devops so devops this awesome vehicle to deliver code and software at speed and with speed uh that means you can't be a heavy uh manual i am processed seasoned in the in the in the path to and stay you can still do devops so at any access management and automation and and and being able to have those operations really efficient and covered all these things are are very important for success of devops and

organizations and vice versa concepts of lease privilege change management all these things are real things that i am programs needs to understand how it can be tackled for devops and final zero cross and i think uh like it's it's a cliche really everyone wants to see what is devops what what is a zero trust what what does that mean for us what does it bring uh as as as this is coming and it's in the future or sometimes some enterprises have managed to go on this journey you cannot buy your trust it's built on it on really lots of practices and things you keep building across the years from data classification segmentation and and very very strong iem uh and

granular permissions and also privileged access management so again you can't do zero trust and succeed with it without a strong im uh program and vice versa i am does have lots of challenges when it comes to an emphasis when it comes to uh making zero trust a reality and so with all these beautiful stuff uh the journey and for anything on any access management as big as the space is it's centered around a very small concept which is the concept of digital identity and for this concept if you look at how this concept is evolving you will clearly see what you really need as an enterprise to focus on and so so we started uh early on with

the traditional scheme where we're talking about really that in order for the user to interact with different applications they need to really create a different account uh with each of these applications as if they're really interacting with each uh there's a different issuer for each of those applications to interact with that was some time and then comes federation we're talking here about uh you know saml based federations our back base authorization models and all these things where really what was happening here was we say hey let the experience improve here why do i it's the same user right why do i need to create multiple identities can i just have an identity that's managed by a certain

issuer and then those apps can just use this issuer or this trusted identity management system to authenticate the user and then we can you know go from there so it's more like uh it is still more organizationally controlled there is some big brother something here that's working on which is this issue where the trusted identity provider the you know um but but all this that's in the federated model now let's go on to the current model where lots of enterprises that are going through their digital transformation journeys are actually passing through it which is the user-centric identity in the user-centric identity the user is at the center of the experience we have what we call

digital customer journeys mapping and we have people study how they can improve on this and an end but also with that comes lots of things that we can do for iem that makes this a success and here it becomes the flexibility of hey i can actually i don't need to use this specific uh identity provider issue of identity i can choose who i want to use i can for example authenticate with with google and or facebook or this idp for my enterprise or the second one or the other one it can even be registered dynamically so that it brings us to this users at the center of the experience and we design based on that

and then moving forward to self-sovereign identities and with that we're really talking about um how can the user is the owner of the identity and how the user can control uh where did they what to share about their identities and with what data so no control over the over the user's identity or issuing uh or basically the user does not need someone to issue an identity on its behalf it and we will learn more about that for and it's how can this become a reality through blockchains so most of our enterprises if you're going through a digital transformation probably you're trying to having lots of conversation around how you can personalize the journey uh the experience for the users and

probably you need to ramp your im program to be more user-centric with user-centric identity protocols and services so uh from that let's um let's take a look a little bit here uh on one important thing just to so that to make sure that we really set the ground right um we are going to explore a number of protocols and things and some of them i will use the word hey that's older than this that's the newer approach that's thus think of all these as tools in your toolbox so we're not doing and in with the oh with the new out of the old no no no keep it in there's no one leaving here the idea is

that the organizations would have this great toolbox to use based on the context based on the problem being solved and we need to make an informed decision of what works best for us so just to reiterate again the im is a huge space and we are going to focus more on authentication and authorization primitives throughout this talk this is as you can see here this is the ficom architecture model uh it's a federal identity a credential access management model i like they have lots of resources there but just i took this for you here and i highlighted those and this is going to be our focus now since this is going to be our focus let's just

make sure that we are on the same page which comes with some terminology when we're talking about authentication authentication is really about making sure that the user is really who he is who he or she is claiming to be so there's some identity claim that's being verified by some verifier now the claimant who is the person to be authenticated have some factors that is being used during this authentication process there can the factors is something you have so for example you have a card you have something something you know like your password something you are like your fingerprint if i combine uh more than one factor it's we call it multi-factor it can be two factors three factors but

these are uh this is how the claimant can prove to the verifier through the use of this factor through a certain scheme uh we should call an authentication scheme uh that it is indeed who it is claiming to be now authorization is entering a different problem authorization is saying is the subject allowed to access the requested object with the indicated operation um and so the the in that case here the subject might have some attributes group group belongings roles and the similarity for the object and there is usually a place where this decision needs to be done it's this this enforcement of access needs to be done which we call usually an enforcement point and it can

consult with different uh things or do operations itself in order to reach this answer to this question just to that we make sure we follow through we're going to start first by authentication then switch to authorization and finalize after that uh with uh uh our talk with some with some new trends and stuff so uh starting with authentication first of all before we can start uh going into any of the schemes or the things you want to talk about i really wanted to share with you this framework so what is this as you can see here this is a table of some criteria okay we're going to use this throughout the stock to compare the different schemes and

things that we introduce uh and talk about now this is not something that i came up with this is actually something that was based on a research in a paper published in 2012 it's an older paper but then it's been revisited a number of times and google has used a number of references a number of paper why am i bringing this here lots of times again from from from experience you find that the enterprises are in situations where we're making some decisions it's not it's just based on oh this is set to be the standard the industry standard oh great industrial centers are awesome i'm all in for it but does it is it the right thing to do for

your situation is it the right thing to do for this feature for this project for this effort this is where this framework can help you and so i brought it in here and i'm going to show you how this will help indicate uh or how we can use it to compare the different frameworks but then as you can see it is made up of three main categories usability which tries to measure the user experience here and deployability as an enterprise is your life going to be held after you adopt the scheme and then security and privacy which is secure considerations and privacy considerations and i'm going to give you an example so usability so we're going to take a

look and say hey is the scheme uh involves something how is it from a memory wise effort does it involve it's easy is it easy to learn and what about is it efficient to use does it what about infrequent adders that measures the the user experience now from a deployability perspective look cost the cost per user what about compatibility is compatible with browsers different types not all maturity that makes a difference we're supporting other security and privacy for a third category let's take a look at this is resilient to phishing is it resilient to theft um it does it include consent is the user ever asked are you okay with sharing your your identity data so all these things are very very

important and i'm going to show you how we're going to apply this so the flow here is as follows i want to introduce you to some of the protocols and the frameworks and the schemes and models that are going to help you as we're going to address those newer challenges like for digital transformations or devops or cloud or zero trust and all um so in order to do that so what i'm gonna do is really i'm gonna uh work with you on first password-based scheme and then passwordless and then uh during that time i'm gonna pivot to federation and show you uh how these two different models work when we're talking about federation as a

concept here so we're all familiar with password-based authentication we see it all the time you enter username and password and uh you log in you create uh some account with the application and then use the credentials to log in later so there is some secret that is shared with a server somewhere that authenticates you when it's time to be um to authenticate with the password-based authentication scheme now i'm gonna pivot to passwords via a single sign-on or federation basically federated access and the reason i want to pivot so fast here is uh really it it is a real need for fast pivot so first of all instead it is as simple as this user wants to use a certain application

uh application a and once you use application b and or spirit application c question do i need to create an account with application a application b application c application d ah okay but is there an easier way is there a better way so that's federation federation says hey you can use if there is some identity provider or identity management system or verifier that you trust and as an application you can actually uh use this to log in your users so for example give an example here which is a single sign-on for consumer apps so this application here say say for enough for an application called uh travel travelopedia whatever that is uh and it has this

sign in with google so it doesn't tell you have to create an account but it allows you actually if you have a google account you can sign with google we call this social login but that's also a form of federation because google in this case as an identity provide acts as an identity provider and allows uh you to authenticate with your google credentials with your trust relationship with google across all these apps without having to have travelopedia uh collect your credit your your credentials and restore it uh at all now on another note probably lots of times probably you've seen that absolutely in your company you log into your computer and uh you have here you

go single sign-on and it adds this best you're able to access all the suite of applications for internal use only you this is the board for this and this is uh the area for that and so on so forth inside your enterprise that's single sign-on you sign in once and you're signed in already to these applications with this single sign-on so um that is great we are going to explore the protocols for single sign-on and look at more towards the details of the newer one which is the the first one i want to draw your attention to which is what we call open id connect but before that i really want to show you how i've used the framework here and

it's not me that's again that's i included the link here where references the paper and also the blog the the article that was wrote on that uh but basically what we're talking about here is comparison of password versus uh password via ssl so password-based authentication versus if you're using federation you have here are the categories and if i'm gonna look look at this so you clearly can see how federation is helping with usability absolutely now deployability some problems here a little bit because of costs and things now also securing privacy is enhanced but look here so resilient to fishing i want you to hang on to this idea because we're going to explore it even more

coming in but i want you to see that none of the password-based schemes are able to protect against phishing hold on to this idea okay perfect now uh open id connect which is a this is a an identity layer that's built on top of a protocol called oath and law it's not a protocol actually it's a delegation authorization framework because it's not a protocol but open id connect adds an identity layer and this is actually also uh can be used for federation so there is the federation protocols that are most common are saml based federation and there's open id connect based federation and there's other stuff we know that there are other stuff we're not going to talk about now but i just

want to highlight under the spotlight open id connect for federation and specifically for consumer apps so let me take you since uh and by the way i want to find this so so i took this this diagram of open id this logo for openid connect and i placed center in it the uh uh the oauth logo because it is really a part of it i can't talk about open id connect document go up so you might say ng you're talking about authentication for god's sake what does authorization have to do here with authentication for federation what is that uh so it's very simple um so you were during the uh remember in the older protocols the

older approaches it's more about hey there's this user also authenticate and so we authenticate them with the uh with the saml protocol with the identity provider of choice and and then a certain assertion um detailing the identity of the user is returned back to the to the questing application right that's the normal federation flow the the problem here is that again zero consideration of the user itself whether the users are okay with sharing their identity attributes with this application or not nothing of this is considered openid connect brings and brings us us it brings us back to the user what we call the user-centric uh uh experience okay for for uh id access management and

here for authentication and so what happens here is that it's really critical to authorize the application that the the user wants to use travelopedia uh to make sure that the the user is okay obtain the user's consent before sharing the user's identity with travelopedia the application or the client and so that is where the oauth protocol comes in and so um what's happening here is uh it's really uh this is a very high level diagram okay so what's happening here is that the uh the application travelopedia the client we call it the client as well and we call through rp relying parts we call it a resource provider like oh my gosh like tons of things

uh terminologies here but uh the user is gonna be using uh the application and the application will be like oh come on hey you know what i need to get this user to authenticate with their uh with the with the identity provider um that uh uh with the identity provider say if it's social login it's gonna be google if it's uh something belong to certain companies gonna be that company and so on so forth so there is those steps here one and two it's about obtaining an authorization grant it's getting a proof from the user that says that they are okay with sharing their identity attributes with this application travelopedia okay so now this application is going to take this

authorization grain and go to something called authorization server give it the grant and say here here's that's the proof that shows that the user is okay and so the authorization gives back some stuff and or the identity uh we're gonna see that they but then it gives back an access token now the access token the application travel pd now have access token now we can use the access token to get more details about the user if needed this is because the user have said it's okay see the user-centric experience it's very respectful of the user and their privacy and their needs as well now i want you to hold on to this idea now let's go on to this

diagram i know it's big we're not going to want to over all this flows but i really loved it i just thought it's going to be very useful uh for you to see that and uh what i would definitely see he say here is that you do have those browsers and this is what we call in the authentication the federation word what we call the identity provider and assume that you have an identity provider support supports both saml and ygc and i want to show you just how both uh differ it's a different it's a mental it's a mindset shift because if you look here at what happens in the sample flow so if i

assume that this part here is not there and just look at the green okay so in this part here a user is trying to use travel pd which is say at sp.example.com okay and so the user will say hey i want to access that i want to log in or do this and so uh the travelopedia takes redirects the user to the identity provider and there the identity provider is going to display a login screen for the user tell them log in and the user is going to log in and stuff and then there will be some signed saml response received the saml is an assertion uh and it is uh signed and include a number of uh

claims uh in uh yeah i'm used more to the uh the openit connect i prefer to use that but anyway so the claims or basically assertions around the privileges the user has in the groups and the stuff information about the user in the symbol and it's returned back to the uh the client here and the client is just gonna validate the signature and stuff and say good yeah that is indeed the user we just did that now you can access the resource now let's look at the same flow here but let's see if i'm using open id connect and i want you to see the respect how the user is being respected here and the user is the owner

look at it the user is the owner of its identity the his or her identity and the user is the king or the queen of their identity it's really that way but we've law firm so long dismissed that but now open id connect again the user centric experience so look at this so uh there is a request for the user wants to access requests and say hey you want to access this i want to log in and stuff the users then there is some openid connect authorization code request that is sent uh to the idc and the user is redirected to login uh with the identity provider then the user starts interacting the login page and enters

credentials and stuff but look at step number six obtain end user consent and say here are your attributes we're gonna share this are you okay are you fine with this and then the user says yes or no and based on that we provide the content um and then it's redirected back with the authorization code this is one of the flows by the way it's not all the flows there are other flows for applying to connect i'm just going to focus on the off code grant for now um so redirect with auth code and then uh with the off code here that's the proof that the user is okay and now the off code now the client

has it and so based on that the uh the user is the the client is gonna send a request back to the identity provider and saying hey i have the proof now please give me back the identity token which is detailing the identity of the user and some claims and it's signed it's assigned json just the shot and return it back to me and give me an access token if i need more and so that's what happens and then now the client has this accidentally token valid and then they can ask ask even for more using the access token isn't it beautiful right it's beautiful okay so open id connect versus saml so i i just put this this here for you

from different sources uh but basically i just want to highlight a couple things here and this is for your reference just a couple of things first of all interoperability so saml saml uh as a a protocol this this is not does not support native apps does not support mobile machine to machine no know that for all these you need to use open id connect for federation and you see that saml is not going to work for you okay now it's only browser based um now collects consent we said say i'm all no open id yeah and lightweight of course open id connect is definitely using lightweight json saml is using xml and um and and and one one thing i just

want to recommend is that if you are developing for enterprise apps and stuff and they are already uh you know you have saml uh ability um to interact with with uh to support semi-federation that's okay now when you're building new apps put in your mind again weigh your benefits way why and and where you want to take it next and my recommendation is things are going towards open id connect if you're building new apps for consumers go for open id connect federation um and and and definitely again if you are protecting api resources uh it's you'd better do we do it using open id connect anyways it's built on a lot so why the you know the plugging things

with with saml just get some tricky stuff um now uh okay so now we talked about passwords right and and remember we had this uh we talked about federation none of them actually solved the problem of fishing obviously it's like feeling us badly here but we're going to use multi-factor so multi-factor brings up the game to a better level a little bit better okay and there's many ways to incorporate another factor so one uh one the very common one which is what we call the otp and there's many different types so it's a one-time password and there's many different types so it's called hmac otp or time based otp and the differences here is like like

the for the hmac otp there is a one-time password since you say in an sms suppose whatever the way but this uh one-time password is gonna stay um at the same stay valid until another one is sent or it expires time um and then what happens is that you enter the password and the one time uh uh pass one time password in order to authenticate the totp though is time sensitive it's like an authentic hitter uh it's a app on your um on your phone and our authenticator app and it's just basically valid for for any single point in time there's only one otp that is valid so it's a little bit of difference but i just wanted to point

that out this is the most common right and sms and voice and stuff based on that another thing that's also very common is mobile push where uh basically when you log in with a password then there's a push notification sent uh back and you there's like when you're logging into office 365 and you get this allowed deny and hey you click allow this will uh basically sign a certain assertion return back and that will say yes the user is okay here and yes uh unfortunately what we just discussed here is still prone to phishing the user is going to be creating a bad site malicious site and can harvest these things as well so and then relay them to

the uh the identity provider so the fishing is still a problem and if you know that oh my gosh like tons of attacks still happening because of fishing and yes human is the weakest link but it's the most beautiful link and so we have to find a way to make it happen right um and so comes fighter 2 and i just took here this is like a screenshot of the fighter 2 super happy about what they've done alliance and then it obviously what we're talking about here is what we call a multi-factor authenticator it's a it is also said to be a password list and we're going to say here why but uh it is it's not because there is

no password whatsoever it's just because the password is not sentence shared with a server there's the password never leaves the device called private key but anyways okay so but there are some pins and things yeah anyways but this allows you based on the fido protocol and its beauty it allows you actually to compose multiple authenticators again the user in full control i can actually have a beautiful experience where i can use a compound many authenticators can be a hardware token it can be in my mobile device it can be a pin it can be my biometrics everything right so uh let's dive into a little bit into this and understand more so we finished the password coming

to password so so the password list i'm introducing fido to and think of fighter 2 whenever you hear the word it's really an umbrella of two main protocols uh that have been actually incorporated as apis in the browsers and the devices so fighter 2 is a combination of two one is called web off and and the other one is called c tap and and then what it what it is doing is trying to find a solution uh by which um your again the client which is running maybe on your um a computer or on your phone uh once again to authenticate to uh some remote server website uh right and uh and send the authentications uh to this

remote server website and another thing here that i want you to notice is um webauthmn is the protocol that handles how the communication goes between the client and the remote server the ctap is the one that handles uh what we call remote authenticators like what are how do we manage the these conversations and chatting that comes between the removable authenticator like a phone your phone can be acting as an authenticator actually uh for uh your applications or you can have a secret key like your keys and things um but also for your client for for even even on your device the same device in which you're running the application or decline you can have built-in authenticators

like through fingerprints and others so beautiful so what uh what we want to do here and do understand is really how this thing works why is it worth it why does it uh why why does it really solve the phishing problem why is it passwordless here's the thing cryptography so here is that assume that i have facebook uh i want to log into my facebook account okay and here is the facebook server here okay so what happens here i have this uh this is the the really um normal screen but that's not what fido looks like really usually there is when it is time to uh for fighter clients uh creating an account there's two things registration uh

and then uh basically the use okay so the the thing is that assume that i have a certain security so i think say in this example have the security key here and maybe it's my phone maybe it's something else maybe it's a hardware key is like just like you see here but what happens here is very simple uh when i want to log in before that i have to create an account so the way that an account is created is uh the um the user um i'm sorry the the client itself wants to get credentials created by the um by by the security key that we own that alice owns and and uh how does this happen the client

which is the client of facebook that is fido supporting fido uses the browser's api for web authen in order to ask hey i want credentials created for a private and public key and give me back the public key so private is a private key is a secret and this device and also i forgot to say that also the origin of the call is returned so you have here um no i'm sorry not the origin here uh so basically what's happening here is uh the the the security key is gonna generate a private and a public key and return back the public key and the browser is gonna pass this back to the client the client is gonna pass this

back to the server and the server is gonna now say yes this is the public key i'm going to use to validate uh assigned whatever signed messages i'm going to get from this thing now when it's time to use let's follow this diagram now it's time to use now so the first thing is uh when it is a time to authenticate uh the server sends a challenge challenges some dance of some sort or something and then uh the client again through the api the web button and the ctap apis uh whatever the again the there's some more details here uh but then it sends the origin so it's the facebook to come along with the

challenge and ask the key to encrypt this see the beauty of it the key is gonna say hey user are you okay with me doing this action because i'm gonna sign this and send it give me your consent the consent is gonna be a fingerprint or a pin or whatever so the user does this and then based on that uh this uh this device uh the removable authenticator is gonna basically encrypt the uh uh sorry it's gonna sign both the challenge and the origin and return it back so it's signed it's signed with the private key now how the signature can be validated it the server does not need the private the private key at all and it doesn't

know anything about it it's only the public key just the asymmetric cryptography right so we go back and then all the way the client sends that assigned assertion uh about the challenge and the facebook the origin to the server it validates it and yes that's it now if i find something like malicious facebook.com with it which is the phishing ideas right it will catch it now there's many types of authenticators again we have roaming authenticators built-in authenticators and the options it's beautiful really the options are a lot uh you might think okay wait hold on how does this relate to single sign-on so you've been talking about open id connecting your protocols and these things in saml

um what does this have to do with that these were password-based so that does that mean this is replacing sso no no no no no this is actually complementing the sso experience with this beautiful experience of fido so uh think of all the sso uh uh like flow just the same as you're used to but then there is one only step that instead of signing in with your password you're gonna sign in with the same steps of fido that's it otherwise everything is the same and the results are in and i just again i'm retreating i put all these stuff here because i want you to see how these platforms how these uh things compare and

what is important about this is that that's not what you're gonna use don't use this comparison and say just because uh it is uh supporting for it is a browser compatible uh for for example server compatible i'm going to use it or no i'm not gonna use it no it's based on your application of it and your use and your needs don't go beyond that it's not based on the stand like this is great but this will allow you how to based on how you value each of these attributes and you're based in your use case you're gonna make a choice so now with stock authorization so for authorization uh authorization again is trying to see really can a

subject access the object at this time with these attributes with these conditions right so access control models uh are have been like since eternity lots of them have really matured over time and from access control list drill bays apac attribute base uh policy base which is uh you know for now probably take it for now attribute based uh and policy base are usually used interchangeably there's a little bit of difference it's okay just use interchangeably for now and what we call a radac risk adaptable access control so in order to explain this to you in an easy way uh i've been thinking about that disney oh my gosh when will the kobe be off out of our

lives i don't know but anyways so the disney rides assume that there's a new ride and uh and all the beautiful access controls uh are gonna be used in order to authorize if someone should uh enter this right and assume it's news we need testers come on you can get the just a customer writing and and you're right without testing you first and so my new ride is waiting for me but the testers have to test so the first one the first protocol which is uh the first model model is not a protocol the first model which is access control lists is gonna say hey is your name on the list if that's the case

you go in you're authorized if that's not the case you're out our back role base access control is all about roles and the permissions and so if testers always have the screen pass because the role is defined by the screen pass and so i'm going to say oh you have the green pass oh so you must be in the group of the testers go in now abac is gonna say come on what's your height what's your age what's the time of the day are we ready okay go on you're authorized or not your attributes based on the attributes of the subject based on the attributes of the objects there are some policies and rules defines

uh should you should go or not redac is going to say have you been to a covered outbreak area lately so it's really trying to put this more risk uh based weighing in access control decisions and there's a lot of it then again in order to support any of this you can remember it's your toolbox it's not a throw bring in and throw the rest okay please don't do that there's tons of details here look look at this i just kept it so you see the complexity of getting these things to be working and producing value for you uh so we're gonna go now over what we call attribute based access control at the center of it really again the

subject object and there's some attributes and then some attributes for both and there is some policies that governs that relationship i want to introduce you be my guest to the standard uh that is very widely known uh for implementing a back it's called zacmo and the latest version is three there's another one that is uh less and less no like at least the vendors are supporting very strongly exact model but there's end jack as well next generation access control but anyways let's stay with the zachmar 3. this is how the architecture looks like usually there is some policy enforcement point where the uh authorization question comes from right so uh someone is asking me to

view records one two three so the post enforcement point sends to something that's called policy decision point this is the one that really gives is responsible to provide me the answer should the policy enforcement point say yes or no and it has lots of intelligence and logic there that allows it to do this how it accesses policies from what we call policy administration point where all policies are managed which is written in xml and there is uh what we call policy information point which retrieves the values of the attributes lots of decisioning happens here and then the condition and then things are returned zac mill has also features and things and it continues to grow and improve

but most importantly here we're talking also about ability to do caching stuff and this is i tried here to get you also this comparison and i've used uh lots of things but the most important differences between a back and rbac is that this concept of fine grain access abacus can really go fine grain and without uh and still able to scale so the problem is yeah you can go find green with rose you're gonna have a roll explosion for god's sake um now i can use it's it's we call it multi-factored access also not only roles i can have other attributes uh the cost of a back can be more higher because of the management of policies

and things uh also a back is more suitable when you need in a dynamic environment where things it's not a static decision it is based on what happens i'm going to apply another rule and then another rule or third rule so in dynamic environments and there is other stuff for your um reference as well here now before we wrap up uh i wanted to go over the road to uh self-sovereign identities using blockchains so the pain points have been fraught skill flexibility privacy right consent user is not happy and much more and so users want to keep control uh really they want to get out of those organizations out of those controlling entities and be

and own their identity and where their information is shared and how it's shared and what to share and so uh comes blockchains if that's legal i'm gonna give you a primer on blockchains in two minutes yeah seven minutes after seven minutes i don't know okay so uh so here is here's blockchains in a very easy way assume that someone wants to have to do a certain transaction okay so there's some transaction that needs to be done and i want to see can this transaction is this transaction valid uh or i want this transaction to be completed whatever my request is but i have a team of a network uh of a peer-to-peer network of what we

call nodes these are going to be actually working together on my transaction and each of them are going to be trying to validate the transaction or work on it the first one to finish is going to be the winner the winner is going to need to produce what's called the proof of work that's going to be validated by the network now after consensus everyone is happy and now i can trust the decision of this thing now what happens here is that this this transaction turns into a block and placed in a chain and this chain now has it permanent and cannot be altered and can be reviewed and checked and validated so now let's use this concept and see

how it will apply here so web of trust on the internet yes it is time to decentralize this thing so again lots of stuff that we do across the internet and in our applications and an end is dependent on public key cryptography so imsnj i will come in and say i have a private key i'm not going to tell you about and i have a public key and and we can come together and we can create a secret uh and i i will create a secret with you in order to do other operations but i'm not going to share with you my secret instead we're going to use an algorithm called the helmand's variants in order to be able to

establish this common secret together and so uh but hey come on there can be someone else that comes in and claim that you are injury and having a private and public key and give your public key and say hey this is ng create a secret with me but that's not okay it has to be that really there's a proof that energy is it this public key really belongs to indian ng is the one associated with this public key this is where what we call certificate authorities comes and usually there is a web of trust uh in which there is a certificate authorities and there's a root certificate authorities and multiple other branchings based on that and it's uh

there are challenges with this and again everything has to be registered with these certificate authorities and things remember self-sovereign getting away with all this here comes the magic of blockchains and so in blockchains really the idea here would be to say i'm sorry the idea here is is to say can i really uh do have a way instead of asking the certificate authority to uh check my uh this to have the signed assertion which is what we call the certs right signed assertion that says here's the public key and really belongs to this person and signed by the trusted certificate authority no let's do something else so blockchains there will be a public ledger this public network and

uh what's going to happen here is a big huge thing and what's going to happen is that the users have need to register their uh what's a unique identifier with their identity and then whenever there's a transaction of a new sort what happens is that any user will take this claimed identity with the public key and provide it to the public blockchain for validation and based on that we can get more uh trust into that this is indeed the claimed identity related to this public key and then uh the whole scheme falls through so yeah so that's uh that's just what what i wanted really to cover uh for today and i think we really went

through a password-based schemes and password less we've been we've looked at federation we've looked at the new concept of empowered users through open id connect in sso for consumer apps we looked at password loss and the beauty of the user experience and improved security and the challenges ahead in the road moving on to the more to come for blockchains and identity access management and um thank you so much for your time and i hope you the best but i would just want to remind you grow it now it takes time uh start planting or bringing all the stools in your toolbox planting those roots for your digital transformation your awesome devops your wonderful zero trust journey and

definitely i want to see you up there in the cloud thank you