 Hi, everyone. We're here to talk about Keystone Advanced Authentication. I'm Nathan Kinder, Steve Martinelli. We will give you introductions of who we are. I'm an engineering manager at Red Hat, responsible for Keystone, Barbeca, and other identity and security-related products. Upstream, for OpenStack, I'm a member of the OpenStack security group. So if you've seen a lot of OpenStack security notes, I publish those. You might know me from there. And I contribute to Keystone when I get time to do so. I'm Steve Martinelli, and Nathan's being a bit modest. He's a LDAP guru. That's why I put that in there. I'm a software developer at IBM. I work pretty much only 100% upstream code on Keystone, OpenStack client, and any other project that really needs help. I've been contributing since the Grizzly release. So just a quick overview of the agenda. We're going to do some level setting and talking about what Keystone does, what you're probably familiar with, and how you probably use it today. Start to go over some of the features, at least at a high level of federation and things, trying not to duplicate things you may have heard from all the other talks already. But then look at how you can actually use the functionality to do more advanced cases that are possible today. So using Kerberos in your environment, for example, how federation and how WebSSO actually works underneath things. Because with an understanding of that, you can see how you can start to plug in all sorts of different authentication methods, which might fit in your environment. So yeah, Keystone in two minutes or less, because hopefully if you're here under the advanced authentication methods in Keystone, you hopefully know what Keystone already is. It provides authentication, authorization, audit, and identity mechanisms for OpenStack. It's OpenStack's identity service. It has some federation capabilities right now, which we're highlighting in the keynote and a few other talks. And the big factor is that it's actually used by all the other OpenStack services. So if you're trying to create a VM on Nova, you have to go through Keystone first. And just a quick note about the identity API versus Keystone. I like to always put this chart in there. They're not the same thing. There's the identity API version two, which I think most people are familiar with. And there's version three, which is being actively worked on. We always get this question on IRC. How can I upgrade from Keystone two, version two to Keystone version three? But it's not really the case. Keystone supports both at the same time. There's just different API specs. The big differences between version three and version two are with version three, you have concepts of groups, domains, and federation capabilities. And as a result of those federation capabilities, we encourage everyone to start using Keystone under Apache or another HTTP server. Instead of running it under EventNet, EventNet was great for like prototype. It served its purpose. Let's go and move on to Apache now. Yeah, and a lot of what we're going to talk about requires you to run an Apache. So it's not even a should. It's a must for a lot of this stuff. And pretty much everything that we were going to cover is V3 related. Anyway, identity sources, there's a whole bunch of different ones, SQL, LDAP, and we'll get into the more advanced ones in a minute, but really quickly for the SQL ones, you're basically storing your identities in Keystone. Keystone is going to fire up a database table, just like it has database tables for your roles in groups and projects, but it's also going to have one for identity sources. So you're going to be storing your users in a Keystone database, which is kind of less than ideal, because if you're already in an enterprise environment, you're going to have an LDAP in there anyway. So you're kind of duplicating your effort at that point. On top of that, Keystone is not an identity. It should not have to be an identity provider. You shouldn't need password enforcement of, we don't really want to get into that game. We want to support OpenStack and the use cases of OpenStack and the other services. We don't want to have to be worried about password rotation or just things like that. And yeah, but on the plus side, though, it is really easy to set up, and it's great for development and test, and it had its time, but now it's on to more advanced things such as LDAP. Yeah, so as Steve said with LDAP, I mean typically most enterprises that are trying to set up like a private cloud, you're going to have LDAP of some sort. You're going to have Active Directory, you're going to have Free IPA, OpenLDAP, 3D9 Direction Server, one of the many. You already have accounts that are used for other things. You want to just allow those users that already exist to actually use your OpenStack cloud. So basically, getting away from SQL, not having another identity silo and just hooking into what exists already. So Keystone talking to LDAP should be just like your mail server or anything else that's using LDAP. It's pretty basic. I covered this at the last summit in terms of what Keystone does against LDAP. It's really just doing binds for authentications and very basic user and group information lookup. This is assuming you're only storing identity in LDAP, not assignment data, which is in SQL and should stay there. You'll see that in some of our other slides as well. So in terms of rights, what Keystone actually needs to be able to do in LDAP, it needs a pretty unprivileged user. It's not an administrator of LDAP. You really shouldn't be doing rights against LDAP and user management through Keystone. You have existing provisioning for LDAP. Leave that in place. Manage your group membership and everything there. Have Keystone just consume it. So a pretty unprivileged account is all that's required there. Keystone acts like a proxy in some regards and you're just passing the credentials along to LDAP. It acts like any other application with an email server or web application that's also using LDAP. Which is a good negative point as well, which isn't spelled out on this slide though, is users are giving their password over to Keystone and it funnels it through to LDAP. So in terms of advanced authentication mechanisms, it really isn't. It's really pretty basic. But it's a step in the right direction. But you're essentially allowing Keystone to get passwords and it's a potential for a man in the middle to sniff that and use it for something. One of the other implications is that if you are, we do actually allow right access to LDAP. And if you are doing this, you're actually storing a password in the Keystone configuration file, which is another, if someone actually gets into your network, they can see your file and they can see the password there and all of a sudden they can start writing to your LDAP, which is a huge security hole. Yeah, so. So SQL and LDAP, this is a really common request from a lot of people I talk with. They wanna use LDAP. They do not wanna put their OpenStack service users in LDAP. Usually it's not allowed. Some team manages Active Directory. They're not gonna allow your OpenStack service users in there. So that's been a problem a couple of releases ago before you had multi backends. You weren't able to do that. And this is a big pain point for people. So people want both. So with multiple backends, you know, as of Juneau, Keystone added support where you can have Keystone domains and you could tie each domain to a specific backend. So it requires V3 and use of domains, which may not be what people are used to working with, but it's required for this. And essentially what a lot of people wanna do is at least have one LDAP domain of their regular users and to have a SQL domain, which has your Nova user and your Heat user and all of that in there. And Assignments Day isn't SQL. And that's been working pretty well since Juneau with the caveats of you have to deal with domains and the command line usage from like the OpenStack client, very, very different if you're just used to using V2 and no domains. Yeah. I think it kinda makes authentication a little bit trickier. Yeah. It still satisfies a very important use case that a lot of enterprises were looking for because they didn't want to put service accounts in their LDAP. You know, we don't wanna tell the LDAP administrator to create a service account called Nova to bug off or something. But authentication-wise, this doesn't really change anything from what was said before. You're still giving your password over to Keystone and it's funneling it through to LDAP or in the case of your service users, the passwords are stored right there in the SQL database. Yeah, the only change to authentication is now you're actually just specifying the domain. And now to touch on the identity providers. This is a federation concept. So going away from LDAP, a lot of enterprises are gonna already have an identity provider set up in their enterprise. Think of this like, you know, your Google account, your single sign-on account. You want to leverage that identity provider because it's very sophisticated as support for a lot of, it's typically backed by LDAP or something else, but you don't have to actually see those bits. It kinda covers it all for you. And it's really nice, because from a Keystone perspective, we just want the identity provider to handle the authentication and we'll get back a representation of the user and we can decide from there how we wanna treat that user, what type of authorization he has on Keystone as a result on the cloud. And so typically an identity provider will speak either SAML or OpenID Connect, and those are XML based and JSON based respectively. And leveraging an identity provider just kinda makes sense. It felt like the natural progression of a way to do things in Keystone. Yeah, and the images on this slide make it look like it's social media based essentially, but SAML is pretty commonly used in the enterprise. You might have something like active directory federation services or Shibboleth or whatnot. So it's not just for, hey, I wanna log in with Google or anything like that. It has a good place in the enterprise role. Yeah, like specifically, I know internally we use SAML for a lot of this stuff. And whenever we wanna use any web application, we're going through a single sign-on experience and that's SAML based. It's a SAML based login. Yeah, so typically for like your public cloud case, people might wanna bring their own IDP. They have their internal LDAP. It's not exposed out in the public, but you have a SAML IDP and you can basically, when you set up your account with the public cloud provider, you set up a trust relationship at that point so you can bring your own accounts there and they don't have to be managed in the public cloud. So some of the use cases as to when you wanna use these identity sources. You wanna use SQL if you're just kinda prototyping stuff, developing, testing, you just wanna do something really quickly. It's probably the least amount of time to set up. It's really handy that way. I use it whenever I'm playing around with DevStack and I don't need to make any changes to the identity, to the identity related code. I'm testing something else. LDAP you wanna use if it's already in place in your enterprise. And using the service accounts there. If you can actually create it in your LDAP, it's easier, but I'm not too sure how many enterprises would be happy about that. You can, some people do. It depends if it's the same team that owns the LDAP server that owns the cloud. Most cases, people don't want to, but have been forced to in the past. Yeah, normally LDAP is a completely different team that's running it, so at that point it becomes messy. With multiple back ends, that's what's preferred for most enterprises. So exactly what we're just saying, you can't put the service users there so you wanna split them. So this has been, since Juneau, even before then, it seems to be the most desirable state for people running private clouds. This split back end approach. Yeah, even in pre-Juneau, there was actually some folks who had actually just created their own, they called it the hybrid driver. That actually did this, but it wasn't domain based, I believe. It was fallback based, yeah. And then an identity provider, you wanna use that if you wanna take advantage of the federation related features in Keystone. Or you have a non-LDAP identity source. I know there's some support for Active Directory in Keystone, but it's not as good as, say, LDAP, because LDAP actually has really, really great support in Keystone. Or if you're using something like MongoDB to hold your identities, it's not there. And just basically, yeah, if you really wanna take advantage of the federation. And one other thing, we'll see it when we go through the diagrams of how the flows work, but with federation, you are never providing the user's credential to Keystone. So that's huge, because Keystone can't then impersonate the user to some other service that might be using LDAP. We really wanna get away from seeing your password. Off plugins. Keystone actually supports a lot of different authentication plugins to interact with those identity sources. Most basic one is the password plugin. I think this is, if anyone spun up DevSec, this is the one most people are actually used to. You essentially go to Keystone with your password, gives you back a token, and you use that token, the other OpenSec services like Compute or Swift. Sorry, storage. And, but the token will eventually expire. And like we said earlier, Keystone is now seeing your password. And if you're using SQL, it's storing it in a hash. Or if you're using LDAP, it's just passing it through to the LDAP server. And one quick note about the authentication is that if you provide a project scope, you're gonna get a project scope token. If you don't provide that, you're gonna get a unscope token, which comes into play a little bit later. The token is very similar. Let's say you already have a token. You've authenticated and it's nearing its expiry time. You can actually use that one to get a new token with a new expiry time. Or like I said earlier, if you specify, if you don't specify a project, just the username and password, you're just gonna get an unscope token back. And we use this token authentication plugin to actually allow a user to see what projects they have access to, based on their roles. And then from there, they can get a scope token, which helps in tenancy. Yeah, I mean, think of the Horizon case when you go into Horizon and you have a whole list in the dropdown of what projects you actually have a role granted on. And selecting between those, it has to get a different token every time you make a different selection, basically, because the token is scoped to something. So you can, instead of prompting for a password every time you hit that dropdown, it's changing tokens. And then the external plugin, it's actually gonna use, it takes advantage of a lot of Apache HTTP servers. It's where a remote user environment variable is set. This is kind of where an identity is being passed forward. You've already authenticated with something else and you're sending an identity over. The same concept stays. You're gonna get back a token and you're gonna use tokens somewhere else. Yeah, and there are a few different plugins, actually, than just one external plugin. There are a couple different types, because you can have it scoped to a domain, for example, and set remote domain. But essentially, as Steve said, you have the web server that's running Keystone. It's handling all of the authentication external to Keystone and Keystone trusts the web server it's running in to say, look, I know this is who I say it is. Here, just go do what you need to do. It's a trusted source of identities. So with Kerberos, I'll give an overview of Kerberos if you're not familiar with it, so you know the benefits and then we'll get into how it all works. So Kerberos is a single sign on authentication system, both for browser-based, if you're using something like GSAPI Negotiate, or for command line-based clients as well. So it's based on symmetric keys, and the concept is very similar to Keystone, or I should say Keystone is very similar to Kerberos since it was partially modeled after that. Users get tickets and they present that ticket when they're accessing a service, much like you get a token from Keystone and you present that to Nova or some other service to actually be authorized to use it. These tickets are limited lifetime. By passing the tickets over, you're never sending passwords over the wire. And actually with Kerberos, even to get your initial ticket, you're never sending a password over the wire. The only time a password's sent anywhere is when you set your initial password for the whole Kerberos ecosystem. So in this case, Keystone never has knowledge of a user's password. It can't impersonate the user to any other service whatsoever. The terminology, and we're gonna see these in some diagrams. So the KDC is the Kerberos Key Distribution Center. A TGT is a ticket granting ticket. So that's used to get other tickets which are called service tickets. A service ticket is good for talking to one specific service. So a lot of infrastructures already have Kerberos, and you may not even know you have it. Active Directory has Kerberos internally. Free IPA has it as well. Or of course you could set up a KDC yourself. So we'll go through the flow and see how this looks from Keystone's perspective. So when a user initially authenticates, typically this is they come in in the morning and they log in to their Kerberos infrastructure, they send an auth request to their KDC. And they get back a ticket granting ticket. That ticket granting ticket is only good for getting other service tickets from your KDC. And so later that user wants to go and access their cloud, they need to authenticate and get a Keystone token. They pass their TGT to the Kerberos KDC and say I wanna talk to the Keystone service. And they'll get back a service ticket. And that service ticket is specific to this Keystone instance. And so then when the user goes to hit Keystone's auth URL and they have that ticket, we're running in Apache and we have something like mod-auth-cur or it could be mod-auth-gss-api. That handles all of the Kerberos side of things. So Keystone itself hasn't done anything yet. It figures out who the user is and then it's upsetting remote user. That gets passed through to Keystone. Keystone can do all of its lookups of what roles does this person have on what projects and it gives back a Keystone token. So what's nice about this is all of the complexity in this chart isn't around Keystone itself. Keystone doesn't even really know that it was Kerberos. So you can plug other things in here. You can use X509 client certs by using something like mod-ssl. And as long as you can do your mapping there in the Apache configuration and pass remote user through, Keystone's none the wiser. It doesn't care. And now we're gonna touch on the federated identity portions which seeing some familiar faces in the audience, I think you've been to some of the earlier talks around this topic so try and go at it a little bit quicker. But basically what you wanna do is, again you wanna set it up within Apache and you wanna use an existing identity provider and use and authenticate with that identity provider. Then you wanna have Keystone acting as just another service provider and run it under Apache and then install different Apache plugins such as mod-auth-shib or mod-auth-open-idc, something like that that can actually take advantage and understand what the identity provider is saying back to you. And a quick note about the terminology like we've already talked about is an identity provider in Keystone terms is a trusted source of identities. You trust him. If he comes back saying, this is Nate Kinder from Red Hat. He has the role of manager. You trust him. You trust that this is not faked because you trust the identity provider. A service provider is something that's already consuming, that consumes the identities. And the assertion is a way of representing the user. So if it's JSON-based, if it's OpenID Connect, it's gonna be JSON-based. If it's SAML, it's XML-based. And over here you can see the flow that's actually going on here. We tried to keep the images as similar as possible. But essentially the user's actually gonna hit a separate auth URL that is protected in Apache. And as a result, they're gonna go directly to the Apache module. In this case, it's ModShip. It can actually be ModOpenIDC. It could be, and then on the left side would be an OpenID Connect identity provider. It doesn't have to be a SAML provider there. But moving forward, since it's a protected path, you're gonna go right to ModShip. ModShip is configured to actually talk to the identity provider. So it's gonna go there. And the user's gonna authenticate with their identity provider, and it's gonna return a SAML assertion. At that point, the assertion, and this is when it actually goes back to Keystone. So ModShip will actually forward that assertion over to Keystone. So it, and that assertion is a representation of the user. So it's gonna say Nate Kander, role manager, organization Red Hat. Then from there, based on the mapping that you've created, it's gonna, Keystone is gonna slot that user into a group. And it's actually gonna pick out the username from whatever property you choose. And based on the group that he gets put into, then he'll have a role on a project or on domain. And from there, he'll be able to actually get a token. Yeah, and the important thing here as well is the assertion is actually being transformed into environment variables by ModShip or ModOIDC or any of the modules that we're talking about. So again, from Keystone's perspective, it just gets a set of environment variables that it has to be able to parse and figure out what to do with the user. And that goes through mapping, which I think is up next. Oh, yeah. Yep. And there's the whole mapping engine kind of happening right there. So like Nathan said, that the assertion was, assertion or open ID claim is actually gonna come in as environment variables within the request. You can see those on the left side over there, bottom left. Then based on the mapping rules that you configure, which are based on a per IDP and protocol basis, you will then output a set of a way to represent that external user. So I guess in this case, he's gonna be put into a group called, oh, just ABC123 apparently, we're not creative. And you can see that the OS federation, it's gonna actually, and that's part of the token part that he eventually gets back from Keystone, is it's gonna have a specific portion called OS-Federation, which shows that he's coming from an external source and an IDP. So you're gonna have the identity provider name based on how you configured it in Keystone. My IDP, the protocol that was used, and the groups that he now has access to. Additionally, the ID and name can actually be specified in the mapping on top there. So under local, local is a way of how you wanna represent the user, the external user in local Keystone terms. So that's how you're gonna represent them, represent the user's name, ID, domain, locally, as well as what groups he has access to. Yeah, so all this is also specific to the OS federation extension. I've seen people do some kind of odd half approaches as well. So if we look at the old external auth approach that we talked about where you just get remote user come through, there's no reason you couldn't use SAML to just set that. Maybe the assertion from your IDP doesn't provide any grouping information or anything of real use other than the user's identity. You can still have the users exist within Keystone, but just use a SAML or an OIDC module and not use OS federation and get single sign on at least. And so there's some interesting kind of hybrid approaches that you can do just by using external auth there without doing the full blown federation. So you can also take OS federation and do some really interesting things with it. So it's useful really anytime that you want to externalize all of the identity information and have it be provided. So federated LDAP is an interesting approach as well. It's not really federation, but there's not really a better name for it either. So Keystone right now with the LDAP driver has to deal with all of the logic of how to talk to the LDAP server. Deal with all of the LDAP operations which it may do a good job of performing. It may not do a very good job of performing from an optimization standpoint. All of that can be offloaded to the underlying platform which knows how to use LDAP for like system authentication via SSSD which is system security services demon. So basically we can take all of that LDAP logic and not use it at all from Keystone. SSSD itself is responsible for doing authentication against remote identity sources. So typically against LDAP servers knows all about Active Directory, Free IPA, any generic LDAP server. It handles caching of lookups which Keystone doesn't. So you have fault tolerance. The LDAP server is down during the cache interval. Your users can still authenticate to Keystone at that point. It's also going to be much faster with cache results. It has failover for fault tolerance. So lots of nice features that are very rich from an LDAP perspective. And so for integration points with SSSD, for a long time it's had PAM and name service switch integration for traditional UNIX Linux type authentication. But we added a D-Bus interface for applications to be able to query it through D-Bus. And the main usage of this is an Apache module we wrote called ModLookupIdentity. And what ModLookupIdentity does is if you have some other module do authentication and set remote user, ModLookupIdentity can take that and ask SSSD for the information associated with that user. What groups does the user remember of? Anything you'd get with a get-and-request on the system typically. And then expose those to a web application as a set of environment variables. So if you take ModOffAnything and ModLookupIdentity and you have an LDAP server, it looks exactly the way that Federation does from Keystone's perspective. So if we go back to our Kerberos case where we had that for authentication and I already had my service ticket and I passed that to ModOffCurb, it figures out setting of remote user. ModLookupIdentity is invoked by Apache. It calls down into SSSD. That has all of the knowledge of where the LDAP server is. Does the lookup and provides all of your variables there. And so from Keystone's perspective it still doesn't have to have the users created and you're using LDAP in a more federated fashion there. So it really simplifies Keystone. And then you get a token back. And so that would use all the same OS federation mapping logic as well just for LDAP attributes. And touching back to the OS federation feature, one of the other features that we had support for in Kilo was the single sign-on. So this goes back to working with Horizon and we had to work a lot with the Horizon team during the Kilo release to get this through because we made some changes to the Django open stack auth and Horizon. And they were very supportive of that and it was actually a good time to, it's actually a good learning experience, put it that way. And it's gonna provide a classic single sign-on flow from a Horizon perspective. And it's important because the user's gonna see something more familiar and that's where branding comes into place. They're gonna see the usual single sign-on login. And this is kind of what it's gonna look like in a really quick glimpse over here. You can still decide how you're gonna authenticate. You don't have to always select the single sign-on flow. You can actually go back to using your service accounts and your username and password there. But if you do actually decide to click on to the open ID connect flow, which is set up in this case, you're actually gonna see your branded login page like this. And at which point, once you log in, it'll go through the Federation Dance, which we described earlier, slightly different, which we're gonna talk about in the next slide. And you're gonna actually see that the username and the roles that he has, he's actually gonna be put in the groups. They have certain roles on projects, but the user ID isn't gonna exist in Keystone, but it's gonna actually be picked up from the identity provider. So similar to the OS Federation flow, and kind of similar to the Federated one, you're gonna have another source on the bottom here. You're gonna have Horizon. It doesn't have to be in the same Apache HTTP as Keystone, but it could be. So in this case here, the user's gonna go to Horizon, which is then gonna actually go to ModShip depending on what protocol you selected, which then is gonna go directly to the SAML IDP, and that's when the user has to actually log in. Once logged in, they're gonna forward the SAML assertion or OpenID Connect. It's the same thing as in the OS Federation example. It doesn't have to depend on SAML. It could be OpenID. Once there, the Apache module is actually gonna forward the username, group member, whatever, all the attributes it's gonna forward, and based on your mapping engine, it's gonna go and give you a token, and that token's gonna have the IDP information and groups. And from there, in this case, the user's actually a browser. It's actually gonna give that token back to Horizon, and that's how he's able to log in. It's Horizon, you need to provide a token. Whereas before, I guess, if you actually submitted your username and password, it did this kinda, it just went straight to Keystone, and then it got the token back to the browser. Yeah, so before, you were basically giving all of your credentials over to Horizon, and it would just get tokens and do whatever it needed on your behalf. But in this case, Horizon's really saying, go talk to Keystone, get a token, and give it back to me. And that's exactly what we're doing here. And the multi-factor auth, did you wanna talk about it? Yeah, so with multi-factor auth, there are a couple options today. There are more options that are being worked on going forward as well. So typically what a lot of people are asking for with multi-factor at this point is one-time password, you know, H-O-T-P-E-T-O-T-P, using a Yuba key, Google Authenticator, anything like that. So today with Keystone, you can, if you're using free IPA as just even direct LDAP, you can register users for OTP tokens. And the LDAP bind will allow you to use an OTP token as the password, essentially. And so really, for something like Keystone, it doesn't have to have any extra support for OTP. A user has OTP enabled, and that's required for their account. They just provide that as their password, and off it goes. So it buys you some good benefits over just regular fixed passwords, of course. And the guys, some of the Keystone guys from Rackspace actually have our proposal to have kind of a pluggable MFA support in Keystone. And just a few quick statements before we go through the questions, because we're kind of running tight on time. You know, the point of the presentation was that Keystone is pretty flexible. Depending on what you have in your enterprise, it'll, there's probably a way to authenticate with Keystone. And we encourage you to leverage existing identity sources. Keystone does not want to be in the IDP game. We don't want to be responsible for rotating your passwords or anything like that. And you know, the clients always need a little bit of help. Keystone client opens that client. They need to leverage the other authentication methods a bit cleaner. Yeah, I mean, that's always the challenge is, you know, the client side pieces have to know how to provide the credential, whatever it is initially. There are some different plugins for like SAML for Federation. I don't believe there's one for OpenID. No, we're working on it. Yeah, so that always seems to lie behind. That's an area where help would be appreciated, definitely. And it's funny because actually in the Federation flows, because Federated Identities, so browser-based that doing things from a command line is kind of tricky, because you have to be able to handle all the redirects kind of silently. Anyway, questions and hopefully some answers. If you could use the mic. I know it's in the middle of the room. Since I'm here first, I'm going to ask a question. And since you ended up on that note about CLIs and Federation protocols, we are here to help Steve, so just so you know, Fernando's working with you. And I'll try to join him. But we need that support very quickly. I think it's really important for Federation to succeed. Yeah, there's been a lot of work to make authentication pluggable from the Keystone client perspective. And so, you know, being able to easily write plugins for different auth types and just hook them in there is crucial, so. Yeah, it's definitely high on the priority list to make sure that the clients can actually consume these features. Yeah, thank you. Thank you. When you use orchestrations, why can't we think of 509s authentications? For orchestration, like heat? Yeah. Heat uses Keystone trusts. So it's sort of after the fact, right? So the user authenticates initially and goes to set up heat. They're going to have a Keystone token at that point and Keystone trusts are going to be created. So what's going to happen at that point is heat itself authenticates to Keystone as its service user and executes a trust to get back a token. So it's a much different flow than end user authentication. Right, and then in that process, why the service user cannot be used at X509? Yeah, so that's some of the work that's going on right now as well. One of the problems is a lot of the services over time have copied and pasted code for how they deal with authentication in Keystone and that's all being extracted and modularized. And that's part of the auth plugin stuff that I was referring to as well, is we're working to allow service users to use Keystone V3 and these plugins so you can say use a key tab to authenticate, use a certificate to authenticate. So there's work going on there as well, but yeah. Thank you. Yeah, we want to get those passwords out of files. I actually have a follow up to that. Is there a timetable for the service users to be able to use V3 at all? At least in June I had real issues. Where we are hoping during the cycle, Jamie Lennox on the Keystone team has been working very hard on that. He's made a lot of progress. But nothing kilo yet? No, no. Another question about the mapping flow. Is there, how is the logging done when you have federation mapping? Because I guess their logging is really important to get the actual end user hash map to a real user. So you actually, if something goes wrong, you know who actually logged in. So well, they're not actually mapped to a real user entity necessarily. It's computed on the fly. So they're mapped to groups. In terms of logging of what came in from the assertion, I don't know if we're emitting CADF for that. Yeah, we have notifications that are emitted for every time a federated login occurs. And it'll map to the user. What's in the payload of that notification is the mapped username and the groups and the identity provider that he's coming from. Okay. We should look probably at if there's additional logging you need of certain values from the assertion. I don't know that we're logging that. We don't log any other content from the assertion. And that could be something interesting to be able to specify pieces that are used in the mapping, not the whole assertion maybe, but. I know if you have it in debug mode, it's actually gonna spit out the whole assertion. So you mentioned the multi factor authentication. I'm wondering, for example, if I'm designing two project and each of them has different security levels, is it possible that for one project there's one factor, authentication is good enough. But for the other one, it requires two factors. That might be covered by what Rackspace was trying to work on there. And because in order to do that sort of thing, you need to have knowledge that OTP is actually happening within Keystone itself. And you'd have to flag that at the project level. I believe that they're recovering that, but it's something we can check with them. Okay, cool. Sounds like a good idea though. Okay. I'm not sure if this question is relevant to Keystone in terms of LDAP and backends, but right now, is there any kind of mechanism for a persistent kind of password or certificate for a VM or an instance to prove who it is so that for like logging, I wanna allow that VM to securely authenticate and not have to be a token that times out. There have been some conversations over the last two days with some of the Barber Can folks that we've been having. It's not really a Keystone thing, but basically being able to do something like when I create a VM to inject a secret from Barber Can on there, or generate and inject, but have it done as like a plug-in from Nova. The design's only just been like discussed in the hallways in the last day and a half, but there have been a couple of people asking for that. And then you can use that for basically identifying the system. I think we're getting the wrap-up music. If you wanna come up, we'll take your question. Thanks. Thank you.