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