 Hi, thanks for coming along. So this will be a fairly interactive discussion and presentation. So we want to cover the work that CERN and Rack Space have been doing together around Cloud Federation with the summary of are we there yet? It's a topic that gets a lot of interest from a lot of people. And we want to present some work that's been going on during the last year as part of collaboration together. I think we'll introduce each other as we go along. For those of you that don't know me yet, it's been quite a summit so far. I'm Tim Bell. I look after the infrastructure at CERN. I'm the infrastructure manager. So we ask ourselves the basic question of why do we need a federation? CERN as an environment is widely distributed. It's about 11,000 scientists, hundreds of countries. Nearly every major scientific country in the world contributes people who come to work at CERN for some time but also go back to their home laboratories in order to be able to then do remote work, remote research, as they're permitted according to their teaching schedules or their other commitments. So the majority of countries are actually based around the member states, those in Europe. That's the blue set. But there's also a set of other countries that contribute. The US, for example, is contributing a sentiment towards the detectors. And some other countries who are just affiliated with CERN. Small numbers, but it's great to see the wide variety of people who all come together at CERN without any political bias. It's simply as a question of understanding and doing fundamental research. So the problem that we have then is with all these people want to have access to CERN-based resources, how do we go about doing that in a way which doesn't have a massive overhead? So the environment itself at CERN is actually widely separated across the world. So we already have a grid. This was set up in the early 2000s and it's very useful function during the first run of the LHC. The grid's set up in a hierarchical fashion, very controlled, with right at the center, the tier zero being CERN, where we record all the data. Around that, gradually increasing numbers, we've got about 12 at the moment, recently just added KISTI in South Korea. And then around 150 universities that are around that. So the challenge is that all of these people would like access to resources at CERN and equally want to be able to provide those resources to people in their institutes because from the point of view of the money flow and the skills flow, CERN could not justify putting all of that computing in a single place. To give you a feeling at CERN, we have around 200 new accounts created every month and there's a corresponding number of people who are leaving and going off to do other activities that aren't connected with CERN who have to be cleaned up. And that creates a set of needs to be very careful that we're not giving people access to resources they're no longer permitted to. But equally, if you're coming to CERN for a period of couple of months, the last thing you want to do is to spend your first week creating a large number of help desk tickets in order to get access to the resources you need for your job. So we need to have a one stop shop where you come in, you show your passport, you've given your CERN card and then behind the scenes, all the resources you need to do your work according to your job role are created for you. So when we look at what does CERN need as we look towards federated clouds, so we have a mixture of technologies that we're looking at. So there's the basic aspects of how do we go about ensuring that people can get access to the resources they want. We need to be able to ensure that where we can take advantage of public cloud resources, then we can do that without having to go through complex changes of applications. So we want the same sort of environment on our public cloud resources that potentially we could be purchasing from external sources. At the same time, we want to be sure that an individual user doesn't get access to the entire resources of CERN. We have to have a structured system that allows quatering and control according to your job role. So you can't have it that a junior scientist in a minor part of the detectors experiments gets given access to the entire resources for that experiment that are intended for doing data recording and data processing. This means you need a combination of both the identity but also the roles to be shared. So within this context, around 18 months ago or so, we were having discussions at a similar summit to this. And with Rackspace and CERN, we found that we are sharing a set of common interests. CERN has a structure under which we can do industry collaboration called the CERN Open Lab. Several major IT vendors, Intel, Huawei, Siemens, Oracle and Rackspace and Yandex are part of this collaboration. The aim behind that is to use the extreme computing demanded by the LHC to push the frontiers of IT such that the things that people will need in a couple of years that we currently need at CERN will be available and standard and well tested at that time. So basically we can battle harden using the LHC computing problems as a technology such that when the average member of industry needs that, we have already got it. We've already got it proven at scale. Open Lab at the same time is also an education vehicle. We have a large number of people coming through under the Open Lab framework and doing short periods of studies with us two weeks to six weeks over the summer. And with that, we then provide them with a set of activities to do around the projects where we're collaborating with industry. So I'll pass over to Chris with whom we had some very fruitful discussions around Federation. Thanks, Tim. Good afternoon, everyone. Chris Jackson from Rackspace had the pleasure of sitting in a cavernous meeting room in Portland about 18 months or so ago, discussing this crazy half-baked idea called Federation with Tim and a couple of guys. I'm really proud to be stood here 18 months later demoing with Marek the stuff that we've done. For the people who have contributed in the room, thank you. It's been a real team effort. We're massively proud of what we've achieved. But it's really just the start. So a quick summary. We set out in this Open Lab project to explore the feasibility of Federation. We didn't even say we'd definitely do it. What we wanted to demonstrate was Federation between a third party opens that cloud like CERNs, Rackspace private cloud, and also our public cloud. We've delivered a proven demo for private cloud third party to Rackspace private clouds. And we've got a healthy roadmap of activity to deliver the public cloud piece as well as part of our keystone work across the coming months and quarters. So what's it like working with CERN? So if you've worked in the community with those guys, you'd have got a feel for what they are. They're obviously now formally recognized super users. And they've got a common passion for open source. So at Rackspace, we love open source technology because we're a service company. We wanna make sure that the connection you have with our business is based on the quality of the service, not the fact that you can't get the software or the technology somewhere else. So we've had a great partner, a great ally to take some very big topics into a community with a very diverse set of ideas and opinions about how to solve problems and delivered a piece of code in relatively quick time for something so big to get a community united around it was a really good thing that we were able to do together. We learned a lot about what real big data is, not the big data that we all talk about. And from a personal perspective, getting out to geek out in LHC during the cold shutdown phases as well was a personal geek master and I unlocked myself. So why federate? We've talked before and if you were in Atlanta last year you'd have heard Troy talk about the concept of multicloud. So the fact that people will need multiple clouds within their environment and their portfolio to serve different workloads because of performance or cost or region, whole bunch of different reasons. But we also know that integrating cloud into your business is hard and doing it more than once is hopefully unnecessary if federation works properly. So you can integrate the federated version of cloud into your business and gain access to anyone that supports that method of federation. So what do we want to enable? Well, identity is kind of the starting block. It's the point you have to get through to better do anything else. It was probably one of the biggest and most complicated pieces and we can take that piece off. But imagine what you could do if you could take a heat template, for example, and define multicloud inside it. Imagine if your glance repository was available to all the different endpoints that you federated together. What if you were starting to talk about business rules and logic that stopped a particular application or workload being spun up in a particular kind of cloud and you had a seamless view of quota management across all those different places? Take that one step further. What if you could resell spare capacity in your private cloud? If you were something that could be federated with and you were running 75% of your workload capacity, you could sell that 25% off. What if IT in your business became a cost center rather than the cost sink? How does that change your view of how you invest in it? And think about spot trading. Like the commonality between that and foreign exchange trading is really interesting. So the stuff that we're enabling with Sir and the rest of the community right now is hopefully gonna put people on that trajectory and start to have those discussions and those debates. I think fundamentally, federation completes the democratization of cloud. It makes it a commodity because you're pushing downstream a lot of the complexity of the infrastructure layers you're making it much easier and much more subconscious to use. People have often used that analogy of as like plugging a plug into the wall and just consuming electricity. I think federation is a key part of getting closer to that kind of that analogy being true. So what are we doing next? We're actively discussing Open Lab 2015 with CERN. We'd love to take that proof of concept and extend the use cases into things you interact with an open stack every day. So things like heat templates to define how an application runs across multiple clouds in one place. Glance image availability to all of them without necessarily taking on the overhead of doing image synchronization between all those workloads. And the idea is then we can be ready to do a demo hopefully this time next year with some more new and advanced and spangly features. But this doesn't get done by the same guys. We've had a very identity centric group this year. We're looking for a wider group of people to come together around other elements, including heat, including over, including glance, start to share their opinions about how we can take this work and extend it into the different OpenStack projects. That's it for me. Mara, as far as I'm concerned, has been the brains behind this and he's the person you really want to speak to. Hi, so my name is Mara Danis and I work at CERN. I actually take care of all the technicalities of the Cloud Federation among the other contributors from IBM, Rajat University of Kent, and so on. And then I want to talk more about the technical aspects of the Cloud Federation. So first of all, if we were to summarize the hybrid clouds and the Cloud Federation to one sentence, I would say this is it. So as a user, I want to use my single set of credentials to access multiple clouds and multiple services. So I have one cloud. I want to be able to go into Cloud A, Cloud B, Cloud C, Cloud D. It's something like you very often have your Facebook or Google Plus account and instead of just creating yet another account somewhere else, you just click the login with your Facebook credentials and then, well, you have your account. You don't have to, you have one password, you have one account, right? So some basic concepts from the Federation, from the something we used for to make it happen. So identity provider, this is, this might be your corporate app, your SQL database, something where your user, where your credentials and the user account is stored, right? This is in your company. This is in your organization and you will not have any more accounts, right? Then you might have some remote clouds, some service provider, which with the trust configured between them and you could say that, okay, it's no problem having yet another account, right? But what if we want to have two clouds, three clouds, four clouds or even more? So then it might be, it might get more complicated to remember the user names, passwords and then what happens if there are some vulnerabilities and then you just need to go and change all the passwords. It's very, it's not very useful. So single local account starting the identity provider and multiple cloud service. So this is where we are aiming, this is what we are aiming. So a couple of words about the design flows we used for Ice House Federation. So the first actually the first release where Ice House Federation landed. So we based an open standard Federation protocol called SAML2. However, all the frameworks baked into the Keystone and the whole OpenStack are ready for other protocols like OpenID Connect, AppFab, Moonshut and so on. Well, service provider, so something which gives you the, what you want in this case, this is the token, something you can use for boot your machine, create the volume and things like this. This is the service provider, identity provider is the SAML2 compatible identity management service. So again, so your corporate app service, your SQL database, with some software sitting on top of this which is capable of talking SAML2. The next point is very important that authentication and authorization in this federated workflow is very split. So identity provider is responsible for authenticating the users. This might be Microsoft's IDFS, so Active Directory Federated Systems, IBM Federated Identity Manager or Shibboleth IDP. And you have service provider which is Keystone in this case, which does the authorization and they are not the same piece of software. It's also very worth saying that it's only IDP that has all the information about the users, so no cloud. However, you may wonder what happens, how can I trace my users when they log in from the remote organizations, companies? How can I see what they did, what they are doing? So from Juno release, all the events are traced, are recorded via the CADF events. So nothing is, I mean, you can still see what your user are doing so we can just account them, make them the build. Speaking about the requirements, for if you want your cloud to be able for federation, you need at least OpenStack Icehouse, you need Brighton Keystone Client 0.11, and if you want your users to use the CLI, to use their authenticated workflow, you're advised to actually use the OpenStack Client 0.5. And for some of you, this might be a sad news that we have built in federation functionalities only for the Identity API version 3, so we need to upgrade. Speaking about the federating clouds or the services and from the big picture perspective, so first of all, there's a lot of work, administrative work included, so you need to join or create your federation. Usually, these are discussions about the, what attributes certain identity providers will provide to others, federation members, what are the SLAs and things like this, then you need to exchange service providers and identity providers metadata, so we need to create a two-way trust, so we know who we are working with, we know that if somebody just provides us some identity, we will trust this is true. This is more technical part, so we're exchanging the metadata files, usually generated, and this is part of the Summable 2 protocol. Then there's one requirement for now that you need to run your Keystone on top of Apache, along with the mod shape or mod OIDC modules to be able to actually federate your clouds. However, as far as I know, there are plans for actually building those functionalities directly into Keystone, but we are not that yet. Then you need to enable your federation extension in Keystone, so this is purely work for your cloud admins and for operators. Then you need to prepare your infrastructure, so prepare your projects, domains, prepare your groups, and then create or assign roles to certain groups and projects, so something which is not very typical that usually you create your users and then you just assign them to certain roles so they can access or cannot access projects or domains. Here, we are working on groups because later the users who will be logging to our cloud and who are not local users, they will be coming, the members of certain groups. And again, a new feature you need to, via the identity API version three, you need to add your trusted identity providers, so what peers from your federation you trust. The mappings, I will talk about later about the mappings. This is a crucial point in the whole configuration and the protocols you want to handle. Once we have our cloud federated, it's time to actually walk you through the whole federated authentication process. So on the left-hand side, we have our starting active directory and we will actually use it later in the next couple of minutes. On the right-hand side, we have our cloud which and this yellow guy with the glasses is actually me. I'm a dentist, this is my real account, a certain account. And then I will, by not having the local account in the service provided in this remote cloud, I will be able to actually just behave like I was the local user just because our certain active directory and this cloud has been federating, so we trust each other. So what I need to do, first of all, step one is like, I need to connect with the remote keystone saying that, hey, I know I don't have local account, but I will want to use the federated workload. So then I will get the token back. I will then in the step two, I will be redirected to the identity provider with the SAML authentication request. The next step is that I will be challenged by the IDP, my own IDP, and I will prove that I am who I claim to be, so I will have to authenticate myself and by saying authenticate, this can be the user password credential, this can be client certificates, any authentication method you can think of. This is really up to you and your admin. And this is why the authorization and authentication is actually split. And once I'm done, I will be presented with the SAML assertion. I'm talking about the SAML because this is something we are using actively at the moment. So the SAML assertion is the structure defined by the SAML protocol, which includes, among many other parameters, it includes description of me as a personality. So this might be my login, my email address, my date of birth, the buildings I can access, and there's lots of very generic parameters which mean nothing to the keystone at the moment. But once I get it, I will just pass this SAML assertion again to the keystone and then by applying the mapping rules that had been configured beforehand, the keystone will actually come up with the credentials. So with the list of the groups, I am a member of as this federated user. So, and still before this operation, I mean, and after this operation, I can, after I boot them virtual machine, after I do anything like any other user, there will be no user created in this cloud backend. So every time I, I mean this process will be repeated, every time I redo all the operations and once, after that step, once the keystone actually applies this mapping rules on the SAML assertion, I will be granted with the unscoped federated token. So where the body of the token will actually have all the groups I am a member of after this authentication. And the next step and last step is to just scope the token to project or domain given you're eligible for that and then use it like just, you know, boot the machine, whatever you want. After each, after each step, the kind of event notification will be emitted. So this will help you to actually see what the users are doing and if they are trying to do something better or not. Real life use cases. Dragspace has built a private cloud for us just to give us a feeling of the real test but so we don't have to play on the virtual box machines because we wanted to go somewhere more into the real environment and I have prepared a short demo for you. So before we show the demo, so again, on the left-hand side, we have the CERN Active Directory. We use our Microsoft ADFS setup and on the right-hand side, there is a small private cloud located somewhere in London, I think. Yes, Kevin, so it's London and for the demo requirements, so I have prepared some projects developers, groups developers, and if you are a member of a group developers, you can access project developers and so far there's only one local admin at the moment, local user called admin and he is by default by the configuration a member of the group developers. There's no me in this cloud, there's no local user here. On the left-hand side, there's just me, I'm a Dennis and I have also configured the trust so federated identity provider and the service provider and by saying trust apart from the configure in the shiplet which is out of the scope of the stock, I configured the identity provider called CERN, I added the mapping and named it CERN and I added the protocol and named it SAML2. So it's time for the video. Yeah, yeah, I know. So on the, you can see two terminals on the right-hand side is the public cloud admin so the local user, on the left-hand side you will see all the operations from my perspective so the user, CERN user, as you can see the admin will be trying, will be using the token scope to the product developer and he's using his standard V3 password authentication plugins so he just uses with his user and username and password. So we can see that there is no local user called MADennis. I will show it explicitly. OpenStack user show MADennis and OpenStack gives us the nice error. So far at the moment there is no identity providers configured, we'll do this in a second. So it's empty, the list is empty. So, and some proof that we are using the same cloud actually for the SA user. And user, yeah. So, yeah, I also had to show the service provider you were at that actually I'm trying to burst into the remote cloud. So let's see that once the federation is not configured yet, I'm not able to actually get any token, anything like this. So why don't we just do the quick federation setup? I'm adding the service provider called service provided called CERN and just for the better output time just I will just show the ID. I'm adding the mapping, the mapping rules I will talk about later. They are stored in the rules.map file and the mapping is called CERN as well. And the last part is to add the federation protocol which ties the identity protocol so identity protocol called CERN, mapping called CERN and let's call it SAML2 and as well just nice output instead of big tables. So once again, now we can see that we have our identity provider configured and the magic is happening. So now we can see that user is able to get the token and scope to the project developers and after that user is able to list his images. He can actually boot a virtual machine and what is really worth noticing here is that I made it show here. So the name of the machine is the FedOne but the user ID is the MMADennis and on the other hand, on the other side, we can see that there's no such user in the database in the Keystone back end. So OpenStack users show MMADennis and voila, there's still error. Yeah, so now just make a proof that actually the users are, the virtual machine has booted and the cloud admin just can give you some insight that we are not cheating and the users can just work like he was a local user even though there's no one in the back end. So basically we are just cleaning up the project developers and after a couple of seconds, we will see that there's nothing left. Just short of proof that there's still no user MMADennis, so no tricks behind, there is this empty. We will also smoothly try to get to the power and the importance of the mappings actually. So far we have worked on the product developer and then the rules, I have configured the rules in a way that my federated user was able to access only the group, the product developer because he became only the access, became the member, he was becoming the member of the group developers. So let's actually see how powerful this mechanism is. So now I will try to get the token as a federated user and scope my token to a project called manager. Obviously I will fail, but if we change our mapping, which takes like five seconds, no more, in a second I will be able to scope my tokens to project manager as well as the product developer. And also breaking the trust is very easy. So in case you don't want to, some remote users to log in more into your cloud instead of just cleaning up the thousands of accounts, you can just delete or disable the provider or change your mapping rules. And then after one actually HTTP call, your users will be not able to log in again. Of course all the virtual machines and other objects will stay. So there was a lot of talking about the mapping and I said this is a key part of the whole federated workload. So to be honest, the mappings are done in the two steps. So first of all, we are leveraging lots of the work to the modules like ModShape, ModMalon, and the others and they do the hard work for us. So they accept the SAML assertion. This is, those are usually the quite complicated XML files, they parse them, they validate the signatures. So we are sure that actually some, I mean, no content was changed when the assertion was being transmitted. And they also store the assertions into the environment and only then keystone actually parses its own environment and applies the mapping rules on it. So how does it look like? So Apache modules actually do the hard work for us and they come up with something like the key value stores like the, and then the mapping engine just takes the rules, the rules configured for such an identity provider of your choice. And we end up with the keystone credentials of the user ID. Like in our case, it was MADENIS because this is how I configured the mappings and the groups his user is a member of. Then this data is used for generating the unscope federated token. It's, I realized that the mapping rules at the first glance may look kind of complicated. However, these are not. So basically this is a JSON. Make sure this is a JSON when you configure such things. And also the, so basically mapping rules are the least of the rules. And each rule has two entries. So the local and remote. And in order to be granted with the local value, you need to satisfy all the requirements in the remote entry. So, okay, the first rule is very useful but it's, so it will always map the zero attributes from the remote value. And this value will be taken from the ADFS underscore login parameter. While the second rule will assign me as a federated user a group called developers only if my ADFS underscore depth is equal to ID iOS. This is my group. And the end IDFS language is either PL or EN. If I don't satisfy one of those requirements, I will not become a member of group developers. And of course we can mix such rules. So rules do concatenate. Some characteristics of the mapping. So this is a JSON. This is our list of the rules. Rule is a dictionary. Each rule has a two entries, local and remote. Rules can be concatenated. So this is something I just said. If I have for the mapping, I have three rules and I am eligible for one and two. That's fine. I will be just granted with the groups coming from the rule one and two, not from the rule number three. At least one rule must map the user ID. And this is extremely important. This is required for identification of your users. So, and the keystone actually will complain if it doesn't find it in the credentials produced by the mapping engine. It will just give you the HTTP 401 unauthorized error. Assertions, so the incoming attributes can be semi-conseparated. So like a list of the groups, mapping engine will understand it completely. You have two mapping keywords, any one of or not any of for the positive and negative tests. And if you change your infrastructure, so if you change the projects or groups of the roles, you should also reflect those changes in your mapping rules. Because it will not be done automatically. Some good practices which may be not super clear after reading the documentation or after some discussions. So first of all, we add the identity provider, we add the mapping and they are at the first step, they are completely independent from each other. It's the protocol that ties a certain identity provider with certain mapping. So, and you can use only one mapping for the identity provider. However, you can use multiple mappings for multiple identity providers, which can be good if you're a part of the, for instance, academia federations where you agree with the one set of attributes issued by the identity providers. Also, please make one rule for mapping unique username, because this is the only chance for you to distinguish and do this distinguish between your users and you don't want to become completely anonymous and make sure that user IDs are unique across your IDPs. An email maybe is probably unique enough entry. So identity federation is ready for the production, I would say, but it's not yet perfect. There's a long work ahead of us. So far we, I mean, if you want to burst into various clouds, you still have to get different tokens for each separate cloud. So there's no one token to rule them all. We are using the Apache modules. So you need to run your keystone on top of Apache and you need to have proper modules for that. We don't have inter-cloud meta-ranking, but sharing virtual network. So actually we could just sit down and start working on the federated glance, federated neutron, federated nova, federated every service across the open stack ecosystem. So that's why I'm saying that there is a lot of work ahead of us. So please come and help with development, testing, evangelizing, documenting, just give us some feedback because we are just working for you. There are also some next steps we would like to carry on. So since Juneau release, there is a keystone to keystone federation functionality enabled where we are federating out. So we, keystone has some extra functionalities and it can work as an identity provider. So with your local cloud, you can just go seamlessly to the other cloud and all the federation protocols are hidden from you as a user. There are some plans for enhancing mapping engine. So it becomes even more powerful and you can do even more in a more flexible way. I personally think that the keystone client needs a better token handling. So the user experience is even much better. And actually, there's a time that Chris also said that we could explore nova glance, neutron and heat. That's all from us. So please join our federation session today and starting at 440 in the venue called Corot in the Meridian Hotel. Thank you. Any questions? I guess not. Okay, thank you.