18:01:29 <dolphm> #startmeeting keystone 18:01:29 <openstack> Meeting started Tue Feb 4 18:01:29 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:33 <openstack> The meeting name has been set to 'keystone' 18:01:38 <dolphm> #topic Reminder: Icehouse feature proposal freeze February 18th 18:01:42 <ayoung> Guten Morgan 18:01:55 <fabiog> Hello 18:02:02 <dolphm> that's 12 days to propose a mergeable patch for blueprints, or it doesn't ship in icehouse 18:02:12 <morganfainberg> mornin all 18:02:13 <dolphm> err 14 days because math 18:02:15 <dolphm> morganfainberg: good morning 18:02:20 <morganfainberg> rumors of my demise have been greatly exagerated 18:02:28 <topol> define mergable... 18:02:36 <dolphm> topol: complete 18:02:38 <ayoung> topol, not -1 from Jenkins 18:02:58 <topol> what if someone asks for *more* test cases? 18:03:00 <dolphm> ayoung: a half baked patchset with a +1 from jenkins deserves to be bumped 18:03:06 <ayoung> that too 18:03:13 <dolphm> topol: refinement is fine, if it's got a long way to go, then it shouldn't ship 18:03:15 <ayoung> but Jenkins complaining is a sure fine no-go 18:03:21 <dolphm> ayoung: ++ 18:03:36 * topol mine is passing jenkins... Im golden 18:03:40 <dolphm> if you're breaking devstack or tempest or something, it's too late to resolve cross-project dependencies in icehouse 18:03:44 <bknudson> jenkins complains about a lot of things that are unrelated 18:03:52 <dolphm> transients excluded 18:04:23 <atiwari> dolphm, thoughts on adding link:https://review.openstack.org/#/c/69145/4 for I3? 18:04:29 <morganfainberg> if you're rechecking for known bugs, it's "mergable" 18:04:40 * stevemar is late 18:04:42 <morganfainberg> (elasticrecheck?) 18:04:45 <dolphm> at this point there are several blueprints that i'm becoming paranoid about 18:05:02 <dolphm> anything still Not Started as of next tuesday i'll likely be retargeting to juno 18:05:13 * topol please don't say audit. please dont say audit... 18:05:13 <dolphm> https://launchpad.net/keystone/+milestone/icehouse-3 18:05:17 <ayoung> Any objection to use pushing through a change that allows notifications to go over oslo messaging instead of RPC. Turns out it is kindof important 18:05:26 <dolphm> topol: audit is started! 18:05:36 <topol> :-) 18:05:43 <ayoung> not sure if we BPed it or not....jamielennox was working on it. and audit will need it 18:06:02 <morganfainberg> dolphm, ephemeral pki tokens need ayoung's revocation stuff. i'll be reviewing the revocation stuff and starting on it (unless it watch rolled into the revocation events) 18:06:09 <ayoung> jamielennox, we have a BP for the notifications Messaging work? 18:06:10 <morganfainberg> s/watch/was 18:06:10 <jaypipes> ayoung: as long as the log verbosity and false-positive exception logging in oslo.messaging is fixed. 18:06:16 <dolphm> atiwari: it's a core api change post m2, so target juno 18:06:25 <dolphm> juno-m2, specifically 18:06:44 <dolphm> morganfainberg: ++ at least get it in review based on ayoung's work 18:06:48 <dolphm> morganfainberg: good way to test it as well 18:07:00 <ayoung> ++ 18:07:06 <dolphm> morganfainberg: if devstack can run with PKI without persisting tokens, then revocations events are fairly solid 18:07:09 <morganfainberg> and parallel testing likely needs to be punted for J1 - i can do some of the scafolding in place post feb 18, because it is test restructuing. but bigger changes - likely will land there 18:07:12 <atiwari> ok 18:07:12 <morganfainberg> dolphm, ++ 18:07:23 <dolphm> morganfainberg: so PLEASE get that going that'll be awesome :D 18:07:32 <dhellmann> jaypipes: see my email to the -dev list from a little bit earlier today on that logging issue 18:07:38 <dolphm> morganfainberg: will retarget now 18:07:44 <jaypipes> dhellmann: I did. 18:07:49 <morganfainberg> dolphm, ayoung, since the kvs refactor and other stuff is up for review now. ephemeral is my last BP that hasn't got code up 18:07:50 <ayoung> revocation events getting solid. yoriksar did such a good review I made him a co-author 18:07:51 <jamielennox> ayoung: blueprint oslo-messaging 18:07:59 <morganfainberg> ayoung, awesome!!! 18:08:12 <dolphm> bknudson: s3 token is unblocked now :) 18:08:16 <dhellmann> jaypipes: cool 18:08:33 <bknudson> dolphm: great... I think I need to update the requirements and then get that to keystone then update keystone. 18:08:49 <dolphm> ayoung: awesome 18:09:00 <ayoung> https://blueprints.launchpad.net/keystone/+spec/oslo-messaging 18:09:02 <morganfainberg> dolphm, can https://blueprints.launchpad.net/keystone/+spec/role-assignments-unified-sql be done behind the scenes since it's not really a "feature" and not api impacting? 18:09:04 <dolphm> bknudson: ++ you mean bump our dep to >0.5.0 ? 18:09:18 <dstanek> i have a few commits coming today or tomorrow for blueprint password-rotation 18:09:19 <bknudson> dolphm: right 18:09:41 <ayoung> dolphm, we'll need client changes to be able to make it work. My current plan is to get the code merged into server, then clone the module.py file into client and integrate it there 18:09:43 <dolphm> dstanek: yay! 18:09:50 <stevemar> dstanek, lookin forward to it 18:10:05 <dolphm> jamielennox: is oslo-messaging realistic for icehouse? 18:10:18 <dolphm> that seems ambitious :) 18:10:21 <ayoung> dolphm, based on the glance implementation, I would say yes 18:10:23 <jamielennox> dolphm: it's pretty much done - it's a simple set of patches 18:10:39 <dolphm> jamielennox: good to hear - when will we see reviews? :D 18:10:43 <ayoung> its dropping the dep on oslo notify and cloning the glance patch, single file. 18:10:57 <lbragstad> jamielennox: have any issues with the self.host we talked about a few nights ago? 18:11:05 <lbragstad> and publisher_ids? 18:11:14 <jamielennox> it might be worth rethinking later how we handle notifications but for now to do a swap that is just the same functionality is pretty simple 18:11:41 <jamielennox> dolphm: starts here: https://review.openstack.org/#/c/70661/ 18:11:45 <dolphm> henry-nash isn't around, but does anyone know of progress against https://blueprints.launchpad.net/keystone/+spec/role-assignments-unified-sql ? 18:11:56 <ayoung> speaking of notifications: do we need to break change password out into its own notification? We revoke tokens based on that, and it is one of the few events that are not processed based on notifications 18:12:04 <jamielennox> bknudson: addressed your comment on https://review.openstack.org/#/c/70661/ can you have another look 18:12:08 <dolphm> jamielennox: can you add links to the bp and update the bp status? the bot appears to be dead 18:12:22 <jamielennox> dolphm: will do 18:12:27 <jaypipes> jamielennox: did you see my patch to avoid using a global constant for dependency injection? 18:12:33 <morganfainberg> dolphm, i think we can do that behind the scenes 18:12:39 <stevemar> dolphm, no idea, i could try to see if henry is around 18:12:48 <morganfainberg> dolphm, it should have no API impact. in fact if it does, we are doing it wrong 18:12:53 <jamielennox> lbragstad: no, it went fairly smoothly once i dropped it 18:12:57 <topol> I just pinged henry 18:13:02 <jamielennox> jaypipes: just woke up :) 18:13:02 <lbragstad> jamielennox: good deal 18:13:05 <stevemar> thanks topol 18:13:13 <dolphm> morganfainberg: but a lot of work would be easier if that was done 18:13:13 <jaypipes> jamielennox: no worries :) 18:13:21 <morganfainberg> dolphm, aye 18:13:27 <ayoung> jaypipes, he's in Brisbane...he's hard core 18:13:32 <jamielennox> jaypipes: i'll have a look soon though because i'm not sure what you were going for with your comment 18:13:40 <morganfainberg> ayoung, but i mean that can probably be an I3 target vs feb 18? 18:13:44 <jaypipes> jamielennox: I pushed a patch with example code. 18:13:47 <topol> or he cant sleep 18:13:47 <morganfainberg> dolphm, ^ not ayoung 18:13:52 <jaypipes> jamielennox: feel free to use, or not. :) 18:14:11 <morganfainberg> it's... cleanup that looks like a BP vs. a "feature" 18:14:22 <dolphm> morganfainberg: ah; it is a giant refactor though 18:14:34 <morganfainberg> dolphm, fair enough. 18:14:40 <dolphm> morganfainberg: the goal of feature proposal freeze is to avoid bugs, and have more time to review, identify and fix them 18:15:16 <morganfainberg> dolphm, that is the one big bit of cleanup i think i'll be sorry it's not in Icehouse if it does't make it... but we can't have everything 18:15:29 <morganfainberg> esp. if no work has been done on it 18:15:29 <dolphm> morganfainberg: ++ 18:15:52 <topol> Henry says he is coding that right now and 1st review will be in a few days 18:16:04 <dolphm> any progress would be nice to have; it's big enough that it might benefit from being taken a table or two at a time 18:16:04 <ayoung> If do put assignments all in one table, lets make the fields big enough to hold the composite userids (with the embedded domain Ids ) in them, or put an idneityt_domain field in there 18:16:10 <dolphm> topol: thanks! 18:16:13 <topol> (he cant join) 18:16:20 <morganfainberg> topol, cool! 18:16:59 <topol> from Henry: confusing there are two bp for the same one...here's the one I create a while back that I have marked as started: https://blueprints.launchpad.net/keystone/+spec/grant-table-rationalization 18:17:39 <dolphm> i also just bumped https://blueprints.launchpad.net/keystone/+spec/keystone-py3kcompat to ongoing 18:17:56 <stevemar> dolphm, good call ++ 18:18:03 <dolphm> i3 wasn't really realistic for an end goal, but we've made a ton of progress on that front 18:18:10 <dolphm> dstanek: thanks for the py33 gate ^ :D 18:18:49 <dstanek> dolphm: ma pleasure 18:18:55 <dolphm> bknudson: know anything of https://blueprints.launchpad.net/keystone/+spec/i18n-logging ? 18:18:59 <jamielennox> all the projects are blocked by eventlet for py3 i thought? 18:19:01 <dstanek> i with all of our deps already worked on py3 18:19:04 <bknudson> it looks like they're updating webob requirement so maybe the py3k gate will do something. 18:19:08 <dolphm> i'm not aware of luis' irc handle 18:19:16 <dolphm> jamielennox: ++ 18:19:25 <lbragstad> dolphm: luisg 18:19:47 <dolphm> pinged him in -dev 18:20:26 <bknudson> dolphm: my understanding is that it's implemented. I'll check on it. 18:20:52 <luisg> hi dolphm 18:20:55 <dolphm> luisg: o/ 18:21:02 <dolphm> luisg: i wanted to check in on https://blueprints.launchpad.net/keystone/+spec/i18n-logging 18:21:14 <dolphm> are there patches in review for that / can we expect to see some soon? 18:21:30 <topol> bknudosn is the i18n-logging Daisy's stuff? 18:21:55 <luisg> dolphm, afaik all the patches for that were already delivered by bknudson 18:22:08 <topol> (Daisy's stuff for keystone...) 18:22:19 <dolphm> luisg: bknudson: on the logging side? 18:22:23 <bknudson> luisg: it was probably included in an oslo-incubator sync... 18:22:30 <luisg> correct 18:22:54 <bknudson> so maybe all I need to check is if keystone is up-to-date with oslo-incubator log. 18:22:57 <dolphm> bknudson: that's what the first step described by the bp -- last i checked there was something relevant in review for oslo 18:23:05 <dolphm> don't recall it syncing 18:23:30 <dolphm> bknudson: if you find a patch to call that one Implemented, will you link it in the whiteboard on that bp? 18:23:41 <bknudson> dolphm: will do 18:25:02 <dolphm> and to put everyone to sleep again... 18:25:04 <dolphm> #topic Why we should have reserved migrations for backports 18:25:13 <dolphm> #link https://review.openstack.org/#/c/69884/ 18:25:36 <morganfainberg> zzzzz 18:25:41 <dolphm> checkout the conversation around Jan 30 18:25:41 <morganfainberg> i mean >.> 18:25:43 <ayoung> Nope 18:25:48 <dolphm> we got lucky in this case fortunately :) 18:26:27 <dolphm> anyway, it's solid demonstration of why we need https://blueprints.launchpad.net/keystone/+spec/reserved-db-migrations-icehouse 18:26:28 <ayoung> dolphm, we risk rewriting history with that approach....I really think we need to avoid doing that 18:26:40 <topol> Im assuming the Jan 30 conversation is a dolphm "I told you so"??? 18:26:41 <dolphm> ayoung: ? 18:26:45 <ayoung> dolphm, if someone is tracking tip of tree 18:26:56 <ayoung> and we slip in a migration, we mess them up 18:27:06 <dolphm> ayoung: there's no rewriting of history in that case, as it's the same history being backported 18:27:06 <ayoung> like, say that we reserve 40-45 18:27:29 <morganfainberg> ayoung, if the migration is idempotent, you make it happen "next" as well as previously in the backport 18:27:37 <bknudson> seems like if someone wants to add or remove an index then they can go ahead. 18:27:38 <morganfainberg> ayoung, i think that is the general approach. 18:27:44 <ayoung> now we decide we need to use up a reservation, so 40 goes from no-op to doing something 18:27:56 <ayoung> if I look at a DB at version 45, has that been applied or not? 18:28:14 <dolphm> i'll contribute some docs explaining how reserved migrations work, and why they won't break anyone ever 18:28:21 <morganfainberg> ayoung, anything backported _must_ be idempotent. 18:28:31 <dolphm> #action dolphm to doc reserved migrations 18:28:32 <topol> dolphm ++ docs would really help for vetting 18:28:48 <ayoung> morganfainberg, idempotent is only relevant if it is executed at least once 18:28:51 <morganfainberg> ayoung, i'm not saying i like backporting migrations 18:28:53 <bknudson> just because we have the reserved migrations doesn't mean we have to use them anyways. 18:28:57 <ayoung> what if it is executed 0 times 18:29:09 <ayoung> bknudson, its like line number in basic 18:29:12 <morganfainberg> ayoung, so you backport it and make it the "next" one, so it's now 40 and 50 for example 18:29:17 <bknudson> are we going to have reserved migrations for extensions, too? 18:29:21 <dolphm> ayoung: i'll write the docs, and you can comment on the approach there 18:29:21 <morganfainberg> ayoung, new runs get the change, old runs get it earlier 18:29:35 <dolphm> i'll include them with the reserved migrations patch https://review.openstack.org/#/c/70153/ 18:29:35 <morganfainberg> ayoung, but.. like i said not that i am for it, just how it would need to work 18:30:22 <dolphm> #topic Return fake users for federated users that don't exist? 18:30:24 <dolphm> bknudson: o/ 18:30:36 <ayoung> We are doing something wrong...but I suspect that is what the SQL alchemy migrations force on us. Alembic has a better approach, doesn't it? More Git like? 18:30:46 <bknudson> ok, so this is because we can have assignments that don't point to users anymore. 18:30:50 <dolphm> i think i've sufficiently confused myself on this topic 18:30:56 <bknudson> if you get users for project (v2 api), it returns all the users 18:31:03 <morganfainberg> ayoung, yes, and no, some of the same issue, but you can reorder them as needed. 18:31:11 <morganfainberg> ayoung, among other things. 18:31:15 <bknudson> which now will 404 Not Found for those assignments to users that don't exist. 18:31:20 <morganfainberg> ayoung, alembic is better, but not 100% solution 18:31:25 <lbragstad> ayoung: ++ 18:31:29 <dolphm> morganfainberg: bknudson: save it for the relevant review 18:31:30 <bknudson> I'm sure there's a few ways to handle the situation... 18:31:46 <ayoung> dolphm, OK...I'll concede, so long as we use the reservations very sparingly 18:31:52 <bknudson> what I'm proposing is to build a fake user to return 18:32:15 <bknudson> because then the caller at least knows the assignment is there and which user_id it's to. 18:32:17 <dolphm> bknudson: it sounds to me like you're trying to code yourself out of a situation that we shouldn't be in at all 18:32:20 <topol> bknudson what is the username and id for the fake user??? 18:32:24 <dolphm> there shouldn't be role assignments on ephemeral users, period 18:32:30 <bknudson> user-<user-id> 18:32:50 <bknudson> so we should not allow creating an assignment to a user that doesn't exist? 18:32:56 <morganfainberg> bknudson, i thought we said federated had to have grants on a group. 18:33:01 <morganfainberg> not a federated user 18:33:10 * morganfainberg might be mis-remembering 18:33:19 <bknudson> this also applies to ldap users. 18:33:30 <stevemar> topol, https://gist.github.com/dolph/5cfa70c02f5b141060c5#file-notes-md 18:33:32 <marekd> morganfainberg: ++ but almost everything in the keystone depends on the user_id..... 18:33:38 <bknudson> since the user might be deleted from ldap directly 18:33:47 <ayoung> bknudson, so...this is the better long term solution: create a uer obnject at the start of the token pipelines. If that user object comes out of the backing store, or out of a SAML document, it is irrelevant 18:33:47 <morganfainberg> bknudson, oh. 18:33:54 <topol> I thought this was always going to be dynamic lookup of the federated user? 18:34:04 <dolphm> topol: what does that mean 18:34:07 <ayoung> dolphm, there absoutelty should be roel assignments on ephemeral users 18:34:11 <morganfainberg> topol, you can't ask the idp about a user really. 18:34:16 <dolphm> ayoung: that doesn't make sense 18:34:17 <ayoung> SAML means you will not have seen the user before they hit the cluster 18:34:23 <topol> means you dont have to store anything 18:34:25 <marekd> ayoung: ++ 18:34:28 <dolphm> ayoung: correct 18:34:40 <dolphm> ayoung: and we drop them into groups, and they get role assignments that way 18:34:41 <ayoung> I'm the teacher, I get the student list. I create a role assignemt for the users in my class. Come Day 1 they get their resources 18:35:05 <bknudson> how are the group assignments done? 18:35:05 <dolphm> ayoung: you assign roles to group=students, not user=student1, user=student2, user=student3 18:35:08 <bknudson> using identity groups? 18:35:42 <ayoung> dolphm, but groups are from Identity. They won't have a group in their SAML document that matches this 18:36:02 <ayoung> short of putting an ephemeral group construct, we need to allow direct role assignments. 18:36:08 <bknudson> I'm guessing you can't put a non-existant user in a group 18:36:30 <morganfainberg> bknudson, doesn't the SAML also dictate groups? 18:36:40 <marekd> morganfainberg: it can, but doesn't have to. 18:36:41 <morganfainberg> bknudson, and wrt groups we only ever (iirc) reference the id 18:36:43 <bknudson> morganfainberg: I believe the federation mapping will asign groups. 18:36:44 <ayoung> morganfainberg, it *CAN* but it won't 18:36:50 <dolphm> ayoung: groups are from identity, yes-- i'm (perhaps falsely?) assuming that an identity backend will still be available? 18:36:52 <morganfainberg> ayoung, i meant via mapping 18:37:07 <ayoung> morganfainberg, its a difference between authorization and authentication. SAML will have the "static" view of the user from the central IT 18:37:10 <dolphm> bknudson: ++ 18:37:23 <ayoung> morganfainberg, might not be anything there to map on 18:37:29 <morganfainberg> ayoung, so we need "assignment" groups now? 18:37:42 <dolphm> morganfainberg: you just lost me 18:37:44 <ayoung> morganfainberg, probably, but direct role assignments come first 18:37:45 <dstanek> i thought we were only assigning roles to groups and using mapping to match SAML to the groups 18:37:51 <morganfainberg> dolphm, i feel lost myself 18:37:52 <dolphm> ayoung: define "direct" ? 18:38:02 <ayoung> dolphm, user to project 18:38:04 <morganfainberg> dstanek, that was my understadning 18:38:07 <ayoung> as opposed to via groups 18:38:11 <marekd> dstanek: that was the idea. 18:39:01 <morganfainberg> marekd, dstanek , that sounds like a mapping needs to generate some group-like-reference (id) then? 18:39:04 <bknudson> given a user-id, assignment backend doesn't know what group they're in, right? 18:39:26 <bknudson> because groups are calculated via mapping of user attrs which we don't have 18:39:28 <morganfainberg> and then you used the assertion to figure all that out each time? 18:39:44 <marekd> morganfainberg: kind of, the problem is that almost everything regarding token_api token_provider_api assumes there is existing user in the backend.... 18:40:06 <morganfainberg> marekd, that is something we can fix. 18:40:06 <dolphm> marekd: that needs to change then 18:40:14 <morganfainberg> marekd, in-fact we should fix that 18:40:20 <dolphm> i think we discussed that at the hackathon? 18:40:26 <morganfainberg> dolphm, think so 18:40:26 <dstanek> morganfainberg: why would it need to generate an id? 18:40:57 <morganfainberg> dstanek, grants are based on the project/domain/whatever-group combination? 18:40:59 <dolphm> mapping should output a list of group IDs 18:41:27 <morganfainberg> dstanek, so.. you need to be able to do some kind of lookup for the grant purpose? i think... 18:41:32 <dolphm> so group-project-role + group-domain-role assignments are all you need 18:41:51 <marekd> dolphm: me? that's relatively easy to fetch... 18:42:01 <morganfainberg> assuming we only have data in assignment (can't ask identity) it needs to be some consistent id we can reference.. or am i totally missing something? 18:42:30 <marekd> dolphm: but i am again super-confused. we spent like few hours discussing that and ended up with responding with a list of groups...the token+roles idea is again on a track? :( 18:42:31 <dolphm> marekd: i was just making a general statement, but i'm glad it strikes you as easy :) 18:42:42 <ayoung> user_id needs to be composed: one thing from SAML etc, one thing from Keystione (domain id) 18:42:42 <bknudson> morganfainberg: assignment can get the roles for a group given group id. 18:42:43 <dstanek> morganfainberg: i thought the mapping statically contained the group id 18:42:46 <marekd> dolphm: NO IT DOESN'T :P 18:42:53 <ayoung> then we don't confirm that the user "exists" 18:43:00 <dolphm> marekd: lol "that's relatively easy to fetch..." 18:43:33 <morganfainberg> bknudson, i'm very confused... if the user if coming from SAML / is federated, we are allowing them to be placed in a SQL (or LDAP) identity group? 18:43:43 <dolphm> dstanek: correct, multiple potential group ids 18:43:55 * dolphm federation is hard 18:44:03 <bknudson> morganfainberg: they're not put in the group in identity... we calculate the group IDs from the user properties. 18:44:16 <morganfainberg> bknudson, ok. so... the group is also ephemeral 18:44:19 <bknudson> morganfainberg: with federation identity is not involved. 18:44:21 <marekd> morganfainberg: no 18:44:25 <dstanek> morganfainberg: no 18:44:33 <bknudson> morganfainberg: I don't think you'd have to define the group. 18:44:38 <dolphm> morganfainberg: i was assuming sql/ldap groups 18:44:45 <marekd> dolphm: ++ 18:44:56 <dolphm> bknudson: define "calculate the group ID" ???? 18:44:59 <ayoung> assume that a role assignment can be made to a group from an IdP prior to the group being created 18:45:05 <morganfainberg> bknudson, that was my assumption here 18:45:07 <dolphm> bknudson: mapping isn't inventing groups, nor creating groups that don't exist 18:45:18 <ayoung> cuz there will be no "group created" event 18:45:32 <ayoung> just that some SAML doc comes in with an attribute that we map to a group. 18:45:43 <marekd> mapping is a connector beetween real world (SAML) and a keystone local world... 18:45:48 <bknudson> dolphm: what is there in the identity group that needs to be looked up to figure out what group a user is in? 18:45:49 <morganfainberg> ayoung, do we care? i mean we don't get user_created events either? 18:45:50 <marekd> so i assume the groups MUST alread exist. 18:45:59 <ayoung> exzactly 18:46:14 <morganfainberg> marekd, i always assumed you'd effectivly "generate" the group based upon mapping and it would be IDP:<group something> 18:46:22 <dolphm> bknudson: i don't understand the question 18:46:32 <morganfainberg> marekd, not go create ideneity group and then use saml to associate the user to that group 18:46:33 <dolphm> bknudson: you don't ask identity what groups a user is in 18:46:38 <marekd> morganfainberg: what for? you'd endup with a group without any roles... 18:46:39 <ayoung> you can't query Identity. That is the new rule for Federation 18:46:57 <ayoung> everything just comes in an either it works or they file a ticket 18:47:02 <dolphm> morganfainberg: if that's the case, i wouldn't call them groups at all 18:47:25 <marekd> morganfainberg: somehow i must map SAML assertion into an ephemeral user with set of roles... 18:47:25 <bknudson> do we need a new kind of federated user/group role assignment? 18:47:28 <dolphm> morganfainberg: the goal was to map ephemeral users into identity groups and let assignments do it's thing 18:47:29 <morganfainberg> marekd, no, you could still assign roles to the "emphemeral group" it just would be created on-the-fly e.g. has attribute contractor, this maps to <IDP>:contractor 18:47:34 <dolphm> bknudson: please no 18:47:50 <morganfainberg> marekd, since assignment doesn't care if a group exists (or a user) (or it shouldn't) 18:47:56 <dolphm> bknudson: not outside the scope of mapping, anyway 18:48:03 <morganfainberg> i was just massively confused on implementation 18:48:33 <dolphm> it seems that the "assignment drivers shouldn't be talking to identity drivers" conversation got very confused with the federation conversation 18:48:42 <bknudson> I don't understand why the group would have to exist... does it need to have the user_id (?) as a member? 18:48:44 <marekd> morganfainberg: on what basis would you assign those roles to the ephemeral groups? another set of api calls? 18:48:45 <dolphm> those were to separate topics with separate goals 18:48:45 <morganfainberg> i don't particularly like crossing federated -> non-federated identity stuff, but it might be the only approach. 18:48:58 <morganfainberg> marekd, same calls we have now. 18:48:59 <bknudson> will federation do identity_api.get_group(group_id) and verify it exists f? 18:49:02 <dolphm> bknudson: what's the point in having a group that doesn't exist? 18:49:24 <bknudson> you can assign roles to the group id ... the group doesn't have to exist for that. 18:49:29 <morganfainberg> bknudson, ++ 18:50:01 <ayoung> what we need to be able to do is to say "I have a user or group coming in with SAML attribute foo. What ID will they get? Use that to create an assignment for Role on Project" 18:50:24 <dolphm> ayoung: no one cares what ID they get -- we care about their authorization 18:50:59 <dolphm> ayoung: so we care about mapping the ephemeral user into identity groups, and picking up any authorization that implies 18:51:04 <bknudson> I also didn't think that federated users got an id. 18:51:28 <ayoung> dolphm, problem still stands even if you just say "groups" 18:51:53 <ayoung> but I think direct user assignments are going to be very common. If we write them out of the equation, people will get annoyed 18:52:08 <ayoung> "why do I need to create a group for a single person"? 18:52:22 <ayoung> You'll have groups that are basically based on the user ID...ugh 18:52:23 <dolphm> ayoung: SAML attribute foo --> foo_group --> foo_group:foo_role:foo_project -> scoped token for foo_project with foo_role 18:52:26 <ayoung> l;ets not do that 18:52:54 <ayoung> dolphm, but if the only reliable attribute tha comes is the one that uniqely identifies the user? 18:53:03 <ayoung> we are going to have Posix groups. 18:53:18 <ayoung> ayoung:ayoung where user ayoung is the only member of the group ayoung 18:53:38 <bknudson> it makes sense to me to have some kind of user_id that can come out of federation auth just like a list of group_ids. 18:53:49 <dstanek> ayoung: are user-based role assignments common? 18:53:49 <marekd> bknudson: always? 18:53:57 <dolphm> if anything, the end is one group per one capability/rule/permission in policy.json 18:54:01 <bknudson> marekd: I don't think user_id has to be required. 18:54:30 <bknudson> just like maybe group_ids are required. 18:54:41 <bknudson> maybe group_ids aren't required 18:54:52 <ayoung> unify users and groups into one entity? Composite pattern? Party Pattern? 18:54:56 <bknudson> do allow mapping to no groups? 18:55:07 <ayoung> yes 18:55:11 <ayoung> groups are optional 18:55:15 <dolphm> but then you get zero authorization 18:55:18 <dolphm> and can't use opentack 18:55:27 <dolphm> but sure, they're otherwise optional 18:55:35 <marekd> user is optional too. 18:55:44 <marekd> at least in the current state of the mapping engine.. 18:55:47 <ayoung> lets keep it consistent with the current auth model: users can get role assignments in federation. 18:56:05 <stevemar> marekd, currently everything is optional :) 18:56:15 <marekd> ayoung: but what if rule engine doesn't return a user, just a set of groups? 18:56:23 <marekd> that's my concern... 18:56:30 <ayoung> marekd, they need to have a user id 18:56:35 <ayoung> Nova needs it for ownership 18:56:43 <dolphm> marekd: some sort of user identifier either needs to be required, or having a user identifier as an output of mapping shouldn't be a feature at all 18:56:45 <ayoung> group can be optional, but not userid 18:57:03 <dolphm> i'm fine with either way, but everyone seems to want ephemeral IDs 18:57:04 <bknudson> ayoung: that's a good point... other projs might need user id 18:57:14 <ayoung> bknudson, they do 18:57:19 <ayoung> both Swift and Nova rely on it 18:57:36 <marekd> so, rule engine will be obliged to issue a user_id. 18:57:36 <dstanek> user id is very useful in auditing 18:57:36 <dolphm> ayoung: they shouldn't 18:57:44 <bknudson> it can be ephemeral -- maybe it's like "IdP:username" 18:58:07 <dolphm> ayoung: i don't know that we'd break anything meaningful in nova if we didn't give them user identifiers 18:58:22 <stevemar> marekd, I guess so, but if I don't see any user related stuff, I can just leave it out 18:58:37 <ayoung> bknudson, so 18:58:48 <dolphm> dstanek: that's the *only* push back i get for dropping user identifiers :) 18:58:49 <ayoung> userid@@domainid is my suggestion 18:58:53 <marekd> stevemar: no, i should be able to assume that you will give me a userid. 18:59:01 <ayoung> one part from the IdP (userid) and one part from keystone (domainid) 18:59:07 <ayoung> 1 minute 18:59:09 <marekd> stevemar: otherwise what do i put in the token['user_id'] ? 18:59:10 <bknudson> ayoung: do we need to define the format? the mapping will just generate one. 18:59:23 <dolphm> dstanek: in which case, i *want* the answer to be sha1(token) gets audited, and you can trace with that 18:59:36 * dolphm 1 min 18:59:46 <marekd> -dev? 18:59:48 <dolphm> ++ 18:59:50 <dolphm> #endmeeting