morganfainberg | topol, eventlet isn't py33 friendly and -infra folks think it wont ever be | 00:00 |
---|---|---|
dolphm | topol: tupil/asyncio/forgotheothername | 00:00 |
topol | morganfainberg, I agree. Just wasnt sure what the replacement would be | 00:00 |
dolphm | tulip for the less-dyslexic | 00:00 |
dolphm | topol: https://code.google.com/p/tulip/ | 00:01 |
dolphm | notable Author:Guido van Rossum <guido at python.org> | 00:01 |
morganfainberg | dolphm, trollius | 00:02 |
topol | dolphm, cool I will take a look at Tulip. Sounds interesting | 00:02 |
topol | any patches on this yet? Does it require py33? | 00:02 |
*** browne has quit IRC | 00:03 | |
morganfainberg | iirc trollius is the py27/33 compatible version | 00:04 |
dolphm | topol: no and ^ | 00:04 |
* topol topol's boss is informing him he has to step away from this interesting conversation to lay out clothes that are in the dryer :-( | 00:04 | |
dolphm | topol: you should maybe review your job description with your boss | 00:05 |
topol | topol has no comment. So Is Tulip multithreaded? | 00:06 |
* topol dryer needs a few mins to heat up | 00:06 | |
*** marcoemorais has joined #openstack-keystone | 00:07 | |
topol | so it looks like it is thread friendly | 00:08 |
*** gokrokve has joined #openstack-keystone | 00:08 | |
topol | Have any of the other openstack project moved to Tulip or will Keystone be the first? | 00:09 |
morganfainberg | topol, don't think anyone has moved there yet | 00:11 |
morganfainberg | topol, but i can't say that definitively | 00:11 |
*** marcoemorais has quit IRC | 00:11 | |
dolphm | we'll probably see oslo dep on trollius first | 00:11 |
dolphm | i also just discovered that enovance wrote trollius | 00:11 |
morganfainberg | dolphm, yeah. | 00:12 |
dolphm | also enovance uses mercuruial | 00:12 |
dolphm | mercurial* | 00:12 |
* morganfainberg doesn't like mercurial | 00:14 | |
morganfainberg | i prefer git | 00:14 |
morganfainberg | and the git-hg plugin is... well ok but not great | 00:14 |
ayoung | Can't we skip all that, run in HTTPD and be done with it? Please? | 00:20 |
ayoung | morganfainberg, there is a git plugin for mercurial. It means you really only have to do git | 00:21 |
morganfainberg | ayoung, it has limitations based on branching differences between the backends | 00:21 |
morganfainberg | that is the only real issue i've run into | 00:21 |
morganfainberg | hg's branching makes my head hurt sometimes. | 00:21 |
morganfainberg | i think that's because i've been using git a lot | 00:21 |
ayoung | morganfainberg, yeah, I'd rather not deal with hg, either. Seems like git is the bettter thought out of the two. | 00:22 |
*** ilives has joined #openstack-keystone | 00:22 | |
morganfainberg | ayoung, yep. but if you're contributing to tox among other things, hg is the tool used. | 00:22 |
ayoung | morganfainberg, NSS, too. Looks like the Mozilla team switched to mercurial | 00:22 |
*** bknudson has joined #openstack-keystone | 00:23 | |
morganfainberg | ayoung, boo. | 00:23 |
morganfainberg | ayoung, at least it isn't bzr | 00:23 |
ayoung | morganfainberg, at least is isn't CVS, which it was until recently | 00:23 |
morganfainberg | ayoung, not sure, is cvs better or worse than bzr? | 00:25 |
topol | dolphm, why would we have to deal with mecurial? | 00:25 |
morganfainberg | topol, if you're contrbuting due to bugs to the project | 00:25 |
topol | just becuase enovance usse it? You think we need to contribute to Tulip? | 00:25 |
morganfainberg | topol, and being that OpenStack is OpenStack, we'll probably find bugs and need to fix it. | 00:26 |
topol | morganfainberg, K, gotcha | 00:26 |
openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Remove LDAP password hashing code https://review.openstack.org/88109 | 00:26 |
topol | perhaps dolphm will voluntold a tulip ambassador to have to deal with mercurial??? | 00:27 |
morganfainberg | topol, hehe | 00:27 |
*** ilives has quit IRC | 00:27 | |
topol | (patch submission to Tulip) | 00:27 |
dolphm | topol: hopefully we won't have problems with trollius :) | 00:27 |
morganfainberg | dolphm, ++ | 00:28 |
*** ilives has joined #openstack-keystone | 00:28 | |
topol | dolphm, does it have a pretty solid track record? | 00:28 |
morganfainberg | and it isn't exactly hard to find enovance folks if we do have an issue | 00:28 |
bknudson | jamielennox: did you have comments on https://review.openstack.org/#/c/82713/ ? stevemar mentioned you had comments on it | 00:29 |
topol | at least it has an apache2 license | 00:29 |
dolphm | topol: i don't know that anyone is using trollius, but hopefully it's just a py2 backport of tulip and doesn't add any untested complexity | 00:30 |
jamielennox | bknudson: +A - i was talking with gyee about it a while ago - i think we should have made that core api | 00:35 |
*** nkinder has quit IRC | 00:37 | |
*** theocean154 has joined #openstack-keystone | 00:45 | |
*** marcoemorais has joined #openstack-keystone | 00:49 | |
*** marcoemorais1 has joined #openstack-keystone | 00:51 | |
*** marcoemorais has quit IRC | 00:54 | |
*** dstanek has joined #openstack-keystone | 01:01 | |
bknudson | dolphm: https://bugs.launchpad.net/python-keystoneclient/+bug/936404 looks like it's about the auth_token middleware | 01:01 |
uvirtbot | Launchpad bug 936404 in python-keystoneclient "No handlers could be found for logger "keystoneclient..."" [Low,In progress] | 01:01 |
bknudson | not the keystone cli | 01:01 |
bknudson | that's an old bug. | 01:02 |
bknudson | ok, then dolphm commented that this still affects the cli. | 01:03 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: CLI always configures logging https://review.openstack.org/88097 | 01:05 |
ayoung | jamielennox, so I tested out Jose's kerberos plugin with Apache. I needed to make a server side change to get it to work: | 01:09 |
jamielennox | ayoung: ah, i was attempting to do that the other day when i was having all those IPA issues | 01:10 |
jamielennox | ayoung: wait client side or server side/ | 01:10 |
ayoung | http://fpaste.org/94829/97028139/ | 01:10 |
ayoung | jamielennox, that change plus a config file edit | 01:10 |
ayoung | in [auth] | 01:11 |
ayoung | kerberos=keystone.auth.plugins.external.KerberosDefaultDomain | 01:11 |
ayoung | methods=kerberos,password,token | 01:11 |
jamielennox | I don't think you want to inherit defaultdomain | 01:11 |
ayoung | jamielennox, meh, it was just a test. | 01:11 |
ayoung | jamielennox, if the plugin was external I would have not had to make any change | 01:12 |
ayoung | method='external' would have worked with the existing set of plugins. | 01:12 |
jamielennox | do you have the link to review handy? | 01:12 |
ayoung | I'm tempted to make that the standard for the client side | 01:12 |
ayoung | jamielennox, nope, didn't post it. | 01:13 |
ayoung | Was still working things out | 01:13 |
ayoung | I can give you access to the machine if you want, though | 01:13 |
jamielennox | i meant his | 01:13 |
jamielennox | it seems abandoned | 01:13 |
ayoung | ah...one sec | 01:14 |
ayoung | https://review.openstack.org/#/c/74317/ | 01:14 |
jamielennox | ayoung: this was my WIP changes to that patch: http://paste.openstack.org/show/76013/ | 01:16 |
jamielennox | but i never got to test it out | 01:16 |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values https://review.openstack.org/76002 | 01:17 |
*** dstanek has quit IRC | 01:25 | |
ayoung | jamielennox, lets not do that | 01:27 |
ayoung | jamielennox, I really don't want to support Kerberos in Python. | 01:27 |
ayoung | richm, Ugh...we need Live LDAP testing in the Gate. Otherwise, changes like yours never get real testing | 01:29 |
richm | ayoung: did you find something? | 01:29 |
ayoung | richm, nope. | 01:29 |
richm | yeah, same problem with designate + live ipa testing | 01:30 |
ayoung | richm, but I rely on the Gate to check "it does what we think it does" | 01:30 |
ayoung | ++ | 01:30 |
*** dstanek has joined #openstack-keystone | 01:30 | |
jamielennox | ayoung: i thought that was a really good compromise | 01:30 |
ayoung | richm, I was hoping to have multi domain backends and then LDAP would be tested alongside the SQL one.... | 01:31 |
ayoung | jamielennox, I don't. And I don't think it is really needed. | 01:31 |
jamielennox | jose would apparently disagree and i can see others wanting to go that way | 01:31 |
ayoung | I have yet to hear a compelling argument for doing Negotiate or X509Client cert validation in Python code instead of HTTPD | 01:31 |
ayoung | Jose and I chatted about it | 01:32 |
ayoung | He didn't realize that you could just mount the "main" (public) router in a kerberized suburl but return the rest from a non-kerberized in the catalog | 01:32 |
ayoung | that is the setup I have on the system I tested this on: | 01:32 |
jamielennox | right, using the same endpoint is the main one | 01:33 |
ayoung | http://fpaste.org/94833/13976984/ jamielennox | 01:33 |
ayoung | I need to get a user cert setup and add that in with | 01:34 |
ayoung | NSS_VerifyClient or whatever the config option is | 01:34 |
*** theocean154 has left #openstack-keystone | 01:34 | |
ayoung | NSSVerifyClient require | 01:34 |
*** richm has quit IRC | 01:34 | |
ayoung | according to the conf file in /etc/httpd/conf.d | 01:35 |
*** marcoemorais1 has quit IRC | 01:46 | |
*** Chicago has quit IRC | 01:47 | |
*** dstanek has quit IRC | 01:55 | |
*** amcrn has quit IRC | 01:56 | |
*** dstanek has joined #openstack-keystone | 02:05 | |
*** derek_c has quit IRC | 02:07 | |
*** derek_c has joined #openstack-keystone | 02:08 | |
topol | ayoung, did you see Remove LDAP password hashing code https://review.openstack.org/88109 | 02:08 |
ayoung | topol, click on the link yourself | 02:09 |
topol | its pulling out code you put in originally but I can remember why you put it in | 02:09 |
topol | gotcha | 02:09 |
openstackgerrit | Li Ma proposed a change to openstack/keystone: Password trunction makes password insecure https://review.openstack.org/77325 | 02:09 |
topol | figured that would happen :-) | 02:09 |
topol | thats what I get for getting dinner | 02:10 |
*** david-lyle has joined #openstack-keystone | 02:17 | |
*** dstanek has quit IRC | 02:19 | |
ayoung | topol, actually, I was wondering if CERN was using that | 02:19 |
ayoung | I suspect not, but worth doing due dilligence | 02:20 |
topol | ayoung, I vaguely recall there being a reason for it. Trying to dig it out of my brain. using git history and git blame to help jog my memory | 02:21 |
ayoung | topol, he alludes to it in the commit message: its for Fake | 02:22 |
ayoung | all passwords are checked hashed. | 02:22 |
ayoung | I think simplebind does that | 02:22 |
topol | its been there a while. I thought it was for something else. But I'll just double check. Its bugging me | 02:22 |
ayoung | So we should probably remove the logic from the LDAP password code and put it into Fake, but it might be that some LDAP code we don't know about just passes the password on through | 02:23 |
ayoung | topol, nkinder knows LDAP, much better than I do. He's the manager for the RH DS team.... | 02:23 |
*** dstanek has joined #openstack-keystone | 02:23 | |
ayoung | or at least he was on the team...need to check the org chart | 02:23 |
*** derek_c has quit IRC | 02:25 | |
topol | ayoung, so yes it looks like it was put in for the fakeldap: https://github.com/everett-toews/keystone/commit/63437e9dca3b969c917fb138716aa4d3e5fabafa | 02:26 |
ayoung | topol, his point is that the LDAP backends may not even allow it, but I would expect the LDAP live tests to barf if that were the case. Its Red Hat Summit this week, so we can discuss with him early next week | 02:27 |
topol | so ayoung if its causing nkinder to hit LDAP bugs I think its worth pulling it out once he refactors it to how you recommend | 02:27 |
ayoung | topol, I'll ask Jose to take a look, too | 02:28 |
*** zhiyan_ is now known as zhiyan | 02:29 | |
ayoung | jamielennox, so...I did yum install mod_nss on the packstack box, and HTTPD refuses to start. I did the same thing on the devstack box and it worked fine | 02:30 |
ayoung | so...just to check, I modified the file in conf.modules.d that pulls in nss, put garbage in there and restarted HTTPD, with no change | 02:30 |
jamielennox | ayoung: i've never really done anythin with packstack | 02:31 |
ayoung | that seems to me to say that the NSS module is not getting added to Apache | 02:31 |
ayoung | jamielennox, yeah, neither have I | 02:31 |
jamielennox | but i can't see why it's different | 02:31 |
ayoung | jamielennox, something we are doing in Packstack configuring HTTPD means that mod_nss is not getting added | 02:31 |
ayoung | the error indicates that as well: | 02:31 |
ayoung | Invalid command 'NSSPassPhraseDialog', perhaps misspelled or defined by a module not included in the ser | 02:32 |
jamielennox | yea, that sounds like a packagin thing | 02:33 |
jamielennox | hmm, the distinction between what is middleware and what is core is a pain in pecan | 02:34 |
ayoung | jamielennox, so there is a set of module files that are supposed to be parsed in ABC order | 02:34 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Allow session to return an error response object https://review.openstack.org/83630 | 02:35 |
ayoung | and nss adds one there. its at the same level as another (10-wsgi.conf) | 02:35 |
*** ilives has quit IRC | 02:35 | |
ayoung | but..the conf.d directory in packstack is crazy | 02:36 |
ayoung | and...it looks like maybe a Puppetism? | 02:36 |
*** ilives has joined #openstack-keystone | 02:36 | |
ayoung | Hmm... | 02:36 |
ayoung | OK, something pulls all of the module load files into /etc/httpd/conf.d I suspect Puppet | 02:38 |
ayoung | I need to selinux relable it | 02:38 |
*** dstanek has quit IRC | 02:38 | |
ayoung | jamielennox, I have | 02:39 |
ayoung | -rw-r--r--. root root system_u:object_r:httpd_config_t:s0 nss.conf | 02:39 |
ayoung | but | 02:39 |
ayoung | -rw-r--r--. root root unconfined_u:object_r:httpd_config_t:s0 nss.load | 02:39 |
ayoung | its not just restorecon... | 02:39 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Implement endpoint filtering functionality on the client side. https://review.openstack.org/82713 | 02:41 |
jamielennox | ayoung: and that fixes it | 02:46 |
ayoung | jamielennox, still battling selinux | 02:46 |
ayoung | I did a cp, but that made it unconfined. I need it to look like the line above | 02:47 |
ayoung | OK, doing a mv worked | 02:48 |
ayoung | jamielennox, yeah, that worked | 02:48 |
ayoung | ARGH. dleted the wrong file | 02:49 |
ayoung | but easy to fix | 02:49 |
*** derek_c has joined #openstack-keystone | 02:50 | |
*** lnxnut_ has joined #openstack-keystone | 02:51 | |
*** lnxnut has quit IRC | 02:53 | |
*** mberlin has quit IRC | 02:56 | |
jamielennox | ayoung: can you explain the need for: https://github.com/openstack/keystone/blob/master/keystone/trust/controllers.py#L186 | 03:00 |
ayoung | paranoia | 03:00 |
ayoung | it went in before RBAC was rock solid | 03:00 |
jamielennox | if you've got protected() do you need assert_admin? | 03:00 |
ayoung | I trust RBAC now, I don't think it was there when the initial call went in. We can possibly remove that | 03:01 |
ayoung | I think the idea is that no one should just be listing trusts | 03:01 |
ayoung | Did I write that? | 03:01 |
*** browne has joined #openstack-keystone | 03:02 | |
ayoung | jamielennox, there were close to 100 revisions of that patch and the one that followed with the tests. My guess is the rationale lies in the code reviews | 03:03 |
jamielennox | ayoung: hmm, it looks like the route is allowed if you use the correct user parameters, but if you want to list all you need admin | 03:06 |
*** browne has quit IRC | 03:06 | |
jamielennox | though the admin enforced by that call is a bit odd | 03:06 |
ayoung | jamielennox, agreed. I added in the is_admin check long before the policy check in that tree | 03:07 |
jamielennox | is there a way to write that properly now? | 03:07 |
ayoung | https://review.openstack.org/#/c/20289/12/keystone/trust/controllers.py does not have it, but 13 does | 03:07 |
ayoung | It would have to be two different calls | 03:07 |
ayoung | one for list trusts for the user and one for list all/ | 03:08 |
jamielennox | or is it something we are stuck with? | 03:08 |
jamielennox | ayoung: it appears to be the only v3 route that uses that methohd | 03:10 |
ayoung | jamielennox, what is the issue? | 03:11 |
jamielennox | ayoung: trying to clean up the controllers to see what i can do with pecan | 03:11 |
*** mberlin has joined #openstack-keystone | 03:12 | |
ayoung | jamielennox, I think you can make changes there, so long as we are clear with the API doc. I suspect that we need two routes, one for the admin list-all, and one for the explicit query-parameter. But there might be a way to do it with an addition @protected call for just the admin portion | 03:12 |
openstackgerrit | Dolph Mathews proposed a change to openstack/keystone: More notification unit tests https://review.openstack.org/81659 | 03:13 |
ayoung | if you refactor out the admin call into a public method on the controller, and put a decorator on it, the RBAC evaluated with be first the more permissive one, and then the is_admin one. | 03:13 |
ayoung | does that make sense? | 03:13 |
jamielennox | not particularly - but i'm really not trying to restructure that part of auth, i'm just trying to figure out the exact dependencies of everyhting | 03:14 |
ayoung | jamielennox, ok, if you need to get rid of the is_admin call, let me know and I can help you with the policy for it. | 03:17 |
ayoung | OK, I got Horizon NSS SSLifies, just need a redirect for http: to https: | 03:18 |
*** stevemar has joined #openstack-keystone | 03:20 | |
*** gyee has quit IRC | 03:23 | |
*** dstanek has joined #openstack-keystone | 03:27 | |
*** lnxnut_ has quit IRC | 03:33 | |
*** dstanek has quit IRC | 03:33 | |
dolphm | https://pypi.python.org/pypi/python-keystoneclient/0.8.0 | 03:38 |
*** bach has joined #openstack-keystone | 03:39 | |
*** zhiyan is now known as zhiyan_ | 03:41 | |
*** bach has quit IRC | 03:48 | |
*** bach has joined #openstack-keystone | 03:53 | |
*** topol has quit IRC | 03:58 | |
openstackgerrit | A change was merged to openstack/keystone: Adding one more check on project_id https://review.openstack.org/85199 | 03:58 |
*** bach_ has joined #openstack-keystone | 03:59 | |
*** bach has quit IRC | 04:03 | |
*** bach_ has quit IRC | 04:03 | |
*** bach has joined #openstack-keystone | 04:03 | |
*** stevemar has quit IRC | 04:22 | |
*** stevemar has joined #openstack-keystone | 04:27 | |
stevemar | morganfainberg, i just saw the "WARNING" chat between you and dolphm, hehehe | 04:28 |
morganfainberg | hehehe | 04:30 |
*** jamielennox is now known as jamielennox|away | 04:32 | |
*** chandan_kumar has joined #openstack-keystone | 04:35 | |
*** harlowja is now known as harlowja_away | 04:47 | |
*** daneyon_ has joined #openstack-keystone | 04:48 | |
*** daneyon has quit IRC | 04:48 | |
*** ilives has quit IRC | 04:49 | |
*** ilives has joined #openstack-keystone | 04:50 | |
*** daneyon_ has quit IRC | 04:53 | |
*** gokrokve has quit IRC | 04:56 | |
*** gokrokve_ has joined #openstack-keystone | 05:01 | |
*** gokrokve_ has quit IRC | 05:03 | |
*** chandan_kumar has quit IRC | 05:03 | |
*** chandan_kumar has joined #openstack-keystone | 05:03 | |
*** marcoemorais has joined #openstack-keystone | 05:21 | |
*** boris-42 has quit IRC | 05:24 | |
*** jzl-ctrip has joined #openstack-keystone | 05:26 | |
*** dstanek has joined #openstack-keystone | 05:29 | |
*** dstanek has quit IRC | 05:34 | |
*** derek_c has quit IRC | 05:39 | |
*** zhiyan_ is now known as zhiyan | 05:41 | |
*** boris-42 has joined #openstack-keystone | 05:43 | |
*** gokrokve has joined #openstack-keystone | 05:45 | |
*** praneshp has quit IRC | 05:45 | |
*** gokrokve has quit IRC | 05:50 | |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: add dependencies of keystone dev-enviroment https://review.openstack.org/80474 | 05:51 |
*** jamielennox|away has quit IRC | 05:55 | |
*** jamielennox|away has joined #openstack-keystone | 05:56 | |
*** RockKuo_ has joined #openstack-keystone | 06:07 | |
*** RockKuo_ has quit IRC | 06:07 | |
*** RockKuo_Office has joined #openstack-keystone | 06:07 | |
*** stevemar has quit IRC | 06:24 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: CLI always configures logging https://review.openstack.org/88097 | 06:27 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Create a V3 Token Generator https://review.openstack.org/78878 | 06:27 |
*** praneshp has joined #openstack-keystone | 06:41 | |
*** gokrokve has joined #openstack-keystone | 06:45 | |
*** Chicago has joined #openstack-keystone | 06:50 | |
*** Chicago has joined #openstack-keystone | 06:50 | |
*** gokrokve has quit IRC | 06:50 | |
*** bach has quit IRC | 06:54 | |
*** tomoiaga has joined #openstack-keystone | 06:54 | |
*** praneshp has quit IRC | 07:01 | |
openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Unimplemented get roles by group for project list https://review.openstack.org/76470 | 07:02 |
*** praneshp has joined #openstack-keystone | 07:08 | |
*** morganfainberg is now known as morganfainberg_Z | 07:13 | |
*** dtroyer has quit IRC | 07:15 | |
*** leseb has joined #openstack-keystone | 07:18 | |
*** dtroyer has joined #openstack-keystone | 07:18 | |
*** ilives has quit IRC | 07:29 | |
*** ilives has joined #openstack-keystone | 07:29 | |
*** jaosorior has joined #openstack-keystone | 07:36 | |
*** gokrokve has joined #openstack-keystone | 07:46 | |
*** derek_c has joined #openstack-keystone | 07:47 | |
*** gokrokve has quit IRC | 07:51 | |
*** RockKuo_Office has quit IRC | 08:00 | |
*** amcrn has joined #openstack-keystone | 08:00 | |
*** marcoemorais has quit IRC | 08:07 | |
*** amcrn has quit IRC | 08:11 | |
*** amcrn has joined #openstack-keystone | 08:13 | |
openstackgerrit | wanghong proposed a change to openstack/keystone: let ssl/pki_setup can overwrite existing files https://review.openstack.org/88207 | 08:20 |
*** derek_c has quit IRC | 08:24 | |
*** andreaf has joined #openstack-keystone | 08:32 | |
*** marekd|away is now known as marekd | 08:38 | |
*** RockKuo_Office has joined #openstack-keystone | 08:39 | |
*** chandan_kumar has quit IRC | 09:08 | |
*** praneshp has quit IRC | 09:36 | |
jzl-ctrip | fdsahkljfjklsdajklfjklfdjklsdfjklfsdjkldfs | 09:42 |
*** gokrokve has joined #openstack-keystone | 09:49 | |
*** zhiyan is now known as zhiyan_ | 09:50 | |
*** zhiyan_ is now known as zhiyan | 09:52 | |
*** gokrokve has quit IRC | 09:53 | |
*** zhiyan is now known as zhiyan_ | 09:54 | |
openstackgerrit | Julien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend https://review.openstack.org/86016 | 09:59 |
*** marekd is now known as marekd|away | 10:16 | |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Sync test_migrations https://review.openstack.org/80618 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Redundant unique constraint https://review.openstack.org/84447 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Corresponding `nullable` value. https://review.openstack.org/84446 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Migration DB_INIT_VERSION in common place https://review.openstack.org/88016 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Compatible server default value in the models. https://review.openstack.org/84445 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Explicit foreign key indexes. https://review.openstack.org/84444 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Make it possible to use multiprocess file locks https://review.openstack.org/84448 | 10:17 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 10:17 |
*** zoresvit has joined #openstack-keystone | 10:19 | |
openstackgerrit | wanghong proposed a change to openstack/keystone: delete association when delete proj or endpoint https://review.openstack.org/87551 | 10:22 |
*** snikitin has quit IRC | 10:27 | |
*** david-lyle has quit IRC | 10:35 | |
*** lnxnut has joined #openstack-keystone | 10:44 | |
*** gokrokve has joined #openstack-keystone | 10:50 | |
*** gokrokve has quit IRC | 10:55 | |
*** RockKuo_Office has quit IRC | 11:07 | |
*** lbragstad has quit IRC | 11:18 | |
*** gokrokve has joined #openstack-keystone | 11:50 | |
*** gokrokve has quit IRC | 11:55 | |
*** thiagop has joined #openstack-keystone | 12:08 | |
*** gokrokve has joined #openstack-keystone | 12:09 | |
*** gokrokve has quit IRC | 12:13 | |
*** dstanek has joined #openstack-keystone | 12:20 | |
*** mgagne has quit IRC | 12:31 | |
*** mgagne has joined #openstack-keystone | 12:33 | |
*** mgagne is now known as Guest78217 | 12:33 | |
*** zhiyan_ is now known as zhiyan | 12:38 | |
*** dims has quit IRC | 12:44 | |
*** dims has joined #openstack-keystone | 12:44 | |
*** lbragstad has joined #openstack-keystone | 12:48 | |
*** ilives has quit IRC | 13:07 | |
*** ilives has joined #openstack-keystone | 13:08 | |
*** gokrokve has joined #openstack-keystone | 13:10 | |
*** stevemar has joined #openstack-keystone | 13:11 | |
*** gokrokve has quit IRC | 13:14 | |
*** zoresvit has quit IRC | 13:16 | |
*** bach has joined #openstack-keystone | 13:20 | |
*** bknudson has quit IRC | 13:32 | |
dolphm | OpenStack 2014.1 ("Icehouse") is released! http://lists.openstack.org/pipermail/openstack-announce/2014-April/000225.html | 13:33 |
*** chandan_kumar has joined #openstack-keystone | 13:36 | |
tomoiaga | great | 13:41 |
*** bach has quit IRC | 13:46 | |
*** bknudson has joined #openstack-keystone | 13:50 | |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Refactor notifications https://review.openstack.org/81660 | 13:57 |
*** bach has joined #openstack-keystone | 14:05 | |
*** gokrokve has joined #openstack-keystone | 14:11 | |
*** bach_ has joined #openstack-keystone | 14:12 | |
*** bach has quit IRC | 14:14 | |
openstackgerrit | Julien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend https://review.openstack.org/86016 | 14:15 |
*** gokrokve has quit IRC | 14:15 | |
ayoung | dolphm, w00t! | 14:22 |
dolphm | ayoung: get your token compression patch re-opened :) | 14:22 |
ayoung | dolphm, Roger Wilco, Over and Out! | 14:22 |
ayoung | dolphm, https://review.openstack.org/#/c/71181/ need to do a manual rebase since a bunch of cms code changed | 14:24 |
*** gokrokve has joined #openstack-keystone | 14:27 | |
*** bach_ has quit IRC | 14:28 | |
*** gokrokve_ has joined #openstack-keystone | 14:29 | |
*** bach has joined #openstack-keystone | 14:29 | |
*** chandan_kumar has quit IRC | 14:31 | |
*** gokrokve has quit IRC | 14:33 | |
*** jagee has joined #openstack-keystone | 14:33 | |
*** raildo has joined #openstack-keystone | 14:34 | |
*** bach has quit IRC | 14:37 | |
*** derek_c has joined #openstack-keystone | 14:37 | |
*** topol has joined #openstack-keystone | 14:37 | |
*** david-lyle has joined #openstack-keystone | 14:37 | |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Sync test_migrations https://review.openstack.org/80618 | 14:37 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Migration DB_INIT_VERSION in common place https://review.openstack.org/88016 | 14:37 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Make it possible to use multiprocess file locks https://review.openstack.org/84448 | 14:37 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 14:37 |
dolphm | dstanek: i see you were credited as a speaker at pycon 2014 - were you even there? | 14:39 |
openstackgerrit | Julien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend https://review.openstack.org/86016 | 14:39 |
dstanek | dolphm: no, i was going to do a joint tutorial, but it turned out i wasn't able to go | 14:39 |
dolphm | dstanek: i'm watching pyohio version that you actually presented instead | 14:39 |
dstanek | that was a fun audience - for whatever reason there were several people that had broken virtual box instalations | 14:40 |
dstanek | i've been talking about the OWASP Top 10 for too many years now | 14:41 |
*** zematynnad has joined #openstack-keystone | 14:43 | |
bknudson | I think openstack has had every one of those | 14:46 |
dolphm | i'm sure | 14:46 |
dolphm | although i don't recall any real sql injection that i've been aware of | 14:46 |
bknudson | there was just recently a shell injection | 14:46 |
dolphm | bknudson: via an HTTP API? | 14:48 |
bknudson | dolphm: https://bugs.launchpad.net/ossa/+bug/1298698 | 14:49 |
uvirtbot | Launchpad bug 1298698 in glance/havana "[OSSA 2014-012] Remote Code Execution in Sheepdog backend (CVE-2014-0162)" [Undecided,Fix committed] | 14:49 |
*** vhoward has left #openstack-keystone | 14:50 | |
dolphm | bknudson: yuck | 14:50 |
dolphm | my hobby: skimming stack overflow for code snippets containing vulnerabilities, and looking to see if it's obvious from the user's profile where that code might be running in production | 14:52 |
dstanek | dolphm: have you found any yet? | 14:52 |
dolphm | dstanek: of course | 14:52 |
dolphm | dstanek: they never get accepted as the answer though lol | 14:53 |
*** overlayer has joined #openstack-keystone | 14:54 | |
*** ilives has quit IRC | 14:55 | |
*** ilives has joined #openstack-keystone | 14:56 | |
dstanek | maybe the really setup stackoverflow to be a honeypot for security holes | 14:58 |
*** chandan_kumar has joined #openstack-keystone | 14:58 | |
dolphm | dstanek: "share your company's proprietary code here that you're not allowed to publish to github" ? | 15:02 |
*** thedodd has joined #openstack-keystone | 15:04 | |
*** tomoiaga has quit IRC | 15:07 | |
*** raildo has left #openstack-keystone | 15:08 | |
dolphm | or maybe that gists | 15:11 |
*** wchrisj_ has joined #openstack-keystone | 15:16 | |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: remove universal_newlines https://review.openstack.org/79411 | 15:16 |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation https://review.openstack.org/71181 | 15:18 |
*** zematynnad has left #openstack-keystone | 15:19 | |
*** Anju_ has joined #openstack-keystone | 15:24 | |
dstanek | am i correct in thinking that the purpose of the token revocation list is just an optimization so that services can reject tokens without having to come to Keystone? | 15:25 |
*** chandan_kumar has quit IRC | 15:27 | |
*** derek_c has quit IRC | 15:27 | |
*** chandan_kumar has joined #openstack-keystone | 15:28 | |
*** bach has joined #openstack-keystone | 15:29 | |
dolphm | dstanek: i suppose that's half the story... | 15:30 |
dstanek | dolphm: is there a longer second half? | 15:30 |
dolphm | dstanek: always! | 15:31 |
dolphm | dstanek: dstanek: the other half is that our default token duration is longer than people are willing to wait for tokens to naturally expire, so that's why we need a revocation mechanism at all | 15:31 |
dolphm | dstanek: the third half is that it's not just an optimization - there's not really an offline solution for invalidating PKI tokens | 15:32 |
dstanek | dolphm: in that particular case can't they just lower the duration? | 15:33 |
dolphm | dstanek: yeah, but users expect tokens to become invalid within seconds or minutes | 15:33 |
dstanek | dolphm: that's what i meant by optimization. the server wouldn't have to make an expensive sevice call if the token was in the list | 15:34 |
dolphm | dstanek: fair enough - then, yes. but the token validation *list* is itself an expensive (heavy) call | 15:35 |
dolphm | dstanek: or at least it can be, when users are generating thousands of tokens, and then the user gets deleted, for example | 15:35 |
*** browne has joined #openstack-keystone | 15:35 | |
dstanek | dolphm: is the list incremental or do we just keep giving that the entire list everytime? | 15:36 |
dolphm | dstanek: it rotates as revoked tokens expire naturally, if that's what you're asking? | 15:36 |
dstanek | dolphm: that's part of it; i thinking ore along the lines of a way to say "i got up to X token on the list" and then have the server return only the revoked tokens after that point | 15:41 |
*** chandan_kumar has quit IRC | 15:42 | |
dolphm | dstanek: the polling mechanism for token revocation *events* has that built in | 15:45 |
dolphm | dstanek: but i'd like token revocation events to be loaded on startup via HTTP, and then received via messaging after that | 15:46 |
dstanek | dolphm: makes sense | 15:46 |
dstanek | dolphm: i was curious because of this review https://review.openstack.org/#/c/86016/ | 15:46 |
dolphm | dstanek: i think it's GET /v3/OS-REVOKE/revents?since=<last-revocation-time-the-client-saw> | 15:46 |
*** overlayer has left #openstack-keystone | 15:48 | |
dolphm | dstanek: i heard someone talking about that recently, i didn't know they were serious | 15:48 |
dstanek | yeah, no tests yet and no revocation lists | 15:49 |
*** richm has joined #openstack-keystone | 15:49 | |
*** marcoemorais has joined #openstack-keystone | 15:50 | |
dolphm | dstanek: if he's targeting UUID tokens only, you wouldn't need one | 15:52 |
dstanek | dolphm: how can you tell what he's targeting? or is it just what he uses it for | 15:52 |
dolphm | dstanek: no revocation support -> probably uuid-only | 15:53 |
dstanek | dolphm: but i agree you wouldn't need it with ephemeral tokens | 15:53 |
dolphm | dstanek: and only PKI can become ephemeral | 15:53 |
dolphm | i'd also rather not introduce any sort of dep on another openstack project | 15:55 |
*** gyee has joined #openstack-keystone | 15:56 | |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: auth_token middleware hashes tokens with configurable algorithm https://review.openstack.org/80398 | 15:56 |
*** nkinder has joined #openstack-keystone | 15:56 | |
*** dstanek is now known as dstanek_lunch | 15:57 | |
*** zhiyan is now known as zhiyan_ | 15:59 | |
*** jaosorior has quit IRC | 16:01 | |
*** chandan_kumar has joined #openstack-keystone | 16:02 | |
*** nkinder has quit IRC | 16:03 | |
*** bach_ has joined #openstack-keystone | 16:03 | |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Sync test_migrations https://review.openstack.org/80618 | 16:04 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Sync on-demand database schemas https://review.openstack.org/84448 | 16:04 |
openstackgerrit | Ilya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations. https://review.openstack.org/80630 | 16:04 |
*** bach has quit IRC | 16:06 | |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token https://review.openstack.org/87091 | 16:09 |
*** bach_ has quit IRC | 16:15 | |
*** marcoemorais has quit IRC | 16:15 | |
*** marcoemorais has joined #openstack-keystone | 16:16 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: More efficient DN list for LDAP role delete https://review.openstack.org/87151 | 16:16 |
*** marcoemorais has quit IRC | 16:16 | |
*** marcoemorais has joined #openstack-keystone | 16:16 | |
ayoung | dstanek_lunch, dolphm a swift backend should be done via the KVS/Dogpile mechanism anyway | 16:17 |
dolphm | ayoung: a swift dogpile driver? | 16:18 |
ayoung | dolphm, yep | 16:18 |
ayoung | dolphm, I'm not saying it is a good idea, mind you, just "if you want swift support..." | 16:19 |
*** nkinder has joined #openstack-keystone | 16:19 | |
*** bach has joined #openstack-keystone | 16:20 | |
dolphm | ayoung: then they could just include it in swiftclient, since it has nothing to do with keystone | 16:20 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token https://review.openstack.org/87091 | 16:20 |
ayoung | dolphm, well, sure. But if they want to store tokens in Swift for whatever reason, the right path is via KVS and Dogpile | 16:21 |
*** Guest78217 is now known as mgagne | 16:23 | |
*** mgagne has joined #openstack-keystone | 16:24 | |
*** bach_ has joined #openstack-keystone | 16:26 | |
*** bach has quit IRC | 16:28 | |
*** derek_c has joined #openstack-keystone | 16:29 | |
*** gyee has quit IRC | 16:29 | |
*** daneyon has joined #openstack-keystone | 16:34 | |
*** dstanek_lunch has quit IRC | 16:37 | |
*** bach_ has quit IRC | 16:40 | |
*** leseb has quit IRC | 16:40 | |
dolphm | 461 developers *regularly* working on openstack, crazy http://blog.bitergia.com/2014/04/17/the-openstack-icehouse-release-activity-and-organizations/ | 17:01 |
*** tomoiaga has joined #openstack-keystone | 17:03 | |
*** dstanek_lunch has joined #openstack-keystone | 17:04 | |
nkinder | dolphm: where is "regular" defined? | 17:04 |
nkinder | ayoung: ping, re - password hashing | 17:05 |
nkinder | ayoung: so I can't think of anything that would be dependent on Keystone pre-hashing LDAP passwords | 17:05 |
nkinder | I can think of plenty of failure scenarios though ;) | 17:05 |
ayoung | nkinder, a dumb ldap server that accepted whatever we handed it? | 17:06 |
nkinder | ayoung: sure, it accepts it | 17:06 |
nkinder | ayoung: what then? | 17:06 |
ayoung | nkinder, simple bind works? | 17:06 |
nkinder | ayoung: do we coulnt on it then being smart enough to treat the hash right? | 17:06 |
nkinder | ayoung: maybe, maybe not. Depends on what the server does with it | 17:06 |
ayoung | nkinder, well, why does the existing code work in live LDAP tests? | 17:07 |
nkinder | If the server accepts a pre-hashed password, then it will do the comparison right during the bind (it hashes the clear password from the bind using the same scheme, then compares it) | 17:07 |
ayoung | I tested with OpenLDAP, and I think that just accepted the password I gave it, and then simplebind does that sha1 salted | 17:07 |
nkinder | ayoung: because it's accepted in 389 DS if you use Directory Manager, and OL can accept it too. | 17:08 |
ayoung | so if we stop pre-hashing will everything still work? | 17:08 |
nkinder | ayoung: doesn't make it a good idea. It's more of a legacy style of doing passwords | 17:08 |
nkinder | ayoung: yes, and the passwords will be hashed by the server | 17:08 |
ayoung | nkinder which Dir Srvs did you verify the code against? | 17:08 |
nkinder | ayoung: old pam_ldap would do a search for the userPassword value to get the hash, then compare hashes on the client for auth | 17:08 |
ayoung | I'm most concerned with AD, since Cern uses it for scale | 17:09 |
nkinder | ayoung: oh, AD would be completely hosed with the current code if you let keystone create users or set passwords | 17:09 |
ayoung | althought I can't believe they would actually manage users via Keystone | 17:09 |
nkinder | ayoung: AD doesn't use SSHA | 17:09 |
nkinder | AD uses NTLM | 17:09 |
ayoung | nkinder, and the LDAP client is smart enought to know that? | 17:09 |
ayoung | the Python code does a simple bind....where is the hashing done? | 17:10 |
*** dstanek_lunch has quit IRC | 17:10 | |
ayoung | on the far side of the wire? | 17:10 |
nkinder | the server | 17:10 |
* ayoung sobs | 17:10 | |
nkinder | the client should never do the hashing | 17:10 |
nkinder | never ever | 17:10 |
*** daneyon has quit IRC | 17:10 | |
ayoung | and, of coure, it would not know the salt | 17:10 |
*** daneyon has joined #openstack-keystone | 17:11 | |
ayoung | but if you do LDAP without TLS...you are sending cleartext passwords. I guess it wouldn't matter if they were prehashed, though | 17:11 |
nkinder | ayoung: sure, which is why plain LDAP is bad | 17:11 |
ayoung | Ugh. CAn we skip all this and go right to Kerberos? | 17:11 |
nkinder | ayoung: note that ldapsearch requires you to use an option (-x) to even do a simple bind | 17:11 |
nkinder | They try to force SASL (DIGEST-MD5) | 17:11 |
ayoung | nkinder, BTW: http://adam.younglogic.com/2014/04/nss-horizon/ | 17:12 |
nkinder | ayoung: one step at a time :) | 17:12 |
ayoung | that was my latest step...I' | 17:12 |
ayoung | ve shifted gears back to the compressed tokens for a short time | 17:12 |
ayoung | want to get the patch functioning...and had a request to do so | 17:12 |
*** harlowja_away is now known as harlowja | 17:12 | |
nkinder | ayoung: one other point with Keystone's current code. We only hash LDAP passwords when setting them. We currently send the clear password to the LDAP server for a bind already. | 17:13 |
nkinder | ayoung: the LDAP password checking method is only used by fakeldap to do a hash check. Live LDAP doesn't use that. | 17:14 |
*** daneyon_ has joined #openstack-keystone | 17:14 | |
ayoung | nkinder, the compression code has a second effect benefit. It gives the ability to pull the signer info out of the token. It will allow for having multiple signers, which will clean up some of the HA stuff kashyap is working on | 17:14 |
ayoung | nkinder, can we do the hashing only in fakeldap? | 17:15 |
ayoung | I guess we don't need it there.... | 17:15 |
dolphm | nkinder: is it possible that LDAP servers would be re-hashing passwords that are already hashed by keystone? | 17:15 |
nkinder | ayoung: I'd rather rip it out. It's not testing anything, and I'd prefer to rip out unnecessary crypto. | 17:15 |
ayoung | OK. I can get behind this | 17:15 |
ayoung | dolphm, then simple_bind would fail | 17:15 |
nkinder | whoops, dolphm ^^^ | 17:15 |
ayoung | they would be double hashed | 17:16 |
dolphm | ayoung: correct | 17:16 |
nkinder | double hashing is my fear with AD | 17:16 |
*** marcoemorais has quit IRC | 17:16 | |
ayoung | nkinder, no one has filed a bug for it, leaving me to think that no one with AD is managing users from Keystone | 17:16 |
nkinder | I have seen that occur before when developing on 389 (long ago) | 17:16 |
dolphm | nkinder: so, by removing double hashing, you're making it so that users with doubly hashed passwords created via keystone can't authenticate anymore? | 17:16 |
nkinder | ayoung: you're likely correct | 17:16 |
*** marcoemorais has joined #openstack-keystone | 17:16 | |
*** derek_c has quit IRC | 17:16 | |
*** daneyon has quit IRC | 17:17 | |
nkinder | dolphm: no, if LDAP double hashes, then authentication via keystone would fail (keystone doesn't hash during bind) | 17:17 |
nkinder | dolphm: so the result would be that I could give keystone my hash as the password to bind | 17:17 |
dolphm | nkinder: i thought you said it was hashing passwords on create AND auth? | 17:17 |
dolphm | create user* | 17:17 |
nkinder | dolphm: nope, only create/mod | 17:17 |
nkinder | fakeldap does hash during auth (not live LDAP) | 17:18 |
dolphm | nkinder: rip it out then! | 17:18 |
nkinder | yep, that's my conclusion too! | 17:18 |
ayoung | dolphm, simple_bind passes cleartext password to the server. THis is what the user passed to Keystone in the token request. We do no hashing of it. | 17:18 |
ayoung | dolphm, https://review.openstack.org/#/c/88109/ | 17:19 |
nkinder | yeah, I confirmed all of that with wireshark yesterday too | 17:19 |
ayoung | nkinder, I kindof figured you had your ducks in a row with this one, but wanted to discuss it with you before ACKing | 17:19 |
*** chandan_kumar has quit IRC | 17:19 | |
ayoung | topol, when you get a chance, read up here, and probably should remove you -1 on https://review.openstack.org/#/c/88109/ | 17:20 |
nkinder | topol: happy to answer any further questions on it for you too | 17:20 |
*** therve has joined #openstack-keystone | 17:27 | |
therve | Hi | 17:27 |
*** gokrokve_ has quit IRC | 17:28 | |
*** gokrokve has joined #openstack-keystone | 17:29 | |
openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Remove LDAP password hashing code https://review.openstack.org/88109 | 17:36 |
topol | ayoung, nkinder Hi | 17:37 |
therve | There is fairly ridiculous regression in ceilometer because of the deprecation of the auth fragments | 17:37 |
ayoung | therve, "auth fragments?" | 17:38 |
dolphm | topol: https://review.openstack.org/#/c/88109/1/keystone/identity/backends/ldap.py | 17:38 |
therve | ayoung, auth_port/auth_host etc? | 17:38 |
dolphm | jamielennox|away: ^ | 17:38 |
therve | It seems we should use identity_uri now | 17:38 |
dolphm | therve: link? | 17:38 |
therve | dolphm, http://logs.openstack.org/69/87869/3/check/gate-ceilometer-python27/fbde553/console.html | 17:38 |
therve | I think we can fix it in ceilo, I just went to give the heads up | 17:38 |
topol | dolphm, I agree, that was my conclusion as well | 17:39 |
therve | It's because we use some custom protocol schemes in the tests | 17:39 |
topol | Im ok with removing my -1 | 17:39 |
*** jimbaker has quit IRC | 17:39 | |
therve | And the keystone middleware uses urljoin which doesn't support those | 17:39 |
topol | nkinder is very articulate in his comments :-) | 17:39 |
topol | so Im good | 17:40 |
*** thedodd has quit IRC | 17:40 | |
dolphm | therve: why do the tests do that? | 17:40 |
dolphm | therve: i mean, what's the use case they're trying to cover? | 17:40 |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation https://review.openstack.org/71181 | 17:40 |
nkinder | topol: ok, great | 17:41 |
*** praneshp has joined #openstack-keystone | 17:41 | |
ayoung | dolphm, ^^ passes py33 as well as py27. Compression is coming! | 17:41 |
therve | dolphm, Just customizing auth_protocol and see if it's reflected | 17:41 |
*** leseb has joined #openstack-keystone | 17:41 | |
therve | There wasn't any restriction previously on what was possible, now there is | 17:41 |
dolphm | therve: and urlparse.urljoin restricts the list of valid protocols? | 17:42 |
*** praneshp_ has joined #openstack-keystone | 17:42 | |
therve | dolphm, Yeah | 17:42 |
therve | If the protocol is in "uses_relative" it works, otherwise it just returns "/" | 17:43 |
*** morganfainberg_Z is now known as morganfainberg | 17:43 | |
therve | dolphm, http://paste.openstack.org/show/76156/ | 17:44 |
dolphm | therve: weird, the urlparse docs even refer to scheme:// | 17:45 |
*** praneshp has quit IRC | 17:45 | |
*** praneshp_ is now known as praneshp | 17:45 | |
*** leseb has quit IRC | 17:46 | |
*** jimbaker has joined #openstack-keystone | 17:46 | |
dolphm | therve: i'd be happy to see a patch that remove the use of urlparse.urljoin, and we can do a 0.8.1 release... but ceilometers tests are much less useful than your pasted use case | 17:47 |
morganfainberg | dolphm, ++ esp. if urljoin is as broken as described here. | 17:47 |
*** gokrokve has quit IRC | 17:47 | |
therve | dolphm, I don't know if it's a problem in practice | 17:48 |
dolphm | morganfainberg: yeah, it totally discards the base url for me | 17:48 |
therve | You probably shouldn't use anything besides https anyway :) | 17:48 |
dolphm | just because it doesn't recognize the scheme | 17:49 |
morganfainberg | therve, ++ true | 17:49 |
dolphm | therve: agree | 17:49 |
*** dstanek has joined #openstack-keystone | 17:58 | |
*** bach has joined #openstack-keystone | 18:00 | |
*** bach has quit IRC | 18:02 | |
*** tomoiaga has left #openstack-keystone | 18:02 | |
*** ilives has quit IRC | 18:03 | |
*** ilives has joined #openstack-keystone | 18:04 | |
*** praneshp has quit IRC | 18:04 | |
*** gokrokve has joined #openstack-keystone | 18:04 | |
ayoung | so...design issue on the client auth plugin. Jose's patch has "kerberos" in it. That becomes the "method" in the token request. If we make it "external" it will work with the existing plugins | 18:09 |
ayoung | but, when setting up the network connection, if we are using kerberos, we need to add the -negotiate flag | 18:09 |
ayoung | so we can't just make a generic client side plugin for external. | 18:10 |
ayoung | If we do client certs, it will have similar issues...need to explicitly add the client cert into the network setup | 18:10 |
ayoung | ...I'll wait for jamielennox|away to come back. This is really a discussion he needs to see | 18:11 |
*** gokrokve has quit IRC | 18:13 | |
dolphm | ayoung: it makes sense to use external plugins on the service side, as far as i can tell. on the client side, plugins should be single-purpose | 18:14 |
dolphm | there shouldn't be a OneSizeFitsAllPlugin :) | 18:14 |
ayoung | dolphm, so the issues is whether it should be one plugin for both Jose's version of Kerbersos (inside eventlet) and the HTTPD one...assuing we want to support Jose's approach (which I don't) | 18:15 |
ayoung | dolphm, I think the main distinction is that with "external" auth, it is mostly the set up of the HTTP connection that varies, but the body of the request will be the same | 18:17 |
dolphm | ayoung: from the client perspective? | 18:17 |
ayoung | dolphm, yeah | 18:17 |
ayoung | dolphm, there are 2 auth mechanisms we need to support: | 18:18 |
ayoung | Kerberos and X509 Client auth | 18:18 |
ayoung | for Kerberos, you set up an HTTP connection with "Negotiate" | 18:18 |
ayoung | for X509 Client auth, you set up the HTTP connection and specify the client certificate | 18:18 |
dolphm | ayoung: you could have an AbstractExternalPlugin that knows how to build the body, but doesn't know how to do any form of external auth | 18:18 |
ayoung | dolphm, so the question is whether we would want end users to distinguish between server side implementations. For example, if Kerberos is done in eventlet, then we need more processing, and it makes sense to have a specific server side plugin for that | 18:20 |
ayoung | I am not certain we want to support that. But I need to confirm with CERN that they don't really need it | 18:20 |
dolphm | ayoung: end users as in api users or deployers? hopefully api users don't need to care | 18:20 |
ayoung | I had an exchange with Jose that indicated it was not really necessary | 18:20 |
*** andreaf_ has joined #openstack-keystone | 18:21 | |
*** andreaf_ has quit IRC | 18:23 | |
*** stevemar has quit IRC | 18:23 | |
*** andreaf_ has joined #openstack-keystone | 18:23 | |
ayoung | dolphm, ok, so just for perspective: we could do BASIC_AUTH to HTTPD. This would mean that, instead of putting username and password into the request, it would go into the HTTP header. Both this form and Kerberos right now would be served by the current "external" plugin. So all of the differences would be client side to distinguish between them | 18:23 |
*** andreaf has quit IRC | 18:24 | |
ayoung | now, we could even use BASIC_AUTH inside of eventlet. | 18:24 |
ayoung | IE...do all of the code to pull username and password out of the HTTP envelope and then call identity.authenticate | 18:24 |
*** stevemar has joined #openstack-keystone | 18:24 | |
*** thedodd has joined #openstack-keystone | 18:25 | |
ayoung | I actually did a proof-of-concept of that. The thing is, I did all of the parsing in middleware, and then the "external" plugin would still execute the same unchanged | 18:25 |
ayoung | so, I'm still undecided about what the "method" should be if we do kerberos, but I am leaning toward leaving it as "external" regardless of what we call the client side plugin | 18:26 |
ayoung | Jose's implementation made the method "kerberos" | 18:26 |
*** praneshp has joined #openstack-keystone | 18:27 | |
ayoung | https://review.openstack.org/#/c/74317/ but that makes sense based on his approach: he is doing significantly more server side work | 18:27 |
dolphm | ayoung: the client side plugin "name" doesn't have to have anything to do with the api or the service side plugin | 18:27 |
ayoung | dolphm, they need to match. | 18:31 |
ayoung | dolphm, the client side plugin populate the "method" | 18:31 |
ayoung | https://review.openstack.org/#/c/74317/11/keystone/auth/plugins/kerberos.py line 35 | 18:31 |
dolphm | ayoung: i was referring to the ClassNameOfThePlugin that the user actually sees - not what's on the wire | 18:32 |
ayoung | dolphm, correct, and I would like to keep that abstraction clear. | 18:32 |
ayoung | dolphm, so, here is one approach | 18:32 |
ayoung | for each "external" server plugin we have now, we create a subclass that just changes the method name from 'external' to kerberos | 18:33 |
dolphm | ayoung: on the client side, the client.KerberosPlugin can use "methods": ["external"] in a kerberos HTTP request to a keystone service running inside httpd protected by kerberos | 18:33 |
ayoung | then, if the client sends a kerberos request of either form, it works | 18:33 |
ayoung | dolphm, yes, it can | 18:33 |
dolphm | ayoung: why do you need service-side plugins that swap out the method name for something else? | 18:34 |
dolphm | ayoung: unless the kerberos httpd mod doesn't use REMOTE_USER or something? | 18:35 |
ayoung | dolphm, here is Jose's server side plugin, which does not user REMOTE_USER | 18:35 |
dolphm | ayoung: i'm ignoring jose's plugin, and assuming we're talking about mod_auth_kerberos (?) | 18:35 |
dolphm | mod_auth_kerb* | 18:35 |
ayoung | dolphm, well, that was my initial approach. I'm OK with that. It just gets a little confusing if we do include Jose's Kerberos approach. So, either we need to modify his client patch or change some server side code | 18:36 |
*** gyee has joined #openstack-keystone | 18:37 | |
ayoung | My initial suggestion was that for "external" you don't even put the method into the auth request. Jamie pointed out that this is actually tough under the current client plugin approach, as it assumes the auth plugin adds a method to an array | 18:38 |
dolphm | ayoung: it's tough to add "external" ? | 18:38 |
ayoung | dolphm, adding extenral is not tough. It would mean that, right now, it would get double processed on the server side, but that is a simple fix | 18:39 |
*** gokrokve has joined #openstack-keystone | 18:39 | |
dolphm | ayoung: mod_auth_kerb unwraps the kerberos request, sets REMOTE_USER, and the External plugins handle REMOTE_USER -- what gets processed twice? | 18:40 |
dolphm | or am i missing something | 18:40 |
ayoung | if we put "external" into the methods, it would get processed once via REMOTE_USER explicit check, and once via processing hte list of methods | 18:41 |
ayoung | dolphm, https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L412 | 18:41 |
*** leseb has joined #openstack-keystone | 18:42 | |
*** chandan_kumar has joined #openstack-keystone | 18:43 | |
dolphm | ayoung: mod_auth_kerb *would* set REMOTE_USER, right? | 18:45 |
ayoung | dolphm, yes | 18:46 |
*** leseb has quit IRC | 18:46 | |
*** leseb has joined #openstack-keystone | 18:48 | |
*** browne has quit IRC | 18:50 | |
*** bach has joined #openstack-keystone | 18:50 | |
*** bach has quit IRC | 18:55 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Refactor test_password_hashed to the backend testers https://review.openstack.org/88399 | 18:56 |
bknudson | ^ could be merged up into the parent commit. | 18:57 |
*** dstanek has quit IRC | 18:57 | |
nkinder | bknudson: I was just going to ask you about what you had in mind for test_password_hashed | 18:58 |
nkinder | bknudson: I don't think there is really anything to do for the live LDAP tests around hashed password tests | 18:59 |
nkinder | bknudson: ideally, Keystone shouldn't even be allowed to access the password hash from LDAP (it wouldn't be able to with AD for sure) | 19:00 |
bknudson | nkinder: on my openldap system the password is different, so we could have a test to check that the password on the create is different than the one from get | 19:00 |
nkinder | bknudson: we can do that if we want the test to assume that the user that keystone binds as can read the userPassword attribute | 19:03 |
nkinder | bknudson: in general, it's a good idea to lock that down. There's no reason to expose the hash unless it's needed (and in this case, we would only need it for a test) | 19:04 |
*** erecio has quit IRC | 19:05 | |
nkinder | bknudson: I think it's of limited value. If the test fails, what can we do in keystone about it? | 19:05 |
*** erecio has joined #openstack-keystone | 19:06 | |
*** YorikSar has joined #openstack-keystone | 19:08 | |
*** bach has joined #openstack-keystone | 19:08 | |
*** marcoemorais has quit IRC | 19:09 | |
*** marcoemorais has joined #openstack-keystone | 19:10 | |
YorikSar | topol: ping | 19:10 |
YorikSar | topol: Do I remember correctly that you were giving some love to LDAP in Keystone? | 19:10 |
YorikSar | or was ayoung driving it?.. | 19:11 |
topol | Hi YorikSar, long time no talk | 19:11 |
topol | I did some but others did some as well | 19:11 |
topol | including you :-) | 19:11 |
ayoung | YorikSar, mostly been taken over by some of my team members | 19:11 |
topol | come back to the party YorikSar! | 19:11 |
ayoung | topol did the devstack work for LDAP | 19:11 |
topol | what ayoung said :-) | 19:11 |
YorikSar | topol: I was only throwing every intern I had to that LDAP fire. | 19:12 |
YorikSar | Actually I've recently thrown another one - Sergey Nikitin. | 19:12 |
topol | I think things are pretty good with LDAP now. Its much more enterprise friendly and usable | 19:12 |
topol | I have seen Sergey post some patches yes | 19:13 |
topol | YorikSar so whats going on? | 19:13 |
YorikSar | Yes. And I've suggested him another direction to dig into. He wrote to ML about that. | 19:13 |
ayoung | YorikSar, I have a few things to work on that make me want to leave LDAP to others | 19:13 |
YorikSar | I want us to have a gate job running over LDAP. | 19:14 |
YorikSar | And so I think he can make that happen. | 19:14 |
YorikSar | But I want someone to write about current state of that direction and I want to tell him who can he ask about current state of LDAP in Keystone's big picture. | 19:16 |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation https://review.openstack.org/71181 | 19:17 |
YorikSar | Current state of LDAP driver actually makes me sad... I brag that I wrote it but then I'm being asked about what can you do with it and... Well, there's a lot of features missing. | 19:18 |
topol | ayoung is the best candidate for your request if he has time, | 19:19 |
ayoung | YorikSar, we are going to reduce the features to zero, close the shop and go home. | 19:19 |
ayoung | Well, maybe not quite | 19:19 |
topol | YorikSar, even with how identity and assignment have been separated you still need a ton of gaps filled? | 19:20 |
ayoung | the goal is for LDAP to be little more than a store of user and group data consumed from some larger organizations store. The LDAP read/write approach is not really sustainable. | 19:20 |
* topol ahh ayoung with his give him a heart atack humor | 19:20 | |
topol | ayoung +++ | 19:20 |
ayoung | Try the veal! | 19:20 |
topol | two shows daily. dark on mondays | 19:21 |
YorikSar | ayoung: What do you mean by "more"? | 19:21 |
topol | YorikSar are you coming to Atlanta? | 19:22 |
*** ilives has quit IRC | 19:22 | |
YorikSar | topol: Nope. Noone in community have ever seen me in person but those who dare to come to Russia :) | 19:22 |
ayoung | YorikSar, um..."little more" really translates to "less" | 19:23 |
topol | YorikSar, any of your colleagues coming to Atlanta? | 19:23 |
YorikSar | ayoung: Ok... Now I'm completely confused :) | 19:23 |
topol | YorikSar, so wha he is saying is we are trying to keep LDAP for doing classic LDAP things (storing users and groups) and not trying to make it do and store stuff it is not accustomed to doing | 19:25 |
YorikSar | topol: Yeah. I guess, lots of them. You can punch anyone in Miranits t-shirt and there's 50% probability that it'll be someone from my office :) | 19:25 |
topol | YorikSar, can you send someone that you can brief with your concerns/issues as your ambassador? | 19:26 |
YorikSar | topol: May be... I just need to find someone with some openings in the schedule. | 19:26 |
ayoung | YorikSar, we split the identity backend, and my goal at that point was to kill the lDAP assignment backend. twas on CERN that said "we really need it" or it would be gone | 19:27 |
ayoung | that leaves users and groups | 19:27 |
ayoung | and it turns out that groups should not only come from LDAP, as we need a way to group users in Keystone, even if LDAP is read only | 19:28 |
ayoung | So...LDAP really just gives us a little bit of info about users | 19:28 |
*** dstanek has joined #openstack-keystone | 19:28 | |
ayoung | Group data from LDAP tends not to be super-useful in a Keystone context. But if what you want is there, you can use it | 19:29 |
ayoung | the real issue is how are we going to support multiple LDAP servers | 19:29 |
YorikSar | topol: Actually I think since (it looks like) noone actually doing global changes in LDAP area I think I can drive Sergey to work on it as I think it should be... | 19:29 |
ayoung | and that issue affects Federation as well | 19:29 |
ayoung | sent a message about that to openstack-dev a day or so ago | 19:30 |
topol | YorikSar, what do you mean by "global changes' Can you list some examples? | 19:31 |
YorikSar | ayoung: I must've missed it... But I really wouldn't eliminate assignment driver as well because I know there're customers who use it and we use it ourselves. | 19:32 |
ayoung | YorikSar, that data is better off in SQL than in LDAP | 19:33 |
ayoung | but, I'm willing to listen to counter arguments | 19:33 |
YorikSar | ayoung: Not if all your organisation is already managed in LDAP | 19:33 |
ayoung | YorikSar, um...no | 19:33 |
ayoung | LDAP is for data that is multi-application | 19:33 |
ayoung | Keystone is specific to Openstack | 19:34 |
ayoung | so, yeah, users and groups from LDAP, but why projects etc? | 19:34 |
ayoung | YorikSar, it means that Keystone needs to be able to write to LDAP. To do that right, we should make it such that the users LDAP ACLs are employued to limit what a user can do in LDAP, but right now we only use a single, admin member. | 19:35 |
YorikSar | ayoung: E.g. we have our internal cloud. We have some customers. We internally create "project" for each customer and it is created in Wiki, bugtracker, Gerrit and OpenStack (all our internal services that are needed by the project). | 19:35 |
ayoung | YorikSar, you have your Customers in LDAP? | 19:35 |
YorikSar | ayoung: Em... I mean, we have some team that works with a customer. It's united in some group in LDAP. | 19:36 |
ayoung | YorikSar, ah | 19:36 |
YorikSar | ayoung: So that if you add new member to that team, one gets access to all services. | 19:37 |
nkinder | YorikSar: that makes sense. You are using the "project" for other purposes than just Keystone, so you want it centralized somewhere | 19:37 |
openstackgerrit | A change was merged to openstack/keystone: Isolate backend loading https://review.openstack.org/74293 | 19:37 |
YorikSar | ayoung: iirc we have "external" accounts for customers themselves, but that's not relevant here. | 19:37 |
ayoung | YorikSar, so if you have features for LDAP, write up the BPs and lets get them reviewed | 19:38 |
nkinder | YorikSar: ...and I can understand why you'd want to just have Keystone leverage it instead of duplicating that info in SQL. | 19:38 |
ayoung | yep | 19:38 |
YorikSar | nkinder: Exactly. | 19:38 |
YorikSar | ayoung: Well, this works quite well for our internal cloud (for now). | 19:38 |
ayoung | nkinder, I guess I would summarize it as "organizations where openstack deployments are central to their business prefer to centralize all Identity in LDAP to synchronize it with Keystone" | 19:39 |
YorikSar | One huge example of what's missing for our customers is domains. | 19:39 |
nkinder | YorikSar: one customer per domain? | 19:40 |
nkinder | YorikSar: the idea as I understand it is that you would be able to map a Keystone domain to a separate LDAP server (though this could be a separate tree, etc.) | 19:40 |
YorikSar | ayoung: Even if OpenStack wasn't central for our business but just another service we use for dev/qa it would be necessary to keep all those services synchronized. | 19:40 |
YorikSar | nkinder: Not exactly. I was recently involved in discussion about one customer. They wanted to have one domain per their tenant (I'm running out of dictionary here :( ) so that every one of them could create a number of projects. | 19:42 |
YorikSar | You cannot create domains dynamically with current LDAP driver. I think there should be some way to do so though. | 19:43 |
ayoung | stevemar, do your comments on https://review.openstack.org/#/c/81166/9/keystoneclient/v3/contrib/revoke.py really call for a -1? | 19:44 |
ayoung | I don't think any of them need to be addressed. | 19:44 |
nkinder | YorikSar: There are indeed too many terms... :) | 19:45 |
ayoung | YorikSar, that would be done in SQL | 19:45 |
nkinder | YorikSar: so what do you map a customer to in this case (if not a domain)? | 19:45 |
ayoung | assignment backend supports exactly that. If you wanted it in LDAP, you could, though, | 19:45 |
ayoung | different subtree per customer | 19:45 |
*** bach_ has joined #openstack-keystone | 19:45 | |
ayoung | you need a way to make sure one customers's user_ids don't conflict with another | 19:46 |
stevemar | ayoung, i usually -1 whenever i have a question | 19:46 |
YorikSar | And I don't really know what amount of changes are going to appear after hieratchical multitenancy work. | 19:46 |
nkinder | ayoung: I was thinking separate subtree as well | 19:46 |
ayoung | stevemar, I appreciate that, but do you really want to hold up that patch? I don't really want to make the changes you suggest. | 19:46 |
stevemar | ayoung, it is no longer holding it | 19:46 |
*** zhiyan_ is now known as zhiyan | 19:46 | |
ayoung | nkinder, either in the same or different LDAP servers. | 19:47 |
stevemar | ayoung, i figure if someone does like it, they can ping me :P | 19:47 |
ayoung | stevemar, cool. thanks | 19:47 |
ayoung | stevemar, I want that in before the next time dolphm re-releases the client | 19:47 |
YorikSar | ayoung: But then every new client causes reconfiguration of Keystone. | 19:47 |
*** bach_ has quit IRC | 19:47 | |
ayoung | YorikSar, yep. The way it is written today, that is true. But we can fix that | 19:47 |
*** bach_ has joined #openstack-keystone | 19:48 | |
*** eyerediskin has joined #openstack-keystone | 19:48 | |
YorikSar | ayoung: Yes. And that's what I'm hoping to achieve with Sergey in not-so-long term. | 19:48 |
ayoung | YorikSar, I could see making the subtree value overridable with something domain specific | 19:48 |
nkinder | ayoung: exactly | 19:49 |
ayoung | YorikSar, but just solving multiple domains in a single LDAP server does not get the full range of use cases. I want to have something that works for Multiple LDAP servers, and for Federation (SAML) coming from multiple IdPs as well | 19:49 |
nkinder | ayoung: adding a new domain would create an ou=<domain> container | 19:49 |
YorikSar | ayoung: Are there actual usecases for multiple LDAP servers? | 19:50 |
ayoung | nkinder, that would be the logical approach, but what if there are two different LDAP servers? Which one does it create it in? | 19:50 |
*** amcrn has quit IRC | 19:50 | |
*** bach has quit IRC | 19:50 | |
ayoung | YorikSar, yes. Ask topol about that. henrynash, too, when he's around | 19:50 |
nkinder | ayoung: we need to support both cases I would think | 19:50 |
ayoung | YorikSar, Mergers and Acquisitions often lead to multiple LDAP cases | 19:50 |
ayoung | nkinder, I could see a need for a setup like this: | 19:50 |
ayoung | One ldap for employees | 19:51 |
nkinder | ayoung: for the multiple LDAP case (or the federation/SAML case), we would need to have config to map a domain to an IdP | 19:51 |
ayoung | one for customers | 19:51 |
ayoung | and some sort of local store for service users | 19:51 |
YorikSar | ayoung: Oh... Ok, I didn't think about that level of legacy... | 19:51 |
ayoung | nkinder, that is one reason I was considering pulling the domain table out of both the identity and assignment backends | 19:51 |
ayoung | YorikSar, lots of different classes of implementations | 19:52 |
nkinder | ayoung: and making it purely config? | 19:52 |
ayoung | nkinder, It should be dynamic. | 19:52 |
nkinder | ayoung: so where would domains be stored? A new backend? | 19:52 |
ayoung | nkinder, but I figured leaving it in assignment would work | 19:53 |
YorikSar | ayoung: Are those nested projects going to become replacement for domains? | 19:53 |
ayoung | we would need a field in there for "IdP" and maybe "assignemnt store" | 19:53 |
ayoung | YorikSar, good questions. I would say this: | 19:53 |
YorikSar | Because if they are then those mappings are going to be very complicated. | 19:53 |
ayoung | a domain should become a project that has no parent | 19:53 |
ayoung | we keep the term, because removing terms never happens | 19:54 |
YorikSar | ayoung: But it will be used only for backward compatibility? | 19:54 |
*** bach_ has quit IRC | 19:54 | |
ayoung | YorikSar no. a domain is the top level namespace | 19:54 |
*** bach has joined #openstack-keystone | 19:55 | |
ayoung | YorikSar, ok, there is a division in vision here | 19:55 |
ayoung | I want to keep the term Domain, and say that a single IdP can support multiple domains | 19:55 |
YorikSar | ayoung: I'm just thinking that nested projects can look very good in LDAP. But if we special-case some level, it might make it harder to implement. | 19:55 |
ayoung | a domain will contain users and groups on the identity side | 19:56 |
ayoung | and on the assignment sid,e a domain will contain projects | 19:56 |
ayoung | a domain can have two different data stores, one for Identity, one for Assignments | 19:56 |
ayoung | the simplest case is that everything is in SQL | 19:57 |
YorikSar | ayoung: Hm... And what would be the use of multiple domains within one IdP? Only to store service users in separate backend? | 19:57 |
ayoung | YorikSar, employees versus partners versus customers? | 19:58 |
ayoung | YorikSar, IdP as exposed by SAML can be thought of as a crypto version of a pushed LDAP query | 19:59 |
ayoung | just a signed document with the results so you don';t need direct access to the server | 19:59 |
nkinder | ayoung: if you're thinking of that in terms of LDAP as the IdP, wouldn't that be multiple trees (or use of filters to identify different classes of users)? | 19:59 |
ayoung | so M&A with multiple trees in a single LDAP server pushed via SAML makes sense to me | 19:59 |
ayoung | nkinder, ++ zactly! | 20:00 |
nkinder | I almost think of that as a separate IdP (that happens to be a different set of entries from the same LDAP server) | 20:00 |
ayoung | nkinder, way I see it, the only difference between SAML and LDAP is in LDAP, Keystone instigates the query | 20:00 |
ayoung | so IdP is the server, and Domain is the subtree | 20:01 |
*** erecio has quit IRC | 20:01 | |
YorikSar | ayoung: So... For example, that customer that wants his customers to create projects and stuff. They can have a separate domain with tree of projects for their customers and a separate domain (probably SQL-based) for admins. | 20:01 |
*** erecio has joined #openstack-keystone | 20:01 | |
nkinder | ayoung: so to define a LDAP IdP, what info is used? host, port, bind DN/cred? | 20:01 |
nkinder | ayoung: and domain would specify base DN and filter? | 20:02 |
ayoung | nkinder, plus filters | 20:02 |
ayoung | the tree structure might be different between subtrees in the same LDAP | 20:02 |
nkinder | ayoung: filters where? In IdP, or domain? | 20:02 |
*** stevemar has quit IRC | 20:03 | |
ayoung | think of a M&A case where they just consolidate to a single LDAP infrastructure but left the origianl org structures intact | 20:03 |
nkinder | To me, IdP equals all of the LDAP config (host/port, bind info , base DN + filter) | 20:03 |
nkinder | domain is a name that maps to the IdP config | 20:03 |
*** eyerediskin has quit IRC | 20:03 | |
nkinder | You can have multiple IdPs where they are the same LDAP server, but perhaps just a different base DN or filter | 20:03 |
ayoung | nkinder, true | 20:04 |
nkinder | it's still a separate IdP | 20:04 |
*** eyerediskin has joined #openstack-keystone | 20:04 | |
YorikSar | nkinder: And you can have one IdP looking at several LDAP servers. | 20:04 |
ayoung | NO! | 20:04 |
ayoung | YorikSar, no no no no no no no no no | 20:04 |
YorikSar | ayoung: Oh... :( | 20:04 |
YorikSar | ayoung: Then I must've missed smth. | 20:05 |
YorikSar | ayoung: I though M&A case is exactly about that. | 20:05 |
ayoung | YorikSar, an IdpP is a single point to query | 20:05 |
ayoung | splitting across multiple LDAP makes Keystone responsible for providing a facade across them | 20:06 |
*** browne has joined #openstack-keystone | 20:06 | |
ayoung | YorikSar, 1 IdP to 1+ Domains | 20:06 |
ayoung | If you split across multiple LDAP, each would be its own domain | 20:07 |
ayoung | maybe more than one, but a domain would never be spread across multiple IdPs | 20:07 |
YorikSar | ayoung: IdP config for me is like (server creds, tree designations). Why not have separate IdP for each domain with their own trees then? | 20:08 |
ayoung | YorikSar, Maybe | 20:09 |
ayoung | It might be that, for LDAP, that is the way we go. | 20:09 |
ayoung | RIght now, Multiple Domains can be stored in SQL | 20:09 |
ayoung | so we have at least one case where multiple domains are in the same datasources | 20:09 |
ayoung | We are not going to remove that abstraction, but it might not be equally distributed | 20:09 |
nkinder | YorikSar: One IdP is one server as ayoung said | 20:10 |
YorikSar | ayoung: We can make the same trick with SQL actually. | 20:10 |
YorikSar | ayoung: It might make architechture clearer. | 20:10 |
ayoung | YorikSar, and, for your use case, with LDAP. I can think of how we make it work that you can create a new LDAP domain in an existing LDAP setup | 20:11 |
nkinder | ayoung: For that case, I see a config option where you say "all domains are just subtree's in this one LDAP server" | 20:11 |
*** topol has quit IRC | 20:12 | |
YorikSar | ayoung: If we have nested projects, dynamic creation of domains might not be needed at all. | 20:13 |
ayoung | nkinder, maybe....that seems pretty specific to me, and if we can keep the abstractions clean, we might get something a little more flexible. | 20:13 |
ayoung | YorikSar, you will need it for users | 20:13 |
YorikSar | ayoung: But we'll need to bind users to those projects so that project admin can manage his users. | 20:14 |
dstanek | any reason not to +A https://review.openstack.org/#/c/88109/? | 20:14 |
ayoung | and on the assingment side, a domain can bve thought of as a top level project | 20:14 |
nkinder | dstanek: I think it's a fabulous patch that should be approved. ;) | 20:14 |
ayoung | dstanek, done | 20:14 |
YorikSar | Ok, I'm going to sleep now. ayoung, topol, nkinder, thanks for enlightening me on current state of domains. If anyone of you have some info on LDAP gating, please write a reply to Sergey's thread in ML. | 20:20 |
ayoung | ++ | 20:20 |
nkinder | YorikSar: Sure! I'll take a look at the thread. | 20:20 |
*** amcrn has joined #openstack-keystone | 20:20 | |
nkinder | YorikSar: LDAP gating sounds like a great idea | 20:21 |
YorikSar | Thanks | 20:21 |
*** chandan_kumar has quit IRC | 20:22 | |
ayoung | nkinder, we'll do it when we can gate in the same run on both SQL and LDAP | 20:23 |
eyerediskin | hi all. not sure if this bug: https://bugs.launchpad.net/python-keystoneclient/+bug/1309180 | 20:28 |
uvirtbot | Launchpad bug 1309180 in python-keystoneclient "nothing works when only externalURL available" [Undecided,New] | 20:28 |
eyerediskin | could someone take a look? ^ | 20:28 |
*** jsidhu has joined #openstack-keystone | 20:30 | |
ayoung | eyerediskin, works as designed | 20:30 |
ayoung | you are trying to do an admin operations | 20:30 |
*** andreaf_ has quit IRC | 20:31 | |
*** andreaf_ has joined #openstack-keystone | 20:31 | |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Example Initialization scripts https://review.openstack.org/82687 | 20:32 |
*** marcoemorais has quit IRC | 20:32 | |
*** erecio has quit IRC | 20:32 | |
*** marcoemorais has joined #openstack-keystone | 20:32 | |
*** erecio has joined #openstack-keystone | 20:33 | |
bknudson | does/should keystone require that a user ID can't be the same as a group ID? | 20:35 |
bknudson | not sure how keystone could require that with a read-only ldap | 20:35 |
jsidhu | using the REST Identity API, is it possible to get a list of users that have been granted access to a domain? Dont see a way describing this in the doc: http://api.openstack.org/api-ref-identity-v3.html | 20:37 |
jsidhu | the only way i can tihnk of is to test every user id and see if there’s a role for it via /v3/domains/__DOMAIN_ID__/users/__USER_ID__/roles" | 20:38 |
*** dstanek has quit IRC | 20:41 | |
*** dstanek has joined #openstack-keystone | 20:41 | |
ayoung | bknudson, hmmm | 20:46 |
ayoung | jsidhu, I thought we had that covered | 20:46 |
*** bach has quit IRC | 20:47 | |
ayoung | something aboiut list roles with afilter | 20:47 |
jsidhu | in v3? | 20:47 |
bknudson | ayoung: jsidhu: GET /v3/role_assignments ? | 20:47 |
bknudson | I don't know if that works for domain scope | 20:48 |
ayoung | bknudson, with ?domain_id=<id> right? | 20:48 |
jsidhu | role_assignments <— giggity giggity | 20:48 |
jsidhu | thank you gentlement | 20:48 |
jsidhu | gentlemen* | 20:48 |
ayoung | it should | 20:48 |
bknudson | scope.domain.id (string) | 20:48 |
ayoung | jsidhu, there you go calling us names | 20:48 |
bknudson | the docs on http://api.openstack.org/api-ref-identity-v3.html#Role_Calls could use some help here | 20:49 |
ayoung | ROBOT ROLE CALL! | 20:49 |
bknudson | CRRROOOOWWWW | 20:49 |
jsidhu | thank you sirs | 20:49 |
jsidhu | yes, this is exactly what i needed. thanks | 20:51 |
*** Anju_ has quit IRC | 20:51 | |
*** erecio has quit IRC | 20:53 | |
ayoung | dolphm, you know what would be really cool? If recheck ran only those tests that failed. | 20:55 |
*** derek_c has joined #openstack-keystone | 20:56 | |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values https://review.openstack.org/76002 | 20:57 |
*** marcoemorais has quit IRC | 20:57 | |
*** marcoemorais has joined #openstack-keystone | 20:58 | |
*** jagee has quit IRC | 21:03 | |
*** david-lyle has quit IRC | 21:04 | |
dolphm | ayoung: i've assumed that was part of the goal in moving everyone to testrepository, but i'm not sure what the next step is | 21:04 |
dstanek | ayoung: and if elastic recheck would just run them for you | 21:04 |
dolphm | dstanek: it will, eventually. assuming it recognizes *all* your failures | 21:04 |
ayoung | dolphm, lets not get personal | 21:05 |
dstanek | dolphm: i'd be happy if it just ran the builders that failed | 21:05 |
dolphm | ayoung: lol | 21:05 |
dstanek | dolphm: that could take *forever* | 21:05 |
dolphm | dstanek: that's also just a limitation of the quality+quantity of queries we feed it | 21:06 |
ayoung | yeah. it just would be nice if recheck just quickly ran through the failing tests. | 21:06 |
dolphm | i'm sure infra would love the reduced load | 21:06 |
*** andreaf_ has quit IRC | 21:06 | |
*** leseb has quit IRC | 21:09 | |
*** leseb has joined #openstack-keystone | 21:11 | |
ayoung | nkinder, I want to update http://openstack.redhat.com/index.php?title=Keystone_integration_with_IDM with information about the split backend for assignments. What is the right way to refer to the Havana release in RDO? | 21:12 |
*** gokrokve has quit IRC | 21:19 | |
*** eyerediskin has left #openstack-keystone | 21:20 | |
dstanek | ayoung: this one confuses me https://review.openstack.org/#/c/84444 - is it preparing for a move to Alembic? | 21:21 |
dstanek | ayoung: or is it just handling a difference in the my certain MySQL versions work | 21:22 |
ayoung | dstanek, I thought it was just dealing with MySQL issues, and using Alembic as an explanation of why | 21:22 |
ayoung | But it does look like he's prepping for moving to Alembic | 21:22 |
dstanek | it's also a little wierd to have the same index twice with 2 different names | 21:23 |
ayoung | I just saw it as prep work for solving https://bugs.launchpad.net/keystone/+bug/1292591 | 21:23 |
uvirtbot | Launchpad bug 1292591 in keystone "Database models differs from migrations." [Medium,In progress] | 21:23 |
ayoung | ? | 21:24 |
ayoung | Oooh, should he be deleting indexes as well? | 21:24 |
ayoung | he has the redundant index fix | 21:25 |
ayoung | does that address it? If so, should probably be in the same patch | 21:25 |
ayoung | nah, its not a migration | 21:26 |
ayoung | dstanek, removed my approval, and added a question to that one.. | 21:31 |
dstanek | ayoung: the redundant index is different | 21:31 |
ayoung | dstanek, yep | 21:32 |
*** leseb has quit IRC | 21:32 | |
*** bach has joined #openstack-keystone | 21:34 | |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values https://review.openstack.org/76002 | 21:34 |
dstanek | ayoung: ^ i think that is pretty good, but I'm no LDAP expert | 21:39 |
ayoung | dstanek, the change to the file removing the override for live LDAP is a good sign | 21:40 |
ayoung | dstanek, can you tell Red Hat finally assingned people that knew what they were doing RE LDAP? I expect to be fired at any point now. | 21:42 |
ayoung | People who can type, too. | 21:43 |
dstanek | ayoung: let's hope that doesn't happen. | 21:43 |
dstanek | it does make me feel like i should actually read the LDAP book i bought so that i have a clue | 21:44 |
ayoung | dstanek, none of this stuff is in the books | 21:44 |
*** bach has quit IRC | 21:44 | |
dstanek | ayoung: i know next to nothing about directory services in general, so anything to get me started would be good | 21:45 |
ayoung | dstanek, I would Highly suggest you install and play with FreeIPA | 21:45 |
dstanek | i was thinking about setting up an LDAP service to control some of the stuff in my house as a learning experiment | 21:45 |
ayoung | Its not going to teach you all of the nasty edge cases | 21:45 |
ayoung | but it gives you LDAP, Kerberos, DNS, and A Certificate Authority | 21:46 |
dstanek | ayoung: i'll take a look this weekend and start poking around | 21:46 |
ayoung | dstanek, ++ | 21:46 |
dstanek | i'll need something to do while i'm sitting around at the inlaw's house | 21:47 |
ayoung | lots of good people in #freeipa to help out with N00b questions. You'll recognize a few of them | 21:47 |
*** bach has joined #openstack-keystone | 21:48 | |
bknudson | while LDAP has a lot of features there really only a few that are ever used | 21:48 |
bknudson | create a user and validate a password | 21:48 |
ayoung | bknudson, one nice thing about FreeIPA is that it makes a few of them much more attainable. Like centralized SUDO | 21:49 |
bknudson | yes, the real promise is centralization of users | 21:49 |
ayoung | Plus Kerberos really needs LDAP, and Kerberos is a really powerful SSO | 21:49 |
bknudson | and auth stuff | 21:49 |
*** bach_ has joined #openstack-keystone | 21:49 | |
bknudson | if LDAP wasn't invented there'd probably be a web service for this kind of thing | 21:49 |
bknudson | but now we're stuck with it | 21:50 |
*** bach_ has quit IRC | 21:51 | |
*** bach has quit IRC | 21:53 | |
*** browne has quit IRC | 21:53 | |
ayoung | bknudson, there is an LDAP->web effort I've seen that looks promising | 21:54 |
*** bach has joined #openstack-keystone | 21:55 | |
ayoung | http://marginnotes2.wordpress.com/2013/03/04/opendj-rest-to-ldap-gateway/ | 21:55 |
ayoung | I think edewata worked on that, or something really similar | 21:55 |
ayoung | bknudson, but FreeIPA is basically that web service: | 21:56 |
bknudson | yea, but you'd probably get better results by forgetting LDAP and writing a directory web service from first principles. | 21:56 |
richm | 389 had a DSMLv2 gateway several years ago | 21:56 |
ayoung | bknudson, no no no no no | 21:56 |
ayoung | second systems syndrome extroidanaire | 21:56 |
bknudson | that sounds suspiciously like XML | 21:56 |
richm | it is | 21:56 |
ayoung | bknudson, several years ago, everything was XML | 21:57 |
ayoung | these guys have been doing this for a long time | 21:57 |
richm | DSMLv2 gateway is about 10 years old | 21:57 |
ayoung | I wasn't kidding when I said I was second string. | 21:57 |
bknudson | I worked on IBM LDAP server when I started here... 15 yrs ago. | 21:57 |
ayoung | 389 DS used to be known as Fedora Directory Server. Before that it was Netscape Directory Server | 21:57 |
richm | tivoli? | 21:57 |
bknudson | richm: it was eventually renamed to tivoli | 21:58 |
richm | did you work with Ellen? | 21:58 |
bknudson | richm: I don't remember an ellen... | 21:58 |
bknudson | our group was porting it to iSeries (AS400) | 21:58 |
nkinder | we're familiar with the rename-game... | 21:58 |
richm | can't remember her last name - she did some work in IETF on ldap | 21:58 |
nkinder | netscape DS -> iplanet DS -> netscape DS -> fedora DS -> 389 DS | 21:59 |
nkinder | then there is the whole other branch from SunDS -> oracle java something something | 21:59 |
ayoung | nkinder, and we have engineers that worked on it the whole time. I've only been doing this stuff for, what, four years now. I'm a neophyte | 22:00 |
nkinder | richm: Ellen Stokes? | 22:01 |
bknudson | richm: I think I remember the name... maybe she was a manager of the austin bunch | 22:02 |
richm | yes | 22:02 |
richm | in Austin | 22:02 |
richm | that's her | 22:02 |
*** bach has quit IRC | 22:03 | |
nkinder | ayoung: that IdM page needs some work | 22:03 |
ayoung | nkinder, yep | 22:03 |
nkinder | ayoung: it uses OU entries, which IPA doesn't really play nicely with | 22:03 |
ayoung | I was just hacking on it | 22:03 |
*** bach has joined #openstack-keystone | 22:04 | |
ayoung | nkinder, we need to strike all of the Assignment stuff | 22:04 |
nkinder | ayoung: it's on my list to set up and clean-up | 22:04 |
nkinder | ayoung: feel free to take a pass, but I'll likely be doing the same very soon | 22:04 |
ayoung | nkinder, let me, and you can edit | 22:04 |
ayoung | nkinder, I have IPA as a backend to devstack. But I need to swap my packstack install to use it as well, and that will be interesting on the systemd side of things | 22:05 |
ayoung | nkinder, plus, CA integration is going to require some work if we want Dogtag to handle the certs | 22:06 |
ayoung | for signing | 22:06 |
nkinder | ayoung: what I want that doc to move away from is doing direct LDAP entry creation. For example, the enabled users group should be created using IPA commands | 22:06 |
ayoung | nkinder, we can and should drop all of that | 22:07 |
ayoung | use swql for assignments | 22:07 |
ayoung | sql | 22:07 |
ayoung | and then no custom LDAP at all | 22:07 |
ayoung | the custom ldap was only needed for the additional schemas, and I would highly recommend we distance ourselves from that | 22:07 |
ayoung | nkinder, I would love it if we could get away from creating service users at all. THey should be service principals in IPA | 22:09 |
*** bach has quit IRC | 22:10 | |
ayoung | nkinder, which would tie in nicely with the proposal for Tokenless operations. | 22:12 |
nkinder | ayoung: yes, it's a hack around the non-standard "enabled" attribute | 22:12 |
ayoung | nkinder, actually, we might be able to do away with service users altogether with revoke events | 22:12 |
ayoung | I don't think there is any operations that will be "admin only" for token validation | 22:13 |
ayoung | there are | 22:13 |
ayoung | with revocation events, any non-privilidged user can validate tokens | 22:13 |
*** browne has joined #openstack-keystone | 22:14 | |
ayoung | morganfainberg, with ephemeral, can we drop service users? | 22:15 |
* ayoung is getting excited about this. | 22:15 | |
*** ayoung is now known as ayoung-afk | 22:17 | |
*** lbragstad has quit IRC | 22:20 | |
*** bknudson has quit IRC | 22:21 | |
*** david-lyle has joined #openstack-keystone | 22:23 | |
*** david-lyle has quit IRC | 22:29 | |
gyee | ayoung, nkinder, any plan to resurrect this one? https://review.openstack.org/#/c/47441/ | 22:29 |
*** zhiyan is now known as zhiyan_ | 22:29 | |
nkinder | gyee: yes, it needs to be picked back up (just haven't had the time) | 22:31 |
nkinder | gyee: there are quite a few performance related optimizations that could be made around LDAP | 22:31 |
gyee | nkinder, can you restore it, I can help you along the way | 22:31 |
nkinder | gyee: I was running wireshark yesterday while adding users to keystone and noticed this chain of operations... | 22:32 |
gyee | we are seeing anywhere from 3 to 10 seconds per auth, when under load | 22:32 |
gyee | 4 full SSL roundtrips to LDAP per auth at the minimum right now | 22:32 |
nkinder | gyee: bind, search for user by sn, unbind, bind, search for user by cn, unbind, bind, add, unbind | 22:33 |
gyee | nkinder, if we use dogpile to cache the user_id/user_name to DN mapping that should help quite a bit | 22:33 |
gyee | and maintain a persistent session for all the lookups | 22:33 |
nkinder | connection pooling would be nice... I know morganfainberg was looking at that a little while ago | 22:37 |
gyee | connection pooling maybe a bit tough in a multiprocess environment | 22:38 |
*** thedodd has quit IRC | 22:42 | |
nkinder | gyee: you could do a single connection (or pool) per process | 22:42 |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values https://review.openstack.org/76002 | 22:43 |
*** rwsu has quit IRC | 22:44 | |
nkinder | gyee: I'll resurrect that one and take a look at cleaning it up | 22:45 |
*** rwsu has joined #openstack-keystone | 22:48 | |
gyee | nkinder, thanks | 22:58 |
*** wchrisj_ has quit IRC | 23:02 | |
*** wchrisj has joined #openstack-keystone | 23:18 | |
*** daneyon_ has quit IRC | 23:27 | |
*** wchrisj has quit IRC | 23:28 | |
*** wchrisj has joined #openstack-keystone | 23:35 | |
*** wchrisj has quit IRC | 23:38 | |
*** praneshp_ has joined #openstack-keystone | 23:39 | |
*** praneshp has quit IRC | 23:40 | |
*** praneshp_ is now known as praneshp | 23:40 | |
openstackgerrit | A change was merged to openstack/keystone: Cleanup of test_cert_setup tests https://review.openstack.org/84550 | 23:41 |
*** wchrisj has joined #openstack-keystone | 23:41 | |
*** wchrisj has quit IRC | 23:44 | |
*** praneshp_ has joined #openstack-keystone | 23:48 | |
*** praneshp has quit IRC | 23:50 | |
*** praneshp_ is now known as praneshp | 23:50 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!