18:02:47 #startmeeting keystone 18:02:48 Meeting started Tue Nov 26 18:02:47 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:51 The meeting name has been set to 'keystone' 18:02:52 #topic icehouse-m1 18:02:54 is next week! 18:03:05 our list of BP's is very short 18:03:07 so soon! 18:03:12 M1 always catches people by surprise 18:03:29 i bumped quotas to m2 recently, as warranted by the additional discussions at the summit 18:03:31 ayoung, no one expects M1 (eh, it's missing something) 18:03:34 ayoung: ++ 18:03:53 #link https://launchpad.net/keystone/+milestone/icehouse-1 18:04:12 dstanek is working on two other bp's that i'm hoping to have merged this week 18:04:22 i think updates are in progress for both, but: 18:04:23 #link https://review.openstack.org/#/c/50491/ 18:04:28 #link https://review.openstack.org/#/c/52456/ 18:04:39 ayoung: danke 18:04:51 Code review or implemented for all. 18:04:55 if there are any other blueprints that should be targeting m1 - speak up! 18:05:03 KDS? 18:05:05 Heh 18:05:13 seriously, though, it should have been 18:05:37 that mailing list discussion is very indecisive -- i thought we had a firm direction on that early last week 18:05:39 yes, well KDS doesn't look like it did at the end of H 18:05:50 now it should be in barbican and in keystone and it's own standalone service 18:06:09 dolphm, the decision i'm hearing is, in keystone, move to it's own thing or barbican later 18:06:17 I'm still a little confused about KDS -- PKI is no good, but you're going to need PKI anyways for SSL. 18:06:24 dolphm, otherwise you need to use a non-integrated project to secure messaging 18:06:25 so my understanding is we are going with keystone extension - ? 18:06:38 dolphm, and separate wSGI/port 18:06:50 i disagree on the seperate port 18:06:56 or at least i don't see any reason for it 18:07:10 morganfainberg: then it might as well be based on falcon or pecan/wsme 18:07:14 jamielennox, isolation since it'll move out of keystone 18:07:28 jamielennox and I discussed this. 18:07:29 shouldn't need a separate port... that's what resource paths are for. 18:07:37 but it's still going to have to live in keystone/contrib anyway 18:07:37 dolphm, i guess the last part, port/wsgi is not needed. 18:07:42 I suggested a separate port to facilitate splitting it of completely 18:07:44 bknudson: ayoung wants it to be a standalone service 18:07:49 if its an *internal* service, why does it matter where you stash it as anything internal is subject to change 18:07:58 I thought ayoung wanted everything in httpd? 18:08:00 dolphm, still do...but we have committments to meet 18:08:22 bknudson, this is tactical, not strategic. I don;t want KDS in Keystone long term 18:08:22 if the config file is point to the base_url for KDS then it should make no difference if it is KDS=http://localhost:5000/v3/OS-EXT-KDS/v1 or KDS=http://localhost:8888/v1 18:08:29 so, short answer, it looks like it should be in keystone until it can be split. - and i'm fine with that. 18:08:35 bknudson: so, supported and reviewed by keystone-core, but a completely separate standalone service that has nothing to do with identity 18:08:40 and I sort of agree with jamielennox on his point 18:08:42 that means it's own catalog entry, etc 18:09:03 before dolphm and ayoung's patch to port it various place i had mostly done a port to it's own service based on pecan/wsme 18:09:04 it's a good idea to have a catalog entry if it's going to move. 18:09:07 but still think we will have less trouble splitting it if we get people starting from KDS root instead of auth_url... 18:09:14 ayoung, dolphm, i think it needs to be in the catalog and be discoverable. 18:09:20 jamielennox: is that in review somewhere? 18:09:21 morganfainberg, hells not 18:09:26 i was hoping that i could just drop it in as an extension using wsme and pecan in a way that it is easily extractable 18:09:26 no no no no no 18:09:28 ayoung, discoverable at least. 18:09:29 dolphm: not finished 18:09:29 NO! 18:09:37 morganfainberg, not our job to do that 18:09:40 no KDS should not be in the servcie catalog 18:09:56 you are lifting up the side of the tent and inviting the camel in 18:09:58 ayoung: you're asking for it to be a separate service, but you don't want it to be discoverable? 18:09:59 ayoung, so hard set uri? 18:10:15 sop many things need to be discoverable in the undercloud....but it is not for us to say how that is to be done 18:10:29 bauzas: I live in NZ - UTC+13 18:10:38 s/undercloud/meaningful language/g 18:10:40 dolphm, it is no different than compute figuring out where the RPC server/message broker is. 18:11:02 dolphm, in the triple-o sense, the management layer (e.g. nova processes themselves) 18:11:26 keystone service, not to be confused by something an end-user would access/consume to make an instance/project/etc 18:11:27 morganfainberg: oh man, so thats not the tripleo sense :) 18:11:37 dolphm, undercloud has come to be a useful term...out of tripleO to distinguish between the services exposed to end users vs those that are Internal to the OS deployment. 18:11:38 the undercloud is the openstack infrastructure deploying cloud. 18:11:40 dolphm: KDS is going to be similar to configuring MySQL or AMPQ. It is not a service that is used at a client level 18:11:44 lifeless, ok ok fine, in the not-so-triple-o-sense 18:12:08 lifeless, in the. not public consumption sense. 18:12:11 lifeless: ++ 18:12:12 I think there's a DBaaS project. 18:12:26 so my suggesting: use jamielennox 's pecan approach, but kick it off from keystone-all 18:12:34 https://wiki.openstack.org/wiki/Trove 18:12:41 suggestion 18:13:00 ayoung: why do you want it to be started by keystone-all? why not just bin/keydist or something? 18:13:00 ayoung: in the same process or using a different port? 18:13:04 you can nest wsgi applications, so there should be no reason that the pecan/wsme app can't live and run as an extension 18:13:04 I don't have a problem with it as a different service. 18:13:08 bknudson, that is for end user consumption...just like Barbican was supposed to be. 18:13:19 if it's a separate service, keystone-all seems like the wrong place to start it. 18:13:26 morganfainberg: ++ 18:13:28 morganfainberg: a key (har har) thing to note is that the nova cloud we deploy - the overcloud - can only use public services from the undercloud (e.g. heat) - so if KDS was 'within the cloud only' we'd deploy one KDS per overcloud. 18:13:33 morganfainberg + 18:13:36 shouldn't call it keystone-all if it doesn't start everything 18:13:42 morganfainberg: rather than one in the undercloud and use it from the overcloud 18:13:44 morganfainberg: i'd rather get as much of the separation correct from the beginning 18:13:45 change it to keystone-some 18:13:47 bknudson, but KDS isn't... keystone really. 18:13:53 bknudson: but it's not keystone-* 18:13:58 dolphm, ++ 18:14:18 lifeless, as stated above, KDS would be like ZMQ or AMQ 18:14:21 so a new bin/kds ? 18:14:35 dolphm, you know what, that works too. not keystone-all, but kdsd or something works for me 18:14:45 * mordred lurking, reading through scrollback - I hear we're talking about fun things 18:15:36 bknudson: yeah 18:15:47 so what i'm hearing so far is new start script in bin and new service on a new port 18:15:47 I don't have a problem with a separate bin... seems like an impl detail. 18:15:49 is that right? 18:15:49 jamielennox, would bin/kdsd make more sense? And then not an extension? 18:15:58 dstanek: ++ 18:16:20 ayoung: i'm still advocating the extension makes more sense, but if the consensus is new service then so be it 18:16:29 i just want the consensus part 18:16:38 jamielennox: why do you think it makes more sense? 18:16:41 what's the port for kds? 18:16:54 #agreed kds to have it's own bin/* startup script to run on it's own port 18:17:08 (default port) 18:17:27 dstanek: the reason for it being a new service is purely so it is easily extractable later - i don't think that this makes any sense as we can already nest all the kds info into the extension 18:17:33 and this is what extensions are for 18:17:34 239297 18:17:37 jamielennox, new service, with an eye to completely extracting it from the keystone code base. 18:17:45 bknudson, port 88 18:17:51 bknudson: random(1025, 32767) 18:18:05 dolphm: I would like to come to a conclusion with the OS-SHARED-SECRET, please. It has been around for too long ... 18:18:07 * ayoung waits for you all to look in /etc/services for port 88 18:18:16 fabiog: it's on the agenda 18:18:33 fabiog: kds has been around far longer :) 18:18:35 dolphm: thanks, just checking we will have time for it ... 18:18:46 so out of interest where does a new service in keystone live (code wise) 18:18:58 top level? keystone/kds 18:19:01 jamielennox, there was some talk of a new repo 18:19:06 jamielennox, we can leave it in contrib for now 18:19:11 morganfainberg: can't happen for now 18:19:15 but contrib is the right place 18:19:24 jamielennox: sure -- it'd be nice if it didn't import anything from outside keystone.kds though :) 18:19:39 jamielennox: you could also isolate it's testing infrastructure -- keystone.tests.kds.* 18:19:47 dolphm, it just uses some keystone.common which should be acceptable 18:19:48 is there going to be a kds-manage ? 18:19:48 dolphm: well, maybe keystone.openstack.common 18:19:52 ayoung: ++ :) 18:19:53 ayoung: -- 18:19:56 dolphm: yep that was the idea - openstack.common was the only one i had to share 18:20:00 to create the db tables. 18:20:01 mordred: ++ 18:20:06 bknudson, so far, no. If we need it, then we will add it. 18:20:18 jamielennox: cool 18:20:21 tests in kds.tests should work too 18:20:28 jamielennox: make it as easy as possible to move to a top level project 18:20:32 shoudl be found by test discovery - doesn't matter - we do that in horizon 18:20:45 jamielennox: or if barbican is the correct home for it, base it on falcon... 18:20:55 We have a plan? Itsounds like we have a plan. 18:21:01 only thing that can be split split is distribution targets - only one setup.py/tarball output 18:21:08 mordred: that works for me keystone.kds.tests 18:21:12 don't base anyhting on falcon please 18:21:13 dolphm: my understanding is that we can mix pecan/wsme and keystone - but falcon is a framework as well 18:21:22 mordred, pecan/wsme? 18:21:25 please 18:21:29 sorry, falcon is a server as well 18:21:29 mordred, ok 18:21:34 mordred: fine by me 18:21:35 we've got to stop having framework wars around here 18:21:40 cause eek 18:21:58 I thought Barbican was a project, and Cloud Keep was a program. Did that change? KDS should stay its own project 18:21:59 mordred: pecan/wsme is more tempting to me for keystone, long term 18:22:09 mordred, lets make our own framework, that is subtly different and standardize on that /s (xkcd ref in here somewhewre) 18:22:09 ayoung: that's still the case 18:22:17 It can be under the CLoudKeep program then, when it spins up 18:22:20 morganfainberg: YES! do that 18:22:37 morganfainberg: is that not keystone.common.wsgi lol? 18:22:43 (programs usually have descriptive names. /me stop trolling) 18:22:45 dolphm, oh no, we need something new! 18:23:06 morganfainberg: oh right! keystone.common.superwsgi 18:23:15 dolphm, *stops being snarky / off topic* 18:23:34 jamielennox, do you have enough to execute off of here? 18:23:36 jamielennox: so, what milestone are we looking at :) 18:23:56 jamielennox: m2? possible for nova to consume by m3? 18:23:58 kds looks like a lot of work 18:23:59 dolphm: well it's not m1 18:24:04 lots of code 18:24:06 m2 should be fine 18:24:22 jamielennox, m2 would be _very_ good 18:24:37 I just hope it doesn't get dumped on us in one big review. 18:24:50 bknudson: 1 for framework, 1 for host keys, 1 for group keys 18:24:52 jamielennox: do you have a link to the bp for kds? 18:24:54 bknudson: +1 18:24:56 i can't find it... 18:24:57 We have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS 18:25:08 ayoung, ++ nice. 18:25:26 ayoung, hopefully it isn't too much work to get it into shape 18:25:29 morganfainberg, he's the Manager for Dogtag, and has a strong crypto background. 18:25:31 ayoung: thank you! 18:25:37 jamielennox: 6 for framework, 8 for host keys, 4 for group keys. 18:25:37 ayoung: hi all 18:25:39 ayoung, woot! 18:25:46 nkinder, yay! 18:25:49 nkinder, was just saying... 18:25:53 We have nkinder from RH engaged as well. He is going to take a swipe at the API doc for KDS 18:25:56 alright, let's move on 18:25:59 bknudson: takes me long enough to get my regular reviews past 18:26:05 jamielennox: poke me with the bp link if you have it 18:26:08 jamielennox: because they're too big! 18:26:14 dolphm: this is the oslo one: https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging 18:26:14 Yep. It's on my list for the thanksgiving break 18:26:31 nkinder, very awesome. and thanks! 18:26:47 I'm curious to know how much belongs in the API doc vs. Keystone docs? 18:26:50 maybe there isn't one for keystone... /me inheritted a lot of this 18:26:56 #link https://blueprints.launchpad.net/keystone/+spec/key-distribution-server 18:27:01 Some of this is really implementation behind the API 18:27:15 nkinder: implementation doesn't belong in api doc. 18:27:43 if you use wsme, you auto generate the docs? 18:27:50 #topic Password rotation 18:27:51 nkinder, https://review.openstack.org/#/c/40692/ is the original api doc 18:28:03 nkinder, we were thinking more along the lines of "how would an end user actuall consume this, and what would they expect" 18:28:06 nkinder, if that helps. 18:28:11 fabiog: o/ 18:28:18 OK, so multiple shared secrets is bad 18:28:30 ayoung, is a business use case 18:28:32 but useful 18:28:35 I've been reviewing, discussing, and stick to my guns on this one. 18:28:41 gyee, then do it outside of Keystone 18:28:48 or use the exsitng abstractions differently 18:28:53 ayoung, services needs to integrate with it 18:29:02 gyee, no they don 18:29:03 t 18:29:08 its been propose as *an extension* 18:29:14 proposed 18:29:18 gyee, no 18:29:25 it is an end run around security 18:29:26 gyee: you can always publish extensions out of tree 18:29:32 ayoung: and it is using the same concept as EC2, that is already there 18:29:32 do it outside of Keystone altogether if you like 18:29:41 and fork the keystone protocol 18:30:05 it's a lot of work to maintain something out of tree... 18:30:13 this is no different than KDS, Trust, or OAUTH 18:30:14 bknudson: +1 18:30:16 especially since we have no guarantee of internal API stability 18:30:22 why is this an exception? 18:30:24 bknudson + 18:30:26 bknudson: it's a lot of work for keystone-core to maintain features that aren't consumed by openstack as well 18:30:56 fabiog, MarkAtwood, really quickly, you want to avoid using the current credential implementation? it seems to already hit the mark, just without the "password" mechanism directly 18:30:57 dolphm, CI/CD and other service are waiting to integrate, so I heard 18:31:27 monty, would CI use it if it was in? 18:31:28 the list of potential security concerns with multiple passwords/symetric shared secretes far outweighs the benefits. 18:31:51 outweigh 18:31:57 ayoung, what security concern? the risk is no different that passwords 18:32:25 did you read my responses in the review? 18:32:30 gyee, it multiplies the issues with passwrods, and adds in the "oh, I disabled this one, but that one is still active" 18:32:36 ayoung: that seems very backwards to me - do you have reasoning? 18:32:42 google does it, amazon does it, fb auth does it 18:32:42 one could use an ldap server that supported multiple passwords. 18:32:42 not sure if there are any, but if you had your own ldap implementation... 18:32:46 ayoung, you disable a user, not a password 18:32:47 morganfainberg: we need an auth method to leverage the current credential API 18:32:59 wait - can someone talk to me very shortly like I'm a moron? 18:33:05 gyee + 18:33:12 gyee: users aren't much more than passwords anyway :) 18:33:13 is this about the rackspace extension that's not compatible with anything ? 18:33:21 we stoped using that in infra 18:33:28 because it's not in keystone for real 18:33:31 mordred, no its about the one that hpcloud is running 18:33:37 we don't use that either 18:33:37 dolphm, points is once you disabled a user, all his credentials are effectively disabled 18:33:45 is hpcloud using this already? 18:33:45 easy to contain the risk 18:33:50 if it was in keystone, would you use it? 18:33:51 gyee, right now, the "user" object is really an ID and a password. There is nothing more to it. The same thing that you were trying to do with multiple shared secrets can be done with multiple user accounts. Yes, it complicates external systems mapping one external acount to Keystone, but that is not a keystone issue. 18:33:51 mordred, no. this would be to be able to rotate passwords without eliminating access until it is explicitly revoked 18:33:52 can anyone explain to me, in very simple terms, why haivng an api key is better than having a password? 18:33:55 bknudson 18:34:04 yes we are, we want to give this work to the community 18:34:09 I see no benefit to contributing to the mess that is the Keystone password system already 18:34:10 when the password gives me access to muck with api keys? 18:34:17 basically ALL of our industrial users are using the feature 18:34:31 ayoung: agree - the only downside (at minimum) is having to manage group membership to apply authorization 18:34:34 mordred, that is the crux of the argument, but in short the argument is to allow access w/o having to change all systems that use that password at once (rolling auth change) 18:34:49 seems like if it's been implemented somewhere already for some time and have found it useful then that's a good candidate to go into keystone proper. 18:34:51 mordred: as i understand it the main benefit would be allowing different api keys on for example different nova hosts but still sharing the same service user 18:34:57 ayoung: multiple 'passwords' per user ID avoids the re-assignment problem 18:34:58 i don't think this is about rotation yet 18:35:04 dolphm, and, if they use external auth, the logic that they want can be done, without adding anything to keystone 18:35:04 our users assign a different "application password" to each app or subsystem 18:35:07 ok. I can see why people might want that 18:35:18 well, some of your users do 18:35:24 some of us just use the one password 18:35:26 and then can track which ones are being used, and can disable indivual ones, and set expirations for them 18:35:27 mordred, jamielennox, rotation is part-in-parcel of this but it is a side effect. 18:35:42 morganfainberg: yea, it allows rotation but it's a side effect 18:35:47 what MarkAtwood just described ^ 18:35:51 So if you want multiple passwords, go for it, but use basic-auth and external, and then map from the credential to the user id in an auth plugin 18:36:19 ayoung, can you explain basic-auth to me and "external" 18:36:35 MarkAtwood, means using Apache :) 18:36:41 or Nginx 18:36:42 http basic auth cannot be trusted to go through SSL accelerations and load balancers 18:36:43 gyee, or even in Keystone 18:36:47 doesn't seem like any clients actually support using basic-auth. 18:36:50 ayoung: I would like for our public clouds to stop having divergent auth methods 18:37:00 ayoung: because that's the first thing people interact with 18:37:01 MarkAtwood, basic auth is the HTTP mechanism for userid and password 18:37:07 bknudson, nope, not right now 18:37:10 I have a proof of concept...one sec 18:37:11 and if you have to do something 'special' that's not discoverable 18:37:14 MarkAtwood: interesting, i've never thought about that 18:37:19 ayoung, it doesnt work. i have been down this path when writing OAuth 18:37:20 to conenect to rackspace and to connect to hp 18:37:32 then we're not interoperable 18:37:35 and all of openstack dies 18:37:47 this is the reason I'm so generally pissed off about the rackspace auth extension 18:37:56 https://github.com/admiyo/keystone/commit/2f5243d779c39f8f5ed2df128e68090df440012f 18:37:59 because it's TECHNICALLY a legal auth extension 18:37:59 basic auth looks great, excpe that load balancers mangle it, transparent proxys mangle it, ssl accelerators mangle it, and apache does not pass it down to the app 18:38:15 but it changes the user experience in ways they have to know more than "this is an openstack cloud" 18:38:41 so if this is an issue that we know is going to make all of our public clouds diverge from what openstack is - I think that's a Really Bad Thing 18:38:41 mordred: I hope that doesn't mean we're stuck with least-common-denominator (user+password) 18:38:43 THAT SAID 18:38:51 mordred, we can propose it a core if makes you a happier man :) 18:38:51 mordred: ++ 18:38:52 hp's fallback is to stop this merge effort and put it under the HPAPI: extenstion, which just makes it worse 18:38:53 the public clouds should have more devs working on keystone 18:39:01 core API I mean 18:39:14 mordred: working on it! 18:39:23 mordred: working on it! 18:39:25 :) 18:39:31 so - I'm a bit more than pissed off at the fac that we have companies in here trying to throw weight behing "we're a big company, listen to us" 18:39:41 MarkAtwood, you know what, you just argued against doing anything with standard HTTP. 18:39:52 ayoung yes i know i did. and it sucks 18:40:02 i was on your side of this argument 6 years ago 18:40:04 I realize Apache does not pass it down to the app, but Apache can handle basic auth for you already 18:40:12 so that one gets passed through as REMOTE_USER 18:40:16 not all of use run Apache 18:40:34 MarkAtwood: i have not seen the issues your talking about with basic-auth 18:40:37 do you really want to make the web server daemon a dependency 18:40:43 MarkAtwood, absolutelty 18:40:55 dstanek, i've seen those issues with some SSL accelerators and LB systems 18:41:10 dstanek, they do a lot of mangling at the larger scale implementations ot get their job done 18:41:12 a web server is better at serving web responses than our basic keystone impl will be. 18:41:14 morganfainberg: do they remove the headers? 18:41:18 dstanek, they can. 18:41:23 and REMOTE_USER doesnt work when you're running apache as a proxy 18:41:26 dstanek, depends on the LB etc 18:41:42 morganfainberg: that sucks, sounds like broken gear 18:41:45 dstanek, and reverse proxying does lots of odd stuff. 18:42:03 MarkAtwood: i'm in favor of leveraging what we can, and i have yet to see *any* specific pushback against requiring httpd 18:42:06 dstanek, not so much broken, but configured as such because it's needed to leverage the farm behind it. 18:42:33 morganfainberg: broken in that they are violating the HTTP protocol right? 18:42:48 dstanek, its not even a violation of protocol 18:42:52 so - is the opposition to the mutliple token thing 18:42:54 dstanek, headers dont have to be passed on. etc. 18:42:59 the w3c have beeen rank cowards about it 18:43:00 the implementaion of managing the tokens? 18:43:08 or being able to expose the consumption one in the protocol? 18:43:15 s/one/of one/ 18:43:17 mordred, multiple tokens? Or multiple passwords? 18:43:23 if we are using external auth it means accounts are managed outside of Keystone 18:43:24 ayoung: passwords 18:43:29 mordred, correct inverse, mutiple passwords any one of them can issue the same token. 18:43:56 gyee: do you have a review or bp i can look at? 18:43:58 same token in this context = same roles/etc in the data (not physically the exact same token) 18:44:00 mordred, my feeling is that Keystone should never have been attempting to manage passwords in the first place, and we should not attempt to increase its scope. 18:44:08 ayoung: honestly, the thing I care about is that there is a consistent user-facing api to access this stuff for cloud consumers - if HP and rax each do a plugin to deal with multi-passsword-mapping-to-user on the admin side, I dont care 18:44:23 dstanek, https://review.openstack.org/#/c/46771/ 18:44:24 ayoung: well, thing is - it's an interface to the exstence of passwords 18:44:30 whether it manages them itself or not 18:44:34 #link https://review.openstack.org/#/c/46771/ 18:44:51 I mean, the system that actually owns the passwords at HP is not keystone, it's something else - but keystone is the thing that the user talks to 18:45:01 mordred and the use case they are asking for could be done in the existing mechanisms 18:45:04 I imagine at many private clouds it's AD or LDAP that owns the passwords 18:45:16 mordred, or even a pre-existing SQL database 18:45:17 mordred, one challenge comes from IdP (identity provider such as ldap) and now having passwords that are indepenant/managed separately from it. you're no longer relying on the IdP for AuthN 18:45:26 gyee: thanks, i should have linked that at the top 18:45:29 that does not map to what SQLAlchemy in Keystone expectes or provides 18:45:48 does anyone use the idp for passwords at scale? 18:46:02 ayoung: by existing mechanism, you mean in the keystone protocol? or using specific things in an apache deployment choice 18:46:03 please take a look at the comments in detail in that review 18:46:03 i remember watching the rdo demo about how they dont either 18:46:10 * mordred trying to catch up on lots of tech details really quickly 18:46:33 alternatively, we can add the "expried_at" field for a password 18:46:43 ayoung: by your reasoning, all of this should be handled by an alternative password auth plugin, correct? 18:46:48 so a password is no longer valid after the upgrade 18:46:52 BTW, there are several other security professionals that have weighed in on that review. I'll leave it to you guys to read their feedback 18:47:13 we keep the passwords and appkeys in a seperate system because it's keep MUCH more secure against read and access than the IdP 18:47:24 ayoung, I've responded to the security professionals in that review 18:47:26 dolphm, I would not even feel comfortable agreeing to that 18:47:34 ayoung: why not? 18:47:45 MarkAtwood, that argues for a separate auth plugin, that just overloads the current password one. 18:47:50 MarkAtwood, simplest solution? 18:47:59 s/overloads/overrides 18:48:01 ayoung, you want to remove login shared secrets from keystone entirely? 18:48:07 dolphm, we can do it with the mapping piece from federation 18:48:19 MarkAtwood: that sounds sane to me - no? 18:48:35 the end user shouldn't need to tell keystone anything new about the tyep of password, no? 18:48:36 ayoung: i don't follow that at all? 18:48:52 ayoung: this is about keystone's idp, not delegated authorization 18:48:56 so would a compromise be to bump the role for installing a SHARED-SECRET to admin (or something new) so that it could be set up for use by services but not be user facing? 18:49:08 and we have agreed internally to maintain internal API stability for 1 cycle (to the best of our ability) so maintaining the plugin shouldn't be too onerous. 18:49:08 this is not about federation, it a simple case of password rotation for rolling upgrade 18:49:12 its useful for user facing 18:49:14 users use it 18:49:16 please don't make it any more complicated 18:49:19 jamielennox: that's entirely user facing 18:49:23 dolphm, I was saying that they could keep the passwords outside of Keystone using mod_auth_sql and then map REMOTE_USER to user_Id and get the same effect 18:49:30 that does not require an explicit plugin 18:49:33 jamielennox: that's just a question of "which" users 18:49:37 MarkAtwood: but where do users use it? and does that require protocol violations? 18:49:47 for normal auth 18:49:56 but that keeps it from being Keystone's problem, and uses a well tested mechanism. 18:50:04