18:01:12 <morganfainberg> #startmeeting keystone
18:01:13 <openstack> Meeting started Tue May 27 18:01:12 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:17 <openstack> The meeting name has been set to 'keystone'
18:01:35 <morganfainberg> #topic identity-specs repo
18:01:45 <ayoung> morganfainberg, you running things today?
18:01:45 <morganfainberg> dolphm, o/
18:01:50 <dolphm> morganfainberg: this is yours
18:01:50 <bknudson> I'm working on a spec
18:01:59 <morganfainberg> ayoung, yeah.
18:02:09 <morganfainberg> ok so we offically have a specs repo now!
18:02:11 * ayoung thinks all of the power of being on monty's team is headed ot morganfainberg 's head
18:02:14 <dolphm> yay
18:02:18 <stevemar> haha
18:02:29 <morganfainberg> ayoung, LOL
18:02:31 <morganfainberg> #link https://github.com/openstack/keystone-specs
18:02:52 <bknudson> this new spec is for v3 extension advertisement
18:02:59 <morganfainberg> the repo is keystone-specs (after much deliberation every program is using the code names)
18:03:00 <ayoung> morganfainberg, already updated.  Should be able to just modify the link in .git/config to point to the new repo
18:03:07 <dolphm> juno 1 is june 12, so basically anything not about to land will need a spec https://wiki.openstack.org/wiki/Juno_Release_Schedule
18:03:13 <morganfainberg> dolphm, ++
18:03:59 <henrynash> is there a template of a spec for us to follow (I see a template.rst in there, but not sure it has anything in it)?
18:04:00 <morganfainberg> keystone core members are responsible for reviewing specs as well now (we don't have a separate team like some other projects do)
18:04:07 <dolphm> docs also asked that we move all our specs from identity-api into keystone-specs - which would also make it easier for us to propose API changes as part of spec proposals
18:04:27 <stevemar> henrynash, hmmm, there was a lengthy template, i'll see if i can find it
18:04:28 <henrynash> ahh, sorry,  I see it is one level up
18:04:29 <bknudson> henrynash: the template has the sections to fill in
18:04:30 <morganfainberg> dolphm, does the doc team mind if we don't give them commit rights?
18:04:30 <nkinder> henrynash: the template seems to provide a good overiew
18:04:35 <morganfainberg> dolphm, right now they have commit rights to identity-api
18:04:36 <stevemar> henrynash, ++
18:04:37 <morganfainberg> erm... approval
18:04:39 <dolphm> henrynash: there are two - the empty one needs to nuked?
18:05:01 <bknudson> it's a symlink
18:05:01 <dolphm> morganfainberg: i think that might have been the point - they don't want our API specs :)
18:05:03 <morganfainberg> dolphm, the templates that are empty are symlinks so docs will build until we have a actual spec
18:05:13 <morganfainberg> cc henrynash ^
18:05:30 <morganfainberg> once we have a real spec we can remove the symlink
18:05:31 <bknudson> don't try checking it out on windows
18:05:36 <henrynash> morganfainberg: right, ok got it
18:05:50 <morganfainberg> bknudson, so, i hear we need to not do symlinks next time and maybe just a copy?
18:06:02 <stevemar> are we having a J2 cutoff for all features that aren't extensions again?
18:06:05 <morganfainberg> or just fix it now as well so we don't break people.
18:06:11 <dolphm> bknudson: this is going to break my workflow then
18:07:04 <gyee> definitely will break windows 8.1
18:07:17 <bknudson> seems like we should fix the doc build so that it doesn't break if there's no files in a directory
18:07:27 <dolphm> gyee: windows 8.0 4 life, yo
18:07:32 <gyee> heh
18:07:47 <dstanek> :( i think i'm in the wrong meeting
18:07:50 <morganfainberg> bknudson, sure.
18:08:17 <morganfainberg> bknudson, i think it's just how the index base is built, not sure we can "fix" it though
18:08:41 <dolphm> morganfainberg: the symlink dies as soon as we have a real spec, correct?
18:08:47 <dolphm> (is there only one?)
18:08:47 <morganfainberg> dolphm, that is the plan
18:08:58 <bknudson> maybe we could have a spec for the release... e.g., there's some work to do for every release
18:09:05 <morganfainberg> dolphm, there is a symlink for each directory (e.g. ksc, juno, etc)
18:09:10 <bknudson> for example, removing stuff that's deprecated.
18:09:13 <dolphm> bknudson: deprecations and removals and whatnot?
18:09:18 <dolphm> release notes?
18:09:29 <morganfainberg> dolphm, pre-development notes?
18:09:36 <morganfainberg> dolphm, summit summary?
18:09:51 <dolphm> i'd like release note contributions to be an artifact produced by the -specs repo anyway
18:11:12 <ayoung> dolphm, what about a doc about work that was bumped from the previous release?
18:13:00 <morganfainberg> ayoung, i think a summit summary (even if it's just a link to the etherpads) would be a solid start. anything bumped from previous release would need to be re-proposed (might be a summary approval, but still needs reproposal)
18:13:23 <dolphm> ayoung: that'll basically be tracked by blueprints that are unmerged, the specs will have to be proposed as a move to the next release
18:13:38 <dolphm> morganfainberg: ++
18:13:52 <dolphm> s/unmerged/not "Implemented"/
18:14:19 <morganfainberg> dolphm, you have a great summary (i saw you taking tons of notes) mind replacing the symlink with that? or something derived from that?
18:14:34 <morganfainberg> and future releases we'll do the same
18:14:54 <dolphm> morganfainberg: my summit summary thing?
18:15:00 <morganfainberg> dolphm, yeah
18:15:15 <dolphm> morganfainberg: i'm not clear on what do you want me to do with it?
18:15:17 <dolphm> #link http://dolphm.com/openstack-juno-design-summit-outcomes-for-keystone/
18:15:25 <dstanek> morganfainberg: even with real docs won't it still be broken on windows because of the specs symlink?
18:15:45 <morganfainberg> dolphm, aha, i was thinking of just taking that and stick it in the repo as the "juno targets"
18:16:08 <morganfainberg> dolphm, instead of the symlink to the template
18:16:34 <dolphm> morganfainberg: not all of them are *targets* for juno (like Centralized quota-management), nor specific to keystone (like TC-blessed API conventions)
18:16:37 <morganfainberg> ah
18:17:29 <morganfainberg> dstanek, probably same issue :(
18:18:03 <dolphm> morganfainberg: i don't know that we need to care too much about -specs + windows
18:18:11 <morganfainberg> dolphm, probably not.
18:18:38 <dolphm> client seems to be the only place where windows users seem to appear
18:18:51 <dolphm> and they're few and far between
18:19:01 <morganfainberg> will client run on windows 3.1 for workgroups?
18:19:04 <bknudson> another lame joke that went terribly awry.
18:19:07 <morganfainberg> cause...
18:19:30 <morganfainberg> bknudson, legitimately my previous company many people contributed from windows systems (did checkouts etc)
18:19:59 <morganfainberg> most converted to a non-windows OS eventually
18:20:03 <dolphm> morganfainberg: we only support two stable releases back, so windows 98se & windows XP
18:20:08 <morganfainberg> dolphm, ++
18:20:48 <ayoung> Win2k was never considered stable?
18:20:59 <dolphm> morganfainberg: #topic
18:21:04 <morganfainberg> anyway back on topic
18:21:07 <ayoung> Excuse me ME
18:21:13 <ayoung> Win ME
18:21:18 <morganfainberg> i think we're done on specs
18:21:20 <morganfainberg> next topic
18:21:30 <morganfainberg> #topic Hackathon information
18:21:33 <morganfainberg> dolphm, this one is you.
18:21:50 <morganfainberg> #link http://dolphm.com/openstack-keystone-hackathon-for-juno/
18:21:53 <dolphm> i have no new information to report since last week :( haven't heard back from geekdom but i sent them another ping today
18:22:24 <dolphm> if you are eager to book something, do flights but not hotels yet
18:22:57 <bknudson> rackspace is not close to geekdome?
18:23:05 <dstanek> dates are firm right?
18:23:08 <dolphm> bknudson: geekdom is middle of downtown
18:23:33 <dolphm> dstanek: yes, let's say dates are firm. if geekdom somehow falls through, we'll do rackspace castle again
18:24:03 <dstanek> ok, on the security lists there were telling folks to get approval for those dates
18:24:17 <dolphm> cool
18:24:25 <bknudson> I understand there's an OSSG meeting before keystone meeting
18:24:26 <nkinder> dstanek: the security team is likely going to move things to a different date
18:24:45 <dstanek> nkinder: not the same week anymore?
18:24:45 <dolphm> nkinder: significantly later in the cycle, or?
18:24:51 <nkinder> there are some date conflicts for a number of OSSG members, so something else will likely be set up
18:25:01 <nkinder> The exact dates aren't clear yet.
18:25:10 <dstanek> ah, i didn't see that follow up
18:25:11 <dolphm> nkinder: and barbican is still planning on July 7, 8, 9, correct?
18:25:21 <nkinder> dolphm: that is my understanding, yes
18:25:30 <morganfainberg> nkinder, thats unfortunate would have been good to have all the security minded folks/teams (OSSG, barbican, keystone) around
18:25:33 <dolphm> good, because i'm pursuing space for them on those dates :P
18:25:37 <nkinder> dstanek: it was sent out privately
18:26:37 <dstanek> nkinder: that would explain it then..that's too bad - i was looking forward to seeing how you guys operate
18:26:50 <gyee> morganfainberg, security is a mindset anyway :)
18:26:59 <morganfainberg> gyee, hehe
18:27:12 <bknudson> since we've got the OSSG we don't have to think about security for ourselves
18:27:27 <nkinder> :o
18:27:44 <dstanek> bknudson: that's a good point! we can just mark everything as having a security impact
18:27:45 <ayoung> Shall we talk plugins?
18:28:00 <morganfainberg> #info Dates are set for meetup July 9-11th, 2014
18:28:07 <morganfainberg> #topic Open Discussion
18:28:22 <nkinder> I added a topic to the agenda about auth plugins
18:28:31 <morganfainberg> nkinder, hm i didn't see it
18:28:38 <morganfainberg> nkinder, aha
18:28:41 <morganfainberg> ok
18:28:42 <morganfainberg> well then
18:28:50 <morganfainberg> #topic Auth plugin method signature changes
18:28:59 <morganfainberg> nkinder, all you
18:29:04 <ayoung> Break all the old clients!
18:29:05 <nkinder> I'm working on hardening how unscoped/scoped tokens work when using a token for auth
18:29:26 <nkinder> This requires scope information from the request to be available inside of the auth plugins
18:29:29 <gyee> ayoung, you break the clients, somebody will wait for you at the parking lot
18:29:30 <ayoung> nkinder, specifically from Horizon, which is the nasty use case....
18:29:43 <nkinder> Unfortunately, we don't pass that info right now.
18:30:02 <ayoung> nkinder, auth plugins are mistnamed
18:30:10 <ayoung> this on the server, you mean?
18:30:22 <ayoung> on the server, auth plugins should be authentication only
18:30:23 <nkinder> I would like to pass the entire AuthInfo object (or a copy) to the auth plugins, but this requires changing the public method signature
18:30:46 <nkinder> forget horizon.  I'm talking about the keystone server
18:30:58 <bknudson> there's other ways to pass it in... for example could have a setter
18:31:03 <gyee> nkinder, so you want to entire payload
18:31:05 <ayoung> bknudson, nope
18:31:16 <ayoung> we need the token creation to be a pipeline
18:31:25 <ayoung> this is not a job for the auth plugins,
18:31:32 <ayoung> this is for the Token Provider
18:31:33 <bknudson> could provide a new method
18:31:49 <nkinder> ayoung: well, this is specific to token authentication
18:31:59 <morganfainberg> bknudson, ReallySecureTokenAuthNoWeMeanItThisTime?
18:32:10 <ayoung> nkinder, doesn't matter...the user is still authenticated, just not authorized for that new service
18:32:11 <nkinder> if I authenticate with an existing token, I want to disallow changing project scope
18:32:22 <bknudson> morganfainberg: authenticate2()
18:32:23 <ayoung> nkinder, that is fine, but it should not be auth plugin that does that
18:32:26 <ayoung> its in
18:32:35 <ayoung> the monolith
18:32:37 <morganfainberg> bknudson, ++ yeah or conditional with a decorator or something.
18:32:39 <gyee> I thought authentication and scoping are two separate deal
18:32:49 <bknudson> why can't we change project scope?
18:32:50 <gyee> scoping is controlled by policies
18:33:04 <nkinder> ayoung: ok, so we would need a whole new method that an authn/authz plugin would have to deal with.
18:33:05 <dstanek> does the plugin have access to the request object?
18:33:05 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/common.py#n414
18:33:07 <bknudson> if I request a token with no scope and the user has a default project then it'll be scoped to the project
18:33:13 <nkinder> ok, let me step back to talk about scoping
18:33:18 <morganfainberg> bknudson, isn't that a v2.0 ism?
18:33:21 <dstanek> this seems like that that belongs on the request itself
18:33:22 <bknudson> so I'd have to get an unscoped token
18:33:25 <ayoung> nkinder, I don't think so....I think that we need logic in that provider...
18:33:32 <ayoung> but we need to make the token pipeline easier to work with
18:33:39 <nkinder> The idea is that an unscoped token is like a TGT in Kerberos
18:33:43 <ayoung> right now the logic for v3 is like this:
18:33:47 <nkinder> It can be used to fetch scoped tokens
18:33:56 <nkinder> ayoung: wait and let me explain the motivation first
18:34:05 <ayoung> aut.controller->pluging->token.provider
18:34:14 <nkinder> a scoped token should only be allowed to be used for the project it is scoped to
18:34:36 <nkinder> Currently, you can take a scoped token and authenticate with it to get a new token for another project (or even a new unscoped token)
18:35:14 <ayoung> nkinder, oh, I agree with you that it is broken as is
18:35:16 <bknudson> morganfainberg: not sure what you mean about v2.0ism -- v3 has default_project and v2 has tenantId (or tenant_id??)
18:35:16 <nkinder> This means that a scoped token has no security properties, as a service that obtains the token can be used to get another token to perform other operations.
18:35:22 <ayoung> and Horizon is what has caused that brokenness
18:35:29 <morganfainberg> jamielennox, how much breakage would that cause in the session object(s)? ^ or how hard would that be?
18:35:39 <gyee> nkinder, you can rescope if you don't have roles on that project
18:35:42 <gyee> you can't
18:35:47 <nkinder> I would like scoped tokens to be used to allow a user to create a restricted token
18:35:47 <ayoung> nkinder, an unscoped token should not be used to do anything but talk to keystone
18:35:59 <morganfainberg> ayoung, ++
18:36:05 <ayoung> horizon should hold on to an unscoped token and use it to get scoped tokens for the current project
18:36:16 <ayoung> asking them to hold on to two tokens per user should not be too dire
18:36:21 <nkinder> gyee: I know, but what if you are an admin on one project and have low level rights on another project?
18:36:24 <jamielennox> morganfainberg: i've always known i need a way to handle rescoping auth plugins, i just haven't got to the point where someone asked for it - beyond that idon't see why it would cause many problems
18:36:41 <ayoung> then when a user changes project, they revoke the scoped token and used the unscoped to get a new scoped token
18:36:45 <gyee> ayoung, that's essentially how horizon operates today, trade in an unscoped token for a scoped token
18:36:52 <nkinder> gyee: in that case, your "low-level" token can be intercepted and reused during it's validity period to get your admin privileges on the other project.
18:36:53 <jamielennox> morganfainberg: although an unscoped token doesn't have any catalog - i would like to change that so an unscoped token at least contains a catalog with keystone it in
18:37:07 <ayoung> and the code to enforce that you can only go from unscoped->scoped would be enforced in the token provider
18:37:09 <morganfainberg> jamielennox, nod.
18:37:15 <ayoung> jamielennox, ++
18:37:39 <nkinder> gyee: I created a writeup with my proposal...
18:37:42 <morganfainberg> jamielennox, not unreasonable. actually i think that works well into the id-only stuff down the line
18:37:42 <nkinder> #link https://blog-nkinder.rhcloud.com/?p=101
18:37:43 <ayoung> jamielennox, gyee that is not how Horizon operates
18:38:07 <ayoung> its how horizon should operate, but they instead keep one, scoped token around, and expect to be able to transfer that to another scoped token
18:38:08 <jamielennox> ayoung: ?
18:38:19 <morganfainberg> horizon also does explicit token revocations now.
18:38:29 <morganfainberg> ayoung, i think we have to work with them in either case on this front
18:38:33 <ayoung> morganfainberg, I know.  I broke that at one point, too
18:38:39 <gyee> nkinder, ahh, escalated privilege
18:38:42 <jamielennox> right, this will cause problems for horizon and mean that we need to remove the concept of default_project_id - these are things i'm in favour of but it's a tough transition
18:38:42 <ayoung> and I think we should break that rule to work like this:
18:38:51 <nkinder> gyee: yes
18:38:57 <ayoung> 1.  Unscoped tokens are for Horizon.  An unscoped has an origin
18:39:09 <morganfainberg> jamielennox, default_project_id has been painful over many releases
18:39:13 <ayoung> an unscoped token must come fromthat origin and will time out in 10 minutes
18:39:22 <ayoung> basically, make unscoped tokens a session
18:39:29 <ayoung> so, sliding windo
18:39:31 <ayoung> w
18:39:32 <morganfainberg> ayoung, with a refresh timer perhaps?
18:39:47 <ayoung> if they refresh unscoped within 10 minutes, they get a new unscoped
18:39:55 <ayoung> lets call them session tokens
18:40:06 <gyee> nkinder, in that case, any rescoping is bad then?
18:40:22 <nkinder> gyee: yes, which is the patch I was working on
18:40:24 <ayoung> gyee, session token to scoped token
18:40:30 <morganfainberg> gyee, it's less secure overall.
18:40:31 <nkinder> gyee: unscoped->scoped should be allowed
18:40:32 <ayoung> only thing that should be allowed
18:40:41 <nkinder> gyee: projA -> projB should not be allowed
18:40:50 <ayoung> nkinder, and only from the same origin as the unscoped was requested from
18:41:01 <gyee> but unscoped->scoped would have the same effect right?
18:41:16 <morganfainberg> ayoung, or would you accept a unscoped token w/ say x509 binding vs strict origin?
18:41:17 <nkinder> gyee: unscoped is a privileged token.
18:41:22 <ayoung> ideally, unscoped session tokens would be bound to a Kerberos principal or an x509
18:41:24 <jamielennox> nkinder: i like that, it's how i thought unscoped tokens worked originally and then i found the default_project mess
18:41:48 <jamielennox> it gives an actual purpose to unscoped tokens
18:41:51 <ayoung> morganfainberg, if Horizon used an X509 to talk to Keystone, that would be what the token gets bound to
18:42:00 <gyee> nkinder, what I mean is if I intercept an unscoped token, its go-time too right?
18:42:03 <morganfainberg> ayoung, i was thinking of unscoped from non-horizon clients
18:42:05 <nkinder> gyee: you hang onto it and use it to fetch scoped tokens as needed.  You only use the unscoped token to talk to Keystone and get scoped tokens.
18:42:13 <nkinder> gyee: yes, which is why you only ever send it to keystone
18:42:15 <ayoung> morganfainberg, bind to an X509 or Kerberos principal
18:42:28 <nkinder> gyee: over SSL/TLS...
18:42:29 <morganfainberg> ayoung, ++
18:42:38 <dstanek> nkinder: ayoung: what do you mean by origin?
18:42:45 <gyee> helll yeah, I am all for x.509
18:42:59 <ayoung> dstanek I want to guard against stolen tokens
18:43:03 <ayoung> so I would say:
18:43:20 <ayoung> if Kerberos or X509 is in use, then "origin" means "same authentication doc"
18:43:33 <ayoung> dstanek, but if not...look at the requestor IP Address?
18:43:50 <ayoung> I don;t know if there really is a way to limit the damage done there, but we should at least try
18:44:02 <dstanek> ayoung: so horizon (and other services) would be passing that through to keystone?
18:44:05 <morganfainberg> dstanek, ayoung   or something like csrf from the horizon
18:44:16 <ayoung> dstanek, yeah
18:44:19 <morganfainberg> dstanek, just some kind of binding to try and ensure authenticity of the requestor
18:44:22 <ayoung> dstanek, wait...no
18:44:32 <ayoung> dstanek, I mean that Horizon requests the token
18:44:39 <ayoung> Horizon would not pass it through.
18:44:57 <dstanek> ayoung: and then only horizon can use the token?
18:44:58 <ayoung> So If I get an unscoped from Horizon, only Horizon can use it to get a scoped from Keystone
18:45:04 <ayoung> ++
18:45:19 <morganfainberg> nkinder, how close are we aiming to re-implementing kerberos ? [not a bad thing]
18:45:21 <dstanek> does that only apply for unscoped?
18:45:40 <gyee> re-implementing kerberos?
18:45:59 <morganfainberg> gyee, token-granting-tokens, etc.
18:46:08 <nkinder> morganfainberg: it's similar conceptually
18:46:14 <ayoung> morganfainberg, this is not Kerberos
18:46:21 <nkinder> morganfainberg: it's still quite different though
18:46:24 <ayoung> Kerberos is authentication.  THis is authorization
18:46:40 <henrynash> i’d say just making unscoped tokens shortlived plus only allowing unscoped->scoped (and not scoped->scoped) would in itslef me a major step fowrard
18:46:49 <gyee> so we have kite, and this thing?
18:46:57 <gyee> both based on Kerberos?
18:46:58 <ayoung> henrynash, ++
18:47:08 <morganfainberg> nkinder, ok making sure we weren't just going too far down a path of reimplementing
18:47:35 <morganfainberg> nkinder, figured we were fairly diverged still
18:47:40 <morganfainberg> ayoung, ++
18:47:52 <bknudson> do we have a way to force an unscoped token even if user has a defualt project?
18:47:56 <nkinder> morganfainberg: yeah, it's very different in other areas (revocation abilities, etc.)
18:47:59 <ayoung> morganfainberg, now....SAML is a different question
18:48:03 <nkinder> bknudson: it didn't look like it to me
18:48:03 <henrynash> bknudson: no
18:48:10 <gyee> bknudson, I am afraid not
18:48:15 <bknudson> seems like we'd just scope: {}
18:48:18 <nkinder> bknudson: I had to unset the default project to get an unscoped token
18:48:20 <ayoung> bknudson, yeah, we could return both?
18:48:29 <jamielennox> so what is the advantage of shortening unscoped tokens? currently you can't get a token with a longer lifetime than the one that was used to authenticate it
18:48:37 <henrynash> bknudson: once you specify the defaul_project in the user entity, no unscoped tokens from then pb
18:48:40 <ayoung> jamielennox, we need to change that
18:48:45 <henrynash> (then on)
18:48:46 <nkinder> jamielennox: ayoung wants that for the horizon session case really
18:48:51 <ayoung> we need to let a session be a session and have a sliding windo
18:48:52 <ayoung> w
18:48:58 <nkinder> jamielennox: time out an inactive user
18:49:00 <morganfainberg> we would actually need unscoped tokens to live longer than scoped
18:49:02 <ayoung> 10 minutes
18:49:08 <ayoung> morganfainberg, nope
18:49:21 <ayoung> we need them to live a very short time, but be renewable
18:49:31 <bknudson> do we revoke unscoped tokens when the password changes?
18:49:58 <henrynash> bknudson: I’d hope so….
18:50:01 <nkinder> bknudson: hopefully you're not using passwords in the first place... :)
18:50:14 <morganfainberg> ayoung, so scoped tokens would no longer be revoked if the parent unscoped token was?
18:50:22 <ayoung> bknudson, I'd say so, yes
18:50:28 <dstanek> ayoung: for long running operations would the calling service have to renew the token?
18:50:33 <bknudson> I guess it only applies to sql users anyways, so really doesn't work anyways
18:50:34 <morganfainberg> ayoung, or just the validity of the scoped token would extend beyond the unscoped (depending on config)
18:50:36 <morganfainberg> ?
18:50:38 <ayoung> morganfainberg, correct: but we should support the opposite
18:50:43 <morganfainberg> ayoung, right. ok
18:50:48 <nkinder> I think the short lived unscoped token idea is really a second step
18:50:50 <ayoung> revoke unscoped->revoke all scoped...
18:51:03 <morganfainberg> ayoung, truely a session token
18:51:10 <jamielennox> nkinder: ++, i'm not sold on that yet
18:51:20 <nkinder> The first step would be to just lock down the unscoped->scoped idea
18:51:30 <morganfainberg> nkinder, i'd probably make it configurable: default is the same TTL as normal tokens
18:51:43 <nkinder> With the current code, the scoped token inherits the expiration time from the scoped token
18:52:03 <henrynash> nkinder: ..from the unscoped one
18:52:15 <morganfainberg> henrynash, from any token, expiry is the same
18:52:29 <nkinder> henrynash: whoops, correct (though you currently CAN go scoped->scoped)
18:52:29 <ayoung> nkinder, we need to solve these other issues too
18:52:29 <henrynash> morganfainberg: yep
18:52:29 <morganfainberg> as it's parent
18:52:40 <morganfainberg> we would need some other unique identifier to solve the unscoped inheritance then
18:52:41 <nkinder> ayoung: yes, but it's not a pre-requisite
18:52:43 <ayoung> I don't think we want to do this in two jumps
18:52:48 <ayoung> nkinder, it kindof it
18:52:49 <ayoung> is
18:53:10 <ayoung> nkinder, the whole "whoops we just loggged you out" thing in Horizon is going to be a problem
18:53:15 <dstanek> nkinder: is your blog post going to be turned into a spec?
18:53:25 <nkinder> dstanek: yes, I'm going to write one
18:53:28 <dstanek> i'm very curious to read about all of these cases
18:53:29 <ayoung> nkinder, we can implement in steps
18:53:40 <nkinder> ayoung: how is that different than now?
18:53:41 <ayoung> but lets figure out the whole design,
18:53:53 <ayoung> nkinder, we shortened the token length to an hour
18:53:58 <ayoung> beforer it was the whole day
18:53:59 <morganfainberg> ayoung, e.g. a spec proposed? :P
18:54:30 <morganfainberg> ayoung, i think we can solve the design in the spec.
18:54:35 <nkinder> ok, so my question was really about where the scope change should be implemented, as I was trying to put it in the token auth plugin
18:54:38 <ayoung> nkinder, we will have puppet resetting the default back to 24 hours or whatever
18:54:46 <ayoung> morganfainberg, ++
18:54:58 <nkinder> It sounds like I should look at the token provider and deal with it there if the 'token' method is listed
18:55:03 <ayoung> morganfainberg, just so long as this is understood in context
18:55:17 <ayoung> nkinder, No, we need to deal with it in Horizon first
18:55:29 <ayoung> I already had that "fix" yanked about 18 months ago
18:55:59 <nkinder> ayoung: Well, that brings the second part of this...  Should the behavior be configurable?
18:55:59 <morganfainberg> nkinder, i think the answer is yes it goes in the provider, but it blocks on getting horizon to solve some issues.
18:56:12 <ayoung> nkinder, Oh god, no
18:56:25 <nkinder> We can't lock this down until Horizon knows how to deal with it
18:56:28 <jamielennox> how much does horizon really have to do? it must already handle the case where it gets either an unscoped token or a scoped one on first auth
18:56:49 <ayoung> nkinder, would you want to ever be able to hand in a kerberos service ticket to get another service ticket?  Should that be configurable?
18:56:52 <ayoung> lets just fix it
18:56:59 <morganfainberg> jamielennox, minor changes really, but we couldn't make this hard and fast unless horizon had those changes.
18:57:05 <bknudson> I'd expect Horizon doesn't care if it gets a scoped token or unscoped, treats them as unscoped either way
18:57:08 <nkinder> I think Horizon would need to get the unscoped token and just use it to get a scoped token when you select a project
18:57:14 <ayoung> nkinder, yes
18:57:22 <ayoung> nkinder, and...funny you should mention that
18:57:29 <morganfainberg> dolphm, do we support the concept of keystone across different versions of other services?
18:57:34 <ayoung> if I might remind morganfainberg about his request for Kerberos help
18:57:36 <morganfainberg> dolphm, don't think that is a real OS requirement... but.
18:57:40 <nkinder> morganfainberg: that's one of my worries too
18:57:40 <jamielennox> morganfainberg, bknudson: right, so lets get something proposed and I don't think horizon will have the problems we thing
18:57:56 <ayoung> There is a pattern here:  Horizon work to talk to Keystone is something that is going to require some design
18:58:02 <nkinder> morganfainberg: ...which would be an argument for making it configurable (even though I'd prefer not to)
18:58:30 <morganfainberg> nkinder, i don't know how many people don't deploy lock-step
18:58:40 <morganfainberg> nkinder, i think this impacts orgs that track master much more though
18:58:47 <morganfainberg> nkinder, it probably needs to be configurable
18:58:48 <ayoung> nkinder, OK,  so I kind of agree, in that I want to break the token provider up into a pipeline
18:59:00 <morganfainberg> ~1min
18:59:01 <ayoung> and the "token  to token" portion could be swapped out then
18:59:24 <ayoung> nkinder, I'd like to have a separate paste pipeline where its like:
18:59:26 <nkinder> morganfainberg: that's the same conclusion I was arriving at.  Leave the default behavior as it is today, change horizon, then switch the default down the road
18:59:30 <morganfainberg> ok lets take this back to -keystone
18:59:42 <morganfainberg> thanks everyone!
18:59:46 <ayoung> auth_plugins  biz_rule1 2 3 4  sign_token _persist
18:59:47 <morganfainberg> #endmeeting