 Can everybody hear me? Oh, no, I can. Wow, big crowd standing room only. Thank you, everyone, for coming to our session, enabling real world interoperability, interoperable hybrid cloud use cases using OpenStacks federated identity capabilities. Wow, that's a mouthful. Just go quickly through the agenda. I'll introduce the presenters. I'll talk about the IBM Cloud ecosystem. We'll talk about some hybrid cloud use cases. We'll then talk about our OpenStack-based product, which is for on-prem IBM Cloud Manager with OpenStack. Then we'll start getting into heavy details. Overview of Keystone, the identity component of OpenStack. Then we'll cover some federation and get into Keystone and federated identity and future work. About the presenters, I'm IBM's Distinguished Engineer for OpenStack. I lead, my name's Brad Topol. I lead all of IBM's upstream contributions to OpenStack. I have cross IBM responsibility for what we're going to contribute to OpenStack. And I'm also a core contributor in Keystone specs, heat translator, and Picad F. On my right here is Steve Martinelli. Say hi. Steve is a multi-core and OpenStack, Keystone core, OpenStack client core, Oslo policy core. Steve has been one of the leading contributors to Keystone and its federation capabilities and its Keystone to Keystone federation capabilities. Did a lot of the SAML work. Did a lot of the OpenID Connect work. And on my left, I have Brant Knudson. Knudson? I never get that right. Brant is also a Keystone core and Oslo policy core. Brant is also on the product side, working with lots of customers on Cloud Manager with OpenStack. And just to give you some background on IBM's approach, when you look at what we're doing in the cloud space, we're essentially building on open technologies at all layers. So believe it or not, obviously we have lots of folks that contribute to OpenStack. But you may not know we have lots of folks contributing at the other layers as well. We have lots of folks contributing to Cloud Foundry, Docker, Node, CouchDB. And even at the higher software as a service layers, we have the co-chair for HTML5. Why would IBM have the co-chair of HTML5 and have folks at the W3C? We don't own a browser. Well, we're typically the adults in the room where we're trying to work across the other folks with browsers to make sure we're delivering the capabilities and the open technologies and open standards that our customers need. So we do actually have folks plugged in at all these different layers at our core. It's critical to us to be based on open technologies. So it's a great strategy. And then if we map this to the IBM Cloud ecosystem, we've got a lot of stuff at all the layers that we turn into product, again, based on these open technologies. And if we look at the lower layer here at infrastructure as a service, we've got for on-prem offerings, we've got an IBM Cloud Manager with OpenStack. We also have dedicated hosting-based OpenStack. So you can get your IBM will run it for you and you don't have to worry about it and it's private. We have in beta, we also have now a public in beta. I believe all that was announced this morning. If I got that wrong, I guess I'm in big trouble, but I know it was announced this morning. At the platform of the service layer based on Cloud Foundry, we have BlueMix. And so when you go to that next layer, when you have your developers and they want to have it real easy to get their environments up and running to do what their small part of what they wanna do when the database is there and the app server is there and then everything is ready to scale in the cloud. That's what we do with BlueMix. I highly encourage you to go check it out. Lots of free trials to go see what's available there. And then as we get at the higher layers, software as a service and up, then you see the other parts of IBM with a lot of analytics, Watson analytics, a lot of security. We do a lot in commerce and healthcare. So that's sort of the overall ecosystem. Real thing we wanna talk to you about today is hybrid cloud and interoperable hybrid cloud based on open standards, based on frankly a lot of the open stack technology and Keystone. And I'm not gonna cover a lot of details here, but the interesting thing about the hybrid cloud use cases are pretty straightforward. There's a lot of folks who wanna start on-prem and based on the need, they wanna then burst out. So you could burst to another cloud, maybe you've got two different on-prem clouds, maybe you wanna burst up to a dedicated hosted cloud, what have you. So those are typically the key use cases for hybrid cloud and when we're gonna do hybrid cloud, so we got a couple of them listed here, workload portability spillover. But the things we wanna worry about, obviously security, control, visibility. There's a lot of folks who wanna have, one of the things we worry about at IBM is worrying about visibility and where things run. If you have certain things that have to stay in a certain country, because of regulatory concerns, we're gonna have the ability so that those things stay in those countries and then we can then burst up when we can and get the benefits of the extra cycles. Now at this point, this can be really easy for me because I just get to do the intro, is we're gonna hand over to Brandt who is gonna talk to us about cloud manager with open stack. Thank you, Brett. So our cloud manager with open stack is one of the products that's in the IBM family here. This is our single tenant on premises cloud offering. You can, it includes all of the IBM or all of the open stack services and you can download it from our website as a demo and install it and see how it works, it provides all the infrastructure of the service. It supports several platforms, Power and our system Z and our X86. It includes some features that make it pretty easy to set it up as a starter cloud. We provide the Chef deployment. So you use a Chef for deployment. Got the resource utilization. There's a self-service interface. So on top of the open stack, we also provide other user interfaces. One of them is the self-service user interface that some deployments need to have a way for customers to request a compute resources and then to have them also be approved by their administrator and it is ref stack compliant. So it's a pretty basic open stack and there's other products that build on top of this. Provides a single point of management. You know, this is pretty similar to the previous slide here. It's got the metering and billing and we'll be demoing some of the Federation capabilities here. All of these demos were built using that cloud manager with open stack. On this one, we have several of the features. Easy to deploy using the Chef cookbooks. It's pretty easy to set up an all-in-one system or you can also set up a single node and multiple computes and then you can also set up HA. We've implemented that in the current release. And on top of that, we also provide a user interface that allows you to pretty easily fill in the, build your deployment, add new computes and move your services around. So Chef based, we got the self-service portal. And I'll go on to the next one here. So of course, along with the cloud manager with open stack, we include the Keystone and this demo here is gonna show some features of Keystone. It's our open stack, it's the identity service, provides authentication, authorization and audit services. Use it to get your token and then you pass that token on to the other services. You define your service catalog there. You know, this is all your other, Nova is running here and Swift is running over here. That's what the service catalog tells you. You also define your users in there, you define the groups, domains are a way to group the users and the projects and it's pretty much outside. And so I'll just cover this. This is how the classic authentication works and then you'll be able to compare this to how does this compare to the federation flow? So in this one, you can see the first step there is this little blue guy with no face. He sends his password to Keystone and Keystone can talk to the backend database that can either be like an SQL database or it can also be LDAP, it can be your corporate LDAP. From there, the guy gets his token back and then he passes it on to Swift and Nova and it's not too complicated when all you're doing is getting the token. So then you pass that on to Swift and Nova and now I'll hand it over to Steve for the federation stuff. All right, okay, great, this thing works. So how many people are at the keynote today? Did you all see that with the federated identity stuff from Digital Film Tree and HP? That's pretty awesome, huh? So yeah, federation's getting to, it was already a hot topic and if anything, now it's still pretty hot. So federation, you have two distinct entities that kind of want to work together. One of the main things of federation is federated identity and federated identity itself is actually broken up into two main categories, I think of it anyway, identity providers and protocols. Identity providers is basically a way for a user to authenticate somewhere. Typically we think of Google or Twitter or LinkedIn, those are, Google especially would probably a first class identity provider, we authenticate there and they're pretty much done at that point, they send off your credentials somewhere else and then that's how you can actually use the one click login or single sign on, stuff like that. All these identities are stored somewhere, somewhere in like an LDAP, could be SQL, could be Active Directory, whatever kind of organized structure. The identity provider is often a piece of software like IBM's Tivoli where it kind of, doesn't really matter what the underlying technology is or what protocol you're using, it's gonna have a way to translate those attributes that are stored in a SQL or LDAP and put them into some set standard way. This is where the protocol comes in. The protocol not only sets the standard for how the user authenticates, but also how the user is represented using attributes and using fields. So there's two main, two most popular protocols that Keystone supports is SAML and OpenID Connect. For those of you who don't know, SAML is XML based. I think the first draft came out like 2004 or earlier. It's tried and true, a lot of enterprises use it. It's been around a while, lots of library support for it. Unfortunately, it is XML based and anyone who's used OpenSack knows that it's in Python and anyone who uses Python knows XML support for Python. It's not the best. But then Incomes OpenID Connect kind of saved the day. They had their 1.0 spec in November of 2014. It had been brewing up before that. It was based off of OAuth 2, which then and OpenID and then came OpenID Connect. The great thing about this is it's actually JSON based, which works out really well for Python and thus OpenSack. So I don't know how many people in the room are IBM, but what we're probably used to associating with federated identity is probably this login screen, which we see on our intranet. You know, when you're booking travel or something, it's like, oh, well, gotta sign in. So here's a, you know, stevemar.ca.ibm.com. This is but just one instance of federated identity. It's a very specific one. It's a browser based single sign-on, but bringing it back to the concepts that we introduced in the slide before. The identity provider in this case is Blue Pages, which is our corporate LDAP, and the protocol that it's talking with is SAML 2.0. Like I said, single sign-on is just one sort of way to use federation and federated identity. The other, so speaking on a broader sense on this slide, there's two main reasons why you want to use federated identity. You're federating in or you're federating out. Federating in would be you have an existing service provider. You have an application, let's say, like, you know, to put in IBM terms, you want to book your travel. So we log in and we see our single sign-on, and then our identity provider would be Tivoli or whatever it uses to actually talk to the Blue Pages back end. So in that case, your web app is just basically a service provider for the user, and it's using an identity provider, which it already knows about. And the main reason it wants to do this is because it doesn't want to handle authentication, it doesn't want to handle user management. Especially when you already have a corporate LDAP doing that for you, it just doesn't make any sense. And that's something that we're noticing with a lot of Keystone and OpenStack kind of customers. They already have this in place, so they don't, you know, they want to leverage this. Federating out is kind of the flip side of that. It's kind of turning it inside out. And I'm going to credit Joe Savick for this one here, and he's sitting in the corner over there. Federating out, it's basically making your application kind of represent a user in a standard way. So in a SAML way or in a JSON way. The reason why we're going to go into this is because that's kind of like what the Keystone to Keystone, or if you saw in the keynote, that's how they're able to actually, you know, get two distinct organizations to kind of trust each other by creating a user in a standard way. But before we go into the stuff, into the Keystone to Keystone stuff, I want to briefly talk about the WebSSO feature. WebSSO is actually one of the new features that we introduced in Kilo. I think it's classified as experimental right now, but it's pretty solid. Credit goes out to the guys from CERN who actually did a POC of this stuff earlier in, I think, Juno. The reason why this is important is because, you know, Horizon is, Horizon, the OpenStack dashboard, is the main kind of landing, not landing page. It's the main point of contact for usability, for users. They're, most of the time, users are going to be going through Horizon to do most things. CLIs are great for automation, but most users are actually going to go through Horizon. And so now what we were introducing in Kilo is that users can out sign in through Horizon by going to their identity provider and then signing in from there. We have a demo of this, we're going to show in about a slider too. But one of the technical points of this was that the users themselves aren't actually going to be existing on Keystone. This is a basic concept for Federation. So, you know, users from an existing identity provider are not going to be, you know, you're not going to find them in the Keystone SQL backend. Keystone should have no knowledge of this. It says, great, your users authenticated. Okay, let's see what permissions they have and go add it from there. And one of the other aspects of this that was important was branding. It seems kind of awkward to kind of type in your IBM username or your, you know, Google password into a Horizon login. I know you can change the branding at all, but it just kind of seems a little awkward. So to give you a quick kind of picture of what you'll see there, and we'll show the demo in one second, the when a user actually is going to hit Horizon, they're actually going to be given an option as to how do you, how do you want to connect? Do you want to use your old password, username and password? Kind of like how you use your service accounts now? Or do you want to go through a federated flow? And with the federated flow, what we're doing is we're listing the protocols. And each protocol is going to have a default identity provider associated with it. And once the user actually clicks that, they're actually going to go to the, to the, to the branded kind of login page that's associated with the identity provider. Log in and then actually go back to, and then they'll actually already be in Horizon at that point. So in the demo, you're going to see, to kind of bring things back to the terms that we're already familiar with, Google would be the identity provider, open ID connectivity to the protocol. And like I said, Horizon can list quite a few protocols. So to actually quickly show the demo, I tried to, there it is. Tried to cap it at two minutes because I don't want to bore you guys. But what's going to happen is, there we go. So the user is going to actually hit Horizon and you're going to see over here, it's the usual login page. This one, this is all actually customizable. So by default, we decided to go with open ID connect, but it's actually customizable. You can actually see the Keystone credentials is listed there. And you can go back to typing your username and password, pretty handy for service accounts. But then if you don't want to do that, you can go through the open ID connect flow. Click connect and you'll actually be prompted to hopefully go to the Google sign in page. Boom. At which point, I made up a dummy account, open stack federation. Just kind of type it in and you authenticate. And I already kind of, I already configured Keystone to know users from being, users coming in from Google are going to have, are going to be put into this group with this role. And that's one of the basic concepts of federation. It's utilizing groups because groups are still managed by Keystone. You can see on the top right that the user is actually coming from at accounts.google.com. That's the user ID that gets picked up. And the user, you can actually switch projects, list projects anyway. I didn't actually bother switching. And just to kind of make sure that we're not playing around too much, we can go see the images. And I think I end up creating a group or something. But yeah, you can see it there. And this is all in Keystone right now. Like this is an untainted version. I just pulled down DevStack, ran a script, and kicked it off. You can see the script on my GitHub or Gist. But it's pretty much just straight up vanilla kilo with a few changes. You just have to have the latest Django open stack auth library. So yeah, you can see the user is doing stuff. He's got the admin role. And just going to sign out. And that was the demo for the SSO pieces. And now Brent is actually going to talk about the Keystone to Keystone Federation Supporting Keyload. Thanks, Steve. So in this section, we have another demo where we're going to talk about the Keystone to Keystone. So this was another thing that was demoed in the keynote this morning where they were doing Keystone to Keystone Federation. And this is going to show some further work that we've got going on. And it will actually be demoing some things that haven't merged yet, but are proposed to the community. So the Keystone to Keystone Federation Support has been marked as stable as of the kilo release. So that means it's supported. It's an example of both the federating in and federating out. So you've got one Keystone is acting as the identity provider. That's the source Keystone is providing a SAML assertion. And then there's another part that acts as actually a separate Keystone that acts as the service provider. It accepts the SAML assertion from one Keystone to the other and it translate that into a separate Keystone token. So in this case, we actually have two Keystones and there's several ways that you might set this up. You know, one of them might be a public cloud. One of them might be on premise. They could both be on premise or two separate companies. So part of this is that the two clouds of course has to trust each other. You set that up by exchanging the SAML metadata. And this is something you have to do in regular Federation too, but you set up this SAML metadata. You set up your mappings of the remote users to the local groups and local authorities. So you have complete control over what authorities these remote users are gonna get. And we provide the tool. You run this tool, it generates the SAML metadata. So it's not difficult to set up. So the flow that you're gonna see here is that the user authenticates with their own cloud. They send their user name and password. They get a token back. And then they talk to their local cloud, their local Keystone. They get back a SAML assertion using their token. They get back a SAML assertion and now they forward that SAML assertion off to the other cloud. And using that, they get their token on the remote system. And so this is a whole diagram showing the flow. Step one, as I said, and in the demo here, we're gonna see that there's a Minnesota region, Minnesota cloud and Texas cloud. Those are just the names we picked for the demo. And as you can see, there's a Keystone Nova Glance that's all running in one cloud. And there's another Keystone running in the other cloud. And the way that you've tied those together is at the top there, there's the one-time setup where you add the Minnesota cloud as a service provider on Texas. You add the Texas cloud as an identity provider on Minnesota. And then as a user, let's say you start out in the Minnesota system here, you ask for a SAML assertion. You get one back and then you present that to the other Keystone and then you get back a token that you can use with, of course, all the Texas systems. Okay, so in this demo, it's gonna be showing Horizon again. So you can imagine an administrator or maybe a user here is using Horizon checking out what's going on in the cloud. You'll see that there's two regions, there's Minnesota and Texas, and it's really seamless here. I mean, you don't even tell that you're going off to another cloud. And what's happening in the background is that it's actually storing in Horizon both of the tokens. So it's storing your Minnesota tokens and storing your Texas tokens. And it knows when you're talking to Texas that you use one token and when you're talking to the Minnesota systems, it uses the first token. And the other part here is, it's set up the service catalog for the system so that it's got, the Minnesota system has got knowledge that there's this other remote Texas region out there. And I think I've covered pretty much all that. So, as I said, some of these patches are still under review in the community and it might wind up looking a little different, but this shows some things that are coming. So here's the demo. This is just what it looks like when you go to the Horizon on the cloud manager with OpenStack. Oops. So I just log in, let's say it's the admin. And this is, of course, the Minnesota region that he's logging into, takes a second. And so for the purposes of this demo, we're just gonna look at, so what are the flavors in this cloud? And you can see in the upper right there, it shows the admin is in the Minnesota region here. So you can see there's a lot of flavors here. We've got the seros image, of course, because this is a demo. And now when I click on there, on here it'll show all the regions that I have available. And of course, the Texas one is a whole another cloud. And when I click on that, this is where the handshake is happening automatically where I'm getting another token on the Texas cloud. And then as you can see here, when we look at the images, there actually aren't anywhere as there used to be that the seros image. And this one's only got a couple of flavors to find. So this just shows that it's connecting to a completely different cloud here. And you can log out after or go back to the Minnesota region and see what's going on. So that was our demo for the Keystone to Keystone. So I was told I'm supposed to wrap up here. So just looking at availability, getting the code refreshed. So the code from the community will be there and cloud marriage with OpenStack in June. Also with our IBM Cloud OpenStack services, which is our dedicated hosted offering. So you get private dedicated hosted cloud. You know, we've got a commitment there from that team to have this up running in private cloud host on software third quarter of this year. Obviously working with the community is something we're gonna continue to do. All our friends are here, I see them all around. And you know, we'll look at the next steps for this. Obviously getting more user feedback to make this more consumable is gonna be huge. Better install and config, whether it be Puppet, Chef, SaltStack, Ansible, what have you, better client support. So we're gonna continue to make this more seamless, more consumable, more usable, and we need your all's feedback. So please, we'd love to work with you. We wanna help kick the tires, what have you. Not just us, but everyone in the community of OpenStack that works on the Keystone team. And we'd love to hear how we can improve things to meet your needs. And also we are hiring tremendously. So look for somebody in this shirt about wonderful opportunities for OpenStack contributors. Well that's convenient, coincidental. Okay, are there any questions? Everybody needs to use a mic when they use a question because it is being recorded. So if we can put Jeff to work. Jeff, make sure that you get a mic for everybody. It's recorded, so I can repeat the question. No excuses, Jeff here. Let's solve that for you, sir. Jeff will be our mic guy. We have the technology. Yeah, well done. Hi. I had a quick question about what happens now that the federated identity is there and you can use, you can connect, you basically have one dashboard for multiple cloud instances. Are you guys taking it to the next point where I can now do move configurations and things that I've set up in one cloud from one point to the other and deployed to the other cloud instead of having a separate outside force that needs to do that separately like sharing images in some sense or copying it over or even like configuration for networking configuration for other things. That's an outstanding question. And the answer is you're hitting on an important point. You know, this is sort of the first step. You saw it just as a demo at the keynote and a demo here. But the things that you're talking about with being able to get those configurations and network configurations and the things that you want is gonna definitely be next steps and things that we have to look at and work with the community on how we make that easier. I know we've done a little bit of work. I know Henry Nash couldn't be here, but you know, Henry worked on adding dynamic configuration to Keystone so you could be able to reconfigure Keystone without having to, you know, through a RESTful API without having to shut it down. These are the basic building blocks that we're adding and you know, we're gonna work with the other folks from the community to figure out that the best way to handle those types of use cases that you're talking about. Do either of you wanna add to that answer? Yeah, sure. I already have a mic. Thanks. No, but this kind of plays into the last slide where we were mentioning that, you know, Puppet, Chef, Ansible, Salt Sack support. That's, you know, that's essential to kind of make it more real for folks. They wanna make, they're already using this. But if the support for Federation's not there, then you know, no one's actually gonna be using it. So we need support there. And I know the guys from CERN have some really interesting use cases for Federation and I think that's what you asked is kind of what's up their alley. So yeah, I think someone's gonna be proposed, someone's gonna be bugging us about that very soon. Yep. All right, next question. Thanks guys. Great talk. I'm Jason Harley from Breakwater. This is a carry on to the last question. Steve, how you doing? It's going good. Toronto Connection. It's great. Really? Yeah. It's the Toronto thing. Open stack meetup. Hey, we're in Canada. We're representing. We can't do the handshake because you'd all learn it and like. It's just structural. Hatchip chips for everybody. Go ahead, sir. I'm wondering what the level of integration with this functionality is into other components at this point, which is sort of a carry on. Like we talked about moving configuration. So he sort of like trails in there nicely. Are these components understanding these kind of assertions coming from their local Keystone at this point? Or, and if you don't know, that's cool too, obviously. It should be, it should be just like any other token, right? It's gonna have, a user's gonna have roles, it's gonna have a project. The only thing is the user's not actually gonna exist there, but the user ID and name are pretty much only there for auditing purposes anyway. And you're assigning the user a role and that's the token he's gonna use. So it should kind of be, you know. Right, but as you have your stuff on-prem, maybe you have images or what have you and then you have them in your glance and there's things that you need to move up to your say dedicated hosted cloud, what have you. I think that's sort of what you're hitting a little bit. But there's gonna be, I think, sort of those ancillary real world things. You say we're, you know, here we come in and we think, oh look, we did such a great job and folks will come to us, I'm sure, and go, well you know, in the real world we need to also handle A, B, and C guys, even us good friends in Toronto. So I'm sure there's a lot of that and we just need to start hammering through it and go to it. Oh wait, we'll just go to the next one. Go ahead. Hey guys, thanks. Damian Stevens with Cervocity. Do you mention that the clouds need to trust each other? So even if they're open stack certified clouds, I think you said the admin needs to do that. So what do you think it takes and what's the likelihood or what's the next step to make sure that you can go from an IBM to a HP or some other certified open stack cloud and then back and forth between that and my hybrid, just from a Keystone perspective because it seems like you know, you don't need to get the cloud admin involved for every request at a public cloud scale. Yeah, it's not gonna be, it's not gonna be every request but you know, the other clouds that you trust, you know, you're going to have to set up a relationship there between those two. And it's really gonna be the Keystone community's job to make that as easy as we can. I suspect now this is sort of out of band, out of channel, you do some configuration, pass some keys. Yeah, to an extent there are actually a few APIs that you can actually hit that just downloads the metadata for you. So you don't have to bug the admin from a service provider perspective but he still might have to do some additional configuration to trust you, you know? Yeah, and my gut says we're gonna need to make that better as a community, yes. Kevin Fox, PNNL. You've got some horizon support for it now. Does Keystone itself have some kind of list the other clouds that are partners because regions are kind of things that share a Keystone but can your CLIs and stuff switch between the clouds? Has any of that work been done? And we'll take one last question after this. Yeah, and I think that's more work that we have to get done is, you know, the CLI part is a big part of it. Yeah, just a quick note on that. We were just piggybacking off the region's list. We just didn't want to have to make a whole new list on horizon so we just kind of slotted it in. Hi, this is Joy from HP. I just had one last question. Are there any plans for adding auditing? A lot of, you know, it falls into a lot of compliance fulfillment for many enterprises. So I was curious if you had plans to add special auditing with this feature. Oh, okay, sure. And I see Matt recasting in the front laughing at me because he's part of the CADF folk. Yeah, right now we actually have support for when a user authenticates through a federated workflow. So that's actually already there. It's been there since, I think, Juneau. And aside from that, what the user does on another cloud, it should be, again, seamless. The user ID should just be in the token and if he's using a token to do an operation, you'll be able to see it. And then I believe we should probably augment the existing auditing to say if it is a federated token, we should probably include the identity provider as well. So yeah, we can probably improve it a little bit, yeah. So and again, that's another one with you. So there's some basic stuff in there, you know, and we need to go further as we work with folks like you and make sure we're hitting all the necessary compliance. Thank you. Okay.