 We will look at federation of keystone v3 api and what we have done in the last few months since I last gave a talk on federation. Federation just for those people new the topic it means that the service provider does not authenticate the user. The service provider has a trust relationship with an identity provider and the user authenticates the identity provider, the identity provider provides an assertion ...cynnaeth y bwrdd y cyfnod yn cyfrifio cyrraffi... ...onno, oedd y cyfnod y bydd y bwrdd y bydd y bydd iawn y cyfrifio... ...onno, wedi cael eu gwneud... ...y'r cyfrifio ar y cyfrifio. Felly mae'r ffordd. Mae ffordd yn lawer o'r ffordd o'r cyfrifio'n bobl... ...y'r ffordd o'i gwaith, maen nhw. Mae'r ffordd o'r bwrdd y bwrdd y bydd yn cael eu cerddol... ...y'r ffordd o'r bwrdd y bydd yn cyfrifio'n cyfrifio... They trust Keystone Right? And so the user goes to Keystone He authenticates Keystone gives the user a token Ann the user gives the token To SWIF, Glance, or whatever And because they trust Keystone They trust the user being authenticated correctly So all we're doing really Is extending the model So that now, Keystone Doesn't authenticate the user Your organisation does My organisation does So I go to the University of Kent and I authenticate there with my existing credentials. There's a trust relationship set up between Keystone and the University of Kent's identity provider and that provides an assertion to Keystone that I've been authenticated correctly. So it's a very simple model. It works very nicely. It means that you no longer need to provision users in Keystone because all of you guys have been provisioned back in your organisations. You've been registered into your organisation systems when you start, when you get promoted, your attributes are altered in the letter, that directory or whatever and when you leave they remove your entry. So we're going to rely on these external identity providers to authenticate and manage the users for our cloud service. No religion please. Everybody, most people believe there's a god. The god got different names for the god, okay? You know, an enter your favourite name here. It can be whatever your god is. Similarly, we believe there is a federation protocol but we don't care what it's called. They're all doing the same thing. They're enabling that three-way authentication and assertion to work. So we built a system that is protocol independent. You can plug in your favourite federation protocol. If you're using SAML use SAML, if you're using a OAuth, if you're using some private protocol, use that. We don't care. We shouldn't care. Because what will happen in the next decade another federation protocol will come along. Sure as anything, before I'm dead, there will be another federation protocol. We want to be able to plug that in to OpenStat and change in anything else other than the protocol-specific bits. Okay? So we've just got one protocol-specific module that has three methods that are called on it. The first method is get the request. Get the request that the user is going to give to the IDP. The second method, which is optional because most protocols today do not need this. There's only one that we've come across so far that doesn't. That's the IT ABFAB work and that's got this negotiation bit in the middle. And then the second one, which everyone implements, is validate the response where the user gives the response to Keystone and Keystone calls the protocol-dependent module. It says, here's this blob that I've got from some remote party. Please check it out for me. Okay? And then all of these protocol-dependent modules will give the same output. So the protocol-independent code that we've written will get the same output regardless of the protocol that's been used. And what is that output? It's essentially three parameters or three sets of parameters. First of all, some ID for the user. An ID that's been generated by the IDP as a unique handle on the user. Next, a set of identity attributes. You work for Organization X. Your role in Organization X is manager. You've got qualifications or whatever, your age. Whatever they want to assert, they assert those as identity attributes along with the name of the IDP that asserted them. And in fact, we've actually built attribute aggregation into the system because we support set of sets. But that is a feature that people are not yet discussing here. It's more sort of a research feature. Finally, the validity time of the assertion. Because usually you find in all these identity federated management protocols the assertion that comes has a time limit on it because they don't revoke it. So they don't want to build revocation in so they will give you an assertion that says this is good for one hour, two hours, 24 hours of weather. Actually there's an exception that is PKI. If you're using X5 and 9 PKI for authentication then you usually got a long lived credential which is valid for probably a year or something and then you have to have revocation. But in that way the protocol independent model would have to deal with that and it would have to tell you'd have to configure it to say well let's have the let's just leave it for basically the period between the CRLs. You know if you're publishing CRLs every 24 hours you may as well say this assertion is good for 24 hours till the next CRL comes because you will have checked the CRL when the user came in. So those are the three outputs. Now how do we configure in trust in the IDPs? Because we said trust is an essential component in federation. Keystone has to trust the IDPs because it's getting assertions about the users from them. So we do this by configuring into the service catalogue not only the names of the local services like Swift, Nova, et cetera, but also the IDPs that are trusted. So we put that into the service catalogue. If you're in the service catalogue you're trusted the type of the IDPs in there so that our code knows which protocol dependent module to call because the type will say if it's a SAML, I'll call the SAML module, if it's an OAuth version 1, I'll call the OAuth version 1 model, et cetera. So the type is there. And then any protocol specific metadata that's needed by the protocol specific module to actually process the response. In the SAML case we need an X59 certificate because the SAML message is signed and we need to check the signature and make sure that the assertion came from the IDP and was signed by the IDPs. So the metadata in our case for SAML has an X59 certificate there. So that's how you're configuring trust in the IDPs. So if the IDPs are not in the service catalogue it cannot be used by the user and the user can't log in with it. So that's how you've got your trust built into the system. From a user perspective we have to have modified client software because the client software has to know how to deal with federation. We've modified Swift and a couple of other ones and we've put a minus F on the command line so when you type the command line in type minus F you're telling the software I want to do federated logging and that causes a new header to be put into the message that is sent from the client to the API and we've defined the message type as X authentication type federated. So we've got a new header in the protocol which goes through to Keystone and then what we've done we've inserted a new module into the Keystone pipeline and that module when it sees the federated X authentication header it says that message is for me and it grabs the message out of the pipeline it does the processing. When it's finished the processing it then passes it back. In fact usually it passes a response back to the user. So that's how it works with this one module put into the pipeline. So the gory details this is the header that is on all the federated messages so that the module in the pipeline knows to grab it and process it. If there's nothing in the message no body but just the header then it says ah I know this is a new session I need to go to the service catalogue pick out the IDPs and send them back to the user to the client and then the client in its own way will work out show them to the user and get the user to pick where you're from and which IDP do you want to use. If you get the header and the body contains a JSON array containing an IDP request element and an IDP in there it means the user has chosen an IDP and this is where he's going to go to do his authentication. So in this case it calls the protocol specific module it says get me an IDP request in this protocol language and it sends that back to the client software. If the header comes in and it's got the IDP negotiation element then it calls the protocol specific module it says this is negotiation it gets the next version of the message and it sends that back to the client so the client can continue negotiating with the IDP and finally if the body contains the IDP response then it says aha I know I've got the response now I'll call the protocol specific module to validate the response and actually get the identity of the user back. So what happens next? What happens next is the magic if you like of federation and there are two bits of magic that are in there. First of all auto provisioning there are no users in the Keystone database when a user logs in via the IDP a temporary entry is created in Keystone with a validity time that the protocol dependent module told us that the assertion was valid for we put the temporary entry into the database it's there and then when the validity time expires it's removed so there's no provisioning to be done on entries by the Keystone administrator because every time you log in the temporary entry is created it then times out and it's exactly the same temporary entry that we created the same parameters providing the user's not changed if the user's changed and he's been promoted then obviously there'll be some different attributes in his entry so that's the first bit of magic is the auto provisioning the second bit of magic is attribute mapping so the user exists at the identity provider and has a set of attributes that are asserted by the identity provider such as you work for organisation X you've got a role of manager you're working on project Y or whatever they want to assert about you and the attribute mapping converts that into the identity that's recognised by Keystone in terms of roles projects and domains so what comes out now is something that all the Keystone all the open stack services can work with because they say I know who this user is he's got this role on this project in this domain and then it can authorise the user and every time the user logs in he'll get back the same open stack identity and then he'll get the same access rights that he had last time he logged in so those are the two bits of magic so some of the key features then it's a modular design most of the functionality in a protocol independent way so that you can plug in your different protocol talking modules whatever your religion is whatever you like you plug that one in and it'll all work and we've already validated that which I'll say in a minute so what are the protocol independent bits and there's the enhanced service catalogue that allows you to store the IDPs with the metadata in there and we retrieve that and use it there's an attribute issue in policy which says which IDPs are trusted to issue which identity attributes that allows that allows you to control the IDPs and what they're going to give to Keystone and if an IDP asserts an attribute it's not allowed to assert it'll be thrown away so for example you work for organisation X and that IDP says you work for organisation Y well when the attribute is given to our code it'll look at the policy and say okay you've come from IDP X but it says you've got attribute which is organisation that's not allowed and it will remove it okay so that policy allows you to control which attribute you're prepared to have from which IDPs the attribute map which talked about which does the conversion and then the bit I'm going to talk about in the final bit of the talk is delegating permissions we need to know more about that because this is a scaling issue it's not an issue when you start off with a small federation you don't need to delegate permissions to IDP administrators but when the federation gets big you actually need something like this okay and then there's one plug in module with three methods and obviously clients have to be tailored to support federation so how do you go around how do you go about initialising Keystone well Keystone admin the first thing he does he goes to the service catalogue and he adds the list of IDPs that he's going to trust he adds the type, the protocol they speak and he adds the metadata that is needed by the protocol specific module and that's set up the trust relationship he then adds the list of identity attributes that may be asserted by the particular IDP so he's actually creating the policy well sorry, he actually creates just a set of attributes and then he creates the policy from the attributes because you have to insert the attributes first before you can create the policy so an example of the policy might be the University of Kent is trusted to assert the edu person affiliation the edu person organisation distinguished name and you can put values in it as well if you want and then he creates the attribute mapping policy which says which values from which IDP will create which open stack attribute so there's an example here if a user comes in and he said edu person staff these are very strange looking attributes to some people here but they are actually the real attributes that are used in the academic federations around the world today so this edu person affiliation is actually what real live federations are actually sending around today so edu person affiliation staff edu person university of Kent country equals GB we will map that into project Kent role staff and the next one is if it comes in with affiliation of student we will map it into project Kent and role students so now you know which of the services they will be able to have access to so federated login then the user contacts keystone sends the header and nothing in the body and keystone traps the request looks at the service catalogue picks out the list of IDPs returns them to the client now the client in whatever way it wants this is a client specific manner it will have some picking list some filtering it might use the NASCAR solution where you have a lot of logos for different things and it clicks a logo whatever you want that is up to you when you build your client how you actually get that choice across to the user in our simple command line implementation we just list them with numbers and the user just picks number one number two and number three or number four whatever and then that will be sent back to keystone telling him which one is chosen so after that the user as I said he chooses chooses it sends a request to the IDP when it came back from keystone and we support two modes of interaction initially we supported under the direct mode of interaction where the user client was talking directly to the IDP because that's how SAML works that's how OAuth works however we started to work on a new protocol which is the IT ADFAB protocol that protocol the client actually talks to keystone and then the protocol specific module in keystone talks to the IDP so we now can support direct communication from the client to the IDP or indirect communication from the client to the IDP via keystone so there are two different modes that are supported to cater for the full remit of protocols that you get from federation finally after the user is authenticated and the client's got the response back saying you've been authenticated and you've got these attributes that is sent into keystone with the body of the IDP response user authorization remember user authorization it's only half of authorization it's only the user to attribute assignment the authorization of the privileges to the attributes the roles, the projects it's done by Swift, it's done by Glance etc they are the ones that are authorizing the user based on their attributes all keystone does is assign attributes to users so it's only half of the the authorization that's actually done so if in controller calls a specific module to say validate this response protocol specific module validates the response it's got from the IDP and it returns keystone or to our code this unique ID for the user the set of identity attributes and this expiry time, this validity time for how long the temporary entry's got to be created for and then the FIM controller deletes any temporary entries that are hanging around from last time it was called that gets rid of those and then it creates one for this user if the user has logged in twice within his validity time then what we do is we update the enter we just update the validity time or in the future we don't bother deleting it and restarting it we just update it and that means that any tokens he's got are valid this means a user could have two sessions he could actually have two simultaneous sessions with different open stack VMs at once because the same entry would work for both and then finally the FIM controller calls the issue in policy to check that the attributes that will return from the protocol specific module are valid if they're not valid it'll throw them away but if they pass the policy check he says okay they are valid all I need to do now is map them into the keystone roles so it then maps them into the roles and projects and puts those into the temporary entry so now the entry has all the authorization privileges or permissions anyway in terms of roles that it needs and then it returns an unscoked token to the client and that's it the federation's finished now the user client has got an unscoked token and it continues as it does today so yeah an unscoked token is a token that hasn't been scoped for a service so keystone initially will if you don't say which service or project you want it will return you an unscoped token then you choose your project and then you get a scoped token that's the standard design of keystone at the moment okay so in terms of validation we've implemented this with two different protocols at the moment we've done it with SAML v2 and we've done it with keystone to keystone so you can now set up two keystones and you can use one keystone as an IDP to authenticate users to a second keystone so you can actually have a whole bunch of different keystones and allow users to access them all by logging into one central one and we're currently implementing the IT Abfab protocol suite which is based on Radius, Eep and SAML now we've talked about delegating permissions what we've done so that is fine for a small federation but look at this in the UK there's now 730 IDPs if you want your keystone administrator to administer 730 IDPs you may say I complain I object can't we sort of delegate permissions out so what we've added is a delegation permission thing which allows the keystone administrator to delegate to each of the IDP administrators the ability to manage his IDP in terms of the attributes it will issue so what the keystone administrator does he says you are responsible for your IDP but you're only going to get access to this domain this project and this role maybe a domain in two projects that's all you've got access to I don't care which attributes your IDP issues it's not in my business you know you can do the mapping if you get it wrong your users won't get access if you get it right they'll get access to just what I've given you access to so in that way the keystone administrator keeps tight control of the overall permissions within OpenStack but he gives the freedom and the flexibility to the IDP administrators to manage the mappings because they know what their IDPs will issue and they know what which people they want from their organisation to be mapped into which roles and projects that are under their scope so that's what it is so the keystone administrator does the following first of all it creates a user entry for each IDP administrator using the standard existing API it creates a set of roles using again the standard existing API he says which administrator has which role which is again using the standard the standard keystone API and then the new API we've added is he gives permissions to the admin role and those permissions say you are entitled to map into the following OpenStack keystone known roles, projects and domains for the following IDPs so it's a many to many mapping you could have 50 IDPs and 10 administrators and they could administer 5 each you've got that freedom there to say how many, or you could have two administrators administrating one IDP because you've got the freedom and flexibility when you're putting the permissions in there so what does the IDP administrator do when he's got the delegated permissions he logs into keystone through the existing API using his username and password on the database which are the anti attributes that his system is going to issue he adds a new attribute issue in policy to say that only my IDP is going to issue these if they're actually private to his IDP he adds a mapping policy to say these attributes must be mapped into these project roles and domains and in that way he's controlling it and if any other IDP tries to issue his attributes he's thrown away because the attribute issue in policy won't allow them to do that so what are the implications of this federated infrastructure one implication is the user is authorized based on the IDP of certain attributes not based on anything in keystone essentially it's on what he gets from his IDP because they actually will drive the whole process so if the service wants the user to be authorized using ACLs and UUIDs then the IDP must provide some unique identifier on every time the user logs in and the assertion and the protocol specific module must say this is the ID that this user has and then we can actually make sure that when we create the temporary entry the temporary entry has the same UUID every time and then the ACLs will still work but that's not our problem that's the IDP's problem to make sure it can do that in fact all IDP's can do it but they're just going to make sure they do do it the identity attributes are mapped into keystone underneath so that means actually the new feature that's just been introduced in Grizzly called groups is not actually needed because it can be subsumed by the attribute mapping feature because the attribute mapping feature is a generalisation if you like of the groups feature because the groups feature is only specific for one attribute type which is groups whereas the attribute mapping is general for any attribute type when we were coding up we found we had to have specific code for roles, tenants and domains because they're in separate data structures rather than one table generic code which says this is a role attribute, this is a tenant so one of the implications and we've talked about this on the keystone list is it will be very nice if we could generalise the table roles and projects and domains and actually make them into one table and that would make the thing more efficient and it would certainly reduce the amount of coding because you don't have to write three lots of code one for each table to pick the information out of separate tables you can have one lot of code that picks out of one table so that's an implication so there is a public demo it is available you cannot use it from the open stack SID but port 5000 blocked and the demo is actually on the keystone standard port which is port 5000 so unfortunately we tried the demo, it doesn't work using the local area network here because they're blocking the port but if you go back to your hotel room you'll probably find it works because I can use it from my hotel room but there is a second network here so if you want to do a demo what this requires is that you have to install obviously a federated client so what we've put on our demo page is an updated SWIFT client so it's the standard SWIFT client in the open stack release but it's been enhanced to support federation so you'll have to install that on your computer and then when you call that client over you'll have to install that and when you call that client up you just put a minus F as a new command option in the command line parameter and then the federation will work and you can do the demo that we've got if we've got time I can actually I've got some screenshots of the demo but let's leave it for questions if there are no more questions I can actually show you screenshots of the demo so do we have any questions? What happens when I change my affiliation and also my affiliation is more administrative a lot of large identity providers they provide identity for lots of different clients and so to say well I'm going to change my roles and put attributes just for this guy who's using a cloud somewhere and maybe he uses 10 different clouds that use the same thing it would seem that pushing the roles and attributes up to the the identity provider will become problematic Okay so the first two questions there the first question is what happens if you change your organization right you change your organization your entry is removed from your organization's IDP so if you go and try and log in to Keystone and you say I'm going to use my organization you'll find you can't log in your organization won't log in so you're ruled out well no when you're on they don't because I had a sabbatical last year and I could still well if they take you out but the point is they've deep provisioned you they're saying while you're away you can't use any university resources well that's up to them well that's up to them the point is they're saying you've gone and we're removing your privileges and you're saying but I don't want my privileges removed well take it with your IDP administrator okay well that's that's not our problem is it I mean if you're not if you've left your organization for whatever reason you expect the organization to remove privileges from you if they didn't they'd have a security vulnerability because they'd have all these pensioners who could still come along and log into the system and start using the resources so and then the new organization you've gone to they'll clearly add an entry into their system for you if you've got a set of attributes and roles which is similar to your neighbor at the next desk then when you go to the cloud you would probably get exactly the same permissions as your neighbor on the next desk with exactly the same role as you because the mapping is but if you want to make the permissions individual in the mapping you put in the ID so you say on the person with this ID is going to get these keystone projects roles tenants and then you can make it on a per individual basis but that is up to the IDP administrator when they put in the mappings in to decide how they're going to deal with their user base right but you are wanting the keystone administrator to be responsible for those 3,000 and another 3,000 and another one someone's got to do it right right no no no no no it's not that no because we have in the UK we've got over a thousand organizations in the Federation there's a trust relationship between the service provider and the identity provider so keystone has had to put into it that it trusts the IDP similarly the IDP has to be configured to say it trusts keystone because if you go to an IDP and say hey just give me the identity attributes of this guy I don't know you you're not in my trust list so there has to be a relationship set up I only talked about the relationship at the keystone side but there's a similar relationship has to be set up at the IDP side but I didn't address that because IDPs will handle that in their own specific way you can always go back to fine well you don't have to all the stuff we've added it's completely backwards compatible you can completely ignore the whole lot and go on as now just putting your users into keystone that's fine so I don't know if I did answer all your questions I'm not sure we had a long discussion if you've got another one ask it in a minute my question is about the token so I assume that when you use a login and an IDP authenticated and issue a token back so there are two questions over here one is to track to a keystone database and the second question is how do you track the token where it is expired right ok so first of all the token is generated by the IDP in the protocol specific way so you have to look at the standard for the protocol you're supporting as to how is that token protected and different federation protocols protect them in different ways so it might be symmetrically encrypted it might have a Mac on it that is independent of the stuff we've done we say that is a protocol specific issue where does it go to it goes to the protocol specific module that's been plugged into keystone it gets this token because it talks to protocol it knows exactly what to do with it it knows how to validate it and it returns to our code I've validated this token and this is the information I've got from it the ID for the user and the validity time and then it's thrown away then the token's gone so how long is it valid for the validity time was returned to us so they picked the validity time from their token passed it to us and then we create the temporary entry for the same validity time does that answer your question sorry the token is not stored in the keystone database the token is processed by the protocol dependent module and the information from the token is returned to our code and the token is then thrown away but the information from the token causes a temporary entry to be created in keystone's database so it's not the token but it's the information from the token correct and we have not touched that bit of code at all so once we've created the temporary entry we've finished we then pass over to the existing code today say there's the user's entry give him an unscoped or scoped token and we've finished then now the fact that the entry we've created has a time stamp in it is completely ignored by existing keystone code today because they don't know it's there so the fact that the entry we've created is a transient entry is completely impervious to all the existing code today only our code looks at it and when it sees the time stamp has expired it removes the entry it does the validity time does pass we've made sure that you cannot have a keystone token of a longer validity time than the validity time of the entry so we do pass that down to the creation of the keystone token yeah so I'm wondering if there's any support for non ephemeral user data in keystone so that you can say external identity provider for authentication but in my case I've got a corporate LDAP that I can never ask them to add anything to so we want to have maybe attributes stored that are specific to our cloud instance right what the code does is if there's no validity time it creates an entry like now so if the protocol specific code decided that this wanted to be a persistent permanent user it would return a null validity time to our code and then the entry will be created without a validity time in it but the problem you've got then is when you're tied to them up and how do you clear them out I was thinking more like merging having some persistent data associated with the user but not the actual token what we do there is if there's an entry already in the database whether it's temporary or permanent when it comes in again the entry to match is current token so if you've been promoted or demoted since you last logged in your attributes will be changed in your entry so you'll get a demotion or promotion in keystone according to the mapping so we don't let you keep your old credentials in the new session that's the whole point that's just what I said his IDP picks up the attributes from their LDAP and sends them to our code and then they put a mapping rule in to say from those attributes that are in the where are they? I'm thinking more like if the attributes can be defined somewhere else and merged I did briefly say attribute aggregation and we've actually built that into the system because we allow attribute aggregation we allow different sets of attributes from different identity providers to be returned and we've got a whole infrastructure that supports attribute aggregation but there are no federations that I'm aware of today that are actively supporting attribute aggregation yeah yeah absolutely absolutely absolutely because because it's a protocol specific plug-in module all we do is we give the token to it and then it returns to us what it wants to return so it could actually make an LDAP call to somewhere or HTTP call whatever it wants to do totally independent of what we do because we just say that's up to you that's your religion you're going to do you know if you want if Sammel wants to pray five times a day then Sammel can do that yeah we don't care any other questions okay I think I think we do to finish anyway now at 10 past are we not okay last question yeah so what's the plan to have this code in our stream right okay at this morning's session this was discussed and it's not finalised but the suggestion is that this becomes an additional plug-in to the grizzly release so in the next six months this code will be an additional plug-in that you can choose to incorporate into your release or not so it won't be part of core but it will be there to be plugged in that's my understanding of what was if anybody else was there at the meeting this morning I've got someone nodding so so that's the plan so you will be able to use it within six months time but it won't be standard part of the code because we want people to get experience of it we want them to see how it works etc and if they're happy with it then it could in the next six months after that it could then become part of the code so that's my understanding of the plan okay well thank you very much Sam