 Hi, I'm Darren Tartino. I'm a Principal Solution Architect with Red Hat. I'm going to talk a little bit about OpenID Connect using Azure AD as the authentication back end. I had to use for a customer in two different things. So, I talked about connecting it to OpenStack and then also with OpenShift. My first thing is one of my team members on my team always likes to start things off with Marvel Studio style, he says. So, which is a demo at first and then a demo. So, the first thing I'm going to do is show, so I'm logging into my OpenStack environment using OpenID Connect. So, OpenID Connect. We're tied, I'm tied into, actually it's not probably me for my login because I logged into Azure before. So, it just has the, it's just cached. I probably should have picked the log out. It prompts me through my Red Hat login and then redirect me back to the horizon dashboard, which should hopefully be told. My environment cracked earlier today, so I restarted it. There you go, look at that. So, I logged into my own project here on OpenStack using Azure AD. The process that we just, that you just saw was the OpenID Connect process. Basically, when you're opening a browser and you navigate to your cloud via OpenStack or OpenShift. The dropdown showed OpenID Connect, so I selected that as my authentication mechanism. And when I did that, it redirected me, it would directly redirect me to Azure AD and it would probably for a username password login. And then there's two factor authentication, obviously. There's a dialog that would come up that says that you can send to passing permissions between the two, between Azure and your cloud. Tokens are issued and then your browser once again redirected back to the cloud, validates the token and then takes you to the secure page of the browser. So, this is the workflow that we kind of worked through here. So, when each of these points are talking to each other, when the private cloud is actually talking out to Azure, it needs the connection details. It needs a client ID and a client secret so that it can authenticate who's actually reaching out to it. When the user connects Azure AD, you provide your credentials and also your consent for the redirect permissions. And then finally, Azure needs to know what the redirect URL is to go back to the cloud that you came from and then it provides the access token. So, those are the key communication aspects that you need to be configured when you're actually configured OpenID Connect with either OpenStack or OpenShift. So, when you go into Azure AD, what you do is you create what's called an application registration. So, the first thing you do is you'll go in, you'll select Azure Active Directory and when you do add, there's enterprise applications and app registration. I'm not an Azure expert. I don't really know why, what's the difference between an enterprise application in there or an app registration. I'm going to guess that it's some maybe service catalog type stuff. I've not really used Azure other than to use the Active Directory aspect for it. So, when you register an application, you give it a name and then you can actually specify the different people who are actually allowed to utilize what the registration you're doing. So, when I created it, I just said it was single panning, use my Active Directory configuration. If you're a Red Hat employee and you actually do have a login to Azure portal using your Red Hat user ID, and you can actually do all this to test or demo for users. Finally, it needs to provide the redirect URI. So, what happens is OpenStack when it reaches out to Azure and says, when it redirects you to Azure to login, it also provides what the URI then wants you to redirect to after a successful login. So, Azure ensures that redirect matches the initial request that comes in when you first log in. So, then after that, you're going to need a couple of things. So, you're going to need the client ID information, which is that long string there. The tenant ID is actually part of a URL string you're going to need. It's actually, if you look at the endpoints, the tenant ID matches the URLs and the tenant endpoints. So, you're going to need the endpoint for the last endpoint there, the metadata document. So, you're going to need that so that your cloud knows where to redirect to. And then, you're going to have to do client credentials. So, you can go into the client credentials. That's where you create your secret. If you're doing this, if you've never done this before in Azure AD, when you create the secret, copy the secret that time, because after that, you'll never be able to see it again. It's hidden. It's obscurity. You can't see, but you can see the ID. You get a secret, and then you have an ID to that secret. The ID is the secret you can always see. You can never see the secret again. So, definitely copy the secret when you create it. And finally, you're going to put in the redirect URIs. So, for OpenStack, actually, when I configured this, when I filed the upstream docs, the upstream docs, as we put in the one URI there that I have locked off there, it failed. I went and redirected back to OpenStack, because Azure said that it was missing this other URI, which I went back in and added, and then after that, everything started working. So, on the OpenStack side, I did this deployment using TripleO. TripleO includes a template called Enable Federation, and all of this information, as you can see within your matches, all the items I pointed out, a couple of exceptions. So, the one thing you'll see there is an ID, see crypto passphrase, like the fourth or fifth bind down. That crypto passphrase is an internal OpenStack thing. So, when OpenStack is actually communicating from node to node within the infrastructure itself, it actually encrypts that traffic using that passphrase. So, that's for internal communication within OpenStack. The other thing to point out here is the OpenIDC IDP name, Azure. So, that mapping, that needs to match your mapping, where you do your OIDP mapping, so that you're mapping Azure to it at an OpenID endpoint. So, before when you first go to arriving, you get the basic to the username and password login afterwards. Like you saw, we have the little drop-down that says OpenID Connect. You go through it, click that. So, this is what it should look like if you're not already logged into Azure. You'll get prompted to pick your account, you choose your account. You request permissions to be able to see your basic profile and be able to send the information back to OpenStack. And then, no failure. So, there's another part to this with OpenStack. So, what we did here is we created the identity provider as far as Keystone be able to go out. What's missing is the actual configuration data within OpenStack that the IDP information in OpenStack were to be able to map back to projects within OpenStack. So, you'll wind up with this 404, could not find an identity provider as your... So, in order to actually go through this, what you have to do is you can create a domain and associate that with this identity provider. So, this way, anyone using Azure ID would be able to log in and utilize and log into this domain. Second thing is you run OpenStack Identity Provider 3. I've archived all of these items that basically match what was back in the YAML file. So, when you guys look at this deck later, you can do that. You can figure out what's actually supposed to come in there. So, basically, you put down all the steps on the left and then all the steps on the right. And after you do all of that, then you'll be able to actually log into OpenStack and get the provided dashboard like we saw before. So, that's OpenStack. So, OpenShift. So, with OpenStack, you've never deployed your below. It takes a little bit of time to deploy. That's what I'm putting in lately. So, instead of actually demoing, configuring that, I figured what we can do is actually configure OpenShift, an OpenShift environment that does not have OpenID Connect right now. Configure it and have it update and authenticate and then we'll be able to log in. So, sound good? Yeah. So, log in to OpenShift. I don't know if many people here use OpenShift. Maybe some people right now have. But anyway, so we'll log in OpenShift. We're going to go down here to administration and go to the cluster settings. We're going to go over to configuration. So, what we're going to configure is the OR. So, by default here, there's no identity providers listed. So, we're going to go ahead and add. And we're going to select OpenID Connect. And I'm going to name it as your work. So, the client ID, copy that. And when I was doing this demo, I went back to get the client's secret for this part and realized that I could no longer see it. And I sure fortunately it's in the triple-optic templates. And then, finally, we're going to put in the issuer URL. So, it made the changes. So, what we're waiting for here now is the authentication of the operator to rebuild. And it's taking the new configuration. So, once it's available again, we'll go back to the... So, actually, while that's going on, I'll switch back over and I'll just log out. So, it can't be reached because right now the cluster operator is not available. So, a couple of things. So, while this is going... If you set this up in your enterprise environment and you are going to use Azure AG, you need to realize that Azure AG doesn't exist on your own premises. So, if you guys are connecting... If you guys have processes or anything like that for you to be able to reach out, if those process servers go down, you just lost all of your authentication to get back to any of your platforms. So, I set this up at a customer and then it was out of the proof of concept. So, it was a lab and they had a single proxy server and someone kicked the power plug on it. And they weren't able to connect and they thought it was a problem with the product. But, in reality, it was the proxy server that was down. So, you do need to keep that in mind. So, while we're waiting for this to restart, does anyone have any questions? Yes. I recently heard of another really good solution from the NASA guys. Because they utilize it from... You guys utilize Kerberos, right? The high-end to Azure AD said you can usually Kerberos log in, be able to log in this way if you lose that connectivity. It doesn't matter. Because you guys are using Azure AD, but you're tying that into a local... We're not using Azure AD. Oh, you're not? We have our own internal. So, we're doing the open AD connect pieces. We played around with Kerberos back in. We set Kerberos as off-fault for Keystone. Okay. At one point. So, we can do... We've done both. I see. Okay. So, you're gonna use... Okay. I thought you guys were going through to be through another, like a third-party proxy for authentication using this. Okay. No, it's... So, yeah. So, then yes. It's NASA's internal. Okay. Okay. All right. So, our authentication cluster operators says that it's available. So, I will refresh this. And so, now I have Kubat and Azure. So, anyone wanna take a guess if this is gonna work? It's not. And here's why. So, if you remember, one of the things I've mentioned earlier was that you have to populate the redirect your eye. Otherwise, it will not go... It will not send you back to the cloud that you were using in the first place. So, we can easily fix this. So, when I did the open stack, that's the same message that I got last time in regards to not having the proper URI, and I have to go back and edit. So, I'm logged here into Azure. This is the authentication registrations here. Here. And then we go to the redirect. And if I come back to that page, just change here. Copy the Azure eye. I go here. Okay. It's a live demo. I think it went smoothly. Switches, it's live. No, I'm gonna try this one more time. Since I've already logged in, it came up. So, you can see that it's not really smoking mirrors because there's my login right there, which is my red hat login. So, I think it's just hashed in here that it's not gonna let me in. So, that's all I did was open another window and log in. So, yeah, it actually worked. So, and that's basically all I had. So, any questions? So, when we went through setting this up, for me, all of the magic was in that mappings.js on the bottom. Does she have the butts around with that at all? Yes. Because that was the super kind of like, wow. Actually, thanks for putting it on. Actually, I'm missing a slide. So, yeah. So, there is it. So, the third bullet down here is creating a map, creating a map, creating the mapping.js on file. Is it maybe called rules.js on? I'm pretty sure it's mapping. I added it somewhere. I'll find it. I'll add it to the deck. So, the mapping.js on file, what it does is, it maps the values that come back from your authentication point back to variables within opens after the user. So, the user. And the privacy. Oops. Yeah. Yeah. So, it's highly configurable for the purposes that I needed to do it for. It was just getting them access to the environments and stuff. But yes, you can get pretty extensive with it and do different types of user mappings and stuff, which users get mapped to which projects and stuff. You can get really in the weeds, but yes. And trying to get that right. And doing something where you try to have multiple projects with multiple people and trying to get them in the right projects could get a little bit hairy. So, what we do is we map them to a group membership in Active Directory. And then we map the group name to a role in OpenSec. So, just being in the right group in AD, entitles you to automatically have this role in this project. Okay. This is pretty sweet. Yeah. But I know if you're doing, if you're just doing straight up LDAP authentication using AD and you don't put your scoping properly, you will kill your AD server. We've had customers, basically, because it'll return more than a thousand. It'll look through everything if you don't configure that properly. Anything else? You said you were starting to work on the CLI. Oh, yes. So, yes. Thanks. So, I mentioned that the other day. So, the concept also I asked if it's capable for the CLI. And yes. You can use the CLIs. You can use the CLI. And basically, I have been working with the LGN documentation and I got up to the point where by entering OpenSec command, it pops up a window, brings me to Azure, I log in, authenticate, comes back to the command and tells me I'm not allowed to do what I was trying to do. So, there's still a stat missing, but I've been told by our engineering team that they had it working and it does work, but pretty much every developer has told me that. I won't point that out. I'm just super curious when you get it working too, because I think you've got to step further than I have. Yeah, I feel like I'm close. So, once I get it working, I will definitely. Yes, that was our default point at Kerberos. We already have a Kerberos taken on this laptop, so we can set that identity as well. Right. Yeah, it's a stupid email. I'm Darren at Red Hat. And then I'll make sure I get back to you when I get the thing working. So, one thing that's interesting about that is when you really dig into the debug logging on this, ultimately, after the OpenID exchange is successful, all it comes down to is a keystone token issue. And if you can snipe that token somehow and pull it back and set that as OS on this core token in your environment, then if you're there, you have to work and see it live. Right. I feel like doing a TCP doting Red Hat and that sort of thing. It's got to be an easier way. But if you come to that, I'll see you in the script.