18:00:53 <dolphm_> #startmeeting keystone
18:00:53 <openstack> Meeting started Tue Jan 22 18:00:53 2013 UTC.  The chair is dolphm_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:56 <openstack> The meeting name has been set to 'keystone'
18:01:07 <dolphm_> #topic High priority bugs or immediate issues?
18:01:22 <ayoung> dolphm_, High priority
18:01:24 <dolphm_> we have several security fixes in the works -- if you have visibility, please review the proposed patches
18:01:25 <ayoung> no V3 API for tokens
18:01:27 <gyee> I need a decision on the auth plugin
18:02:00 <dolphm_> gyee: do you have code to put up for review?
18:02:07 <gyee> not yeah
18:02:21 <dolphm_> gyee: i think that's going to be the fastest route to solicit solid feedback
18:02:27 <gyee> I can finish off the tokens work and leave the auth plugin later
18:02:28 <ayoung> +1
18:02:34 <henrynash> +1
18:02:42 <gyee> alrighty then
18:02:45 <dolphm_> gyee: sure
18:02:45 <ayoung> gyee, +2 Frost damage!
18:02:56 <dolphm_> lol
18:03:05 <dolphm_> any other high priority things?
18:03:37 <dolphm_> #action gyee to put v3 auth interface up for review, without pluggability
18:04:47 <dolphm_> #action core to review proposed security patches
18:04:55 <dolphm_> (^^keep commentary within the bugs for now, please^^)
18:05:13 <dolphm_> i'll take silence as a no...
18:05:14 <dolphm_> #topic Default domain and v3 calls where domain_id is not specified
18:05:24 <henrynash> dolphm: will do
18:06:10 <dolphm_> #link http://lists.openstack.org/pipermail/openstack-dev/2013-January/004691.html
18:06:22 <henrynash> dolphm: So I made the suggestion to separate the discussion on creation of a default domain from the actions we take on v3 calls
18:07:06 <dolphm_> henrynash: worthy point
18:07:57 <gyee> we can only scope to one domain at a time so specifying a domain ID in create user is irrelevant right?
18:08:24 <gyee> unless it is the global ADMIN user
18:08:29 <henrynash> dolphm: since that re-orders/names the migration files….would be good to get that in asap….the I can layer my changes in
18:08:34 <dolphm_> gyee: yes, but if multi-tenant tokens merge, we'll also end up with multi-domain tokens
18:08:40 <dolphm_> gyee: however, i don't think it's going to happen
18:08:43 <dwchadwick> Why cannot the keystone admin create multiple users in multiple domains in a single session without needing to swap between domains
18:08:59 <dolphm_> henrynash: +1
18:09:07 <ayoung> dwchadwick, explicitly, then should be able to do so.  It is justin the implicit case it is  an issue
18:10:14 <henrynash> ayoung: I notice your suggestion on the loading of different easy of doing this….we could clearly do that…I just wander if it is worth it…since we are only talking about the case when a v3 caller decides NOT to specify a domin
18:10:14 <dwchadwick> If it is a multi-domain set up, then you can either mandate explicit domains or default to the domain the admin is currently associated with
18:10:56 <henrynash> (...different ways of doing this…)
18:11:11 <ayoung> henrynash, It still doesn't solve the hard question of what should the default behavior be.
18:11:21 <ayoung> henrynash, but it mitigates the cases where people disagree
18:11:28 <dwchadwick> Rather than having 10 ways of skinning a cat, why not have just one way
18:11:32 <dolphm_> i'd really rather not have if-then-elseif logic handling this in the core implementation
18:12:04 <dwchadwick> meaning that the domain must be specified in a multi-domain system
18:12:22 <gyee> dolphm_, I am OK with token scoped to multiple domains
18:12:28 <dwchadwick> Its explicit, its not confusing or ambiguous
18:12:38 <henrynash> dolphm: I kind of agree….if the operators don't like the default, then they can specify the domain anyway in the call..
18:12:45 <gyee> but not multiple projects as it has severe impacts right now
18:13:04 <dolphm_> i don't really want anything more complicated than, e.g.: create_user_request.setdefault('domain_id', token['domain']['id'])
18:15:18 <dolphm_> gyee: i don't want to accept multi-project tokens without multi-domain tokens -- they should be merged hand-in-hand (if they hand)
18:15:25 <dolphm_> lol (if the merge*)
18:16:22 <gyee> fair enough
18:16:23 <dolphm_> anyone opposed to my pseudo code above? it corresponds with what me and henrynash were "violently agreeing" on in the mailing list thread
18:16:52 * gyee is comfortably numb
18:17:02 <ayoung> ayoung is comfortably dumb
18:17:43 <topol> dolphm_ : dare I say it looked good to me!
18:17:45 <topol> 
18:17:48 <henrynash> ayoung: I think you were probably the most keen on giving the options….do you still think it is necessary
18:18:01 <ayoung> dolphm_, sounds about right...can we post to the larger community as a "here is what we are going to do.   I know you are all going to complain, but we are going to do it anyway, as we have determined all of the other options were more horrible."
18:18:18 <dolphm_> ayoung: i feel like that's what we just did on openstack-dev
18:18:20 <ayoung> henrynash, if we can agree on a reasonable default, the options can be an ace in the sleeve we keep for later
18:18:34 <henrynash> ayoung: +1
18:18:38 <ayoung> dolphm_, I had trouble following the discussion, I'm sure most people tuned it out
18:18:39 <dolphm_> ayoung: +1
18:19:20 <gyee> so A) then?
18:19:35 <dolphm_> #action utilize domain-scoped authorization to imply owning domain_id on create user & project requests
18:19:41 <dolphm_> moving on..?
18:19:54 * ayoung hears his cue
18:20:04 <dolphm_> #topic Tenant to Project, Roles versus Membership, and Trusts
18:20:32 <ayoung> OK./..
18:20:43 <ayoung> so, you might remember I was kindof keen on trusts for a while
18:20:52 <ayoung> and then it turns out trusts needs tokens to get a full test
18:20:55 <ayoung> and tokens need roles
18:21:03 <ayoung> and roles and membership are conflicting concepts
18:21:06 <ayoung> to be specific
18:21:20 <ayoung> member ship old and borkne
18:21:23 <dwchadwick> What is the membership concept
18:21:26 <ayoung> roles--new hotness
18:21:36 <ayoung> dwchadwick, tenants had members
18:21:36 <dolphm_> dwchadwick: a horrible legacy implementation detail we're trying to get rid of
18:21:55 <ayoung> dwchadwick, you can pretty much assume that explanation for most of the work we are doing, actually
18:22:08 <ayoung> so...metadata
18:22:22 <ayoung> another horrible choice of terms we need to expurgate
18:22:25 <dwchadwick> At what point in time do you delete code of deprecated features
18:22:40 <dolphm_> 'membership' is basically treated as an implied role assignment internally, we'd like to make it an explicit role grant that can be managed through the api
18:22:50 <dwchadwick> You cannot carry deprecated baggage for ever or you will end up like Windows
18:23:05 <dolphm_> it came as a result of importing legacy auth data from nova
18:23:05 <ayoung> dwchadwick, that is an important enough question that I don't want to give a glib answer now
18:23:15 <ayoung> can we table it for now?
18:23:27 <ayoung> the short is, we will deprecate
18:23:40 <dwchadwick> ok
18:23:48 <dolphm_> dwchadwick: this isn't so much a user-facing feature; but the answer is 2 release cycles
18:23:57 <ayoung> from an API perspective, we are going to implement user tenant membership via the role entity but keep the APIs...for now
18:24:03 <ayoung> this is a V23 thing primarily
18:24:14 <ayoung> V2 has this stuff,  3 not so much
18:24:45 <ayoung> As I go through the code, though I see parallels in domains and groups
18:24:50 <ayoung> and I want to make sure I have it straight
18:25:06 <ayoung> domains should have membership, as domains own the user records
18:25:39 <dolphm_> ayoung: no! user.domaid_id defines that ownership
18:25:43 <henrynash> ayoung: true to the last bit, but why do we need membership
18:26:01 <ayoung> dolphm_, ah...so I think I can cut out some more code
18:26:26 <dolphm_> ayoung: the more you delete the faster i'll +2
18:26:28 <ayoung> there should be no grants on domains then, right?
18:26:38 <dolphm_> ayoung: nono, that stays
18:26:41 <ayoung> domain relationships are fixed
18:26:44 <dolphm_> ayoung: thats in the v3 spec
18:26:53 <ayoung> what is a user/domain grant if it is not defined by a role?
18:27:01 <dolphm_> ayoung: it is
18:27:21 <henrynash> ayoung: grant role x to group Y on domain Z
18:27:39 <henrynash> ayoung: all three elements must be specified
18:27:42 <dwchadwick> this is getting to be a mess
18:27:47 <dolphm_> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#grant-role-to-user-on-domain-put-domainsdomain_idusersuser_idrolesrole_id
18:27:53 <ayoung> dwchadwick, agreed, that is why I am trying to remove...
18:28:12 <henrynash> ayoung: I don't follow at all…..
18:28:20 <dolphm_> ayoung: this should have zero api impact
18:28:25 <ayoung> dolphm_, right
18:28:31 <ayoung> this is implementation
18:28:36 <dolphm_> ayoung: not even on v3
18:28:54 <ayoung> OK...let me back up
18:29:05 <ayoung> metadata:  it is a denormalized blob
18:29:41 <ayoung> this pattern is in groups, tenants, domains
18:29:50 <ayoung> there are grants for
18:30:09 <ayoung> UserProjectGrant UserDomainGrant GroupProjectGrant and GroupDomainGrant
18:30:36 <henrynash> ayoung: yes, and the meta data in each table just has the roles in it, e.g.:
18:30:36 <henrynash> class UserDomainGrant(sql.ModelBase, BaseGrant):
18:30:37 <henrynash> __tablename__ = 'user_domain_metadata'
18:30:38 <henrynash> user_id = sql.Column(sql.String(64), primary_key=True)
18:30:39 <henrynash> domain_id = sql.Column(sql.String(64), primary_key=True)
18:30:40 <henrynash> data = sql.Column(sql.JsonBlob())
18:30:42 <ayoung> denormalized data for things that should have integrity constrains in the DB is a bad approach
18:30:47 <dolphm_> ayoung: data -> role_id
18:30:59 <ayoung> dolphm_, that is where I am headed
18:31:06 <dolphm_> multiple roles could be in data though
18:31:10 <ayoung> can we drop the data/extra columns for all of these?
18:31:16 <ayoung> dolphm_, bad
18:31:18 <dolphm_> ayoung: yes
18:31:24 <ayoung> roles are foreign keys
18:31:35 <dolphm_> ayoung: they should be, yes
18:31:38 <ayoung> we looks referential integrity if we do multiple keys in one field
18:31:50 <henrynash> ayoung: why don't we just at a role_id column (in place of the data) and then that is the foreign key
18:32:13 <henrynash> ayoung: that was the plan....
18:32:25 <ayoung> henrynash, sure, that is OK, so long as we are ok with getting rid of the data column
18:32:34 <gyee> +1
18:32:42 <dolphm_> +1
18:32:48 <ayoung> we have this nasty tendency to do serialied JSON blobs that we really should not do
18:32:51 <henrynash> +1
18:33:04 <dolphm_> ayoung: this is not the membership issue though..?
18:33:22 <henrynash> ayoungL so I did commit as part of the groups work to do that normalization
18:33:25 <ayoung> dolphm_, well, for users to proejcts, membership is replaced by roles
18:33:35 <ayoung> for domains, membership is specified by the domain id
18:33:50 <gyee> sounds 'bout right
18:34:01 <dolphm_> user_tenant_membership and user_tenant_metadata need to both be migrated to user_project_grants
18:34:13 <ayoung> dolphm_, yep..I'm working on that
18:34:19 <dolphm_> ayoung: awesome
18:34:35 <ayoung> the code that calls them is common to those as well as domain and group grants:
18:34:46 <dolphm_> ayoung: let me know if you need help there
18:34:49 <ayoung> link coming...
18:34:54 <dwchadwick> I dont suppose there is any chance you can change the name grants to assigns is there?
18:35:10 <dolphm_> dwchadwick: implementation or api?
18:35:27 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L242
18:35:28 <dwchadwick> Grants sounds like you are granting a privilege, whereas in reality you are assigning role membership or similar
18:35:42 <dwchadwick> the granting of acces is done by the service via its policy engine
18:35:56 <ayoung> and the corresponding creates all have logic
18:36:12 <dwchadwick> API primarily, but the implementation ought to match the API
18:36:38 <dolphm_> dwchadwick: propose the corresponding api changes, they're only superficial there
18:36:57 <dwchadwick> OK, I am currently reviewing the APIv3 anyway
18:37:06 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L550
18:37:27 <ayoung> so these all assume that the roles are a denormalized list
18:37:46 <dolphm_> dwchadwick: make it a separate patch though (smaller patches are easier to review and faster to merge with fewer conflicts)
18:38:13 <ayoung> for a group/domain grant,
18:38:33 <dwchadwick> yes my changes wont be anything to do with Kristy's mapping changes
18:38:43 <ayoung> where we are saying group_id gets roles in domain_id
18:39:12 <ayoung> there is no need for membership....OK I think the only thing that was unclear than I needed to get straight was domain
18:39:22 <ayoung> groups should have membership...right?
18:39:46 <gyee> yes
18:39:47 <ayoung> users are either a member of a group or they are not...they do not have "roles" in a group.
18:40:00 <henrynash> ayoung: correct
18:40:09 <ayoung> instead they get roles assigned by being a member of a group....
18:40:17 <henrynash> ayoung: yes
18:40:26 <dwchadwick> users are also members of a role as well
18:40:30 <dolphm_> ayoung: Grant role to user on domain: PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}
18:40:39 <dolphm_> ayoung: Grant role to group on domain: PUT /domains/{domain_id}/groups/{group_id}/roles/{role_id}
18:40:49 <dwchadwick> assign role to user please
18:41:12 <henrynash> dwchadwick: there is no such call….you must specify a target
18:41:17 <dolphm_> dwchadwick: i'm quoting the current spec
18:41:32 <ayoung> so..users have roles in domains....
18:41:42 <dwchadwick> I was merely asking that you replace Grant by Assign
18:41:48 <dolphm_> ayoung: yes, that's what henrynash is working on
18:41:53 <ayoung> hmmmm...that seems superfluous
18:42:05 <dolphm_> domain role grant, domain-scoped tokens, domain-authz operations in keystone (create user, create project)
18:42:07 <ayoung> seems like it would be cleaner to keep roles in group assignements
18:42:39 <ayoung> dolphm_, this is implementation,
18:42:41 <dolphm_> ayoung: users and groups can both be granted roles in both projects and domains
18:42:48 <henrynash> ayoung: yes…and to be complete a user maybe be able to operate on a domain/project either due to a direct grant or via grant on a group of which they are a member
18:42:56 <dolphm_> henrynash: +1
18:42:59 <dolphm_> ayoung: this is api
18:43:35 <ayoung> ok..bear with me for  a moment
18:43:41 <henrynash> dwchadwick; (just using grant since this is current terminology)
18:43:44 <topol> henrynash: +1
18:43:50 <dwchadwick> understood
18:44:06 <ayoung> dwchadwick, you understand?  Good...someday you can explain it to me.
18:44:17 <ayoung> OK...
18:44:28 * gyee is working on understanding Keystone book
18:44:38 <dwchadwick> excellent idea
18:44:54 <ayoung> so domain membership is done via the user object, we don't need a collection there...so the only collection that domain maintains is via role grants
18:44:55 <dwchadwick> book should have been written before the code
18:44:58 <dolphm_> ayoung: this needs to go away http://paste.openstack.org/raw/29722/
18:45:06 <dwchadwick> then the code would have been much simpler ;-)
18:45:16 <ayoung> dolphm_, done this morning in my local repo
18:45:30 <henrynash> ayoung: +2
18:45:38 <dolphm_> ayoung: post for review and we'll take it from there?
18:45:44 <ayoung> dolphm_, not so simple
18:45:53 <ayoung> there are a lot of changes implicit with that
18:45:55 <ayoung> migration etc
18:45:58 <dolphm_> ayoung: yep
18:46:04 <dolphm_> legacy import rewrite
18:46:10 <dolphm_> schema migration, data migration
18:46:11 <ayoung> and I'm still flushing out errors....
18:46:18 <dolphm_> driver calls that need to be killed
18:46:48 <ayoung> "I've got my country's 500th anniversary to plan, my wedding to arrange, my wife to murder and Guilder to frame for it; I'm swamped. "
18:46:54 <dolphm_> ayoung: post something WIP so we can make sure everyone is on the same page
18:47:17 <ayoung> dolphm_, will do, as soon as I can get even the sql unit tests to run to completion
18:47:34 <dolphm_> ayoung: i never had time to get that far when i tackled it :(
18:47:48 <dolphm_> #topic v3/auth
18:48:06 <dolphm_> gyee: we obviously already talked about this...
18:48:16 <dolphm_> gyee: comfortable to land in g-m3?
18:48:27 <gyee> you mean auth plugin?
18:48:42 <dolphm_> gyee: i think we're just talking about auth on the v3 api in general
18:48:45 <gyee> well, v3/auth still result in token issuance
18:48:52 <dolphm_> gyee: using the current spec
18:48:53 <henrynash> dolphm: maybe we covered this a bit already….I just wanted us to get the v3/auth early since I need to add to itf for domain name spaces
18:48:54 <gyee> so v3/tokens seem ok to me
18:49:06 <dolphm_> henrynash: +1
18:49:40 <dolphm_> gyee: want me to propose the spec changes to move from /v3/tokens -> /v3/auth?
18:49:52 <dolphm_> happy to help however i can
18:49:54 <gyee> g-m3 cut-off is 2/21 right?
18:49:58 <dolphm_> gyee: yes
18:50:10 <gyee> why change to v3/auth?
18:50:29 <gyee> I am OK with v3/tokens since auth will result in token creation anyway
18:50:39 <dolphm_> gyee: (mailing list discussion) /tokens is not a collection, it's a noun e.g. /authentication /authorization
18:50:40 <dwchadwick> and what does auth mean? authn or authz?
18:51:30 <dolphm_> dwchadwick: intentionally ambiguous since the same api handled both in one call if you need that efficiency
18:51:39 <dwchadwick> ok
18:51:44 <gyee> dolphm_, go ahead, same amount of code anyway
18:51:58 <dolphm_> dwchadwick: or you can break it into two steps against the same API (request authentication and then request authorization)
18:51:59 <ayoung> dwchadwick, I proposed an url scheme /auth/n and /auth/z but was told I was being a smarty pants
18:52:10 <dolphm_> gyee: yep
18:52:14 <gyee> thanks
18:52:19 <dwchadwick> But I thought the service made the authz decision via its policy engine
18:52:37 <dolphm_> #action dolph to revise v3 API from /v3/tokens -> /v3/auth
18:52:39 <dwchadwick> Are you proposing that Keystone will run an authz server?
18:52:41 <ayoung> dwchadwick, to a degree
18:52:56 <dolphm_> dwchadwick: only that it provides an interface to an authz implementation, which may be a remote server
18:53:11 <ayoung> dwchadwick, but tenant tokens, where are authN stuff, are provdied by keystone, and keystone can decide not to issue one
18:53:28 <dwchadwick> Well I like the smarty pants API :-) with the /n and /z
18:54:11 <dolphm_> /v3/authentication and /v3/authorization would make the REST fans happy
18:54:29 <gyee> my fingers won't be happy
18:54:34 <dwchadwick> its is also much clearer to the user
18:55:16 <dwchadwick> but /v3/authz and /v3/authn are also clear and easier on the fingers
18:55:25 <gyee> damn straight!
18:55:40 <ayoung> dwchadwick, so...there is token issuing and token validation
18:55:46 <ayoung> we don't want token  IDs in the URL
18:55:50 <dwchadwick> Yes we have that in our design
18:55:53 <ayoung> as that is Identified as a security risk
18:56:16 <dwchadwick> why a security risk? is this due to them being bearer tokens?
18:56:20 <ayoung> the token is really the signed set of attributesd for the user, so the union of authz and authn data
18:56:23 <dwchadwick> you can solve that by holder of key
18:56:25 <ayoung> dwchadwick, yes
18:56:39 <ayoung> dwchadwick, and then we need a full SSL handshake
18:56:46 <ayoung> and then we have reimplemented X509
18:56:51 <ayoung> which we should be using in the first place
18:56:52 <gyee> SSL won't protect URL
18:56:55 <ayoung> or Kerberos
18:57:03 <ayoung> gyee it wouldn't need to
18:57:14 <ayoung> if the tokens were not vulnerable to a relay attack
18:57:27 <dolphm_> dwchadwick: requested URLs are frequently logged, obtaining such a log would provide access with any still-valid tokens
18:57:44 <dwchadwick> yes replay attacks
18:58:06 <ayoung> dwchadwick, here is the deal
18:58:11 <ayoung> there are lots of secure technologies
18:58:17 <dolphm_> gyee: +1
18:58:22 <ayoung> we can't use them because of the webserver that openstack chose
18:58:24 <ayoung> it is really that simple
18:58:34 <ayoung> and really that frustrating
18:58:38 <dolphm_> gyee: getting it out of the URL and then wrapping the connection in SSL makes it sound pretty safe to me
18:58:47 <ayoung> and we have 2 minutes left in our meeting
18:58:53 <dolphm_> #topic open discussion
18:58:55 <gyee> dolphm_ +2
18:59:34 <dolphm_> anything else in hte last 20 seconds?
18:59:36 <dwchadwick> I must go now. Bye for now
18:59:40 <dolphm_> dwchadwick: /wave
19:00:01 <dolphm_> #endmeeting