18:00:06 <lbragstad> #startmeeting keystone
18:00:07 <openstack> Meeting started Tue Nov 22 18:00:06 2016 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <openstack> The meeting name has been set to 'keystone'
18:00:14 <lbragstad> 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
18:00:21 <jaugustine> hello
18:00:22 <dstanek> o/
18:00:23 <rodrigods> o/
18:00:25 <lbragstad> #agenda https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:25 <gagehugo> o/
18:00:26 <rderose> o/
18:00:26 <spilla> o/
18:00:32 <breton> howdy
18:00:41 <lamt> o/
18:00:45 <lbragstad> ah...
18:00:46 <lbragstad> #link agenda https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:46 * crinkle not really around
18:00:47 <edtubill> o/
18:01:08 * stevemar is also not really around, but in a different place thank crinkle
18:01:13 <stevemar> than*
18:01:24 <stevemar> thanks lbragstad ;)
18:01:29 <lbragstad> stevemar np
18:01:40 <raildo> o/
18:02:14 <knikolla> o/
18:02:27 <ayoung> lbragstad, So I'd really like to get the RBAC spec in to Ocata
18:03:00 <lbragstad> ayoung cool - let's talk about it at the end of the meeting - since we have a quick agenda anyway
18:03:04 <browne> o/
18:03:13 <ayoung> lbragstad, first item is specs.
18:03:55 <ayoung> Announcements [stevemar]
18:03:56 <ayoung> Next milestone is Ocata-2 -- Week of Dec 12-16 -- This is also spec freeze week, specs must merge by then!
18:04:24 <lbragstad> ayoung looks like a request for reviews - but we can talk about
18:04:25 <lbragstad> https://review.openstack.org/#/c/391624/
18:04:46 <lbragstad> #optic Announcements
18:04:55 <lbragstad> #topic Announcements
18:05:01 <lbragstad> Next milestone is Ocata-2 -- Week of Dec 12-16 -- This is also spec freeze week, specs must merge by then!
18:05:19 <lbragstad> also - looks like we
18:05:29 <lbragstad> are going to stick with the etherpad format for the meeting
18:05:43 <lbragstad> at least according to the current responses - https://goo.gl/forms/Gs4lZxgktRzlwHAn2
18:06:00 <lbragstad> Reminder that we have the policy meeting tomorrow
18:06:16 <lbragstad> #link https://review.openstack.org/#/c/398500/ merged
18:06:45 <lbragstad> so there should be an ical published http://eavesdrop.openstack.org/ by EOD
18:07:23 <lbragstad> ayoung can we breeze through breton's topic before the RBAC spec since it was on the agenda last week and we didn't get to it?
18:07:33 <ayoung> check
18:07:40 <lbragstad> ayoung htanks
18:07:53 <lbragstad> #topic Request id chaining in keystoneclient
18:07:55 <morgan_> o/
18:07:57 <lbragstad> breton you're up
18:08:05 <breton> there was that spec with request-id chaining
18:08:18 <breton> the idea was to send the same request-id to all services
18:08:24 <breton> so that actions could be tracked
18:08:35 <ayoung> we have a plan in place to fix?
18:08:42 <breton> it was a cross-project spec and there was a huge discussion
18:08:55 <lbragstad> breton is there a link to the spec?
18:09:02 <breton> and, apparently, it was  broken in ksc for ~2 major releases
18:09:24 <breton> lbragstad: http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
18:09:26 <ayoung> and...since everything starts with a keystone token, people thought the request ID should come from Keystone, but since  token can be used on multiple requests, even the auditID is not an appropriate value
18:09:40 <breton> lbragstad: i couldn't find the spec for reusing request-id though
18:09:42 <morgan_> ayoung: i remember this
18:09:49 <ayoung> and we can't trust the client to generate it as they could fake it out
18:09:50 <morgan_> ayoung: the convo went in a lot of circles for that
18:10:03 <morgan_> we have to pick *something* to trust
18:10:09 <ayoung> and we don't know, after the token is requested, what the right place to generate the request ID is
18:10:15 <breton> we removed the last bits of this broken request-id thing in  https://review.openstack.org/#/c/396260/
18:10:16 <lbragstad> so a request ID needs to be a combination of the token + operation?
18:10:20 <morgan_> honestly, i think the client can generate it just fine.
18:10:37 <ayoung> seems like it has to be in keystonemiddleware, and passed down the reuqest hierarchy.  But...hmmm
18:10:37 <breton> and released yesterday after some discussion
18:10:41 <morgan_> it's better to have a request-id than not.
18:10:58 <ayoung> there is no way to prevent a bad actore from faking the ID
18:10:59 <breton> someone should bring it back to keystoneclient
18:11:03 <morgan_> ayoung: ++
18:11:11 <breton> i am not sure that it works in other clients though.
18:11:18 <ayoung> I wonder if this could be piggybacked with jamielennoxs service token approach
18:11:41 <morgan_> ayoung: possibly
18:11:50 <ayoung> it seems that the request ID should be generated at the edge,  so if a service is calling another service, we trust it to generate the ID and pass it along
18:11:51 <breton> please review https://review.openstack.org/#/q/topic:bp/return-request-id-to-caller+project:openstack/python-keystoneclient that should bring it back.
18:12:00 <ayoung> breton, kill it
18:12:09 <morgan_> breton: i would rather see it in KSA than ksc in this case
18:12:12 <ayoung> it is not a keystoneclient problem to solve.  It might be keystonemiddleware, though
18:12:13 <breton> ayoung: done
18:12:19 <morgan_> keystoneclient is the wrong place regardless
18:12:28 <ayoung> might need KSA support, but I think it is middleware
18:12:38 <morgan_> the way i see it, ksa supports it
18:12:41 <morgan_> ksm uses it
18:12:48 <breton> uses it?
18:12:49 <breton> for what?
18:12:55 <morgan_> uses/makes use of the support
18:12:56 <ayoung> breton, to pass it on
18:12:59 <morgan_> ^^
18:12:59 <ayoung> in a trusted manner
18:13:03 <morgan_> what ayoung said.
18:13:13 <breton> it is not auth thing
18:13:30 <morgan_> but keystoneauth *is* the session for a given set of requests
18:13:30 <ayoung> so...what we are really talking about here is an audit trail, but the ability to distinguish between two different requests using the same token
18:13:37 <ayoung> othewise, the token audit ID is sufficient
18:13:48 <ayoung> breton, it is an Audit thing
18:13:50 <breton> right now it is in all python-*client, not sure if it works
18:13:51 <morgan_> let it be part of the session object(s) that are passed around internally
18:14:12 <ayoung> so...to do it right (overdesign) we would do something like this:
18:14:36 <ayoung> first service that gets the request geneerates and ID and signes  it (yeah PKI again...this is athought experiment, not reality, bear with me)
18:14:48 <ayoung> and then each service in the chain adds its own signature to it.
18:14:49 <morgan_> even if we started with audit id. that is a step in the right direction (just don't reference the audit-id as the audit-id, so if we want t change/enhance it we can)
18:15:27 <ayoung> ugh...not even that signing thing works.
18:15:40 <ayoung> The problem is that we have to treat services like Trove and Sahara as untrusted services
18:15:50 <lbragstad> ayoung the request id would change every time it hits a new service, wouldn't it?
18:15:54 <ayoung> or add some other service outthere that is not under the big tent, and you get the same idea
18:16:04 <morgan_> so simple solution
18:16:16 <morgan_> lets start with the audit id. or a UUID seeded from the audit-id
18:16:25 <morgan_> now we have at least *some* level of tracking.
18:16:27 <ayoung> lbragstad, does it?  I would not think that would be useful, but the id still then needs to be linked to the endpoint, or a hacked endpoint could modify
18:16:37 <morgan_> or audit_id+timestamp if request_id is none
18:16:49 <ayoung> I thought the idea of a request id, though, was to track the request across multiple services
18:16:49 <morgan_> (seeded into uuid)
18:16:55 <breton> request-id thing was cross-project. Before killing it and discussing something new we should talk to other projects.
18:17:02 <ayoung> audit_id+timestamp is pretty good
18:17:18 <ayoung> breton, I come to praise audit id, not to bury it
18:17:25 <ayoung> morgan_, I think that is it
18:17:29 <ayoung> audit_id + timestamp
18:17:44 <ayoung> the worst a service could do then is munge the timestamp
18:18:10 <ayoung> any other service can confirm that the audit_id on the token matches...
18:18:39 <ayoung> breton, would that work?  request ID = (token['audi'id'], timestamp_of_initial_request)
18:18:52 <morgan_> ayoung: uuid.uuid5(audit_id, timestamp) (timestamp is namespace)
18:18:56 <morgan_> ayoung: or something like that
18:19:02 <breton> ayoung: no idea :)
18:19:08 <ayoung> morgan_, sha256?
18:19:15 <morgan_> it's sha1
18:19:22 <morgan_> but that is sufficient for a request_id
18:19:25 <ayoung> morgan_, it can always be a calculated value, so long as we capture the original request time
18:19:34 <morgan_> right
18:19:52 <morgan_> i'd rather populate a uuid (strings are easier to suss out in longs) if we're doing it.
18:19:58 <morgan_> logs*
18:20:03 <morgan_> but impl detail aside
18:20:08 <ayoung> so...original request timesamp now becomes an additional header?
18:20:12 <morgan_> audit_id + timestamp_of_request_at_edge
18:20:41 <ayoung> morgan_, sha256 as a string.  Lets avoid any crypto discussion
18:20:41 <morgan_> ayoung: sure. or make it all the same header
18:21:10 <morgan_> OpenStack-Request-Id: <calc_string>, <timestamp>
18:21:12 <ayoung> morgan_, we need the initial time in order to confirm the hash.
18:21:22 <morgan_> if you want to re-calc it you can
18:21:38 <ayoung> breton, is that enough to go on?  We don't need to design it all here, but you should be able to take that and run.  Hit me or morgan_ up for ?s in #keystone if needs be
18:21:40 <morgan_> split is cheap in python and any other lang (maybe excluding C)
18:21:51 <morgan_> ayoung: ++
18:22:12 <morgan_> and this can be encoded in keystoneauth (support for it) so it just exists
18:22:21 <lbragstad> breton does that help?
18:22:51 <ayoung> #action breton to spec out new request id format based on token audit ID and timestamp of original request
18:23:11 <morgan_> since we are trying to get sessions to be passed in from middleware and reused when talking to subsequent services for the request
18:24:23 <breton> please comment on https://review.openstack.org/#/q/topic:bp/return-request-id-to-caller+project:openstack/python-keystoneclient too
18:24:31 <breton> so that the person doesn't work on them any more
18:25:03 <lbragstad> alright - moving on
18:25:04 <breton> i was actually trying to notify people about the request-id thing :p
18:25:13 <lbragstad> #topic PCI lockout and recovery
18:25:18 <lbragstad> gagehugo you're up
18:25:25 <gagehugo> ok
18:25:32 <gagehugo> I saw people responded already
18:25:54 <gagehugo> but basically, I was looking at this later yesterday: https://bugs.launchpad.net/keystone/+bug/1641645
18:25:54 <openstack> Launchpad bug 1641645 in OpenStack Identity (keystone) "PCI: a locked out user must ask an admin to unlock their account" [Wishlist,Opinion] - Assigned to Gage Hugo (gagehugo)
18:25:59 <ayoung> breton, use that new -2 you have to stop any really bad decisions in their tracks
18:26:06 <ayoung> just, be nice when you do it
18:26:32 <ayoung> gagehugo, so...I would think a domain admin yes, but a locked account cannot be fixed by a user themself
18:26:55 <morgan_> a locked out account is just that.
18:26:57 <gagehugo> yeah, I think the title should probably have been more specific about expired password users vs locked out
18:26:58 <morgan_> locked out
18:27:04 <morgan_> ah
18:27:10 <gagehugo> unless both are considered "locked out"
18:27:15 <lbragstad> agreed
18:27:20 <ayoung> expired password should be resettable by the user.  And that is a code/logic error, I bet
18:27:24 <morgan_> expired password is something valid to address. some systems require admin intervention on that front
18:27:27 <morgan_> some dont
18:27:32 <lbragstad> morgan_ ++
18:27:35 <gagehugo> morgan_ yeah
18:27:44 <morgan_> we would need to re-work the password self-change i think
18:27:53 <ayoung> don't check the expiry when the user calls that API, and let it be called (only?) with basic auth
18:27:55 <ayoung> HA!
18:27:59 <ayoung> Basic-Auth middleware
18:28:00 <morgan_> but i am 100% ok with keystone supporting self-service change of expired password
18:28:16 <morgan_> ayoung: does self-service password change require a token?
18:28:19 <morgan_> if it does...
18:28:20 <gagehugo> yes
18:28:24 <ayoung> morgan_, it does
18:28:31 <morgan_> then that is something we would need to address
18:28:38 <ayoung> morgan_, the only operation in openstack that does not require a token it to get a token
18:28:40 <morgan_> it would need to support a tokenless-mode
18:28:46 <ayoung> tokenless with x509 works
18:28:48 <gagehugo> I left a comment about that on the bug listing, it was why I was concerned about what direction to take with it
18:29:08 <morgan_> it should be fine to make self-service password change not require a token
18:29:17 <ayoung> the API takes the old Password in the body of the request?
18:29:19 <gagehugo> yeah
18:29:20 <morgan_> yes
18:29:56 <gagehugo> you also need to know the user_id I believe
18:30:01 <dstanek> the expirationlogic was modeled after how other orgs handle the situation (we just dont' implement the grace period)
18:30:14 <morgan_> dstanek: and i think it's fine as is.
18:30:25 <rderose> allow users to change when their password expires? we discussed this during development and the decision was that once a password expires, it requires a admin password reset.
18:30:26 <gagehugo> dstanek I've worked in places that handle it either way
18:30:45 <morgan_> rderose: i've seen it both ways
18:30:57 <morgan_> rderose: i don't feelw e need to change it.
18:31:04 <dstanek> gagehugo: we didn't want to make it infinitely configurable so we opted for the most secure route
18:31:11 <rderose> morgan_ true
18:31:14 <morgan_> but fwiw, i would be 100% ok with self-service change to work for expired passwords
18:31:14 <gagehugo> dstanek I'm fine either way
18:31:23 <morgan_> since we can lock an account independantly
18:31:24 <morgan_> (disable)
18:31:34 <morgan_> we don't require a password or password expiry to change it
18:31:44 <morgan_> it also could allow an admin to force a password change on next login
18:31:52 <morgan_> here is your temp password, use this api and change it
18:32:03 <morgan_> since the password is "expired" to start
18:32:04 * dstanek just gave his last 2cents away before vacation brain sets in
18:32:22 <morgan_> looking at active directory style setup (and some LDAP impls)
18:32:53 <morgan_> there is definite use for forcing a password change so the user doesn't need to tell the admin the real password -- and the admin *cant* know it because the change is required
18:33:08 <ayoung> So... to do that would, I think, require a different Paste Pipeline
18:33:22 <morgan_> ayoung: no, we explicitly exempt some apis
18:33:26 <dstanek> i don't think admins need to know the old password, that's just self-service
18:33:33 <morgan_> aka no enforcement
18:33:54 <morgan_> dstanek: right, but in the case of admin-password set you're implicitly telling the admin a password to use
18:34:06 <ayoung> gagehugo, is that enough for you to go on?
18:34:06 <morgan_> often orgs have an admin set a temp password that must be changed
18:34:21 <lbragstad> no enforcement and a very specific case that someone's password is expired
18:34:28 <ayoung> Fix just the expired case, make it skip the token request...that will require a change in Keystoneclient, too
18:34:43 <morgan_> ayoung: hm. yes minor change to ksc
18:34:44 <ayoung> and...do we have a way to get that URL to the end user without a token?
18:34:47 <gagehugo> ayoung kinda? it's still a question of whether or not to change it
18:34:49 <dstanek> we actually talked about forced-reset and i think the concensus was that it was bad enough that we added PCI features to the keystone IdP that we didn't want to have any extras. the advice was to use a real IdP
18:34:57 <gagehugo> but right now just requiring an admin to do it works
18:35:05 <ayoung> gagehugo, yes, change only the reset-password case, and only on expired, not locked
18:35:17 <dstanek> PCI was to be the bare minimum as opposed to a base for building an IdP
18:35:18 <gagehugo> ayoung ok
18:35:34 <morgan_> like i said, don't feel we need to change it
18:35:39 <morgan_> it just has a real use case if we do
18:36:14 <gagehugo> could we add a config option to disable users resetting their own passwords when expired? If whoever doesn't want that option?
18:36:16 <morgan_> ayoung: well, the auth request could return the URL for password change if password is expired (regardless of the value of the password)
18:36:22 <dstanek> morgan_: if we do change it then it would mean y'all were right and is was too slippery a slope
18:36:35 <morgan_> dstanek: i think we've already hit that slope
18:36:48 <morgan_> dstanek: we implemented basic PCI-DSS support
18:36:50 <ayoung> morgan_, I like that. Very rest.
18:36:51 * dstanek hi fives morgan_
18:37:01 <ayoung> THat slope has snow on it
18:37:09 <ayoung> and it is forming moguls
18:37:12 <morgan_> ayoung: nah, sierra cement...and it's iced over
18:37:22 <morgan_> the avalanche started a few thousand feet above you..
18:37:28 <ayoung> frozen moguls
18:37:30 <morgan_> you have no avalanche gear...
18:37:33 <ayoung> on Telemark skis
18:37:35 <morgan_> :P
18:37:41 <ayoung> I have Avalanche gear.  I might be the only one that does
18:37:49 <ayoung> probe and beacon and collapsable shovel
18:38:00 <morgan_> annnyyway
18:38:01 <ayoung> next topic
18:38:04 <dstanek> ayoung: probably
18:38:05 <gagehugo> ok
18:38:21 <lbragstad> gagehugo want to take point on updating the bug with the discussion here?
18:38:27 <gagehugo> will do
18:38:30 <lbragstad> minus avalanche talk
18:38:34 <gagehugo> aw
18:38:38 <morgan_> lol
18:38:45 <lbragstad> gagehugo cool -thanks
18:38:46 <lbragstad> #topic RBAC specification
18:38:49 <lbragstad> ayoung
18:38:54 <lbragstad> go ayoung go!
18:39:11 <ayoung> OK... RBAC
18:39:14 <ayoung> so I want this spec in
18:39:19 <ayoung> just the Keystone piece of it
18:39:29 <ayoung> and just the REST api to start
18:39:39 * morgan_ read that as "The Keystone Price"
18:39:39 <ayoung> #link https://review.openstack.org/#/c/391624/
18:39:47 <morgan_> and i wondered when we entered the game of thrones
18:40:43 <ayoung> there are details to work out,  so, should I split the spec into toe pieces and only putthe REST part in the first piece, and then the second is enforcement
18:41:16 <ayoung> enforcement is going to be done based on the REST API, and in middleware first, although the "RBAC during the token validation" has struck some interest and could still be done as a second piece
18:41:19 <lbragstad> ayoung what specifically is the REST part?
18:41:36 <lbragstad> because i was thinking the REST part was the enforcement part...
18:41:44 <ayoung> lbragstad, upload and fetch of mpping from URL patterns to roles
18:42:07 <lbragstad> ayoung so the enforcement part would include the changes to the token validation api
18:42:09 <ayoung> you need a management interface before you can have enforcement
18:42:10 <lbragstad> that's what you mean?
18:42:15 <ayoung> right
18:42:18 <lbragstad> ok
18:42:51 <ayoung> lbragstad, and in fact, I am right now thinking that enforcement would be done in keystonemiddleware.  Then, if e do the -enforce -during token validation" we would reuse the middleware code inside of Keystone
18:42:55 <ayoung> so there is a natural ordering:
18:42:58 <ayoung> 1. management API
18:43:07 <ayoung> 2. Enforce in middleware (leaves caching alone)
18:43:17 <ayoung> 3.  enforce in token API (optional, depends on 2)
18:43:48 <lbragstad> and 3 would break caching... right?
18:43:59 <ayoung> It means that once the API is working for management, there will be follow on changes to middleware.
18:44:02 <ayoung> lbragstad, right
18:44:22 <ayoung> lbragstad, and I can make that its own spec, so we can judge it separately
18:44:45 <lbragstad> so - right now policy has two places that it gets information from
18:44:46 <lbragstad> 1.) the policy file
18:44:48 <lbragstad> 2.) keystone's token response
18:45:08 <lbragstad> introducing the management api essentially puts both of those pieces of information into keystone, right?
18:45:14 <ayoung> 3) the service itself
18:45:25 <ayoung> lbragstad, so yes
18:45:48 <ayoung> lbragstad, as the new mechanism skips the service specific attributes
18:46:24 <lbragstad> have other projects thought about this? I assume this would need a migration
18:46:45 <lbragstad> or do they have an opinion?
18:48:21 <ayoung> there  is a migration path, but to start, there would be no impact
18:48:33 <ayoung> it would be disabled by default. People could then enable it to test it out
18:48:41 <ayoung> as all good things should be;  sportsmanlike
18:49:12 <ayoung> but we can probably pregenerate all the URL pattern mappings based on the API specs for the other projects, and just assign them the Memeber role
18:49:26 <ayoung> so long as admin implies member, that will continue to work as is
18:50:11 <lbragstad> so - if a policy changes for a project, they have to update the policy as it is stored in keystone.
18:50:21 <ayoung> lbragstad, don't call it policy
18:50:22 <lbragstad> is there a way to bootstrap this in keystone?
18:50:32 <ayoung> yes, there is a way:
18:50:54 <ayoung> one thing I have not done yet, and that nedsto be better clarified in the spec is how to specify a default rule if there is no match
18:51:22 <ayoung> we could then load up just the defaults on a per service basis.  We could even generate those automatically based on the service catalog if we wanted
18:51:31 <morgan_> ayoung: that is probably the best bet
18:51:40 <morgan_> the per-serivce basis that is
18:52:07 <ayoung> So, lets get the management API spec approaved (I'll split it later today) and we can continue to work through the implementation details
18:52:32 <ayoung> everyone OK with this approach?
18:52:35 <morgan_> wfm
18:52:47 <lbragstad> does anyone have reservations?
18:53:01 <lbragstad> we can take the time to go through this in the policy meeting tomrrow too
18:53:06 <lbragstad> if people have more questions
18:55:08 <lbragstad> thinrichs isn't here is he?
18:55:22 <lbragstad> or edmondsw
18:55:31 <lbragstad> ruan?
18:56:48 <lbragstad> ayoung would you be available to field questions at tomorrow's meeting if people have them?
18:57:00 <ayoung> yes I will
18:57:19 <lbragstad> thinrichs, edmondsw, ruan, all seem to have a bunch of feedback on policy - so having their input would be nice
18:57:28 <lbragstad> anything else?
18:57:33 <lbragstad> we have two minutes left?
18:57:40 <lbragstad> s/?//
18:58:43 <lbragstad> alright - let's call it a minute early
18:58:44 <lbragstad> thanks for coming!
18:58:45 <lbragstad> #endmeeting