18:00:53 #startmeeting keystone 18:00:54 Meeting started Tue Apr 23 18:00:53 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:56 didn't realize it was already time 18:00:57 The meeting name has been set to 'keystone' 18:01:03 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting 18:01:16 #topic High priority bugs or immediate issues? 18:01:39 DB access can't be atomic for LDAP 18:01:44 bug 1130676 is on the agenda 18:01:46 Launchpad bug 1130676 in keystone "DB accesses during user creation should be atomic" [Medium,In progress] https://launchpad.net/bugs/1130676 18:01:52 would make it easier to review if that was split up into smaller changes. 18:02:11 I think we should NACK it. 18:02:17 It sets expectations wrong 18:02:30 so we would think Dolph's way to have a TransactableDriverMixin is one way 18:02:56 rohitk, nope 18:03:03 but the approach which is in the review could be changed 18:03:05 rethink the approach 18:03:05 ? 18:03:16 rohitk, take it this way 18:03:24 assume you do not have a transactional back end 18:03:31 i agree with ayoung's review, but i think we ultimately need to figure out an approach to make potentially transactable operations transactable... so i'd rather it be a -1 on the current pass rather than a -2 for the whole concept 18:03:33 how do you write it to minimize risk? 18:03:52 Band-aid on a sucking chest wound. 18:04:10 We will never have transactions from the token backend, which is actually the more serious issue 18:04:10 We dont touch the other backends at all, and just make those changes for the SQL backend 18:04:31 I prefer only on sql backend, since that's the only one that's got acid. 18:04:43 rkanade: you ARE touching the other drivers 18:04:46 https://review.openstack.org/#/c/25517/4/keystone/identity/backends/ldap/core.py 18:04:47 rkanade, and we don't treat the SQL backend as a "higher class citizen" than the other backends 18:05:09 that gets us into trouble (see next bug) 18:05:21 Adding another layer between identity api and controller as suggested by Tushar Patil in the review, lots of rework there though 18:05:28 LDAP does have transactions... http://tools.ietf.org/html/rfc5805 18:05:41 some servers might support it 18:05:43 rohitk: that's probably the right approach though, and we can do it one small refactor as a time 18:06:02 don't assume servers have transactions 18:06:05 Yes, currently we are, for the next patch we dont touch any other backend other than SQL, and we add the TransactableSQLDriverMixin to the SQL Base class? 18:06:30 or you'll make the implementation unusable for lots of people 18:07:19 dolphm: agreed it seems like a design enhancement than a quick fix 18:07:26 rkanade: can you post that and we'll discuss then? no point in reviewing the current patch if it's already WIP 18:08:06 rohitk: this could be moved from a bug to a blueprint as well 18:08:18 dolphm: Yes, i can do that 18:08:20 bknudson, yeah...*might* 18:09:02 dolphm: sure, I think if we get the blueprint right we can get the code into havana early 18:09:04 cool, we also have bug 1168724 on the agenda 18:09:05 Launchpad bug 1168724 in devstack "Horizon log-in failure in grizzly with LDAP backend" [Undecided,New] https://launchpad.net/bugs/1168724 18:09:11 and bug 1168726 18:09:12 Launchpad bug 1168726 in keystone "default_domain_id breaks the ability to map keystone to ldap" [Undecided,In progress] https://launchpad.net/bugs/1168726 18:09:29 i've marked both as grizzly-backport-potential, but that's up to how complicated the fix is 18:09:36 so what is happening? 18:09:43 dolphm: both the bugs opened for the same issue for possible fix against devstack and keystone 18:09:56 i understand these were known issues going into the grizzly release 18:09:58 domains are an attribute on the LDAP objects, and if one is not specified, it should be filled in with the DEFAULT value 18:10:04 devstack one is easy. will submit patch today for review 18:10:06 is it that we need an actual Domain object? 18:10:10 ayoung: no 18:10:18 #action dolphm to doc bug 1168724 and bug 1168726 on release notes 18:10:18 I have made some code change 18:10:22 Launchpad bug 1168724 in devstack "Horizon log-in failure in grizzly with LDAP backend" [Undecided,New] https://launchpad.net/bugs/1168724 18:10:23 Launchpad bug 1168726 in keystone "default_domain_id breaks the ability to map keystone to ldap" [Undecided,In progress] https://launchpad.net/bugs/1168726 18:10:25 domains are attributes on which objects? 18:10:29 #link https://review.openstack.org/#/c/27364/1 18:10:51 Ryan_Lane, yeah...it seems the LDAP world is 50/50 split on that 18:11:00 ayoung: 50/50 split on what? 18:11:00 ayoung: that's the patch i created as fix 18:11:03 half want it as an attribute, half want it as a subtree 18:11:11 which attribute would be used? 18:11:27 I want to yank domains out of LDAP altogether...make it optional 18:11:34 spzala: basically our controllers assume all backends are "domain aware"….and the LDAP one is only half there 18:11:34 Ryan_Lane, brace yourself 18:11:35 and would it be mutli-valued? 18:11:56 unless you have some other plan for global grouos, please don't yank domains from ldap 18:12:05 BBusinessCategory 18:12:05 henrynash: thanks.. agree 18:12:08 hahahaha 18:12:11 you're kidding me, right? 18:12:19 is that even multi-valued? 18:12:30 Why would it need to be multi-valued? 18:12:41 a project can only exist in a single domain? 18:12:41 domain is a single value entity only 18:12:49 Ryan_Lane, correct 18:12:51 what if you want two projects with the same name? 18:12:52 however 18:12:52 I assume any attribute name chosen could be overridden with a config option 18:12:59 this is a bad idea 18:13:01 I suggest we divide this into two fixes 18:13:07 Ryan_Lane, project name does not need to be unique across domains 18:13:26 ayoung: agree.. that's what I believe. 18:13:31 a) Just fake up the default domain so v2 access works with LDAP 18:13:43 Ryan_Lane, you missed me ranting about this at the end of the last release and during the dev conf 18:13:46 b) Then get our correct domain implementation fired up and going 18:13:52 ayoung: how do you have the same project name in two domains if there is a single project ou? 18:14:08 henrynash: you can point v2 to *any* domain 18:14:30 there's really only a single sane way to do this IMO 18:14:32 Ryan_Lane, well, I am a propoentn of doing domains by subtree, but that is neither here nor there 18:14:49 We need to support both, I think 18:14:53 support both what? 18:14:54 and that didn't happen in Grizzly 18:15:01 both subtree and attribute 18:15:08 if you want it to be distinguished, use distinguished names :) 18:15:10 attribute isn't going to work 18:15:23 unless you want the project names to be globally unique 18:15:23 Ryan_Lane, not for you, but for others, it is 18:15:26 hence we need both 18:15:38 and that can be a security concern 18:15:44 henrynash: thanks. 18:15:49 dolphm: is that true? How do you do the "pointing"? 18:15:54 Ryan_Lane, agreed, 18:15:57 because then you can figure out the project names already in use in other domains 18:16:11 Ryan_Lane, yep 18:16:13 henrynash: keystone.conf default_domain_id 18:16:19 henrynash: it's 'default' by default 18:16:43 henrynash: db_sync will even use that value when creating the initial domain 18:16:44 supporting two ways of doing this and having one that's basically broken and insecure is probably a bad idea 18:17:02 Joe Savak wanted it if I recall 18:17:03 dolphm:: ahh, ok, see what you mean…that kind of pointing…. 18:17:06 henrynash: there's absolutely nothing special about that domain other than keystone.conf points to it for use by v2 18:17:11 topol, who was it that said they wanted the Attribute way to do domains during the LDAP discussion? 18:17:26 I think it was Joe 18:17:33 Savak 18:17:38 #link https://etherpad.openstack.org/havana-ldap-integration 18:17:50 so they wanted some attribute on all projects/users in a domain? like businessCategory=domain1 18:17:52 unfortunately he's not on to defend himself 18:18:00 It mapped to how they were doing domains 18:18:27 topol, I suspect that they will trip up on what Ryan_Lane just said about unique names 18:18:27 bknudson: is that a domain id or name or domain id == domain name in ldap anyway? 18:18:28 dolphm: sure…I guess it's just the the initial problem is that no default domain get's created, so it would at least let us get off to there races 18:18:30 dolphm, we do this traffic court style, if he's not here, we blame it on him :) 18:18:40 Heh 18:18:48 gyee: yay community 18:18:51 gyee, or in this case, we decide to break the approach he is depending on 18:19:43 So I want domains to be subtrees. And I actually don't want domains at all. I want this: 18:19:44 no matter how you guys go about this, someone's approach is getting broken 18:19:46 #link https://blueprints.launchpad.net/keystone/+spec/multiple-datastores 18:19:57 That is in support of the one backend per domain blueprint 18:19:59 ayoung: domains actually make sense to be stored in ldap 18:20:01 so what frustrating is domains don't seem to naturally fit in ldap yet folks want it there 18:20:02 dolphm: it could be a name or an id... if the id is a DN then you can set that as the base of the search and if the value is an ID or name you have to do a search to resolve it. 18:20:21 I don't see why domains don't fit 18:20:33 it fits perfectly well if you make it a hierarchy, which is naturally is 18:20:39 Ryan_Lane: that's why i'd like to see ldap support relegated to specialized authn/z plugins :) 18:20:59 and lookups 18:21:01 it already is a plugin ;) 18:21:01 maybe separate plugins? 18:21:09 supporting ldap as a first-class identity driver seems like overkill for almost everyone 18:21:25 40% of users use ldap 18:21:28 well we couldnt get consensus on that. and most read only ldaps have just users and groups of users. so adding domains is hacky 18:21:32 that responded to the survey 18:21:36 You can never have too much overkill. There is no overkill, there is only open fire and reload 18:21:38 but who wants to use the SQL identity driver? it's not perfect either 18:21:44 dolphm, yeah, supporting write LDAP is risk than reward 18:21:49 Ryan_Lane: what percent of that wants keystone to attempt full crud over ldap data? 18:21:50 read only ldap/ad integration is huge 18:22:03 I hate write ldap 18:22:07 dolphm: it depends on the level of CRUD 18:22:11 So...bringing this back on topic 18:22:23 do we have a quick fix rady for the actual bug? 18:22:24 * gyee is standing right behind topod on the hate write LDAP line 18:22:30 If not, please ping me when it is ready 18:22:30 topol 18:22:30 we had complaints here about the SQL identity driver because it doesn't lock out users after x attempts, and doesn't have password requirements (length, etc) 18:22:32 LDAP should only be used for things that can be reused 18:22:47 ayoung: i think this is on topic, supporting broadly different approaches to ldap would be best handled by smaller auth plugins 18:22:48 ayoung: https://review.openstack.org/#/c/27364/1 is something I did for a quick fix 18:22:53 https://review.openstack.org/#/c/27369/ 18:22:59 is for the devstack fix 18:23:02 yes, but we should have a reference driver 18:23:12 dolphm, true,. although talking through the summit items is at the end of the agenda 18:23:13 and it should be a sane one 18:24:08 spzala, we looked at doing something in the keystone manage code for LDAP in the past... 18:24:15 would be good it integrate it in there 18:24:33 ayoung: +1 18:24:38 also, btw, it's probably perfectly sane to just not implement any of the write functions 18:24:40 I think this is indeed related to authn/z….it's because we lump them together and just talk about "the backend" that we get ourselves into problems….we really should have different plugins (as we discused_ fro authz/n 18:24:42 I doubt people are using it 18:24:47 my dream is that we find a reference way to support domains in ldap, sahdev codes it up and we all move on with our lives to fun keystone work 18:24:53 ayoung: so make changes via keystone-manage script? 18:25:06 there's a really simple way to do domains in ldap 18:25:07 spzala, we did that for the membership issue, IIRC 18:25:20 Ryan_Lane, you had me at hello 18:25:23 Ryan_Lane, one subtree per domain? 18:25:33 ou=domains 18:25:41 cn=domainA 18:25:48 cn=projectA,cn=domainA 18:26:00 ayoung: if you can please provide me more info or pointer to the work.. that will be very helpful as I am not aware of the past work. 18:26:03 it's a natural tree hierarchy 18:26:06 spzala, will do 18:26:20 ayoung: thanks! 18:26:21 it fits the design of domains and keeps the exact same design we have for projects 18:26:21 Ryan_Lane: are users under projects or under domains? 18:26:27 both 18:26:33 under domains for global members 18:26:38 under projects for project members 18:26:46 under roles for role members 18:27:44 hell, you can have global roles by sticking organizationalRole entries under the domain as well 18:27:48 Ryan_Lane, can you work up a simple example for Sahdev to use as a design doc? 18:27:54 Does anybody have their corporate LDAP directory set up like that? 18:28:08 of course not 18:28:10 would love to have this documented in a blueprint, then coded, then *DONE* 18:28:19 but they don't have it set up like our previous designs either 18:28:24 people make new OUs and such for this 18:29:09 The number one feature for Havan is the automatic provisioning of Users from a centralized authentication store 18:29:22 via auth plugins 18:29:34 most LDAPs they wont let you change anything. so should I worry about Ryan_lanes proposed changes??? 18:29:34 you mean adding/deleting users and such? 18:29:35 Ryan_Lane: can you also please take a look at this ..would be great to have your feedback #link https://etherpad.openstack.org/keystone-ldap-domain-support 18:29:38 against a (most likely) non-ldap identity backend 18:29:47 topol: keystone wouldn't be changing anything 18:29:48 Ryan_Lane: just adding 18:30:08 Ryan_Lane: well, maybe i take that back 18:30:27 maybe phase 2 18:30:30 dolphm: so, this is doable… but keystone's way of handling this is… ugh 18:30:38 Ryan_Lane: how so? 18:30:38 well keystone will work with a read only ldap as is and then you can do whatever you want that makes most sense for read-write ldap (the 2% use case) 18:30:48 currently it writes entries with their UUID as the naming attribute 18:30:49 Ryan_Lane: there is a design doc link, something we talked couple weeks back in IRC meeting. 18:31:05 yes, that sucks 18:31:18 do we need uuids to integrate with other backends? 18:31:24 so unreadable. 18:31:31 topol: if the number is really 2% then it shouldn't be supported by keystone out of the box.. 18:31:32 the UUIDs are needed to allow easy renames 18:31:44 having the uuids isn't a problem 18:31:54 dolphm, Im having a hard time arguing with you on this 18:32:04 *shrug* i'm not trying very hard 18:32:15 i figure we are close enough to a ref implementation to be done and move on 18:32:20 the entry has two unique fields anyway, the uuid and the user/project/domain/etc field 18:32:36 dolphm, cause I agree with you 18:32:41 so, you use the name for the naming attribute and add the uuid as a second value of the multi-value attribute 18:33:06 OK. We've spent half the time allotted on this. Lets get an #action work up the Blueprint for this. 18:33:16 I'll write up a DIT example for domains 18:33:27 spzala, you want to take point, and include Ryan_Lane 's document as a reference? 18:33:39 I can also write up an example of how to properly handle adding entries without using uuid as naming attribute 18:33:40 we really must focus on the common use cases…and R/W LDAP is unlikely to be it 18:33:46 ayoung, yes 18:33:59 I'd say prioritize getting read working well, then worry about R/W after 18:34:00 Ryan_lane and Sahdev should collaborate and come to joint consensus 18:34:16 how about we solve the common case when we have an enterprise ldap with users for authn…and this generates temp user records in our SQL authz backend 18:34:31 henrynash, that is what I said above 18:34:34 autoprovisiniong 18:34:42 I'm with you 18:34:47 the Kent folks aren't here 18:34:47 so… that's a cache... 18:34:48 now henrynash is mentioning somehting we really need. and repeating ayoung 18:34:51 but they have an impl 18:35:02 and it's fine, assuming you're going to invalidate the cache properly 18:35:05 they are supposed to be fragmenting out from their Federation code base 18:35:24 henrynash was gonna "review" their code and harvest 18:35:26 (in fact, it's a good idea, but cache invalidation is hard and this is prone to a security vulnerability) 18:35:38 Ryan_Lane, yep, and it will not solve 100% of the things for 100% of the people, but it is the single most requested feature 18:35:51 ayoung +1000 18:35:56 Ryan_Lane, you always authenticate against the central IDP 18:36:03 ayoung: we should create the structure and architecture that allows us to let them contribute components we need for this RO authn LDAP and RQ SQL authz 18:36:14 (RW SQL authz) 18:36:30 henrynash, agreed 18:36:47 hnerynash, agreed 18:36:50 henrynash, I think we need to look at how we are pipelining the auth methods in the V3 api, first 18:37:01 ayoung: +1 18:37:07 right now, only methods that are explicitly named in the token request get processed 18:37:14 +1 18:37:21 (felt the need to agree as well) 18:37:23 but autoprovision is something that always needs to be executed 18:37:26 I was thinking Sahdev could work with Ryan Lane just to finish the read write case cause I think that is easier than pulling it out 18:37:30 ayoung: they can lead to a custom plugin though 18:37:49 dolphm, yep, just we don't have the appropriate integration point for that yet 18:38:02 ayoung, not sure if I understand 18:38:03 ayoung: what are we lacking..? 18:38:16 dolphm, we need it to happen when we execute the auth plugins 18:38:21 ayoung: replace the Password plugin with your own implementation, have that impl talk to ldap 18:38:35 ^^^ what he said 18:38:36 gyee: Error: "^^" is not a valid command. 18:38:40 dolphm, yes, but unless I put that in the token request, it will not get called 18:38:44 uvirtbot: stop it 18:38:45 dolphm: Error: "stop" is not a valid command. 18:38:48 1 sec I'll link 18:39:12 dolphm: I heavily reuse the project structure 18:39:16 in ldap 18:39:22 cant we call the identity driver from the auth plugin to provision the user when authenticated 18:39:30 I'd really prefer not to have to implement that in LDAP and in the database 18:39:44 I don't use keystone for anything other than getting tokens 18:39:54 hell, i don't even want to send a password to keystone 18:39:54 topol, yes we can 18:39:59 topol: yes 18:40:01 #link https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L349 18:40:13 So only auth methods that are explicitly listed get executed 18:40:27 Ryan_Lane, you don't trust Keystone? 18:40:56 gyee, is there any reason that the list of methods *has* to come out of the token request? 18:41:02 Ryan_Lane: 'getting tokens' is sort of a complicated task though... and certainly keystone's first intended use 18:41:09 What if we just always executed each one in the pipeline? 18:41:24 ayoung, yes, that's how we know what payload it is 18:41:26 ayoung: what's your goal, exactly? 18:41:45 dolphm: yes, but I expose multi-tenancy throughout my entire architecture, and LDAP is the only sane way of doing that 18:41:55 dolphm, in this case, we need to autoprovision after the authenticate call completes successfully, but before we do any identity backend work 18:42:15 I have to have that structure in LDAP. if it's not there, then I need to duplicate it there 18:42:23 which means I'd need to make keystone calls and ldap calls 18:42:30 we've got like 18 minutes left, so we should move on and carry this conversation to mailing list + blueprints where relevant 18:42:35 sure 18:42:41 #topic How to kick off v3.1 identity api spec 18:42:53 so ideally autoprovision would be executed right after authenticate when we determined the user was in the cetnral store but not in the local one 18:42:53 henrynash added this to the agenda, but i think the answer is fairly simple... 18:42:56 Ryan_Lane, you will still write something up for the read write case, correct? 18:43:06 dolphm: yep - you did what I was thinking 18:43:06 step 1) Add v3.1 change log, see.... 18:43:12 #link https://review.openstack.org/#/c/26676/ 18:43:14 dolphm: and I approved it already! 18:43:15 I'll write something up for domains and for writing entries properly 18:43:24 start documenting backwards compatible addition into that change log 18:43:40 and document v3.1 specific changes in discrete paragraphs / sections with a v3.1 notice (e.g., New in version 3.1) 18:43:44 henrynash, you might approving this too? https://review.openstack.org/#/c/26665/ 18:43:49 so, that's that 18:43:51 dolphm: just wanted to get an agreed approach before we got started 18:44:01 #topic Havana API-level feature freeze 18:44:09 (related to v3.1) 18:44:33 dolphm, I assume you want Feature freeze to be yesterday? 18:44:37 in every release, we've regretted not doing a feature freeze a milestone ahead of all the other projects 18:44:55 as a first swing at that, i'd like to have an API-level feature freeze at the end of Havana-m2 18:45:18 are we going to have a branch for Ixx after Havana-m2? 18:45:19 +1 on earlier feature freeze than the other folks 18:45:30 which means v3.1 freezes at the end of Havana-m2 18:45:31 dolphm, not sure I agree 18:45:39 I think that features other proejcts depend on, yes 18:45:52 whatever api features don't land wait until havana+1 and fall under the umbrella of v3.2 18:45:55 but there are other features that are not going to get consumed until they get into Keystone 18:46:09 ayoung: those features can wait while we focus on stability and client support 18:46:15 soe we write them for Havana, but people won't write to them until I time frame 18:46:16 ayoung, not sure I follow 18:46:20 topol, Trusts 18:46:26 no one is using trusts yet 18:46:33 but thay can't until we write them 18:46:45 so if we punted on them for Havana, not one would be able to even start writing to them 18:46:48 this will give us time to implement and consume trusts within a single release cycle, for example 18:46:52 same think with PKI tokens 18:46:57 we put them in, buthad them disabled 18:47:31 I think what you really mean dolph ios that we should focus on "do it in a plugin in an external project first" approach, which I fully support 18:47:41 if we dont get them avail early for peer review we are morte surprising them with stuff than providing them with stuff 18:47:52 I also think you mean "featuer freeze is a hard freeze, not a soft freeze" and I support that too 18:48:04 the m2/m3 distinction is conditional on a three milestone cycle as we did in grizzly, i haven't looked at the draft release schedule to see if that's changing yet, but either way the goal is a milestone early 18:48:26 ayoung: i mean both 18:48:59 the early feature freeze gives us a chance to be agile and adjust when we slightly miss stakeholder needs 18:49:29 dolphm, OK, lets tkae it for a goal. It is an internal constraint, and not a bad one. 18:49:32 take it 18:49:47 #topic Priorities following summit Summit etherpads 18:50:04 so, i'm working through our etherpads and working on some blueprints based on those discussions/conclusions 18:50:26 dolphm, I've been doing the same 18:50:30 if anyone wants to do that for something you want to work on, go for it, just link to the new bp in the etherpad so i don't create a dupe :) 18:50:34 dolphm, I intend to get endpoint-filtering in by m2 18:51:02 gyee: cool 18:51:05 not sure about domain quota though, that's above my pay grade 18:51:11 Im stating with Apache-Keystone in devstack. will write the bp today 18:51:20 topol, +5 18:51:41 topol: pretty cool 18:51:53 topol: thanks 18:51:56 dolphm, might I suggest that all blueprints must have, at a minimum, an implementor assigned in order to not be ignored or disapproved? 18:52:02 I'm working on inherited domain roles (or whatever solution we need for that problem) and some of the keystone performance issues 18:52:08 Someone has to commit to the task or it is just spinning 18:52:08 topol: i assume devstack has it's own bp's 18:52:18 topol: https://blueprints.launchpad.net/devstack/ 18:52:24 it does but I will notify you 18:52:27 #link https://blueprints.launchpad.net/devstack 18:52:41 yes, thank you for thinking of me 18:52:43 …and sign me up to work with however on splitting out authz/n and domain backends with autoproviioings 18:52:55 henrynash: will do 18:53:08 henrynash: related https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user 18:53:18 henrynash: if you need any help with that let me know. I'm more than happy to assist with that stuff. 18:53:22 I agree with ayoung, for each task who is the one person losing sleep on whether it gets done or not 18:53:26 dolphm: indeed 18:53:29 topol hmmm, I tagtged this as implemented, and it blamed me for it. Can you tajke credit for it somehow ? https://blueprints.launchpad.net/devstack/+spec/ldap 18:53:39 CERN basically wants REMOTE_USER pluggability for x509 grid certs + auto provisioning 18:53:59 topol: can we nominate people to be the ones to lose sleep for a particular task? 18:54:13 dwaite, only if they have expressed interest 18:54:27 ayoung: aww, guess thats fair 18:54:34 dwaite, it you write a blueprint, park on it until you have someone to implement it for you 18:54:34 dwaite, only if they consent 18:54:35 I'd also like REMOTE_USER + ldap for project/role/user info 18:54:47 I basically want LDAP for everything except authentication 18:54:48 Ryan_Lane, I think that works now 18:55:01 REMOTE_USER implies HTTPD from Apache 18:55:05 or comparable web server 18:55:06 * Ryan_Lane nods 18:55:20 I want S4U2Proxy and Kerberos, + LDAP 18:55:28 Ryan_Lane:….that seems weird, I think we want to optimise for the case of LDAP for authentication ONLY! 18:55:28 (5 minutes) 18:55:34 Ryan_Lane is hurting my head. Most folsk want ldap for only authentication 18:55:39 #topic open discussion 18:55:44 henrynash: ldap authentication sucks 18:55:45 REMOTE_USER is a CGI thing, see rfc3875 18:55:45 since we're back to ldap :) 18:55:54 it's password authentication 18:56:06 or kerberos via passthrough 18:56:08 Ryan_Lane, what do you want instead? X509? 18:56:09 termies nosetest option is breaking sahdev as well as me. how do we fix that 18:56:16 I ran into problem running run_tests.sh with the latest code http://fpaste.org/tLAR/ 18:56:22 ayoung: I'd really like oauth 18:56:24 ayoung: what do you want S4U for? 18:56:26 Ryan_Lane, ah, yeah, Kerberos 18:56:30 Ryan_Lane: but LDAP authentication is how enterprises (effectively) use AD for authn but still want authz in keystone. 18:56:35 not another nose test break….damn, I approved that one too! 18:56:43 morganfainberg: you assume that's the case :) 18:56:47 Ryan_Lane: i added your name to that bp 18:56:48 dwaite, I want to auth via Kerberos and then have the operations against he LDAP backend performed via the users context 18:56:53 not an "admin" 18:56:56 sign stevemar up for OAuth, dolphm, you have my expressed written consent to do that 18:56:57 people who actually know LDAP really well don't use it that way 18:57:17 topol: i put termie on the bp, stevemar can finish it 18:57:18