 Good morning. How are y'all doing? There are some uncomfortable chairs in the middle right there if y'all want to find a spot or over there for the people in the back I know how wonderful those chairs are so it's great You must be here for open-stack identity Federation Which is good? We'd like to go ahead and start off by thanking a whole bunch of companies actually contributed to what we've done with an ice house Red Hat CERN University of Kent I represent Rackspace with Jorge here and IBM Brad and Steve a lot of a lot of good companies came together When we looked at how to do identity Federation what kind of protocols we should support how it would work from the API layer How to implement it and so this is a this is a story of great collaboration first off So who are we my name is Joe Savick. I'm Rackspace identity product manager We have Brad Topol IBM distinguished engineer Jorge Williams principal architect with Rackspace and Steve Martinelli Keystone core IBM software developer. There's a lot of other core software developers for Keystone in the room. You raise your hand Thank you very much Okay, so I know it's been a little while but how many of y'all remember on Monday when Troy presented this slide This is a pretty cool image, isn't it? You can kind of move the scales up and down and decide the cloud that you want to go To it's a perfect use case for a cloud broker use case, right? So if I have a workload that needs to be very cost efficient, but doesn't need to be that performant I could go to the cost Oriented cloud if I want something that I need the support there. I could go to the support cloud But we have these bridges and I don't know if you see them We have these bridges in between the clouds and that's kind of what we're talking about here today It's how to define those bridges in a secure way and it starts with identity Federation. So Fed or Washington There's a lot of definitions for what Federation is and again, we're concentrating on identity Federation So this is using one identity to securely access resources across multiple different clouds So you have the end points across these services within your service catalog It's maintained by a trusted identity provider It could be your employer provided credentials that you use and you don't have to re log in all the time So and enables single sign-on Why do we want to do this well and whenever you provision an identity from one cloud to another cloud or from one service Provider to another service provider. It's a security risk. It becomes a management nightmare as well especially when you have a whole bunch of users over in universities or in big corporations that move in and out and Fluid right? How do you know that you turned off access when an employee got terminated across all services that they had access to? But I want to concentrate on site on 0.5 and 6 the best test of interoperability in the cloud is to enable one identity Without one identity working across multiple clouds It's a big blocker you have to be able to change your clients to be able to work with multiple tokens representing access to the different clouds You can't burst as easily from one cloud to another cloud or from your dedicated hardware and your data center over to a public cloud So we need to be able to solve for identity Federation first in order to be able to test the true interoperability So when we talk about identity Federation, there's a lot of what do you support this protocol? Do you support that protocol? One thing I want to get Make clear on this slide is that it's extensible. We built it to be extensible the Federation protocols We have SAML with an ice house We're working on open ID connect and we can also do David Chadwick You mentioned AB FAB if we know we you can absolutely commit to that and the Contracts are built to be extensible to be able to handle that R2D2. Yes The big picture. What do we have with an ice house? So this is this is what ice house delivers the prerequisite is a Patchy running my ship many people already run a patchy around Keystone today so that shouldn't be too much for a problem and R2D2 represents kind of the employer portal or the access manager So you would log in with your employer provided credentials into this access manager you would be able to click on go to cloud and It does a handling for you of SAML So they Sam will handshake with identity provider and sending that information off to a Keystone cloud in Or to be able to get back an unscoped token representing access to that cloud And then you do what you normally would do at that point you would get the projects and domains that you have access to and you would go ahead and request a scope token for access to that cloud So this is great. This enables you to be able to use your employer provided credentials against the cloud But that's not cloud to cloud identity Federation before we get to that I wanted to let you know that we're kind of talking future state here. There's design sessions going on This is kind of an idea that we have on how it could be implemented. It's not set in stone. There's a blueprint down there Feedback is appreciated I encourage y'all to attend the design sessions or hit me up or any of the other gentlemen up here on stage with me to provide feedback So the big picture we covered what R2D2 does right well What if you go ahead and get a token from Keystone 1 cloud and you want to use it against Keystone 2 So you would want to be able to go ahead and send that token to Keystone 2 to provision a server This could be for autoscale reasons. This could be for cloud bursting. It could be for cloud brokering There's a lot of different use cases image portability. There's a lot of use cases that this could solve for So how does a key? How does cloud 2 Keystone 2 know that you are who you say you are and you have access to what you Say you have access to At this point Nova just handles it as if it was it just any other token So no change within Nova to go ahead and send that token back to the local Keystone to be able to validate the token But at that point there's a decode token origin and I'll jump into that where Keystone 2 defines Okay, well this token was issued by cloud 1 the Keystone 1 and needs to go back there in order to be able to Validate that that is an accurate token. There's a Federation protocol handshake that happens there You remember on the on the other side There was a protocol handshake in between the identity provider and our 2d2 there's now one in between cloud 2 and cloud 1 So what do I mean by decode token? Federated token needs to include information about where the originating authentication actually occurred needs to know okay Who where did you get this token? I need to figure out if that's a trusted place that I could go to and there's a trust relationship in between Clouds, I'll jump into here a little bit as well One potential solution is to have this within the token metadata and includes originating identity provider the protocol that they support and the subject or user that came across in the token At this point I gotta say that I like the work that we're doing with catf It really supports the auditing use cases that we're looking at and it's kind of important to be able to have that So that way we could trace from cloud to cloud to cloud What are users actually doing? So how to trick clouds trust each other so it's important first that clouds indicate what they support So I support a nova instance or I support the Swift API So that way they could that you could build a service catalog that represents a total scope of what an identity could do across these Clouds, but it's also important to be able to set up explicit trust And there's trust as an identity provider from one cloud to another and then there's trust as a service provider from one cloud To another and so in this case cloud one trust cloud to as a service provider So that way any identity is authenticating It could be given those endpoints surface by cloud to And on the other hand the cloud to trust cloud one as an identity provider So that way when it comes across as an assertion as a token comes across and it had decodes originating identity provider and knows where to go back to and trust that that's that's a solid point or originating identity provider point so when we connect all these together eventually we start forming this cohesive federation of rebel alliances right where we could speak different protocols to be able to authenticate to a cloud get access across multiple clouds and and In many cases there aren't any client changes that are absolutely Actually needed you see Chebacca right there using the standard username password as they do today and not needing to federate directly into the cloud Okay, right now. I'm gonna go ahead and turn it off to Brad Topol to talk about what was delivered with a nice house Great. Thanks, Joe So getting started here There is a quote from our fearless ptl. Dolf raise your hand. Where are you? I can't find you That's amazing. My eyes are terrible Go ahead and stand up Dolph Dolf is a who leads us on what we're doing and this is his quote OS federation extension allows Keystone to consume federated authentication Via an Apache module for multiple identity providers mapping federated attributes into open-site groups based based roll assignments We're gonna go through that and actually put that into English now The Keystone team and we've got all the cores there and we've got lots of folks here we Really really believe in stakeholder driven development and we were very lucky that on this particular topic We were honored to have Merrick Denny's Merrick stand up, please He is one of those super users that the caricatures are there Merrick is at CERN This was one of their key requirements. And so as the development has been ongoing, you know You're getting the validation just in classic agile development of of being able to do this So thank you, Merrick, and we're gonna keep doing that and for all the stuff that we do in Keystone We love having stakeholders like Merrick. So please when you have stuff, you should know the right names to contact Dolf That's others. We this is how we like to do this. So please So here's what we're gonna go through and talk about We're gonna talk about the the new APIs and why you need them. We're gonna talk about the magic, which is the mappings And then after that I'm gonna hand over to one of the the key developers Steve Martinelli And he's gonna get into some of the the authentication details and how they're different One thing to point out is most of you use Keystone I'm sure use the the Python Keystone client We're actively and actually Merrick has helped coding this We're actively putting a lot of what we're gonna describe here into the client. So that will come soon It's a work-in-progress patch, but I'm gonna go through and describe things using the existing restful APIs and Merrick You had an existing version of your client that you used for your work and that'll get into the client Hopefully quickly But what do we need to do here? Well the first thing we need to do is You're gonna have different identity providers. We need to find a way to register them. So very simple restful API here to register You've got a description for your identity provider. You get to give it ID nice and easy Similarly your different identity Providers can have different protocols. You could have SAML 1, SAML 2 Again, you know the classic open-stock model We believe in being pluggable on lots of options to meet everybody's needs and so here you can see there's a nice simple API Where you can describe the protocol and you look, you know classic restful API you point out the IDP ID and then you can have the protocol ID and then You know register the values We're gonna get into this in a little more detail But the magic to making this work is to be able to take the information that comes from the identity provider typically in the form of things like SAML assertions and map them into the Keystone world So that we can do the right things set folks in the right roles in the right groups and The the magic that there was a lot of work done and and was to provide a robust Robust mapping layer to accomplish this and lots of iterations on that And I'm sure it'll continue but but but that's sort of you know another piece that you need to get registered and You register it with a mapping ID Okay, so let's kind of level set and and talk about classic Keystone I love giving presentations on classic Keystone because the the model is Really straightforward and I get up there and I say listen you've got users and You typically map them to projects used to be called tenants via a role and that role is just a label and All the other open-stack projects take that information and they have their own policy engines And that's how they decide whether you're able to kick off an instance or attach storage or whatever you want to do so That's great and it works, but as we start moving to federated identity There's a few problems that we're gonna have to address The first biggest one is you know in that model that I just talked about you had the users You map them via roles to the projects the users were in Keystone They might have been you know coming from LDAP, but they are essentially in Keystone and federated identity Those users are no longer in Keystone That kind of makes that original classic mapping a little difficult So that's one of the big problems that we had to solve And really what we do is now what's coming from the identity provider is some notion of attribute values typically called assertions and we're gonna take those values and Map them to groups So we you know, maybe not know exactly who you are But based on the attributes that you have we know to put you in a group And then we can do classic Keystone Which is groups have the notion of roles just like the classic model of Users and now we got you in a group and the groups got roles all the rest of what I described in classic Keystone is gonna work so You know, I don't know if any of you've done this, but you can go this is a little bit ugly But you know here you can create some groups and down here you've got the you know You can put people in different groups And that's what you're seeing some examples there and we're associating the groups with a role So we're you know setting creating the groups and associating roles on the groups just like you would just see on the users I know it's a little hard to read, but that's the big concept there and Now things get a little interesting We've got the notion of Samuel assertions and so we've got some examples here We've got one that for whatever reason has like a name a username in it And then we've got some that were you know some attribute values for different types of identity groups I think that you know, it's typically the more common case And so these are the kind of things that are gonna flow from the identity provider That we're gonna need to map into Keystone's world Right now to create the mapping There's a lot of details on this and docs on all the different features. They really worked hard a lot of iterations to make this very flexible And we'll continue to improve it if we missed a few boundary cases. Let us know but the the idea here is From the remote identity provider There's going to be certain attribute values like I showed on the previous slide one example was you know the type IDP group and here we've got a mapping that says hey if that attribute comes in with the value of IBM regular employees Canada map it to a group ID and What happens is this information is going to get into the token that's created and that's how the rest of Keystone works to Do its roles and what have you Similarly, we've got another one of those down below, but then we've got another one That's interesting is maybe you need the username So if any of you know me I'm very big on cloud auditing. I gave a presentation earlier in the week on cloud auditing You're really going to want to know the information coming in from those Identity providers to be able to figure out who's getting authorized. What have you and so we've got a capability here where if the identity provider provides something like Subject as the type which is essentially the username we can map it in the token to a well-known value in the token called name and Since that value is going to get Populated on I've then get access to it when we plug in our auditing and we can keep track of wonderful things like who's getting authorized Okay getting in I'm gonna hand off on the really hard details to Steve Martinelli before he falls off the stage Thank you Steve. Thanks Brad. All right So thanks Brad for explaining all the mapping portions of the new and the new APIs But what do we actually want? We want a token back from Keystone this way we can use that token To use it in Nova or sender or any other open stack service So really brief briefly I'm going to recap What was the old Keystone authentication model? You would have a username and a password you would authenticate with Keystone and get back an unscope token, right? Once that happened you would then go in query. It's to find out what projects or domains you have access to Once you find out the project that you want you use that ID for the project along with the unscope token and Then make a scope token request get back to scope token and then you can start using that in Nova or sender what have you? All right, so as Brad already touched up on this there's one big issue in a federated Keystone environment and that's that The user doesn't exist in Keystone. He exists in an IDP somewhere else So as such we've had to make a few tweaks a few new APIs But we want to keep the process as similar as we can to the old non federated Keystone process So you want to keep the unscoped get the project ID? Issue a scope token request. We want to keep that essentially as similar as we can So part one We want to get back an unscope token So over here the user is going to perform a get or a post request on the URL that you see above there and What's going to happen is the IDP is actually going to go and intercept this request and then prompt the user to log in and Once the user has been authenticated the IDP is then going to Send a SAML assertion over to Keystone which acts as a service provider in this case Which point the once Keystone actually has the SAML assertion? It's got all the data it kind of needs at this point if you look at the URL it's got the IDP it's got the protocol and It's got the SAML assertion you can find the mapping that you want to use that Brad talked about by looking up the IDP and protocol and Then you can put the SAML assertion all the attributes you can push them all through the mapping engine and then in the end The mapping engine should output group IDs and a username so you can see over here We actually go ahead and stick those values into the unscope token So you can see over here the user ID would would be Steve Marr and the group and we have a new OS federation kind of object there And we stick the group IDs in there as well Why we want the group IDs is part 2 So again keeping with that same non federated Keystone model We want to find out what projects and domains we have access to So we're going to go ahead and use that unscope token that we just got back from step one And we're going to use that to query against a few new APIs This will then go and look up what? What projects or domains the group has access to and by proxy the federated user would also have access to The output of these things should be very similar and you'll see them in v3 slash projects or v3 domains All right, so once we figure out the target project ID or domain ID We have our own scope token from step one. We got to now scope it here we can actually leverage the existing off tokens URL and It should be pretty much business as usual at this point. We just have to change I think the methods portion we change that to SAML 2, but otherwise it's more or less the same We keep the scope Format the same we put the project ID in there And we put the unscope token ID in the ID value of SAML 2 and the output it should be a fully functional keystone token It's gonna have the extra fields that you need like the user value over there. We forgot to update that should say Steve Mara and But otherwise it should have the project ID there too and the roles that you have on the project and It should act as a fully functional keystone token you can use it on Nova or sender or any other open-sac service and We're taking that as a success So this ends the presentation. We're gonna talk we're gonna have a few minutes for questions However, we have additional design sessions coming as Joe had already talked about Federation's not over we have a lot more work to do We're gonna do some cool stuff in Juneau and we have some design sessions coming up today and one tomorrow The main ones today at 130. It's in room B 306. Please drop by However, I think we're taking a few questions now, right? Okay, thanks Adam come on Adam I Took notes Okay first on Translating what you're saying into English. I'd like to point out that we first had to translate it from the Queen's English Think we all should give a big. Thank you and round of applause to professor Chadwick who started driving this effort. Oh Six years ago eight years ago before open-stack So thank you very much for absolutely for being a mentor to all of us on this Agreed. Thanks. I Want to just make something more explicit you kind of alluded to and then you said much ship for now It actually doesn't have to be much shibboleth in front of Apache has to be something that will pass through environment variables from Apache to The back end and and much it was what these guys have been working with and made sure that we work So we know that that works, but There are several other Apache modules that work in similar ways with other things and so the Federation Mechanism is not limited to working with much shibboleth. There's one to make that explicit, but you did yeah allude to it on the PKI thing We can actually pull the signer information out of the token. So I think that's be where we start working on that And the idea of federate federated keystone to keystone I Think we can potentially make happen without having to phone home to the original keystone for every authentication And then That's actually I have a question here that I you answered afterwards. So job guys. Thanks a lot. Okay. Thank you Thanks, Adam question Lovely comments Yes, I had a question about other clients such as jclabs or fog do we Do we reach out to those communities when we make changes to the keystone APIs like so that they can get caught up with the changes You mean to the client? Yeah We obviously You know let us know we want to make sure we're not breaking anybody and give best practices if they're not using the standard client. So Sure, this was additive in nature. So it wouldn't be breaking J Clouds fogs or anything like that. But yes, I mean added functionality, right? Yeah, it's a functionality. So Yeah, we have to be there before they can actually start using it So it's ready for any jcloud or fog developer to start picking this up and run them with it. Okay. Thank you Any other questions? One more Will a v3 federated token work against the v2 keystone So it's a standard the back-end validation process for it was still work I don't think you'll get back the federated context when you validate the token So in the v3, is that right, Adam? v2 So yes, but in the construct of the v2 response you wouldn't see that that token was federated So it's not really good for your auditing records to do that Yeah, but I mean if you have clients that are still using v2 and you have keystone v3 And for some reason your patches have been accepted the atrore. You're still using the v2 client Sure, the token is just the same right and it's a string at the end okay, so if I get a all right, so if I if I If I manually get a Federated token using curl for example, and then I pass it into a client that's written for v2. That's not gonna work So I think to sum up the answers Ideally use v3 if you're gonna use v2 it might work you might run into some weird problems Okay, thanks Thanks, Adam. Thanks Morgan Have a question about them keystone to keystone Authentication in this case I was wondering where you set the rules for the users in the first case on on the second case to keystone and another question is Have you thought about the authentication from not from the chrome online client, but from an Web service or observer like a rights or whatever It's possible to have the ship or authentication in this case That's it work Okay First question is is where does the actual token scope come from when a role is associated to a user and it's the wherever They token was issued so in that in that diagram that I had it would be keystone one that initially issued that Token now what triggered that keystone one to issue the token could have been a federation That occurred with employer provided identity provider or it could been just username password being passed into that keystone one At that point the token is scoped to that user to the roles and and and then it's passed elsewhere Does that make sense? Yes, but in this case the keystone one can decide what the user can do on the other clouds Right because you decide the rules on the fist keystone Sure, or hey, it's quite different from Yeah, you should be able to create mappings that sort of limit the scope of when a user can do Between one cloud and another and to sorry It isn't actually there at the moment isn't the keystone to keystone But when it will be there it should be quite easy because the token that's issued by keystone one will go over to keystone two It will be validated and then Attribute mapping will come in and it will map it from the stone one world into keystone two world And the user will then have his projects for keystone two. Yes, you have a double map It all depends if he logs in with username and password at keystone one There'll be no necessarily any mapping on keystone one if he comes in federated They'll be mapping on keystone one and then there'll be addition mapping on keystone. Yeah, and I and ideally to answer your second question We we'd like to be in a world where if you're doing this service provider type federation You're you should get a service catalog that includes Additional endpoints that may be in another cloud So from the perspective of horizon, you know Nothing really changes aside from the fact that you have additional endpoints that you can provision resources into so the the part In the slide where we're doing this communication between keystone kind of hides away some of those Federation You know protocol Implementation stuff and to the user you just send the request and treat it as if you would anything else That makes sense. I just want to add this is ongoing So we really want to work with you to get this right exactly so this is not you just gave us a few things right come back To us, you know who we are and let's do this together so we get it right right Yes, sir I'd like to go back to your to the discussion you had about auditing and the interest in auditing so in the In the case of trying to track a given Action within the service to a particular user. I Think I heard you say that part of the SAML Attribute you'd pass over it would be the user ID Or username or yeah some user identifier So talk about okay, so now that in the SAML attribute the user name comes over but because keystone doesn't know who that user is Nothing else does either so what happens then right so the SAML the attribute comes over Gets attributed and mapped in appropriately, but what do you do with that user ID in order to facilitate the rest of the audit trail? Which identity provider so we've got an identity provider and a user name and Those are things that we could fill in our cat F event record with Now if there's something we need to refine on that that if that's not good enough You need to come talk to us and we should talk about what we should be adding there So that we make that much easier and and in easier to have that bread crumb back to really what happened I mean, that's the best. That's our straw man. And but if you can help us to think of what's better Please do so again, maybe I'm missing it But so it sounds like as part of the cat F aspect you would So let's say, you know, I use that token to now go create a spin up a new server Does that attribute somehow follow in well, it's in the token right so it's in the token We should be able to pull it out and with our standard Auditing be able to say this thing was started up or this thing was attached by this user name from this identity provider I mean that that's my current thinking okay, and it's just because it's past this metadata It's not the metadata doesn't mean anything but because it's passed along you can then audit and report on it as well It meant something in the context of the original identity provider. So so hopefully that's enough Okay, it's TBD to see how well we do there, but but we'll work on it together. Okay. All right. Gotcha. All right. Thanks. Thank you I saw on the roadmap I think you had to off to is the Are you considering the use case that I should be able to log on to I'd like to log on to horizon? using my github credentials So you're talking from a strike to use case of delegation for a wealth to and what we're looking at is open ID connect Which is based on no off for the actual authentication federated authentication Yeah, so if I want to if I'm interested in or I'd like to work on that use case Is that part of what you're thinking about? Is that something you're open to is that? in the roadmap So I would I would put that under the delegation use case as opposed to a federation use case But yes, it's something that many people are interested in and then this should be part of keystone roadmap overall I think I think you did describe a federation use case You said you want to use a credential from a different identity provider to log into a cloud and that is federation And so yeah, you should be able to do that Yeah, I mean I imagine I'd have to probably have an account for If it's a if it's a real cloud where I'm going to use resources that are chargeable I probably have to set up an account somewhere But you need to set up a relationship so that they did that you know that and that's an out-of-pound Relationship that's going on between the two providers If I set up Dev stack and turn on github integration should be you'll just go in yeah, that would be cool. All right. Thanks. Okay No other questions. Alrighty. Thank you. Thank you very much