 Well Hello, everyone. Um, my name is Miguel Suniga and I'm gonna go over and talk to you about some How to do a single sign-on on a hybrid cloud? I know that this is open stack, but to be honest all the enterprises are not gonna have on the open stack They're gonna have open stack assure AWS, whichever it is All everything all this work started two years ago Pretty much was working for semantic back then and we're doing a hybrid cloud between open stack running in three data centers and AWS so back then um, I start doing the Authentication for the open stack piece and then try to plug it into AWS Which is kind of difficult to go over and do it and then on top of that one You have a lot of different tools in open source like Kivana or Grafana that some of them they do actually provide authentication some of them They don't and actually coding it inside of it. It requires some major Development effort So who am I like I said you'll see I usually do software and infrastructure I've been working from engineer all the way to down to the rector on hands-on If you want to know anything more about me, you can just jump into LinkedIn So what are we? I'm gonna go a little bit fast. I tend to talk a lot But there's a lot of things that we're gonna go over and see First of all, we're gonna see why you need a single sign-on then the difference between the IDP and SP and what's the role of each of them then we're gonna go over and do some basic Different protocols and standards that we have for authentication, which is basically SAML, OAuth2 and open OIDC or Open ID connector Then we're gonna see some software and SSR architectures And we're gonna move forward into how do we need to enable it for open stack then how we enable it for AWS for the Exactly same authentication and then as extra I have a little bit of how to do the SSO for applications That I are that are pretty much already out there That you don't have to go and recode them itself put it this way How to do an on Kubernetes also as well, which is the new thing that is coming on and then a small demo On a small lap that I put myself up there so Why are we gonna be using single sign-on first of all? Simplifies user management. It's way easier to just go over until it added to the active directory Because it's tied up to your IDP or pretty much just put it on the IDP itself It's more easy than going over and creating the user on all the every single Systems they have in your enterprise or in your business and Then actually have something that is gonna go over and sync between them That was one of the problems that I had a long time ago When I was working for a video game company that we had LDAP and then we have AD and doing the sync between the two of Them require a freaking cron job that was running daily every five minutes instead of doing that With an IDP system is way much easier because just put it in the back end directory if you want it or you just put it on the IDP itself and that basically takes care of the authentication of everything Like I mentioned it. It's a single point of authentication and authorization for all systems This means that it can do authentication One thing is that you go over and tell it who you are and the other thing is to go over and tell you What exactly you can do in this case the single sign-on will provide both of them Depending on the protocol That we're using if it is SAML it can provide both if it is open I this OIDC will basically just provide authentication But not authorization. It depends then the other thing is that you're gonna have a single framework for authentication Meaning that any other new application that comes in you're gonna be able to go over and tell your developer You know what follow up this standard and you're gonna be tied up to it You're gonna have access to all the users and you can just put your roles on it You don't have to do any crazy into it Like I mentioned that we support multiple protocols. It depends on what is your use case So for instance if you're gonna be using for a web interface Ui or some kind you can put it on SAML If you're gonna be using it for just authentication because you're managing your authorization in your own application itself You can use open OIDC But if you're gonna be using something else like for instance on Kubernetes, oh, no, sorry That you're gonna be using just authentication and you're gonna be using OIDC then you can go over and tell it I'm gonna be using this but I'm gonna be using an OAuth 2 server as a resource server and The resource server takes care of actually giving you authorization to different pieces The users and the operations teams will really thank you about it and for security compliance and audits It's way must simple to go over and say Give me all the users that you're actually that you're gonna have access to these systems then going over and auditing every single system by hand manually So what is the IDP and the and the SP the IDP comes from? ID provider and the SP is a service provider. There are the two SSO components the most common ones the IDP the identity provider Does the user management basically keeps track of who's who and what I mean if they're actually gonna Say that they're acting that they're claiming into it and the service provider is the one that has all their resources and Improvise the service to the user verifies that the user is authenticated and verifies that the user is authorized also as well some examples of IDPs well right now on outside on public cloud one of the ones there is One of is basically Otca, which is the most popular one But you also have some other ones that are open source like key cloak on glue and WSO All of them provide all the services IDP and SP as well Now if you're looking only for service providers, you can think of it open stack AWS Google key cloak as well specific configuration and as well as Otca and WSO you can put it on a service provider as well the main thing here is that these two kind of like Components are what is actually required to go around to a proper authentication meaning that IDP usually doesn't run where the SP is running And that way you can separate security concerns of going or and saying you know what you can actually hack into the IDP Because the service provider is in the same network. That's not how it's designed for that's the reason why they're separated So going into the protocols These are the Authentication protocols if you want to go over and put it in this way you have SAML either SAML 2 or SAML 2 SAML 1 or SAML 2 It's a really old protocol. It's been out there for a long time Then came out both 2 and then now the latest one is so IDC It really depends on like a sale in the use case. They were looking for if you're doing enterprise SSO Most of them will actually require SAML Because you SAML provides a lot of information about the user doesn't provide only like here's your token or he is basically who claims It is it can provide you all the set of roles set of probes anything that you want user emails anything like that You want into the XML format on the odd tool is Similar but it won't actually go over and do the authentication. It will just go over and tell you This user can be authorized for this stuff But it won't go around say, you know what this user claims to be this user and this correct and no IDC is the other part Which it only takes care of authentication, but it won't go around tell you. Yes, you have access to this resource So you can think of it as a lot to an IDC Compliment of each other and pretty much that's how it works now for the use cases like I mentioned it SAML is the overall enterprise Use case on all two is more focusing to API servers Because you use tokens to go into it and no IDC It's more of web interfaces that already have some kind of like role on in the back end trying to figure out What exactly you can you can have access into it? The pretty much the table just tells you really quick Interview on what is happening in there. So on the author architecture on the SSO architecture right now This is pretty much how you usually go around deploy the stuff You go over and put an identity provider on each of the clouds On each of the regions if you want to they can go around just replicate themselves They have different pieces the one that is more accessible and easy to go over and configure and set up right now It's key cloak and all the demo is gonna be based on that one because it's really straightforward to go around do it And the replication of key cloak has a HA and active active using infinite infinite infinite span which allows you to go around and just have IDP Running in AWS and modify a user in there And doesn't matter if it is not connected right away with the IDP of OpenStack It will go over and just done replicated later So the users have these multiple ways of doing things you can go over and access on Through the unprotected app for a secure proxy on the secure proxy basically becomes the off to server Which go over and tell you okay now that you're authenticated with the IDP I'm gonna go around let you pass over or not to the specific resource that you're putting in you can do An SSO capable app if you are want to go over and implement your own SAML Client and connect it directly to the IDP is also as well possible or you can go over and access it Through the poly cloud I am client which in this case we're going to be using AWS or accessing to OpenStack through horizon We're gonna go through each of these settings and how they work on each on each of the use cases and then afterwards We're gonna see the like said the small demo Outside of this stuff the IDPs are usually monolithic applications They're not microservices, but extending them is for most of them They just basically use a database to store them to store the things in the user from actually the details of the user and Everything else is pretty much done at the application of the IDP So in crazy memory or and all of them are stateless because it's easy So scaling it is basically just adding more nodes into it So SSO with OpenStack here's a little quick how to do it Really fast. What's happening in here? OpenStack in order to do SSO you need to enable federation Once you have federation enabled you pretty much configure keystone you configure horizon you configure out melon The reason why we're doing it melon is because it's really straightforward Just works as a proxy for authentication between the identity provider and keystone itself At the beginning a few OpenStack releases back It doesn't it didn't support the OIDC or it didn't support anything else So you have to use out melon right now. You can use it if you want to go over and use directly with SAML I think and the latest in pike is gonna be supporting the OIDC But I need to double check that really quick But the usual workflow is that the user's logs into horizon Then horizon goes over and request Rare X to key cloak inside of the key cloak or the IDP the user authenticates The IDP connects to your LDAP or to your user database to match user passwords and all that kind of stuff and then Pretty much goes over and talks to melon melon and keystone They keep the communication between themselves in order to go over to translate from what is the IDP? SAML pieces into keystone You can see it as a translation between SAML and keystone itself and keystone roles and then once that is actually running Instructs horizon to go over and say, you know what let the user actually log in so in order to set it up You pretty much deploy Apache melon, which is basically just H2PD with the Apache melon the Apache melon model you modify keystone.conf local settings And then you bunch you run a bunch of open stack commands in order to create a the federate domain the project domain the federated group Add the role that you're gonna be using inside of OpenStack and then create the identity provider Set up bunch of mapping rules and define the protocol that the IDP is gonna be using for those mapping rules At the end I'm gonna give a kid have repository where it's basically all the config files So if you want to go over and try it out So all these pieces are required to just set up this this thing after you're done with it. You're gonna have The users being able to authenticate into OpenStack and All of the users are gonna be living inside of the federated domain If you want to go over and do another specific user or sorry another specific project you can go over and put it in place But you have to pretty much create also the other pieces that are basically assigning the identity provider to that specific federated project or the federated domain and It's basically just doing OpenStack roles groups and and users Over and over and over So once you have that done, let's say you want to go over and your company is gonna go and tell you Well, it's nice to have OpenStack But we also have AWS running because marketing is doing some website in AWS And we need to tie it up to the same authentication. Here's the tricky part. Um, how do you do it? with the IDP Pretty much you can just put it in place and tell it to use AWS I'm client for SAML in the case of a public cloud This is only for AWS, but it works with Azure and works with Google You have your IAM server You're gonna go over and use to create your identity provider in it and then create roles Exactly the same way as in OpenStack and inside of Keycloak you just define or inside of your IDP You define another client another SAML client that is gonna be doing exactly the same pieces But without the mail on that requires right so in this case the user logs directly into Keycloak in order to access I am The difference here is that um, there's two in SSO land. There's two options You can have IDP SSO or you can have SP SSO The IDP SSO is when the identity provider starts the authentication The SP SSO is when the service provider starts the authentication in case of OpenStack is Service provider SSO in case of AWS or Google or something else is gonna be IDP SSO so That being said the user logs into Keycloak into the IDP itself Authenticates and if that actually happens and is properly done It will the IDP makes a post to the service provider in this case I am and tells it you know what I have this user with this role That is already authenticated. You have access for it if I am replies back with the to the SAML post With the SAML XML post saying yes, I do have access into it Then I'm gonna give them access to the UI or I'm gonna give them access to the CLI doesn't matter which one is it How you set it up? Like I said you create another client in the IDP work every single application Whether if it is a public cloud a private cloud or another app, it's just a client that you're actually working with You create the SAML Keycloak client and then you configure your IAM to govern Match the role that you have and the group that you have inside of your IDP with the ones that you have in in IAM itself Once you pretty much set it up in that way you go into your public cloud provider and specify Okay, now I'm gonna give you the specific access to these guys like for instance This group in this role will have access to create instances or this group and this role will have access to Use database as service pretty much the same way that you do it already in in OpenStack The only difference here like I mentioned it is how the authentication starts in this case since Most of them all of them hold the public clouds are pretty much kind of like a closed source You have to go around and start the authentication from the IDP Once you have it up and running the IDP will just go around and check that SAML post That is actually doing and that is receiving in order to go around authenticate Everything else all the roles all the other specific pieces are actually managed by the service provider itself So those are the two examples of SAML But what happens if you want to go over and use on something different for instance, I know a two server Then here comes the other tricky part say that you're gonna go over and you go back to your CTO and you tell it, you know what I have OpenStack now running now I have the public cloud now running. So what exactly do I need now and you and he comes over and tells you well, we have these legacy applications running in Windows that is running on IIS server and we don't have authentication at all for it. So how do you're gonna protect them? Well, you can use Yes, so for applications in this case it's a little bit more complicated It requires a secure proxy or security proxy the role of the security proxy is to do the authentication Instead of the actual application What happens is that when you try to go over and log in into the specific URL that you're given of the proxy the proxy will Tell you know what you're trying to access these back-end URL or this application in the back You're gonna need to go over and tell me and authenticate whether if I need to let you pass or not on that case The proxy or the gatekeeper will go over and talk to the IDP pass over the user and Password and pretty much check the roles The IDP responds back To the gatekeeper or to the secure proxy and tells it you know what these are the roles And the user is good to go the proxy self goes over and has a small map that goes and tells you okay You can have access to this URL and you can have access to this or your or you can have access to this or your That way you can create a really granular Access into your legacy application without modifying the application itself Once the proc secure proxies good to go with your roles and the in the access that you're requesting into it Sends the traffic directly to the back-end application all of these stuff converts the The proxy the whole point is to create and all that to our resource server where it goes over and depending on what the And what the protocol is giving you on the roles and the access if you're authenticated the resource server goes on and tells you Okay, I'm gonna give you access to this specific resource Now what can you go over and do into it? You can pretty much just enable it to go and tell it Okay, all the application has access to Requires authentication or to the point where you know what these URL has access for the admin group These URL has access for the super user group These URL has access for development and you don't have to modify anything else. No, how do you do this stuff? You create your IDC client in inside of the IDP Then the things pretty much is just Confuring what is going to happen with that client and give them the sack back in URL What is going to show if the user is not authenticated from where you actually come from or what exactly paths are coming from? that are going to be authorized and Pretty much just remove the full scope if you don't want to make it like kind of like global authentication Then the second part is you go over and inside of your IDP you create your user and groups if you don't already have them in LDAP Maybe have them in LDAP. You can just let them actually go over It will go and grab them from there and pass it over and then you create the gatekeeper the secure proxy configuration Specify the same client ID same secret the discovery URL Which is basically the IDP and the target URL the target URL is always your back end application And and you then you specify which map and the map rules are going to be whether if this user with this group is going to have access to like for instance slash marketing site or slash Development site or slash HR and then you're good to go The same way that this stuff is working similar works for SSO and Kubernetes Kubernetes one of the things that I came out when he came out didn't have any authentication at all. It was just like Cool, we don't care about it. We're basically just running jobs on it But then came up open shift and open shift decided, you know what this is not gonna work at all and they started doing the Authentication themselves and they tried to push it back into a Kubernetes community But the Kubernetes community say no you guys are crazy. We're not gonna push it into it And it had to pass over like probably about a year or a little bit more Until the Kubernetes community and started doing saying, you know what everybody's looking for authentication So we're gonna try to put in there, but in this case on There basically have the options of doing cluster Role binding objects where you store what exactly which user no which user which group is gonna have access to which options or to which Actions in the class in the Kubernetes, but it won't actually store the users for you And so Kubernetes came up and say, you know what if you want to go over and do something You can put it on IDC and we'll trade it as an OAuth2 server Which is basically the same thing that we were doing for the secure proxy But in this case this secure proxy is Kubernetes itself So in order to do it and what happens here in this in in the Kubernetes world and the SSO Is that you go over and the user requests the token and Configures Q of CTL Q of CTL then goes over and talks to Kubernetes when you go over and say I'm gonna get all the pots I'm gonna be running to it Kubernetes has the ID and the information of your IDP itself And goes over and authenticates yourself and tells you I is this guy really who's claiming to be yes No, and if it's if it is then I'm gonna go over and look into my RBAC Which is basically cluster or all bindings or cluster roles Objects inside of Kubernetes and there is gonna tell you what exactly he has access into it That is pretty much the same kind like procedure that is doing them for all the other SSO implementations But is pretty much done by Kubernetes so in order to use it In order to make it simple Kubernetes went over and say you know what just let's do something really simple We can tie it to Google OAuth 2 we can tie it to github OAuth 2 to any other OAuth 2 Implementation that we can go over and put in place in this case Those implementations are basically just doing the authentication is not doing the authorization so we can use any IDP for it These quick how to do it. You can just put it the OIDC client Create the group for the cluster admin create the group and the group for the cluster users Then create the cluster role For a Kubernetes admin users and the cluster role for the Kubernetes users themselves You just have to pass the OIDC parameters into your queue of API server and restart and you're good to go The next time you try to go and log in into it. The Kubernetes will basically go or tell you if you don't have the Proper token I cannot verify who you are. So I'm not gonna let you do anything in there So That being said let's go around do a really quick demo and whatever we're gonna show up here I tried to finish it up the Kubernetes cluster, but I didn't have time into it So we're gonna do a small single sign-on on OpenStackLab It's basically just the VM running all the controllers into it We're not gonna care about like going over and creating VMs or anything like that The whole idea is just focus on the authentication. The same thing is gonna happen with AWS itself And then we're gonna do an app that doesn't have authentication at all that we're gonna put authentication without even touching it And all the configuration files you can go over and download it from that you'd have repository if you guys want to go over and do it It will work with everything the only things that I don't recommend using it for production instances You can based on that one to go over and do for production, but it's not gonna go around tell you configure your IDP for like HA in this way it's more about configure your IDP your client in this way to go Over and have the authentication So let me just go over and see how much time do I still have three Okay, I have 20 minutes So like I mentioned it before we're gonna be using key cloak because it's straightforward to go over and do it So on key cloak You have the administration Consult right so we're gonna add me in the end Secret I hope it's gonna work and here you can see you can have multiple realms each realm means that it's like a global configuration Inside of that global configuration you can have you can have multiple clients and multiple Identity providers if you're gonna federate itself or you can have multiple backends for User federation, which is basically means connected to your LDAP or to your AD on the clients Since we're gonna be using the same authentication for all of them We have there are a bunch of them. They're actually pretty fine But this is the one for open stack We have the one for coordinates. We have the unprotected app and we have the I am itself The fact that we have all the clients here means that any user that is tied up to this real will have access to all of this And not I'm not mentioning key cloak It will have access the same user will have access to AWS the same user will have access to open stack The same user will have access to the application that is not protected But it depends on the roles that you're assigning into it. So we over I already pretty much Put out some groups into here Which is the AWS user cluster admins for Kubernetes the open stack users We have a couple of users that we already the finals as well We have jdo and mdo and then we have some roles as well here, which has Why I'm not putting all the other roles Inside of here the reason is because like I mentioned it depends on the protocol that you're working on since the app is working more as an authentication Open IDC kind of like resource server behind the the actual secure proxy I need to say specify the roles in the IDP all of the other roles are gonna be stuck either an open stock or in the public cloud provider itself So in order to Go over real quick Let's just jump into the controller It's gonna open horizon Let's do open stack first We'll take a while once you configure federation You're gonna be able to see either you have so or your keystone credentials You have any other type of IDP here. We'll basically show it for you also as well Once you click if you go over and specify credential keystone credentials basic standard thing we're gonna put SSO You go and click connect and that's where Hold on I Need to go over and clean and clear the sessions. Give me a second From all sessions users sessions from all sessions Let's grab on private web browser New incognito window. Let's do this GPS slash controller The One of the caveats of having this stuff is that I'm like you saw before It really that you have to sync both of the timeouts from the From the IDP and your back-end service provider because if you don't sync them up Basically happens that it will go over and tell you, you know what I'm gonna try to authenticate it But the service provider still has a timeout So either you're gonna let you pass or we're gonna say, you know what you don't have access into it So let's see if we clear up There we go Let's do mdo So in the post binding sample post and now it's gonna take a while because like I said It's only one VM running all the controllers in it and now we have access into it like I said before Once you basically run the open stack commands you're tying up that specific IDP provider into your federate domain To a specific federated project You already have it will basically go around allow you to log into it This whole block Is the representation of the global representation of the user? There's Set up to go over and put it in there instead of doing that just show mdo But right now I didn't have time to put it in place But as you can see you can go over and tell it, you know what I'm gonna go over and sign out here now Um But now let's say that you want to go over and tell it, you know what Joe though J though You don't have access to this stuff. I still have time. Oh Okay, I'm right now She's not inside of the open stack users So he shouldn't be able to log in into open stack unless you put it in place Let's just give it a shot Let me just really quick mdo Sessions and log out Let's open another incognito Still say that's the only thing that I mentioned it Since still already in the back. Let me just do with this one with this browser Controller dashboard. Yes. I know it's not secure We're gonna add the exception confirm I can mention it's basically just a lab that we're gonna be using We're gonna be connecting to the SSO J. Doe J. Doe Log in In this case As you can see you're not authorized because you're not inside of the open stack users group Meaning that if I go over wait for the time out put it in inside of the open stack user to do So I'm gonna be able to just log in in there and we'll show up his own global user ID in that place So now let's go over and do something for AWS itself if we go back to the IDP You're gonna be able to see that there's a Hold on groups. There's an AWS users groups also as well. Let's say that now we're gonna J. Doe has access to it also as well Let me just graph this here. This is the URL that you basically go over and tell it Copy link address This is the difference between going over and doing an SP SSO and an IDP SSO The IDP will go over and tell you I need to go over and log in first to the IDP new private window in the case of the control be in The case of AWS since it's IDP IDP SSO you go first to the IDP Sorry in the case of opens like you go first to the SP to go over and do the authentication Now we're gonna try to log in here Goes back to your IDP M. Doe M. Doe and Same users in his password Will go over and actually go and let you now into AWS You don't have to go and have different users or create users locally in your public cloud provider or anything at all You'll see here that basically goes over and gives you The demo and the federated login and works similar way that opens that is basically another federation they're putting in place Now I still have time. Yeah, I do still have time So now let's say that that user is gonna have access to Another pretty place and our applicant an application that doesn't have anything in there. So doing the IDP with With the secure proxy what is gonna happen now? I'm gonna target the secure proxy first to the authentication and then based on that will go over and let me Log in or not on to the actual application if you go over and let's let's just look into Prometheus demo This is the site that I'm using for For testing this out. This is just a Prometheus server that somebody put out there They're using it for them. No authentication whatsoever. You can just target it directly Nobody's gonna know what happens or if you go over and see the I don't know configuration or some stuff like that But let's just go and put it in behind once you have it behind the Sorry behind the IDP server and the secure on proxy Let me just close a little bit of Things here You can go or enable the authentication for it without having to modify the actual site Let me just clear the users Sessions log out and then we're gonna try it out Jodos as well sessions log out Okay, let's see how we do with this stuff the secure proxy Sorry Vault one I have it running here On this board what is gonna happen here is that it will go over and try to Proxy everything into it right away. It says, you know what? There's no states on on actually how to do this stuff So I'm gonna go over and send you to the IDP provider that the provider will go over and tell you login So depending who you are and though though I'm gonna try to log in now you have the same Prometheus server with the access authenticated like I mentioned it before this basically is converting the Prometheus server into full OAuth to resource server so you can Literally protect it based on the URL. Let's say you want to have only the admins to connect to the config or access The config you just define that into the specific map roles that you're passing into the secure proxy Pretty much straightforward I hate windows But now let's give it a shot with the other user that we're actually having problems here with Let's try with Jato which she shouldn't have access. Let me just go in double check that we're actually put in here The demo is going pretty well So on the roles that I have here, I have an admin app admin itself Which is basically just who's gonna have access to that Prometheus server The user roles only Mdo has access into it. You can see here the user name. I've actually changed it now. It was kind of like Don't worry about it So now we're gonna go over and put it. We're gonna try it out Jdo who doesn't have Access to that piece. So let's give it a really shut really quick Let's just see if we can open a new private window here. So we don't have to deal with this stuff Vault one. Let's go to our secure proxy Jdo Jdo No, I don't have access At least now there's some way to protect something that you can have in the back Without actually having to modify or telling trying to figure out who built this stuff 10 years ago or who built the Building system. We don't have any figured out how to put it in there, right? In this case, like I said, it's really straightforward This doesn't matter if your application is running an open stack Or if it's running on a very narrow control by ironic or if it is running anywhere Everything is done at the HTTP layer without any interaction with the underneath application or where it's actually located As long as you pretty much go as long as you go over and close the access into it from any other side, you can go over and just set up the Sorry, you can just go over and protect it itself Let me just go and show you really quit How the config files are For this demo So like I mentioned it here, you have the files into it So for in case of open stack This is just really the configuration basic configuration Nothing at all. What you need to enable here and look for is to enable mapped and then on federation you have to Specify the remote attribute which is melon IDP because I'm using melon. You could use sheavelet also as well if you want to And then specify which is going to be the trusted dashboard. This means that which Trusted horizon is going to talk to you directly and then just template For you also sold callback if you want to use it Once you have the find out like I said, there's nothing else out there You just pretty much restart keystone and the configuration from that point of view is done. Then you modify horizon on horizon is it has a way much more Details on it, but the only pieces that you have to look for it is first of all To enable this part Which is telling it you're gonna enable SSO. It's gonna be using the map and That SSO and keystone credentials are the options that you're gonna be working on on the horizon dashboard Outside of that everything else like I said is basic configuration straightforward. Just follow up documentation Then the map rules. Sorry, then the federation. How do you enable these all these pieces? Well, you go over and you have two options in the case of key cloak itself It has a real cool Http decline that goes over and you execute it from where you're gonna be running melon Melon usually runs inside of the same keystone server because that way you don't have to go around to any communication outside of it Just pass over the melons the IDP server Basic just parameters and then you pass which are gonna be the keystone URLs that are gonna be protected that are gonna Working in the way of oh, you know what? This is the URL. I'm gonna have to Login into it in order to see whether if I have access or not So once you define those these are really straightforward There's nothing that you're gonna get over and change except for instance my SSO with your IDP name Everything else straightforward Once that's set up you go and just create the domain for the federation You create the project inside of that domain and then you create a group for that specific domain also as well You add the users. I don't know why I actually put in here. Okay. This one doesn't go You this is the one. This is the good one. Sorry. I'll modify that one and fix it up You add the group of those federated users into the federated domain and then you specify which is gonna be your IDP You create the mapping roles. We're gonna go through that map Johnson And then you create the protocol that is going to be talking between the map and the federations and the IDP provider All those pieces are required to just show up that a specific That specific flow that I mentioned it inside of the on the diagram for OpenStack Now the map Johnson are the ones that are actually doing the mapping between one thing and the other That's it. You don't need anything else I'm pretty much here. What is happening is that you're telling it okay for the group inside of this domain call it federated users The remote IDP which is working with melon will translate it for melon groups and look for the open stack users This open stack users is what you have in your IDP So in your eye if you're in your IDP you have public on sorry private cloud users Group then you just pretty much put it here If you need to add more groups, then you have to pretty much tie Or match each of those groups inside of your IDP to groups inside of with OpenStack Like I said is once you have that you're pretty much a good to go. You don't have to do or deal with anything else If you guys want to go over and see the other pieces We have also as well the like I said the Samo client Johnson and the Samo metadata for AWS Straightforward also as well. This is the IDP Samo client. We're just going to specify All the flags are going to be done by Samo Just modify this in the certificates Outside of that you're gonna tell it these are similar way that opens that has his protocols mapping to it The public cloud providers also have protocols map. This one depends on the public cloud So AWS might call it something The other ones might call it something else You can just go over into the Samo authentication on documentation for each of the public clouds to go around put it then You go over and if you want to go over and see the Secure proxy configuration. This is what is running here. I still have five minutes So we have first of all the authentication of the client set up, which is really straightforward You can just import this thing if you want to But what is actually looking here for is the redirect URLs We're just gonna go over and tell you where I'm going to be sending things No, and those things have to match with the gatekeeper config. Here's where it comes the tricky part All the roles that you define inside of your IDP. This is where you go over and just put them in place Mention it that anybody has and that is inside it or has to roll up admin. It's gonna have access to everything So if here if you put like slash config Admin only the admin has access to slash config if you put up here roll user on The I don't know slash graph only those user roles only only those users that have that role Will go over and have access to it Outside of it and anything else is really just discover URL is your IDP server Where it's gonna be listening you're certain your proxy what it's gonna be the website in case that doesn't have access So you can customize it and which is gonna be the backend app that you're gonna forward in the traffic once the IDP is actually logged into it Sometimes they go around ask me like why don't you just use this stuff for open stack as well There is this because you could probably just tie it up and protect horizon the same way But if you go around do it in the SAML option, you will go around tell it Now you have to make sure that you have the Open stack roles to do the order different pieces on like create bm's or anything like that and that being said Coordinates Same thing happens. Why is the client? The other thing is just follow up the everything that I put on the presentation And I still have three minutes. Well, I mean I'm done. So that being said, let me just go around here real quick Let me see what else I have here and This is pretty much it. So I'm running out of time real quick So, um, thank you very much any questions feel free to just ask me afterwards