18:01:06 <heckj> #startmeeting keystone
18:01:07 <gyee> \o
18:01:08 <openstack> Meeting started Tue Mar  5 18:01:06 2013 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:11 <openstack> The meeting name has been set to 'keystone'
18:01:15 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:01:20 <heckj> my IRC client decided it needed to update
18:01:32 <henrynash> me too
18:01:38 <topol> Hello
18:01:42 <heckj> ola all!
18:01:52 <dwaite> is there more information on the havana summit?
18:01:54 <spzala> Hi all!
18:01:57 <dwaite> (checks wiki)
18:02:11 <heckj> #topic high priority issues?
18:02:12 <dwaite> and there we go
18:02:22 <ayoung> dwaite, I know I have a hotel room, a plane ticket, and a summit talk.  What else is there?
18:02:26 <heckj> Anything burning down?
18:03:13 <heckj> henrynash, dolphm - if either of you are going to be running for PTL, please nominate yourselves to the mailing list ASAP
18:03:14 <ayoung> 0 critical bugs
18:03:21 <heckj> Okay - next topic
18:03:25 <ayoung> heckj, they did
18:03:25 <heckj> #topic trusts
18:03:32 <heckj> humm, haven't seen it yet
18:03:36 <ayoung> or do you mean on #openstack as opposed to #openstack-dev?
18:03:54 <heckj> openstack-dev - I must have just missed it in the deluge
18:03:56 <dolphm> o/
18:04:10 <heckj> ayoung: trusts topic?
18:04:14 <ayoung> heckj, Ok
18:04:25 <ayoung> so of the dependency list on the agenda
18:04:34 <ayoung> the oslo migration has gone through
18:04:42 <ayoung> gyee has a change he wants to push for his patch
18:04:54 <gyee> I got denied by gerrit
18:04:54 <ayoung> I would prefer to merge his patch as is and do his change as an additional
18:05:02 <gyee> my contact info wasn't on the ICLA :)
18:05:09 <dolphm> lets approve gyee's patch as is and file a bug for his desired change
18:05:14 <ayoung> dolphm, +2
18:05:17 <topol> gyee, join the club!!!
18:05:22 <gyee> sounds good
18:05:45 <gyee> topol, I am deciding whether to put my Cayman or Bahamas address there
18:06:04 <topol> gyee, :-)
18:06:14 <ayoung> gyee, in the interim, if you want me to submit for you, post to github and I can pull the patch.  You will list as the author, I will list as the commiter
18:06:15 <dolphm> gyee: you dont trust the foundation?
18:06:57 <ayoung> heckj, so trusts just needs one official core more last I looked
18:07:04 <gyee> dolphm, I am trying to figure out what else the foundation is looking for besides my email address
18:07:28 <ayoung> https://review.openstack.org/#/c/20289/
18:07:31 <heckj> ayoung: gotcha
18:07:36 <topol> gyee, did you re-register for the ICLA.I had to to do that
18:07:43 <gyee> ayoung, I am mostly fine with trusts
18:07:49 <heckj> ayoung: will run through it after this meeting
18:07:49 <ayoung> topol, yeah but he tried to avoid putting in an address
18:07:54 <gyee> topol, I can't even cancel my ICLA
18:08:43 <heckj> next topic
18:08:46 <topol> gyee, I had to re-register my user name :-(  and then fill everything out. Even though I was showing up in the pulldown
18:09:07 <heckj> #topic folsom stable
18:09:24 <ayoung> heckj, OK, so background
18:09:41 <ayoung> jaypipes, has listed in an email a bunch of PKI token based issues
18:10:02 <ayoung> we are trying to get PKI tokens usable by backporting the reasonable set of changes to address those problems,
18:10:10 <heckj> makes sense
18:10:18 <heckj> I'm aware of some of these from Vish
18:10:18 <ayoung> the origianl rationale for PKI tokens was not security, but perf
18:10:33 <heckj> (nova's in memory caching setup)
18:10:37 <ayoung> so beyond the 24 hour issue
18:10:56 <ayoung> there are a couple on caching and hashing PKI tokens in auth_token middle ware
18:11:25 <ayoung> Just want to get agreement from the team here that they are viable candidates for backporting
18:11:51 <dolphm> ayoung: add us to backport reviews?
18:12:20 <ayoung> dolphm, will do.  These were just identified this morning, and I haven't completed yet, but will do
18:12:22 <dolphm> ayoung: deployments can always switch to keystoneclient auth token as well
18:12:34 <heckj> #link Backport potential for https://review.openstack.org/#/c/15116/
18:12:41 <heckj> #link Hashing PKI tokens in auth-token middleware https://review.openstack.org/#/c/15116/
18:12:46 <ayoung> https://review.openstack.org/#/c/23564/
18:12:48 <heckj> #link Backport for in memory caching https://review.openstack.org/#/c/23309/3
18:13:06 <ayoung> #link backport of auth_token hash pki key PKI tokens https://review.openstack.org/#/c/23564/
18:15:03 <heckj> ayoung: is the request to review, or is there specific discussion on this we should have now?
18:15:49 <ayoung> request is to review...just wanted to make sure that this didn't happen without consensus.
18:16:10 <heckj> #topic Havanna summit
18:16:25 <heckj> We have some known issues on the agenda page (link above)
18:16:54 <heckj> Anyone start an etherpad with related pieces?
18:17:32 <henrynash> +1 for the open standards for auth & authz
18:18:28 <heckj> Also - please submit topics at summit.openstack.org
18:18:40 <heckj> #link http://summit.openstack.org
18:18:53 <heckj> ^ this is where we'll be coordinating the topics for keystone officially
18:18:54 <uvirtbot> heckj: Error: "this" is not a valid command.
18:19:00 <dolphm> uvirtbot: ssh
18:19:00 <heckj> I hate uvirtbot
18:19:02 <gyee> heckj, I will be adding a couple more to the list
18:19:02 <uvirtbot> dolphm: Error: "ssh" is not a valid command.
18:19:13 <henrynash> heckj: do you know when/how we decide on which topics?
18:19:28 <dolphm> uvirtbot: be quiet
18:19:29 <uvirtbot> dolphm: Error: "be" is not a valid command.
18:20:06 <dwaite> uvirtbot: kill -9 uvirtbot
18:20:07 <uvirtbot> dwaite: Error: "kill" is not a valid command.
18:20:16 <heckj> henrynash: the process is that everyone submits as they like - a reviewer (me, in this case as PTL) goes through and reviews for content and asked for updates, and then finally pre-approves and/or selects sessions.
18:20:31 <heckj> The PTL also ends up doing some of the scheduling, within whatever blocks that ttx enables/lays out.
18:20:36 <henrynash> heck; sounds good
18:21:07 <heckj> The last two summits they've had us in these block/segments, but the downside of that is what we saw the ML lately re: Quantum and Nova - cross-polination becomes damned difficult
18:21:16 <heckj> I don
18:21:36 <heckj> I don't know that there's a scheduling oriented solution to that - nothing's been proposed anyway
18:23:18 <heckj> #topic open discussion
18:23:59 <henrynash> heckj: So on auth_token, we have this fix: https://review.openstack.org/#/c/23401/
18:24:18 <ayoung> henrynash, looks good, minor nit
18:24:40 <henrynash> heckj: in general I think most people are OK with it, except for wether we do the fallback approach (i.e. ttry v3, if it fails, try v2)
18:24:40 <heckj> #link review please: https://review.openstack.org/#/c/23401/
18:25:06 <gyee> https://bugs.launchpad.net/python-keystoneclient/+bug/1136476
18:25:08 <uvirtbot> Launchpad bug 1136476 in python-keystoneclient "keystone discover command not finding the keystone endpoint running on localhost" [High,Confirmed]
18:25:20 <gyee> is get version supposed to return a 300?
18:25:31 <gyee> in v2, the spec says 200 or 203
18:25:32 <henrynash> I'm going to add the fall back later today
18:25:32 <topol> uvirtbot reminds me of my 8 year old son.
18:25:33 <uvirtbot> topol: Error: "reminds" is not a valid command.
18:25:42 <heckj> henrynash: the fall-back sounds good
18:25:43 <gyee> for v3, spec says 300
18:26:11 <dolphm> henrynash: on hte fallback behavior, you only need to fall back once -- if v3 isn't available just permanently fall back to v2?
18:26:26 <henrynash> gyee, dolphm: do we do a get version, or just try the validate…what would it return if the url is "wrong"
18:26:47 <dolphm> gyee: the 300 response is sort of outside the API spec, but the base url should provide a 300
18:26:50 <ayoung> For folsom stable, I think we should mark V2 as stable.  For Grizzly, Dolph voiced it should be deprecated.  Any opinions?
18:26:55 <henrynash> dolphm: although we need to decide where we store that fact , since this is the client now
18:26:56 <dolphm> gyee: GET /v3/ should return a 2xx
18:27:06 <dolphm> gyee: as should GET /v2.0/
18:27:11 <gyee> dolphm, keystone is return 300 currently
18:27:32 <dolphm> gyee: correct, GET / should return a 300 with links to /v2.0/ and /v3/
18:27:38 <dolphm> gyee: i don't think we've included v3 there yet
18:29:03 <dolphm> henrynash: ideally, on __init__ it should call GET / and decide if it's going to use /v2.0/ or /v3/
18:29:45 <gyee> dolphm, so get / should return 300 but get /v2.0 should return 2xx
18:29:50 <ayoung> dolphm, on trust failures, bknudson1 suggests returning a 403 instead of a 401.  I was thinking that it was due to sending in the trust that they got denied, but and so it was a 401 (Unauthorized means that the user needs to log in)  as they ciould perform the action with different credentials, but I can see the argument for 403 (Forbidden)
18:29:51 <dolphm> gyee: yes
18:29:55 <henrynash> dolphm: Ok, we'll do that…unless that have set the default to v2
18:30:35 <bknudson1> 401 says "The response MUST include a    WWW-Authenticate header field (section 14.47) containing a challenge    applicable to the requested resource."
18:30:52 <bknudson1> so, does our response include a WWW-Authenticate header field when we return 401?
18:31:34 <ayoung> bknudson1,  good question.  I'd have to look at the mechanism, but since we do the equivalent of form based auth anyway, I don't know if it makes a diference
18:31:43 <ayoung> but, if not, that would be a bug
18:31:57 <dolphm> bknudson1: i believe the response returned to the end user by auth_token will contain a WWW-Authenticate, but keystone will not return one on a 401 (no reason why we don't)
18:32:00 <ayoung> the question is which is the right return code, and I think I've just convinced myself you are right
18:32:14 <dwaite> I have a good deal of experience with SAML and OAuth2, and have been looking to how I can best contribute
18:32:19 <dwaite> and the right context to get a discussion going
18:32:31 <dolphm> dwaite: awesome
18:32:45 <henrynash> dwaite: great…I think this is an important area
18:32:45 <ayoung> dwaite, I would say that we need a summit session on those
18:32:59 <ayoung> Web SSO in general
18:33:15 <ayoung> alternative auth methods.
18:33:35 <henrynash> ayoung: +1…happy to work with however wants to on a session on that
18:34:07 <dwaite> with OAuth2, the concept at its root is that you use a component called an Authorization Server (AS) to have a user authorize a client, which might or might not be named
18:34:27 <dwaite> that authorization is represented as a token, which is applied to HTTP requests
18:34:31 <dwaite> so, it seems the most compatible
18:35:03 <dwaite> I'm already looking at coming out for the Summit
18:35:09 <dwaite> as of 35 minutes ago :)
18:36:04 <dolphm> auth flows that require a browser / ui are typically shot down at the summit, but i think we should have room for them with pluggable auth -- it just can't be the primary auth method
18:36:06 <dwaite> assuming I can get that worked out relatively quickly, i'd be happy to participate/lead in a session on that
18:36:22 <ayoung> dolphm, +1 on that
18:36:33 <topol> dwaite: AWESOME
18:36:36 <dwaite> oauth 2 has a ton of methods to get a token, including username/password via a REST call.
18:36:58 <dolphm> dwaite: feel free to submit to http://summit.openstack.org/ once you know you're attending :)
18:37:03 <dwaite> ok!
18:37:22 <ayoung> that has been my primary issue with the WebSSO mechanisms in general,  they try to work around lmitiations with the browser as opposed to fixing the auth mechanisms like Kerberos and X509 that perform crypto-secure Auth
18:38:37 <dolphm> i'm personally hoping that we can use a future version of oauth -- there was some discussion on their list for a gui-free flow last i checked
18:39:02 <dwaite> ayoung: there have been several mechanisms that have tried to fix things at a more fundamental level. The problem is that they have then required support for the fixed versions. Web SSO is widespread because it doesn't require any new client software
18:39:32 <dwaite> someday, someone will create an approach that fixes things at a fundamental level with a fallback that works with today's infrastructure, and then that method IMHO will "win" :)
18:39:48 <ayoung> dwaite, understood.  But also understand that Mozilla and Chrome have their own processes, and things can get fixed there, which makes them work pretty much everywhere.
18:40:17 <ayoung> Most web SSO approaches that I have seen have been broken by design.
18:40:42 <ayoung> But I think we can use X509 as a basis without reworking the browser.
18:41:02 <dwaite> dolphm: there are several gui-free flows; you can exchange a SAML assertion for a token, or authenticate a user directly via username/password.
18:41:13 <ayoung> It will be ugly to start, and probably would require a browser plugin to make it smooth
18:42:02 <dwaite> ayoung: I don't think we have the room long enough for that discussion ;-)
18:42:43 <ayoung> dwaite, you need to look at  davidchadwick's implementation of Federation.  It has ties ins for the WebSSO mechanisms already. They demod last summit
18:42:56 <dwaite> ok
18:43:49 <dwaite> I am btw from Ping Identity ( read that there was some discussion of the call on openstack-dev)
18:45:00 <dolphm> dwaite: awesome, i *may* be going to that summit as well
18:45:28 <spzala> #link review request for https://review.openstack.org/#/c/22624/  (dolphm, henrynash, yuriy.. thanks for your initial review and comments)
18:46:38 <dwaite> I assume that David Chadwick's implementation is attached to the blueprint. I'll review
18:46:55 <henrynash> spzala: still some work to do there, but making progress
18:47:53 <spzala> henrynash: ah, :) OK. thanks.
18:48:49 <dolphm> spzala: will do
18:49:26 <spzala> dolphm: thanks!
18:49:33 <dolphm> spzala: also blurring the line between bug fix and feature add -- i'd like ttx's okay there as well
18:50:00 <bknudson1> ldap identity auth is broken right now, returns Not Implemented.
18:50:46 <spzala> dolphm:  :( sorry, didn't get it
18:52:45 <henrynash> bknudsom1: you mean the authenticate function in the ldap backend?
18:53:52 <bknudson1> henrynash: let me take a quick look again...
18:54:24 <henrynash> bknudson1: np
18:54:45 <gyee> dolphm, ayoung, https://review.openstack.org/#/c/23158/
18:54:47 <dolphm> dwaite: approved and registered for ping summit
18:54:51 <spzala> dolphm: will you be talking to ttx?
18:54:55 <gyee> should I cancel that one
18:55:17 <dolphm> spzala: yes, i'll ping him once it's ready to merge
18:55:20 <bknudson1> henrynash: the ldap backend doesn't implement list_groups_for_user, and that gets called during authenticate
18:55:57 <bknudson1> henrynash: I could look into this some more, would need to set up my devstack.
18:55:58 <henrynash> bknudson1: ah, right…and I think that is in spzala's patc
18:56:09 <spzala> dolphm: OK, great. Thanks!
18:56:11 <dwaite> dolphm; havana summit or ping's cloud identity summit?
18:56:19 <dolphm> dwaite: well, both
18:56:25 <dwaite> (I'll be speaking at CIS as well)
18:56:36 <dwaite> hah, fun!
18:56:43 <bknudson1> henrynash: my concern was mostly about the comment that spzala's changes were a bug fix or a new feature.
18:56:52 <ayoung> gyee, what was the change in 23158?
18:56:57 <heckj> going to have to wrap this in ~4 min
18:57:06 <ayoung> https://review.openstack.org/#/c/23158/6..7/keystone/auth/methods/token.py ?
18:57:10 <dwaite> dolphm: you have good taste in summits
18:57:11 <gyee> ayoung, just added the G3 token support
18:57:15 <spzala> bknudsonl: list_groups_for_user is implemented under the patch I have put up for review
18:57:18 <henrynash> bknudson1: it is tagged against a bug…but I think not being able to authenticate might trump that one
18:58:07 <dolphm> gyee: you killed the merge though lol
18:58:56 <ayoung> gyee, was it just that file and the token_facotry change?  That was all I saw?
18:59:56 <gyee> ayoung, that's it
19:00:02 <gyee> just two changes
19:00:48 <heckj> #endmeeting