*** tellesnobrega_ has joined #openstack-keystone | 00:04 | |
*** henrynash has quit IRC | 00:10 | |
*** henrynash has joined #openstack-keystone | 00:12 | |
*** ChanServ sets mode: +v henrynash | 00:12 | |
*** htruta_ has joined #openstack-keystone | 00:14 | |
*** jorge_munoz has left #openstack-keystone | 00:19 | |
*** kobtea has joined #openstack-keystone | 00:30 | |
samuelms_ | dolphm, is this still valid? https://bugs.launchpad.net/keystone/+bug/963176 | 00:30 |
---|---|---|
uvirtbot | Launchpad bug 963176 in keystone "Document should report that Users must have at least one role" [Medium,Incomplete] | 00:30 |
*** dims_ has quit IRC | 00:30 | |
morganfainberg | samuelms_, that is likely still valid. i mean, you *could* have no roles, but it really becomes very strange. | 00:32 |
morganfainberg | but honestly, we might be ok if that goes away | 00:32 |
samuelms_ | morganfainberg, so we need to set to 'wont fix'? | 00:34 |
morganfainberg | incomplete will expire out and disappear in 54 days | 00:34 |
samuelms_ | 59 days, since I just messed up | 00:35 |
*** kobtea has quit IRC | 00:35 | |
samuelms_ | status: Incomplete → Opinion | 00:35 |
samuelms_ | status: Opinion → Incomplete | 00:35 |
samuelms_ | morganfainberg, only core-reviewers can set a bug report to triaged/wont fix? | 00:36 |
morganfainberg | right | 00:36 |
morganfainberg | opinion also pretty much disappears | 00:36 |
* morganfainberg never looks at opinion bugs ever | 00:36 | |
samuelms_ | morganfainberg, what does 'opinion' means in this context? | 00:37 |
morganfainberg | like "wont fix" but more like "you think this is something and we don't" | 00:38 |
samuelms_ | morganfainberg, hmm.. so that's something I could do like: 'hey, you're making a mistake' | 00:39 |
samuelms_ | morganfainberg, and a core then mark it as wont fix ('yes, this wrong, get out of here') | 00:40 |
samuelms_ | :p | 00:40 |
morganfainberg | eh | 00:40 |
morganfainberg | i mean i'd discourage people from marking bugs as opinion because it makes them disappear | 00:40 |
morganfainberg | like i said, i *never* look at opinion bugs | 00:40 |
samuelms_ | morganfainberg, ok | 00:41 |
samuelms_ | didnt pay attention at morganfainberg never looks at opinion bugs ever | 00:41 |
morganfainberg | similar to the way i don't go back and look at wont fix bugs or invalid unless someone brings them back to an active state | 00:42 |
samuelms_ | makes sense | 00:42 |
samuelms_ | morganfainberg, how much time a day you reserve for reviewing patches? | 00:42 |
morganfainberg | i don't have a fixed amount | 00:42 |
morganfainberg | but i can tell you tuesdays is next to nothing | 00:43 |
morganfainberg | just because i have at least 4 meetings. | 00:43 |
*** chrisshattuck has quit IRC | 00:43 | |
samuelms_ | lol lot of meetings | 00:44 |
samuelms_ | I'll try to reserve at least 2h/day to do reviews .. | 00:44 |
samuelms_ | I think it's the best way to know what's going on | 00:45 |
stevemar | morganfainberg, i was idle | 00:48 |
stevemar | i am now sorta here, at best | 00:49 |
openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Improves feedback message in SSL error https://review.openstack.org/129769 | 00:49 |
*** david-lyle is now known as david-lyle_afk | 00:51 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystonemiddleware: Adds Memcached dependencies doc https://review.openstack.org/134993 | 00:52 |
*** nkinder has joined #openstack-keystone | 00:52 | |
openstackgerrit | Merged openstack/keystone: Use _ definition from keystone.i18n https://review.openstack.org/132116 | 00:56 |
openstackgerrit | wanghong proposed openstack/python-keystoneclient: add missing user-id option to auth.identity.generic.password https://review.openstack.org/132626 | 01:04 |
*** stevemar has quit IRC | 01:05 | |
*** gokrokve has quit IRC | 01:06 | |
*** esp has left #openstack-keystone | 01:13 | |
jamielennox | morganfainberg: do you have any ideas on where the context object should live? | 01:15 |
jamielennox | or anyone else here | 01:15 |
jamielennox | i'm almost certain oslo.context is a bad idea | 01:16 |
jamielennox | but is our upcoming policy engine extract supposed to contain like a middleware piece? is it allowed to contain that much keystone specific information if it's not a keystone or oslo branded project | 01:17 |
jamielennox | ayoung-dad-mode: ^ | 01:17 |
rodrigods | Haneef, did you have some time to revisit https://review.openstack.org/#/c/130277/ and check Raildo's comments? | 01:17 |
*** tellesnobrega_ has quit IRC | 01:23 | |
*** tellesnobrega_ has joined #openstack-keystone | 01:29 | |
openstackgerrit | David Stanek proposed openstack/python-keystoneclient: Removes confusing _uuid property https://review.openstack.org/137253 | 01:30 |
*** dimsum__ has joined #openstack-keystone | 01:30 | |
*** r-daneel has quit IRC | 01:32 | |
*** dimsum__ has quit IRC | 01:36 | |
*** dimsum__ has joined #openstack-keystone | 01:37 | |
*** diegows has quit IRC | 01:37 | |
*** jacorob_ has joined #openstack-keystone | 01:39 | |
*** dimsum__ has quit IRC | 01:41 | |
ayoung-dad-mode | jamielennox, keystoneclient...or keystonecommon if we do that | 01:42 |
jamielennox | yea, i'm just tryng to figure out how | 01:42 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Allow users to change own default_project_id https://review.openstack.org/137254 | 01:44 |
jamielennox | and whether we need to stop oslo.context | 01:45 |
jamielennox | does context creation want to be its own middleware, or should it hang off the plugin? | 01:46 |
*** dimsum__ has joined #openstack-keystone | 01:53 | |
ayoung-dad-mode | we need to stop oslo context | 02:01 |
*** ayoung-dad-mode is now known as ayoung | 02:01 | |
ayoung | it is not a middleware, but there will be multiple builders. | 02:02 |
*** lhcheng has quit IRC | 02:04 | |
*** _cjones_ has quit IRC | 02:08 | |
jamielennox | multiple builders? | 02:14 |
*** raildo_ has joined #openstack-keystone | 02:24 | |
*** richm has quit IRC | 02:27 | |
*** erkules_ has joined #openstack-keystone | 02:28 | |
*** erkules has quit IRC | 02:30 | |
*** raildo_ has quit IRC | 02:35 | |
*** erkules_ is now known as erkules | 02:36 | |
*** NM has joined #openstack-keystone | 02:38 | |
*** htruta_ has quit IRC | 02:49 | |
*** gokrokve has joined #openstack-keystone | 02:52 | |
*** gokrokve has quit IRC | 02:52 | |
*** dimsum__ has quit IRC | 02:52 | |
*** gokrokve has joined #openstack-keystone | 02:52 | |
*** gokrokve has quit IRC | 02:53 | |
*** gokrokve has joined #openstack-keystone | 02:53 | |
*** gokrokve has quit IRC | 02:54 | |
*** gokrokve has joined #openstack-keystone | 02:55 | |
*** raildo_ has joined #openstack-keystone | 02:57 | |
*** gokrokve has quit IRC | 02:59 | |
*** NM has quit IRC | 02:59 | |
*** gokrokve has joined #openstack-keystone | 02:59 | |
*** gokrokve has quit IRC | 02:59 | |
*** gokrokve has joined #openstack-keystone | 02:59 | |
*** gokrokve has quit IRC | 03:00 | |
*** gokrokve has joined #openstack-keystone | 03:00 | |
*** fifieldt has joined #openstack-keystone | 03:01 | |
*** gokrokve has quit IRC | 03:05 | |
*** gokrokve has joined #openstack-keystone | 03:05 | |
*** gokrokve has quit IRC | 03:06 | |
*** gokrokve has joined #openstack-keystone | 03:07 | |
*** gokrokve has quit IRC | 03:07 | |
*** gokrokve has joined #openstack-keystone | 03:08 | |
*** gokrokve has quit IRC | 03:08 | |
*** gokrokve has joined #openstack-keystone | 03:12 | |
*** gokrokve has quit IRC | 03:17 | |
*** raildo_ has quit IRC | 03:24 | |
*** harlowja is now known as harlowja_away | 03:29 | |
*** _cjones_ has joined #openstack-keystone | 03:36 | |
*** _cjones_ has quit IRC | 03:37 | |
*** _cjones_ has joined #openstack-keystone | 03:38 | |
jamielennox | ayoung: still here? | 03:39 |
ayoung | jamielennox, yep | 03:39 |
jamielennox | ayoung: so with this context, i've already got an auth plugin that i'm passing out of auth_token | 03:39 |
ayoung | "this context" meaning what? | 03:40 |
jamielennox | i'm torn between whether i should just reuse that and make it do the context interface | 03:40 |
ayoung | you mean instead of what I submitted for review as a WIP? | 03:40 |
jamielennox | ayoung: where did you submit? | 03:41 |
ayoung | https://review.openstack.org/#/c/137231/ jamielennox | 03:41 |
jamielennox | ayoung: pshh, server side is for chumps :) | 03:41 |
ayoung | jamielennox, heh. Need it server side first | 03:42 |
jamielennox | ayoung: different things | 03:42 |
ayoung | well *I* need it server side first | 03:42 |
jamielennox | so there's this: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/context.py | 03:42 |
ayoung | yes, it is meant to replace that | 03:43 |
jamielennox | https://github.com/openstack/nova/blob/master/nova/context.py | 03:43 |
jamielennox | etc | 03:43 |
ayoung | the general rule is parse to canonical, munge to required form | 03:43 |
jamielennox | glance as well | 03:43 |
ayoung | so we get a good canonical representation first | 03:43 |
ayoung | user_idt is an interesting approach | 03:44 |
jamielennox | ayoung: so i don't know if all the type safe stuff is required but whatever | 03:44 |
ayoung | heh | 03:44 |
jamielennox | i'm looking at what is sent into policy in non-keystone services | 03:44 |
ayoung | nothing is required. It just is good programming practice | 03:44 |
ayoung | right | 03:45 |
jamielennox | currently they all create there own dict object | 03:45 |
jamielennox | which is loosely based around that incubator one | 03:45 |
jamielennox | and that's what's being extracted into oslo.context | 03:45 |
ayoung | that is what the token_to_auth_context code is supposed to do, once I get it right: | 03:46 |
ayoung | I don't need to copy it | 03:46 |
jamielennox | i already have https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L627 | 03:46 |
jamielennox | what i'm wondering is if i just put the same to_dict, from_dict on that | 03:46 |
ayoung | jamielennox, yes, but that assumes the form you've gotten in the token as a starting point | 03:47 |
*** amcrn has quit IRC | 03:47 | |
ayoung | I need to solve a wider array of problems, namely building the token up in the first place, as well as revocation events | 03:47 |
jamielennox | no, it assumes nothing | 03:47 |
jamielennox | ayoung: which is why i consider client/server different things | 03:47 |
ayoung | No | 03:47 |
ayoung | the code in the client is going to run in the server eventually | 03:47 |
ayoung | I need to fix the revocation evetns, and refresh that patch | 03:48 |
ayoung | this will come over when I do that | 03:48 |
jamielennox | there's no reason non-keystone services need the ability to create tokens | 03:48 |
jamielennox | this stuff is tightly coupled to auth_token middleware - i don't think it's relevant outside | 03:49 |
jamielennox | although i'm wondering whether i should have included it in auth_token middleware or made it a seperate piece | 03:49 |
jamielennox | anyway, all i would need to do is convert that _UserAuthPlugin into something with a to_dict() that matches what is currently required for policy | 03:50 |
ayoung | the term token is horrible. It is no diffrent than cookie. It means nothing except "remote handle to data" so...lets kindof ignore that for a moment., | 03:50 |
ayoung | all this is to get the authorization data from keystone | 03:50 |
ayoung | call it auth context, or accsees info | 03:50 |
ayoung | they all need the same thing, and we are distributing our business logic | 03:50 |
ayoung | now, yes, we have a wire format that is fairly well documented, so different consumers could parse it themselves | 03:51 |
ayoung | but this is what Keystone does, and it is our job to provide the common mechanisms around authorization | 03:51 |
ayoung | so beyond the token mechanism to deliver the data, we are going to do revocation checking and policy enforcement | 03:52 |
jamielennox | ayoung: completely agree, and doing things on the server are great and that's not what matters at the moment | 03:52 |
jamielennox | ayoung: right, this is all auth_token | 03:52 |
ayoung | this will be done in every server, and should be done in the client | 03:52 |
*** dimsum__ has joined #openstack-keystone | 03:52 | |
jamielennox | right - but auth_token isn't used by keystone | 03:53 |
ayoung | no, but policy is | 03:53 |
ayoung | and revocation checking will be as well | 03:53 |
ayoung | and they all need to use one mechanism | 03:53 |
ayoung | auth_token with deferred evaluation will no longer be really doing anything other than ensuring that the token is unpacked | 03:54 |
ayoung | and that the token itself is valid | 03:54 |
ayoung | it really doesn't care about the body of the data itself...well, it does cuz it sets all the env vars | 03:55 |
ayoung | now, once we have revocation checking, then yes, it will care about the body of the token data. | 03:55 |
ayoung | And that needs the access_info code | 03:55 |
*** dimsum__ has quit IRC | 03:57 | |
jamielennox | ayoung: so i guess what I need to know is a format that i can expose publicly that will work with current and future policy checking | 03:58 |
ayoung | jamielennox, so that is what I am trying to document in that code | 03:58 |
ayoung | jamielennox, can we switch over to talking about the Horizon stuff? | 03:59 |
jamielennox | ayoung: you got time to do that now? | 04:00 |
ayoung | yeah | 04:00 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Turn our auth plugin into a token intace https://review.openstack.org/137268 | 04:03 |
ayoung | jamielennox, intace? | 04:03 |
jamielennox | ayoung: so that's ^ really all i was thinking | 04:03 |
jamielennox | interface | 04:04 |
ayoung | and waht is IDT? | 04:04 |
jamielennox | ayoung: comes from https://github.com/openstack/oslo-incubator/blob/master/openstack/common/context.py#L60 seems to be used | 04:04 |
ayoung | I've heard of user = ID_10_T | 04:05 |
jamielennox | huh, never thought of that | 04:05 |
ayoung | I guess it is short for identity | 04:05 |
jamielennox | no, i'm not trying to be clever | 04:05 |
jamielennox | i want to have existing policy more or less work but not corner us on anything new | 04:06 |
jamielennox | to_dict probably shouldn't exist | 04:06 |
jamielennox | policy should create a dict based on the context object | 04:06 |
ayoung | I mean in the original code: 'user_identity': user_idt | 04:07 |
jamielennox | but given that that object already exists and contains an AccessInfo within itself, i've got a fairly good oportunity here to present a clean interface above it | 04:07 |
*** ncoghlan has joined #openstack-keystone | 04:07 | |
ayoung | they are generating a unique id from the token's access data | 04:07 |
jamielennox | already exists and is passed through auth_token middleware to everyone | 04:07 |
*** kobtea has joined #openstack-keystone | 04:07 | |
jamielennox | unique to the auth, not to the request - possibly someone somewhere is using it as a hash key | 04:08 |
*** ncoghlan has quit IRC | 04:08 | |
jamielennox | i'll remove it, i was just copying over things for a POC | 04:08 |
*** ncoghlan has joined #openstack-keystone | 04:08 | |
ayoung | I'd be interested to see where it is used. It has domain info in it, which means it is relatively new | 04:08 |
jamielennox | so i'd need to add roles | 04:09 |
jamielennox | i don't want to add is_admin | 04:09 |
jamielennox | i think instance_uuid is a nova thing | 04:09 |
ayoung | have you looked at what I laid out for policy? | 04:09 |
jamielennox | i was looking through that review you mentioned | 04:10 |
jamielennox | but this is not that | 04:10 |
ayoung | the blog post | 04:10 |
ayoung | if you are at all touching policy it most certainly is | 04:10 |
ayoung | we have a half dozen people going at policy, and we need to make sure we are not working at cross purposes | 04:11 |
jamielennox | i'm not touching really touching policy, if i don't include a to_dict then i | 04:11 |
jamielennox | 'm fairly indifferent | 04:11 |
ayoung | so...please read http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ to see where we are headed | 04:11 |
jamielennox | but you're right, the AccessInfo structure is a mess and i don't really want to make that public to everyone | 04:11 |
jamielennox | so this is a chance to put a read only wrapper in front of it | 04:11 |
*** kobtea has quit IRC | 04:12 | |
ayoung | the dictionary approach is only to keep from breaking existing code. Places where we can use the straight python interface is obviously preferred | 04:12 |
ayoung | hence the focus on doing that first | 04:12 |
ayoung | I'm really far more concerned that you understand and can guide what is going on in Horizon. Working on that stuff in your absence was frustrating | 04:14 |
ayoung | Its like the primary driver of requirements in Keystone | 04:14 |
ayoung | and we've just got no clue there.... | 04:14 |
morganfainberg | ayoung, no, horizon is *not* the primary driver. | 04:15 |
ayoung | https://review.openstack.org/#/c/121281/ is really something you need to take in hand | 04:15 |
ayoung | morganfainberg, stop contradicting me | 04:15 |
openstackgerrit | ChangBo Guo(gcb) proposed openstack/keystone: Add library oslo.concurrency's option to keystone.conf.sample https://review.openstack.org/137270 | 04:15 |
morganfainberg | ayoung, horizon happens to be a reasonable consumer of Keystone | 04:15 |
morganfainberg | ayoung, haha i'm not strictly contradicting. there have been a lot of things i've agreed with you on recently | 04:15 |
jamielennox | ayoung: i know this stuff, and that's not what i'm designing here | 04:16 |
jamielennox | i want this object to be considered your auth - in the same way that an auth_plugin should | 04:16 |
jamielennox | auth_token middleware will always produce the same type of plugin because it reads from keystone directly | 04:17 |
ayoung | morganfainberg, ok. The # one thing we've had to deal with lately on my team is Federation | 04:17 |
ayoung | and Federation and SAML really only works with WebUI | 04:17 |
jamielennox | i want to have this auth object passed to policy to make decisions | 04:17 |
morganfainberg | And federation, whether that is via Horizon is a big driver for requirements in Keystone | 04:17 |
ayoung | So making Horizon work is essential to actualy having a consumable Federation solution | 04:17 |
morganfainberg | ayoung, i'll definitely agree federation + the consumers of federation are drivers. | 04:18 |
jamielennox | so really what i'm concerned with here is presenting an interface that policy can read and make decisions on | 04:18 |
ayoung | or, in short Horizon is the primary driver of requirements in Keystone | 04:18 |
morganfainberg | nope | 04:18 |
jamielennox | whether that's a dictionary or not i don't care | 04:18 |
ayoung | for me | 04:18 |
ayoung | for jamielennox | 04:18 |
jamielennox | (at the moment_ | 04:18 |
ayoung | for nkinder | 04:18 |
morganfainberg | ayoung, jamielennox , there we go. | 04:18 |
ayoung | OK? | 04:18 |
ayoung | Now that we have the pedantry out of the way.... | 04:19 |
morganfainberg | ayoung, mostly i didn't want someone else to step in and think we're only catering to Horizon. context. | 04:19 |
morganfainberg | ayoung, /me isn't sure what people are thinking / lurking /etc | 04:19 |
ayoung | Horizon has been driving some of the limitations on Keystone, too, and the patch I linked to above is a prereq to fixing that, too | 04:19 |
* morganfainberg goes back to lurking. | 04:20 | |
ayoung | morganfainberg, tell me if https://review.openstack.org/#/c/137231/ was basically what you want | 04:20 |
morganfainberg | ayoung, sec | 04:21 |
jamielennox | morganfainberg: have a look at that WIP review, https://review.openstack.org/#/c/137268/ | 04:21 |
ayoung | I didn't do the workflow minus 1, but it is WIP | 04:21 |
morganfainberg | meh WIP or not, if i see a +2 on it i'd -2 if it wasn't ready... you know... | 04:21 |
ayoung | morganfainberg, I really didn't have too much fear of that happening. | 04:22 |
morganfainberg | and i know you'd -2 if it you thought it was in jeapordy of going in too soon | 04:22 |
ayoung | +2s are few and far between | 04:22 |
*** _cjones_ has quit IRC | 04:22 | |
ayoung | plus, I think only you and I are thinking this way on this topic....at least, I hope we are aligned | 04:22 |
morganfainberg | we were mostly there barring any implementation weirdness discussing it | 04:23 |
morganfainberg | in general | 04:23 |
ayoung | jamielennox, ok, you beat me...I'm too tired and near to bed time to discuss Django OpenStack Auth. We'll postpone till next week | 04:24 |
jamielennox | ayoung: i'm fine to do it, i just assume it'll take a while and it's got to be late | 04:24 |
ayoung | jamielennox, lets get started now... | 04:24 |
ayoung | start here https://review.openstack.org/#/c/121281/7/openstack_auth/backend.py,cm | 04:25 |
morganfainberg | ayoung, so i have a neat trick to show you for applying some virtual / abstract methods to classes but this is the direction i was headed. | 04:25 |
ayoung | morganfainberg, Im not going to touch this code for a bit. If you want to hack on it, please feel free | 04:25 |
morganfainberg | nah, it may not be relevant here | 04:25 |
morganfainberg | it's more of a, "you might like this for composition cases" | 04:25 |
ayoung | I kindof want to avoid virtual/abstract actually for the core classes | 04:26 |
morganfainberg | ayoung, i'll show you the way it works after the weekend | 04:26 |
ayoung | deal | 04:26 |
morganfainberg | ayoung, i have like 40 work things to do this holiday :( | 04:26 |
morganfainberg | some HP some keystone. | 04:26 |
morganfainberg | so, hacking on this is unlikely :P | 04:26 |
ayoung | jamielennox, ok, so the issues are things like where do we get the auth plugin, where we do put it after we authenticate and so on | 04:28 |
jamielennox | sure | 04:28 |
ayoung | the logic is split up somewhat arbitrarily between utils.py and backend.py | 04:28 |
ayoung | the Django form will call authenticate with the values on the form | 04:28 |
jamielennox | so if i see correctly the biggest problem is going to be that auth_plugins authenticate as required not when created | 04:28 |
ayoung | jamielennox, we can almost work around that by treating the "list_projects" call as the authenticate | 04:29 |
jamielennox | right, but so what is the Token model they have? can we just replace that with an auth plugin? | 04:29 |
ayoung | I think so | 04:30 |
ayoung | as long as everything is contained within DOA, we can hack it | 04:30 |
ayoung | I don';t think the token is passed to the actual Horizon app itself | 04:30 |
jamielennox | something has to cross that boundary | 04:31 |
ayoung | jamielennox, http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/user.py#n59 | 04:31 |
jamielennox | and ideally it would be the auth_plugin because that's what will get passed to the other clients | 04:31 |
ayoung | so, yet another chunk of code that I want to replace with the Access Info code when it is ready... | 04:32 |
ayoung | yeah | 04:32 |
ayoung | using the auth plugin in place of the token would be, I think, the right abstraction | 04:32 |
jamielennox | there's no auth_token middleware involved here right? | 04:32 |
ayoung | right | 04:32 |
jamielennox | obviously not here, but anyway in horizon? | 04:33 |
ayoung | it requests tokens, it does not accept tokens | 04:33 |
jamielennox | s/anyway/anywhere | 04:33 |
ayoung | not yet. If we make Horizon accept a token as a login form of authentication, that changes | 04:33 |
ayoung | we need either auth-token or an analogue | 04:33 |
jamielennox | if horizon is comfortable with AccessInfo as it is know then it can make a trivial plugin and control that interface itself | 04:34 |
jamielennox | s/know/now - really struggling with that one recently | 04:34 |
jamielennox | it would be essentially the same object that i created and just showed over in auth_token | 04:34 |
ayoung | jamielennox, http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/backend.py#n186 | 04:35 |
ayoung | that is where it is persisting the token across calls | 04:35 |
ayoung | the assumption is that the token is small enough to fit into a cookie | 04:35 |
ayoung | right | 04:35 |
ayoung | request.session['unscoped_token'] = unscoped_token.id | 04:36 |
jamielennox | ayoung: so if we don't cross the boundary into horizon this is fairly simple, i was of the impression we would use that plugin throughout the entire request and pass that to other clients | 04:36 |
ayoung | there is a dashboard portion that is keystone specific, but it just makes KC type calls ... let's see | 04:37 |
ayoung | http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py | 04:37 |
jamielennox | so line 190 it is saving the client to the request | 04:37 |
jamielennox | that's what we want, to save the plugin to the request and be used everywher | 04:38 |
jamielennox | e | 04:38 |
ayoung | http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py#n171 | 04:38 |
ayoung | line 190 of backend.py? Yeah, I think so | 04:38 |
ayoung | but that is request scoped, not session, so once Horizon responds to the user, the object is gone | 04:39 |
ayoung | So we might have some slop over into Horizon | 04:39 |
ayoung | conn = api_version['client'].Client(token=user.token.id, | 04:39 |
ayoung | Let's get DOA settled, and we can then modify the Horizon code | 04:41 |
jamielennox | cool, so this works kind of how i think keystone should work | 04:41 |
jamielennox | the request object is request scoped and gets passed to everything | 04:41 |
ayoung | So we'll have to leave the token id in the user object for the time being | 04:41 |
jamielennox | different sections attach what they need and others use it | 04:42 |
ayoung | Fairly common in Server side scripting frameworks | 04:42 |
jamielennox | yep | 04:42 |
ayoung | the context object in Keystone used to be that way...it really is not a great abstraction for reusability, as you end up with lots of implied interfaces. | 04:43 |
ayoung | Better to treat the request as an explicit middleman, and have a "web API" specific set of classes for doing what you describe: putting things into or getting them out of the request | 04:44 |
ayoung | or the session, or the application, or global, as appropriate | 04:44 |
jamielennox | ok, so if all we need to get is auth and get the token we can do this simply | 04:44 |
jamielennox | https://review.openstack.org/#/c/121281/7/openstack_auth/utils.py is no longer required | 04:44 |
jamielennox | replaced by generic.Password | 04:44 |
jamielennox | not sure about delete_token | 04:45 |
ayoung | yeah, and if discovery is cached or shortcircuited, that wil work much better | 04:45 |
ayoung | that is wierd | 04:46 |
jamielennox | discovery is cached per session, to start that would probably be per client request | 04:46 |
ayoung | they delete tokens to revoke them when loggng out or switching projects | 04:46 |
ayoung | if the KC session is scoped one-per to the Horizon application, that should work | 04:46 |
ayoung | then KC.client is request scoped, and the auth plugin is session scoped | 04:47 |
ayoung | but if all we can persist is the token id, maybe auth plugin becomes request scoped, too, for the first iteration | 04:48 |
jamielennox | what are the unit tests like? | 04:48 |
ayoung | mediocre | 04:48 |
ayoung | but workable | 04:48 |
ayoung | http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/tests | 04:48 |
jamielennox | doesn't look like you've changed much | 04:49 |
jamielennox | probably i just replace the mox with a requests_mock layer and it'll be the same | 04:49 |
ayoung | In that one, I tried to make all the changes just straight refactorings | 04:49 |
ayoung | I changed more in other commits | 04:49 |
ayoung | ++ | 04:49 |
ayoung | OK...I need to head to bed. | 04:50 |
jamielennox | ok, i'll give it a look | 04:50 |
ayoung | You got enough to get started, I take it? | 04:50 |
jamielennox | yea, honestly it should be not too hard | 04:50 |
ayoung | so, last piece of advice is to get friendly with rpdb | 04:50 |
ayoung | if you do a devstack setup, use pip install rpdb and then you can step through code etc | 04:51 |
jamielennox | oh, damn yea, horizon will suck to debug | 04:51 |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment table migrate if duplicate entry exists. Closes-bug: #1395959 Change-Id: I394a0391ee074c3ee79bdb06391fc4d5fb9067a9 https://review.openstack.org/136946 | 04:51 |
ayoung | its not bad | 04:51 |
ayoung | import rpdb; rpdb.set_trace() | 04:51 |
ayoung | then from another window: telnet localhost 4444 | 04:51 |
jamielennox | could be worse - i could have to look at the javascript/css | 04:51 |
ayoung | if you do cont, just remember to exit out of telnet | 04:52 |
ayoung | yeah, I'll try to insulate you from that | 04:52 |
*** zzzeek has quit IRC | 04:52 | |
jamielennox | no need to try - i'm not going anywhere near it | 04:52 |
ayoung | you can tell when I've been looking at javascript, as I start putting ; at the end of my lines | 04:52 |
jamielennox | heh | 04:53 |
ayoung | thanks for looking at this. | 04:53 |
jamielennox | alright, i'll have a look and find you tomorrow with anything i don't understand | 04:53 |
ayoung | there is also a development server for Django | 04:53 |
ayoung | david-lyle_afk, and company would be better for pointing you at how to get started with that, but rpdb should carry you through | 04:54 |
jamielennox | so do i need a db or anything for testing? | 04:55 |
jamielennox | run_tests fails with a clean checkout | 04:55 |
*** henrynash_ has joined #openstack-keystone | 04:57 | |
*** ChanServ sets mode: +v henrynash_ | 04:57 | |
*** henrynash has quit IRC | 04:57 | |
*** henrynash_ is now known as henrynash | 04:57 | |
ayoung | jamielennox, if you do devstack, you need enough other services up to get logged in...really just keystone | 04:58 |
ayoung | horizon itself has no database. Which is why they keep trying to cram user info into Keystone | 04:58 |
ayoung | OK..bed | 04:59 |
*** ayoung is now known as ayoung_ZZzz_zzZZ | 04:59 | |
*** nellysmitt has joined #openstack-keystone | 05:03 | |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment table migrate if duplicate entry exists. https://review.openstack.org/136946 | 05:04 |
*** bjornar has quit IRC | 05:06 | |
*** nellysmitt has quit IRC | 05:08 | |
*** _cjones_ has joined #openstack-keystone | 05:09 | |
*** bjornar has joined #openstack-keystone | 05:11 | |
*** stevemar has joined #openstack-keystone | 05:13 | |
*** ChanServ sets mode: +v stevemar | 05:13 | |
*** _cjones_ has quit IRC | 05:13 | |
*** _cjones_ has joined #openstack-keystone | 05:28 | |
samuelms_ | dolphm, did you already started sql-id-binary-16 ? | 05:34 |
openstackgerrit | Merged openstack/keystone: Move check_output and git() to test utils https://review.openstack.org/130662 | 05:35 |
*** stevemar has quit IRC | 05:36 | |
openstackgerrit | Merged openstack/keystonemiddleware: Docstring cleanup https://review.openstack.org/127084 | 05:43 |
*** gokrokve has joined #openstack-keystone | 05:50 | |
*** henrynash has quit IRC | 05:51 | |
*** gokrokve has quit IRC | 05:52 | |
*** _cjones_ has quit IRC | 05:59 | |
*** stevemar has joined #openstack-keystone | 06:01 | |
*** ChanServ sets mode: +v stevemar | 06:01 | |
*** k4n0 has joined #openstack-keystone | 06:03 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/136243 | 06:06 |
*** _cjones_ has joined #openstack-keystone | 06:08 | |
openstackgerrit | Merged openstack/python-keystoneclient: Remove useless log message https://review.openstack.org/131294 | 06:10 |
openstackgerrit | Dave Chen proposed openstack/keystone: Reduce database query statement https://review.openstack.org/133135 | 06:19 |
*** ukalifon1 has joined #openstack-keystone | 06:27 | |
*** stevemar has quit IRC | 06:34 | |
*** samuelms_ has quit IRC | 06:37 | |
*** afazekas has joined #openstack-keystone | 06:50 | |
*** jacorob_ has quit IRC | 06:51 | |
*** ajayaa has joined #openstack-keystone | 06:52 | |
*** Shohei has quit IRC | 07:00 | |
*** Shohei has joined #openstack-keystone | 07:00 | |
*** Shohei has quit IRC | 07:03 | |
*** nellysmitt has joined #openstack-keystone | 07:04 | |
*** nellysmitt has quit IRC | 07:09 | |
*** fifieldt has quit IRC | 07:16 | |
*** henrynash has joined #openstack-keystone | 07:22 | |
*** ChanServ sets mode: +v henrynash | 07:22 | |
*** ncoghlan has quit IRC | 07:35 | |
*** henrynash has quit IRC | 07:46 | |
*** mitz- has joined #openstack-keystone | 07:51 | |
*** mitz_ has quit IRC | 07:51 | |
*** nellysmitt has joined #openstack-keystone | 07:57 | |
*** Shohei has joined #openstack-keystone | 08:11 | |
*** _cjones_ has quit IRC | 08:15 | |
*** oomichi has quit IRC | 08:17 | |
*** ukalifon1 has quit IRC | 08:29 | |
*** mitz_ has joined #openstack-keystone | 08:34 | |
*** mitz- has quit IRC | 08:36 | |
*** jistr has joined #openstack-keystone | 08:59 | |
*** ukalifon1 has joined #openstack-keystone | 09:02 | |
*** bjornar has quit IRC | 09:06 | |
*** kobtea has joined #openstack-keystone | 09:15 | |
*** kobtea has quit IRC | 09:20 | |
*** bjornar has joined #openstack-keystone | 09:24 | |
*** afazekas has quit IRC | 09:33 | |
*** afazekas has joined #openstack-keystone | 09:48 | |
*** afazekas has quit IRC | 10:07 | |
*** afazekas has joined #openstack-keystone | 10:20 | |
*** samuelms_ has joined #openstack-keystone | 10:25 | |
*** KanagarajM has joined #openstack-keystone | 10:34 | |
*** aix has joined #openstack-keystone | 10:34 | |
*** tellesnobrega_ has quit IRC | 10:49 | |
*** tellesnobrega_ has joined #openstack-keystone | 10:52 | |
*** NM has joined #openstack-keystone | 10:56 | |
*** junhongl has quit IRC | 11:01 | |
*** junhongl has joined #openstack-keystone | 11:02 | |
openstackgerrit | Marek Denis proposed openstack/keystone: Scope federated token with 'token' identity method https://review.openstack.org/130593 | 11:04 |
*** diegows has joined #openstack-keystone | 11:10 | |
*** samuelms_ has quit IRC | 11:14 | |
*** tellesnobrega_ has quit IRC | 11:14 | |
openstackgerrit | Marek Denis proposed openstack/keystone-specs: Scope federated tokens with ``token`` auth method. https://review.openstack.org/137020 | 11:29 |
*** diegows has quit IRC | 11:30 | |
*** diegows has joined #openstack-keystone | 11:47 | |
*** jamielennox is now known as jamielennox|away | 11:48 | |
*** ioram has joined #openstack-keystone | 11:48 | |
*** aix has quit IRC | 12:07 | |
*** ioram has quit IRC | 12:10 | |
*** raildo has quit IRC | 12:13 | |
*** raildo has joined #openstack-keystone | 12:26 | |
*** KanagarajM has quit IRC | 12:28 | |
*** ajayaa has quit IRC | 12:41 | |
*** kobtea has joined #openstack-keystone | 12:53 | |
*** kobtea has quit IRC | 12:58 | |
*** bjornar has quit IRC | 13:05 | |
*** ioram has joined #openstack-keystone | 13:07 | |
samuelms | https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata | 13:14 |
*** aix has joined #openstack-keystone | 13:20 | |
*** ioram has quit IRC | 13:23 | |
*** ajayaa has joined #openstack-keystone | 13:36 | |
*** toddnni has quit IRC | 13:39 | |
*** gordc has joined #openstack-keystone | 13:42 | |
openstackgerrit | gordon chung proposed openstack/keystonemiddleware: Adding audit middleware to keystonemiddleware https://review.openstack.org/102958 | 13:50 |
openstackgerrit | gordon chung proposed openstack/keystonemiddleware: documentation for audit middleware https://review.openstack.org/130344 | 13:50 |
*** dimsum__ has joined #openstack-keystone | 13:51 | |
openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/102244 | 14:02 |
*** svasheka has joined #openstack-keystone | 14:08 | |
svasheka | hi | 14:08 |
svasheka | can someone tell me how to rename keystone role ? | 14:09 |
*** nkinder has quit IRC | 14:10 | |
*** toddnni has joined #openstack-keystone | 14:17 | |
*** ayoung_ZZzz_zzZZ is now known as ayoung | 14:21 | |
samuelms | svasheka, I think we don't have this operation exposed to the API | 14:24 |
samuelms | ayoung, morning, you confirm this ^ ? | 14:25 |
samuelms | svasheka, what roles you'd like to rename, specifically? admin one or other you've created? | 14:25 |
svasheka | admin | 14:26 |
svasheka | I ment using mysql and stuff | 14:26 |
samuelms | svasheka, even if it were possible, I discourage you to do this .. | 14:27 |
samuelms | svasheka, the code in some projects are prepared to have the admin role changed .. (there are some hard coded checks that check for the role name 'admin') | 14:27 |
samuelms | svasheka, we have this in mind and need to fix this | 14:28 |
samuelms | dolphm, ping .. few minutes to talk about sql-id-binary-16 spec? | 14:36 |
*** r-daneel has joined #openstack-keystone | 14:37 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Add missing translation marker for dependency https://review.openstack.org/136824 | 14:43 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Fix tests using extension drivers https://review.openstack.org/124603 | 14:43 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Avoid multiple instances for a provider https://review.openstack.org/124599 | 14:43 |
openstackgerrit | Brant Knudson proposed openstack/keystone: TestAuthPlugin doesn't use test_auth_plugin.conf https://review.openstack.org/137367 | 14:43 |
openstackgerrit | Marek Denis proposed openstack/keystone: Scope federated token with 'token' identity method https://review.openstack.org/130593 | 14:47 |
*** jjulien_ has joined #openstack-keystone | 14:49 | |
*** zzzeek has joined #openstack-keystone | 14:53 | |
*** jacorob_ has joined #openstack-keystone | 14:55 | |
*** jacorob_ has quit IRC | 14:56 | |
*** nkinder has joined #openstack-keystone | 14:58 | |
ayoung | svasheka, if you want to see the complexity involved read this: http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ | 15:04 |
*** saipandi has joined #openstack-keystone | 15:08 | |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists. https://review.openstack.org/136946 | 15:09 |
*** david-lyle_afk is now known as david-lyle | 15:28 | |
*** dimsum__ has quit IRC | 15:28 | |
*** stevemar has joined #openstack-keystone | 15:28 | |
*** ChanServ sets mode: +v stevemar | 15:28 | |
*** dimsum__ has joined #openstack-keystone | 15:29 | |
*** gokrokve has joined #openstack-keystone | 15:30 | |
*** radez is now known as radez_g0n3 | 15:32 | |
svasheka | ayoung, thank you | 15:34 |
svasheka | I am reproducing bug connected with complexity you are telling about) | 15:34 |
openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Templated catalog backend not implemented https://review.openstack.org/120011 | 15:42 |
*** afazekas has quit IRC | 15:58 | |
*** dimsum__ is now known as dims | 16:03 | |
*** ukalifon1 has quit IRC | 16:05 | |
*** henrynash has joined #openstack-keystone | 16:08 | |
*** ChanServ sets mode: +v henrynash | 16:08 | |
*** _cjones_ has joined #openstack-keystone | 16:08 | |
stevemar | after adding a 'paging' value to the keystone config file, i was hoping that user-list or group-list would work, but instead it's just crapping out with INSUFFICIENT_ACCESS: {'desc': 'Insufficient access'} | 16:11 |
stevemar | anyone know whats up? lookin' at you ayoung since you're the ldap guy | 16:11 |
bknudson | stevemar: do you have domain-specific backends? | 16:13 |
stevemar | bknudson, no, just one domain, and one identity backend being ldap | 16:14 |
stevemar | i bootstrapped and gave a user (me) the admin role on the admin project | 16:15 |
*** NM1 has joined #openstack-keystone | 16:15 | |
bknudson | stevemar: it's the LDAP server returning insufficient access? | 16:16 |
stevemar | bknudson, yep | 16:16 |
*** zigo has quit IRC | 16:16 | |
bknudson | stevemar: are you connecting with a user that has authority to use the paging control? | 16:17 |
stevemar | bknudson, probably not! | 16:17 |
stevemar | didn't know that was a thing | 16:17 |
bknudson | I'm sure it depends on the server | 16:17 |
*** NM has quit IRC | 16:18 | |
bknudson | I'd think a server wouldn't allow it for just anyone because it requires storing some state on the server and could be a potential DOS | 16:18 |
stevemar | i'm guessing our own ldap enforces that then, since i can't think of another reason | 16:18 |
bknudson | doing a user-list on an entire LDAP directory is probably not something you want to do anyways | 16:19 |
stevemar | yeah, thats why i was playing around with paging | 16:20 |
stevemar | but meh | 16:20 |
stevemar | bknudson, oh nice, do our CLIs not have filtering support for list operations? | 16:21 |
bknudson | stevemar: I don't know... haven't tried it. That's what curl is for. | 16:22 |
ayoung | stevemar, paging dumb? | 16:23 |
stevemar | ayoung, not dumb just picky | 16:23 |
ayoung | insufficient access looks like an access controll | 16:23 |
stevemar | bknudson, quit using curl and help with the command line efforts :P | 16:23 |
ayoung | no paging is a dumb idea...having gotten that out of the way... | 16:23 |
ayoung | stevemar, I have not looked at how paging is implemented. I'm guessing that it asks something of the LDAP serve rthat the server doesn't want to permit. Paging requires a long lived connection, so I'm guessing it is that | 16:24 |
ayoung | nkinder, does my explanation to stevemar make LDAP sense? | 16:25 |
stevemar | ayoung, yeah, i'm thinking that's the case | 16:25 |
stevemar | bknudson, already explained the possible DoS scenario if everyone could page | 16:25 |
ayoung | stevemar, more logging, find out "insufficient access" to what | 16:25 |
marekd | morganfainberg: around? | 16:26 |
*** zigo has joined #openstack-keystone | 16:27 | |
*** nellysmitt has quit IRC | 16:30 | |
*** gokrokve_ has joined #openstack-keystone | 16:30 | |
*** k4n0 has quit IRC | 16:30 | |
*** kobtea has joined #openstack-keystone | 16:30 | |
*** gokrokve has quit IRC | 16:31 | |
*** NM1 has quit IRC | 16:34 | |
*** kobtea has quit IRC | 16:35 | |
*** packet has joined #openstack-keystone | 16:35 | |
*** packet has quit IRC | 16:37 | |
marekd | nkinder: hi. So if i understand correctly, you want to match groups a user brings in his assertion with a role assignments configured in keystone? | 16:38 |
openstackgerrit | henry-nash proposed openstack/keystone: Split the assignments manager/driver. https://review.openstack.org/130954 | 16:42 |
stevemar | marekd, yeah nkinder brought this up in paris | 16:43 |
stevemar | i think it's worth investigating | 16:43 |
marekd | that's what i am doing. | 16:43 |
*** gokrokve_ has quit IRC | 16:45 | |
henrynash | morganfainberg, samuelms: new patch with roles in their own backend, but part of assignment is up: https://review.openstack.org/#/c/130954/ | 16:48 |
nkinder | marekd: hey | 16:50 |
marekd | nkinder: responding now to the e-mail. | 16:50 |
nkinder | marekd: yeah, that's pretty much it. Pass the groups through from the assertion and allow a role assignment to happen without group creation or mapping changes. | 16:50 |
marekd | nkinder: ok, but then a group whitelisting is a must. | 16:51 |
marekd | nkinder: otherwise my CERN's idp admin can make me a member of group 'superadmin' and i will automagically become admin member in Rackspace cloud. | 16:51 |
marekd | nkinder: do you agree? | 16:51 |
*** NM has joined #openstack-keystone | 16:52 | |
nkinder | marekd: this would be useful in the case where you want to control roles purely off of the LDAP groups that the IdP uses when constructing the assertion | 16:52 |
samuelms | henrynash, great! I'm going to take a look at it tonight | 16:53 |
nkinder | marekd: in the case you describe, that may not be desirable | 16:53 |
marekd | why? | 16:53 |
nkinder | marekd: so whitelisting/blacklisting would be a nice addition | 16:53 |
nkinder | marekd: well, you seem to be saying that you don't want to just trust the assertion for the 'superadmin' group | 16:54 |
*** _cjones_ has quit IRC | 16:54 | |
marekd | nkinder: kind of. i trust the assertion but i want to be able to control who can do what on my cloud... | 16:54 |
nkinder | marekd: and that's fine, but it's a deployment specific concern. The blacklist/whitelist would solve that sort of case where one group wants to control the cloud, and one wants to control the IdP/LDAP. | 16:55 |
nkinder | If that is the same person/group that runs both, then may want to control it all via LDAP grouping | 16:55 |
nkinder | So 100% passthrough would be ideal in that scenario. | 16:55 |
marekd | nkinder: in that case, yes | 16:55 |
nkinder | marekd: they are both valid use cases | 16:55 |
marekd | but in general i'd make this black/white listing not an optional feature. rather a 100% passthrough a cornercase of empty black/whitelists | 16:56 |
nkinder | so passthrough with a blacklist/whitelist adds a lot of flexibility | 16:56 |
nkinder | marekd: sure, they can go together | 16:56 |
marekd | nkinder: ok | 16:56 |
marekd | nkinder: so you want to be able to add a role assignment poiting to a keystone group even though the group doesn't exist. Do you want the group to be created then (wile adding a role assignment)? | 16:57 |
nkinder | marekd: no, no need to actually add it I think (though we may want a mapping table like the multi-domain feature uses) | 16:58 |
marekd | nkinder: hm, i wonder if it would change a lot in role assignments code. | 16:59 |
marekd | those ephemeral groups. | 16:59 |
marekd | nkinder: do you think we still need to tie IdPs to domains? | 16:59 |
*** jdennis1 has joined #openstack-keystone | 16:59 | |
nkinder | marekd: I think so, otherwise how do we differentiate between two groups with the same name from different IdPs? | 17:00 |
marekd | nkinder: right, it is covered by mapping rules now. | 17:01 |
marekd | but, if we tie IdPs to different domains... | 17:01 |
*** jdennis has quit IRC | 17:01 | |
marekd | nkinder: how can we let users from 2 separate IdP work on one project together. | 17:01 |
marekd | we should let scope to different domains basing on other parameters? | 17:03 |
marekd | nkinder: you know what i mean? | 17:06 |
marekd | ayoung: morganfainberg: dolphm: stevemar: appreciate if you could take a look at the 'alternatives' (esp bullet no. 2) in https://review.openstack.org/#/c/135604/6/specs/kilo/k2k-service-providers.rst as it is something that is being requested but this also complicates everything. | 17:14 |
marekd | nkinder: ^^ you too | 17:14 |
marekd | rodrigods: and you, sir! | 17:14 |
nkinder | marekd: got pulled into a meeting. Will look in a bit... | 17:15 |
marekd | nkinder: sure. | 17:15 |
ayoung | marekd, I have real problems with a lot of K2K. I've stayed out of it because I don't really have a reason to wade in. | 17:15 |
marekd | ayoung: understood. | 17:15 |
ayoung | K2K to me is two completely separet things | 17:15 |
ayoung | 1. Identity | 17:16 |
ayoung | 2. Authorization | 17:16 |
*** jorge_munoz has joined #openstack-keystone | 17:16 | |
*** henrynash has quit IRC | 17:16 | |
rodrigods | marekd, ++ taking a look on it | 17:16 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Trust redelegation https://review.openstack.org/126897 | 17:17 |
stevemar | marekd, i dont like #2 because i feel it locks us in to using saml from now on | 17:18 |
marekd | stevemar: how do you configure openid ? | 17:19 |
stevemar | marekd, there is no exchange, you just need the right client id and client secret | 17:19 |
openstackgerrit | Andre Aranha proposed openstack/keystone: Creating a policy sample https://review.openstack.org/123509 | 17:19 |
marekd | stevemar: well, i don't think it makes us use saml only, as i proposed that metadata would be a blob, attribute in a RESTful JSON request. | 17:20 |
marekd | stevemar: you could send something else for the openid | 17:20 |
marekd | stevemar: but that's far away as we would need to implement all that stuff in Keystone | 17:21 |
*** jorge_munoz has quit IRC | 17:21 | |
stevemar | yeah... no need to take it into account for today | 17:21 |
marekd | stevemar: what I am fearing that we may end up trying to make Keystone legitimate SAML IdP and prepare for being ready OpenId identity provider | 17:21 |
marekd | ok, please simply leave your comments | 17:22 |
stevemar | yeah i fear the same thing | 17:22 |
marekd | as i want to keep the ball rolling. | 17:22 |
openstackgerrit | Andre Aranha proposed openstack/keystone: Modify the default policy https://review.openstack.org/123509 | 17:22 |
marekd | rodrigods: the point is to not make people make up SP names :-) | 17:23 |
stevemar | nkinder, let me know when you get back from your meeting, have a question about listing users in a group from ldap | 17:23 |
marekd | rodrigods: imagine you need to add 150 (or 1500) SPs | 17:23 |
marekd | rodrigods: you'd need to make up 150 unique names | 17:23 |
marekd | that are informative enough | 17:23 |
marekd | ok, need to run, bbl. | 17:24 |
*** jorge_munoz has joined #openstack-keystone | 17:27 | |
rodrigods | ayoung, https://etherpad.openstack.org/p/policy-library-name :P | 17:27 |
ayoung | rodrigods, it really is a rules engine...its like prolog implemented in pyuthon | 17:30 |
ayoung | but I can't quite craft that into a name | 17:31 |
ayoung | rodrigods, maybe we should just replace the policy engine with prolog | 17:32 |
rodrigods | ayoung, haha | 17:33 |
ayoung | rodrigods, have you ever coded in prolog? Once you get the hang of it, it is very elegant...and fun | 17:34 |
rodrigods | ayoung, just in a tiny project in the university... Logic discipline | 17:34 |
ayoung | Make files are the most exposure people ever get to this kind of coding....Make has too many idiosyncracies to make it a pleasant experience for most people, though. | 17:34 |
openstackgerrit | Sergey Skripnick proposed openstack/python-keystoneclient: Raise proper exception in case of connection error https://review.openstack.org/137422 | 17:34 |
rodrigods | rodrigods, grandfather(X, Y) :- father(X, P), father(P, Y). :) | 17:35 |
rodrigods | ayoung, ^ | 17:35 |
ayoung | that is the usual example, isn't it | 17:35 |
rodrigods | ayoung, yep | 17:35 |
rodrigods | cousin too hehe | 17:36 |
ayoung | more like first-cousin-once-removed | 17:36 |
ayoung | but in this case, we are implementing rules logic in python. | 17:37 |
ayoung | We call it policy, but that is just what we *use* it for | 17:37 |
*** _cjones_ has joined #openstack-keystone | 17:37 | |
rodrigods | ayoung, yeah, good point | 17:37 |
ayoung | I wonder if there is prior art... | 17:37 |
ayoung | http://pyke.sourceforge.net/ | 17:38 |
ayoung | http://pyke.sourceforge.net/pyke_syntax/index.html | 17:38 |
ayoung | looks familiar.... | 17:38 |
*** gokrokve has joined #openstack-keystone | 17:39 | |
ayoung | yeah, we should be using something like that | 17:39 |
ayoung | If we want to use Prolog: https://code.google.com/p/pyswip/ | 17:40 |
rodrigods | ayoung, we could just parse the policy rules and enforce using it | 17:40 |
ayoung | rodrigods, have you ever heard me rant on the word "just" before? | 17:41 |
ayoung | heh | 17:41 |
rodrigods | ayoung, hehe yeah, sorry :P | 17:41 |
ayoung | you parse our existing policy files and turn them into prolog? Interesting. | 17:41 |
*** _cjones_ has quit IRC | 17:41 | |
ayoung | Probably not a "just" but not a bad thought. | 17:41 |
*** _cjones_ has joined #openstack-keystone | 17:41 | |
rodrigods | ayoung, wonder if the person who introduced policies, thought about it being just logic programming paradigm | 17:42 |
ayoung | I sense that they did, or at least suspected as much. | 17:43 |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists. https://review.openstack.org/136946 | 17:43 |
rodrigods | ayoung, way to far from my Logic classes, didn't make the connection until now | 17:43 |
ayoung | rodrigods, when last I coded in Prolog, Bush was the President. And I don't mean 'W' | 17:48 |
rodrigods | ayoung, http://alloy.mit.edu/alloy/ have you heard about it? People are using it here instead of prolog | 17:48 |
rodrigods | ayoung, impressive memory than :P | 17:49 |
ayoung | I think I took comparitive programming languages in Sophmore year, so 1990-91 | 17:49 |
ayoung | one of the things is that we want the policy files limited to just checking policy. Just like we wouldn't want people uploading python code and executing it blindly, Prolog is a general purpose language, and can have security implications | 17:50 |
rodrigods | ayoung, didn't thought about *actually* using it anyway | 17:50 |
*** NM has quit IRC | 17:51 | |
openstackgerrit | Henrique Truta proposed openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3 https://review.openstack.org/116081 | 17:51 |
ayoung | I think we want to stick with the existing policy file format for now, as it is the limited set of operations that we need. | 17:51 |
ayoung | As far as what to call it...meh | 17:51 |
ayoung | I don't think Alloy, as it is a Java project. Lets avoid adding in additional virtual machine formats | 17:52 |
*** jistr has quit IRC | 17:56 | |
ayoung | rodrigods, I really like what I'm seeing around Pyke | 17:57 |
ayoung | rodrigods, the token and other stuff from the context would be the fact base | 18:00 |
ayoung | the policy would be the rules base | 18:00 |
ayoung | It might not be set up for the scalable querying that we need, though | 18:00 |
rodrigods | ayoung, right | 18:01 |
ayoung | rodrigods, i think the " my_engine.reset()" approach won't work. We couldn't share the engine across multiple requests | 18:02 |
morganfainberg | marekd: will look at that spec this morning. But I am mostly out today due to family + travel. | 18:03 |
ayoung | butif we don't the engine would just explode in size | 18:03 |
ayoung | so what we are doing has an additional constraint beyond prolog/pyke: evaluate a given context while flyweight sharing of the rules. | 18:04 |
*** browne has joined #openstack-keystone | 18:04 | |
*** harlowja_away is now known as harlowja | 18:04 | |
morganfainberg | Ayoung: without context, this sounds like a request scoped object dep would be suitable? case but like I said... No context. | 18:05 |
rodrigods | ayoung, yeah, let's just choose a name and once the lib is in place we can check alternatives for its growth :) | 18:05 |
rodrigods | morganfainberg, fyi: ldap tests for HM are in place :) | 18:06 |
morganfainberg | rodrigods: those probably are going to need a rebase against master. I'll help, so we can squash the topic branch ASAP. | 18:07 |
morganfainberg | rodrigods: but awesome!! | 18:07 |
*** _cjones_ has quit IRC | 18:07 | |
ayoung | morganfainberg, I was just looking for prior art on rules enforcement in the context of policy. Pyke seems like a logical start point, but it really doesn't fit our usage | 18:07 |
*** _cjones_ has joined #openstack-keystone | 18:08 | |
morganfainberg | ++ yay! I like prior art if we can use it. But step one: graduate what we have. Then grow the superpowers of the lib. | 18:08 |
morganfainberg | I think a wholesale change is going to be too much in this one step. But adding / migrating to a better enforcement Lang. Is def on the table b | 18:09 |
morganfainberg | If we do it all at once I think we will never get adoption of the lib ( never more like v3 keystone never, not really never) | 18:10 |
rodrigods | morganfainberg, ++ | 18:12 |
ayoung | morganfainberg, all this grew out of what to name the library. It is rules programming, but with the flyweight bent required by the load of a web application | 18:16 |
morganfainberg | Hehe. | 18:16 |
morganfainberg | Two hard things in computer science ... | 18:17 |
ayoung | in the Authorization literature, it is the implmenetation of a policy decision point or PDP | 18:17 |
morganfainberg | Cache coherency , naming things, and off by one errors. | 18:17 |
ayoung | oooh,m interesting http://en.wikipedia.org/wiki/Common_Open_Policy_Service | 18:18 |
ayoung | Keystone COPS turns up again | 18:18 |
*** harlowja has quit IRC | 18:18 | |
morganfainberg | Some one totally backronymed that. | 18:18 |
ayoung | dead link to the implementations, though | 18:18 |
morganfainberg | :p | 18:19 |
ayoung | January 2000 | 18:19 |
ayoung | not new | 18:19 |
*** harlowja has joined #openstack-keystone | 18:19 | |
rodrigods | ayoung, morganfainberg, best name so far: pyrulz :D | 18:19 |
morganfainberg | That rfc, while potentially useful for our case is targeted at qos | 18:20 |
ayoung | nice | 18:20 |
ayoung | pyrulz rulz! | 18:20 |
morganfainberg | rodrigods: I think I still want a coffee reference in there. :P | 18:21 |
rodrigods | morganfainberg, https://etherpad.openstack.org/p/policy-library-name | 18:21 |
morganfainberg | Pyrulz isn't bad. It isn't taken is it? Also remember we're going to need to get the tc and possibly openstack legal involved on this :( | 18:22 |
rodrigods | morganfainberg, ayoung, honesty is nice too (by dolphm ) | 18:22 |
ayoung | he likes his word games, but you need to follow his logic first. You need to explain to people why the project is named Kite, for example | 18:23 |
morganfainberg | But keys... Cloud... Yeah. | 18:24 |
*** NM has joined #openstack-keystone | 18:26 | |
morganfainberg | ayoung: cloud open policy engine, COPE | 18:31 |
ayoung | Oooh | 18:31 |
* morganfainberg needs to bug Topol. We might actually want to push this to a standard like pycadf | 18:32 | |
ayoung | Hypertext Open Policy Engine | 18:32 |
ayoung | Parallel Open Policy Engine | 18:32 |
ayoung | Scalable Open Policy Engine | 18:32 |
morganfainberg | No, not pope :P | 18:32 |
ayoung | Scalable Open Authorizatione Policy | 18:32 |
morganfainberg | Hah. | 18:33 |
rodrigods | nforce | 18:33 |
rodrigods | pynforce (htruta) | 18:33 |
ayoung | Open Policy Engine Next | 18:33 |
samuelms | authorizer | 18:33 |
ayoung | ^^ is something you'd get from the FSF | 18:34 |
ayoung | Terribly Redundant Open Policy Engine | 18:34 |
ayoung | Next Open Policy Engine | 18:35 |
* ayoung is enjoying himself way too much here | 18:35 | |
samuelms | hah | 18:36 |
htruta | Great Open Authorization Technology | 18:36 |
nkinder | stevemar: back. What's up? | 18:37 |
ayoung | Gnu Open Authorization Technoloy Redundant Open Policy Engine | 18:37 |
morganfainberg | You need to get rodeo as the second word. | 18:38 |
ayoung | that is the CentoS version | 18:38 |
ayoung | Gnu Open Authorization Technology-RDO | 18:38 |
stevemar | nkinder, so i think i narrowed it down | 18:39 |
morganfainberg | Hah. | 18:39 |
ayoung | stevemar, this the authorization issue with paging? | 18:39 |
*** ajayaa has quit IRC | 18:40 | |
stevemar | nkinder, i was using emailAddress instead of uid as the ldap attribute, that was working for me initially, but died when i tried to do a user list for a known group | 18:40 |
stevemar | ayoung, nah | 18:40 |
stevemar | nkinder, because the results of a group member list were just uids | 18:40 |
stevemar | anyway, i'm playing around with it now, and set the user-id attribute to uid. but now i'm failing authorization | 18:41 |
*** harlowja_ has joined #openstack-keystone | 18:41 | |
nkinder | stevemar: the group members need to be DNs, not uids | 18:42 |
*** ajayaa has joined #openstack-keystone | 18:42 | |
morganfainberg | nkinder: unless you do evil standards breaking awfulness. | 18:43 |
morganfainberg | *cough*ive never done that ever inswear*cough* | 18:43 |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation https://review.openstack.org/131541 | 18:44 |
nkinder | morganfainberg: you're not alone.... entire operating systems do that for LDAP group membership too | 18:44 |
*** harlowja has quit IRC | 18:45 | |
*** aix has quit IRC | 18:45 | |
morganfainberg | I know :( | 18:46 |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation https://review.openstack.org/131541 | 18:46 |
*** NM has quit IRC | 18:47 | |
stevemar | nkinder, sent you a bunch of PMs | 18:48 |
nkinder | marekd: for the case you mentioned previously (users from multiple IdP sharing the same project), wouldn't you just use the same domain for those IdPs? | 18:48 |
nkinder | marekd: there's nothing wrong with mapping multiple IdPs to one domain | 18:49 |
morganfainberg | nkinder, doesn't even need to be the same domain (unless you're getting into strict HM-reseller security cases) | 18:50 |
morganfainberg | nkinder, you just assign a role to that user/group/whatever on that project | 18:50 |
morganfainberg | or even craft a good mapping rule to make it so *all* members from that IDP can share the project | 18:51 |
* morganfainberg wonders why he's not on vacation yet. | 18:51 | |
crinkle | stevemar: do you happen to know how often distros update their packages for python-openstackclient? ubuntu seems to be lagging a little | 18:52 |
stevemar | crinkle, that i don't know, we just post to pypi, what version are you seeing? | 18:53 |
crinkle | stevemar: ubuntu has 0.3.0 http://packages.ubuntu.com/trusty/python/python-openstackclient | 18:53 |
stevemar | yeesh thats old | 18:54 |
crinkle | fedora is a little more up to date https://apps.fedoraproject.org/packages/python-openstackclient | 18:54 |
morganfainberg | crinkle, UCA should be more up-to-date | 18:55 |
morganfainberg | crinkle, check cloud archive for ubuntu. | 18:55 |
morganfainberg | the base packages will always be waaaaay out of date | 18:55 |
morganfainberg | and likely fedora will have a similar EPEL etc. | 18:56 |
morganfainberg | though ayoung and nkinder could speak to that more readily | 18:56 |
nkinder | crinkle: so we update the version when preparing for new releases, then on-demand as needed (for fixing important bugs, pulling in a new feature that's important, etc.) | 18:57 |
ayoung | morganfainberg, I'm not really certain what the ubuntu process is. Fedora is probably more akin to Debian upstream than to Ubuntu, with Ubuntu more comparable to RHEL/CentOS. | 18:58 |
ayoung | albeit the parallels break down. | 18:58 |
crinkle | morganfainberg: I'm not seeing it on uca | 18:58 |
morganfainberg | crinkle, thats unfortunate | 18:58 |
morganfainberg | crinkle, i am used to UCA being much more up to date | 18:58 |
ayoung | crinkle, you might want to start by looking in Debian testing, and then .... | 18:58 |
morganfainberg | ayoung, ++ or unstable | 18:59 |
ayoung | not sure the process to get Ubuntu to update, | 18:59 |
morganfainberg | ayoung, in this case i think it's really UCA needs to be updated. | 18:59 |
nkinder | crinkle: 0.3.0 is pretty old... | 18:59 |
ayoung | morganfainberg, could be. Not sure what the criteria is that Ubuntu uses to say that a package is ready for inclusion | 18:59 |
morganfainberg | ayoung, and UCA comes from upstream direct i think. | 18:59 |
morganfainberg | not debian | 18:59 |
ayoung | UCA? | 18:59 |
morganfainberg | though zigo probably knows | 18:59 |
morganfainberg | ubuntu cloud archive | 18:59 |
morganfainberg | its where releases of OpenStack are located | 19:00 |
morganfainberg | crinkle, i'd chase down zigo for packaging info, he's the openstack debian packager (and does it in his free time iirc), super awesome guy to get info on this from. | 19:01 |
crinkle | morganfainberg: awesome, thank you | 19:01 |
* morganfainberg doesn't have any direct cannonical contacts or i'd point you at them as well | 19:01 | |
*** NM has joined #openstack-keystone | 19:02 | |
morganfainberg | though pliea2 (in openstack-infra) might have contacts, she's involved with ubuntu community i think. | 19:02 |
morganfainberg | pleia2? | 19:02 |
* morganfainberg might be dyslexic today | 19:03 | |
nkinder | morganfainberg: I before E except after C... ;) | 19:03 |
crinkle | okay cool | 19:04 |
morganfainberg | nkinder, or as sounded as lay-ah as in P(rincess)Leia or way-uh? | 19:04 |
morganfainberg | nkinder, /me thinks its coffee and go on vacation for a couple days time. | 19:04 |
morganfainberg | nkinder, ;) | 19:05 |
morganfainberg | nkinder, i only guess thats the pronounciation there because that's liz's website. | 19:06 |
*** browne has quit IRC | 19:08 | |
*** browne has joined #openstack-keystone | 19:09 | |
morganfainberg | XML support removal in tempest is rapidly merging/ | 19:09 |
morganfainberg | yay | 19:09 |
morganfainberg | no more XML [except in SAML] | 19:09 |
rodrigods | morganfainberg, ++ | 19:10 |
rodrigods | morganfainberg, the buggy part in the SAML metadata retrieval was the XML bits heh | 19:10 |
openstackgerrit | Steve Martinelli proposed openstack/keystone: User ids that begin with 0 cannot authenticate through ldap https://review.openstack.org/137449 | 19:15 |
stevemar | morganfainberg, i found a nice bug :) | 19:15 |
stevemar | crinkle, dtroyer and i were really hoping to release a new version this week and last, but the gate is super broken for client builds | 19:16 |
stevemar | we haven't had a successful build in > 1 week now | 19:16 |
crinkle | stevemar: :'( | 19:17 |
bknudson | we might have a fix for the keystoneclient / middleware issues | 19:25 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Trust redelegation https://review.openstack.org/126897 | 19:25 |
bknudson | it's an infra change: https://review.openstack.org/#/c/136512/ | 19:26 |
*** NM has quit IRC | 19:29 | |
*** edmondsw has joined #openstack-keystone | 19:30 | |
samuelms | morganfainberg, do you have a status of sql-id-binary-16 spec? | 19:46 |
*** NM has joined #openstack-keystone | 19:46 | |
samuelms | morganfainberg, I tried to ping dolphm but it looks like he's having a busy day | 19:46 |
samuelms | morganfainberg, I'd like to grab that | 19:46 |
morganfainberg | Sql-id-binary-16? | 19:47 |
samuelms | morganfainberg, https://blueprints.launchpad.net/keystone/+spec/sql-id-binary-16 | 19:47 |
morganfainberg | samuelms: most us folks are going to be checked out today. Holiday tomorrow. | 19:47 |
morganfainberg | That bp might be dead, not all ids are uuids. | 19:48 |
*** NM has quit IRC | 19:48 | |
morganfainberg | Some are >32 bytes (sha256). | 19:48 |
samuelms | morganfainberg, wow .. sure .. thanksgiving | 19:48 |
samuelms | morganfainberg, those ids (sha256) are for what entities ? | 19:49 |
samuelms | morganfainberg, I'd like to take a look on the code .. | 19:49 |
morganfainberg | Users and groups when using multi ldap backend. | 19:49 |
morganfainberg | And in ldap userids arent uuid, that are db based. | 19:50 |
morganfainberg | Etc. | 19:50 |
stevemar | ayoung, so apparently this code hasn't changed since 2012 when you wrote it, any chance you remember why you converted to int? https://github.com/openstack/keystone/commit/63437e9dca3b969c917fb138716aa4d3e5fabafa | 19:52 |
stevemar | looking specifically at the ldap2py function | 19:52 |
samuelms | morganfainberg, yep .. makes sense .. thanks | 19:54 |
morganfainberg | stevemar: some of that is just "it worked initially". | 19:55 |
morganfainberg | stevemar: and without complaints bugs etc, it hasn't changed. | 19:55 |
stevemar | morganfainberg, yeah thats what i'm thinking | 19:55 |
stevemar | i've got a nice juicy corner case bug :) | 19:56 |
*** NM has joined #openstack-keystone | 19:56 | |
*** dims has quit IRC | 19:56 | |
morganfainberg | Fun. | 19:56 |
*** NM has quit IRC | 19:57 | |
stevemar | morganfainberg, it's explained here: https://review.openstack.org/#/c/137449/ opening a LP bug now | 19:58 |
morganfainberg | Fun times. Yeah def needs a bug. | 19:58 |
morganfainberg | Make sure if you have confirmed it you prioritize and classify the bug. Don't leave it in new. | 19:59 |
*** NM has joined #openstack-keystone | 20:00 | |
*** radez_g0n3 is now known as radez | 20:01 | |
stevemar | morganfainberg, https://bugs.launchpad.net/keystone/+bug/1396763 | 20:21 |
uvirtbot | Launchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [Undecided,New] | 20:21 |
stevemar | med or high? | 20:22 |
stevemar | bknudson, ayoung nkinder i'm open to suggestions on this one: https://bugs.launchpad.net/keystone/+bug/1396763 and y'all are the ldap gurus | 20:23 |
uvirtbot | Launchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [High,Confirmed] | 20:23 |
bknudson | stevemar: not really anything to do with ldap... the values have to be the right type. | 20:24 |
stevemar | bknudson, well yes, i am wondering if we need the int() conversion still? whats the point of it if we mostly deal with strings anyway | 20:25 |
stevemar | even if it's a timestamp, i think we would want a string | 20:25 |
bknudson | stevemar: have to go through the spec and see if there's values that are ints... mostly isn't good enough. | 20:25 |
ayoung | stevemar, I think it is a python issue. It is treating the value as a hex number? | 20:26 |
stevemar | bknudson, but it's not just that, it's how we end up consuming that | 20:26 |
stevemar | ayoung, no, treating it as an integer, but by treating it as an integer it drops the leading zero | 20:27 |
ayoung | yeah, that is wrong | 20:27 |
ayoung | any reason to treat it as an integer? | 20:28 |
stevemar | ayoung, thats where it gets tricky, it attempts to convert any/all fields coming back from ldap | 20:28 |
*** nkinder has quit IRC | 20:28 | |
ayoung | yeah, I'm guessing due to posix userids | 20:28 |
*** _cjones_ has quit IRC | 20:28 | |
*** ajayaa has quit IRC | 20:28 | |
ayoung | shudder | 20:29 |
stevemar | but it's converting these fields for our *own* use in the code / backends | 20:29 |
ayoung | what happens if we just don't do that? | 20:29 |
bknudson | the identity api spec says ids are strings so no reason to convert it to an int | 20:29 |
ayoung | does Keystone still work | 20:29 |
stevemar | then i can authN fine | 20:29 |
ayoung | yeah, drop the code that does that....then check what happens if you set a numeric field as the userid | 20:29 |
bknudson | I don't think users or groups have any ints. | 20:29 |
bknudson | it might cause a problem with enabled emulation | 20:30 |
bknudson | I mean the enabled mask or whatever it is | 20:30 |
stevemar | ayoung, i did comment out that code, that was the only way i could authN :) | 20:30 |
stevemar | bknudson, yep, i pushed a patch that removes that logic, and the enabled stuff failed | 20:31 |
stevemar | http://logs.openstack.org/49/137449/1/check/gate-keystone-python27/67dac9b/console.html | 20:31 |
bknudson | so maybe have a special case if the attribute is enabled then convert it... or change the enabled handling to convert it from a string. | 20:32 |
*** jdennis has joined #openstack-keystone | 20:34 | |
*** _cjones_ has joined #openstack-keystone | 20:35 | |
*** NM has quit IRC | 20:36 | |
*** jdennis1 has quit IRC | 20:37 | |
*** NM has joined #openstack-keystone | 20:37 | |
*** henrynash has joined #openstack-keystone | 20:38 | |
*** ChanServ sets mode: +v henrynash | 20:38 | |
*** NM has quit IRC | 20:38 | |
*** arunkant has quit IRC | 20:44 | |
ayoung | morganfainberg, so I am going to drive on with the access info code and use it to update the way we are doing revocation events | 21:02 |
ayoung | In doing so, I'll make sure it works for policy as well | 21:02 |
ayoung | I assume you are nowhere near getting ready to redo the token provider stuff. I'm tempted to integrated it into that code as well | 21:02 |
*** edmondsw has quit IRC | 21:09 | |
*** radez is now known as radez_g0n3 | 21:17 | |
morganfainberg | ayoung: the access info stuff is part of that and can be done first. | 21:18 |
ayoung | morganfainberg, agreed. Do you want me to take it on? | 21:18 |
morganfainberg | Go for continuing with it. I'll show you the abstract stuff on Monday, you might include it then. If not should matter. | 21:18 |
ayoung | deal | 21:18 |
morganfainberg | Up to you, I'm starting to see clear and have time to engineer things now that ptl suff is moving more smoothly. | 21:19 |
morganfainberg | Taken a bit of time to get things on track. | 21:19 |
rodrigods | ayoung, https://review.openstack.org/#/c/137476/ thiagop improved a bit the docstring :) | 21:22 |
ayoung | morganfainberg, I just suspect that the access info will be more fully featured if it is used in the token provider first. | 21:23 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: WIP - Improve list role assignments filters performance https://review.openstack.org/137202 | 21:27 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests https://review.openstack.org/137021 | 21:28 |
*** NM has joined #openstack-keystone | 21:43 | |
*** nkinder has joined #openstack-keystone | 21:45 | |
nkinder | jdennis: did you see stevemar's bug? https://bugs.launchpad.net/keystone/+bug/1396763 | 21:46 |
uvirtbot | Launchpad bug 1396763 in keystone "user id beginning with 0 cannot authenticate through ldap" [High,Confirmed] | 21:46 |
nkinder | jdennis: I think that is code you are familiar with. Do you know why we try to convert the value to an int before falling back to utf8? | 21:46 |
*** jdennis1 has joined #openstack-keystone | 21:46 | |
*** jdennis has quit IRC | 21:47 | |
nkinder | jdennis1: In stevemar's case, he has a numeric identifier for the user in LDAP, which happens to be prefixed by a 0 | 21:48 |
stevemar | which causes all sorts of calamity when we convert to int() | 21:48 |
nkinder | stevemar: my concern is that something else might be depending on that conversion to int | 21:49 |
nkinder | stevemar: did you run through the tests with the conversion removed? | 21:49 |
stevemar | nkinder, yes, bknudson called it - enabled emulation stuff | 21:50 |
nkinder | stevemar: I'd also check the use of userAccountControl with active directory since that's a numeric value that we do a bitmask check on | 21:50 |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists. https://review.openstack.org/136946 | 21:52 |
nkinder | stevemar: yeah, it's the enabled mask stuff that's failing in your review | 21:53 |
stevemar | yep | 21:53 |
nkinder | stevemar: I would expect that enabled emulation to work since that's not actually getting a numeric value from LDAP (it's just using group membership) | 21:53 |
openstackgerrit | Steve Martinelli proposed openstack/keystone: User ids that begin with 0 cannot authenticate through ldap https://review.openstack.org/137449 | 21:53 |
stevemar | nkinder, ^ | 21:53 |
nkinder | and a boolean LDAP attribute returns "True" and "False" strings | 21:54 |
stevemar | nkinder, i can't imagine there are many that return t/f aside from enabled | 21:55 |
nkinder | stevemar: no, and it's not even t/f which is a problem since LDAP represents those as actual strings | 21:55 |
nkinder | The enabled attribute is the only attribute that we care about treating as a number, and that's only when using the mask option. | 21:56 |
stevemar | nkinder, ahhh, because it's a bit mask | 21:56 |
nkinder | stevemar: so it can be special cased (which might be what your most recent patch does)... | 21:56 |
nkinder | stevemar: yes, exactly | 21:56 |
stevemar | nkinder, thats exactly what it does | 21:56 |
*** kobtea has joined #openstack-keystone | 21:57 | |
stevemar | we have a surprisingly large amount of id's that start with 0 (ibm ldap), i'm kinda surprised it wasn't found earlier | 21:57 |
stevemar | but i guess that user would have to authN, or someone would be detailed enough to notice someone missing from a returned user/group listing | 21:59 |
ayoung | might there be other AD issues? I wonder if this code is from CERN's AD effort? | 22:00 |
*** lhcheng has joined #openstack-keystone | 22:01 | |
nkinder | ayoung: userAccountControl should be the only need for an int conversion | 22:01 |
ayoung | Nah...I wrote that, direct port from the Nova/Pre KSL code | 22:01 |
*** kobtea has quit IRC | 22:01 | |
*** lhcheng_ has joined #openstack-keystone | 22:03 | |
*** NM has quit IRC | 22:04 | |
*** lhcheng has quit IRC | 22:05 | |
*** lhcheng_ is now known as lhcheng | 22:06 | |
ayoung | nkinder, https://review.openstack.org/#/c/129951/ still is not showing up as either merged or in Zuul. I went through a recheck when I set reverify, but then, Bupkis | 22:07 |
nkinder | ayoung: yeah, I looked at it this morning. Not sure what's up with that... | 22:07 |
nkinder | maybe time to bug infra... | 22:08 |
ayoung | gonna ask in infra | 22:08 |
nkinder | ayoung: thx | 22:08 |
openstackgerrit | Will Foster proposed openstack/keystone: skip assignment rows migrate if duplicate entry exists. https://review.openstack.org/136946 | 22:19 |
*** lhcheng has quit IRC | 22:34 | |
*** lhcheng has joined #openstack-keystone | 22:35 | |
*** tellesnobrega_ has joined #openstack-keystone | 22:40 | |
*** EmilienM has quit IRC | 22:47 | |
*** EmilienM has joined #openstack-keystone | 22:47 | |
*** stevemar has quit IRC | 22:50 | |
*** jamielennox|away is now known as jamielennox | 22:51 | |
openstackgerrit | Andre Aranha proposed openstack/keystone: Modify the default policy https://review.openstack.org/123509 | 22:54 |
*** gordc has quit IRC | 22:55 | |
jamielennox | bknudson: well found on that neutron postgres issue - i went through those logs and didn't see anything that linked to that bug | 22:59 |
zigo | morganfainberg: I'm not doing OpenStack packaging "on my free time", this was the case 3 years ago, now I'm a full time employee of Mirantis, after I was a contractor of eNovance for 2 years. :) | 23:02 |
zigo | crinkle: How may I help? | 23:02 |
jdennis1 | nkinder, stevemar: the fundamental problem is the code that returns values from LDAP needs to know the LDAP schema in order to know the syntax of the attribute | 23:03 |
nkinder | jdennis1: yeah, but we at least know how we expect to treat the values for things like the id or name | 23:03 |
jdennis1 | without that information everything else is just a hack and will fail one way or another | 23:03 |
crinkle | zigo: hello, we were wondering about getting up-to-date python-openstackclient for Debian and UCA and thought you could point us in the right direction | 23:03 |
zigo | What is UCA btw? Google suggests "University of Central Arkansas" though I'm sure you were not referencing that! :) | 23:04 |
jdennis1 | nkinder: are you suggesting a hard coded table of syntax? | 23:04 |
crinkle | pleia2 has directed me to #ubuntu-server and I'm waiting for some folks to wake up | 23:04 |
crinkle | ubuntu cloud archive | 23:04 |
zigo | Ah ok... | 23:05 |
nkinder | jdennis1: not exactly. I'm mainly stating that we know that we will take the 'id' attriute value and use it later in a search filter, so we know that it should never be transformed in the way that int() is doing it | 23:06 |
zigo | crinkle: I can update it *now* if you wish. | 23:06 |
zigo | crinkle: Though we have 0.4.0 in Debian, and Ubuntu has just 0.4.1. | 23:06 |
jdennis1 | nkinder: in IPA we retrieve the schema from the server and the code that does the ldap to python conversion utilizes that information to convert it to a python type | 23:07 |
zigo | crinkle: There was no more new tags since... | 23:07 |
zigo | crinkle: Do you need something even newer? | 23:07 |
crinkle | zigo: I wasn't able to find it in ubuntu, could you point it out to me? | 23:07 |
crinkle | I think 0.4.1 is the newest | 23:07 |
nkinder | jdennis1: yes, that's the right approach to take | 23:07 |
jdennis1 | nkinder: but the code that does the int conversion occurs before you receive the ldap attribute from the ldap code | 23:07 |
zigo | crinkle: http://packages.ubuntu.com/search?keywords=python-openstackclient&searchon=names&suite=all§ion=all | 23:07 |
crinkle | oh, I was only looking at trusty | 23:08 |
crinkle | I didn't even know there was a v | 23:08 |
zigo | crinkle: The package in Ubuntu is based on the one in Debian, made by Gustavo Panizzo. He's the 2nd active openstack package contributor in Debian, though he hasn't done much over the last few months, since he moved in China. | 23:09 |
jdennis1 | nkinder: so the logic not to convert that attribute to an int has to occur there, right? | 23:09 |
jdennis1 | not at a higher level | 23:10 |
crinkle | zigo: we're going to be wanting this for trusty i think | 23:11 |
nkinder | jdennis1: no, it was a value we got from LDAP which we then convert | 23:11 |
nkinder | jdennis1: we just happen to then later reuse that converted value in an LDAP filter for another operation | 23:11 |
zigo | crinkle: hang on for a few minutes and I will make the backport for it. | 23:13 |
*** browne has quit IRC | 23:13 | |
crinkle | zigo: I don't really need it right this second, I was more trying to feel out who to talk to and what kind of timeline to expect | 23:13 |
crinkle | it's great that you're so responsive :) | 23:14 |
zigo | crinkle: it's just that I forgot to add it to my jenkins for trusty, otherwise it would be there already. | 23:14 |
crinkle | aha :) | 23:14 |
jdennis1 | nkinder: well, I'm confused, I thought the issue was the LDAP syntax is string but we converted it to int after the ldap query | 23:16 |
nkinder | jdennis1: It is, but we then use that converted value to perform a second search operation | 23:17 |
nkinder | jdennis1: for example, you log in with "jdennis" as your username, and I lookup your id from LDAP | 23:17 |
nkinder | jdennis1: ...let's say that id is "0123" | 23:17 |
jdennis1 | nkinder: right, so the problem is we should not have converted from string to int, or am I missing something? | 23:18 |
nkinder | jdennis1: We convert that, and it's represented as "123" in the user object | 23:18 |
nkinder | jdennis1: We then try to look up what groups your in with "(&(uid=123)(objectclass-user))", but that won't find you | 23:18 |
jdennis1 | nkinder: isn't the converted value the integer 123, not the string "123" | 23:18 |
*** tellesnobrega_ has quit IRC | 23:18 | |
nkinder | jdennis1: yes, but it ends up as a string when we create the LDAP filter | 23:19 |
jdennis1 | nkinder: doesn't the problem simply go away if the int conversion for that attribute does not occur and the original string is returned instead? | 23:19 |
nkinder | jdennis1: so yes, the conversion is the problem. We take the path of "looks like an int, smells like an int, ..." | 23:19 |
nkinder | jdennis1: yep, that works fine that way | 23:20 |
nkinder | jdennis1: did you see stevemar's patch? | 23:20 |
jdennis1 | nkinder: so we need a lookup table of some sort to drive the conversion | 23:20 |
jdennis1 | no, have not looked at the patch | 23:20 |
nkinder | ok, it's a special case hack (but it works) - https://review.openstack.org/#/c/137449 | 23:20 |
nkinder | jdennis1: it's still guessing at the possible syntax | 23:21 |
nkinder | jdennis1: but we should only need an int for the enabled attribute, as AD uses a numeric userAccountControl value | 23:22 |
nkinder | jdennis1: I wonder if AD actually uses the "Integer" syntax for UserAccountControl... I'm not confident enough to bet either way | 23:24 |
jdennis1 | nkinder: why not a lookup table (i.e. a dict) that maps from an attribute name to a python class? i.e. return table[attr](value) | 23:25 |
nkinder | that would be a fine solution | 23:26 |
jdennis1 | the value is a type obect, i.e. a constructor, for instance str, unicode, int, bool, etc | 23:26 |
*** gokrokve has quit IRC | 23:27 | |
nkinder | jdennis1: it requires some LDAP know-how to look up the details and set things properly, but it would allow for a proper configuration | 23:27 |
jdennis1 | for the time being instead of using the schema we can have a small table of known attributes, this can later be replaced by a full table populated by the schema | 23:27 |
nkinder | jdennis1: that's only a forward looking solution though (doesn't meet the stable backport requirements) | 23:27 |
jdennis1 | why not? | 23:28 |
nkinder | jdennis1: not supposed to add new config | 23:28 |
jdennis1 | I'm not suggesting a new config, the table is hardcoded into ldap.py | 23:28 |
jdennis1 | er, rather ldap/core.py | 23:29 |
nkinder | jdennis1: so is 'attr' in your proposal the LDAP attribute name or the keystone attribute? | 23:30 |
nkinder | jdennis1: I'm guessing the keystone attribute since you're saying it's hardcoded | 23:30 |
jdennis1 | nkinder: actually for a while we ran that way in IPA, a small table of known "special" attributes, until it got unweildy | 23:30 |
nkinder | jdennis1: we need flexibility though. Take the 'enabled' attribute as an example... | 23:31 |
nkinder | jdennis1: if it's AD, the enabled attribute is an int | 23:31 |
jdennis1 | no, I mean the ldap attribute name, which technically is the type, a very confusing word :-) | 23:31 |
nkinder | jdennis1: if it's IPA, the enabled attribute is a boolean | 23:31 |
jdennis1 | that's a problem :-) | 23:32 |
jdennis1 | what other information disabiguates the two? | 23:32 |
jdennis1 | is it the object class? | 23:32 |
morganfainberg | zigo: I though you did packaging on free time and other stuff else time. | 23:36 |
morganfainberg | zigo: I apologize for being wrong. :) | 23:36 |
morganfainberg | Ahh | 23:36 |
zigo | morganfainberg: No need to apologize, but think about it: I'm doing *all* of the Python module dependencies for *both* Debian and Ubuntu (they just "sync" form Debian, right?). | 23:37 |
zigo | morganfainberg: How could I humanly just do this "on my free time" ?!? :) | 23:37 |
zigo | That's 200 packages that we're talking about ... | 23:37 |
zigo | http://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org | 23:37 |
morganfainberg | zigo: fist point. | 23:38 |
zigo | :) | 23:38 |
zigo | Oh gosh, we're really at more than 200 now !!! :( | 23:42 |
*** htruta_ has joined #openstack-keystone | 23:43 | |
*** tellesnobrega_ has joined #openstack-keystone | 23:47 | |
zigo | crinkle: http://juno-trusty.pkgs.mirantis.com/debian/pool/trusty-juno-backports/main/p/python-openstackclient/ | 23:53 |
zigo | Just fresh out of my Jenkiins! :) | 23:53 |
zigo | Let me know if you find some issue. | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!