18:00:28 #startmeeting keystone 18:00:29 Meeting started Tue Jan 8 18:00:28 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:32 The meeting name has been set to 'keystone' 18:00:53 #topic team membership updates 18:01:10 http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:55 heckj, I think this one is yours to address.... 18:01:58 heckj made a couple nominations for 'core' contributor status on the mailing list last week (guang-yee & henrynash) 18:02:12 this is definitely heckj's to address 18:02:28 i'd also like to throw a belated +1 for henry-nash into the ring 18:03:34 Well, for now, lets assume that it is a done deal. I think we are all in agreement. 18:03:50 \o 18:03:50 i guess we can leave that topic at that until heckj shares the "verdict" 18:03:54 gyee: /salute 18:04:14 yep /O 18:04:17 #topic High priority bugs or immediate issues 18:04:24 anything exciting going on? i'm not aware of anything 18:04:36 0 Critical 18:04:41 I am working on separating out authentication, token validation 18:04:45 16 High importance 18:04:51 gyee: on the road for v3? 18:04:54 yes 18:05:03 I am hooking up google 2-factor auth as well 18:05:14 with any luck, I should have a WIP review this week 18:05:14 gyee: awesome, joesavak and chmouel will be thrilled :) they've both been asking about auth support on v3 recently 18:05:20 gyee: i look forward to it 18:05:21 gyee, nice 18:05:28 indeed 18:05:35 on multifactor, can you spec ouyt how it will look inside the token data? 18:05:39 #topic multifactor 18:05:48 speaking of which 18:05:51 so we have "password_credentials" 18:05:59 that auth mechanism 18:06:10 we are basically teeing off on the auth mechanism 18:06:20 #link https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn 18:06:29 so for google 2-factor, I'll have something like "google_2factor" 18:06:45 #link https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn 18:06:48 gyee, so I would see it like 18:06:49 auth mechanisms will be handler like backend drivers 18:07:08 auth_mechs: ["google_2factor"] 18:07:24 each time you authenticate token to token, you add to that list 18:07:30 right, so for v3 , there are two auth mechanisms by default 18:07:36 password_credentials and token 18:07:45 maybe we can just call that field "factors"? 18:07:55 probabl auth_factors 18:08:10 Design specs must be independent of the factor 18:08:14 * heckj runs in and runs out - will promote the +1'd folks to core this afternoon & announce in release meeting & mailing list (congrats gyee & henrynash!) 18:08:31 factors is slightly more complicated than that, in that 2 "somethings you know" are still just 1 "factor" (something you know) 18:08:32 heckj, you have something else you want to add? 18:08:45 dolphm, so the idea was we list the factors in the token 18:08:49 so ['password', 'mothers_maiden_name'] is 1 factor auth 18:08:49 and then RBAC uses 18:08:53 er, policy 18:09:03 uses the factors to decide "This token is good enough" 18:09:22 ['password', 'mothers_maiden_name', 'rsa_token'] == 2 factor auth 18:09:31 google 2factor supports both sequence-based hash or time-based hash 18:09:33 there is a better way than this. Its called level of assurance (LoA) if anyoone has heard of it 18:09:39 very straight forward 18:09:51 dwchadwick, yes. I think that is what we are headed toward 18:09:52 I tested it with my android phone, pretty easy to use 18:09:54 There is a NIST standard on it, and an ISO standard as well 18:10:06 dwchadwick, the thing is, it needs to be enforced by the policy engine 18:10:16 We have already included this in our federation work 18:10:40 Exactly. That is what LOA is for. For over 5 years our PERMIS policy engine has support LOA 18:10:42 dwchadwick, have you specified how it modifieds the data encapsulated in the signed token document? 18:11:02 for multi-factor, we'll have something like "transitional" tokens 18:11:08 LOA is an attribute assigned to the user, just like any other identity attribute 18:11:22 so that the PDP makes decisions based on all the attributes 18:11:28 dwchadwick, is that the name of the attribute "LOA"? 18:11:30 transitional tokens are like unscoped tokens except you can't trade them in for a scope token 18:11:36 I would like to avoid TLAs 18:11:42 Yes LOA (for level of assurance) 18:11:49 There are two ways you can handle it. 18:11:56 1. As a subject attribute or 18:12:03 2. As an environmental attribute 18:12:29 gyee, why not trade them in? 18:12:35 gyee: would it make more sense to simply add an extra factor to *any* valid token you have? 18:12:35 It does not really matter as long as the policy writer and the authn engine in Keystone agree and put the attribute in the right place 18:13:17 gyee: what's the problem with trading in a "transitional" token for one with authz? 18:13:40 well, auth policies is a different issue 18:13:58 so in the auth dictionary of the token we have a field factors. It will have an array. I will write up the values that go in there based on existing mechanisms. Any additional mechanisms will get reviewed when they get submitted as patch review 18:14:00 gyee - please done use auth 18:14:00 s 18:14:02 for 2factor, transitional token is an incomplete token 18:14:10 like a half token 18:14:11 use either authn or authz then it is clear what you mean 18:14:20 dwchadwick, I'll post a sample JSON doc. 1 sec 18:14:55 today, you can trade in an unscoped token for a scoped token 18:14:59 gyee, instead, it will be a token that would not pass the policy check on some servers. 18:15:23 so if you auth with just uid/pw, you could trade that for a scoped token, but it still wouldn't make it pass the policy check. 18:15:26 transitional token just holds the state of auth 18:15:37 If tokens are created by keystone and validated by keystone why does it matter to any other service what they contain 18:15:44 gyee, so my point is that we won't have explicit transitional tokens 18:16:01 dwchadwick, because it is up to the other services to determine the LOA they require 18:16:06 right, I am thinking about inventing one :) 18:16:11 Keystone does not enforce policy 18:16:17 gyee, don't 18:16:21 gyee, we don't need them 18:16:35 but the token contains the loa buried secretly in it, and keystone tells the service what the loa is whe n the service asks keystone to validate the token 18:16:40 so for auths that require multiple roundtrips, what token do we issue? 18:16:58 so the LOA needs to be passed back in keystone's response but that is all you need to define to the outside world 18:17:09 dwchadwick: why does it need to be buried / a secret? 18:17:11 gyee, a token that specifies what authorization mechanism was used to generate it 18:17:37 dolph: because the format of the token is opaque to the service 18:17:43 ayoung, authentication mechanism? 18:17:57 the service is given a blob by the user and passes the blob to keystone for validation 18:18:25 In this way keystone can change the blob format and the service is unaffected by it 18:18:33 dwchadwick: ah, didn't realize that's all you meant 18:18:41 gyee, OK, say I need 2 factors: uid/pw and PKI for example. 18:18:54 First I auth with uid/pw and get a token. Then I resubmit that token with PKI 18:19:13 ayoung, that's two "complete" auths 18:19:14 now I have a token with auth{ factors:[pki,pw] 18:19:17 ayoung. In your authz policy you say "in order to access this resource you need a role of X and an Loa of 43 18:19:23 ayoung: that's still 1 factor auth -- both are something you know 18:19:33 43 should be 3 18:19:37 dolphm, please stop confusing the issue with facts. 18:19:45 dude 18:19:58 say we have a challenge-response auth mechanism 18:20:07 which require multiple roundtrips 18:20:17 how do we issue something that holds the transitional state? 18:20:29 you guys need to separate out authz from auth. LOA is the perfect mechanism for this 18:20:36 gyee, that is outside of Keystone 18:20:54 well, we have to issue/return something 18:20:54 dwchadwick, authZ from authN? 18:21:00 yes 18:21:13 gyee: can you start a mailing list discussion on this topic with the direction that you're headed? obviously there's a lot to be discussed that we won't be able to cover today :) 18:21:20 dolphm, will do. 18:21:24 yes sir 18:21:35 meeting agenda is crazy long today 18:21:40 #topic mapping 18:21:43 ayoung: ^? 18:21:47 dolphm, what I am describing is the end result of the discussion from the summit. I'll clean up the spec. 18:21:59 dolphm, I assume you mean mapping for LDAP and groups? 18:22:13 we have posted one new spec for mapping and revised the existing spec 18:22:14 as the Kent folk also have mapping stuff to discuss 18:22:15 "mapping (groups? attributes? ldap? ?? ayoung)" full topic on the agenda 18:22:29 OK. one thing at a time 18:22:32 first up is groups 18:22:52 henrynash' sreview has been approved and will merge once Jenkin's issues are sorted 18:22:58 w00t! 18:23:00 it's merged 18:23:06 https://review.openstack.org/#/c/18097/ 18:23:24 gyee: indeed! 18:23:24 that has a SQL backend, but no LDAP. henrynash and I will work through that offline 18:23:46 ayoung: yep, have some other IBM folks I can bring in to help on that too 18:24:06 henrynash, cool. Anything else that we need to discuss in this forum? 18:24:18 if you make the group change to controllers shouldnt it be independent of the backend 18:24:20 not on this one 18:24:39 dwchadwick this is where the group information is stored 18:25:16 I know, but when we are producing the attribute mapping code we are now doing it in the controllers 18:25:27 dwchadwick, OK, care to talk through your updated mapping spec? 18:25:33 so that it does not matter what backend you have (or so Kristy informs me) 18:25:41 Yes can do 18:25:52 dwchadwick, right, and for your code, that is the right place to do it, but even your code persists mapping, it just does it in a separate backend 18:25:57 dwchadwick, it still needs a backend interface 18:26:05 dwchadwick….but you need to store it somewhere (or at least someone needs to)… 18:26:18 To the spec changes 18:26:31 ksiu, you are creating a new backend module called "mapping" right? 18:26:31 The original spec assumed that the keystone admin was in charge of everything 18:26:44 i think I may have created some confusion here, I may have mispoke, I was discussing moving some functionality 18:26:47 also the APIs were too low level for Henry to use 18:26:54 dwchadwick…and need to decide which backends you need to support 18:26:56 dwchadwick: the controllers consume an interface to a backend, but it doesn't matter what backend the user has configured (all backends should implement the interface equally); the backend driver still need to support whatever calls you need to make, such as "persist_new_mapping" 18:26:56 So the new spec does two things 18:27:12 a) provides a mechanism for distributed administration of mappings 18:27:29 b) provides a high level API for these admins to use which makes attribute mapping easy 18:27:51 dwchadwick, so a) sounds like a general purpose problem solver 18:28:04 dwchadwick: (a) is dependent on (b) i assume? 18:28:07 dwchadwick/ksiu: do we have a proposal on the formal api doc on that? 18:28:07 can you talk through it in a little more detail 18:28:11 dolph: I will leave you and Kristy to deal with these "implementation" issues if you dont mind 18:28:19 dwchadwick: no problem 18:28:21 No 18:28:38 OK, moving on then.. 18:28:40 heh 18:28:44 next topic? 18:28:59 #topic register modules 18:29:08 i'm not really sure what this is -- anyone? 18:29:08 it would be posssible for the keystone admin to distribute out the work and let the admins use the low level APIs, but it would be inconvenient to them 18:29:33 dolphm: nope 18:29:36 henry: on what 18:29:52 dolphm, ah, let me address 18:30:05 (on knowing what register modules is) 18:30:09 ayoung, that's the lazy loading stuff you working on? 18:30:15 gyee, yes 18:30:17 ah 18:30:18 here is the issue 18:30:25 controllers need backends 18:30:37 recently, we have made decent strides in cleaning this up 18:30:41 thanks dolphm 18:30:50 but there is still a little ugliness 18:31:03 ayoung: modules == concrete classes? 18:31:14 In order for a backend to fulfill a dependency it needs to have been created already 18:31:31 ayoung, any reason you can't use keystone.openstack.common.importutils? 18:31:34 dolphm, well, I would say modules = identity, trusts, tokens... 18:31:39 gyee, hold on 18:31:56 there are 3 pieces in play, before we talk solutions 18:32:03 gyee: i'm not sure that 'modules' == 'python modules' 18:32:06 1) a class has to say what it needs 18:32:32 2) the web server etc needs to specify what class fills what dependency 18:32:40 and 3) that class needs to be loaded 18:32:57 all that has to happen before we can resolve a dependency 18:33:19 right now, we have this managers() mechanism from termie's efforts 18:33:33 it allows us to swap out the implementation based on the configu file 18:33:44 which is basically what I want to be able to do, just in a more general way 18:34:27 So I'd like to drop "managers" and instead have code that iterates through the Drivers list in config and regsters which classes are used to resolve those depenedencies 18:34:36 This would be built on top of my strings->classes work 18:34:51 #link https://review.openstack.org/#/c/18542/ 18:35:33 ayoung: that would certainly work, but where would you put code that managers currently implement? (e.g. exception handling) 18:35:35 One thing it would clean up is that we wouldn't need to have code to explicitly create all of the Managers early on 18:35:57 dolphm, let me post the link 18:36:22 https://github.com/openstack/keystone/blob/master/keystone/common/manager.py 18:36:25 That is all they do 18:36:42 dolphm, there is also some real ugliness there 18:36:57 in that we make calls with context used as the slef pointer. 18:37:00 self 18:37:02 ayoung: classes that extend keystone.common.manager.Manager have implementation details 18:37:26 dolphm, Identity, for example 18:37:44 https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L51 18:38:19 ayoung: the identity manager is relatively barren compared to https://github.com/openstack/keystone/blob/master/keystone/policy/core.py#L29 18:38:22 so tokens is in here https://github.com/openstack/keystone/blob/master/keystone/token/core.py#L70 18:38:38 And that code can easiler go into the Driver at the class level 18:38:41 let me look 18:38:54 ayoung: then it must be replicated into every driver? 18:39:07 dolphm, no 18:39:25 Drivers are treated as abstract base classes, but they don't have to be pure abstract 18:39:39 we'd need to deconflict names, like get_policy 18:40:18 ayoung: i see where you're going, but i think the rest of this conversation would be best suited in the context of the code review? 18:40:30 ayoung: i think everyone else is falling asleep 18:40:40 I am still awake, barely :) 18:40:59 dolphm, fair enough. I just wanted people aware of where I was going with this, and why. Much easier up front. 18:41:06 ayoung: cool 18:41:08 We can move on 18:41:10 ayoung +1 18:41:15 #topic Test coverage 18:41:31 ayoung: i assume you've been tracking our coverage? 18:41:35 ayoung: has it improved? 18:41:37 Have not looked at it 18:41:53 (why was this on the agenda then?) 18:41:57 dolphm, let me regen the stats and hit this at the end of the meeting 18:42:10 dolphm, because we said we were going to review 18:42:28 ayoung: cool, we need to get jenkins tracking our coverage again (it used to chart it for every commit) 18:42:52 i think it got killed because it started recording 0% coverage all the time 18:42:59 ayoung: ah 18:43:11 #link Discussion on proposed api changes for domain role grants 18:43:15 #topic Discussion on proposed api changes for domain role grants 18:43:22 #link https://review.openstack.org/#/c/18706/ 18:43:28 hopefully can make this quick…Dolph - I changed the bp to just be the re-specifation of what it meant to assign a role to a domain 18:43:51 ..i.e. it means just to the container (not all the projects within it) 18:44:11 so, for everyone else... to grant a user a role on all projects in a domain: you'll have to get the list of projects in the domain, and then make a grant call for each project you get back 18:44:30 it's a bit more chatty, but lets us distinguish between grants on the domain itself and grants on the contents of the domain 18:44:33 any objections? 18:44:41 wait 18:44:49 i assume only keystone will consume domain-grants 18:44:55 for now yes 18:45:02 so what does granting a role to a domain mean? 18:45:16 good question 18:45:18 gyee: absolutely nothing to other services 18:45:30 e.g. give a user permission to manage user and drops for a given domain 18:45:43 gyee: but to keystone, it means you have a role on the container, so you could (for example) create projects in that domain 18:45:50 i.e. the keystone policy engine will process this 18:46:02 oh, so its a domain admin role then? 18:46:06 henrynash, hrm. Let me process that. Not sure I like it, as it makes the implementation tricky. I'm not saying "No" just lets discuss in a couple days. 18:46:10 gyee: yes 18:46:12 this is not granting a role to a domain. this is granting a role permission to perform ops on the domain 18:46:21 gyee: could be more granular as well 18:46:25 dwchadwick: yes 18:46:48 so it would help to be more precise 18:46:51 ayoung: sure 18:47:13 dwchadwick: "not granting a role to [the contents of] a domain" yes; however, i imagine that if you have some sort of admin role on the domain, nothing is stopping you from granting yourself roles on all the of contents of the domain 18:47:52 dolphm, I am fine with this 18:47:57 gyee: cool 18:47:58 correct. but this is still granting permissions to a role, isnt it? they are just diferent permissions 18:48:08 gyee: checkout the linked review above if you have a chance 18:48:14 ok 18:48:19 do we need domain level roles at all? Don't groups support that use case better? 18:48:33 groups dont have permissions 18:48:55 groups map into roles and roles have permissions 18:49:02 ayoung, role definitions are global right now, you saying domain-level role definitions? 18:49:24 gyee, OK, let me be clearer 18:49:34 do we need domain specific role grants? 18:49:49 ayoung: i think they're sort of orthogonal concepts -- domains own users and projects, groups collect subsets of users from any domain as an administrative shortcut 18:49:53 I would say yes 18:50:09 since domains are autonomous units arent they? so they should have different permissions 18:50:13 gyee, I can see where two domains might have different names for their roles. 18:50:16 ayoung: how would I allow one user to only, day, manage the crud for users and groups in one particular domain, but they not have any project access 18:50:24 (a very common enterprise job) 18:50:36 ayoung: when i wrote the spec for domain role grants, i failed to distinguish between having a role on the domain and having a role on the contents of the domain; this fixes that 18:50:54 ayoung, I would love to have role definitions own by domains 18:51:24 meaning you can only grant domain-roles to users for projects within the domain only 18:51:28 I thought we agreed months ago that roles could be both local and global 18:51:52 dolphm, henrynash right, I can see the need to be able to administer the domain, but why would I want to be able to use gratns to grant a role to au ser for all projects in that domain. 18:52:06 That, to me, is what groups are for. 18:52:21 ayoung: that's way we took out 18:52:38 henrynash, then there should be no need for a flag 18:52:53 the role is never applied to the enclosed projects 18:52:54 ayoung: it's been removed, see the commit comment 18:53:14 henrynash, ah, I was looking at the blueprint. We are in violent agreement 18:53:15 ayoung: I should go update the bp as well, sorry 18:53:25 ayoung: +2 18:53:40 yay 18:53:44 nice 18:53:50 #topic Discussion on proposed api changes for domain token scoping 18:53:55 #link https://review.openstack.org/#/c/18770/ 18:54:27 this is kind of the partner in crime….so you can get a token that lets you do the admin role 18:55:02 so, this ties into the previous conversation, and other services wouldn't support these tokens, as there's no project-level authorization 18:55:33 dolphm, that may not be true. It should not be up to Keystone to enforce 18:55:33 dolphm: yes..one day I can imagine cases when the might (e.g. images that are common to a domain) 18:55:43 henrynash, zacly 18:56:15 but they can do that in their own time…this lays the foundations 18:56:51 henrynash, so the follow on work is "scope a token to a set of endpoints." 18:57:08 Feel free to knock that out as well! 18:57:24 ayoung: I'll certainly take a look! 18:57:43 henrynash, cool, we can talk about that offline 18:57:48 henrynash: if we implement this in auth_token middleware, we need to be very careful about what is exposed as DOMIAN_ID / DOMAIN_NAME to the underlying service (as we have both the user's owning domain and potentially the token's domain-scoped authz, which may not reflect the same domain) 18:57:56 3 minutes remaining 18:58:21 we can skip Dependency injectsion 18:58:24 dolphm: ok 18:58:24 already covered it 18:58:25 USER_DOMAIN_ID / USER_DOMAIN_NAME (user's owning domain) + DOMAIN_ID / DOMAIN_NAME (authz scope) 18:58:43 ayoung: k; i'll push the rest of the topic to next week 18:58:55 good idea, need time to absorb this 18:58:58 dolphm, migration, for the last minute? 18:58:59 topics* 18:59:03 "Default" domain migration (dolphm) 18:59:20 ayoung: i don't have a code review up for that yet, so i'll push that as well 18:59:23 Cool. 18:59:39 If anyone is willing to talk SQL, lets to that in #openstack-dev after this 18:59:46 #topic open discussion 18:59:58 super brief, we have like 10 seconds on my clock ;) 18:59:59 can somebody review my memcache protection changes? 19:00:02 Summit is in Portland this year 19:00:04 gyee: link? 19:00:24 dolphm: https://review.openstack.org/#/c/18909/ 19:00:27 thanks 19:00:32 always wanted to go to portland (i've been to vancouver, which was fantastic) 19:00:38 #link https://review.openstack.org/#/c/18909/ 19:00:42 gyee, please add the core devs to the list of reviewes for important changes 19:00:50 list of reviewers 19:00:52 ayoung, will do 19:01:00 i get notified either way :) 19:01:07 times up. we all revert to mice and pumpkins 19:01:10 hence my review queue moves slowly 19:01:23 hack responsibly, everyone 19:01:25 #endmeeting