18:00:05 #startmeeting keystone 18:00:06 Meeting started Tue Nov 29 18:00:05 2016 UTC and is due to finish in 60 minutes. The chair is stevemar__. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:09 howdy! 18:00:10 The meeting name has been set to 'keystone' 18:00:12 o/ 18:00:34 o/ 18:00:36 tally-ho, chaps 18:00:50 henrynash: chip chip 18:00:55 #agenda https://etherpad.openstack.org/p/keystone-weekly-meeting 18:00:59 o/ 18:01:07 pokes amakarov, ayoung, bknudson, breton, browne, chrisplo, crinkle, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, gyee, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lbragstad, kbaikov, ktychkova, morgan, nisha, nkinder, notmorgan, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, shaleh, srwilkers, stevemar, topol, StefanPaetowJisc, agrebennikov 18:01:13 o/ 18:01:23 o/ 18:01:25 stevemar__, why are you stevemar__ and not stevemar? 18:01:25 o/ 18:01:28 o/ 18:01:33 o/ 18:01:33 o/ 18:01:35 rodrigods: he grew a tail 18:01:35 hello 18:01:39 Hi 18:01:40 rodrigods: cause my bouncer and/or vm are not working 18:01:44 morgan_, you too 18:01:50 stevemar____________________________________________ 18:01:53 ^ 18:01:58 rodrigods: because i'm lazy after reconfiguring irccloud 18:02:07 rodrigods: and haven't typed /nick morgan 18:02:09 hi cbits, you're new around these parts :) 18:02:11 o/ 18:02:24 My F25 update broke and I am on a different machine...monitoring but bouncing back and forth to try and fix 18:02:30 Yes I am.. Nice to meet you all 18:02:30 #topic release status 18:02:37 ayoung, lol, had the same issue 18:02:39 hi. cibts, welcome 18:02:49 just a reminder that Next milestone is Ocata-2 -- Week of Dec 12-16 18:02:50 cbits o/ 18:02:57 This is also spec freeze week, specs must merge by then 18:03:05 such a short release :( 18:03:11 rodrigods_, did you fix, or still dealing, too? 18:03:13 o/ 18:03:20 o/ 18:03:40 ayoung, fixed by wiping everything and re installing f24 18:03:50 let's try and land all the bps and bugs that touch a lot of things earlier than later 18:04:16 #topic Spec: "Extend user API to support federated attributes" 18:04:19 rderose: ^ 18:04:35 Cool 18:04:36 https://review.openstack.org/#/c/397410/ 18:04:50 The problem: I have a federated user and I want to do delegation or make a concrete role assignment, however in order to do that, I need the local user ID. 18:05:00 And there is no way to query Keystone to get the user ID for federated users. 18:05:07 Likewise, federated users don’t exist in Keystone until after they authenticate. 18:05:18 Proposal: Let's simply extend the user API to support a federated object, allowing operators to: 18:05:25 Query users based on federated attributes (unique_id…) 18:05:26 rderose, so, I don't like the formate: we should do it likethis: 18:05:32 Create federated users by including a federated object 18:05:48 ayoung: what format would you suggest 18:05:53 idp: "name" : protocols [ ...] 18:06:02 need to support multiple idps and multiple protocols 18:06:13 ah, good point 18:06:23 something that reflects that, linked to the same account. 18:06:30 other than that, you are on the right track 18:06:48 don't get it... we fetch the users without having them in the backend? 18:06:54 rodrigods_, nah 18:07:10 rderose: if i make a post requet to /v3/users with federated bits in my request, it'll only create the entry in the federated_users table? 18:07:19 rodrigods_, say a user comes in by one Idp/prtotocl, and then later via a different one...we should see how they link back to their IDP accounts 18:07:34 rderose: the querying parts i don't mind 18:07:35 rderose, does maybe it feel like this should be a separate API? 18:07:44 stevemar__: no, it will create a user in the user table and federated_user table 18:07:49 ayoung: a bit yes 18:07:56 rderose: two eh 18:08:05 ayoung: why not utilize the user API? 18:08:05 looks like it should be a different API 18:08:09 rderose: why isn't that an issue? 18:08:17 rderose, its related...but different eentities. 18:08:17 at least... we are exposing how things are implemented underneath 18:08:25 it does the same thing as a shadow user being created through the federation authentication flow 18:08:26 which usually is not a good thing 18:08:28 a federated user is a user 18:08:31 something like user//idps or something? 18:08:52 lbragstad: ++ 18:09:03 OK, for a user show...it probably is OK to have in there as is. 18:09:10 lbragstad: thats a better explanation :) 18:09:13 for affecting change...lets see what you have... 18:09:24 so the problem is to create role assignments prior the user has even been authenticated? 18:09:29 ayoung: and GET /v3/users/?unique_id={unique_id} 18:09:32 this seems limiting in any situation where the saem user has more that one login method 18:09:35 ayoung you mean it's ok to return federated attributes via the identity API? 18:09:53 lbragstad, I'm wavering... don't think it would brek anything 18:09:58 i don't think we've tackled the account linking story yet... 18:10:03 jamielennox: this is the opposite of limiting, this is giving operators full control 18:10:24 OK...what if we said we don;t want it as a POST, but had to be a PUT? 18:10:26 jamielennox: POST /v3/users/{id}/federated 18:10:27 { 18:10:27 "federated": { 18:10:27 "idp_id": "1789d1", 18:10:27 "protocol_id": saml2, 18:10:28 ayoung: it shouldn't break anything 18:10:28 "unique_id": "jdoe", 18:10:29 "display_name": "James Doe" 18:10:31 } 18:10:33 } 18:10:39 but in which case there is the possibility on multiple federated blocks 18:10:58 what if we used the OS_FEDERATED URL scheme instead? 18:11:17 ayoung: thats what i was thinking, 18:11:27 jamielennox: multiple federated blocks are okay for different IdPs 18:11:41 can anyone think of the implications of this? 18:11:44 rderose, so this is to create the user prior they authenticate, right? 18:11:47 jamielennox are you proposing that is how we link accounts? 18:11:54 PUT /v3/OS-FEDERATE/idp/"1789d1",/protocol/saml2,/user_unique_id/"jdoe" ... 18:11:56 rodrigods: yes 18:12:01 I know, jdoe not guaranteed to be URL safe 18:12:12 rderose, how can we be sure they will be correctly linked? 18:12:34 i mean... once the user authenticate, it won't create a different entry 18:12:34 lbragstad: no, but i'm thinking of a situation where we have linked accounts and in which case there are multiple of these per user 18:12:40 if we had the user ID, we could do 18:12:58 ayoung stevemar__: we could use OS_FEDERATED, but I just think lets treat federated users like any other users and stop making them special 18:13:00 jamielennox right 18:13:11 also i'm not sure i see the need for unique_id 18:13:15 PUT /v3/OS-FEDERATE/idp/1789d1/protocol/saml2,/user_id with a payload of "unique_id": "jdoe", 18:13:15 "display_name": "James Doe" 18:13:19 rderose, yes and no 18:13:35 jamielennox: it is because we need the bit from the federated idp to create the mapping 18:13:38 rderose, I want FEderation to be the dfault way we work with KEystone's identity 18:13:41 rodrigods: no, because they will already be created; once they auth, we'll pull the existing user 18:13:59 I kindof hate the OS-FEDARTION part but that was not my doing .... 18:14:04 rderose, how will you assure this? 18:14:09 should be just /idp.... 18:14:12 morgan: with this, we don't need the mapping 18:14:16 or mapping is optional 18:14:22 redrose: what do you mean by “pull”, you mean delete? 18:14:27 mapping needs to be pre-set 18:14:32 rodrigods i think because we look up the user's federated bits and compare them to what we've already created, right? 18:14:36 rderose: yep, i was realizing that :) 18:14:40 rodrigods: shadow users first looks if the user exists and if they don't just pulls that user 18:14:41 morgan: yea, was looking at the second post block where you already need the id, guess it makes sense from a new user perspective 18:14:46 doesn't create a new user 18:14:55 I would liketo point Out that I suggested exactly this kind of API about a year ago....so, yeah, I like it. 18:15:18 ayoung: < 1 year ago, in austin :) 18:15:25 stevemar__: lol 18:15:26 but yes, pretty much the same thing 18:15:34 rderose, what you are looking for is something that will pre-create the user, right? 18:15:44 henrynash: I mean, when a federated user auth, we query for that user. if they exist, we user that user ID and if they don't, we create the user 18:15:57 2 us case: one user has never visited, 2 link new protocol to existing user? 18:16:00 rderose: ok, got it 18:16:05 ayoung: essentially allowing operators to do manual provisioning 18:16:10 create user and assign role 18:16:16 rderose: so hows the workflow for an operator? just create all X users one time? 18:16:33 stevemar__: no, shadow mapping will create users in mass 18:16:38 this will be for manual provisioning 18:16:48 rderose: shaddow mapping? 18:16:55 or even things like get me the local user ID so that I can do delegation 18:17:11 dstanek: Shadow mapping will do the auto provisioning, but I still can’t query for the user ID if I want to do delegation or make a concrete role assignment. 18:17:23 dstanek: I see this going hand-in-hand with shadow mapping. Shadow mapping allows for provisioning in mass. While extending the API, allows for other common operations, such as delegation. 18:17:37 what about a create user taht takes the input expected from the IDP as parameters and then we use the mapper to generat the ID (or maybe that is what you are suggesting) 18:17:52 henrynash, ++ 18:17:52 okay, so not a total replacment for mapping engine bits 18:17:59 henrynash, that approach looks safer 18:18:04 rderose, ok, so to link an account to an existing user, you can do that all as a single PUT, where the data is the JSON version of the assertion 18:18:15 more or less another way to solve a similar problem 18:18:16 henrynash: either way, we will generate the user ID; ideally based on the federated attributes 18:18:29 and the URL is based on the OS-FEDERATION url scheme. I'm OK if we drop the OS-FEDDERATION part from there though 18:18:42 rderose: shadow mapping doesn't create multiple users at at time right? it just extends mapping to provision projects, etc? 18:18:42 so /v3/idp is fine 18:18:45 ayoung: cool 18:18:59 dstanek right 18:19:05 rderose: it must be based on the federated attributes 18:19:09 dstanek: ah, right 18:19:16 rderose: if we do it the way I suggested then we are guarnteed to create the same ID, irrespective of whether it was generate by first auth or by this new api 18:19:27 same thing for creating a user: use a POST, I think, is appropriate there. Then the controller and the router don't conflict with the existing user controller 18:19:31 dstanek: currently, it's uuid, but yes, it should be 18:19:49 henrynash: agree 18:20:06 ayoung: ++ 18:20:10 for reporting information.... are we OK changing the output of the GET user ? 18:20:16 or should it be a separate API? 18:20:17 ok - so regardless of how a fedearted use is created, the ID will be the same 18:20:19 okay, this topic has eaten enough time, rderose the spec is getting favorable feedback, lets hash out some minor bits there, look for it to get approved 18:20:26 rderose, henrynash ++ that's was my concern 18:20:41 From scratch I think I would be OK with a GET user...but can we be cautious here and start by just providing a new API? 18:21:10 ayoung, now that i understand better, i guess it should be the same API 18:21:14 i dont think that makes sense with a shadow user, the shadow user id is not supposed to be reflective of a federated login info, it's just an id 18:21:15 I can put all those comments in the review. 18:21:26 rodrigods, related API, but different, just to avoid breaking things 18:21:28 ayoung: please do! 18:21:42 ayoung: we won't be breaking, just extending :) 18:21:54 stevemar__ ++ 18:22:02 rderose, maybe... better safe than sorry 18:22:13 ayoung: :) 18:22:14 adriant: you around? 18:22:20 o/ 18:22:25 #topic Keystone MFA 18:22:26 #link https://review.openstack.org/#/c/343422 18:22:37 patch is here: https://review.openstack.org/#/c/343422/ 18:22:41 ^ implementation 18:22:46 The patch itself is done, looks to have all the right things (docs release notes, etc), just needs people to play with it and test it to see how it works so they can confirm they are happy with it. 18:23:04 There are some issues around the way I'm doing the testing (I need to test standard password auth without TOTP works), and while that works for now, other random unrelated broken tests may crop up. 18:23:09 adriant: that is on my list of things to do soon. FWIW it looks good 18:23:32 was there a specification for this? 18:23:33 There isn't really too much to say, I just wanted to see if there were any last minute points anyone had I've missed. 18:23:41 last time i looked i think it was just about done. adriant i'll look again today. 18:23:52 lbragstad: yes 18:23:57 i'm not seeing one linked in the blueprint 18:24:09 ah, spec came after the blueprint... 18:24:17 lbragstad: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/password-totp-plugin.html 18:24:18 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/password-totp-plugin.html 18:24:20 ah 18:24:27 alright - updating the blueprint 18:24:39 adriant: can we move to your next topic? 18:24:43 yes :) 18:24:47 #topic Spec: User Self Management of MFA 18:24:48 as that's the odd one 18:24:56 spec here: https://review.openstack.org/#/c/345705/ 18:24:56 adriant: thanks for getting up early btw 18:25:17 stevemar__: haha, np 18:25:33 After the passwordtotp patch is merged, Keystone will have MFA support. Problem is, users have no way to make use of it without an admin creating totp creds for them. This spec is about fixing that in a manner that doesn't break things or require a huge rework, but it does add new API features on top of the existing user API (exactly the same way EC2 does). 18:25:52 There has been some discussion about this, and if this should be a new/extended user api, or we change the credentials API. I argue against the latter as it is harder and can break things. 18:26:07 made notes just in case because it is early ^ 18:26:27 So yes, the last point, new API vs extend the credentials one is a point of contention 18:26:48 we do need user self management for TOTP, otherwise TOTP is kind of useless as a feature 18:26:48 adriant: so first question... this can't be done as a policy change? 18:26:58 adriant, why is admin now required? 18:27:02 dstanek: that was my first question in the spec! :) 18:27:20 I've updated the spec itself, it sort of answers those questions. 18:27:23 stevemar__: don't keep me in suspense. what's the answer! 18:27:24 OK 18:27:38 dstanek: hehe, on july 22 -- i forget why 18:27:39 and there is more in the comments themselves 18:27:56 A simple policy change isn't enough 18:28:06 adriant because it's per resource? 18:28:11 we've need to add code to the credentials controllers 18:28:18 if you consider a credential a single resource in a tenant? 18:28:21 adriant: what's the limitation? 18:28:29 i really wish we could just force the system to require multiple auth plugins 18:28:32 a user owns their own TOTP credentials 18:28:39 instead of needing a new passwordtotp plugin explicitly 18:28:42 adriant, OK, I like the "type" argument you post there... 18:28:48 morgan ++ 18:28:53 looks like the right approach 18:28:55 iirc that was what we discussed when we accepted the totp plugin in the first place 18:29:14 because... lets be fair, the auth plugins if enabled do not ensure a specific one is used 18:29:20 so it becomes an all or nothing deal 18:29:32 everyone must use passwordtotp or you have to inspect the token to know if they did 18:29:32 mordred, auth plugins should be linked to idp/protocol 18:29:37 morgan: I agree, and have ideas on that as an approach, but it's hard to enforce. I'll put a spec together for that in future. 18:29:48 er morgan 18:30:03 auth plugins should be linked to idp/protocol and not be a global list 18:30:03 ayoung: i disagree, that is too limiting 18:30:07 all the code would exist in the credentials layer, just the routes themselves would be /users/user_id first 18:30:39 adriant: ^ 18:30:44 morgan, everything should er done via the Federation style API, just Keystone is its own IdP 18:30:48 ayoung: eh. i would be more inclined to say auth-plugins are user-by-user OR idp/protocol 18:30:49 stevemar__: for this spec, pretty much 18:31:04 ayoung: a user should eb able to require mfa not just be limited by what the protocol/idp list is 18:31:10 adriant: looks OK to me 18:31:17 any dissenters? 18:31:19 ayoung: also... some users in an idp/protocol may not use this 18:31:20 adriant: i don't quite understand why the policy would be broken based on your description. couldn't we credential format based on type? 18:31:20 stevemar__: me 18:31:25 morgan: :O 18:31:27 it's the extra routes and serverside generation/activation that make it useful 18:31:31 morgabra, wouldnt OTP be another protocol? 18:31:35 what if a user does NOT want to use MFA? 18:31:42 stevemar__: i do not like adding more plugins for this that is against the original design of the MFA inclusion 18:31:46 like, you konw, if the user is an API-consuming automation script? 18:31:49 stevemar__: this is going down the wrong path. 18:32:02 so - throughout the discussion of this spec - we mentioned that there are several things about the existing credential api that prevent us from doing stuff like this 18:32:04 * mordred interjects insanity because he accidentally got pinged 18:32:05 dstanek: it's not just policy, I want to add the generation of TOTP to the serverside 18:32:19 stevemar__: we should be fixing the plugins so we can by user or by idp/protocol enforce required plugins to be used (if enabled) 18:32:26 Heh...single use tokens! 18:32:38 mordred: you're not insane 18:32:41 \o/ 18:32:42 to me, it would be easier to roadmap a way to fix what we have, clean it up, and elaborate on it later than to release yet another credential api and hope we can clean it up later 18:32:50 lbragstad: that too 18:32:55 lbragstad: ++ 18:32:57 the latter is much harder to do in my opinion 18:33:15 but we then can't do the serverside generation, or the enable/delete needing a passcode 18:33:21 or at least not easily 18:33:25 lbragstad: ++ i mentioned redesign in my review. i think we need to have a clear direction instead of bolting on something else 18:33:36 i think the passwordtotp plugin is fundamentally the wrong approach here. we are diving down a bad direction that is now adding more credential apis 18:34:17 morgan: you want to have multiple auth plugins? like password and totp? 18:34:18 so i dissent here and say we need to ratchet back and fix the system correctly 18:34:23 dstanek: correct 18:34:27 dstanek: you can do that now 18:34:34 morgan: you volunteering? ;) 18:34:36 ypou just can't enforce that multiple plugins are needed 18:34:43 morgan, yes but not by breaking things 18:34:44 morgan, can you write up your objectiions? THink they might be too big for this meeting, and I want to understand them 18:34:46 mordred: ^ do I have time for this? 18:34:50 mordred: :P 18:34:57 but you can't enforce that someone uses 2 of them. that's something we talked about in Austin (i think) 18:35:02 this new plugin allows password+totp to with via password as normal 18:35:08 dstanek: before austin 18:35:21 I'm not using the totp plugin at all, I get the totp passcode from the password itself 18:35:25 dstanek: every time MFA has been brought up we said we need to enforce this. 18:35:41 adriant: i think morgan's point is that we should need another plugin to do that 18:35:51 sticking two auth methods together means ALL the services need a separate totp passcode 18:35:54 yeah - i remember that discussion in austin 18:35:56 we shou;dn't need a plugin for password+totp explicitly 18:35:56 seems like /credentials is kindof like OS-FEDERATION/idp/self/protocol/totp 18:36:19 morgan, but the base password plugin needs to know to strip the passcode from itself 18:36:20 we should be able to say UserX NEEDS to use both totp and password plugins 18:36:23 to auth 18:36:24 otherwise it fails 18:36:27 a cloud might have 3 auth plugins required and want the user to use any 2. with this implementation that would be a lot of subclassing 18:36:48 well maybe user X needs these auth creds for a particular IdP 18:36:49 i thought i had a really detailed discussion about this with dolphm at one point... a long time ago 18:36:51 but user Y (service user) only needs password 18:37:08 should be on a per domain basis 18:37:13 ayoung: hell npo 18:37:14 no 18:37:17 nah 18:37:30 ayoung: how does rescoping work then? 18:37:36 morgan, project-domain? 18:37:43 ayoung: user or idp/protocol level 18:37:45 there is nothing stopping us from doing that as well, my whole point with this patch was to allow totp to work with the standard default 'password' auth 18:37:46 not domain by domain 18:37:53 which boiled down to enforcing authentication factor on specific operations (ie. nova boot doesn't care how i authenticated so long as I used two separate authentication factors, like password and tongue print) 18:37:56 you need to use this Auth form to get access to your role assignments on D->P 18:38:17 ayoung: please no. please please please no. 18:38:22 the passwordtotp plugin strips the passcode from the password, that's all. Doing that as two plugins wouldn't work easily 18:38:42 morgan, my goal is to make the suggestions so wild that we give up on the whole idea all-together 18:38:45 adriant: in the body of the auth request you have multiple plugins specified. this works today 18:38:46 not really 18:39:04 adriant: but we can't say you MUST use both plugins 18:39:05 yes, that is part of the design 18:39:08 morgan: yes, but that's not what I wanted with this, that breaks things 18:39:12 morgan: adriant was trying to not change the cli/horizon/etc for this 18:39:22 morgan we can ALSO do that 18:39:30 adriant: nothing is broken. things would need to be updated 18:39:32 yes, what dstanek said 18:39:52 adriant: except if you are adding a specific plugin you can use any to auth 18:39:53 yes, but updating across multiple projects takes time, and is akin to breaking :P 18:40:17 so you're adding yet-another-auth method and not fixing the issue we said we needed to fix when totp was added 18:40:23 i think the plugin is reasonable, but not sufficient for the overall mfa needs 18:40:34 morgan: I think we need both 18:40:39 sorry, i'm on a soapbox here because we only accepted totp at all because the next step was fix the system 18:40:47 morgan: I agree, we need a way to enforce: "these two together" 18:40:52 i am against adding another plugin with the nebulous "we'll do this in the future" bit 18:41:10 but this plugin is meant to work around that in the mean time, and allow a different password+totp auth method 18:41:18 So, do we have something actionable for the next week, or are we kicking this out of Ocata? 18:41:25 adriant: except it is an all or nothing on the entire cloud 18:41:39 adriant: if password is enabled, they can use password... circumventing totp 18:41:45 even with the new plugin 18:41:51 morgan: the *only* reason i see this plugin as valuable is that a cloud operator won't have control over the libraries a customer is using and they may have to not use MFA until everything works with it 18:41:53 so don't enable password? this is a replacement for password 18:41:59 this plugin makes it *just work* 18:42:05 adriant: and then all service users cannot auth 18:42:13 adriant: and keystonemiddleware is broken 18:42:16 morgan: if you don't have the time to do the work, can you outline what needs to be fixed to adriant ? i'm not even clear how to make multiple auth work 18:42:31 morgan: this plugin works as a replacement for password auth just fine 18:42:32 stevemar__: i can probably do this. let me land the ksa changes. 18:42:39 it does not break password auth without totp 18:42:44 that was the point of it 18:42:50 morgan: service users can still auth... iirc the mfa is only enforced if you have a totp credential 18:42:51 it allows OPTIONAL totp auth with a password 18:43:11 morgan: yes, what dstanek said 18:43:15 ugh. it scans the db on each auth-request to see if you have a totp cred? 18:43:17 gross. 18:43:21 double gross. 18:43:25 it works though 18:43:26 Heh 18:43:33 the totp auth plugin does the exact same thing 18:43:34 Federation 18:43:56 Even password should switch to Federation 18:43:58 i'm actually really annoyed that we went down this path 18:43:58 ayoung: ++. here we debate another IdP feature 18:44:02 but i wont block it. 18:44:27 the only reason totp was included was because we were going to "fix" the auth mechanisms next 18:44:41 otherwise i would have held on the -2 on totp 18:44:44 morgan: can you elaborate how to fix auth in -keystone after? 18:44:50 dstanek, need a way to do "the keystone database is itself and IdP" and then the rest of this falls in to line 18:45:09 stevemar__: yes it is not a hard-to-fix thing. but it requires expanding the api(s). 18:45:12 can we fake the password/totp split in the json payload? 18:45:20 password:totp or similar format? 18:45:41 dstanek: we could in horizon and the in the cli. 18:45:47 heck keystoneauth could do the work for us. 18:45:57 the ksa authplugin could do the magic 18:46:15 but the enforcement on keystone side isnt' there w/o adriant's plugin and changing keystone.conf to only allow the new plugin 18:46:28 adriant: stick around -keystone and chat with morgan later? 18:46:37 ping me, too 18:46:37 the problem is how do you make MFA optional, but enforce it on users who have it? 18:46:38 morgan: ++ 18:46:42 like i said, i wont block this. i am lodging my dissent 18:46:50 stevemar__: yeah I can stick around 18:46:51 adriant: i want to fix that part :) 18:47:05 okay, 15 minutes-ish left 18:47:06 adriant: so we can make it optional/required etc. 18:47:17 let's move on 18:47:22 jgrassler: here? 18:47:26 stevemar__: Yes 18:47:31 #topic Spec: Trust Scope Extensions 18:47:48 jgrassler: you're up! 18:47:52 * morgan crawls back under a rock so as not to derail the meeting too much. 18:47:52 https://review.openstack.org/#/c/396331/ 18:47:59 This is the spec review 18:48:19 tl;dr on it: I want to add an optional whitelist of capabilities to trusts 18:48:47 If that whitelist is present for a trust only the listed operations (in terms of oslo.policy targets) are allowed 18:49:30 yeah, kill that 18:49:34 jgrassler so - i could create a trust giving you the operation to list vms on a project, but *only* list vms 18:49:35 I'd do the enforcement in oslo.policy since that is where all the information about policy targets (and even concrete objects) is available 18:49:41 trusts are not the right abstraction 18:49:44 lbragstad: Exactly, yes 18:49:47 jgrassler that was my next question 18:49:53 this would be a cross project spec 18:50:00 lbragstad: Yes, it would be 18:50:03 No 18:50:12 THis is unworkable 18:50:34 Please read the proposal i have for RBAC in Middleware before you pursue this any further 18:50:46 ayoung link? 18:50:51 it retreads groud we've been over, and it does not work with the current abstraction 18:50:57 lbragstad, in the etherpad 18:51:13 after Taskmnager 18:51:22 #link https://review.openstack.org/#/c/391624/ 18:51:29 ayoung: Where does it break? 18:51:31 the short is "there is no way to tell a user wht they need to delegate" 18:51:56 ayoung: Ah, you mean they do not know the name of the oslo.policy targets? 18:52:03 we have 9 minutes left..too long for this meeting 18:52:13 and the role needed for those policy targets 18:52:44 jgrassler, I had a proposal for operational scoped tokens about a year ago...fell apart on this issue 18:52:59 so... URL patterns 18:53:05 jgrassler: no a backup_vm target may under the hood use other targets to do its work. what happens there? 18:53:09 enforce RBAC on 18:53:19 gah..wrong computer 18:53:42 dstanek: Yes, that problem is unsolved, currently :-/ 18:53:53 enforce RBAC on soemthing like POST /v2.1/{project_id}/server/{server_id 18:54:10 dstanek: It's the same issue with Barbican secret containers (they consist of multiple secrets) 18:54:28 jgrassler, so, work with me on the RBAC stuff and we'll get to what you want 18:55:34 ayoung: But how do you get the thousands of roles this approach requires for the same granularity in place? 18:55:48 jgrassler, step by step.... 18:56:00 so in the Z release :-P 18:56:10 dstanek: we'll flip over by then 18:56:11 dstanek hopefully 18:56:15 nah, we have something that will work based on all the restrictions 18:56:18 ayoung: That one is my main objection to it. It requires a _lot_ of infrastructure to be in place :-/ 18:56:33 please read through https://review.openstack.org/#/c/391624/ 18:56:51 jgrassler, believe it or not, it is the path of least resistnace 18:57:00 ayoung: Don't get me wrong, I like your RBAC proposal per se. But not for this purpose. At least not in 2016 :-) 18:57:02 it is all within code that the Keystone project manages 18:57:41 jgrassler, what you are proposing is unworkable. You cannot enforce policy the way you propose without getting changes into every single project 18:57:54 just look at how long bug 968696 has been open 18:57:54 bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Matthew Edmonds (edmondsw) 18:58:05 ayoung: oslo.policy would suffice. 18:58:10 Hey, assignemd to Matt...ah whatever... 18:58:13 jgrassler, hah 18:58:46 "Baby I've been here before I've seen this room and I've walked this floor I worked on this alone before I knew ya" 18:58:58 jgrassler, lets take it off line 18:59:06 I will be very happy to work through these things with you 18:59:14 meeting is almost over 18:59:22 we left a lot on the agenda 18:59:27 i'll add it to next weeks 18:59:28 I want to get the RBAC spec in this release 18:59:31 ayoung: Agreed on that. I really don't want to rush through this in half a minute :-) 18:59:39 thank you very much for spending 40 mins on the second topic :( 18:59:40 please review 18:59:46 please read through https://review.openstack.org/#/c/391624/ 18:59:50 agrebennikov: happens dude 19:00:01 agrebennikov: we can discuss your thing in -keystone after this meeting 19:00:04 since i have the -2 on it. 19:00:08 exactly 19:00:16 and we have a customer online)) 19:00:20 #endmeeting