18:00:29 <dolphm> #startmeeting keystone
18:00:30 <openstack> Meeting started Tue Mar 26 18:00:29 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:33 <openstack> The meeting name has been set to 'keystone'
18:00:52 <dolphm> ayoung: o/
18:00:55 <joesavak> o/
18:01:14 <dolphm> #topic Anything on fire?
18:01:37 <dolphm> (silence is appreciated here)
18:01:47 <topol> :-)
18:01:57 <henrynash> dolphm: so am debugging why the current master fails to run the test_sql_upgrade scripts on MySQL and PostGres
18:02:14 <dolphm> henrynash: master without my patch, you mean?
18:02:21 <henrynash> dolphm: yes!
18:02:33 <dolphm> henrynash: does db_sync fail?
18:03:00 <ayoung> I'm here!
18:03:09 <henrynash> dolphm: seems to be when you downgrade to zero…problem with tenant membership table
18:03:22 <henrynash> ok with sqlite, of course
18:03:25 <dwaite> ayoung: o/
18:03:31 <dolphm> henrynash: have you seen christopher yeoh's comments on a similar issue in postgresql?
18:03:38 <henrynash> dolphm: yes
18:03:43 <dolphm> 0->22->0 fails on postgres
18:03:50 <dolphm> but only in test_sql_migrations
18:03:52 <henrynash> dolphm: yea I found that too
18:04:02 <henrynash> dophm: that matches what I have found….
18:04:09 <dolphm> henrynash: in db_sync or test_sql_upgrade?
18:04:20 <henrynash> dolphm: test_sql_upgrade
18:04:48 <dolphm> i'm inclined to say it's an issue with the test infrastructure, not an issue with the migrations
18:04:50 <henrynash> dolphm: so I think its probably our bad test code….but want to make sure
18:04:59 <henrynash> dolphm: I tend to agree
18:05:11 <dolphm> i.e. test_sql_upgrade and test_sql_migrations aren't properly mimicking the process of db_sync
18:05:11 <henrynash> dolphm: will try to get to the bottom of it
18:05:54 <dolphm> henrynash: thanks; if you find that it's an issue with db_sync, we need to raise a bug / backport fix ASAP
18:06:00 <henrynash> dolphm: yep
18:06:15 <henrynash> dolphm: I also just raised this bug https://bugs.launchpad.net/keystone/+bug/1160504
18:06:16 <uvirtbot> Launchpad bug 1160504 in keystone "Grizzly v2 catalog has slight formatting changes compared to Folsom" [Undecided,New]
18:06:58 <dolphm> oh wow, that's breaking
18:07:16 <dolphm> err, hmm
18:07:21 <dolphm> i reviewed this, hold on
18:07:30 <dolphm> this was a mismatch between spec and reality
18:09:33 <dolphm> targeted that at rc2 for review, at minimum, i can't find the relevant patch atm
18:09:42 <henrynash> dolphm: ok
18:09:43 <dolphm> it was a tested change to the xml serializer though
18:09:53 <dolphm> #topic Grizzly release candidate status (RC2)
18:09:58 <dolphm> #link https://launchpad.net/keystone/+milestone/grizzly-rc2
18:10:05 <henrynash> dolphm: yea , remember it…and we added some special code doe links etc.
18:10:42 <topol> dolphm, what is the target date for RC2?
18:10:53 <dolphm> topol: always ASAP
18:10:55 <dolphm> anyone aware of any other issues or patches that need to be backported, or considered for backporting to grizzly?
18:11:19 <topol> dolphm, I am working on TLS Support for LDAP. Should be done soon
18:11:36 <dolphm> topol: features especially can't be backported
18:11:54 <dolphm> we'
18:11:59 <dolphm> we're open for havana though :)
18:14:07 <gyee> dolphm, found an inconsistency with credential
18:14:13 <dolphm> gyee: link?
18:14:20 <gyee> in the spec we have "data", but in impl we have "blob"
18:14:28 <gyee> I haven't file a bug yet
18:14:56 <dolphm> gyee: unless we have a strong preference for 'data', i think we should fix the spec at this point
18:15:08 <gyee> dolphm, no argument here
18:16:39 <dolphm> gyee: ping me when you have a review up
18:17:13 <dolphm> if we only have one issue left (that may not need a fix?), we might be able to cut rc2 today
18:17:22 <dolphm> that was my goal before henrynash's issue at least :)
18:17:27 <dolphm> #topic Review, revise & amend Keystone's release notes
18:17:35 <dolphm> #link https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Identity_.28Keystone.29
18:17:48 <dolphm> i got our release notes started last week, and have noticed a few contributions since
18:18:20 <dolphm> i'd encourage everyone to make sure all the features and potential upgrade issues you're familiar with are included, and doc them if not -- even if it's just a stub so someone else can go fill it in later
18:18:21 <gyee> dolphm, will oauth be part of rc2, or havana?
18:18:28 <dolphm> gyee: havana
18:18:31 <gyee> cool
18:18:54 <topol> dolphm, do we have a blueprint for oauth?
18:19:06 <ayoung> dolphm, TLS will probably be nominated for backport to Grizzly stable
18:19:24 <dolphm> termie opened one today https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth
18:19:26 <topol> dolphm, because adding oauth can me a couple of things
18:19:40 <topol> dolphm, OK
18:19:43 <gyee> yeah, LDAP + TLS is recommended
18:19:44 <dolphm> topol: have you seen termie's impl?
18:19:52 <dolphm> i don't believe it's in review, but it's on his github
18:19:59 <gyee> doing LDAP auth without TLS/SSL is like driving without seatbelt :)
18:20:03 <ayoung> dolphm, it was cursory last I looked
18:20:05 <topol> dolphm, I have steve martinelli digesting as we speak
18:20:10 <ayoung> let me see if he has updated
18:20:26 <dolphm> i think that's why he didn't put it in review
18:20:41 <dolphm> termie: feel free to post it to gerrit as WIP ;)
18:20:55 <ayoung> +1
18:21:09 <ayoung> dolphm, also,  is it possible to comment on the gist?
18:21:09 <gyee> +1.0
18:21:33 <ayoung> #link https://gist.github.com/termie/5225817#file-delegated_auth
18:21:34 <dolphm> ayoung: yes, you can comment on gists at the bottom of the page
18:22:36 <dolphm> #topic oauth support
18:22:41 <dolphm> because why not
18:23:36 <dolphm> topol: is steve looking through the spec, impl, or both?
18:23:45 <stevemar> dolphm: both
18:24:27 <dolphm> stevemar: thanks
18:24:41 <ayoung> The more I learn about oauth, the more I think it is the right approach. Trusts is really a limited subset of the functionality, but it maps pretty clearly to oauth.  The major benefit is that oauth provides a way that the remote service can specify what roles are requred
18:25:15 <dolphm> yeah, i think oauth is a great long term solution
18:25:22 <stevemar> ayoung: does that mean we will get rid of trusts? I think termie submitted something for that already
18:25:23 <ayoung> Also, I think I was a bit put off by the bad reputation that oauth2 has, but didn't realize just how supported the version 1 protocol was.
18:25:27 <dolphm> i'm just not familiar enough with it myself -- yet
18:25:30 <ayoung> stevemar, no
18:25:38 <ayoung> stevemar, more likely we will merge
18:26:04 <gyee> dolphm, https://review.openstack.org/25421
18:26:06 <ayoung> stevemar, as I see it, anything set up with trusts can be served by oauth
18:26:07 <dolphm> stevemar: care to share your initial impressions?
18:26:13 <ayoung> so it is a superset of functioanlityy
18:26:19 <stevemar> ayoung: yeah, from what I read - the community was split when v2 came out, v1 is well supported though
18:26:22 <ayoung> long term, yeah, proably won'tbe much call for trusts
18:26:49 <ayoung> but we need a way to prime the pump for delegation, and trusts will allow people to do that for Grizzly
18:26:54 <stevemar> dolphm: still have to digest a lot of things, it's all coming in quickly now
18:26:59 <topol> dolphm, so two ways to look at oauth. Using it between openstack components and using it to bridge the outside world to openstack world
18:27:40 <ayoung> oauth should be in Havana, with a migration for established trusts, and the trust API will still work against the unified table
18:28:15 <topol> stevemar  will gather use cases to make this more clear
18:28:15 <ayoung> topol, it looks like using it between OS components is a pretty straightforward simplificaition of the overall protocol
18:28:42 <topol> ayoung, assuming the other components buy in I agree!
18:28:52 <ayoung> and one thing you could do if you didn't want to support the bridge would be to enforce that all consumers are entires in the user tables
18:29:07 <dolphm> partly related summit session...
18:29:09 <dolphm> #link http://summit.openstack.org/cfp/details/111
18:29:10 <topol> stevemar will gather info on the bridge to the world use case
18:29:16 <dolphm> dwaite: ^
18:29:34 <stevemar> dolphm: i was *just* going to link that, but was afraid it would cause confusion :)
18:29:35 <dwaite> not sure the community which was split on v2
18:30:00 <ayoung> dwaite, oh yes it was
18:30:02 <dwaite> one person involved in creating v2 rage-quit the project :)
18:30:11 <ayoung> dwaite, he wasn;t the only one.
18:30:16 <dolphm> dwaite: how much time do you intend to spend on oauth?
18:30:18 <ayoung> Just the most visible
18:30:22 <dolphm> percentage wise
18:30:44 <dwaite> I was thinking 10 minutes on oauth itself
18:31:33 <dwaite> 10 on saml, 2.5 on SCIM and JWT, saving 15 for talk
18:32:44 <dolphm> i suspect that the introduction of oauth might be the biggest change on the table for havana; if that's the case, i'd like to make sure we have a significant chunk of time dedicated to it at the summit
18:32:53 <dwaite> more seriously wrt oauth 1 and 2, there are three usual points of contention on the protocol. One is that the tokens alone are used for authorization of the API, without any other user/client proof tokens. There are some efforts to add MAC profiles back to the spec for this
18:32:53 <henrynash> dolphm:…and you may have seen I put in a second session for us to then talk about how we implment
18:33:12 <dwaite> but the tokens in use today in openstack are the same; just a token, put in a header.
18:33:17 <dolphm> henrynash: link?
18:34:39 <dolphm> dwaite: ideally we don't have to change the X-Auth-Token infrastructure, as doing so would be an expensive and slow process
18:35:03 <dwaite> second is that there is a push to have clients identified in general (limiting API access to clients who have registered and been approved and possibly agreed to terms of service). Its anti-hacker, while a fair number of people consider APIs to be complete fair game
18:35:24 <henrynash> http://summit.openstack.org/cfp/edit/157
18:35:31 <dwaite> dolphm: I suspect that the first step would be to support the header style of OAuth (Authorization: Bearer <token>) in tandem
18:35:34 <dolphm> #link http://summit.openstack.org/cfp/details/157
18:35:38 <dwaite> and phase that out slowly
18:35:47 <dolphm> henrynash: swap /edit/ for /details/
18:36:21 <ayoung> So might I address that last point?
18:36:25 <dwaite> the third issue I see people have with OAuth is that there are so many different options for acquiring a token. There are web flows, username password flows, flows where users aren't involved and its just service to service, etc.
18:36:53 <ayoung> As I see it, for getting beyond bearer tokens, there are three approaches worth addressing
18:36:53 <dolphm> ayoung: absolutely; this wasn't anyone's specific time slot on the agenda
18:36:59 <dwaite> this is probably the main reason people say oauth 2 is a framework, and not a protocol - because there is no MTI here, its just based on what you want to support
18:37:16 <ayoung> 1.  add a public key to the tokens, and sign the request.  Lets call that "roll your own PKI"
18:37:24 <dwaite> I would propose we support username/password to start, which is closest to what keystone does today, and move forth from there.
18:37:42 <ayoung> 2.  Kerberos, and extend the authorization data with the information we have in the token today
18:37:48 <ayoung> 3.  X509
18:38:09 <ayoung> The benefit of X509 is that we can then use the same infrastructure for all of the security related pieces
18:38:16 <ayoung> but it is not too clean
18:38:32 <ayoung> there is no standard way to do authorization data, short term certificates, etc
18:38:41 <ayoung> not unsurmountable problems, but worth mentioning
18:38:52 <ayoung> Kerberos has a few short comings as well
18:38:56 <dwaite> SAML is closest to that IMHO (short term certificates)
18:39:11 <ayoung> dwaite, but you can't use SAML to set up SSL connections
18:39:16 <dwaite> nope
18:39:21 <ayoung> so it woudl be "in conjunction with"
18:39:50 <ayoung> kerberos you can't use the service tickets to set up SSL either
18:39:57 <ayoung> and you need to fetch thme over port 88
18:40:14 <ayoung> and there is no firm standard about what should be in the authorization data
18:40:22 <ayoung> Also, a negotiate call requires 2 round trips
18:40:42 * ayoung will explain negotiate later to any that really care
18:40:45 <dwaite> kerberos becomes a real pain when you start to cross domain boundaries. thats the driver behind Microsoft supporting federation protocols like SAML
18:41:06 <ayoung> so typically you end up doing something like Kerbers for initial auth and then a cookie
18:41:15 <ayoung> since that cookie can also be our tokens
18:41:27 <dwaite> bearer tokens are hard to get away from :)
18:41:34 <ayoung> Ithink that the first thing to do is to add a credential to the currrent bearer tokens, or option 1
18:41:52 <ayoung> we can make the signing optional to start
18:42:06 <dolphm> ( aside- we should create a design.openstack.org based on stackexchange to allow voting on competing design solution to problem statements :) )
18:42:11 <ayoung> and we'll have to clarify how the user will specify which credential to use
18:42:39 <ayoung> as well as make sure we do the request signing in an intellegent manner for people that want to use them
18:42:50 <ayoung> over time, we make signing go from optional to expected and required
18:43:09 <ayoung> we can only do that if we have a delegation mechanism, hence the push for trusts
18:43:22 <ayoung> if oauth replaces trusts, no big deal, we still have the mechanism we need
18:44:04 <ayoung> dwaite, there are a few things about Kerberos that make it worth addressing, though
18:44:19 <dwaite> def.
18:44:26 <ayoung> probably the most important is that it is an enterprise must
18:44:38 <ayoung> so good interop is required
18:45:02 <ayoung> to what degree that gets integrated into the rest of the stack can remain to be seen
18:45:44 <dwaite> kerberos in keystone is a must. kerberos in each other service, I could probably argue well against
18:46:01 <ayoung> for example, you could put the auth data into the service ticket, and have the web server that nova runs in use negotiate and an analogy to auth_token
18:46:17 <ayoung> dwaite, there is also some question about securing AMQP
18:46:33 <ayoung> Kerberos there might actually make more sense than at the HTTPS level
18:47:35 <ayoung> We also might want to look at "worst case scenarios"
18:47:57 <ayoung> the most likely target for an attack seems to be nova-compute, since it is running the virtual machines, ie random code from out there
18:48:21 <ayoung> if a hypervisor exploit is found, we want to make sure that they don't end up with admin privs in keystone
18:48:46 <dwaite> so it would make sense to recommend nova and keystone be physically isolated, and for nova to not have delegation privileges
18:49:02 <dwaite> also, to make sure that raw credentials are not sent to nova, so that they would never be able to be captured
18:49:13 <ayoung> dwaite, nova-computet
18:49:24 <ayoung> nova needs it but not the hypervisor, I think
18:49:31 <ayoung> however, that might not meet current arch
18:49:58 <ayoung> for example, an application running in a VM might need to be able to talk to swift
18:50:07 <ayoung> that needs to be very limited scope.
18:51:06 <dwaite> yeah, I suppose constraining the delegation is more appropriate
18:51:15 <dolphm> i'm going to cut ya'll off so we have a bit of time for summit sessions & open discussion
18:51:34 <dwaite> kk
18:51:45 <ayoung> also, when you deploy a VM to a compute node, I assum that the image gets "pushed" from nova-api, but if it actually gets pulled out of glance, the compute node would need a token, and that would be a potential attack
18:51:46 <dolphm> would love to continue in -dev after :)
18:51:47 <ayoung> sure
18:51:48 <dolphm> #topic Design summit sessions
18:52:24 <dolphm> would love for people to become familiar with what's been proposed for the summit
18:52:25 <dolphm> #link http://summit.openstack.org/cfp/topic/9
18:52:40 <bknudson> dolphm: Forbidden
18:52:45 <dolphm> hrm
18:52:52 <dolphm> http://summit.openstack.org/
18:52:57 <dolphm> and then click keystone
18:53:00 <topol> I am verbotten as well
18:53:04 <dolphm> you might have to login through launchpad?
18:53:55 <bknudson> http://summit.openstack.org/cfp/details/9
18:53:58 <ayoung> yeah, log in
18:54:30 <dolphm> if anyone has new sessions to propose -- do so as soon as possible! so far i've avoided approving/denying anything as new ones are still being proposed, but it looks like at least a few will have to be merged or denied, due to time constraints if nothing else
18:54:34 <ayoung> here are the unreviewed topics
18:55:07 <ayoung> Scaling/Performance of Keystone for the Enterprise,   	Supporting KMIP in Key Manager,   	Keystone LDAP Integration for Enterprises ,   	Domain specific backends,  Generic support for external authn/authz,
18:55:16 <ayoung> SAML, OAuth 2, and SCIM - Overview and Application,   	Availability zone and region management
18:55:44 <ayoung> Fine-grained access control,   	Endpoint Filtering,   	Service Metadata/Capabilities,  	Centralized Quotas,
18:55:50 <ayoung> and an incomplete for  	Use DNS for initial endpoint information
18:57:07 <stevemar> ayoung: dolphm: should termie also have a proposal?
18:57:07 <ayoung> dolphm, I assume we have time for one days worth of topics?
18:57:11 <topol> we gonna review all these in 4 mins?
18:57:19 <stevemar> in case it is not the same as dwaite's OAuth
18:57:24 <ayoung> topol, we need to consolidate
18:57:43 <ayoung> dolphm, we have a day, right?
18:57:45 <dolphm> ayoung: roughly
18:57:53 <dolphm> topol: no
18:57:53 <ayoung> Thursday, with 2 topics pre-approved
18:58:06 <dolphm> topol: just become familiar with them in your free time
18:58:08 <ayoung> Keymanager and KMIP should be one topic
18:58:15 <topol> OK
18:58:28 <dolphm> topol: i'd like to have some initial discussion around them in irc, mailing list, etc before we start rubber stamping stuff
18:58:37 <dolphm> i'd also like to remind everyone that sessions with a goal of concluding with a yes/no tend to go pretty quickly as there's not usually much to discuss (it always seems to be either a resounding yes or resounding no) -- the most productive sessions are the ones with contending design solutions presented or are intended for open discussion on a specific topic
18:58:42 <topol> dolphm, makes sense
18:58:43 <ayoung> Guang, can your two topics be combined?
18:58:59 <ayoung> Service Metadata/Capabilities  and  	Endpoint Filtering  seem like almoste....
18:59:03 <dolphm> lectures are also welcome if you're a super expert on something and are open to questions :)
18:59:43 <dolphm> but we should always walk away with an action item or two from every session
19:00:05 <ayoung> topol, does yours tend to tie in with  	Generic support for external authn/authz
19:00:11 <dolphm> hrm, we're out of time
19:00:18 <dolphm> switching to -dev!
19:00:20 <dolphm> #endmeeting