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