18:01:25 #startmeeting keystone 18:01:26 Meeting started Tue Dec 8 18:01:25 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:30 The meeting name has been set to 'keystone' 18:01:43 thanks for coming to this week's installment of keysone-meeting :) 18:01:49 the agenda is here: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:52 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:16 He yo! 18:02:20 its rather light, i guess some folks are already in holiday mode 18:02:37 #topic MFA 18:02:48 nonameentername: did you want to chat about this one? 18:02:49 o/ 18:02:56 #link https://review.openstack.org/#/c/130376/ 18:03:01 the review is up here ^ 18:03:17 do it! 18:03:27 gyee will you champion? 18:03:27 o/ 18:03:38 i know *a lot* of folks want this in 18:03:39 gyee is a champion! 18:03:39 Yeah, basically I want to add another authntication type 'passcode' that is based on TOTP, HOTP 18:03:41 lbragstad, you mean like writing code? 18:03:55 gyee i think champion is dedicating review time 18:04:02 gyee owner is the one writing the code 18:04:04 lbragstad: correct 18:04:09 lbragstad, sure, I am quite familiar with that one 18:04:14 what if the owner gets too busy? 18:04:21 gyee awesome 18:04:22 and require users to specify both password and passcode for some domains and projects. 18:04:37 bknudson: then someone else can pick up the work or we can see it in N 18:04:50 nonameentername how far along are you? 18:04:54 on the implementation? 18:04:58 if at all.. 18:05:37 nonameentername: so the things i'm looking for in the spec... where are the API changes? what's the impact to non SQL users (ldap/federated/trust/etc) 18:05:38 I already have a poc that has TOTP working for authenticate, but it's missing the database part that stores backend 18:05:42 so as long as we do the time hash only 18:05:47 managing sequence is not fun 18:06:10 do we need to change the current auth plugin framework we have in keystone? 18:06:17 no 18:06:19 stevemar: I can add api changes to the spec 18:06:21 just another plugin 18:06:55 it, will need an apy to enable / disable mfa for user, domain and project 18:07:01 *api 18:07:19 and also to setup mfa for a specific user 18:07:19 it's unfortunate that we have to implement this in keystone. we already have federation so can't the idps do this? 18:07:31 nonameentername, you want to go that far? 18:07:42 so far we don't tied auth mechanism with users 18:07:48 bknudson: so yeah, if i have google as my IDP, then i get MFA for free 18:07:59 bknudson: ++ 18:08:19 I guess it depends on how easy it is. Maybe it's only a few lines of code. In which case go ahead. 18:08:24 but that's only for federation, right? 18:08:29 lbragstad: correct 18:08:34 is there a python library for google auth? 18:08:43 What if a user wants to setup mfa for his own account without using federation? 18:08:47 this would be useful for sql accounts and possibly.... ldap? 18:09:09 nonameentername: right, theres definitely a use case for sql users 18:09:17 nonameentername: i think it's more a case of if a provider wants to make those sort of requirements then it should be done via federation 18:09:22 I wish we'd get rid of sql users. 18:09:37 because this sounds to me like enhancing the SQL user store - which i thought we weren't doing 18:09:59 we also have the shadow user stuff coming 18:10:16 doesn't that enhance the sql user store? 18:10:24 lbragstad: not really 18:10:28 lbragstad: that's more tracking than being source of truth 18:10:35 lbragstad: the biggest gain is for federated users 18:11:17 for sql users we've to the extras column so I don't care if we're expecting new fields. 18:11:23 I think one reason the MFA needs to be in keystone is we want to setup MFA for certain projects/domain only. Can we do that in federation? 18:11:38 "certain projects/domains" 18:11:41 mfa can be used with LDAP, correct; not only sql users 18:11:43 can you expand on that? 18:11:56 rderose: thanks for confirming 18:12:09 stevemar: the use case would be.. 18:12:11 i thought it was likely to work with ldap 18:12:25 since this doesn't actually require any changes to keystone I'm fine with it going ahead. 18:12:39 I want to setup a global keystone to access my data center, and within the data center there would be different security zone. 18:12:39 let's see the code 18:12:42 In a public cloud I setup a project and want users to use the project, but I only want them to use it when they have MFA enabled. 18:12:52 bknudson, it does, it depends how far we want to go 18:13:28 bknudson: how would it not have changes to keystone? 18:13:36 for server running in higher security zone, I want higher security. The idea is have a project that can have access to higher security zone, and add MFA to those projects. 18:13:37 it's just a new plugin 18:13:41 if we have to associate domain/project and user with auth mechanisms, this require framework changes 18:13:45 most of the implementation lives in the authentication plugin 18:13:48 so you're not changing any existing code, only adding new 18:13:58 thats the hope :) 18:14:28 would we expect this to affect federtaed users? 18:14:38 or want it to? 18:14:44 maybe we can make the security zone thing explicit and work with any auth 18:14:54 nonameentername: update the spec to be explicit about what user's this will work for (I think just SQL and LDAP), and write out any new APIs as well. 18:15:05 maybe give the user a role if they auth with some method and you can use that in policy? 18:15:17 stevemar: well with shadow users table you'll pretty much get it anyway 18:15:17 stevemar: ok, I can do that 18:15:20 so, no federated support for mfa initially (i'm not sure that seems right anyway?) 18:15:37 federation already gives you mfa today 18:15:45 nonameentername: i believe lhcheng and lbragstad are going to "champion" this spec 18:15:51 if you're using federation you don't need this 18:15:56 bknudson how so? 18:15:57 bknudson: right-o! 18:15:59 right, so i'm not sure it makes sense to have federation in the scope of this sepc 18:16:00 federation is orthogonal to MFA 18:16:01 spec* 18:16:04 bknudson: how? +1 18:16:10 topol: the idp will have it for free 18:16:15 set up your identity provider to do mfa 18:16:32 topol: like how google tells me to enter the code it sends to my phone 18:16:32 bknudson, k just checking. thought you would say that 18:16:41 stevemar +++ 18:16:50 nonameentername: you've got 2 TODOs and 2 champions 18:16:58 update the spec and we'll approve 18:17:02 just to be clear, this one is not about entering codes send to the phone 18:17:03 stevemar: thanks 18:17:08 this is strictly for time hash 18:17:10 gyee: yes yes 18:17:21 so TOTP specific? 18:17:24 so federation is even better 18:17:28 gyee: this is not for sms, only totp, and hotp 18:17:33 bknudson: it's always better 18:17:43 nonameetername, no sequence hash please 18:17:45 where's ayoung, i expect he's going to have some opinions on how this is done 18:17:47 that's very hard to manage 18:17:56 syncing sequence number is not easy to implement 18:17:56 gyee: yes, it was just an example :) 18:17:57 gyee did you try this already ? 18:17:58 and doing it in/out of keystone 18:18:00 I thought keystone supported auth with multiple roundtrips? 18:18:17 gyee: ok, I can implement only totp and ignore hotp 18:18:20 lbragstad, we have some inhouse POCs awhile back 18:18:25 Nah, I never have opinions 18:18:27 gyee gotcha, 18:18:27 bknudson: we could make it work, but not explicitly i think 18:18:44 ayoung: bland, quiet…. 18:18:48 ayoung: you hadn't said anything for a while - typically i take that to mean you're not around :) 18:19:05 calling this topic finito 18:19:14 ole 18:19:19 #topic Domain Specific Roles 18:19:28 #link https://review.openstack.org/#/c/254139/ 18:19:38 jamielennox, was still catching up...my kneejerk reaction is "can we do this with federation" 18:19:41 henrynash gyee ayoung -- figure this mess out 18:19:45 oh, didn;t know this was on here! 18:19:45 I am struggling mightily with that one right now 18:20:00 we tried OTP with SAML and basically had it working 18:20:04 gyee: so see my comments to the link steve just posted 18:20:19 try to keep crypto stuff out of Python if possible. 18:20:45 (just for background to all): Since gyee had argued for using a role-group concept for Domain Specific Roles, I posted a review (just for discussion) on how that would look: https://review.openstack.org/#/c/254139/ 18:20:50 ayoung: mine to, was mentioned 18:20:57 but...still need more details to make a firm recommendation 18:21:18 henrynash, we can more or less can accomplish role groups with user groups 18:21:43 so role groups doesn't buy much 18:22:05 user groups are essentially perm templates 18:22:11 domain specific roles are roles that a domain administrator can create/delete/assign, right? 18:22:18 gyee: so *some* companies might, but others haev strict user groups defined in LDAP etc.. and don’t necessarily lend themslevs to this 18:22:21 only difference is that role groups have no targets 18:22:24 stevemar that's what I was thinking 18:22:24 stevemar I hope so 18:22:25 stevemar: yes 18:22:47 so these roles only mean anything within that domain, how does that tie in with policy? 18:23:06 stevemar, yes, but we can't prevent the creator from mapping them to some global roles 18:23:09 lbragstad: yes, they don't go into the policies, only globalroles go 18:23:10 gyee, so...we could split groups out of the identity backend 18:23:21 and I think gyee, the nub of your concern is that it will be confusing in the case of DSRs based on implied roles,….that the DSR iteself doesn;t go in the token 18:23:33 lbragstad: cause you don't want the domain admin to be able to create/delete/assign roles globally 18:23:47 lbragstad: they're expanded into global role when issueing tokens 18:23:53 so domain roles won't be applied to other services? 18:23:53 so see my comment and scenario I posted on https://review.openstack.org/#/c/254139/ - I really don;t see the confusion youare concerend about 18:24:00 that might make sense anyway. It means that a user could get their identity from one domain, and their groups from a second 18:24:07 henrynash, right, that was my original concern 18:24:36 lbragstad: DSRs are mapped into global roles…which is what go esin the token 18:24:43 lbragstad: no, other services only need to know about global roles 18:24:49 henrynash: ++ 18:24:51 samueldmq ok, so you have super granular global roles 18:24:55 gyee, so, I was thinking we do the "URL safe" approach. If you go URL safe, then you can do 18:25:04 Domain admin can only delete/create/mod users, roles in his/her domain? 18:25:11 domain/IBM/admin versuse domain/HP/admin vs domain/redhat/admin 18:25:11 and the domain roles are combinations of really granular global roles 18:25:13 david8hu yes 18:25:19 lbragstad: yes and you can group them as you want, with custom names for your domain ,etc 18:25:21 lbragstad: ++ 18:25:33 but...not sure if having them in the token would ever be used to enforce policy 18:25:42 samueldmq henrynash gotcha, interesting 18:25:47 ayoung, we can, but its useless till we can update the enforcement part 18:26:13 gyee, while we could enforce on that now, I just don't know when that would be required 18:26:22 right now role is unidimentional, not multidimentional 18:26:26 ayoung: they'd go in the token? 18:26:28 I mean, yeah, you would have to edit policy by hand 18:26:41 jamielennox, this is IF they go in the token, what would they look like 18:26:42 remember (not wishing to be forward or nothin’) but we did vote on DSRs using implies roles alst week and got 7 For and 6 or 7 abstains, and none against 18:26:50 if we agree that role is multidimentional, then we have some flexibility there 18:27:13 jamielennox, I can't see a reason to put them into the token 18:27:16 ayoung: yea, not in token 18:27:36 henrynash, if I create custom role within the domain I administers, are you going to have policy per domain? 18:27:38 the token will still only have the global roles 18:27:46 gyee: what does that mean ? roles being unidimentional vs multidimentional ? 18:28:07 samueldmq, it means instead of just a name, it is a set of attributes 18:28:22 role.name, role.domain_id, role.type, etc 18:28:27 david8hu: so you cannot cahneg the policy file as a domain admin…but the idea is that if yoru cloud provider has created a nice fine-grained policy file, you can use DSRs to better model what those mean to your users 18:28:45 I kindof agree that what henrynash is working for here is due to the groups concept being taken, but really what we want. This is an internal mapping step, from individual user to role assignment 18:28:46 gyee: so you basically want to expand the role entity, rather than creating a new first citizen in keystone , 18:29:25 I really don't want a new concept. EIther go with DSRs, or rework groups 18:30:17 samuedlmq, gyee: and of course that’s what the current DSR is….a special tyoe of role (that has a domain_id set) 18:30:52 henrynash, not really, we don't enforce it on the policy side 18:31:02 since they don't return in token response 18:31:23 gyee: and absolutely don’t want them to…this is a pro onot a con 18:31:34 gyee: that'd cause headaches, we'd need to keep list of implied roles synced with endpoints ,etc 18:31:39 groups might be a little strange. When the assertion comes in, you would have REMOPTE_USER and REMOTE_GROUPS set. You'd make REMOTE_GROUPS to groups in the users own domain...or in any other domain...and the REMOTE_USER to group mapping would be either from the Federation mapping, or an explicit Federated user to group mapping from... where? 18:31:58 gyee: I have to ask you again to read what I posted in the review….I really do not see the confusion of DSRs not goiong in the token 18:32:24 So, I kindof like DSRs as the abstraction, because they are Keystone specific data, not identity. 18:33:05 henrynash, if your support person comes to you and ask why don't they get that role as it was seemingly assigned, what do you do? 18:33:18 I'd like to point out that this is why David CHadwick origianlly wanted the mapping to go from the assertion all the way to the roles, and to skip the group concept. 18:33:45 gyee, that was why I was asking about diagnostic APIS. I think we would want that 18:34:01 gyee: so you have to think through teh scenario….the domain admin and project admin will know what the roels are 18:34:17 and figure out which DSRs to assign in order to get some specific role 18:34:20 #link https://openstack.nimeyo.com/66396/openstack-dev-keystone-diagnostic-apis-for-keystone 18:34:36 (sorry to past this, but I already write this out): 18:34:36 1) A public cloud provider wants to attract as many, diverse customers as possible 18:34:37 2) To do that, they are likely to offer a flexible, fine-grained set of roles that are encoded in policy rules 18:34:38 3) As part of the on-boarding of a customer (represented as a domain), they will give the domain admin the spec of what roles they must assign their used to give the permission to execute various APIs. These are set by the cloud provider, the domain admin has no control over this. 18:34:39 4) Without DSRs the domain admin will either use this list or explain this list to their project admins for project within their domain. They'll work out (and probably circulate internally) how the set of roles defined by the cloud provider shod map onto what every usage model they have 18:34:40 5) With DSRs, they'll encode that model in DSRs and use those (or tell their project admins to use those). So they'll be fully aware of what roles are cloud provider roles and which are DSRs. 18:34:52 …hence I don’t see the confusion 18:35:19 gyee: DSRs should have very suggestive names (as they can be customized), so not too hard to realize that ? 18:36:34 samueldmq, its the working backward part, from token response 18:36:36 henrynash, I think that any of us that spend time on the issue will come up with a similiar solution. The real issue is what do we call them, and how do we implement without retolling the entire UI. 18:37:12 If we assume Federation as the starting point (ID in SQL or LDAP is simpler) then there are several layers of indirection 18:37:32 Assertion->identiyt (users, groups)->role assignments. DSR adds an additional layer 18:37:45 Assertion->identiyt (users, groups)->DSRs->globalrole assignments. 18:37:58 ayoung: agreed 18:38:08 it would be an entry in the shadow table, preferably 18:38:19 So, I stand firm on not wanting to add a new abstraction (rokle groups) but am flexible on which of the layers we modify 18:38:29 stevemar, not quite 18:38:49 it would be keyed by the shadow talbes User iD, but these are additional layers of assignment 18:38:53 gyee: your issue with the current API is that policy will be hard to write? 18:39:24 stevemar, DSRs still constraint by global roles 18:39:37 so if you make your policies and global fine grained that's fine 18:39:43 global roles 18:39:50 like one to one 18:39:58 i think gyee's problem is that it's hard to tell what your DSR is from the token response 18:40:02 one global role per API or something 18:40:05 For me, although I origionally propes role-groups 18 months ago and fought against implied roles for a while, amd convinced that our current (merged) DSR approach is the one we should do for. 18:40:42 DSR (and implied roles) is about easing the way you assign global roles 18:40:43 but I can't restrict domain-admin from seeing all the global roles 18:40:44 gyee: in the end, that’s probably where it goes, but with some “cloud wide” grouping encoded in the policy file by teh cloud provdier 18:40:57 if you, as a deployer, don't think it does, just don't use it ? 18:42:02 gyee: OK 18:42:07 gyee: that’s a different problem 18:42:13 I think we are going to want a diagnostic API no matter what solution we come to here 18:42:13 samueldmq, so what kind of role can someone assign? 18:42:38 gyee: the current suggested API is just a new attribute to the roles API, it's pretty minimal, we can get away with have that option be experimental for 1 release 18:42:42 gyee: one (who is allowed to assign roles) can assign either global roles or DSR (from his domain) to someone else 18:42:43 if someone have permission to assign roles, what kind of roles can they assign? 18:42:45 gyee: I’m not trying to solve role hiding here 18:42:54 we can see how it works out and if it sucks, we can go to another design 18:43:29 stevemar, sure, make it experimental then 18:43:32 gyee: the proposed spec is minimally invasive, let's try it out first 18:43:37 ++ 18:43:46 Can domain admin assign the "admin" role to himself? 18:43:48 aren’t all major new featiures experiemental 18:43:49 gyee: yep, we can add that to the documented APIs 18:43:51 stevemar, I am not worry about the implementation part, its all code 18:44:00 its the APIs that I am loosing sleep over 18:44:07 implement can be changed anytime 18:44:11 implementation 18:44:39 gyee: right, but let's try it out first, if we dont like the API, we can rework it a bit since it's experimental 18:44:46 just like we did with service providers 18:45:03 david8hu, in order to solve what you are implying, we need the unified delegation spec 18:45:13 gyee: we cool? 18:45:22 yea, we coo' 18:45:30 stevemar, sure, as our role assignment is pretty messy as is right now :) 18:45:32 david8hu, unified delegation says "a user can only assign(delegate) roles that they themself have" 18:45:41 alright :) 18:45:46 cool 18:45:51 ayoung: gonna give davechen some time 18:46:04 #topic need to support delete/get V3 endpoints via V2 API 18:46:05 absolutely agree on it being experimental - all majoe new features should be experimental to start - that’s what we agreed a while back 18:46:08 gyee, ponder over whether you would be happier with a modification to mapping or groups abstactions than this 18:46:15 davechen: you've got about 10 minutes, sorry 18:46:22 okay, 18:46:31 why do we need to do anything via V2? 18:46:38 it's fine, i am just wondering if we could support to do that. 18:46:39 ayoung, I don't want role groups 18:46:45 let's not support this in v2 api 18:46:53 support get/del endpoint via v2 api 18:47:13 but it's currently possible to list v3 endponints 18:47:16 by v2 api 18:47:32 ayoung, I have a usecase that combo of DSR and UD will solve. 18:47:35 how much work is it? just a few lines? 18:47:40 so, it's looks a little werid that we cannot get or delete. etc. 18:47:50 davechen, I'd be more prone to say "allow V3 API modify V2 stuff" than the reverse. No changes to V2 if we can avoid it. 18:48:04 at the summit we had the opposite discussion in our deprecation session i think? 18:48:21 keystone v2 can be a little weird. 18:48:31 ayoung: just keep it as is? 18:49:08 we wanted to deprecate/remove everything that wasn't absolutely required v2 (like auth and validate) 18:49:13 davechen: if a user is adding endpoints in v3, then how likely is it that they'll list endpoints with v2? 18:49:18 bknudson: i agree that we should no add new ability for v2 api 18:49:40 davechen: what is the risk if we keep it as is? 18:49:43 stevemar: i am not saying add, but get and delete 18:49:55 why delete? 18:49:57 rderose just the inconsistency? 18:50:03 ignoring get for the moment 18:50:22 rderose: i think the risk is pretty low 18:50:24 ayoung: just from end use's persepctive, you can see these endpoint but you can do noting about it 18:50:26 do we have a bug about this? 18:50:30 is that make sense? 18:50:39 stevemar: not yet 18:50:42 you can do something about it. use the v3 api and do it 18:50:45 davechen, look, no touch OK :) 18:51:14 gyee: don't touch it? 18:51:16 :) 18:51:23 davechen: how often are people actually modifying/deleting endpoints? 18:51:40 dstanek: not quite often, i think 18:51:43 modifying and deleting v3 endpoints through the v2 api 18:51:49 davechen: unless someone is actually running into this error, then i say don't bother fixing 18:51:58 dstanek: but it quite often for get 18:52:05 stevemar: ++ 18:52:08 davechen, reserving admin for V3 for any lingering V2 isms is a better bet 18:52:13 get some info for specific endpoints 18:52:23 devananda: get works for things with a publicURL right? 18:52:27 you can read old data, or new data in an old format, but you need to use the new format to change it. 18:52:30 stevemar: gotcha 18:52:53 i think it's settled that this is a `won't fix` issue 18:53:01 stevemar: yey! 18:53:23 #topic champions 18:53:38 i wanted to share something i've been using to keep track of work 18:53:48 heres a google doc for anyone to comment on: https://docs.google.com/document/d/1MD1WJNasuDkDFstK6kgfZiA7SkIGKdH6n69AoVaTy1g/edit?usp=sharing 18:54:19 cores, add yourself as "champions" meaning you *will* review the spec 18:54:25 err implementation* 18:54:42 i'll be keeping track of links for implementation, somehow, probably a gist 18:54:54 stevemar, you'll be adding MFA? 18:55:00 try not to over commit yourself 18:55:06 stevemar: like it 18:55:07 gyee: yes, it was blessed just 30 minutes ago LO 18:55:08 stevemar: great idea! 18:55:10 :P 18:55:19 also, leave lots of room for reviewing bug fixes. 18:55:28 because we still have to do that, too 18:55:31 thats the goal 18:55:38 bknudson: on that note... 18:55:53 i've updated LP to reflect ALL of our deliverable for mitaka: https://launchpad.net/keystone/+milestone/mitaka-2 18:56:00 so far nothing is in mitaka-3 18:56:09 mitaka-2 ends in ~45 days 18:56:11 stevemar: the one thing I would add is maybe the Phase 1 of reseller (projects acting as toplevel domains)….althoug the spec was approved in a previous cycle, most of the code is up for review in M 18:56:11 wow, the slots are filling up, fast 18:56:36 feel free to add more slots ... i don't mind additional champs :) 18:57:07 gyee do you want to champion the mfa stuff? 18:57:08 so please HAVE a patch up for review BEFORE MITAKA-2 ENDS! 18:57:16 lbragstad, yes 18:57:19 otherwise it'll get booted to N :) 18:57:55 if the patch is not yet merged, we can still land stuff in M3, even though it was targeted for M2 18:58:08 stevemar, ayoung I expect unified delegation code to be finished in mitaka timeframe, and the problem is that spec is being modified in the process. Should I just do what I do now and propose everything in N release? 18:58:27 amakarov: that sounds like a good plan 18:58:36 we can slide that right into N1 18:58:48 i don't want to overcommit ourselves 18:58:48 stevemar, ok 18:58:54 functional testing is not on the doc 18:59:00 python3 support is not on the doc 18:59:04 bknudson: it's "ongoing" at the bottom of the doc 18:59:10 both are 18:59:16 yep 18:59:32 what's ongoing? 18:59:38 how is that different than the other work? 18:59:40 bknudson: they span many releases 18:59:42 * lbragstad high fives bknudson 18:59:42 stevemar: fyi: I am grabbing functional tests on keystoneclient 18:59:50 tag team online migrations! 18:59:54 we're not planning to complete these for M? 18:59:58 amakarov and if there are any pre-reqs we can do in M that are non-disruptive, we can merge them when they are ready. 19:00:05 bknudson: ideally we should 19:00:05 stevemar: python3 shouldn't it should be completed in M 19:00:08 out of time! 19:00:10 #endmeeting