18:00:37 <heckj> #startmeeting keystone 18:00:37 <openstack> Meeting started Tue Dec 18 18:00:37 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:38 <dwchadwick> hi 18:00:40 <openstack> The meeting name has been set to 'keystone' 18:00:50 <heckj> dolphm: thanks 18:01:03 <egallen> hi 18:01:05 <heckj> Agenda updated at http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:08 <heckj> #link http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:12 <heckj> egallen: welcome! 18:01:48 <heckj> Not sure what you guys hit last week - nobody updated the wiki with the keystone meeting notes, so some of the agenda topics may be moot 18:02:07 <ayoung> Hey Ho 18:02:12 <heckj> ayoung! 18:02:42 <heckj> ayoung, dolphm : Anything remaining from last weeks' agenda that's still relevant today? I just appended on Henry's requests to the list up on the wiki 18:02:59 <ayoung> heckj, we need to keep around the old Agenda's... 18:04:05 <dolphm> ayoung: http://eavesdrop.openstack.org/meetings/keystone/2012/keystone.2012-12-04-18.00.html 18:04:51 <heckj> I've been pasting the meeting notes into the wiki at the end, but it looks like last week we missed that - not sure what you covered and what you didn't. 18:05:20 <heckj> Ah, found it: #link http://eavesdrop.openstack.org/meetings/keystone/2012/keystone.2012-12-11-18.00.html 18:06:01 <ayoung> heckj, so the old action items are all on the agenda for this week. 18:06:09 <ayoung> with the exception of #3 18:06:09 <heckj> ayoung: cool, thanks 18:06:24 <heckj> #topic burning issues? 18:06:27 <heckj> Anything? 18:06:37 <heckj> I haven't triaged any bugs in a couple weeks, so haven't even looked 18:06:55 <ayoung> heckj, neither have I. Lets just make that a #action 18:07:02 <dolphm> bugsquash day was last week, so i went through a few 18:07:41 <heckj> #action heckj, dolphm, and ayoung to triage through new bugs and review open high priority bugs 18:07:54 <heckj> dolphm: any standing out that need immediate attention? 18:08:26 <dolphm> heckj: not that i'm aware of 18:08:29 <heckj> kk 18:08:34 <heckj> moving on... 18:08:36 <heckj> #topic Groups/Attributes 18:08:44 <ayoung> gyee, anything to add on " write up strategy is for implementing keyring, covering (at least) 3 uses: automated , HTTPD, CLI" 18:08:45 <heckj> ayoung, dwchadwick ? 18:08:52 <ayoung> actually, table that 18:08:58 <gyee> ayoung, I haven't get to it yet 18:09:01 <gyee> probably this week 18:09:02 <ayoung> heckj, gave it a first pass 18:09:16 <henrynash> so on groups/attributes, we have had the reviews of the api, client and wii server code this week 18:09:53 <heckj> ayoung, henrynash : what are the next steps there? 18:10:17 <henrynash> I think the action for this week as to endorse (or not) the action to submit a reference design based on RBAC as per the blueprint 18:10:38 <ayoung> heckj, I think it is relatively close in impl. We have an approach that will work for LDAP, but a SQL only version can go in first 18:11:16 <heckj> dolphm: you were providing overall feedback in there as well - any concerns on your end, otherwise general tone sounds like "move forward with it"? 18:11:29 <henrynash> ayoung: +1 18:12:16 <ayoung> henrynash, actually, can you open a ticket for LDAP backend? 18:12:25 <dolphm> heckj: i like where it's headed... i think the API & client are both pretty close to being mergeable, but i haven't completely reviewed the latest patches 18:13:06 <henrynash> ayoung: will do - we need to do something to the current server code, since the test_backend fails since it calls the ldap stuff anyway 18:13:35 <heckj> #action henrynash to open a ticket on making an LDAP backend for groups/attributes 18:13:38 <ayoung> henrynash, put skip tests in the LDAP backend for now 18:13:47 <ayoung> er, test_backend_ldap 18:14:06 <henrynash> ayoung: yep, that was the plan 18:14:07 <dwchadwick> from my perspective I dont know what the LDAP design is. I have not seen it written down anyway 18:14:14 <dolphm> heckj: if you do that ^ cite the bug number in the test skip message 18:14:22 <dolphm> henrynash: ** 18:14:23 <ayoung> dwchadwick, yes you have, we ahve been batting it back and forth in email. 18:14:26 <heckj> #agreed: continue review of groups/attributes and drive towards a SQL-first implementation 18:14:34 <heckj> dolphm: heh, autocomplete, eh? 18:14:39 <dwchadwick> So it is hard to comment on whether you have the right approach or not 18:14:41 <dolphm> heckj: +1 18:15:16 <dolphm> heckj: typing more than two characters of anyone's name is beyond my muscle memory 18:15:29 <heckj> #topic keyring 18:15:38 <dwchadwick> ayoung. But it is not finalised is it? At least you have not responded to the latest emails on it 18:15:40 <heckj> sorry, going in order on the agenda list so I can keep things straight 18:16:39 <ayoung> dwchadwick, there was one small question in the last email you sent which I haven;t responded to, but it is close. Anyway, we can nail down all the details prior to impl....I fel like we are on the right track. My concern is really mapping this sto someonerunning AD.... 18:17:38 <dwchadwick> My concern was primarily mapping the groups to roles/project, not how the groups are stored 18:17:53 <ayoung> heckj, 2 agenda additions: 1 mapping 2 register modules. We can discuss those at the end? 18:18:27 <dwchadwick> As I have said before, I think we should try to maximise code re-use not write code to be discarded next release 18:18:47 <heckj> ayoung: yep 18:18:52 <ayoung> lets move onto keyring. We can close out the LDAP impl in email 18:19:04 <dwchadwick> ayoung. agreed 18:20:19 <heckj> gyee: you were answering about keyring earlier - sounds like theres still a pending "write up strategy?" 18:21:39 <gyee> heckj, yes, I will work on that this week 18:22:18 <heckj> #action: gyee to write up strategy on keyring - HTTPD, CLI, automated 18:22:28 <heckj> anything else on keyring? ayoung? gyee? 18:22:46 <gyee> I need to do some research on how to use keyring with automation 18:23:38 <heckj> cool, moving on... 18:23:41 <gyee> which rst file should I add the stuff to? 18:23:48 <ayoung> heckj, just that I think keyring is going to be strategic 18:23:59 <ayoung> we are going to need it for anyone that is the least bit paranoid 18:24:08 <ayoung> cleartext passwords are a no no 18:24:10 <heckj> ayoung: yep, it's a good idae 18:24:15 <ayoung> to use an industry term 18:24:28 <heckj> #topic module refactoring - where to put controllers? 18:24:29 <ayoung> heckj, I haven't investigated, but I would like to see if we can use keyring to front nss 18:24:35 <ayoung> heckj, resolved 18:24:42 <ayoung> that was merged 18:24:45 <dolphm> ayoung: i prefer the industry term "Very Bad Idea(tm)" 18:24:59 <heckj> ayoung: excellent 18:25:01 <ayoung> dolphm, ISO versus NIST 18:25:05 <heckj> #topic trusts 18:25:37 <heckj> ayoung: status? 18:25:51 <ayoung> trusts keep falling behind refactorings 18:25:55 <ayoung> so right now... 18:26:02 <ayoung> https://review.openstack.org/#/c/18269/ 18:26:31 <ayoung> not sure this is 100% the end state, but we need something like this 18:26:34 <dwchadwick> I still have one issue on the design which is, the default trust should be to delegate a role to delegate so that he is your full delegate. Then you can optionally add restraints to this 18:26:46 <ayoung> it grew out of the "controllers" question from last week 18:27:04 <heckj> #action review https://review.openstack.org/#/c/18269/ 18:27:23 <ayoung> dwchadwick, I understand why you say that, but the way that we are enforcing token access won't permit that 18:27:36 <ayoung> tokens have signed in them the allowed attributes 18:27:49 <ayoung> we can't say "anything not signed in the token is allowedd" 18:28:17 <ayoung> So anything that is going to be used as an attribute has to be explicitly enumerated already 18:28:35 <dwchadwick> ayoung thinks that the default trust should be a constrained trust, whereas I think it should be unconstrained by default. then you add all the constraints you want as extra parameters. Otherwise if you have a constrained trust as the default, you will need to add some parameters to remove some constraints and other parameters to add other constraints. Which is not a good design in 18:28:36 <dwchadwick> my opion 18:28:37 <ayoung> In order to do what you are suggesting, we would need to go back to online verification 18:28:55 <ayoung> dwchadwick, so.... 18:29:40 <ayoung> I think we can make that happen, but it would require a different API...let me think if we can make it not "either-or" 18:31:04 <dwchadwick> I dont follow your argument anyway, since what is being delegated is a role. Pure and simple. 18:31:27 <dwchadwick> You need to add parameters to constrain that so that the delegation is role plus constraints 18:31:53 <dwchadwick> so the simple delegation is unconstrained delegation of a role 18:32:14 <dwchadwick> the delegate is then the role holder and has the same privileges as the delegator 18:32:51 <ayoung> dwchadwick, tokens are signed documents. That is what is used to enforce authorization. In order to delegate something not in the signed document, you wqould have to ask a neutral broker "is this OK" 18:33:21 <ayoung> When a trustee goes to get a token, that token has a set the roles/attributes assigned to it. 18:33:34 <dwchadwick> But what you delegate is the role. So the signed document says "I the delegator delegate this role to this delegate" 18:33:54 <dwchadwick> and then you can add additional constraints if you want to 18:33:59 <ayoung> If some action required an attribute not in that list, then the remote system would have to ask "is this OK" 18:34:40 <dwchadwick> I dont follow that, since all actions are authorised based on the role arent they? 18:35:06 <dolphm> ayoung: wouldn't it just be denied, since its not in the list? 18:35:06 <dwchadwick> So what other attribute are you talking about? 18:35:20 <ayoung> dwchadwick, if all you are asking is that when a user creates a trrust, by default they get all roles, we can do that. I was more thinking that there would be a deliberate option saying "all roles for this tenant" as that is just as usable, and more deliberate 18:35:24 <ayoung> dolphm, right now, absolutlety 18:36:07 <ayoung> dwchadwick, whatever ones we come up with in the future...you've gotten me sold on ABAC 18:36:09 <dwchadwick> No I am not saying the delegate gets all roles. On the contrary, the delegate only gets the role or roles the delegator wants to give him 18:36:23 <dwchadwick> This gives minimum privileges 18:37:23 <dwchadwick> When you move from RBAC to ABAC then you delegate an attribute instead of a role 18:37:45 <dwchadwick> (providing the attribute can be delegated, which is part of its definition. E.g. Age cannot be delegated) 18:37:53 <dolphm> (roles are attributes though, correct?) 18:37:59 <ayoung> dwchadwick, right, but there are likely to be more attributes on heaven and earth than dreamt of in our philosophy... 18:38:06 <ayoung> dolphm, yes 18:38:12 <ayoung> roles are attributes 18:38:15 <dwchadwick> Yes, they are a subset of attributes that can be delegated 18:38:33 <dwchadwick> You can delegate all roles but not all attributes 18:38:54 <ayoung> dwchadwick, ok, we are in violent agreement, I was just trying to future proof 18:39:10 <dwchadwick> You can delegate roles, group memberships, project participation, stuff like that. But not personal attributes like age, hair colour etc 18:39:22 <ayoung> dwchadwick, I will make it such that it is easy to say "this trust delegate all roles for this user/tenant" 18:39:25 <dwchadwick> But all can be used for authz 18:40:18 <dwchadwick> I would say that if the delegation has an optional parameter which is a role, then if the role is present only that is delegated, but if it is missing, all roles are delegated 18:40:35 <lifeless> primeminsterp: alexpilotti: hi. hyper-v/quantum sounds excellent; my plate is kinda full atm though :) 18:40:46 <dwchadwick> But I dont really like delegation of all roles since it is not least privileges is it 18:40:57 <ayoung> dwchadwick, I think I am more comfortable with "either/or" either you sepcify "these roles" or "all roles" or the create fails 18:41:14 <dwchadwick> ok 18:41:14 <ayoung> specify 18:41:43 <dwchadwick> That's trusts done then. 18:41:51 <ayoung> cheers 18:42:03 <ayoung> #topic mapping 18:42:06 <ayoung> ? 18:42:17 <ayoung> actually 18:42:22 <ayoung> one thing that trusts really needs is 18:42:28 <ayoung> tokens scoped to endpoints 18:42:55 <ayoung> we can do trusts without that, but it is far wiser to plan for it up front 18:43:12 <dwchadwick> Tokens scoped to endpoints is nothing to do with trusts though is it. It should be an orthogonal issue 18:43:25 <dolphm> heckj: ping ^ 18:43:36 <dwchadwick> In other words, the original role holder may want a token scoped to an endpoint 18:43:39 <ayoung> dwchadwick, correct, although what do we do with existing trusts we add it to tokens 18:43:45 <heckj> sorry, distracted at work too 18:43:48 <ayoung> I'd rather it be like the roles 18:43:50 <brich1> ayoung, dwchadwick...and the ability to designate a delegate needs to be under administrative control, else separation of duties is impossible 18:44:18 <ayoung> brich1, you mean an admin can create a trust for me? 18:44:19 <dwchadwick> I think we agreed that Keystone becomes a trusted delegation service 18:44:32 <ayoung> dwchadwick, yes 18:44:42 <dwchadwick> All trusts have to go via keystone. If you dont hold a role, keystone wont let you delegate it 18:44:55 <ayoung> dwchadwick, I'd rather have the token scoped to endpoints nailed down, even if it isn't implemented 18:45:03 <ayoung> when trusts go live 18:45:17 <dwchadwick> If you do have the role, keystone will add an entry to the delegation table saying that you have given it to someone els 18:45:18 <dolphm> ayoung: are you proposing changes to identity-api? 18:45:41 <heckj> ayoung: dolphm: do we have a proposal on how to bind tokens to endpoints? 18:45:41 <brich1> ayoung: and/or preclude you from allowing someone else to become you from an authz perspective 18:45:59 <ayoung> dolphm, I think it will be a change to the auth_token middle ware 18:46:16 <dwchadwick> I see that scoping a trust to an endpoint is a useful constraint 18:46:17 <ayoung> heckj, but also adding an option to scope a token to a set of endpoints 18:46:28 <gyee> +1 on endpoint scoping 18:46:37 <ayoung> heckj, it has been discussed, but I don't think we have a blueprint 18:46:40 <ayoung> let me look 18:47:00 <dolphm> heckj: i'm not aware of one 18:47:03 <ayoung> I don't see one 18:47:09 <dwchadwick> I am happy to contribute to the blueprint on this as I think trusts/delegation is an essential feature for openstack 18:47:11 <heckj> Sounds like that's the first thing we need 18:47:13 <ayoung> #action write up blueprint scope token to endpoints 18:47:27 <dolphm> heckj: i see the notion as being valuable, but i'm lost on where that would be enforced 18:47:50 <dwchadwick> Whilst on endpoints I think we need a new API which is "return me the endpoints for this service" 18:48:03 <ayoung> dwchadwick, I'll send it to you for review. 18:48:32 <dolphm> dwchadwick: GET /v3/endpoints?service_id={service_id} 18:48:42 <dwchadwick> It should be enforced in the Token Issuing and Token Validation Services 18:49:06 <dwchadwick> dolph: good 18:49:10 <ayoung> dolphm, dwchadwick but also scoped to user, no? 18:49:12 <ayoung> so 18:49:30 <ayoung> GET /v3/endpoints?service_id={service_id}&user_id={user_id} 18:49:56 <dwchadwick> I did not know you could set an endpoint for a user 18:49:59 <dolphm> ayoung: endpoints don't have users 18:50:02 <ayoung> however, that information should be encoded in the token 18:50:15 <ayoung> dolphm, don't users have a subset of endpoints to which they have access? 18:50:16 <gyee> right, should be in the token 18:50:22 <ayoung> Even if it isn't enforced now? 18:50:27 <dolphm> ayoung: not in the current implementation 18:50:49 <gyee> we also need to be able to assign endpoint to projects 18:50:58 <ayoung> gyee, yes 18:50:59 <gyee> and filter endpoints on token validation 18:50:59 <dolphm> ayoung: well, either you have is_admin=True and you see adminURL's in your catalog, or you don't, but that's it 18:51:00 <dwchadwick> mixing up two issues. Enpoints associated with services, and what a user is authorised to access 18:51:18 <ayoung> dwchadwick, right, but ypou need both in the query stage 18:51:37 <gyee> I can start a bp on that if that's OK with y'all 18:51:47 <ayoung> lets blueprint that, even if the implementation for now will be "all users can see all endpoints" 18:51:47 <dwchadwick> ayoung. right I can see that 18:52:04 <ayoung> gyee, can you take that one? 18:52:15 <gyee> right now we are returned everything in the catalog known to mankind 18:52:43 <dwchadwick> another way of looking at tokens, is that they are simply pointers to state held by keystone 18:52:53 <dolphm> gyee: keystone legacy let you map tenants to endpoints, so you had to have a role on the tenant to see the associated endpoint 18:52:55 <heckj> gyee: tossing up a blueprint and basic design would be great 18:52:57 <ayoung> dwchadwick, correct 18:53:02 <dwchadwick> so they dont need to hold all the information themselves, but just be a pointer to it 18:53:18 <ayoung> dwchadwick, but they are also a load-management mechanism 18:53:37 <dwchadwick> ayoung. Dont follow that 18:53:38 <ayoung> the idea is that they should be self verifying, to keep services from having to go back to keystone to verify 18:53:44 <gyee> heckj, will do 18:53:56 <ayoung> dwchadwick, one reason why tokens went PKI was that they were Identitied as the chattiest part of openstack 18:54:07 <dwchadwick> ayoung. Why cant the client cash the result after getting the first verification 18:54:11 <ayoung> not necessarily for security, but to decrease network load 18:54:17 <ayoung> dwchadwick, revocation 18:54:23 <ayoung> I mean, they do cach for a short time 18:54:23 <heckj> ayoung, gyee: key quandry that might be tricky - how services know which endpoint they're assocaited with - today I do'nt think they do, will need to take that into account 18:54:35 <ayoung> but role assignemetns changes, etc 18:54:51 <dolphm> dwchadwick: tokens are passed around, each recipient needs to validate each token 18:55:16 <dwchadwick> that sounds Ok to me 18:55:27 <gyee> the other benefit of endpoint scoping is security 18:55:46 <dwchadwick> the alternative is to have an encrypted signed token than anyone can validate but you still have the revocation issue 18:55:55 <gyee> say each endpoint have an account in Keystone and have its unique private/public keypair 18:55:57 <ayoung> dwchadwick, it just puts the onus on the user (or the client) to figure out up front "what should I put in this token" 18:56:06 <gyee> we can essentially issue a token for just that endpoint 18:56:12 <ayoung> gyee, yes, that is the "delegation" blueprint...sort of 18:56:16 <gyee> only that endpoint to decrypt the token 18:56:26 <ayoung> gyee, then those endpoints can sign tokens 18:56:28 <gyee> ayoung, amen brother! 18:56:45 <ayoung> https://blueprints.launchpad.net/keystone/+spec/delegation 18:56:53 <dolphm> gyee: how is that different from the "service user" pattern people use today? 18:57:13 <ayoung> OK, can we talk mapping in the last 3 minutes? 18:57:19 <gyee> token, if I can capture a user token, I can use for all the services user have access to 18:57:25 <dwchadwick> yes mapping please 18:57:38 <heckj> 3 minutes left 18:57:42 <dwchadwick> Kristy has put the first code up for QAing 18:57:43 <ayoung> mapping is posted for review. I've made minor corrections, but the code looks clean for the most part 18:58:14 <ayoung> We need to understand it better, and part of that is showing how it can be used fro a non-trivial application 18:58:14 <dwchadwick> What we would like to suggest is that groups uses mapping for working out which roles the group members have 18:58:27 <ayoung> that might be in the unit tests, I haven't processed that yet 18:58:56 <henrynash> I owe david/kristy a review of it - will get that done tomorrow 18:58:58 <ayoung> but it might be beyond the scope of unit tests. I would like to see an example, though, of mapping code in use. 18:58:59 <dwchadwick> Agreed that having good use cases is valuable 18:59:28 <dwchadwick> Henry should be able to produce use cases 18:59:39 <kwss> My next step is to work it into the federated authentication middleware 19:00:00 <ayoung> kwss, I guess that mapping isnot really usable withou tit, is it? 19:00:22 <ayoung> Does mapping somehow stand alone without middleware support? 19:00:24 <dwchadwick> we thought Henry was going to use our code but currently he hasnt started 19:00:39 <ayoung> can use use mapping to convert som other attribute to a role? 19:00:42 <kwss> Not unless the ability to assign internal user attributes is added too 19:00:44 <dwchadwick> My plan was that the first use of mappings would be groups 19:01:00 <ayoung> ...I am think that should come before customer middleware 19:01:05 <ayoung> custom 19:01:09 <dwchadwick> I have explained this migration path several times before 19:01:17 <heckj> I'm afraid we're out of time... 19:01:32 <heckj> I'll put this at the top of the agenda for next week, and we can continue in email? 19:01:44 <heckj> (or just take the conversation to #dev)? 19:01:45 <dwchadwick> yes 19:01:47 <ayoung> dwchadwick, kwss write that as a use case 19:01:53 <egallen> Agenda for next week : Multi factor ? 19:01:59 <gyee> I won't make the meeting next week, holiday closure here 19:02:00 <ayoung> egallen, +1 19:02:04 <heckj> will add 19:02:10 <heckj> #endmeeting