18:02:00 #startmeeting keystone 18:02:00 Meeting started Tue Jul 22 18:02:00 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:04 The meeting name has been set to 'keystone' 18:02:17 #topic Juno milestone 2 18:02:56 anything that needs to get in for M2? 18:03:01 dolphm: i added a topic to the end - if we don't get to it i won't be heart broken 18:03:04 #info Ensure changes targeted at milestone-2 are gating TODAY 18:03:09 also, is there a keystoneclient release at M2 time? 18:03:12 dstanek: ack 18:03:30 bknudson: no; but i'd like to do a release of keystoneclient and keystonemiddleware both, by coincidence 18:04:13 if there's any reason to block either of those, target bugs/bp's to the next milestone of those projects and i'll follow up 18:04:18 Lets stagger the client changes after M2 18:04:24 keystoneclient 0.10.0 or keystonemiddleware 1.1.0 18:04:35 ayoung: why? 18:04:45 dolphm, ++ on the release of both of those 18:04:56 dolphm, one thing at a time...and I'm hoping to still get the revocation events in 18:05:15 I'd just suggest getting J2 cut first 18:05:31 ayoung: that'd be nice, but i'd also pull the trigger on 0.11.0 in a heartbeat to get that out if it was delayed beyond 0.10.0 18:05:40 dolphm, fair enough 18:05:47 ayoung, i'd argue that the moment rev. events land we can justify a rlease 18:05:47 ayoung: and yeah, j2 is a bigger deadline for us 18:06:04 lbragstad's api validation patch gated, but there are follow up patches to start utilizing that stuff 18:06:15 ayoung, this is the reason we split out the middleware :) 18:06:37 i'd like to have it marked as Implemented today though, so let's get as much as we can in, and then do the rest in j3 as follow up (wishlist bugs to add validation in different places?) 18:06:38 the meat of the following on patches are in the catalog and assignment apis 18:06:47 dolphm, works for me. 18:07:15 this also means i can use it for validating the token format .. woo 18:07:19 i think lbragstad's patches will be easy to get into merging shape 18:07:30 lbragstad: last i looked, it appeared that you could do more parallelization among those patches (they don't need to be deps?) ... is that true? 18:07:37 dstanek: ++ 18:07:38 yes 18:07:44 they no longer need to be linear 18:07:59 lbragstad: can you get them split apart then? we should be able to merge more+faster that way 18:08:06 so they can be working in parallel and I don't have to spam the channel every time I change the assignment validation patch :) 18:08:19 dolphm: yep, I can do that 18:08:23 lbragstad, but... that was fun 18:08:25 :) 18:08:28 lbragstad: thanks :) 18:08:29 #topic Renaming the OpenStack Identity program to the OpenStack TripleA program 18:08:34 thanks for all the review! 18:08:51 so, i've had smaller conversations on this topic, and i think it's time to bring this to a larger audience 18:08:55 AAA? Authentication, Authorization and Audit?\ 18:09:00 ayoung, yep. 18:09:01 ayoung: ++ 18:09:02 #link https://review.openstack.org/#/c/108739/ 18:09:15 ayoung, which also implies we push for policy (both the rules engine and otherwise) 18:09:15 this is a change to the openstack/governance repo to tweak our program's defintition ^ 18:09:29 ayoung, when / as they graduate. 18:09:44 'Call AAA. We'll help when you crash." 18:09:56 rather small A for authorization as it still done at the services 18:10:01 so there's two meaningful changes proposed there... 18:10:01 dolphm, all for it!!! 18:10:02 we're always the first thing to fail so that's how it works 18:10:08 gyee, nope, we'll own that too 18:10:13 one is renaming the program to TripleA (authentication + authorization + audit) 18:10:16 policy enforcement in keystonemiddleware 18:10:26 which i think better reflects the program's maturity and long term scope 18:10:37 Works for me 18:10:38 and then there's the move of pycadf from oslo to tripleA 18:10:55 good starting place. 18:11:00 * morganfainberg is in support. 18:11:09 is anyone here opposed to either of those changes? concerns? 18:11:12 * topol is also in huge support 18:11:14 AaA sounds good 18:11:18 what about Congress? Are we going to break the news to them that they can't have policy? 18:11:22 gyee, will be TripleA 18:11:26 :) 18:11:28 ayoung: does that still exist? 18:11:44 ayoung, if they get that far, i would make a move to pull them into TripleA 18:11:44 are they still in session??? 18:11:55 commit 6 days ago: https://github.com/stackforge/congress 18:11:57 i basically forgot about it 18:12:08 me too. congress has been quiet 18:12:14 ayoung, but afaict they are very very much off in the "figuring how things work" 18:12:49 morganfainberg, they are looking to do things outside of what we consider policy as well. I suspect they are looking to be a general "here's how you do Rules based stuff" project. Half of what we get from oslo, and half stealing from each of the other project; Firewall rules are policy to Congress as well. 18:13:03 it should go through a graduation process on it's own; if there's clear demand/support for it, i think it would fall under the tripleA umbrella. but it shouldn't be fast tracked or grandfathered into an 'integrated' status 18:13:13 if audit is part of keystone then congress can work on keystone 18:13:15 ayoung, that wouldn't be a good service/program on it's own. 18:13:18 Weekly on Tuesdays at 1700 UTC, e.g. Feb 25, 2014 18:13:34 so if someone needs pycadf but doesnt need all of keystone that is still possible correct? 18:13:42 ayoung: that's right after this 18:13:45 ayoung, but I still don't see it as being a huge blocker for them joining this program if they figure things out 18:13:45 topol, should be. 18:13:50 topol, correct, it would stay a separate lib 18:13:54 topol: pycadf would still stand on it's own 18:14:06 topol: it's core team would just change from oslo core to keystone core 18:14:14 thats would be the only issue folks might bring up 18:14:23 so we'd be adopting keystone-specs for pycadf, for example 18:14:35 actually, according to World Clock it is 1700 UTC right now, I think. 18:14:39 1715 18:14:59 Just FYI: Congress just finished up a meeting and they were talking about joining with Tetris too. 18:15:16 ayoung: oh; i'm definitely wrong. but it's 1815utc according to google :P 18:15:22 celttechie, tetris? 18:15:27 theres going to be a good amount of confusion about the renaming 18:15:34 celttechie: tetris? 18:15:40 * jamielennox arrived late and has never heard of half these terms 18:15:52 stevemar: with tripleO? or just between identity/triplea 18:16:00 stevemar, probably not, rename wouldn't affect the code-name, just the program name: OpenStack Identity -> OpenStack Authn/Authz/Audit 18:16:01 dolphm, the latter 18:16:16 morganfainberg, ahhh OK 18:16:16 stevemar, and most people know the code name more than anything else 18:16:24 we'll have to change the identity API to tripleA API 18:16:30 stevemar: anywhere we can solve for? s/identity-api/triplea-api/ ? 18:16:50 morganfainberg, thought we were changing the codename to triplea 18:16:50 bknudson, I think we leave it as the identity API 18:16:55 stevemar, nah. 18:17:00 i caught up with the train now 18:17:01 stevemar, that would be silly 18:17:07 agreed 18:17:19 AAAAPI 18:17:20 bknudson, we might want to cut it into smaller chunks in the future; each of the A's deserves its own API 18:17:22 ayoung, i'd 301 the references 18:17:33 ayoung: that just sounds terrible 18:17:45 ayoung, because we are more than just "Identity" api, but something to discuss 18:18:03 AAAAPI 18:18:03 so, we would have and Identity API that is implemented in TripleA? 18:18:11 gyee: i just understood your joke. 18:18:20 I feel like that would be confusing 18:18:37 our meetings will get very noisy as we yell aaapi 18:18:53 lbragstad: well, it'd be the identity/tripleA API being implemented by Keystone 18:19:00 bknudson, you missed one aaaapi 18:19:07 aaargh 18:19:10 would it be too much if we did have a few different named APIs? identity-api, audit-api, etc 18:19:20 that's an idea 18:19:25 dstanek, no wouldn't be a bad thing 18:19:30 authentication-authorization-audit-programming-interface 18:19:36 that works too 18:20:07 Dolph, if we split of the IdP, that would be the AuthN API. Current Keystone API would be AuthZ. Audit is its own thing. 18:20:21 so, i think we have a todo list of action items to produce (possibly renaming repos, etc), i'll start an etherpad... 18:20:23 ayoung, sounds right. 18:20:25 authentication-authorization-audit-roles-groups-hierarchy 18:20:31 current API minus the stuff that went to Idp, like user management 18:20:44 dolphm, repo renames are fairly easy. 18:20:53 does this all happen within the standard v3 api? 18:21:02 a³pi 18:21:09 ThreePI 18:21:27 #link https://etherpad.openstack.org/p/Identity-to-TripleA 18:21:30 ayoung, c3po? 18:21:34 jamielennox, nah, I'd suggest we leave things along until we need to bump a version 18:22:24 morganfainberg: yeah, that's how I saw it too 18:22:54 When we are ready to split IdP off into its own, we can deal with it then. I'd aregue that the whole thing stays in the identity API repo, just be 3 "core" apis. We can even version each of them 4.0 if we need to keep the number straight 18:23:16 ayoung, yeah, we'll have a split repo by then 18:23:44 ayoung, lets not even talk about 4.0 here :P 18:23:57 alright... let's move on :P 18:24:12 i added a few things to the etherpad to get started; feel free to add things like repo renames 18:24:36 morganfainberg, its OK, termie started on 5 a while ago 18:24:49 uhh, there's just a couple blueprints & reviews on the agenda: jamielennox bknudson - did ya'll want those to be #topics? 18:25:22 For mine I just wanted to mention that it's making progress 18:25:25 dolphm: don't mind, just want to get some discussion/general approval of ideas 18:25:39 jamielennox: bknudson: okay, then let's hit them in order 18:25:39 and if you want to see it in action check it out and curl -H "Accept: application/json-home" http://localhost:5000/v3 | python -mjson.tool 18:25:44 #topic Auth Specific Data 18:25:50 #link https://review.openstack.org/#/c/107325/ 18:26:08 The main thing that's come up for this one is what to do about already scoped tokens 18:26:22 2 specs for the price of 1 18:26:26 jamielennox, horizon folks would love that 18:26:37 i like the idea that if you are already project scoped you shouldn't receive a list of other projects that you can scope to 18:26:40 right now they are parsing policy files on their own 18:26:47 but i don't know if it's doable given default_project_ids 18:27:20 related i cleaned up https://review.openstack.org/#/c/108071/ 18:27:31 but i don't know if that's a viable alternative 18:27:34 jamielennox: side note, maybe we need a "scope": null or something in an auth request to explicitly request an unscoped token? 18:27:38 would be a separate bp 18:27:47 I wonder if we really need those. What if enumerating projects and domains could only be done with an unscoped token. Like, ever? 18:27:55 that'd also mean we need to support unscoped tokens forever 18:28:06 rather than having a higher level of explicit scope 18:28:10 why does unscoped token need service catalog? 18:28:13 If the token is scoped to a project, then that scoped token can only see that project. 18:28:21 you have the identity endpoint to begin with 18:28:24 Unscoped Tokens Forever! 18:28:25 dolphm: see review https://review.openstack.org/#/c/108071/ 18:28:28 gyee: that's the next agenda item; hold up 18:28:45 jamielennox: ha 18:28:59 unscoped tokens are kind of necessary given that we currently say a token has only one scope 18:29:12 i don't know how far we can get away from that with PKI tokens 18:29:25 dolphm, we can replcae "unscoped" with "scoped to Keystone" so long as it is considered the root scope, and can only be used with Keystone. 18:29:48 Just that we call them unscoped today. Session tokens are another possibility, and we could lump all of the concepts together 18:29:49 ayoung: right, this came up before that an unscoped token was really a keystone scoped token 18:30:05 and the next blueprint about adding a service catalog is really just a cheap way of handling thta 18:30:17 A token granting Token, if you will..... 18:30:39 kerberolize Keystone 18:30:48 ayoung: less lumping please 18:31:22 dolphm, i like my token texture creamy, not lumpy 18:31:33 heh 18:31:44 dolphm, I'm willing to discuss the issues separately, but it might be that we want to have both concepts linked in the same new token format. Mostly this is to support Horizon and comparable use cases 18:32:12 so if we can get ?unscoped=true into /auth/tokens then it might make sense that /auth/projects will only response to unscoped tokens? 18:32:26 ayoung: i'd rather have a gradual evolution than a "new format" 18:32:34 1st step on the path to getting rid of default_project_id 18:32:58 I'd think the token would have "scope": null 18:33:03 or "scope": {} 18:33:06 the auth request 18:33:08 bknudson: ++ 18:33:24 ok 18:33:37 let's save that for an identity-api discussion; jamielennox / ayoung: cut the API details from the spec :) 18:33:46 i'm +A on the direction though 18:34:04 #topic Unscoped catalog 18:34:09 bknudson, yeah, that sounds right. And in the future, we could make that scope: {"endpoint": } 18:34:11 the problem description makes sense... if you really want an unscoped token you can't get one 18:34:19 #link https://review.openstack.org/#/c/107333/ 18:34:25 so I think the unscoped catalog does not need to be in nthe token itslef, just in the response to getting the token 18:34:56 the client will use the result, but only Keystone should be able to validate/accept the token 18:34:56 why catalog for unscoped token? use case? 18:35:04 seems odd that we were able to survive all this time without a catalog in an unscoped token 18:35:16 ayoung: why not just return a catalog in response to an unscoped token + GET /v3/catalog ? 18:35:26 gyee: essentially the point is to make the flow the same as regular tokens 18:35:37 good plan 18:35:45 bknudson: yeah, i'd like to better understand the use case here.. 18:35:45 gyee: at the moment you have to mangle unscoped URLs so that they include the auth_url 18:36:16 auth_url is the same regardless 18:36:32 that becomes somewhat harder with auth plugins where they don't need to provide you the auth_url in the same way 18:36:33 * gyee still confused 18:36:36 clients are going to have to handle tokens without catalogs anyways since they have to support old versions of keystone 18:36:47 bknudson: right 18:37:09 jamielennox: so you basically just want to return the auth_url in something that looks like a catalog because it's too hard to use the auth_url that was originally requested, which you'll have to continue doing anyway for backwards compatibility? 18:37:49 there's only one auth_url right? 18:37:52 dolphm: ideally i'd return the identity endpoints and let the client do the same discovery on them that it would do for a scoped token talking to keystone 18:37:58 one that client need to know anyway 18:38:31 but essentially yes, it's kind of housekeeping in that it's something that i've always found has broken the flow of working with tokens 18:39:16 jamielennox: but you'll still need to support both flows... forever 18:39:22 jamielennox: so you're adding complexity for zero gain 18:39:46 sound like a "zero" gain for me 18:40:32 dolphm: you'd still have to support it, i guess it's just a better feeling workflow 18:40:37 For the server, it sounds like it's easy to implement. 18:41:04 bknudson: it's easy on both sides... but there's no payoff 18:41:25 especially because for unscoped tokens the fallback looks like: https://review.openstack.org/#/c/104771/9/keystoneclient/v2_0/tokens.py 18:41:58 there's really only a few things you can realistically do with an unscoped token 18:42:04 how about have an "unscoped" client? 18:42:06 essentially let's try to perform this operation in the normal way and if that didn't work it must be because we have an unscoped token so try again with the auth_url 18:42:17 jamielennox: i don't think your auth.AUTH_INTERFACE is going anywhere healthy either 18:42:18 rather than trying to support unscoped tokens in the regular client lib 18:42:47 bknudson: i think that might be what generic was originally for 18:43:12 jamielennox, the logic could also be "if there is no service catalog, generate one from the auth url" 18:43:24 jamielennox: it seems the auth plugin should be able to work with an auth_url to generate an unscoped token; it never needs any other endpoint. similarly the session never needs the auth_url, just scoped catalogs 18:43:25 ayoung: that's what the AUTH_INTERFACE is 18:43:32 with auth_url becoming an implicit admin interface 18:43:42 something is crossing boundaries here, but i'm lost as to what it is 18:43:46 jamielennox, I know, I've been using that ccode for the last ...well since you wrote it 18:43:57 ayoung: auth_url is NOT an "admin" interface. at all. 18:44:11 dolphm, once you have an unscoped token, where can you use it? 18:44:16 ayoung: the auth_url 18:44:48 ayoung: you haven't finished the full authN/Z flow yet - so you're still confined to the auth_url. 18:44:49 dolphm: the only way i can see that working is that auth plugins should be different for scoped and unscoped tokens 18:45:35 as in all tokens that accept a credential should only be scoped and then there is only 1 way to rescope 18:45:49 only be unscoped 18:45:52 jamielennox: let me back track on myself; i do think the session should be aware of the auth_url so that it can handle rescoping as necessary - agree? 18:46:18 dolphm: no, why would the session want to know auth_url - that's plugin specific 18:46:33 you can have 1:M session:plugin 18:46:40 jamielennox: i see the circle we're in now :) 18:48:05 jamielennox: can we pick this up after the meeting? 18:48:11 dolphm: sure 18:48:34 #topic JSON-Home progress 18:48:35 bknudson: o/ 18:48:40 #link https://review.openstack.org/#/c/103983/ 18:48:48 just wanted to mention that it essentially works, for v3 18:48:53 so if you want to try it 18:48:54 bknudson: this must be your biggest patch ever? 18:49:04 curl -H "Accept: application/json-home" http://localhost:5000/v3 | python -mjson.tool 18:49:15 it's mostly data 18:49:26 also, there's a lot of duplication 18:49:40 removing the duplication will be quite a bit of work 18:49:55 because it will essentially mean going up a level of abstraction in the routers... 18:50:05 if anyone is interested, i just checked it out and called it: http://pasteraw.com/4ozb5otuj2bjf9tcvok9q8uolqa2qhh 18:50:14 * topol pretty sure bknudson can handle refactoring :-) 18:50:40 where the routers are doing mapping.add_route they should be doing some kind of self._add_resource() that has more info. 18:50:53 so, that was about it. 18:51:00 thinking about how to rewrite the clients to use it... 18:51:08 bknudson: COOL. 18:51:11 bknudson: yea that's tough 18:51:15 thats cool to see 18:51:25 essentially the client would have to fetch the json-home doc, then they'd be able to get the URL from JSON-Home 18:51:29 rather than building the URL themselves 18:51:42 bknudson: i see a couple bugs :P 18:51:44 bknudson, that makes sense from a workflow 18:51:57 but yeah it's got some oddities 18:52:25 ok. early feedback would be nice. 18:52:36 bknudson: can json-home handle the standard /v2 or /v3 discovery we do now? 18:52:42 jamielennox: yes... 18:52:51 I've only got it for /v3 18:52:51 is /v3/role_assignments/{role_assignment_id} actually a thing ?! 18:53:13 but essentially GET / would return all v2 and v3 resources 18:53:19 that's totally not documented if so, and role_assignments should not have IDs 18:53:19 bknudson, V3ExtensionRouter(ExtensionRouter): should be in keystone/routers, not in common/wsgi.py 18:53:31 v3 resources are like http://docs.openstack.org/identity/rel/v3/users 18:53:45 and v2 resources would be like http://docs.openstack.org/identity/rel/v2.0/users 18:53:45 bknudson: i don't know that we'd get much payoff from adding this to v2 18:54:09 Or is every router now becoming an V3ExtensionRouter.... 18:54:11 dolphm: it's so we would have to do vereion discovery lookup and then json-home lookup as well 18:54:11 dolphm: y, I think the payoff would be if we wanted to use this for "version discovery" 18:54:12 ayoung: V3ExtensionRouter belongs in wsgi imo 18:54:23 ayoung: it's wsgi framework code 18:54:38 s/would/wouldn't 18:55:06 I think all of the lookup/discovery stuff is starting to call for some sort of caching/bookmark story 18:55:07 bknudson: +1 for responding to json-home on / but do you need to provide *every* v2 resource there? 18:55:15 it means is it a change to discovery or a change to client 18:55:20 are we going to bother revving the v2 client to acknowledge all that data? 18:55:44 dolphm, do we need the v2 client to? 18:55:57 ayoung: discovery caches on the session and on the auth plugin 18:56:10 at least for the public interface there aren't many v2 resources 18:56:14 can we let the v2 client just kind of... do it's thing? 18:56:42 jamielennox, I'm not certain that will work for CLI and Horizon use cases, unless we have "persist and restore session to keyring" 18:56:45 yea, i don't mind if json-home doesn't say anything at all about v2 resources 18:56:57 just if /v2 and/or /v3 exist 18:57:07 well, it sounds like v2 isn't that interesting to people so I'll focus my time on cleaning up the current change 18:57:16 morganfainberg: IncompletePreposition: 'to' (i don't know what you're asking) 18:57:21 bknudson, does it work with extensions? 18:57:32 nm, I see it 18:57:33 gyee: yes, it works with extensions (the v3 work does) 18:57:36 ayoung: yea CLI is a problem, serializing the session and auth plugins is something i've known about but haven't been asked for yet 18:57:47 dolphm, bother acknowledging the json-home stuff 18:57:52 bknudson: +++ 18:58:34 ok, thanks for the feedback. 18:58:58 jamielennox, I think I am going to be hitting that in Horizon here shortly. People are using the tokenid as the session persistance. But if there is discovery that went on, we'll want that remembered, too. And not every Horizon session should have to do the full discovery dance 18:59:31 hrm we're out of time with two things left on the agenda 18:59:52 continue in #openstack-keystone 19:00:15 actually, is there an infra meeting today? or can we run long? jeblair? mordred? 19:00:59 dolphm, there is also OSCON stuff going on 19:01:38 dolphm: go for it 19:01:40 do we stay here or hop? 19:01:55 jeblair: are you having a meeting today? 19:01:57 alright. stay until we get bumped and glared at :-) 19:02:06 k :) 19:02:20 jeblair: if we run long it'll be like 20 minutes 19:02:33 jeblair: or we can just switch to -keystone 19:02:36 gyee: would X.509 client cert auth benefit from a mapping? 19:02:41 we have our own channel... why grovel for breadcrumbs?? 19:02:53 bknudson, it could 19:02:54 lol 19:03:05 but we don't have the plumbing in place for that kind of stuff yet 19:03:14 ideally, everyting should go through mapping 19:03:16 I like federation then 19:03:18 keystone is no longer living in a van by the river 19:03:29 topol, shhh don't tell anyone 19:03:30 #topic X.509 SSL Client Certificate Authn 19:03:31 :P 19:03:43 we'll need to make significant changes to the federation plumbing to make that happen 19:03:53 right now it only works for saml2 19:03:55 significant? 19:03:59 yes 19:04:01 hopefully those changes to the plumbing will make it more flexible 19:04:16 I think this is what we wanted from the beginning. 19:04:18 how does it change from the current 'map this httpd header to this attribute' 19:04:34 and i agree anything it doesn't currently cover it should 19:05:08 gyee: i think it will be less work than you think and there is already movement toward making it more generic 19:05:40 yes, I think we can make it generic 19:05:50 only question is time and effort 19:05:56 I'd like to know what is happening towards this :) 19:06:13 gyee: btw the spec looks great 19:06:17 1) change federation plugin to make it generic 19:06:23 https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L242 19:06:34 so i guess the interesting part of this would be how does it fit in with /identity_providers/{idp}/protocols/{protocol} ? 19:06:37 2) change the saml2 plugin to make it generic 19:06:45 3) make token issuance a pipeline 19:07:17 jamielennox, it would be an x.509 provider 19:07:18 there is a code review somewhere to rename saml2 to something else - it really isn't saml2 specific IIRC 19:07:32 if federation was used then would you have to use an apache module? 19:07:48 bknudson, yes 19:07:50 https://review.openstack.org/#/c/104301/ 19:07:51 gyee: but it doesn't map to an idp id was my though 19:08:06 you still need apache to do the heavy lifting in validating and parsing the cert 19:08:06 bknudson: you wouldn't have to because the vars are pulled from the environment 19:08:46 does it work through an SSL terminator? 19:08:48 kwss: can you take the term 'reegineered' out of that spec? it scares people and it's so vague that any spec could be prefixed by 'reegineered-*' 19:08:50 dstanek: apache is still needed to populate those environments though 19:09:15 dolphm, sure, what do you think it should be changed to? 19:09:36 jamielennox: using federation does not require it though - you may need an apache module for a specific protocol though 19:09:42 kwss: something specific and succinct that describes the problem 19:09:45 bknudson, i don't think it would work through an SSL terminator 19:09:59 bknudson, SSL has to be terminated at Apache 19:10:23 dolphm, something like generic-federation-plugin? 19:10:38 kwss: that's a step better 19:10:50 standard-mapping 19:11:02 so we all agree to kill the x.509 cert auth plugin in favor of a generic federation layer? 19:11:18 or do the plugin now and then work on generic federation? 19:11:45 gyee: I prefer federation 19:12:07 gyee: i think that's the right path 19:12:08 with federation, we can get rid all the remote user auth plugins too 19:12:28 external auth can also use the same framework 19:12:32 bknudson, I agree, as it then ties in with adding keystone-to-keystone, open idc etc 19:13:13 gyee: so is there still a "support X.509" or is it just "make federation more generic" 19:13:24 bknudson: ++ 19:13:54 bknudson, we still need x.509 19:14:17 ok, just wondering if x.509 needed something in addition to generic federation 19:14:19 but now it has a dependency on making federation more generic 19:14:41 instead of a standalone plugin 19:15:09 gyee: i'm lost on how x509 support is not a plugin either way? 19:15:30 dolphm, with generic federation, it would become an identity provider 19:15:56 saml2 auth plugin will be part of the token pipeline 19:16:53 only problem is making generic federation work, we are probably looking at K and beyond 19:17:17 gyee: do you know what doesn't work? 19:17:22 since the changes are quite significant 19:17:27 we seem to have a lot of people interested in it 19:17:38 gyee: ^ does a spec exist that describes the gaps your looking at? 19:17:46 you're* 19:18:03 dolphm, I think David and kwss have a spec 19:18:11 kwss, you have the url? 19:18:42 It's this one, but I think it still needs work https://review.openstack.org/#/c/104301/ 19:19:31 Can I rename a spec or do I need to make a fresh one? 19:19:40 kwss: iterate on this one 19:19:49 when we talked about this at the hackathon i got the impression that it really wasn't that bad 19:20:16 dstanek, you mean the refactoring part? 19:20:23 dstanek: kwss's spec is fairly straight forward 19:20:38 gyee: making the mechanism more generic 19:20:45 dstanek, I thought it was just a case of renaming the saml2 plugin to something generic and calling the correct code to manage extraction of assertion data 19:20:55