 All right, welcome everybody. We have a panel session, open stack Federation panel, past, present, and future, just a brief introduction. You know, many of us have been working in Keystone for many a year. And I remember, you know, where Keystone started in the early days, it had some basic capabilities. It did not have a lot of security. It didn't have the notion of being able to have secure connections from Keystone to LDAP or Active Directory. And so a lot of us, a lot of folks you see here jumped in, and not only did we actually add secure connections, but then we started adding the ability to integrate into LDAPs and Active Directories, and then integrate into multiple LDAPs and Active Directories. And of course, that was never enough, right? And then people came to us with terms like Federation and SAML and OpenID Connect. And so what you've seen is the teams put a lot of work into adding Federation support to Keystone. And this is a great panel session to talk about, you know, where we were, where we're going, what we're going to do. So we have a lot of wonderful speakers here, and I'm going to let them introduce themselves. We're going to first start with Joe Savick. Hi. We're sitting out of order. Oh, that's not good. Okay. My name is Joe Savick. I'm a Senior Manager of Product Over at Rackspace, and I've been working on brilliant people working on the Keystone project, and now the Barbican project, and excited to move the ball on Federation even further down the road. All right. Next one is Steve Martinelli. Hi. I'm Steve Martinelli. I'm going to be the Keystone PTL for the Mitaka release. I've been working on Keystone for a while, and working a lot on the Federation bits, so that's it. Excellent. We're going to go next to Marek. Yeah. Hey, I'm Marek Deniz. I work at CERN Switzerland. I'm a Keystone core as well, and I focus mainly on the identity of Federation in OpenStack. Now we're going to move on to Doug Menzeball. Yeah. So I'm Doug Menzeball. I'm the current Barbican PTL for Mitaka, and I've been PTL for Barbican for the last two cycles as well. Okay. And last but not least, we'll go on to Klaus Werenga. Yes. Klaus Werenga, Identity Architect for Cisco Cloud Service. I'll take a little bit longer, because I'm kind of the new kid on the block. I guess that's why I'm on the side of the podium, that they can shove me off. Now I'm relatively new to OpenStack. I have a long history in identity and federated identity. Those of you who are from academia may know a service that I built almost 15 years ago at your home for Wi-Fi roaming. I've been involved in the start of educating the higher ed federation of federations. And when I moved to Cisco, I kept working on mobility and federations. And for a year now I'm at Cisco Cloud Services and basically trying to put everything I learned about federations and federated identity into what we do with OpenStack. Excellent. Thank you Klaus. So we're going to start with Federation Past. And the first question goes to Merrick. Who is this CERN group and why do they do identity federation? Yeah, sure. So who is this CERN? CERN is the high energy physics laboratory based in Europe, in Switzerland. We're basically trying to solve the mystery of the universe, try to understand how the universe was created and why do we have mass? Well, yeah, why do I have some weight? And for that we do some kind of experiments. We have the 27 kilometers long ring under the ground where we accelerate the particles to the speed of light and we collide them and in the controlled environment we see how they behave and what new can we see. And for this, this is like the one of our detectors. It's like 30 meters in diameter. So it's pretty huge. So for this, our detectors produce a lot of data. And when I say lots, the bandwidth is roughly one petabyte of data per second. So it's really a lot. Okay, most of the data is actually filtered out by our sophisticated electronics but basically what's interesting and what's stored needs to be processed, analyzed and then some people just get the Nobel Prize. So we end up with 30 petabytes of valuable data per year that needs to be analyzed. Of course we cannot afford building all the data centers to all the work by ourselves. Plus this is the scientific collaboration so we are open to the collaboration. And right now we rely on the WRCG, so World Allege Computing Grid but we are also looking into cloud computing solutions. We are looking for the ways for integrating with various private and public cloud providers and clearly the Federation is the best way to do this because we can focus on doing what we mean to do so finding the physics equations and the results instead of just managing the accounts and probably just fixing the errors when somebody is not deleted from the project or is not added to the project. So clearly we need the Federation for just moving the ball. Excellent. Thank you. So now I'll move on to some other folks. We'll start with Steve. Steve, how do you use Federation today at your respective company, IBM? Are you sure you don't know? I don't pay attention to a lot of things. Well, so we're looking into it right now. So one of the main things, well, we have products that act as identity providers that you can use so we have things like Tivoli Federated Identity Manager and Webster Liberty which act as identity providers which you can then connect to Keystone and OpenStack. Additionally, we also have some OpenStack offerings because it's essentially vanilla OpenStack, the vanilla Federation OpenStack code and as a result we get the Federation bits there and one of the things that we're looking into now is connecting our BlueMix offering which is based on Cloud Foundry and tying it into OpenStack, into our OpenStack offerings so things like BlueBox and our BlueBox on SoftLayer. That's something that we're going to look into. Excellent. Thank you. Joe, how do you use Federation at your respective company, Rackspace? Sure. We typically take a look at three different use cases and part of it is the same use case that you mentioned, Steve, of BlueMix and tying it in with OpenStack. Over at Rackspace we have our dedicated world. We use through a certain control panel that we have, a website, and then we have our cloud world through a separate one. We use federated identity in between these two different hosted control panels that we fully trust over at Rackspace to kind of tie them together and allow our users to use the same provisioned identity across both of them. We use SAML in that case. In other use cases, Rackspace is a managed service provider so Rackers have access whenever supporting customers to be able to go from a support tool over to a control panel and be able to help answer customers. There's SAML integration there from a Rackspace employee credential that's provisioned and wanting to federate over to a different system. In the third use case, there are users using things like Active Directory Federation Services to with them wanting to come into our different control panels that we have. Excellent. Thank you. Klaus, same question. How do we use Federation at Cisco? And I believe you have a turn. I do. Yes. I believe we do things a little bit different from what I've heard at the previous conference. There was a lot of talk about Federation. There is the whole Keystone to Keystone Federation stuff going on. And I thought it was best to show in a slide what we're doing. Basically, what we try to do is to be an intermediary between the companies that are our customers and the services that we or third parties are offering. And that way, put it in identity terms, we act as an IDP towards the relying parties, the service providers, and we act as an SP to the customer IDPs. So the nice thing about that is that they have to manage only one trust relation and more importantly, we only have to manage one trust relation per customer. And the same towards the relying parties. I keep saying relying party because service providers, at least inside Cisco, are much overloaded term, even though it's the Semmel terminology. So instead of essentially an N squared trust establishment problem, we bring it down to an order of magnitude of N problem and associated with that, we can pairwise change whatever Federation protocol we talk either to the relying parties or to the identity providers. So if the customer wants to talk Semmel 1.1 or Semmel 2 or OpenID Connect or OAuth 2, we don't care. We can do that. Southbound, we can still at the moment talk Semmel but in the future I expect actually that we will do more OpenID Connect because it's a little bit more API friendly. And let's see, so really it is about scaling to large numbers. I think that's the big problem that we're trying to solve here. And the kind of a philosophical design criteria I liked and that's perhaps because I come from a little bit different background, I like to keep as much as possible out of OpenStack. I want to treat OpenStack like just any other relying party and have it do the minimal set of capabilities that is needed to function correctly, but everything else we've spent 20 years and if you take Kerberos or elsewhere as an example of albeit crippled Federation protocol even longer than that, we've been working on making identity and federated identity work. We wanted to work the same also to other types of relying parties like WebEx, Spark, whatever web-based service you have. So if we were to put it all that functionality into Keystone, we could not leverage it for order services so as much as possible out of OpenStack. And with that I'm still on the stage so that's nice. With that I'll end it back. We're a very inclusive group, we are OpenStack. Moving on to the next question, we'll start with Steve. Steve, what's your favorite Federation or identity protocol and why? I like OpenID Connect. SAML is XML-based which makes it more difficult with Python. OpenID Connect is JSON-friendly, so is Python. It works great and it's really easy to get a identity provider because Google talks OpenID Connect and I already have a credential there so it makes it easy to test out. Excellent. Joe, same question. You know, mind changes, it depends on the target market so when we're looking at reaching out to enterprises at SAML, they typically run identity providers that could speak SAML over OpenID Connect. If we're looking at the developer market, maybe OpenID Connect might be better. Nobody cares, maybe skim. Skim is provision, it's not Federation at all. It's just being able to speak and replicate identities all around. You know, I haven't heard the term skim for like a year and a half at this conference. But there was, I think it was Portland, I heard it a lot. And then since then just you, so I want to hear more skim. I had it on my slide but I removed it, I thought let's not bring that up. This is the term that's going to push them over the edge and get me off the stage. I'll take this one off. Yeah, it's back on stage. Klaus, same question. Yeah, I have to say my favorite Federation protocol is Radius. I know it's not used inside OpenStack, in AppVap usually. I should have said it in my introduction. I'm also the AppVap chair in the ITF. But actually, AppVap doesn't use it in a way I like it. What I like about Radius is that it's simple. It has one purpose and one purpose only and it does that well. I think all of the other protocols are at a severe risk of being overloaded. And, well, Semmel is a good example of that. But that's Semmel 2 is 10 years old. I'm sure OpenID Connect will go the same way. Yeah. Klaus, you just gave me a horrible flashback. I was sent to Amsterdam for a customer critsit. We were doing wireless devices and Radius was involved and it wasn't working. So I'm having cold sweats that you even brought that up. Merrick. I think I will go my supportive vote for Semmel, even though it's XML. But it's at least 10 years old and so this means if it's still on the market, it means this is trusted and tested. Yeah, Semmel. Okay. Doug, you've been awful shy and quiet. You had to chime in. What is your favorite protocol? You can't hide anymore. So as far as identity protocols here, I would have to go with whatever the JSON one was. That's super. So my identity, OpenID Connect, that's the one. Somebody brought them. Not my strong suit. That's right. When we're ready to talk key management. We're getting there, sir. Right. Excellent. I'm glad we put you on the spot there. Nice hazing for the new guy, right, Joe? That's a good answer. Good answer. Okay. So let's talk a little about Federation of Future. We'll go with Joe first. Joe is Federation limited to only identities for OpenStack. Yes. Are there other federatable things? Yeah. So there's a couple of use cases out there that could invoke Federation. One of them that we're looking at, and I talked about earlier today over at the design area, was bring your own key use cases. It's a use case where, actually, you were supposed to talk about this, aren't you? He will. It's next question for him. Do you want to go into the next question? Sure. Sure. Then we'll come back to Steve. Since you got kind of, Doug, how do you see Federation and bring your own key working? What are the use cases? I think Federation is interesting, and we're still building Barbican Federation as a way to provide a bring your own key workflow to OpenStack. And so use cases for that would be customers that are sort of security conscious. They don't particularly want to trust a Barbican that is running a public cloud with all their secrets. And bring your own key would provide a way for them to keep ownership of any secret material and only federate that out to the public cloud when needed. Excellent. Also, oh, sorry. Keep going, keep going. One more. Different use case, some customers may be under some kind of compliance regime whereby they cannot actually save those secret things to a public cloud and they have to sort of keep ownership of those things in their premise. You see bring your own key slash Federation as a way to achieve that. Outstanding. And we'll come back to Steve. Same question we gave Joe. Is Federation limited only to identities for OpenStack? Are there other federatable things? Yeah, so yesterday during the cross-project session we had a talk about Federation and federating it with other things in OpenStack. And one of the cases that the guys from the Massachusetts OpenCloud group were talking about and they prototyped it is, you know, you have your Nova instances in one location and then you have your Cinder volumes in another location and you want to attach volumes to instances that are not in your cloud that are on another cloud. So that's one instance. And really there's quite a few use cases and in the same kind of flow there's storing objects but you want to assign the objects and you want to get the key from Barbican. So another one there, another one is Nova and Glance. You want to, you know, set your create instances in one area and then you want to get images from another location, completely other cloud. Okay. Yeah. All right, thank you. All right, this question is going to go in first to Doug and then Joe. What are the challenges organizations will face in a bring your own key model? And then I'm going to also add to this an imprompt. You know, also kind of talk about how this works, how you can sort of bring your own key and meet compliance. I think that might be something to expand upon a little bit as well. Okay. So how can he, sorry, I got confused with the second part of the question. We'll take this too. First, what are the challenges? Challenges. Yes, sorry. So as soon as some organization decides they want to bring their own key, then the responsibility of managing those keys falls on them. Right. And so you're going to have to think about things about, you know, the key storage, key management as far as exploration, rotation, sort of all those things. I think Barbican can help with that. Being able to deploy a Barbican in your own prem would help you sort of with managing that key life cycle or secret life cycle. And then the second part of the question was. Well, just want to help people understand how that bring your own key magic works, right? I brought my own key, but my key is still safe and compliant. So we're still sort of in the design phase of this. We had a design session earlier today and then one of actually two of them, there's a lot of discussion, a lot of different points of view on how this should work. Sort of at a high level what we're thinking is, you know, you have your private Barbican hosting your own keys that you own. And then you send a request to say Nova to boot from an encrypted sender volume. And you tell it, hey, you know, use this key that's on my prem. You give it a reference to a key that is held in the private Barbican. No, then we'll talk to sender and say, hey, I need this volume. And then I will talk to a public Barbican saying, hey, I need this key that's federated somewhere. And then the two Barbicans will sort of talk to each other. And then the public Barbican would get that key handed over to sender magic would happen. Sort of the point here is that the key, even though a story in your private Barbican, it does exist in the cloud for some time, but it's not stored there. So this would help with sort of a tax ed rest, I suppose, where you don't, your key is in the cloud only when it's being used, but then when it's not being used, it's only inside your prem. Gotcha. Joe, same question. Yeah, absolutely. Another use case that customers may find when doing the bring your own key is what they experienced today with AWS and Azure. Azure has a bring your own key model, but there are products that they have that don't support this kind of key federation or keys that you brought, one being exchange online isn't supported. In the AWS world, I think they launched on S3, but not EC2 yet for the same reason. So it's, hey, with my provision keys, I could do everything that your service offers, but when I bring my own key, there are certain things I can't do. And this is another use case where Barbican can actually help, because when the public cloud or a service provider runs Barbican, it can act as the broker in between the different products that the service provider hosts. And so it's a, for Nova, it's no difference in between a provision key and a brought your own key. Same thing for Cinder, same thing for Keystone even, you know. It makes it a whole lot easier for customers to be able to know what they're getting into and being able to leverage a whole portfolio of a service provider. Okay. And, you know, thinking about these keys and the bring your own key model and you temporarily go from the private Barbican to the public Barbican, you think, hey, how are we tracking these keys? What are we doing here? Have you thought about audit support, federation-based audit support show? Yeah, that's the other thing is that if I'm dealing with so many different service providers, multiple different clouds, either floating up different flavors of OpenStack too. I want to be able to know that the events that are being produced in these different OpenStack clouds are really coming from the service provider, and that they're really intended for me and I can actually decrypt them using my own key. So this is another use case where if we get the foundation of key federation in place, we can start using the pieces that are there with CADF and PyCADF with the nozzle libraries to be able to sign the CADF events with a key that only the customer has. They could decrypt those events, know that there wasn't a man in the middle attack, and that trust relationship still exists in between the customer and the service provider. So now they know, hey, I'm getting all these different audit events and these were truly intended for me and this is truly intended for the resources on my tenants. Yeah, it's an outstanding use case and we'll definitely get you connected with our CADF gurus, Matt Rukowski, and we'll have those discussions. Excellent. Okay, so we're going to move on to sort of setup and problems with federation. Could there be problems with federation? Could there be setup problems with federation? So we'll start with Klaus. Klaus is Identity Federation and Keystone Ready for Enterprise adoption. Well... It's only close to the stage. No, it's perfect. No, the thing is, I think it is good enough and that is in this world already very important. There are some issues, but like I explained, by taking away most of the processing out of OpenStack, we can pretty much do everything we want. There are some nasty things that we'll get to later if you ask about things that need to be solved, but generally speaking, it's okay. I am a bit concerned about the fact, but I guess that's a general problem for OpenStack, that there is so little code base, there is one implementation and that's it, and it gets reviewed, but I guess my ITF background likes multiple implementations for everything and scrutinizing and comparing and stuff like that. That bothers me a little bit about something that is so tightly integrated with security. That's something to think about. Typically, how OpenStack solves that is with multiple plug-in points, extension points, plug-in models, driver models. So, some things to discuss with the Keystone team. Well, certainly. Very, very good data points. We're going to ask the same question, I believe, to Steve. So, I would really, really, really like it if more people would kick the tires on it and on the current federation implementation and just to really stress it and see how it works. I know a lot of guys at Red Hat have done that. We've done it at IBM. A lot of the Rackers have done it. The feedback's been, oh, it's good enough. And I, myself, can find some issues with it, I think. I think some things can be improved. Command line interactions can be better. We can start caching things to make it faster. Caching assertions, caching tokens. We could also improve the mapping engine a little bit more. But, I mean, otherwise, I think it's a pretty good, and I'm totally not biased here. I think it's good enough for now. And I just want a whole lot of feedback from it. And, yeah, I just want folks to really kick the tires on it. Okay. Thank you, Steve. Joe, same question. Yeah, I think there's some, it's good enough, but there's a cost that implementers have to be able to pay. And some of the costs that we're looking at is the manageability of it. There's use cases where a customer wants to be able to swap out the key that they're using for the SAML signature. And the key is handled by the Apache Mountshib and actually the decryption of it. And so that requires an operator to go in. And on a large public cloud, when you're having hundreds of thousands of customers, that gets to be kind of a pain when a customer wants to be able to swap out a key. There's other concerns, though, as well, that are kind of more specific with Keystone overall, such as the mapping isn't nearly as granular as I want it to be for the authorization. This is the same true for provisioned users as well. I can't go down and I can't do fine-grained access control. I can't give cost access only to the dev environment because I don't trust them with my product environment. Things like that, yeah. So I think there's more robust authorization rules that Keystone needs to put in place. That sounds very important. Do you hear that, Henry? All right, good to know, good to know. Excellent. So we're going to go on to our next question here. We'll start with Joe, since he sort of started touching upon this. Joe, how can we enable more authorization grants through assertions? Yeah. Geez, I wish I didn't post that cedar question on there. This one's tough because we've talked about this quite a while in Keystone about dynamic policy and getting into dynamic policy for the policy JSON file and making that available in essential stores that way customers can see the capabilities that they actually have and they're granted through their token. But then there's a deeper level too that goes through for fine-grained access control and really it's baby step to baby step and these are big baby steps that we have to take. That's the problem. And so I think really we have two big problems to solve for within Keystone. That's policy management, policy is being able to understand the capabilities available and then fine-grained access control, to limit those capabilities to specific resources like servers or load balancers and so I think we need some help on this. Okay. Steve, same question. Yes. Joe effectively answered that one. We have some work to do on Keystone itself. I mean this is outside of the Federation scope to really be better at granting control to certain resources and endpoints, more fine-grained access control. This is outside of the scope of Federation, just Keystone proper. Well, I think that we would have floated up through the mapping element for it to be available to federated users. So it's really just the getting the framework in place for that authorization. You need the framework on both sides. You need the framework on the mapping side and your framework on the support and Keystone for the more fine-grained operations. Klaus, same question. Did I sign up for this one too? You're allowed to pass one. You don't like those game shows? Only as the new guy. Just one though. Actually, it sounds a little bit repetitive but also there, we are actually now kind of forced to do part of the authorization outside of OpenStack to circumvent things like the God token and stuff like that that we really don't want to give to our customers. So in general, I would like to see more of the authorization heavy lifting happening outside OpenStack and for the XML lovers that could be something like EXECML but something else might also be possible. So I don't care so much about it. What is being used? I have to admit I didn't think much about it yet because we have lots of other problems to solve but there is an element of reinventing the wheel inside OpenStack and that is another thing that concerns me a bit. Okay. And the next question is for Klaus. I hope he does realize his names on it. Do we do federation inside OpenStack? Keystone to Keystone or external? Yeah, so I actually had a bit of a discussion with Marek about that yesterday evening. I guess it depends is the question and not even so much for technical reasons than for organizational reasons. I see a case for Keystone to Keystone Federation, for instance, things like breaking out from a private cloud to the public cloud and it kind of makes sense to just use Keystone Federation to the public Keystone instance. But in general, again, I prefer to do this outside just like if you go do a single sign-on from one website to another website, you don't have those websites federated with each other. You have an IDP that supports a single sign-on. But there may be organizational reasons why you want to do Keystone to Keystone. For instance, Marek brought up the issue that sometimes as an organizational unit you don't have control over what happens at the central IT and you can perhaps not control the Federation at that level and then Keystone to Keystone might be a good solution. My take is if you hold all the elements in the ecosystem, so IDP, the relying parties, et cetera, I see little reason to do it inside OpenStack, to be honest. Okay. All right, we're now on to our challenge questions and I'm going to throw this out to whoever wants to try and attempt to answer it. First challenge question is, where do you see other OpenStack projects needing enhancements to better enable Federation slash hybrid cloud support? I was thinking about Joe when I asked this. And anyone else who wants to answer? So for Identity Federation, there's always a horizon answer and make it easier, more manageable to be able to do IDPs. But then a lot of stuff is also on Keystone as far as being able to allow easier rotation of keys, being able to help manage my identity provider within Keystone too. But then there's other objects. So Key Federation, we talked about that within Barbican. There's some work with Oslo and Catif as well on adoption. These are all integration services and they require an adoption effort after we build it out. And so most of the brunt work is trying to get other services to use it and expose it. Okay. Did anyone else want to try and answer that? We're good. Okay. We're going to go to our lightning round. I'm about to wrap up here. Everybody gets to give a one-minute answer. What's the next big thing you would like to see happen in the OpenStack Federation space? We'll start with Steve. Federating other services. So either, you know, interaction between, oh, I got to go fast. Interacting between Barbican and Swift, Nova and Cinder, Nova, Glance. Those are things. Am I, did I get it under a minute? Fabulous. Okay. Cool. Merrick, your turn. Same thing, federating services or just going into another layer of abstraction so you can spread your clouds across multiple providers. And you can, I mean, from the user perspective, you can see this as a one cloud. So those two things. Doug? Obviously, I want to see some Barbican federation, especially trying to make this sort of transparent to the things that are using the federated thing, right? So in the bubble cloud, have Nova never know that it's using a federated key and stuff like that. Cool. Joe? Yeah, I like his answer. I also, on top of that, I want to see Keystone use Barbican for the key management stuff. And I implement key rotation in one place and make that available to customers. Excellent. Klaus? Yeah, I kind of mentioned this before, but I'd like to see where we managed to get the identity management part out of OpenStack. I would like to see the same happening for authorizations. Excellent. Well, panel members, that was our last question. You're off the hot seat. I'd like to thank all of you for your wonderful answers and the insights you gave us. So thank you very much.