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