| *** stevemar has joined #openstack-keystone | 00:04 | |
| *** leonchio_ has quit IRC | 00:04 | |
| *** gokrokve has quit IRC | 00:28 | |
| *** gokrokve has joined #openstack-keystone | 00:29 | |
| *** bknudson has joined #openstack-keystone | 00:29 | |
| *** gokrokve has quit IRC | 00:33 | |
| *** gokrokve has joined #openstack-keystone | 01:14 | |
| *** gokrokve has quit IRC | 01:14 | |
| *** gokrokve has joined #openstack-keystone | 01:15 | |
| openstackgerrit | A change was merged to openstack/keystone: Keystone service throws error on receiving SIGHUP https://review.openstack.org/107482 | 01:21 |
|---|---|---|
| stevemar | bknudson, clearly we need some non-ibmers to review some of our patches! | 01:36 |
| bknudson | stevemar: we should talk to their employer and tell them to spend more time on reviews | 01:37 |
| bknudson | they should get paid for reviews | 01:37 |
| stevemar | bknudson, maybe they are not reviewing ours because we don't review their, spite and all | 01:37 |
| stevemar | dolphm, seems like the grudge holding type | 01:38 |
| *** gokrokve has quit IRC | 01:39 | |
| *** gokrokve has joined #openstack-keystone | 01:39 | |
| *** gokrokve has quit IRC | 01:43 | |
| ayoung | bknudson, stevemar spread the rumor that the non IBMers are going to get thrown off core. | 01:48 |
| stevemar | ayoung, starting with dolphm | 01:48 |
| ayoung | Heh. Seriously, though, what patches are languishing? | 01:49 |
| stevemar | ayoung, i think it's just this guy: https://review.openstack.org/#/c/113669/ | 01:51 |
| stevemar | oh right, this one too: https://review.openstack.org/#/c/112959/ ayoung | 01:53 |
| *** zzzeek_ has joined #openstack-keystone | 01:59 | |
| *** zzzeek has quit IRC | 01:59 | |
| *** zzzeek_ is now known as zzzeek | 01:59 | |
| *** yasukun has joined #openstack-keystone | 02:02 | |
| *** zzzeek has quit IRC | 02:18 | |
| ayoung | stevemar, the links one.... | 02:23 |
| ayoung | they would make the token larger. That would be bnad | 02:24 |
| ayoung | bad even | 02:24 |
| ayoung | stevemar, +A | 02:25 |
| ayoung | any others? | 02:25 |
| *** diegows has quit IRC | 02:25 | |
| openstackgerrit | A change was merged to openstack/keystone-specs: Role assignment notifications https://review.openstack.org/113669 | 02:28 |
| *** Krast has joined #openstack-keystone | 02:33 | |
| *** topol has joined #openstack-keystone | 02:35 | |
| openstackgerrit | A change was merged to openstack/identity-api: Make API specification match our token format. https://review.openstack.org/112959 | 02:37 |
| openstackgerrit | A change was merged to openstack/keystone: Rename bash8 requirement https://review.openstack.org/113828 | 02:45 |
| stevemar | ayoung, nah, just those two | 02:47 |
| stevemar | the links were never being returned, just some long standing copy pasta | 02:47 |
| nkinder | dstanek: I reviewed https://review.openstack.org/#/c/51610/ from a security perspective | 02:51 |
| nkinder | dstanek: it all looks fine to me. I don't see how that would leak anything sensitive. | 02:51 |
| nkinder | dstanek: I played around with openssl to trigger some various failures with the commands we run, and all of the error information is very generic and safe if exposed. | 02:52 |
| *** arosen1 has quit IRC | 03:05 | |
| *** arosen1 has joined #openstack-keystone | 03:05 | |
| *** Krast has quit IRC | 03:10 | |
| *** Krast has joined #openstack-keystone | 03:10 | |
| *** gokrokve has joined #openstack-keystone | 03:31 | |
| *** gokrokve has quit IRC | 03:33 | |
| *** harlowja is now known as harlowja_away | 03:42 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Bump hacking to 0.9.x series https://review.openstack.org/98996 | 03:42 |
| *** yasukun has quit IRC | 03:43 | |
| *** yasukun_ has joined #openstack-keystone | 03:44 | |
| *** chandankumar has joined #openstack-keystone | 03:54 | |
| *** rushiagr_away is now known as rushiagr | 03:56 | |
| *** hrybacki has joined #openstack-keystone | 04:06 | |
| *** chandankumar has quit IRC | 04:06 | |
| *** richm has quit IRC | 04:21 | |
| *** amcrn has quit IRC | 04:23 | |
| dstanek | nkinder: thanks! | 04:30 |
| nkinder | dstanek: sure | 04:32 |
| *** alex_xu has quit IRC | 04:32 | |
| *** alex_xu has joined #openstack-keystone | 04:33 | |
| *** amirosh has joined #openstack-keystone | 04:49 | |
| amirosh | hi guys, could you review https://review.openstack.org/#/c/113232/ I'm sure someone somewhere is waiting for this feature, we shouldn't make her waiting | 04:51 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Allow passing user_id to v2Password plugin https://review.openstack.org/113712 | 04:53 |
| amirosh | BRB | 04:53 |
| *** amirosh has quit IRC | 04:53 | |
| *** amirosh has joined #openstack-keystone | 04:54 | |
| *** rushiagr is now known as rushiagr_away | 04:56 | |
| *** amirosh has quit IRC | 04:58 | |
| *** rushiagr_away is now known as rushiagr | 05:03 | |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Allow unauthenticated discovery https://review.openstack.org/107570 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Make keystoneclient use an adapter https://review.openstack.org/97681 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Allow providing a default value to CLI loading https://review.openstack.org/113742 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Fix handling of deprecated opts in CLI https://review.openstack.org/113859 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Version independent plugins https://review.openstack.org/81147 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Make auth plugins dest save to os_ https://review.openstack.org/114435 | 05:21 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystonemiddleware: Refactor auth_token cache https://review.openstack.org/105314 | 05:25 |
| *** Krast has quit IRC | 05:31 | |
| *** jamielennox is now known as jamielennox|away | 05:35 | |
| *** arosen1 has quit IRC | 05:41 | |
| *** arosen2 has joined #openstack-keystone | 05:41 | |
| *** hrybacki has quit IRC | 05:47 | |
| *** alex_xu has quit IRC | 05:55 | |
| openstackgerrit | A change was merged to openstack/keystone: Bump hacking to 0.9.x series https://review.openstack.org/98996 | 06:01 |
| openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Transform a Keystone token to a SAML assertion https://review.openstack.org/110542 | 06:05 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/111920 | 06:06 |
| *** Krast has joined #openstack-keystone | 06:09 | |
| *** alex_xu has joined #openstack-keystone | 06:11 | |
| *** topol has quit IRC | 06:12 | |
| *** amirosh has joined #openstack-keystone | 06:14 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Create SAML generation route and controller https://review.openstack.org/114138 | 06:15 |
| *** tomoiaga has joined #openstack-keystone | 06:17 | |
| *** alex_xu has quit IRC | 06:21 | |
| *** stevemar has quit IRC | 06:22 | |
| *** alex_xu has joined #openstack-keystone | 06:27 | |
| *** arosen2 has quit IRC | 07:26 | |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/102244 | 07:46 |
| *** RicoLin has joined #openstack-keystone | 08:40 | |
| *** Dafna has quit IRC | 08:49 | |
| *** RicoLin has quit IRC | 08:49 | |
| *** RicoLin has joined #openstack-keystone | 08:51 | |
| *** RicoLin has quit IRC | 08:52 | |
| *** RicoLin has joined #openstack-keystone | 08:53 | |
| *** Dafna has joined #openstack-keystone | 08:58 | |
| *** RicoLin has quit IRC | 09:01 | |
| *** RicoLin has joined #openstack-keystone | 09:01 | |
| *** RicoLin has quit IRC | 09:33 | |
| *** Krast has quit IRC | 09:56 | |
| *** RicoLin has joined #openstack-keystone | 10:02 | |
| *** RicoLin has quit IRC | 10:06 | |
| *** RicoLin has joined #openstack-keystone | 10:06 | |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources https://review.openstack.org/96266 | 10:23 |
| *** RicoLin has quit IRC | 10:44 | |
| *** diegows has joined #openstack-keystone | 11:01 | |
| *** RicoLin has joined #openstack-keystone | 11:11 | |
| *** RicoLin has quit IRC | 11:25 | |
| *** rushiagr is now known as rushiagr_away | 11:30 | |
| *** rushiagr_away is now known as rushiagr | 11:35 | |
| *** aix has joined #openstack-keystone | 11:38 | |
| *** aix has quit IRC | 11:40 | |
| *** henrynash has joined #openstack-keystone | 11:40 | |
| *** aix has joined #openstack-keystone | 11:40 | |
| *** yasukun_ has quit IRC | 11:50 | |
| *** RicoLin has joined #openstack-keystone | 11:53 | |
| *** henrynash has quit IRC | 11:53 | |
| *** RicoLin has quit IRC | 12:05 | |
| *** henrynash has joined #openstack-keystone | 12:07 | |
| *** rushiagr is now known as rushiagr_away | 12:08 | |
| *** henrynash has quit IRC | 12:11 | |
| *** afazekas has joined #openstack-keystone | 12:19 | |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources https://review.openstack.org/96266 | 12:27 |
| *** gordc has joined #openstack-keystone | 12:29 | |
| *** cjellick has joined #openstack-keystone | 12:30 | |
| *** _elmiko is now known as elmiko | 12:40 | |
| *** jimbaker has joined #openstack-keystone | 12:44 | |
| *** aix has quit IRC | 12:55 | |
| *** aix has joined #openstack-keystone | 12:57 | |
| *** topol has joined #openstack-keystone | 12:57 | |
| *** radez_g0n3 is now known as radez | 12:59 | |
| *** jdennis has quit IRC | 13:01 | |
| *** russellb is now known as rustlebee | 13:03 | |
| *** topol has quit IRC | 13:04 | |
| *** joesavak has joined #openstack-keystone | 13:08 | |
| *** rushiagr_away has quit IRC | 13:09 | |
| *** nkinder has quit IRC | 13:10 | |
| miqui | is there keystone v3 installed with the latest devstack? | 13:12 |
| *** richm has joined #openstack-keystone | 13:16 | |
| dolphm | miqui: keystone itself has supported both v2 and v3 side by side since grizzly; to use v3 from the CLI, use python-openstackclient rather than python-keystoneclient's deprecated CLI | 13:18 |
| miqui | dolphm: thanks ... so the url endpoint displayed at the end of the devstack install is same but with /v3 ? | 13:19 |
| dolphm | miqui: yes | 13:19 |
| miqui | dolphm: thanks...so is this the proper way to test keystone and contribute? | 13:20 |
| *** fifieldt has quit IRC | 13:20 | |
| *** bknudson has quit IRC | 13:22 | |
| *** jdennis has joined #openstack-keystone | 13:22 | |
| dolphm | miqui: there's a lot of ways to contribute :) but if you're looking to do any sort of API work, we're certainly putting all our focus on v3 | 13:22 |
| miqui | awesome.... | 13:23 |
| miqui | dolphm: thanks.. | 13:24 |
| ayoung | miqui, want an easy hit? | 13:26 |
| *** rushiagr_away has joined #openstack-keystone | 13:27 | |
| ayoung | The Horizon code has some "v2.0" strings embedded in it. Yank those and make the URLs correct for either v2 or v3 | 13:27 |
| miqui | ayoung: sure... no better way to get started | 13:27 |
| ayoung | miqui, I'll post a link | 13:27 |
| miqui | ayoung: thanks... | 13:27 |
| miqui | interesting that those strings do not come from a config ... | 13:28 |
| ayoung | miqui, I need to find it...I made the change in an installed system, one of the few things not done in a git repo | 13:29 |
| ayoung | miqui, yeah, I think this one was an oversight, and someone might have got it already... | 13:29 |
| miqui | no probs... | 13:30 |
| miqui | i'll be around, i'll find another one... thnanks | 13:30 |
| ayoung | miqui, http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/api/keystone.py#n115 | 13:34 |
| ayoung | its not quite what I remebered | 13:34 |
| ayoung | it looks like someone has touched it....it used to bre | 13:34 |
| ayoung | bits = urlparse.urlparse(url) | 13:35 |
| ayoung | root = "://".join((bits.scheme, bits.netloc)) | 13:35 |
| ayoung | and that didn't work for V3...I had changed it to | 13:35 |
| ayoung | er..one more line, it had then | 13:35 |
| ayoung | url = "%s/v%s" % (root, VERSIONS.active) | 13:35 |
| ayoung | I had hacked it to | 13:35 |
| ayoung | url = "%s/v%s" % (url, VERSIONS.active) | 13:35 |
| ayoung | the current code might be better. | 13:36 |
| *** RicoLin has joined #openstack-keystone | 13:36 | |
| ayoung | but it still looks wrong....lets see | 13:36 |
| miqui | great..thanks. | 13:37 |
| ayoung | miqui, yeah, so that won;t work | 13:37 |
| ayoung | what I had in another code was replaceing the /v2.0 with "" if it was there. That was just proof of concept | 13:38 |
| ayoung | I think the right code might be something like | 13:38 |
| ayoung | url = url.replace('/v2.0',"") | 13:38 |
| ayoung | url = url.replace('/v3',"") | 13:38 |
| ayoung | url = urlparse.urljoin(url, 'v%s' % VERSIONS.active) | 13:39 |
| ayoung | Horizon should be doing discovery to find V2.0 vs V3, but since we have it as a config option, and since older clients need the service catalog to have V2.0 in there, we are kindof stuck with horrible hacks like this | 13:40 |
| *** bknudson has joined #openstack-keystone | 13:40 | |
| *** RicoLin has quit IRC | 13:40 | |
| miqui | hmm yeah i see,, | 13:41 |
| *** RicoLin has joined #openstack-keystone | 13:41 | |
| amirosh | hi guys, could someone review https://review.openstack.org/#/c/113091/ ? implementation of filter-credentials-by-user bp depends on it | 13:42 |
| *** hrybacki has joined #openstack-keystone | 13:45 | |
| ayoung | amirosh, sure. | 13:52 |
| amirosh | ayoung: thanks! you help me second time in a row, appreciate it | 13:53 |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Implement validation on the Catalog V3 resources https://review.openstack.org/96266 | 13:58 |
| ayoung | cred_from_credential_api = self.credential_api.list_credentials_for_user(self.user_id)) | 13:59 |
| ayoung | hard to do in IRC | 14:00 |
| ayoung | bottom line, its too pedantic for me to care about. Just so you know | 14:00 |
| *** nkinder has joined #openstack-keystone | 14:00 | |
| amirosh | Thanks for letting me know, I thought it's pep8 recommended way, will check | 14:01 |
| amirosh | ayoung: would it be too much to ask review https://review.openstack.org/#/c/113232/ - the last one for today, promise | 14:04 |
| *** henrynash has joined #openstack-keystone | 14:05 | |
| *** stevemar has joined #openstack-keystone | 14:08 | |
| *** henrynash has quit IRC | 14:18 | |
| stevemar | sometimes VPN just isn't your friend | 14:22 |
| *** gordc_ has joined #openstack-keystone | 14:23 | |
| ayoung | amirosh, do you need to update policy.json as well, or just cloudsample? | 14:23 |
| amirosh | ayoung: good question, I thought cloudsample was enough, perhaps I was wrong | 14:24 |
| ayoung | amirosh, your change won't take effect on standard policy | 14:25 |
| ayoung | lets see... | 14:25 |
| amirosh | I think I should change it too in that case | 14:25 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.json#n62 | 14:25 |
| ayoung | its admin only right now | 14:25 |
| ayoung | amirosh, no, I think I would prefer that we not touch the standard policy for this one | 14:26 |
| amirosh | ayoung: trust your judgement | 14:27 |
| *** mitz has quit IRC | 14:27 | |
| ayoung | amirosh, we can always roll in that change as a follow on if it is required. | 14:28 |
| ayoung | beating on it in cloudsample is the safer approach | 14:28 |
| *** vhoward has joined #openstack-keystone | 14:30 | |
| *** tomoiaga has quit IRC | 14:31 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION https://review.openstack.org/113998 | 14:31 |
| *** amirosh has quit IRC | 14:37 | |
| *** amirosh has joined #openstack-keystone | 14:38 | |
| *** amirosh has quit IRC | 14:42 | |
| morganfainberg | mornin. | 14:44 |
| *** henrynash has joined #openstack-keystone | 14:48 | |
| henrynash | stevemar: hi | 14:48 |
| stevemar | henrynash, hola | 14:49 |
| henrynash | stevemar; so maybe I’m just having a senior moment, but assuming we exchange a scoped token for a SAML assertion (for K2K), where in the assretion is the scope? | 14:49 |
| stevemar | henrynash, ahhh good question :) | 14:50 |
| stevemar | henrynash, rewind to icehouse | 14:50 |
| stevemar | henrynash, did the SAML assertions have scopes there? (nope) | 14:50 |
| stevemar | henrynash, the mapping determined what 'group' the user would be slotted into, and we would inherit roles from the group | 14:51 |
| henrynash | stevemar: True……although the original assertion was usncoped in that it had (i assume) everything that the IdP knows about me | 14:52 |
| stevemar | henrynash, that is also true... | 14:53 |
| *** zhiyan has quit IRC | 14:53 | |
| *** zhiyan has joined #openstack-keystone | 14:54 | |
| henrynash | stevemar: I’m just trying to work it if I’m the receivor of one of our K2K assertions, whether I can make sense of it….. | 14:54 |
| stevemar | henrynash, it should look like any other incoming assertion | 14:54 |
| henrynash | stevemar: so let me try and walk myself through this :-) | 14:55 |
| stevemar | henrynash, ideally we have keystoneclient issue the request to the SP, once it has the assertion in hand | 14:55 |
| henrynash | stevemar: I’m teh SP and providing some set of services (say compute for some set of projects) | 14:56 |
| stevemar | mmhmm | 14:57 |
| henrynash | stevemar: I assume I agree with the Keystone IdP cloud provider, that I should allow requests provided they have some set of roles? | 14:57 |
| stevemar | the SP admin should set up the keystone idp (create an identity_provider, protocol, and mapping) | 14:58 |
| henrynash | stevemar: agreed | 14:58 |
| henrynash | stevemar: and that mapping is driven by the “roles” we put in the assertion, I assume | 14:58 |
| stevemar | henrynash, yep | 14:59 |
| *** jorge_munoz has joined #openstack-keystone | 14:59 | |
| henrynash | stevemar: so if the role mapping required, say, “teaboy”… | 14:59 |
| henrynash | stevemar: so I could scope to any project (or domain) that I have the role “teaboy” on, swap that for an assertion and then go to the SP | 15:00 |
| stevemar | henrynash, thats the plan | 15:00 |
| stevemar | henrynash, not to muddy the waters, but you had me thinking... we could list all effective roles a user has, upon receiving a token | 15:01 |
| henrynash | stevemar: so we really saying (I think) role assignments are kind of global for K2K (i.e. it doesn’t matter what project/or domain they’re on) | 15:01 |
| henrynash | stevemar: which somehow feels odd to me | 15:01 |
| stevemar | henrynash, yeah it kinda does. what do you think about an unscoped token.. and getting effective roles ? | 15:02 |
| *** jorge_munoz has quit IRC | 15:02 | |
| stevemar | all/effective/inherited, whatever word we're using today | 15:02 |
| henrynash | stevemar: effective roles - meaning whatever roles you have anywhere? | 15:02 |
| stevemar | yes | 15:03 |
| henrynash | stevemar: well. that would actually be more accurate to what we are actually doing….I think I just need to tyhink though where what we are doing isn’t too scary! | 15:03 |
| henrynash | stevemar: back in sec | 15:03 |
| stevemar | k | 15:04 |
| *** jorge_munoz has joined #openstack-keystone | 15:04 | |
| *** topol has joined #openstack-keystone | 15:08 | |
| *** david-lyle has joined #openstack-keystone | 15:12 | |
| *** gokrokve has joined #openstack-keystone | 15:15 | |
| *** hrybacki has quit IRC | 15:15 | |
| *** mflobo has quit IRC | 15:16 | |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 15:25 |
| morganfainberg | anyone have any issues with spec: https://review.openstack.org/#/c/107325/ | 15:28 |
| morganfainberg | ? | 15:28 |
| morganfainberg | just wanted to check before pressing "go" on it | 15:28 |
| morganfainberg | ayoung, bknudson, if I'm adding documentation about token audit_ids... where would you expect that documentation? | 15:30 |
| morganfainberg | cc dolphm, ^ question i just asked ayoung, bknudson | 15:31 |
| bknudson | morganfainberg: https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md | 15:31 |
| morganfainberg | bknudson, ok. | 15:31 |
| ayoung | morganfainberg, looking | 15:31 |
| bknudson | morganfainberg: some people also look at the docs in http://developer.openstack.org/api-ref.html | 15:32 |
| bknudson | morganfainberg: and here -- http://docs.openstack.org/api/openstack-identity-service/2.0/content/ | 15:32 |
| morganfainberg | bknudson, yeah not sure which file to stick it in for the api-ref | 15:32 |
| morganfainberg | bknudson, i don't even know how to get it there. | 15:32 |
| morganfainberg | if it requires editing wadls, i uh i'm not doing it :P | 15:33 |
| bknudson | morganfainberg: POST /v3/auth/tokens | 15:33 |
| morganfainberg | bknudson, and v2/tokens my guess | 15:33 |
| bknudson | morganfainberg: (and I already filed a bug for the lack of sections in POST /v3/auth/tokens. | 15:33 |
| bknudson | morganfainberg: looks like it's also copied in GET /v3/auth/tokens | 15:34 |
| morganfainberg | bknudson, so, i have no clue where that data is generated from | 15:34 |
| bknudson | morganfainberg: WADLs! | 15:34 |
| morganfainberg | bknudson, ok i'll open a bug for the docteam. i don't think i'll be able to get it updated myself in any reasonable timeframe | 15:35 |
| bknudson | morganfainberg: you probably also have no clue what "xsd:string" is. | 15:35 |
| bknudson | we're in the same boat | 15:35 |
| morganfainberg | bknudson, phew, i am glad i'm not the only one :P | 15:35 |
| bknudson | or what "plain" style is. | 15:35 |
| ayoung | morganfainberg, what do you think of changing the end state of the specs to being documentation. We can state at some point that a spec is "approved" but the document we start writing can continue to morph past that point to be something usable long term? | 15:35 |
| *** gokrokve has quit IRC | 15:36 | |
| ayoung | It seems a waste to put all of the energy into the specs without making them part of the final product | 15:36 |
| morganfainberg | ayoung, something to consider, not something i want to think too hard about now. | 15:36 |
| *** joesavak has quit IRC | 15:36 | |
| *** joesavak has joined #openstack-keystone | 15:36 | |
| morganfainberg | ayoung, as in... not thinking about it today :P | 15:36 |
| * ayoung just planting the seed | 15:36 | |
| *** gokrokve has joined #openstack-keystone | 15:36 | |
| openstackgerrit | Richard Megginson proposed a change to openstack/keystone: Use mail for the default LDAP email attribute name https://review.openstack.org/94668 | 15:37 |
| ayoung | morganfainberg, so, basically I'm OK with the spec. The one reservation I have is that we need a way to communicate how to get tokens from tokens as well. If I get a token using X509 client cert or Kerberos, do I need to continue to use that mechanism when converting one token to another? What about SAML? | 15:38 |
| morganfainberg | ayoung, what? | 15:38 |
| ayoung | morganfainberg, ok...lets take the SAML case | 15:39 |
| morganfainberg | ayoung, i'm confused did we just end up in left field? | 15:39 |
| ayoung | no | 15:39 |
| ayoung | morganfainberg, there are three things an unscoped token with no service catalog can't tell us todya | 15:39 |
| ayoung | two are covered by Jamie's spec | 15:39 |
| morganfainberg | oh oh jamie's spec | 15:39 |
| ayoung | how to list projects and how to list domains | 15:39 |
| morganfainberg | like i said, felt like left feild going from tokens -> jamie's | 15:40 |
| ayoung | the third is how to exchange the token we have for a scoped one, using the info on projects | 15:40 |
| morganfainberg | ayoung, i don't think that really changes much with jamie's proposed change | 15:40 |
| ayoung | morganfainberg, in my Kerberos work, I have to be able to use the Password mechanism and the Kerberos mechanism for the same Keysteon server | 15:40 |
| morganfainberg | ayoung, those changes i see as improvements/further specs | 15:40 |
| ayoung | but ideally I would not let people using kerberos use the password mechanism | 15:41 |
| ayoung | this needs to be thought through | 15:41 |
| *** gokrokve has quit IRC | 15:41 | |
| ayoung | stay with me for a moment, | 15:41 |
| morganfainberg | ayoung, again don't see how that spec is changing that | 15:41 |
| ayoung | for each auth url, we should say "what mechanism is supported" | 15:41 |
| ayoung | or mechanisms | 15:41 |
| ayoung | and also, once we have an unscoped token, where do we go to get a scoped token | 15:41 |
| ayoung | I'm npot certain, however, that it needs to be in /auth | 15:42 |
| ayoung | listing mechanism would be like /auth/mechanisms , and that probably should be there | 15:42 |
| ayoung | listting projects and domains, though, probably should be links that become avaialble once you have a token | 15:42 |
| morganfainberg | ayoung, back up. if it isn't in /auth where should it go? | 15:42 |
| ayoung | and that doens;t need to be in /auth | 15:43 |
| ayoung | morganfainberg, I was thinking that the links to where to list project should be in the token response | 15:43 |
| ayoung | they don't need to be known before getting a token | 15:43 |
| ayoung | if I get an unscoped token, I should get access to the links. I'm almost thinking that Jamies spec is headed the wrong direction, away from discoverability | 15:43 |
| morganfainberg | so.. it goes wherever we want to stick it. | 15:44 |
| morganfainberg | just not /auth | 15:44 |
| ayoung | in the response | 15:44 |
| ayoung | leave the currnet /projects and /domains as is | 15:44 |
| morganfainberg | but... he's saying if you're asking information about your current scope you ask in /auth | 15:45 |
| morganfainberg | so why is it bad to put it there? i'm not clearly seeing the argument against it | 15:46 |
| ayoung | morganfainberg, it means you have "a-priori" knowledge of where to ask. Just becasue We do that throughout the API. doesn't make it right, though. | 15:46 |
| ayoung | I'm not certain it is either necessary nor sufficient | 15:46 |
| ayoung | not saying "no" just...suspect it is wrong | 15:47 |
| ayoung | You shouldn't have to read the spec to figure out what url to use | 15:47 |
| morganfainberg | so, please comment on the spec. it's been lingering and we are kind of at the deadline here. pocket veto wont fly :) | 15:47 |
| ayoung | you should chain that from the response to figure out where to go. | 15:47 |
| morganfainberg | you know he doesn't say you can't have those links in the response just that they'd exist in /auth/XXXX not <some ranome place> | 15:48 |
| morganfainberg | because it's relevant to auth | 15:48 |
| morganfainberg | current authorization scope, you don't ask /v3/domains "what domains do i have access to" | 15:49 |
| morganfainberg | with an unscoped token | 15:49 |
| *** aix has quit IRC | 15:49 | |
| morganfainberg | in either case, please comment on the spec, if it needs clarification in your mind, that would be fine - or if it really is headed in the wrong direction | 15:50 |
| *** HenryG has joined #openstack-keystone | 15:55 | |
| *** jsavak has joined #openstack-keystone | 16:01 | |
| *** aix has joined #openstack-keystone | 16:02 | |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 16:02 |
| *** joesavak has quit IRC | 16:04 | |
| ayoung | morganfainberg, I left a comment with neither + nor - . | 16:07 |
| ayoung | I know why he submitted it, as it is a response to this patch of mine: https://review.openstack.org/#/c/106838/ | 16:08 |
| bknudson | morganfainberg: do we support a migration directly from havana to juno (keystone-manage db_sync), or is that broken by removing the migrations? | 16:10 |
| *** cjellick has quit IRC | 16:11 | |
| *** cjellick_ has joined #openstack-keystone | 16:11 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/identity-api: Add information about audit_id in token docs https://review.openstack.org/114590 | 16:11 |
| *** hrybacki has joined #openstack-keystone | 16:15 | |
| *** cjellick_ has quit IRC | 16:16 | |
| morganfainberg | bknudson, we should be able to do havana -> juno | 16:19 |
| morganfainberg | bknudson, the collapse was to the last migration of havana | 16:19 |
| morganfainberg | bknudson, so as long as someone used havana release (and nothing wonky was backported) it *should* work | 16:20 |
| morganfainberg | ayoung, ++ thanks | 16:20 |
| bknudson | morganfainberg: I thought so... but someone here is complaining | 16:20 |
| morganfainberg | where is it failing? | 16:20 |
| bknudson | CRITICAL keystone [-] KeyError: <VerNum(35)> | 16:21 |
| bknudson | morganfainberg: which I assume means that the migration script isn't present | 16:21 |
| *** hrybacki has quit IRC | 16:21 | |
| morganfainberg | they should already be on ver36 | 16:21 |
| morganfainberg | if they are havana release | 16:21 |
| bknudson | morganfainberg: oh, weird. | 16:21 |
| ayoung | they are on Grizzly | 16:22 |
| morganfainberg | bknudson, https://github.com/openstack/keystone/tree/stable/havana/keystone/common/sql/migrate_repo/versions | 16:22 |
| * ayoung guesses | 16:22 | |
| morganfainberg | maybe they were on an RC of Havana? | 16:22 |
| morganfainberg | somehow missed that last migration | 16:23 |
| ayoung | keystone-manage db_version | 16:23 |
| morganfainberg | or the last two | 16:23 |
| *** hrybacki has joined #openstack-keystone | 16:23 | |
| morganfainberg | neither would affect keystone runtime (maybe make it a bit slower | 16:23 |
| * ayoung duh must be 34 | 16:24 | |
| morganfainberg | hehe | 16:24 |
| *** gokrokve has joined #openstack-keystone | 16:25 | |
| morganfainberg | bknudson, the easiest fix is to get an icehouse (or havana) git checkout, setup a venv and migrate to at least 36 before trying the juno upgrade. | 16:25 |
| morganfainberg | it's what metacloud had to do (for nova) when they jumped essex -> grizzly | 16:26 |
| *** comstud is now known as bearhands | 16:26 | |
| *** gokrokve has quit IRC | 16:27 | |
| bknudson | morganfainberg: y, maybe migration 36 failed for them and they didn't notice the failure. | 16:27 |
| morganfainberg | ayoung, thanks for the comment, that is a bit easlier to read than our conversation, totally get what you're driving at now. :) | 16:27 |
| henrynash | stevemar: sorry, back | 16:28 |
| stevemar | henrynash, np at all | 16:29 |
| morganfainberg | ayoung, i like everything being under /auth, but the links would def. make it clearer. | 16:29 |
| morganfainberg | ayoung, anyway, circle back w/ others / jamie first thing next week (or sunday our time) | 16:29 |
| morganfainberg | ayoung, see where we land | 16:29 |
| henrynash | stevemar: so I must admit I had imagined (!) that somehow the scope for which the roles were valid where in the assertion | 16:29 |
| *** hrybacki has quit IRC | 16:29 | |
| ayoung | morganfainberg, I think the key thing is that GET /auth should have links. The rest is commentary | 16:29 |
| morganfainberg | ayoung, yep. | 16:30 |
| henrynash | stevemar: which I realise isn’t very SAML-like | 16:30 |
| morganfainberg | ayoung, and i don't disagree in the slightest. | 16:30 |
| morganfainberg | ayoung, i think it isn't clear if that was the intention in the spec or not (it may have been) | 16:30 |
| raildo | henrynash: Could you see my last comment on hierarchical projects? | 16:30 |
| stevemar | henrynash, yeah, that would be the problem, just cause i have adminness on myown system, doesn't mean i have adminness on yours | 16:30 |
| henrynash | stevemar: quite true….but that’s the mapping does | 16:31 |
| stevemar | henrynash, you have to define the mapping which gives me some measure of authorization | 16:31 |
| stevemar | yep | 16:31 |
| ayoung | stevemar, henrynash I've been thinking about Horizon, login, Kerberos and SAML | 16:31 |
| stevemar | henrynash, i think the only thing i would change is maybe use an unscoped token, and get all the roles a user has | 16:31 |
| ayoung | what do you think of this idea: | 16:31 |
| henrynash | ayoung: sh*t…with those 4 things on the same line, I’m making a run for it now | 16:32 |
| stevemar | henrynash, lol wait for me! | 16:32 |
| ayoung | instead of Horizon going to keystone to fetch a token, Horizon uses Javascript to direct the user to Keystone to fetch a token, and the users's browser will then ajax-post it to Horizon | 16:32 |
| ayoung | its in line with marekd|away 's WebSSO approach | 16:33 |
| morganfainberg | henrynash, I'm with you there! | 16:33 |
| ayoung | Well, I have a requirement to support Kerberos from Horizon, and I think this is the simplest way. | 16:33 |
| ayoung | Then i realized it would work for SAML, too | 16:34 |
| henrynash | ayoung: so the principle of making Horizon work more in a WebSSO approach I think is good….we really don’t want it tied so tight……I think it kind of shows a godo work ing model | 16:34 |
| henrynash | stevemar: when you say unscoped token…you mean the one we supply to get the assertion, or the when we get in teh SP from the assertion? | 16:35 |
| ayoung | it would require CORS support for non-all-in-one deployments, but I don't think that is a huge barrier. Swift already has support for CORS | 16:35 |
| ayoung | http://en.wikipedia.org/wiki/Cross-origin_resource_sharing | 16:36 |
| stevemar | henrynash, the first one, one we would supply to get an assertion | 16:36 |
| henrynash | ayoung: so I’d have to dig in a look some more to commetn on the deatils of your suggestion…but I like the principle | 16:36 |
| ayoung | If I understand it correctly, it would work like this: the Javascript from horizon would have an additional header: Origin: http://horizon | 16:37 |
| henrynash | stevemar: well today, you can’t get an unscoped token that has roles in it | 16:37 |
| henrynash | stevemar: oh you mean you provide taht just to show proof of identity | 16:37 |
| ayoung | and then Keystone will have to respond with Access-Control-Allow-Origin: http://horizon | 16:37 |
| stevemar | henrynash, yep, but it's got the user_id, and we could query the backend to get all the roles she has | 16:37 |
| ayoung | which implies that horizon should be registered as an endpoint, and then we allow CORS between endpoints. I think. | 16:38 |
| stevemar | henrynash, although that would break the 'recursive' model, where a user is ephemeral :( | 16:38 |
| openstackgerrit | A change was merged to openstack/keystone: Support the hints mechanism in list_credentials() https://review.openstack.org/113091 | 16:38 |
| ayoung | stevemar, why do you need Roles again? | 16:39 |
| stevemar | ayoung, to put in the saml assertion | 16:39 |
| ayoung | stevemar, is this for K2K? | 16:39 |
| stevemar | ayoung, yep | 16:39 |
| henrynash | ayoung: the question is, for K2K federation via SAML, what are the “attribute” we put in it | 16:39 |
| ayoung | OK, lets start by stating the obvious. SAML and Keystone PKIZ tokens are just two different marshalling mechanisms | 16:40 |
| ayoung | neither should be able to have info that the other would not have | 16:40 |
| ayoung | it should be based on a scoped token, not an unscoped one | 16:40 |
| ayoung | so instead of /auth/tokens, I go to /auth/saml. That is all that is different. | 16:41 |
| *** aix has quit IRC | 16:41 | |
| henrynash | ayoung: so I raised this since the current spec doesn’t have the scope in it…so you get some roles, but as a consumer I can’t differente betweem to people turning up with “admin” in their assertion UNLESS we are going to treat roel assignments as “global” (which feel wroung) | 16:41 |
| henrynash | ayoung: but whatver we do, we need to be able to write some nice mapping rules that make sense of it | 16:42 |
| afaranha | Does someone knows how to execute a SQL migrate script? I have this migrate script https://review.openstack.org/#/c/111840/4/keystone/common/sql/migrate_repo/versions/052_add_parent_project.py that seems it is not being executed. | 16:42 |
| ayoung | I still see no reason to use SAML | 16:43 |
| ayoung | it confuses things | 16:43 |
| morganfainberg | raildo, added some comments to the spec | 16:43 |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 16:43 |
| morganfainberg | raildo, it is looking well rounded, just have some concerns | 16:43 |
| henrynash | afaranha: I think there is alerady a 52 defined | 16:43 |
| ayoung | SAML from our perspective should be limited to "proving" authentication, for limited, suspect values of prooving | 16:44 |
| ayoung | but that aside | 16:44 |
| ayoung | If I go t my local keystone, I need a scoped token to do anything outside of keystone | 16:44 |
| ayoung | that doens't change if I'm doing K2K | 16:44 |
| henrynash | ayoung: I think we agreed to use SAML as the K2K payload format | 16:44 |
| ayoung | henrynash, I never agreed | 16:44 |
| ayoung | I must have stepped out of the room, but that idea is not helping. | 16:45 |
| ayoung | Mind you, I have nothing against SAML, and love the Idea of Keystone supporting it in general | 16:45 |
| ayoung | just not that K2K somehow benefits from it | 16:45 |
| henrynash | ayoung: eek, I think everyone came away with…and that’s what the juno/spec was approved as | 16:45 |
| ayoung | it reflects, I think, a fundamental misunderstanding | 16:45 |
| morganfainberg | ayoung, i'm fairly certain you at least gave some concent to saml at the hackathon | 16:46 |
| morganfainberg | but it was late in the day that day | 16:46 |
| afaranha | henrynash: ah, true, thanks | 16:46 |
| ayoung | henrynash, does that mean I can't expect you guys to give a decent reality check to it | 16:46 |
| morganfainberg | might have been a lot of cross talk | 16:46 |
| ayoung | morganfainberg, it really doesn;t matter | 16:46 |
| ayoung | morganfainberg, I'm OK with SAML, but lets understand it as just a marshalling format. | 16:46 |
| morganfainberg | ayoung, i think the choice for saml comes from leeraging the federation code we have and mod_shib | 16:46 |
| raildo | morganfainberg: thanks! I will answer them now | 16:47 |
| ayoung | SAML in general looks like a snapshot of an LDAP query | 16:47 |
| morganfainberg | ayoung, was a low barrier to entry with support already in place (in a good way) | 16:47 |
| ayoung | morganfainberg, ah...but... | 16:47 |
| * ayoung just had epiphany | 16:47 | |
| ayoung | ok ,token pipeline | 16:48 |
| ayoung | we've discussed that alot | 16:48 |
| henrynash | ayoung: OK, let’s make it general….should the K2K payload passed include the roles a user has on the scoped entity to get this payload, along ith info on the scope taht was used | 16:48 |
| morganfainberg | and we'll keep discussing it :) until we get there. | 16:48 |
| ayoung | think of it this way: there is the unmarshall stage...apache does that for Kerbers and SAML, but Keystone does it for Token to Token exchanges | 16:48 |
| morganfainberg | henrynash, i don't *think* it would work like that, it would work like current federation, attributes (maybe the roles are used) are mapped to the group on the remote end | 16:49 |
| ayoung | so for K2K, lets say for arguments sake that we accept both | 16:49 |
| ayoung | the end product is a set of GROUPS | 16:49 |
| ayoung | if we were to use mod_auth_identity, it would be REMOTE_GROUPS. lets just use that as shorthand | 16:49 |
| henrynash | ayoung: I never said the roles were passed through unmodified…I agree they are jsut an attribute to be mapped at will by the SP receiving the payload | 16:50 |
| ayoung | henrynash, right, I 'm with you | 16:50 |
| ayoung | the disconnect is groups (flat) versus role-in-project | 16:50 |
| ayoung | so I thnk the SAML approach was assuming that the exporting keystone would flattend the role assignments somehow | 16:51 |
| ayoung | but it really doesn't matter who does it | 16:51 |
| ayoung | we need a way to convert a role assignment to a group. | 16:51 |
| morganfainberg | ayoung, so you're saying project:role is required? and that maps to the group on the other end? | 16:51 |
| ayoung | morganfainberg, absolutely | 16:51 |
| ayoung | or domain | 16:51 |
| ayoung | but... | 16:51 |
| ayoung | there can be additional roles assigned on the other end | 16:51 |
| morganfainberg | domain:role same thing, in this convo :) | 16:51 |
| henrynash | ayoung: the disconnet is: i supply a tolen scoped to project X to get my asserton..which is built with just teh roels/groups I have on project X……but (as spec’d today) no idea of project X is put in the assertion | 16:52 |
| ayoung | its only if you want to have roles on the remote side based on roles on the local side | 16:52 |
| ayoung | henrynash, its similar to the userid mapping issue you just resolved | 16:52 |
| ayoung | role:group | 16:53 |
| ayoung | er | 16:53 |
| henrynash | ayoung: so if am the SP receiving these assertions: two users claim to be in group/role “admin”…but they were for very different entities | 16:53 |
| ayoung | let me try that again | 16:53 |
| ayoung | admin should not come through. | 16:53 |
| ayoung | if I have admin on the demo project I could make a group demo-admin | 16:53 |
| ayoung | now, we have the same issues as the ID mapping about parsing | 16:53 |
| ayoung | so...we could hash, just like before. | 16:53 |
| morganfainberg | ayoung, i think you're thinking from the perspective if roles mapped 1:1 local to remote, they don't | 16:54 |
| ayoung | so the group in the SAML assertion would be sha256(project, role) | 16:54 |
| ayoung | morganfainberg, we can also do | 16:54 |
| ayoung | user always gets a group sha256(project) | 16:54 |
| ayoung | or just project if we don't care about consistnaacy | 16:54 |
| morganfainberg | ayoung, on which side? | 16:55 |
| morganfainberg | ayoung, i'm lost now | 16:55 |
| ayoung | morganfainberg, this is one reason that I prefer the keystone token format to SAML. Lets assume that for the moment | 16:56 |
| morganfainberg | ayoung, it sounds to me like you're saying the remote end automatically has a group for user based on the idp | 16:56 |
| *** nkinder has quit IRC | 16:56 | |
| openstackgerrit | A change was merged to openstack/keystone: Issue multiple SQL statements in separate engine.execute() calls https://review.openstack.org/110512 | 16:56 |
| *** aix has joined #openstack-keystone | 16:56 | |
| morganfainberg | ayoung, the confusion wouldn't change with a token vs saml | 16:56 |
| morganfainberg | ayoung, as far as i can tell | 16:56 |
| ayoung | if I have a token with {proejct: demo, role:admin} coming from my keystone, and I hand it to your keystone, your keystone can then map that to a group however it likes. | 16:56 |
| morganfainberg | you'd still not be able to use that token for anything *really* and have to map it to something local | 16:56 |
| ayoung | and...dchadwick would point out, that the groups were not how they wanted to do mapping in the first place | 16:57 |
| morganfainberg | no different than what we do with saml and federation | 16:57 |
| ayoung | you could instead map incoming project-role to outgoiung project-role | 16:57 |
| morganfainberg | and you'd still need to issue a new token for the remote cloud | 16:57 |
| ayoung | morganfainberg, yep | 16:57 |
| morganfainberg | so... we need to add extra attributes to act on in the k2k saml assertion... is what i'm getting out of this? | 16:58 |
| ayoung | morganfainberg, the difference is which keystone does the mapping in the K2K exchange | 16:58 |
| morganfainberg | the remote one always does the mapping | 16:58 |
| morganfainberg | the local one cannot since it doesn't know anything about the remote cloud | 16:58 |
| henrynash | ayoung: so all I was say (which is actually I think agreeing with ayoung) is that we shouldn’t lose scope information when we crreat the SAML assertion….so we need some mechanism of including it | 16:58 |
| morganfainberg | in both caes. | 16:58 |
| ayoung | morganfainberg, actually, we should look into the saml format, and see if it has a way to represnt the role intact. I bet it does | 16:59 |
| ayoung | I'm guessing SAML accounted for RBAC | 16:59 |
| morganfainberg | ayoung, the remote end still needs to do the mapping. | 16:59 |
| ayoung | henrynash, so, first off lets see if there is a clear way to persist the current keystone token data in SAML | 16:59 |
| morganfainberg | henrynash, yeah i think we need to include the scope data / roles as attributes so they can be acted on | 16:59 |
| henrynash | morganfainberg: ++ | 17:00 |
| morganfainberg | henrynash, it should be able to be done as attributes is my guess | 17:00 |
| ayoung | if there is, then SAML vs Keystone token is irrelevant | 17:00 |
| ayoung | it may mean, however, that we need to expand the scope of what the mapping mechanism accepts | 17:00 |
| ayoung | right now it accepts a list of groups, | 17:00 |
| henrynash | ayoung: agreed….and I think teh point of using SAML would be that its nice not to invent our own federation assertion…we’ve been accused on re-inventing the wheel enough already | 17:01 |
| ayoung | project-role could be represented that way, but it is ugly | 17:01 |
| morganfainberg | ayoung, it can only map to groups, but it accepts any attrinutes | 17:01 |
| morganfainberg | ayoung, iirc | 17:01 |
| ayoung | morganfainberg, ah | 17:01 |
| ayoung | then I think we are ok....we could, in theory, also let it map directly to role-project for certain domains, and it would avoid a lot of duplication of data, but that can come later | 17:01 |
| *** openstackgerrit has quit IRC | 17:02 | |
| *** openstackgerrit has joined #openstack-keystone | 17:02 | |
| morganfainberg | henrynash, ++++++++++ | 17:02 |
| * morganfainberg needs breakfast =/ | 17:02 | |
| ayoung | it also means we can stop treating Keystone tokens as different from any other mechanism | 17:02 |
| henrynash | nneds dinner | 17:02 |
| morganfainberg | henrynash, hows that side of the pond today? | 17:03 |
| henrynash | ayoung: agreed | 17:03 |
| ayoung | token for token would be handled the same regardless of where the token came from. Hmmmm | 17:03 |
| henrynash | morganfainberg: sunny and showers….. | 17:03 |
| morganfainberg | henrynash, nice | 17:03 |
| henrynash | sunny now…so runninng to grab dinner | 17:03 |
| morganfainberg | henrynash, have a good dinner! | 17:03 |
| *** harlowja_away is now known as harlowja | 17:03 | |
| morganfainberg | ayoung, it does open up a number of doors we can expand on | 17:04 |
| ayoung | morganfainberg, ok , I have a book with a bit about SAML in it right here.. This is an example from it | 17:07 |
| * ayoung types in | 17:07 | |
| *** nkinder has joined #openstack-keystone | 17:08 | |
| ayoung | <saml: AttributeDesignamtr AttributeName="username" AttributeNamesapce="iBuyStocks.com"> | 17:08 |
| ayoung | ugh, that was from the request...ok | 17:09 |
| ayoung | from the response | 17:09 |
| *** htruta has joined #openstack-keystone | 17:10 | |
| ayoung | <saml: Subject><saml: NameIdentifier SecuirytDomain="iBuyStocks.com" Name=joe.bloggs" /> <saml: Subject/> | 17:10 |
| ayoung | I would think that, in our case, the secuiryt domain would be something like | 17:11 |
| ayoung | https://remotekeystone/v3/projects/<projectid> | 17:11 |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 17:11 |
| ayoung | and then Role... | 17:12 |
| ayoung | http://adam.younglogic.com/resources/adam_example.saml is the one from my company that I somewhat modified for an example | 17:12 |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 17:13 |
| *** hrybacki has joined #openstack-keystone | 17:19 | |
| *** aix has quit IRC | 17:23 | |
| *** hrybacki has quit IRC | 17:23 | |
| *** shakamunyi has joined #openstack-keystone | 17:24 | |
| *** jorge_munoz has quit IRC | 17:26 | |
| *** aix has joined #openstack-keystone | 17:36 | |
| *** shakamunyi has quit IRC | 17:43 | |
| *** shakamunyi has joined #openstack-keystone | 17:57 | |
| bknudson | morganfainberg: looks like there were some migrations added since the original stable/havana? | 18:01 |
| raildo | morganfainberg: I answered your comments if you can look :) | 18:02 |
| *** amcrn has joined #openstack-keystone | 18:03 | |
| *** aix has quit IRC | 18:05 | |
| bknudson | morganfainberg: 2 migrations were added in 2013.2.2 ... so you can upgrade from 2013.2.2 to juno but not from 2013.2.1 or 2013.2 | 18:11 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Add parent_project_id field https://review.openstack.org/111840 | 18:12 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Base methods to handle hierarchical projects https://review.openstack.org/111841 | 18:13 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Create, update and delete hierarchical projects https://review.openstack.org/111842 | 18:13 |
| *** zzzeek has joined #openstack-keystone | 18:15 | |
| *** jorge_munoz has joined #openstack-keystone | 18:31 | |
| rodrigods | quick question: when we request to keystone return in a XML format, is there any place where the json is parsed? Or it's used some kind of lib that does the job? | 18:33 |
| rodrigods | just found middleware.XmlBodyMiddleware =) | 18:45 |
| ayoung | raildo, what about if, instead of "root":"openstack" we called it "installation" and, while it could have any string as the name, it got a UUID? | 18:48 |
| richm | hello - I'm working on adding unit tests for deleteTree for https://review.openstack.org/#/c/74897 | 18:48 |
| ayoung | richm, thanks | 18:48 |
| ayoung | rodrigods, that is such a hack | 18:48 |
| ayoung | I had a "contentt type:" middleware which is really what we need, to replace JSON and XML middlewares | 18:49 |
| richm | I thought I would create a subclass of FakeLdap that would override delete_s and delete_ext_s - this would check for children of the given dn and throw ldap.NOT_ALLOWED_ON_NONLEAF | 18:50 |
| ayoung | rodrigods, https://review.openstack.org/#/c/29105/9/keystone/contrib/html/middleware.py | 18:50 |
| richm | however, I'm not sure where to add the tests to use the new class | 18:50 |
| ayoung | richm, ldap_identity tests, I suspect, is the right place | 18:51 |
| ayoung | richm, you mean that there is not general LDAP unit tests? | 18:51 |
| richm | I thought about subclassing LDAPIdentity in test_backend_ldap | 18:51 |
| ayoung | hmmm | 18:51 |
| ayoung | richm, would you want those tests run against a live server too? | 18:52 |
| richm | but if I do that, would running the test suite execute every test method in the parent class, then again in the subclass? | 18:52 |
| richm | ayoung: right, that's another concern | 18:52 |
| richm | I would prefer to just write a very specific unit test that would exercise the various code paths in the deleteTree method | 18:52 |
| ayoung | richm, so the issue is that these tests should use a different subclass of FakeLDAP. But that logic would not be the same for the live test | 18:52 |
| richm | right | 18:52 |
| richm | the live test already fails | 18:53 |
| richm | because e.g. openldap does not support deleteTree | 18:53 |
| ayoung | I'd to it inside of ldap_identity, and have a method that gets called from the test to swap the FakeLDAp | 18:53 |
| ayoung | then, onlive tests, that function is a no-op | 18:53 |
| raildo | ayoung: no, it's just a string | 18:53 |
| ayoung | raildo, Federation. K2K | 18:53 |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Add oslo.utils requirement https://review.openstack.org/112164 | 18:53 |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Use oslo.utils https://review.openstack.org/112165 | 18:53 |
| richm | ayoung: ok - I thought that might be sort of ugly (== -1 review) | 18:53 |
| ayoung | richm, necessary ugliness | 18:53 |
| richm | my favorite kind | 18:54 |
| openstackgerrit | Brad Topol proposed a change to openstack/keystone: Add audit support to keystone federation https://review.openstack.org/114337 | 18:54 |
| ayoung | richm, you could make that call on the live tests check to see what ldap is being used, and skip if openldap, or better yet | 18:54 |
| ayoung | skip if the control is not supported on the server | 18:54 |
| ayoung | make the call something like delete_specific_setup | 18:55 |
| richm | ok - I'll also have to add support to FakeLdap to query the rootDSE supportedControls | 18:55 |
| ayoung | richm, you sure about that? | 18:56 |
| richm | either that, or the caller will have to do something like this: | 18:56 |
| ayoung | richm, actually, that is good | 18:57 |
| raildo | ayoung: sorry but I did not understand the relationship with root project: openstack in hierarchical projects --- federation and K2K | 18:57 |
| ayoung | raildo, sorry, too many convos at once. I get incoherent | 18:57 |
| richm | if isinstance(obj, FakeLdap): use subtree delete | 18:57 |
| ayoung | more incoherent than usual | 18:57 |
| richm | elif isinstance(obj, FakeLdapNoSubtreeDelete): do not use subtree delete | 18:57 |
| ayoung | richm, OK, I think that is the right approach. And we can set FakeLDAP to both support and not support. | 18:57 |
| raildo | ayoung: hahaha no problem | 18:57 |
| richm | else obj.search_s("", ...) | 18:58 |
| ayoung | If not supported, the test will run the same for Fake and Live... | 18:58 |
| ayoung | same with supported | 18:58 |
| ayoung | richm, so on live, you have two tests, one of which would always be skipped based on whether or not the server supported the control | 18:58 |
| ayoung | raildo, ok...BACK TO YOU | 18:59 |
| ayoung | raildo, if I want to see the whole Heirarchy, I start with root. If every installment has "openstack" as root, there is no way to compare two different installments | 18:59 |
| ayoung | ideally root would be the name of the organization hosting the cloud | 18:59 |
| ayoung | so "rackspace" , or "HP" | 19:00 |
| ayoung | raildo, and...if an organization wants to do it right, they could do this | 19:00 |
| ayoung | say rackspace wants to do a private cloud and a public cloud in two unlinked datacenters | 19:00 |
| raildo | thats make sense | 19:01 |
| ayoung | they make root for one "rackspace public" and the other "rackespace private" then, later, when they decide to put them in the same, the yroot it with "rackspace joint" | 19:01 |
| ayoung | and each project bumps one level deeper in the hierarachy, but everything else stays the same | 19:01 |
| ayoung | and, to make sure that two companies don't sit on the same name, like "test lab" | 19:02 |
| ayoung | you actually distinguish between them with a uuid, like we do for everything else | 19:02 |
| ayoung | raildo, you like that?> | 19:02 |
| raildo | ayoung: I liked a lot of your vision. | 19:03 |
| ayoung | raildo, its cuz I had LAZIK | 19:03 |
| raildo | ayoung: that is why you are part of the core keystone and I do not hahaha | 19:03 |
| ayoung | LASIK? | 19:03 |
| raildo | Lasik -> vision -> keystone core | 19:05 |
| *** henrynash has quit IRC | 19:08 | |
| * ayoung mike drop | 19:16 | |
| * ayoung dropped mike on bare foot. Is likely now to look big toenail | 19:17 | |
| ayoung | look->lose | 19:17 |
| afaranha | Hello, does someone knows how can I execute a SQL migrate script? Is it automatically executed when I restart Keystone service? | 19:28 |
| morganfainberg | bknudson, ugh, we backported things to havana in a wierd way then | 19:29 |
| bknudson | afaranha: keystone-manage db_sync | 19:29 |
| morganfainberg | bknudson, :( | 19:29 |
| bknudson | morganfainberg: y, I think we need to move havana back a couple of changes | 19:29 |
| bknudson | move the havana marker back to 34 | 19:30 |
| morganfainberg | bknudson, lets get a bug filed i'll get that brewed up early next week or on sunday | 19:30 |
| bknudson | shouldn't be impossible or be incompatible | 19:30 |
| bknudson | morganfainberg: I filed a bug... | 19:30 |
| bknudson | https://bugs.launchpad.net/keystone/+bug/1357498 | 19:30 |
| uvirtbot | Launchpad bug 1357498 in keystone "Can't upgrade from 2013.2 or 2013.2.1 to Juno" [Undecided,New] | 19:30 |
| morganfainberg | bknudson, i *thnik* it'll just be moving 036_havana to 034_havana and re-adding those two migrations | 19:30 |
| morganfainberg | and making sure they are idempotent | 19:31 |
| morganfainberg | minimal work. | 19:31 |
| bknudson | morganfainberg: y, that's what I was thinking. | 19:31 |
| afaranha | bknudson: Thanks, I'll try that | 19:31 |
| morganfainberg | bknudson, cool. i'll see if i can get that rolled up this weekend and tag you on it | 19:31 |
| morganfainberg | unless someone else beats me to it :P | 19:31 |
| bknudson | morganfainberg: I might take a look at it since I've got people asking about ti | 19:32 |
| bknudson | it | 19:32 |
| morganfainberg | bknudson, let me know if you get it done, happy to review it. | 19:32 |
| dolphm | anyone know if (i think dstanek's) xml matcher redux landed in master? | 19:33 |
| morganfainberg | bknudson, in either case i expect it'll be ready for review on monday | 19:33 |
| morganfainberg | dolphm, hm. i *think* it did, but... let me check | 19:33 |
| morganfainberg | dolphm, this one? https://review.openstack.org/#/c/109177/ | 19:33 |
| dolphm | morganfainberg: yep! | 19:34 |
| morganfainberg | dolphm, not landed, but def on the way | 19:34 |
| dolphm | morganfainberg: i'd like to backport that to icehouse as well | 19:34 |
| morganfainberg | dolphm, ++ | 19:34 |
| ayoung | stevemar, https://review.openstack.org/#/c/113998/4/v3/src/markdown/identity-api-v3-os-federation-ext.md is for splitting the ID backend off the rest of keystone, right? | 19:35 |
| ayoung | Also for K2K, maybe, but with no role info in the token? | 19:35 |
| ayoung | er...Assertion? | 19:35 |
| morganfainberg | raildo, ok so responded to your comments. i added a -1, lets look at that security concern and add any clarification needed for henry's comments and notifications. but i really think the major issues have been addressed in the spec | 19:42 |
| morganfainberg | raildo, thanks for the quick response on it! | 19:42 |
| morganfainberg | raildo, the -1 is only really because of the security concern, if you have a good answer to that i'll reverse the scoring | 19:44 |
| morganfainberg | dolphm, before i dive into code, anything else to talk about for pycadf? | 19:44 |
| dolphm | morganfainberg: oh yeah! | 19:44 |
| * morganfainberg is hoping to get a patch for revocation events to use audit ids done in the next hr or so. (and corresponding identity-api change) | 19:45 | |
| dolphm | morganfainberg: first, stable backport: https://review.openstack.org/#/c/114642/ | 19:45 |
| raildo | morganfainberg: Thanks for the reply, I will respond as soon as possible | 19:45 |
| morganfainberg | raildo, ++ i'm ducking out in a couple hours, but i'll look at your responses tonight at the latest | 19:45 |
| raildo | great | 19:45 |
| morganfainberg | dolphm, clean cherry-pick ? | 19:45 |
| dolphm | morganfainberg: no | 19:45 |
| dolphm | morganfainberg: we switched from io to six.io | 19:46 |
| morganfainberg | thats too bad :P makes it easier. ok looking at the two reviews | 19:46 |
| dolphm | morganfainberg: rebased around that, and some other import change | 19:46 |
| * morganfainberg nods. | 19:46 | |
| dolphm | morganfainberg: so, i agree descriptors are a really cool pattern, but i think it's far from being the most easy to read, low maintenance solution for the problem that pycadf is solving | 19:47 |
| dolphm | morganfainberg: before i continued further in switching to json schema, i wanted to stop and ask if you saw any value in maintaining the descriptor approach instead | 19:48 |
| morganfainberg | dolphm, i'm 100% sure the descriptor approach is way cooler than jsonschema, but i agree it's hard to read | 19:48 |
| dolphm | morganfainberg: nevermind cooler, do you think it's better | 19:49 |
| dolphm | morganfainberg: there are improvements to be had without switching to jsonschema | 19:49 |
| morganfainberg | dolphm, i think from a strict maintainablility standpoint (and readability) jsonschema makes more sense | 19:49 |
| dolphm | that's what i care about more in open source | 19:50 |
| morganfainberg | dolphm, which is my biggest concern. performance differences should be negligible | 19:50 |
| morganfainberg | to get all the benefits of the descriptor pattern and none of the negatives we can add __setitem__ that does a .valid check on each set once initialized | 19:50 |
| morganfainberg | (or even make that optional) | 19:50 |
| dolphm | but you need that for *every* attribute, right? | 19:52 |
| morganfainberg | dolphm, __setitem__ is a dict magic method, so it would occur when you did something like cadf_obj['thing'] = value | 19:53 |
| dolphm | or you mean setattr | 19:53 |
| morganfainberg | if you did something like that | 19:53 |
| dolphm | oh ok | 19:53 |
| openstackgerrit | Steve Martinelli proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION https://review.openstack.org/113998 | 19:53 |
| morganfainberg | same thing can be done with __setattr__ but it gets a bit more wonky with lots of super calls to not break things in cases. | 19:53 |
| dolphm | well that was my other motivation to just switch to jsonschema - cadf events are just json, so i'd rather the datatype more closely reflect that | 19:53 |
| morganfainberg | dolphm, descriptors are better in only one real clear way, you have more control over individual properties and how they act (can validate them in all sorts of magic ways) since each attribute is it's own descriptor class | 19:55 |
| morganfainberg | dolphm, i don't think we're losing much (if anything) moving to pure jsonschema like you're doing. and we are gaining a lot in readability | 19:55 |
| dolphm | morganfainberg: and most of the validation is basically isinstance-basestring and maybe is-not-none | 19:55 |
| morganfainberg | dolphm, net win in my book | 19:55 |
| openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Enumerate Projects with Unscoped Tokens https://review.openstack.org/106838 | 19:55 |
| morganfainberg | dolphm, ++ | 19:55 |
| dolphm | alright, i'll keep it up then | 19:56 |
| morganfainberg | dolphm, and yes i am still volunteering to be core on pycadf if you need volunteers. otherwise i'm content to review the code and +1 as appropriate | 19:56 |
| morganfainberg | dolphm, unrelated - stable backport looks really clean. super simple conflict | 19:56 |
| morganfainberg | just 2x checking the tests | 19:57 |
| *** chmouel has quit IRC | 19:57 | |
| *** chmouel has joined #openstack-keystone | 19:58 | |
| openstackgerrit | Andreas Jaeger proposed a change to openstack/identity-api: Add SAML generation route to OS-FEDERATION https://review.openstack.org/113998 | 19:58 |
| *** hrybacki has joined #openstack-keystone | 20:02 | |
| morganfainberg | dolphm, you might need a __setattr__ to convert pycadf.ATTR = thing to the dict model, i'm not sure if people directly set attributes on a pycadf object or if they just do a .to_dict() then thing[key] = value | 20:04 |
| *** jsavak has quit IRC | 20:06 | |
| *** bknudson has quit IRC | 20:09 | |
| *** notmyname has quit IRC | 20:10 | |
| *** chmouel has quit IRC | 20:10 | |
| *** notmyname has joined #openstack-keystone | 20:11 | |
| morganfainberg | dolphm, ooh i think we need to cleanup our specs page... we still have some templates rendered in there >.> | 20:15 |
| morganfainberg | dolphm, http://specs.openstack.org/openstack/keystone-specs/ "Template": and "Client" | 20:15 |
| openstackgerrit | ayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ https://review.openstack.org/114646 | 20:15 |
| *** chmouel has joined #openstack-keystone | 20:15 | |
| morganfainberg | template might be fine. | 20:15 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystonemiddleware: Hash for PKIZ https://review.openstack.org/114646 | 20:16 |
| morganfainberg | ayoung, ^ fixed typo in commit | 20:16 |
| ayoung | thanks | 20:16 |
| morganfainberg | ooh thats kindof a nasty bugger. | 20:16 |
| dolphm | morganfainberg: there are set_ methods on a couple objects | 20:17 |
| morganfainberg | dolphm, ah | 20:17 |
| morganfainberg | dolphm, haven't gotten all the way through the review yet. | 20:17 |
| dolphm | morganfainberg: it's still WIP | 20:17 |
| ayoung | morganfainberg, dolphm should I submit that PKIZ hash fix to keystone client as well? | 20:17 |
| morganfainberg | dolphm, ack. | 20:17 |
| morganfainberg | ayoung, is it a security fix? | 20:17 |
| ayoung | no | 20:17 |
| morganfainberg | ayoung, then i'd say answer is no | 20:18 |
| morganfainberg | ayoung, not sure if we can test this. but we might want to add a test for this one. | 20:19 |
| dolphm | ayoung: it's just a performance fix? | 20:19 |
| morganfainberg | dolphm, it's a we'd have a cache miss everytime on pkiz tokens (so yes) | 20:19 |
| ayoung | just performance | 20:19 |
| dolphm | ayoung: the bug report is for something different then? "that should make token revocation for PKIZ tokens broken" | 20:20 |
| dolphm | ayoung: that's why i marked it critical | 20:20 |
| ayoung | ah...lets see...if the hash is not done, then it will fall back to... | 20:20 |
| ayoung | oh, the revocation list.... | 20:20 |
| ayoung | hmmm...not sure how to test that. But yeah, if a token was cached, the revocation check would not match it | 20:24 |
| morganfainberg | ayoung, i think brant has a test for that when he redid some of the cache stuff | 20:25 |
| morganfainberg | ayoung, i think just need to funnel a pkiz token through | 20:25 |
| *** nkinder has quit IRC | 20:26 | |
| ayoung | morganfainberg, there is a test test_cached_revoked_pki(sel | 20:26 |
| ayoung | I can dupe for pkiz | 20:26 |
| morganfainberg | ayoung, perfect, should do that if you don't mind | 20:27 |
| *** ajayaa has joined #openstack-keystone | 20:29 | |
| ajayaa | ayoung, hi! | 20:29 |
| openstackgerrit | ayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ https://review.openstack.org/114646 | 20:30 |
| ayoung | morganfainberg, I'm going to submit that toe KC as well | 20:30 |
| dolphm | ayoung: add keystoneclient to the bug first | 20:31 |
| ayoung | willdo | 20:31 |
| dolphm | we should probably add OSSA too | 20:32 |
| openstackgerrit | ayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ https://review.openstack.org/114646 | 20:32 |
| ayoung | dolphm, should I remove "affects Keystone?" | 20:33 |
| morganfainberg | ayoung, ++ yes security (please mark it as a securityimpact) | 20:33 |
| morganfainberg | or.. do we mark it securityimpact? | 20:33 |
| morganfainberg | in either case yes, security | 20:34 |
| dolphm | morganfainberg: the patch should be SecurityImpact, yes | 20:34 |
| dolphm | ayoung: if it doesn't affect keystone (i wasn't sure), remove it there | 20:34 |
| ayoung | dolphm, , that is Security-Impact: in the commit message, right? | 20:36 |
| morganfainberg | ayoung, SecurityImpact | 20:36 |
| morganfainberg | iirc | 20:36 |
| ayoung | looking | 20:36 |
| openstackgerrit | ayoung proposed a change to openstack/keystonemiddleware: Hash for PKIZ https://review.openstack.org/114646 | 20:37 |
| *** david-ly_ has joined #openstack-keystone | 20:43 | |
| openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: Hash for PKIZ https://review.openstack.org/114654 | 20:43 |
| ayoung | can you guys expedite those? | 20:44 |
| *** david-lyle has quit IRC | 20:45 | |
| dolphm | ayoung: this looks like a valid fix, but i don't see how it addresses the concern in the bug about revocation | 20:50 |
| *** henrynash has joined #openstack-keystone | 20:50 | |
| *** rwsu has quit IRC | 20:51 | |
| morganfainberg | dolphm, i *think* the .get() (which does the hash check) is responsible for hashing the ids which then get passed to the verifynot revoked code | 20:52 |
| morganfainberg | dolphm, /me is still looking | 20:52 |
| *** hrybacki has quit IRC | 20:54 | |
| dolphm | morganfainberg: if i'm reading it correctly, a cache miss results in it falling into verify_pkiz_token() with the original unhashed token and checking the revocation list anyway | 20:55 |
| dolphm | and holy crap the revocation check has a for loop in it that runs on every check | 20:56 |
| morganfainberg | dolphm, the .get does the hashing and returns out https://review.openstack.org/#/c/114646/5/keystonemiddleware/auth_token.py at line 1411 | 20:56 |
| *** bknudson has joined #openstack-keystone | 20:56 | |
| raildo | morganfainberg: I answered your comments there, if you can take a look :D thanks | 20:56 |
| *** bknudson1 has joined #openstack-keystone | 20:57 | |
| dolphm | morganfainberg: correct, but the previous behavior was that PKIZ tokens would skip that block | 20:57 |
| morganfainberg | right | 20:57 |
| morganfainberg | so, this fixes the bug, if i'm reading it right | 20:57 |
| dolphm | morganfainberg: so you get a cache miss, and the return value of that method is (full_plaintext_pkiz_token, None), right? | 20:57 |
| dolphm | err | 20:58 |
| morganfainberg | no you still get a list of [cms.hash for algo in hashing_algorithms] | 20:58 |
| morganfainberg | you get ([hash, ...], None) back | 20:58 |
| dolphm | morganfainberg: no, previously it never went into that if block | 20:58 |
| morganfainberg | the None is if it was a cache hit | 20:58 |
| dolphm | ([full_plaintext_pkiz_token], None) | 20:58 |
| morganfainberg | right previously, the TRL never contains the complete full_pkiz_token_id | 20:59 |
| dolphm | user_token == full_plaintext_pkiz_token == token_id | 20:59 |
| dolphm | morganfainberg: and look at where _token_cache.get() is called | 20:59 |
| morganfainberg | dolphm, in _validate_user_token | 21:00 |
| morganfainberg | oooh | 21:00 |
| *** bknudson has quit IRC | 21:01 | |
| morganfainberg | PKIZ tokens were validated correctly, | 21:01 |
| dolphm | god this is confusing | 21:01 |
| morganfainberg | PKI tokens were falling back to UUID-form | 21:01 |
| morganfainberg | this fixes the cache hit-scenario but makes it so we live-validate PKI(Z) tokens 100% of the time | 21:01 |
| dolphm | wait really | 21:01 |
| morganfainberg | arguably, that is *not* a security hole, just a crappy performance | 21:01 |
| morganfainberg | yep, because is_pkiz and is_pki will fail on the hashed token | 21:02 |
| morganfainberg | so, .get is called and returns ([hash], None) | 21:02 |
| * morganfainberg walks through this | 21:02 | |
| morganfainberg | we set token_id to [hash][0] | 21:03 |
| morganfainberg | ahhh no we're ok | 21:03 |
| morganfainberg | we do is_pki / is_pkiz on user_token not token_id | 21:03 |
| *** elmiko is now known as _elmiko | 21:03 | |
| dolphm | right, that's part of the super confusingness | 21:04 |
| *** hrybacki has joined #openstack-keystone | 21:04 | |
| morganfainberg | then we pass user_token and the token_id list to _verify_signed_token | 21:04 |
| morganfainberg | (in a cache_miss) | 21:04 |
| dolphm | but we're basically calling self._verify_pkiz_token(user_token, [user_token]) -- right? | 21:04 |
| morganfainberg | yeah | 21:04 |
| *** david-ly_ is now known as david-lyle | 21:05 | |
| morganfainberg | which the fix ayoung provided solves. it makes pkiz tokens get hashed as expected | 21:05 |
| morganfainberg | so it becomes self._verify_pkiz_token(user_token, [hash]) | 21:05 |
| morganfainberg | which is how is_signed_token_revoked expects it to work | 21:05 |
| dolphm | and then _is_signed_token_revoked([hash]) with the fix | 21:05 |
| morganfainberg | yep | 21:05 |
| dolphm | okay | 21:06 |
| dolphm | holy crap | 21:06 |
| ayoung | dolphm, yes. Holy Crap. I never wanted to do revocations for PKI tokens in the first place. And then the complexity of multiple hash algorithms made it worse. | 21:07 |
| *** radez is now known as radez_g0n3 | 21:07 | |
| morganfainberg | the really confusing part is that the cache.get does the hashing as a side effect | 21:07 |
| dolphm | ayoung: someone -1'd btw | 21:08 |
| ayoung | dolphm, legit? | 21:08 |
| morganfainberg | we should yank that bit out into a clearer function. i think that would be the easiest way to make it a bit more clear | 21:08 |
| dolphm | ayoung: i don't know, my brain is fried | 21:08 |
| ayoung | heh. | 21:08 |
| dolphm | ayoung: my inline comment is a half reply to their -1 | 21:08 |
| dolphm | ayoung: you tell me | 21:08 |
| *** spandhe has joined #openstack-keystone | 21:09 | |
| ayoung | I think he's just wrong | 21:09 |
| ayoung | it explicitly is in _TokenCache.get | 21:09 |
| morganfainberg | let me re-read the bug | 21:09 |
| ayoung | and it is what identifies that a PKIZ token should be hashed | 21:10 |
| ayoung | really, we should go back to the minimum length approach: | 21:10 |
| ayoung | any tokens longer than a sha256 should be hashed. | 21:10 |
| ayoung | that would avoid the issues with different token formats | 21:10 |
| ayoung | but I would say that is a larger change than this | 21:10 |
| morganfainberg | ayoung, actually any token longer than sha256 will fail in keystone | 21:11 |
| morganfainberg | ayoung, but that is def a different story | 21:11 |
| morganfainberg | dolphm, i think the -1 is the same confusion we just had | 21:12 |
| dolphm | morganfainberg: but i'm happy to entertain a request for more test coverage lol | 21:12 |
| morganfainberg | except.. can self._TokenCache be something from swift? | 21:12 |
| morganfainberg | as in *not* our code that does the tokencache logic | 21:13 |
| ayoung | I still suspect this was just a performance issue. I don;t think a PKIZ token would ever have been hashed, thus never been cached. Which means if it was submitted a second time, it would have gone through the whole unpack, check signature, and check revocation list that way | 21:13 |
| morganfainberg | ayoung, you'd never match in the TRL is the issue | 21:14 |
| ayoung | morganfainberg, actually I would. It was checked else whre | 21:14 |
| ayoung | I'll link | 21:14 |
| morganfainberg | ayoung, for a PKIZ token, because you'd be looking for the user_token string in the TRL (we don't put it in there) | 21:14 |
| morganfainberg | oh we're double duty on the TRL check? | 21:14 |
| dolphm | ayoung: what's the pkiz equivalent of cms.cms_hash_token | 21:14 |
| ayoung | morganfainberg, that was only for the cache case | 21:14 |
| morganfainberg | dolphm, the same thing. | 21:15 |
| ayoung | dolphm, they hash the same way | 21:15 |
| morganfainberg | dolphm, cms.cms_hash_token works for asn1 and pkiz | 21:15 |
| ayoung | cms.cms_hash_token hashes anything | 21:15 |
| morganfainberg | ah ok yeah token_Cache is always our code | 21:15 |
| morganfainberg | phew | 21:15 |
| dolphm | ayoung: your patch is *way* behind master btw | 21:16 |
| ayoung | dolphm, ugh | 21:16 |
| openstackgerrit | Dolph Mathews proposed a change to openstack/keystonemiddleware: Add test for revoked PKIZ tokens in TRL https://review.openstack.org/114663 | 21:16 |
| dolphm | ayoung: fixed | 21:16 |
| ayoung | morganfainberg, OK, even if it was cached, it would not have been identified as cached | 21:16 |
| ayoung | morganfainberg, so the check happens... | 21:16 |
| dolphm | ayoung: this test fails when run on top of your patch - why? https://review.openstack.org/#/c/114663/1/keystonemiddleware/tests/test_auth_token_middleware.py | 21:17 |
| notmyname | FYI swift team (portante and acoles and peluse) just clicked approve on v3 auth support for swiftclient https://review.openstack.org/#/c/91788/ | 21:17 |
| morganfainberg | dolphm, the id might not be in the TRL it has | 21:17 |
| ayoung | morganfainberg, revocation list was checked here https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L907 | 21:18 |
| ayoung | whew | 21:18 |
| dolphm | notmyname: yay! | 21:18 |
| ayoung | dolphm, looking | 21:18 |
| dolphm | morganfainberg: it fabricates a TRL | 21:18 |
| morganfainberg | ayoung, yes, but the token_ids it's using is [full_user_token_id] | 21:18 |
| morganfainberg | ayoung, which would not be in the TRL | 21:19 |
| morganfainberg | ayoung, because the hashing would have failed. | 21:19 |
| ayoung | morganfainberg, um..no | 21:19 |
| dolphm | morganfainberg: are you talking about my test there^ | 21:19 |
| morganfainberg | dolphm, possibly | 21:19 |
| dolphm | morganfainberg: lol | 21:20 |
| ayoung | morganfainberg, the hashing happens on a different code path | 21:20 |
| morganfainberg | dolphm, i'm talking about adam's fix and PKIZ without it was not being checked against the TRL | 21:20 |
| dolphm | it fabricates the TRL but it also calls auth_token with X-auth-token = hashed_token | 21:20 |
| morganfainberg | ayoung, the hashing happens in token_cache.get() as a side-effect | 21:20 |
| morganfainberg | ayoung, it *used* to happen elsewhere | 21:20 |
| ayoung | hmmm | 21:20 |
| ayoung | that is wrong | 21:20 |
| morganfainberg | ayoung, https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L660 | 21:21 |
| *** nkinder has joined #openstack-keystone | 21:21 | |
| morganfainberg | token_ids is a result of token_cache.get() | 21:21 |
| ayoung | AHHH | 21:21 |
| ayoung | yep, I see it now | 21:21 |
| * ayoung gonna git blame that one | 21:21 | |
| morganfainberg | it's probably 2-3 levels of refactoring back | 21:21 |
| morganfainberg | just as a headsup | 21:22 |
| ayoung | I have to go pickup my son | 21:22 |
| morganfainberg | dolphm, ah | 21:22 |
| morganfainberg | dolphm, didn't see if fabricating the TRL | 21:22 |
| morganfainberg | dolphm, ooooh i see line 711 | 21:22 |
| morganfainberg | how does this test work | 21:28 |
| dolphm | morganfainberg: ? | 21:28 |
| morganfainberg | this looks like it should fail on that same check in the PKI version | 21:29 |
| morganfainberg | the wray it's written | 21:29 |
| dolphm | lol | 21:29 |
| morganfainberg | looking at your test | 21:29 |
| dolphm | the calling once with a hashed version to populate the cache, and then calling with the full version is... odd | 21:30 |
| morganfainberg | its to check that hashing works | 21:30 |
| morganfainberg | it's not straight forward though :( | 21:30 |
| morganfainberg | i don't see how it's valid since you already put the token in the TRL a few lines before | 21:30 |
| dolphm | yeah, they should both be 401 | 21:31 |
| dolphm | it's like it's asserting a vulnerability | 21:31 |
| morganfainberg | yep | 21:31 |
| morganfainberg | ok maybe the PKI one is doing something dumb... | 21:32 |
| dolphm | i changed one line | 21:32 |
| morganfainberg | i dunno. this is making my head hurt | 21:34 |
| morganfainberg | oh | 21:34 |
| morganfainberg | ... OH. | 21:34 |
| morganfainberg | short-hash doesn't check TRL | 21:35 |
| *** amcrn has quit IRC | 21:35 | |
| morganfainberg | short hash has to ask keystone *anyway* | 21:35 |
| morganfainberg | so keystone would bounce the token if it was invalid not the TRL when checking by the hashed form | 21:36 |
| openstackgerrit | Dolph Mathews proposed a change to openstack/keystonemiddleware: added FIXME to PKI cache+TRL test https://review.openstack.org/114668 | 21:36 |
| dolphm | i need to run, but ^ | 21:37 |
| dolphm | oh that's terrible | 21:37 |
| dolphm | amend my commit with an explanation lol | 21:37 |
| dolphm | i need to run; happy weekend! | 21:37 |
| morganfainberg | dolphm, sure. i need to bail soon as well | 21:38 |
| morganfainberg | been looking at code since 645am my time | 21:38 |
| ayoung | which check failed? | 21:41 |
| morganfainberg | ayoung, dolph's new one https://review.openstack.org/#/c/114663/1/keystonemiddleware/tests/test_auth_token_middleware.py | 21:41 |
| ayoung | morganfainberg, the last check? | 21:41 |
| ayoung | # Should find the token in the cache and revocation list. | 21:41 |
| ayoung | self.assertEqual(401, self.response_status) | 21:41 |
| morganfainberg | no the one on 719 | 21:42 |
| morganfainberg | it gets a 401 on that one | 21:42 |
| ayoung | oh...he revoked it already | 21:42 |
| ayoung | that test is wrong. I'd do it like this: | 21:42 |
| morganfainberg | look at the test above | 21:42 |
| morganfainberg | the PKI version works | 21:42 |
| ayoung | test a pki token is valid. That puts it in the cached. Then check by passing just the hash to auth_token | 21:43 |
| ayoung | nah, wait | 21:43 |
| ayoung | that is a different code path | 21:43 |
| ayoung | hmmm | 21:43 |
| morganfainberg | the hashed form shouldn't check TRL | 21:43 |
| morganfainberg | keystone should bounce it (hence it's valid in short form) | 21:43 |
| morganfainberg | and should be 200 | 21:43 |
| ayoung | yeah, just revoke between the two checks | 21:43 |
| morganfainberg | that doesn't explain why the PKI one works and PKIZ one doesn't | 21:44 |
| ayoung | the hashed form checks the TRL if there is a certain flag enabled | 21:44 |
| morganfainberg | there is a 1 line difference tbween the tests | 21:44 |
| morganfainberg | if one fails so should the other | 21:44 |
| morganfainberg | or we have some kind of divergent code path being really weird | 21:44 |
| morganfainberg | anyway i am brain fried. need to stop looking at this for a bit | 21:45 |
| ayoung | morganfainberg, I'm disappearing for the weekend. I'll bring my machine with me, but...well I'll be in the middle of Lake Champlain. | 21:47 |
| ayoung | the 200 is wrong, though. That should be revoked. Revocation is checked everytime | 21:48 |
| ayoung | morganfainberg, maybe something is stateful with if self.check_revocations_for_cached: | 21:49 |
| morganfainberg | yeah i'll dig around it a bit later | 21:52 |
| morganfainberg | i need to bail as well | 21:52 |
| morganfainberg | have a good weekend dude | 21:53 |
| *** henrynash has quit IRC | 22:00 | |
| bknudson1 | ayoung: watch out for Champ | 22:01 |
| bknudson1 | the lake champlain monster | 22:01 |
| *** ajayaa has quit IRC | 22:03 | |
| *** jorge_munoz has quit IRC | 22:04 | |
| *** nkinder has quit IRC | 22:14 | |
| *** nkinder has joined #openstack-keystone | 22:14 | |
| *** topol has quit IRC | 22:23 | |
| openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Add notifications for role assignment created and deleted events https://review.openstack.org/112204 | 22:30 |
| *** shakamunyi has quit IRC | 22:30 | |
| openstackgerrit | Bob Thyne proposed a change to openstack/keystone: Implementation of Endpoint Grouping https://review.openstack.org/111949 | 22:37 |
| *** zzzeek has quit IRC | 22:41 | |
| *** stevemar has quit IRC | 22:49 | |
| spandhe | Hi folks.. I see some conversion going on regarding token caching. I observed some weird behavior in my setup and hence opened a bug: https://bugs.launchpad.net/python-keystoneclient/+bug/1357567 | 22:50 |
| uvirtbot | Launchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" [Undecided,New] | 22:50 |
| *** amcrn has joined #openstack-keystone | 22:51 | |
| spandhe | can someone please take a look at it and check for validity of it - in case I am doing something wrong? | 22:51 |
| nkinder | I'm seeing a really weird gate failure with a stable.icehouse backport - http://logs.openstack.org/44/113744/2/check/check-grenade-dsvm/981550c/logs/old/screen-key.txt.gz | 22:57 |
| nkinder | keystone fails to start because it can't do an 'import utils' | 22:58 |
| nkinder | is this something related to a newer keystoneclient getting pulled in? | 22:58 |
| nkinder | every test fails due to this failed import that is done by keystoneclient - http://logs.openstack.org/44/113744/2/check/gate-keystone-python26/57ac3b9/console.html | 23:04 |
| *** gordc has quit IRC | 23:04 | |
| *** ayoung has quit IRC | 23:06 | |
| *** rwsu has joined #openstack-keystone | 23:06 | |
| *** morganfainberg is now known as morganfainberg_Z | 23:07 | |
| bknudson1 | nkinder: .tox/py27/bin/pip install oslo.utils | 23:11 |
| bknudson1 | nkinder: maybe we should back out the changes to keystoneclient to use oslo.utils. | 23:12 |
| *** david-lyle has quit IRC | 23:13 | |
| bknudson1 | stable/icehouse & havana will need updates to requirements.txt to add olso.util | 23:13 |
| *** zzzeek has joined #openstack-keystone | 23:16 | |
| *** zzzeek has quit IRC | 23:21 | |
| *** rwsu has quit IRC | 23:35 | |
| *** shakamunyi has joined #openstack-keystone | 23:51 | |
| *** zzzeek has joined #openstack-keystone | 23:56 | |
| openstackgerrit | Monty Taylor proposed a change to openstack/python-keystoneclient: Remove lxml as a forced depend https://review.openstack.org/114701 | 23:56 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!