 Hello. All right. Welcome, everybody. This is an update on Keystone Federation and We have lots of speakers on this talk. Most of them actually decided to show up. The famous guy, I think, is gonna make a dramatic entrance. Well, we'll see what happens there. Always exciting. About the presenters. Morgan, who will be here, or will never hear the end of it, is a master technologist and HP. We have Mareeq Deni. Thank you. CORE for Keystone. We have myself, Brad Topol, an IBM Distinguished Engineer. We have Steve Martinelli, another CORE for Keystone, and we have Rodrigo Duarte from Universidad Federal de Campina Grande, and of course, Mareq is from CERN. You want to cheat him there? CERN is so much easier to remember than the other one, but Okay, so agenda. We're gonna cover Keystone. We're gonna cover it quickly. We'll talk about the differences that people don't realize between the identity API and Keystone. We'll do a Federation overview. We'll talk about all the cool updates we've been doing to Federation, and you see those here. Then we'll talk about how Federation is sort of rolling its way out into some of the distros and, you know, what vendors are supporting it, and then we'll talk about future work and what's left to do. But first, I'd like to say thank you to all of these folks that you see here. Sometimes we kind of rotate. We can't get all of the wonderful folks that have contributed this effort up on the stage. You know, we've had help from folks from the University of Kent. We've had help from Adam Young at Red Hat. You know, we've had help from Joe Savick sitting there in the front stage who's done this many a time, and you're really one of the original drivers of this work. It's so nice of you to join us, sir. Really? I just thanked you in all your contributions. I'll add one more. I'm making one of my co-speakers late. Thank you. Alright. So this has been a, and of course, we've had newer folks come on board with CERN and Urusidad Federal De Campina Grande. It's really been a wonderful collaborative effort across the community to deliver some of the more complex functionality and tying in our stakeholders directly into the work to make sure we're hitting the mark and providing functionality in the space that we need it. So thanks to all of these great organizations working in this space. Keystone in two minutes or less. So Keystone, it provides it's our identity and access management service. It provides authentication, provides authorization, provides audit, basically provides a notion of identity. Also provides a service catalog and service discovery. Really important part of OpenStack. I go talk to lots of customers. Every enterprise customer we talk to, when you go and you first get and start with OpenStack, you're typically hit with, well, how do I do OpenStack security and how do I integrate it in with my existing identity provider, identity server, my LDAPs, my active directories? How do I do this in my existing protocol based for federated identity, federated identity managers, all these types of things? Key strength of OpenStack Keystone is it's very flexible and configurable to be able to integrate with whatever the customer has. This has been one of its strengths. So it does support a variety of identity providers. It even supports a variety of token formats. It's got the little tokens. It's got the bigger tokens that are cashable. It's got now some that are in the middle that are sort of just the right size because people didn't like too little or too big. So, you know, we're here to please. That's what we do. And so, you know, from that perspective, used by all the different services, we kind of like to feel that, you know, it's kind of a big deal. So, all right. On that note, covering some things. Some people don't realize, you know, Keystone is the project. The actual API is what we call the identity API. And we've gone through sort of, there's two main versions of this, right? The original version that pretty much everybody got used to was the V2. And we added a V3. And then the V3 is when you start seeing things like the notion of domains and groups. And we changed tenants. The name from tenants to projects felt like projects would be a little more easier to understand. That's been kind of a, you know, pulling people out of that tenant thought and making it projects. And so, all the new functionality has been going into the V3 API. And that includes Federation as well. So, you know, your Keystone typically, you know, it's still a lot of folks using V2. But when you want to start using the newer features, you need to start moving up to the V3 API. And we've been working a lot with a lot of the other projects to make that happen. Another key change that's worth pointing out is how you deploy Keystone. Originally, you'd run in sort of standalone in what was called a ventlet. Nice, lightweight, easy to go, easy to use. But when it became time to grow up and you need more security and was time to grow up and you need to start using more of the Federation-based protocols where, you know, you have, you know, the extra libraries you need for Federation like Shibboleth, it really became smart that the proper way to run this was as part of Apache and using the mod WSGI, I'm just running WSGI to run it as part of Apache. So, that is now the official supported way to run it. It's been added to DevStack. That's the way to go and you'll be a lot happier running it in that deployment. So, on that note, I'm gonna hand over to Steve to cover Federation. Thanks, Brad. So, Federation is kind of, you want two kind of distinct entities to kind of collaborate and work together and most of the time when people think of Keystone Federation, they immediately go for federated identity but that's only one part of it and when you break federated identity up, a lot of people start to think of it as identity providers and protocols and those are the two main aspects of it. To briefly define those, an identity provider is a place where a whole bunch of users are stored and you really wanna use it for authentication. Previously, Keystone was kind of handling all this itself and people were saying that Keystone's acting like an identity provider and that's not something we want because most enterprises are not gonna wanna run Keystone as an identity provider, they have their own. Oftentimes it'll be LDAP or Active Directory could be anything, it could even be MongoDB and you need an identity provider to get that structured way of organizing users and then output it and represent a user in a very specific way and that's where the protocols come in. The two main ones that we've been focusing on in Keystone are SAML and OpenID Connect, SAML being the tried and true XML based way of representing a user and it's been out since 2004 whereas OpenID Connect just had its 1.0 spec at some time in late 2014. It's JSON based, which makes it really handy for working in Python. However, it is a bit more web oriented whereas SAML kinda had, I think, a slightly better support for non-browser flows. But when we talk about federated identity, I think this is what most people are used to seeing, your single sign on Google account, you wanna use Google or Twitter, LinkedIn instead of creating a new user account on some other application. And that's pretty much like the most common use case that you're gonna see, but that's just one use case of federated identity and federation. But it is a very, very handy one. So yeah, and like I said, these users can be stored in whatever format you want, they can be MongoDB, LDAP, Active Directory, whatever, it doesn't matter. And again, like I know at our enterprise sign on, we're actually using SAML, but if you're using Google, it's gonna be OpenID Connect. So we've been actually trying to, like making strides toward federated identity in Keystone for a while now. And you can see in Icehouse, we actually started by doing some basic support for federation setup. Just we wanted to create an identity provider resource, a mapping resource, protocol resource. We actually created the first iteration of the mapping engine to translate the attributes that you're getting from your identity provider to Keystone attributes, because those aren't gonna be one-to-one. You're gonna need some way of an engine that can take, if I'm an admin at Pepsi, and what does that mean on Keystone? What role do I get? And the basis of that is you're gonna be put into a group, and that group is gonna have a role, and that's the main basis of the mapping engine. Then in Juneau, we started to play around with the Keystone to Keystone support, and that was actually highlighted during the keynote, the 9 a.m. keynote one on Monday. And that is kinda trusting two different Keystones and allowing a user to go from one Keystone, and then getting a token from one Keystone, and then getting another token, and using that token on another Keystone that's completely separate. And that's kinda meant for a burst scenario where you wanna be able to use resources on another Keystone. And then we focused on actually improving the clients because as usual, they're all lagging behind. And in Kilo, I'm actually gonna highlight. All of us are gonna go through some of the improvements that we've been doing. But why would you wanna use federated identity in Keystone? You could have a non-LDAP source, Keystone for the most part provides great support for LDAP, but if you're not using LDAP, the support's a little wishy-washy. And also, you probably already have an identity provider in your enterprise, so you wanna leverage that. And plus, it's really, really cool. So updates federation. We did quite a few updates to federation in Kilo release, but I'm just gonna be talking about the web single sign-on. And this was pretty cool because it was, like I said, single sign-on is what most people think of when they think of federated identity. And it was really cool to get this finally in because it's visual, people can see it. They can actually, it's easy to understand. It's something that the community has wanted for a while. So together with the Horizon team, we actually worked a lot with the Horizon team on this. And it was one of the first times I've had to deal with cross-project collaboration. And it took some work, but we got it done. And what happens is, you're gonna hit the Horizon webpage, just like you normally would. And then from there, you can actually list the different ways that you wanna authenticate. So you can go through the normal username and password flow, or you can select one of the other protocols. And each protocol is a default identity provider associated with it. So in this case over here, say it's OpenID Connect, which is backed by Google, because that's how I set it up. If you were to click Connect on that, you're gonna see the Google branded login page that's gonna redirect you right to it. And from there, once you sign in, you'll actually be redirected back into Horizon. And that's actually the top right screen of Horizon, where you actually see the username. And in this case, it's something at accounts.google.com. And this was important because branding is important. People wanna see a familiar login page when they're logging in. It's kind of awkward to type in one identity provider's credentials into an OpenSec branded webpage. It was kinda weird. And even then you can tell from the URL, it's not what you're used to. And we created a bunch of extension documentation for this, and CERN actually is using it in their production clouds right now. Anyway, I talked about the mapping enhancements is, I think, Merrick. Thanks, Steve. So I'm mapping enhancements. You can see that it can kill. Just a short reminder what the mapping engine in Keystone is, it's our secret weapon for OS federated workflow. So it's something which actually, just like Steve explained, translates the credentials which are put in the similar session or the OpenID Connect claim into something which is usable for Keystone. So in that case, it would be user ID, user name, or it's domain, and the groups this member will be, and the groups the user will be member of. So as I said, this is a very powerful module. We are trying to add the new features because it will ease the use cases and it will make all this configuration even easier. So during the Keystone, Keylow cycle, we added a couple of new features. So one of them would be the ability to identify the effective users by name and the domain because up to before Keylow, you could only identify the users by the user ID. It was done basically for being able to map the, to map to the local users. I mean, you may want to this, I mean, it's a great use to, it's a great way to use your corporate startup or IDP to provide the first class authentication result. Like, you know, it may align to the policy that your corporation, that you have to authenticate through the IDP. It's just leverages the, you know, authentication to the first class identity provider. If, how should you build your mapping rules? Just use the name and the domain of your effective user and just specify any other domain than the federated. Yeah, another enhancement was the, I think the service domain which is called federated, which means that if an effective user is a member of the federated domain, he is an FMRL user. So, I mean, you know, the users being FMRL is the core design decision which we made in the OS federation. So, this is how we just started thinking about this. And this is, as I said, this is a service domain. So, basically you cannot create this domain. You don't have to create this domain before you, before, you know, configuring the OS federation in OpenStack. But you also will not see this domain when you lease all the domains. You cannot delete it. You cannot alter this domain. Another feature is the white listing and black listing in the mapping rules. This is, again, this was requested for so-called item use case, and then we're going to history. This is, it's extremely useful when you're dealing with some complex parameters like the list of the groups which are issued by the identity provider. So, for instance, Adam wants to create his, you know, he wants to reuse his groups from the LDAP. He wants to create the groups in the Kiston configuration and then he wants the users, you know, from the LDAP to become members of this group. So, instead of just creating the mapping where he maps the groups from all the, all the combinations of the groups from LDAP and the local groups in Kiston, he will simply just pass all these, all those groups and use the black, and use the black list or white list. So, you know, you always want to need to be able to define the maximum set of the groups. This user will become a member of. So, this is an example of the very simple mapping set where you have just simply, yeah, you will basically map all the groups which are stored in the parameter called remote user groups. You're not blacklisting anything. You could probably blacklist anything which is like the negative filtering and you could use the white listing for the positive filtering. And then, you know, the mapping engine will try to match all the existing groups in Kiston. Okay, so Kiston, Kiston, again, thanks to Morgan, you'll know what's that, I guess, I suppose, but again, some small refreshments. So, it basically provides the underpinnings for interoperable hybrid cloud enablement. In Kiston, in June, we just, you know, we just provided the experimental implementation for Kiston to Kiston. Basically, what to do, you get your token, you swap the token, you know, for the SAML assertion, so basically the other format of your identity and you just send the SAML assertion to the federated trusted cloud. You get the new token back now. You're good to go and use the remote cloud, like you authenticate with the remote cloud. We leverage on the so-called IDP initiated SAML workflow, so you always go to your local Kiston which happens to be the IDP identity provider in this case in the SAML terminology. And it's, Kiston to Kiston basically provides the building blocks for the interoperable hybrid clouds. So we'll for sure use it for other services and, you know, not only Kiston to Kiston Federation, but also we want to build some image sharing services and things like this. So this was Juno. In Kilo, we focused on hardening Kiston to Kiston support as well as, you know, as far as of Kiston, the Kiston to Kiston is marked as stable, so you are good to go and Morgan proved it. You can actually use it and it even makes some movies. So it's a very important industry, probably more useful than the physics. Okay, I didn't say this. I wouldn't say that. Yeah, no, it's not, I just, I roll back. Anyway, anyway, yeah, and in Kilo, we fixed some critical bugs and focused on usability. So basically we just fixed a major bug where Kiston was unable to correctly validate the signature of the SAML assertion. So it was extremely, you know, a severe bug. Thanks to HPE folks, we are now safe and secure. We made using Kiston to Kiston easier from the client perspective, where we just dropped the dependency for the XML. The server side just does the hard work for us. So client just needs to fetch the SAML assertion, which is wrapped with some SOAP, some blocks, and it just passed to the remote service providers. We also decided not to piggyback on the overloaded region terminology, which brought us to adding some new whole set of objects which are called service providers, and Rodrigo will tell you some more about service providers. Thank you, Marek. So improvement that we made in Kilo release was the addition of the self-provided concept and to represent these kind of remote trusted peers. In June, as Marek said, we tried to overload the region resource, but we figured out that we need a lot of more information to properly represent this external service provider. So as of Kilo, we have this new API to manage this new type of resources. Besides that, we added the list of service providers in the, alongside the self catalog in the token. So once a user requests a token from Kiston, the list of service providers that he can access is inside the token. And as Marek explained as well, you won't be able to use your Q-hand token for your original Kiston to in this service provider cloud. You would need to request a semi session from your original Kiston, and present this session to the service provider, and then retrieve a token that will work in this external cloud. You can see on the right how it would appear in this token. And it has all the information that the client needs to burst into this external cloud. So we also added this API to Kiston Client, Opusheq Client, so operators are good. It's easy to maintain and update this new resource. And of course, if you have more than one service provider in your token, the whole list will be returned, and this will be used for clients like Horizon. You would be, Horizon would display the whole list that of service providers that the user has access. Another update was we added the to Kiston, the capacity to generate ECPS sessions. ECPS stands for Enhanced Client Approxies, which is an extension from the semi to protocol. So one of the differences is that in pure semi, this external semi that we use this web SSO, this semi session is encapsulated inside of a sub-envelop, and it's really useful. This extension is really useful when we are trying to run a non-browser workflow, like running the protocol in a common line interface. So today, Kiston can return a pure semi session via the OSFD2 endpoint, and this new rapid ECP rapid summer session via this other endpoint. So since Kiston already has this capacity to return the ECP session, clients do not need to worry about getting the original session, putting it inside a sub-envelop and then send to the service provider. So clients do not need to worry any more about an XML or import XML libraries. So Kiston to Kiston Sunday becomes a lot easier in this release, and it's even possible to write a proof of concept where you can access your service provider via your own horizon. So using federation. Can I use it? I think that Morgan showed yesterday that we can. And in the university, we had this user case where we had like this Juno deployment with Kiston and Swift, and we wanted to add this new cloud, and you wanted to, that the users from this new cloud to have access to this previous deployment. So what we did was we used Kiston to Kiston and now the users from this Kilo cloud, new cloud has access to this old Juno deployment. Everything works. So I'll pass to Mark that is going to explain the CERN user case. Yeah, so CERN uses the identity federation for a long time. We have lots of users coming and leading our organization every month. So it's really easier to have one single point of identity rather than just multiple websites or services, adding and removing users locally. We are using the Microsoft Active Directory and as well as the Active Directory federated services for this configuration. We have roughly 12,000 service providers inside our organizations. I mean, I'm not talking still about the cloud, but it all aligns to the one setup. We internally use the Shibu as a service provider. So ModShip, yeah, of course we are also, I mean, we then just came up with some idea that probably just using also the identity federation in the cloud would be extremely useful. We just drove requirements by filling some gaps. And one of those gaps was lack of the web SSO at the time of Icehouse and the later releases. We basically sketched up some kind of a proof of concept which actually worked pretty well and then it was used for the Keystone team to actually build the upstream reference solution which we are just having right now on the GitHub. And we, yeah, just like I said, so when you go to the open stack to CERNCH, which is the endpoint for all the users using our production cloud, it will be redirected to the, our identity provider service webpage where you are supposed to authenticate yourself. So, and we've been running this configuration since September 2014, so it's, it works pretty well. We also support OpenStack Client, you know, as a CLI, which so we also feature the, you know, V3 identity V3 API as well as you can also authenticate via the Kerberos. So please go ahead and feel free to use it. It's proven and tested. Welcome. So, as Merrick was saying, is it real? Yes, absolutely. You've got many different organizations already using it. Can you use it? Well, of course, we proved earlier this week that you absolutely can. As of the time of the keynote here, federated identity is available within the HP Public Cloud. It is definitely for proof of concept purposes. We have a variety of things that go along with, you know, accessing how we handle which customers are, you know, work with it, that type of stuff. It was done for proof of concept, but we got all the work into, to get it as a feature that is possible within the Public Cloud. Successfully used with digital film tree, as you saw, and we definitely have the target of making it generally available across the board in an upcoming Helion release. When it comes to the IBM front, I'm gonna let Brad talk about this because somebody might, you know. Sure, I understand completely. Thank you. So we do have at our booth a demonstration of the federated identity and that work shows two clouds working together with it and a little bit more. It uses some patches that haven't quite merged yet, but allows you to do a little more on the UI side, which people seem to like in the demo. We're gonna have this available in our on-prem offering, the IBM Cloud Manager with OpenStack in June. And third quarter of this year, we're gonna have this available in our private dedicated offering. So the offering that is, we manage it for you, but it's your dedicated cloud. So you're starting to lay the groundwork there for folks that wanna do on-prem and then burst up to a dedicated cloud. And so yeah, feel free to come by for a demo. And as said here at the bottom, just keep in mind that it isn't just the big organizations, it isn't just what you've seen here at Summit. We've got many, many different people working on this, many people successfully deploying it. HP, Bluebox, IBM, Red Hat's been working on it and you saw the slide earlier on everybody who is planning on supporting. So what's left to do? We have a lot of stuff still along the way that we need to solve in the grand scheme of things. We need better functional testing, clearly having a great test suite that tests everything end-to-end. Make sure that we have real setup of active peers, we don't have this kind of a test mock-up solution, truly testing end-to-end for the service provider mode, the identity provider mode and simply the clients. But what do we need to make that happen? We need a lot. Currently you need at least two different keystones, different hosts or at least different endpoints, but that gets a little bit weird as you may have found out if you try and change things too much in OpenStack on the endpoints. And you can't rely on just a unit test. I mean, unit tests, what are they? They test that your logic works, that's not what we're talking about here. We've got preliminary work, it's underway, we have a lot of people focused on making sure that we have these functional tests and we do need to take care of getting even the base framework for these types of functional testing taken care of. The other side of it is what would be an identity provider you can stand up quickly. If you've looked at the documentation and what's been described here, ModShib and Shibboleth, that's not a small amount of setup, it's a whole service, it has XML requirements, certificate requirements. There's a lot that goes into it. Maybe we should look at something else. Well, we have something else we're looking at, that's the Pi SAML 2 library. It's very basic, but it should be sufficient. And we definitely expect to have a full set of gate jobs validating everything for the federated services in OpenStack, federated entity, including hopefully having third party CI for the identity providers that we don't run in gates. More proprietary, it'd be like the Tivoli's or Active Directory, that type of stuff. No, is it? This one me, really? No, I don't know about this one. I don't remember this slide. So how do you deploy this? Well, you can deploy it with Chef, Ansible, Puppet, Saltstack, but we don't really have any of those tools built. What do we need to do? We only need to have them support all the crazy configuration stuff for the Apache modules, getting Shibboleth set up. I mean, I know that we have some of the stuff internally for HP because we've deployed this, but it doesn't mean that it's out there and Open Source we're working on getting that out there. The, we would definitely want some volunteers. Please join us if you have expertise in this stuff. We'd be very happy to have you. Especially like the really creepy demon looking cats. So at this point, if you have any questions, please ask. We might even have an answer for you, but no guarantees on that. And use the mic if you guys want to use them. And please use the mic, we have. Well, pass one of the mics up. All right, all right, all right. You know what, I am making, go on your response to handing this out. You see that? That's delegation. Leadership. That's what the PTO does. Not Federation, but it is delegation. Go ahead. I have a question. Would it be possible to somehow backport it to the ice house or should we weigh two kilo? We can't. The, the size of the feature set that goes into the Keystone to Keystone stuff and the amount of options and changes that had to happen to make that apparent backporting it at least in the upstream stable branches is not really feasible. We typically don't backport features. I think what would be more practical for you to test and I'm not suggesting to do this because you avoid your warranty is to try running just a kilo Keystone if you need to leave the rest of your cloud alone. The rest of the cloud should work with an upgraded Keystone. There's nothing in Keystone, Keylo that will not run at your no cloud. But like I said, you avoid and you warranty. I can, Mike and Mike too. Okay. You go, you go. He's been waiting. Okay. So during the time that the like doesn't work, I will ask my question. So my question was about the web SSO. So you've put a great screenshot about how it works with. So I guess that the service provider has to know the list of IDPs beforehand. So and get the metadata really frequently. I have a question. Is there a plan to support the discovery service or? Well, the discovery service is a part of the, I think it can be used as the third party piece of software. I know Shibola just, when you read the docs from the Shibola website, they usually say, okay, so here's something you can use. I mean, they even provide some kind of a discovery service software. So I think we can try it at the moment, leverage as much as we can, because I think those applications are doing the great job. I mean, is there anything which you're still missing or? You would like to have it somewhere directly in Keystone? Yeah, I would like to simply use the discovery service that I already have instead of implementing it again with Keystone, but I don't know if it works. You can't. In fact, that's exactly what CERN is doing. Okay. It's just, it's just SAML. Okay, okay. I have another thing to add. It's not really a question. It's about the fact that you need help about some things. So basically we're speaking about Chef Puppet et cetera. And we have a project that's for a company that is basically building an IDP as a service. So we will have some kind of Ansible recipes to build Chebelet as a service. And so maybe this could be great for testing. Anyway, that was my two cents. All right, sir. Your other question there? You've been waiting. So first of all, congratulations for getting there. It's an important milestone for the OpenSec community. However, my question is actually not related to federation and it's a much simpler use case, if I may, having all of you there on the panel. The question is how about enabling customers, people that are using OpenSec Clouds to define their own roles and within their own roles, their own policies. And say, hey, here are my CZ admins. They have access to my production servers. So being able to go as far as here are the resource ID that I allow them to manage and touch. And here are the resource IDs that I don't allow them to manage and touch because that's a much simpler use case and what we are actually expecting. I don't want to answer that point. You missed the talk on it. I don't want to answer the ad. Yes, dynamic policy. It's underway. Making stuff like that possible. Adam has been working extensively on it. You should definitely give information to Adam and sync up with him. He's a great resource on this. Yeah, you might be able to find him in here. He's the guy with the red hat. Oh, there he is. He might be jumping up and down excited that you asked that question. OK, first of all, thanks for the presentation. It's really great to see that this is so far. And I guess we're shutting down. But if I have time, how about OpenStack CLI support for EACP in non-Keystone to Keystone, existing sample federations? So it all comes down to the auth plugins and some of those are already in Python Keystone client. We're currently kind of sorting out that and trying to think about how to best set it up. But there is support for SAML and Kerberos for OpenStack client. So you could use those in a non-Keystone to Keystone way. OK, cool. Thanks. Thanks.