| nkinder | gyee, jamielennox: ^^^ that adds the missing unit tests | 00:00 |
|---|---|---|
| nkinder | one thing I went back and forth on was if I should modify the create/update v2 user tests to just check if the passwords are logged, or if I should add entirely new tests. | 00:01 |
| nkinder | I went with the former, but I can change it if desired | 00:01 |
| nkinder | It just seemed like a waste to duplicate all of that logic when we only need to add some additional assertions about the logging to the existing tests | 00:02 |
| morganfainberg | jamielennox, any idea why we issue a new token on a user's password change? | 00:02 |
| jamielennox | nkinder: ah, thanks - i hadn't see that yet | 00:02 |
| morganfainberg | jamielennox, in OS-KSCRUD contrib? | 00:02 |
| morganfainberg | jamielennox, more to the point, we do an awful, broken, very bad new token generation? | 00:02 |
| *** amerine has quit IRC | 00:02 | |
| jamielennox | yea, i'd have mixed it in with the original tests - it's not purist but i don't see the point in replicating them to test one additional thing | 00:02 |
| *** amerine has joined #openstack-keystone | 00:03 | |
| nkinder | jamielennox: one other thing I changed was that you were logging a user create request if it didn't contain a password for v2, but you never logged a create for v3 | 00:03 |
| nkinder | jamielennox: I tweaked v3 to be consistent. Was there some reason you didn't do that in v3, or was it just an oversight? | 00:03 |
| jamielennox | nkinder: just oversigh i think, i just wanted some log output so that when you were using CLI or something it didn't look like it had just skipped an entire request | 00:04 |
| jamielennox | morganfainberg: i don't know about awful and broken things (i obviously had nothing to do with those :) i think the logic was that a change in password was possibly a response to a security issue and we should revoke the old tokens | 00:05 |
| nkinder | morganfainberg: yeah, we revoke tokens with the password changes, so someone likely made it fetch a new token for convenience ? | 00:06 |
| morganfainberg | jamielennox, yeah it's awful we do a .get_token, change the id, resave the *same token with a different embeded, now uuid token even if it was PKI to begin with*, then say "here's your new token" | 00:06 |
| morganfainberg | nkinder, yean ~2yrs ago | 00:06 |
| morganfainberg | nkinder, jamielennox, ok well then, time to *fix* this to actually issue a token. | 00:07 |
| jamielennox | should we issue a new token at all? | 00:08 |
| jamielennox | let the user/client fetch a new one next time | 00:08 |
| gyee | nkinder, patch looks good to me | 00:09 |
| jamielennox | most likely a change password will be done from either the CLI where a new token isn't really useful or horizon which can manage it | 00:09 |
| nkinder | gyee: great, thanks for the review! | 00:10 |
| nkinder | morganfainberg: a review from you would be appreciated as well when you get time | 00:11 |
| nkinder | morganfainberg: then we can finally close this password logging thing | 00:11 |
| jamielennox | bknudson would be good as well as he has had some opinions here, but he doesn't seem to be around | 00:11 |
| gyee | jamielennox, do you understand what's going on with this? https://review.openstack.org/#/c/109141/ | 00:13 |
| gyee | I still don't see the problem | 00:13 |
| jamielennox | gyee: so i think what's happening is that the ENV variables aren't getting picked up because of the way defaults work | 00:14 |
| jamielennox | so you define the backwards compatability options and if they are not available it puts the None on the namespace | 00:14 |
| *** dims has joined #openstack-keystone | 00:14 | |
| gyee | but how's flipping the order make any difference, that's where I got lost | 00:14 |
| jamielennox | then when you define the real options and you don't provide those it looks to whether it shouuld provide a default value, and the default is where the ENV is read | 00:15 |
| jamielennox | so because there is already a value on the namespace it decides it doesn't need to add a default | 00:15 |
| gyee | but command line trumps env var right? | 00:15 |
| jamielennox | this is more interpretation and thinking it through than i have actually experimented with it | 00:16 |
| jamielennox | right | 00:16 |
| jamielennox | and if you put an argument on the cli it would still work | 00:16 |
| jamielennox | https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L595 | 00:17 |
| jamielennox | it's just i think when it says i didn't get a cli argument should i add a default of the ENV var it says no because there is already a value on the namespace | 00:18 |
| jamielennox | it's a bit weird and dumb | 00:18 |
| gyee | oh, I see what's going on now | 00:18 |
| gyee | it won't register twice | 00:18 |
| jamielennox | i guess it's because you are allowed to make your own namespace objects so they could have default values that you don't want to override | 00:18 |
| gyee | first registration have no default | 00:19 |
| jamielennox | gyee: yep no default = default=None | 00:19 |
| gyee | I completely agree, dumb! | 00:19 |
| jamielennox | yea, and i would have just tested it with the CLI args | 00:20 |
| *** gabriel-bezerra has quit IRC | 00:20 | |
| jamielennox | because the rest is annoying | 00:20 |
| gyee | -1 for no tests :) | 00:20 |
| openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Trust unit tests should target additional threat scenarios https://review.openstack.org/109120 | 00:20 |
| jamielennox | harsh | 00:20 |
| jamielennox | but yea | 00:20 |
| *** gabriel-bezerra has joined #openstack-keystone | 00:20 | |
| *** gabriel-bezerra has quit IRC | 00:21 | |
| *** richm has quit IRC | 00:25 | |
| *** gabriel-bezerra has joined #openstack-keystone | 00:25 | |
| *** gyee has quit IRC | 00:33 | |
| morganfainberg | jamielennox, i don't think i can fix this. we're emitting INTERNAL data to the wire | 00:40 |
| morganfainberg | jamielennox, the entire token_ref as stored in the backend | 00:41 |
| jamielennox | morganfainberg: there needs to be an internet acronym for laugh/cry | 00:41 |
| jamielennox | got a link to where you're looking? | 00:41 |
| morganfainberg | jamielennox, right? | 00:41 |
| morganfainberg | jamielennox, can i just rm -rf v2.0 now | 00:42 |
| morganfainberg | jamielennox, yeah, sec | 00:42 |
| morganfainberg | jamielennox, https://github.com/openstack/keystone/blob/master/keystone/contrib/user_crud/core.py#L80-L85 | 00:42 |
| morganfainberg | first off *that isn't a token we're spitting onto the wire* | 00:42 |
| morganfainberg | but we kinda pretend it is. | 00:43 |
| *** shakamunyi has joined #openstack-keystone | 00:43 | |
| jamielennox | ahahahaha | 00:44 |
| jamielennox | nuke it from orbit | 00:44 |
| morganfainberg | jamielennox, so when i put a *real* token on the wire... the tests go kersplode | 00:44 |
| jamielennox | i can only assume that's before we had jenkins? | 00:45 |
| morganfainberg | this.. i.. ... w.t.f. | 00:45 |
| morganfainberg | oh no, tests pass, just... nothing *obviously* actually consumes that dat | 00:45 |
| morganfainberg | a | 00:45 |
| morganfainberg | well, nothing we wrote | 00:45 |
| morganfainberg | except a couple unit tests | 00:46 |
| jamielennox | i'd strip that, have it return a 204 and see whether we have anyone consuming it | 00:46 |
| morganfainberg | LOL. *sigh* | 00:46 |
| jamielennox | it looks like client will just pass it through | 00:46 |
| jamielennox | oh - no it expects something with an 'access' key | 00:47 |
| morganfainberg | i love when we have tests that *ensure* we are emitting broken stuff | 00:47 |
| morganfainberg | # TODO(morganfainberg): nuke this from orbit...it should die. | 00:47 |
| jamielennox | https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/users.py#L78 | 00:49 |
| jamielennox | it looks like the method will update strip off the 'access' part of the response - and then make a User object from the rest of it | 00:49 |
| jamielennox | what sort of POS doesn't validate enough to realize that this is not even close to the real object type you expect | 00:50 |
| morganfainberg | jamielennox, yeah well i'm just going to emit a real token here | 00:52 |
| morganfainberg | jamielennox, let me just figure out why i'm somehow generating a bad token now (yes our issue_token code apparently just issues whatever the crap you give it, which can result in... duh duh duh, invalid tokens) | 00:53 |
| *** amerine has quit IRC | 01:07 | |
| *** amerine has joined #openstack-keystone | 01:07 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Make token_provider_api contain token persistence https://review.openstack.org/109041 | 01:11 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 01:11 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove assignment controller dependency on token_api https://review.openstack.org/109162 | 01:11 |
| *** amcrn has quit IRC | 01:11 | |
| *** marcoemorais has quit IRC | 01:12 | |
| *** diegows has quit IRC | 01:13 | |
| morganfainberg | marekd, stevemar, ayoung-aft, for federated-issued tokens is there a way to know what domain the IDP is associated with? | 01:43 |
| ayoung-aft | morganfainberg, I think so | 01:44 |
| *** ayoung-aft is now known as ayoung-fore | 01:44 | |
| morganfainberg | marekd, stevemar, ayoung-aft, because right now the logic for revocation events wont work with federated tokens | 01:44 |
| *** ayoung-fore is now known as ayoung-midship | 01:44 | |
| *** ayoung-midship is now known as ayoung | 01:44 | |
| morganfainberg | ayoung, since there is no domain in the user bit of the tokne | 01:44 |
| ayoung | morganfainberg, isn't there a user_id? | 01:44 |
| morganfainberg | ayoung, looking | 01:44 |
| ayoung | we use henrynash's user-id to domain lookup table | 01:45 |
| morganfainberg | ayoung, yeah, ok | 01:45 |
| morganfainberg | ayoung, that was my next step | 01:45 |
| ayoung | morganfainberg, BTW, I'm debugging inside Django-Openstack-Auth....in httpd | 01:45 |
| ayoung | not in a way I can upstream submit yet, but still. | 01:46 |
| morganfainberg | ayoung, interesting gaps in our code are found when i start funneling all tokens through token_provider_api.validate_token instead of just doing token_api.get_token() and assuming all is well | 01:46 |
| ayoung | yeah, I think I had a comment to that effect in the events code | 01:46 |
| *** mberlin has joined #openstack-keystone | 01:47 | |
| ayoung | morganfainberg, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/controller.py#n65 | 01:47 |
| morganfainberg | ayoung, yeah but the reason you called .get_token there was actually invalid iirc, | 01:48 |
| *** mberlin1 has quit IRC | 01:48 | |
| ayoung | it was due to tow different formats | 01:48 |
| ayoung | two | 01:48 |
| morganfainberg | but anyway | 01:48 |
| morganfainberg | want to see something fun... | 01:48 |
| ayoung | sure | 01:48 |
| morganfainberg | ayoung, how about emitting the raw token data from the persistence backend (no formatting) to the wire ... but pretending it looks like a token: https://review.openstack.org/#/c/109162/1/keystone/contrib/user_crud/core.py | 01:49 |
| morganfainberg | (look at the original, line 80-85) | 01:49 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystone-specs: Auth Specific Data https://review.openstack.org/107325 | 01:49 |
| ayoung | morganfainberg, I think Russell Wrote that | 01:54 |
| ayoung | Ah, Derek Higgens | 01:54 |
| morganfainberg | ayoung, derek higgens? | 01:54 |
| ayoung | Heh, I used to have trouble telling those two apart | 01:55 |
| ayoung | Back when I joined the project, and all of the RHers were pulled together, I met them at the same time. | 01:55 |
| ayoung | I thought I'd gotten over confusing them....one last time, I guess | 01:56 |
| openstackgerrit | Victor Morales proposed a change to openstack/keystone: Sqlite files excluded from the repo https://review.openstack.org/109165 | 01:56 |
| morganfainberg | ayoung, are IDPs specifically assigned to a domain? | 02:02 |
| ayoung | morganfainberg, I wanted it the other way around | 02:02 |
| morganfainberg | ayoung, i'm not seeing anything that guarantees that. | 02:02 |
| ayoung | one IdP could manage one or more domains | 02:02 |
| ayoung | I know. | 02:03 |
| morganfainberg | ayoung, it doesn't look like an IDP is explicitly mapped to *anything* | 02:03 |
| morganfainberg | ayoung, i might just be missing where this hooks in, but it looks like IDPs aren't specific to a domain. | 02:05 |
| ayoung | they are not. I said "I wanted" | 02:05 |
| ayoung | It is the right abstraction | 02:06 |
| morganfainberg | ah | 02:07 |
| morganfainberg | this means there is no way to get a domain for a federated user afaict, henry's thing wont work | 02:08 |
| morganfainberg | the user is tied to an idp not a domain | 02:08 |
| *** alex_xu has joined #openstack-keystone | 02:09 | |
| morganfainberg | bleh, we need to stop making special case token formats. | 02:10 |
| morganfainberg | ok i'm going to take a break from this, it's making me kinda annoyed | 02:10 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove assignment controller dependency on token_api https://review.openstack.org/109162 | 02:12 |
| *** dims has quit IRC | 02:14 | |
| *** ncoghlan has joined #openstack-keystone | 02:22 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Expose token revocation list via token_provider_api https://review.openstack.org/109170 | 02:37 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Expose token revocation list via token_provider_api https://review.openstack.org/109170 | 02:39 |
| *** dims has joined #openstack-keystone | 02:40 | |
| *** dims has quit IRC | 02:44 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove ec2 contrib dependency on token_api https://review.openstack.org/109173 | 02:50 |
| *** alex_xu has quit IRC | 02:55 | |
| *** Chicago has joined #openstack-keystone | 02:57 | |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixes an issue with the XMLEquals matcher https://review.openstack.org/109177 | 02:58 |
| morganfainberg | jamielennox, you're going to win on the location of the token model, simply because i need to avoid circular dependencies. | 03:02 |
| morganfainberg | jamielennox, :) | 03:02 |
| jamielennox | morganfainberg: win by default - i'll take it | 03:02 |
| *** alex_xu has joined #openstack-keystone | 03:03 | |
| jamielennox | morganfainberg: i heard you and topol did a presentation last week - is there a video? | 03:06 |
| morganfainberg | jamielennox, uhm.. somewhere :P | 03:07 |
| openstackgerrit | Jamie Lennox proposed a change to openstack/keystone-specs: Explicity request an unscoped token https://review.openstack.org/108071 | 03:21 |
| *** stevemar has joined #openstack-keystone | 03:22 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Make token_provider_api contain token persistence https://review.openstack.org/109041 | 03:29 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 03:29 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Expose token revocation list via token_provider_api https://review.openstack.org/109170 | 03:29 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove assignment controller dependency on token_api https://review.openstack.org/109162 | 03:32 |
| morganfainberg | jamielennox, https://review.openstack.org/#/c/109141/ passed check (this is the cli option thing) | 03:36 |
| jamielennox | morganfainberg: makes sense - nothing tests clis | 03:36 |
| morganfainberg | yep | 03:36 |
| jamielennox | even devstack is using OSC | 03:36 |
| morganfainberg | vishy says this fixes the issue, looks sane to me. | 03:37 |
| jamielennox | gyee was going to -1 for not being tested | 03:37 |
| jamielennox | i don't know if that's warranted | 03:37 |
| jamielennox | the tests for shell already suck | 03:37 |
| morganfainberg | jamielennox, i don't know how i'd test this one tbh | 03:37 |
| jamielennox | you can set env variables, you just have to be careful about cleanup i guess | 03:38 |
| jamielennox | morganfainberg: meh, just +A i think | 03:39 |
| *** dims has joined #openstack-keystone | 03:41 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove ec2 contrib dependency on token_api https://review.openstack.org/109173 | 03:42 |
| *** dims has quit IRC | 03:45 | |
| morganfainberg | i think i need to go lie down. my brain hurts from staring at token stuff :P | 03:46 |
| morganfainberg | only another ~7 or so reviews to post for converting things over to use token_provider instead of using token_api | 03:46 |
| morganfainberg | jamielennox, also https://review.openstack.org/#/c/104000/ looks safe to me | 03:50 |
| morganfainberg | jamielennox, strutils is a dependency and doens't need to be listed in openstack-common.conf (automatically sync'd in) | 03:50 |
| jamielennox | morganfainberg: +A | 03:52 |
| *** chandankumar has joined #openstack-keystone | 03:53 | |
| jamielennox | i've received so many gerrit emails that i don't see them any more, and my filters don't show me stuff that i've -1ed | 03:53 |
| jamielennox | definitely not a perfect system | 03:53 |
| morganfainberg | hehe | 03:54 |
| morganfainberg | not a worry just bugging you for the stupidly easy ones | 03:54 |
| jamielennox | i hate github pull requests, how do you push a new version of a request without loosing access to your history? | 03:57 |
| *** stevemar has quit IRC | 03:59 | |
| morganfainberg | jamielennox, you don't, you add a commit on top of the current one and you end up with a bunch of commits as part of the pull request | 04:00 |
| jamielennox | then you end up with all those commits in history | 04:00 |
| morganfainberg | jamielennox, so instead of an --amend, you just keep stacking on commits until it's done | 04:00 |
| * morganfainberg thinks it's dumb compared to the gerrit model | 04:00 | |
| morganfainberg | yep | 04:00 |
| morganfainberg | welcome to pull requests | 04:01 |
| jamielennox | how is this still a thing... | 04:01 |
| morganfainberg | people aparently like it | 04:01 |
| jamielennox | all of the comments on my PR no longer make sense cause i keep push -f changes | 04:01 |
| *** ncoghlan is now known as ncoghlan_afk | 04:01 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/106210 | 04:02 |
| morganfainberg | basically, you can't -f push (or shouldn't) you're supposed to keep all the commits as part of the history afaict | 04:02 |
| morganfainberg | jamielennox, something about iterative work | 04:03 |
| jamielennox | i feel a -f is fine for something you are requesting to be merged | 04:03 |
| jamielennox | i see the point of having a pull have multiple commits | 04:03 |
| jamielennox | but that doesn't mean you can't fix mistakes in your commits in the actual commit | 04:04 |
| morganfainberg | i prefer openstack's model | 04:04 |
| morganfainberg | gerrit makes this *a lot* easier | 04:04 |
| jamielennox | yea, just thought github would have jumped on board this by now | 04:09 |
| morganfainberg | jamielennox, nah | 04:11 |
| *** syedawaisali has joined #openstack-keystone | 04:13 | |
| *** topol has joined #openstack-keystone | 04:26 | |
| *** oomichi has joined #openstack-keystone | 04:28 | |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Reorder the old compatibility arguments https://review.openstack.org/109141 | 04:35 |
| *** dims has joined #openstack-keystone | 04:41 | |
| *** stevemar has joined #openstack-keystone | 04:43 | |
| *** ajayaa has joined #openstack-keystone | 04:45 | |
| openstackgerrit | A change was merged to openstack/keystonemiddleware: move webob from test-requirements to requirements https://review.openstack.org/109064 | 04:46 |
| *** dims has quit IRC | 04:46 | |
| *** chandankumar has quit IRC | 04:49 | |
| *** zzzeek has quit IRC | 04:53 | |
| *** stevemar has quit IRC | 04:56 | |
| *** chandankumar has joined #openstack-keystone | 04:59 | |
| *** topol has quit IRC | 05:04 | |
| *** harlowja has quit IRC | 05:11 | |
| *** harlowja has joined #openstack-keystone | 05:11 | |
| *** ncoghlan_afk is now known as ncoghlan | 05:15 | |
| *** k4n0 has joined #openstack-keystone | 05:24 | |
| *** junhongl has joined #openstack-keystone | 05:41 | |
| *** dims has joined #openstack-keystone | 05:42 | |
| *** alex_xu has quit IRC | 05:45 | |
| *** dims has quit IRC | 05:47 | |
| *** tomoiaga has joined #openstack-keystone | 05:59 | |
| *** alex_xu has joined #openstack-keystone | 06:01 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/106939 | 06:05 |
| *** amerine has quit IRC | 06:07 | |
| *** amerine has joined #openstack-keystone | 06:08 | |
| *** _afazekas has quit IRC | 06:20 | |
| *** sbasam has quit IRC | 06:20 | |
| *** afazekas is now known as _afazekas | 06:20 | |
| *** zigo has quit IRC | 06:27 | |
| *** mitz has quit IRC | 06:30 | |
| *** mitz has joined #openstack-keystone | 06:32 | |
| *** zigo has joined #openstack-keystone | 06:32 | |
| *** ChanServ changes topic to "July 9-11 Hackathon notes https://etherpad.openstack.org/p/keystone-juno-hackathon | Now with 100% gate and check runs on Apache deployed Keystone | K release named "Kilo"" | 06:33 | |
| *** andreaf has quit IRC | 06:34 | |
| *** sbasam has joined #openstack-keystone | 06:37 | |
| *** harlowja is now known as harlowja_away | 06:42 | |
| *** dims has joined #openstack-keystone | 06:43 | |
| *** dims has quit IRC | 06:48 | |
| *** alex_xu has quit IRC | 06:59 | |
| *** shakamunyi has quit IRC | 07:03 | |
| *** afazekas_ has joined #openstack-keystone | 07:04 | |
| *** syedawaisali has quit IRC | 07:06 | |
| *** alex_xu has joined #openstack-keystone | 07:13 | |
| *** jamielennox is now known as jamielennox|away | 07:20 | |
| *** xianghuihui has joined #openstack-keystone | 07:23 | |
| *** ncoghlan is now known as ncoghlan_afk | 07:26 | |
| *** xianghui has quit IRC | 07:26 | |
| *** jimbaker has quit IRC | 07:36 | |
| *** gabriel-bezerra has quit IRC | 07:38 | |
| *** gabriel-bezerra has joined #openstack-keystone | 07:38 | |
| *** xianghuihuihui has joined #openstack-keystone | 07:41 | |
| *** dims_ has joined #openstack-keystone | 07:43 | |
| *** xianghuihui has quit IRC | 07:44 | |
| *** xianghuihui has joined #openstack-keystone | 07:48 | |
| *** dims_ has quit IRC | 07:48 | |
| *** xianghuihuihui has quit IRC | 07:51 | |
| *** xianghuihuihui has joined #openstack-keystone | 08:01 | |
| *** xianghuihui has quit IRC | 08:03 | |
| *** andreaf has joined #openstack-keystone | 08:05 | |
| *** xianghuihuihui has quit IRC | 08:11 | |
| *** xianghuihui has joined #openstack-keystone | 08:11 | |
| *** ashepelev has joined #openstack-keystone | 08:29 | |
| *** dims_ has joined #openstack-keystone | 08:44 | |
| *** xianghuihuihui has joined #openstack-keystone | 08:47 | |
| *** xianghuihui has quit IRC | 08:48 | |
| *** dims_ has quit IRC | 08:49 | |
| *** miqui has quit IRC | 08:54 | |
| *** jimbaker has joined #openstack-keystone | 09:05 | |
| *** jimbaker has quit IRC | 09:05 | |
| *** jimbaker has joined #openstack-keystone | 09:05 | |
| *** ajayaa has quit IRC | 09:05 | |
| *** miqui has joined #openstack-keystone | 09:12 | |
| *** alex_xu has quit IRC | 09:17 | |
| openstackgerrit | wanghong proposed a change to openstack/keystone: add internal delete notification for endpoint https://review.openstack.org/108329 | 09:27 |
| *** dims_ has joined #openstack-keystone | 09:45 | |
| *** dims_ has quit IRC | 09:50 | |
| *** k4n0 has quit IRC | 10:07 | |
| *** vhoward has joined #openstack-keystone | 10:09 | |
| *** k4n0 has joined #openstack-keystone | 10:21 | |
| *** ajayaa has joined #openstack-keystone | 10:25 | |
| *** gabriel-bezerra has quit IRC | 10:27 | |
| *** gabriel-bezerra has joined #openstack-keystone | 10:27 | |
| *** vhoward has left #openstack-keystone | 10:30 | |
| *** harlowja_away has quit IRC | 10:59 | |
| *** k4n0 has quit IRC | 11:01 | |
| fish_ | hrm.. I'm still a bit confused about keystone, users and tenants. when just looking at keystone, it seems like the common case is to have an tentant for, well a tenant. whether it's a external customer or a team inside your company etc | 11:07 |
| *** pgnx has joined #openstack-keystone | 11:07 | |
| *** pgnx has quit IRC | 11:08 | |
| fish_ | but with barbican things look different: since it stores credentials on a per tenant basis, the tenants are more 'entities to grant access to a set of resources' which are the actual services - not teams | 11:08 |
| fish_ | but maybe I got something completely wrong | 11:08 |
| fish_ | so I'm wondering: if it reasonable to have one tenant per service, or is there a better way to grant access to a set of credentials? | 11:09 |
| *** miqui has quit IRC | 11:15 | |
| *** chandankumar has quit IRC | 11:17 | |
| *** k4n0 has joined #openstack-keystone | 11:19 | |
| *** chandankumar has joined #openstack-keystone | 11:32 | |
| *** diegows has joined #openstack-keystone | 11:33 | |
| *** marzif has joined #openstack-keystone | 11:34 | |
| *** dims has joined #openstack-keystone | 11:44 | |
| *** k4n0 has quit IRC | 11:59 | |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Keystone part of a PoC for Horizon/Keystone WebSSO https://review.openstack.org/106096 | 12:07 |
| *** afazekas_ has quit IRC | 12:07 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Hierarchical Projects https://review.openstack.org/108841 | 12:09 |
| *** afazekas_ has joined #openstack-keystone | 12:24 | |
| *** oomichi has quit IRC | 12:25 | |
| *** jamielennox|away has quit IRC | 12:26 | |
| *** jamielennox|away has joined #openstack-keystone | 12:29 | |
| *** gordc has joined #openstack-keystone | 12:35 | |
| *** ajayaa has quit IRC | 12:52 | |
| *** jimbaker has quit IRC | 13:00 | |
| *** jimbaker has joined #openstack-keystone | 13:01 | |
| *** jimbaker has quit IRC | 13:02 | |
| *** jimbaker has joined #openstack-keystone | 13:02 | |
| *** zigo has quit IRC | 13:03 | |
| *** ajayaa has joined #openstack-keystone | 13:03 | |
| *** zigo has joined #openstack-keystone | 13:04 | |
| *** alex_xu has joined #openstack-keystone | 13:05 | |
| *** ajayaa has quit IRC | 13:08 | |
| *** chandankumar has quit IRC | 13:10 | |
| *** dims has quit IRC | 13:13 | |
| *** nkinder has quit IRC | 13:13 | |
| *** dims has joined #openstack-keystone | 13:14 | |
| openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Keystone part of a PoC for Horizon/Keystone WebSSO https://review.openstack.org/106096 | 13:16 |
| *** afazekas_ has quit IRC | 13:20 | |
| *** richm has joined #openstack-keystone | 13:22 | |
| *** lbragstad has joined #openstack-keystone | 13:23 | |
| openstackgerrit | Alexey Miroshkin proposed a change to openstack/keystone: Add another check of the url in the 'self' link https://review.openstack.org/109290 | 13:25 |
| *** topol has joined #openstack-keystone | 13:32 | |
| *** afazekas_ has joined #openstack-keystone | 13:33 | |
| *** oomichi has joined #openstack-keystone | 13:34 | |
| *** erecio has joined #openstack-keystone | 13:35 | |
| *** oomichi has quit IRC | 13:40 | |
| *** afazekas_ has quit IRC | 13:42 | |
| *** erecio has quit IRC | 13:43 | |
| *** vhoward has joined #openstack-keystone | 13:44 | |
| *** stevemar has joined #openstack-keystone | 13:46 | |
| openstackgerrit | ayoung proposed a change to openstack/keystone-specs: Cookie for tokens https://review.openstack.org/109295 | 13:49 |
| openstackgerrit | ayoung proposed a change to openstack/keystone-specs: Cookie for tokens https://review.openstack.org/109295 | 13:51 |
| *** bknudson has joined #openstack-keystone | 13:53 | |
| dstanek | ayoung: why is horizon already doing what you suggest with cookies? | 13:53 |
| dstanek | s/is/isn't/ | 13:53 |
| *** radez_g0n3 is now known as radez | 13:56 | |
| ayoung | dstanek, because they originally had a "no memcache" rule | 13:57 |
| ayoung | dstanek, so they needed to store the whole token in the users cookie, and I told them about the MD5 hack | 13:58 |
| dstanek | do they use authtoken middleware too? | 13:58 |
| *** nkinder has joined #openstack-keystone | 13:58 | |
| *** joesavak has joined #openstack-keystone | 13:58 | |
| morganfainberg | ayoung, so ... we're precluding the use of non-persistent tokens by that spec. | 13:59 |
| ayoung | morganfainberg, nope | 13:59 |
| morganfainberg | well with horizon at least | 13:59 |
| ayoung | morganfainberg, nope | 13:59 |
| ayoung | morganfainberg, here's how it would go | 13:59 |
| ayoung | user hits horizon and logs in | 13:59 |
| ayoung | horizon goes to keystone, gets an unscoped token, sticks that in the users session, gets a scoped token, sticks that in memcache, sticks the key in the users session. THat is prep.... | 14:00 |
| dstanek | ayoung: you are not guaranteed memcached will hold the token for the entire time it is valid | 14:00 |
| ayoung | now, Horizon goes to nova and does a status call | 14:00 |
| ayoung | dstanek, I'm aware, and if that is the case, return a 403 or whatever with enough info to send the origianl token | 14:01 |
| ayoung | maybe "multiple options" | 14:01 |
| ayoung | dstanek, that is always the risk with memcached | 14:01 |
| dstanek | if the token isn't persistent what do you send? a new token? they would have to go back to keystone for it | 14:02 |
| dstanek | ayoung: also you wouldn't want this to happen in front of the other services right? just horizon? | 14:03 |
| ayoung | No | 14:03 |
| ayoung | dstanek, this is for heat talking to swift, for example | 14:04 |
| ayoung | the session cookie can have a time out, so the client knows to send the whole token again | 14:04 |
| morganfainberg | i'm still not seeing how this works with non-persistent tokens | 14:05 |
| morganfainberg | especially in the horizon case | 14:06 |
| dstanek | ayoung: i'm a little confused. if heat is the client and swift is the server....they both have the token and an agreed upon short string that is the equivalent of the token? | 14:07 |
| ayoung | dstanek, that is it | 14:07 |
| ayoung | morganfainberg, this is a shorthand way of saying "here is the token I'm using, you've already seen it, validated it, and handed back to me a receipt." | 14:08 |
| dstanek | how does that help horizon then? | 14:08 |
| ayoung | dstanek, in the case of horizon talking to swift, it cuts down on the message size going from Horizon to swift | 14:08 |
| dstanek | ayoung: but as you are decreasing the network traffic between the two, you are adding a new network connection to memcached and using the same about of bandwidth there | 14:10 |
| ayoung | dstanek, the memcached call is there already. We store the tokens in memcached, just keyed by their hash. This would replace that with keyed by a random number | 14:10 |
| dstanek | ayoung: hmmm...i wouldnt | 14:11 |
| dstanek | have expected that | 14:11 |
| ayoung | dstanek, I want to remove the "hash of the token is as good as the token" approach | 14:12 |
| dstanek | i would have thought that given a pki token you would need to check the revocation list and not memcached | 14:12 |
| ayoung | revocation list is going away | 14:12 |
| ayoung | we need to check the revocation events | 14:12 |
| ayoung | which implies the full token | 14:12 |
| morganfainberg | dstanek, ayoung, btw, minimal token (PKIZ) is 1.7k | 14:12 |
| ayoung | need the full token for RBAC anyway | 14:12 |
| morganfainberg | (no catalog) | 14:12 |
| dstanek | events can't replace the list - just supplement it | 14:13 |
| ayoung | morganfainberg, 1.7k unscoped ? I had it at under 1 K | 14:13 |
| morganfainberg | raw data is 1.4k | 14:13 |
| morganfainberg | no, that is scoped | 14:13 |
| ayoung | dstanek, no, replace | 14:13 |
| ayoung | Absolutley replace. the list is a security nightmare | 14:13 |
| morganfainberg | ayoung, minimal *useful* token, unscoped tokens today are not-useful | 14:13 |
| ayoung | morganfainberg, ah. OK | 14:13 |
| ayoung | what else is in there? role and project? | 14:13 |
| morganfainberg | it is a v2 token as well | 14:13 |
| morganfainberg | {'access': {'token': {'issued_at': '2014-07-24T14:10:42.735309', 'expires': '2014-07-24T15:10:42Z', 'id': 'placeholder', 'tenant': {'domain_id': 'default', 'enabled': True, 'description': 'description', 'name': 'BAZ', 'id': 'baz'}}, 'user': {'username': 'TWO', 'roles_links': [], 'id': '7c3e610c4e274ffda349888ced57e1ce', 'roles': [{'name': '_member_'}], 'name': 'TWO'}, 'metadata': {'is_admin': 0, 'roles': ['9fe2ff9ee4384b1894a90 | 14:13 |
| morganfainberg | 878d3e92bab']}}} | 14:13 |
| dstanek | ayoung: how do you guarantee all events are caught? and how would you can't up new instance to what is already revoked? | 14:14 |
| ayoung | morganfainberg, ++ | 14:14 |
| morganfainberg | the metadatacrap is an issue | 14:14 |
| ayoung | dstanek, when you switch? All earlier tokens are revoked | 14:14 |
| *** ayoung is now known as ayoung-phone | 14:14 | |
| morganfainberg | but, basically, we're not going to get much lower than ~1k even with ID only | 14:14 |
| dstanek | so if i turn on a new instance of nova all previous tokens are revoked? but only by that instance | 14:15 |
| morganfainberg | dstanek, it would ask keystone for the full revocation event list, and we poll the revocation events on X interval | 14:15 |
| morganfainberg | same as we do for the list | 14:15 |
| morganfainberg | but events are more accurate | 14:15 |
| morganfainberg | you don't need to enumerate each token to know it is revoked | 14:15 |
| morganfainberg | oh interesting... we screwed up in issuring tokens | 14:16 |
| * morganfainberg just noticed expires at is not subsecond | 14:16 | |
| dstanek | morganfainberg: that's what i thought too, but ayoung said it was going away | 14:17 |
| morganfainberg | dstanek, the revocation list is going away | 14:17 |
| morganfainberg | the enumeration of each token id being revoked, the events will be used which say (tokens for user X revoeked before time Y) | 14:17 |
| morganfainberg | which in the revocation list could be 1000s of tokens | 14:17 |
| *** gabriel-bezerra has quit IRC | 14:17 | |
| dstanek | morganfainberg: how do you have for a full revocation list if it doesn't exist? | 14:18 |
| dstanek | s/have/ask/ | 14:18 |
| morganfainberg | dstanek, you're asking for the revocation events, not the *list* | 14:18 |
| morganfainberg | the list is a list of ids, works like a CRL | 14:18 |
| morganfainberg | revocation events work based upon data in the token, e.g. user_id | 14:18 |
| dstanek | a list of events? | 14:18 |
| morganfainberg | yep | 14:18 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:19 | |
| *** YorikSar_ has joined #openstack-keystone | 14:19 | |
| *** ajayaa has joined #openstack-keystone | 14:19 | |
| dstanek | ah, that makes more sense - we need better naming | 14:19 |
| morganfainberg | on a password change, instead of having to revoke (for example) 1000 tokens and shove the ids into the TRL | 14:19 |
| morganfainberg | which is now 32k bigger (assuming md5 hash) | 14:19 |
| morganfainberg | you issue one event that says user_id=XYZ, timestamp=Q | 14:20 |
| morganfainberg | and all tokens before timestamp Q for user_id XYZ are now revoked | 14:20 |
| *** gabriel-bezerra has quit IRC | 14:20 | |
| morganfainberg | much much much less data (and much faster) | 14:20 |
| morganfainberg | much faster to generate the list, actually a bit slower to validate a token (at the moment) | 14:20 |
| *** hrybacki has joined #openstack-keystone | 14:20 | |
| morganfainberg | dstanek, but everyone seems to want 32byte magical blobs that work like PKI tokens but use like UUID tokens | 14:21 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:21 | |
| *** YorikSar has quit IRC | 14:23 | |
| morganfainberg | dstanek, i can get a token down to about ~1k just not seeing it getting much lower | 14:27 |
| *** rwsu has joined #openstack-keystone | 14:28 | |
| *** david-lyle has joined #openstack-keystone | 14:28 | |
| dstanek | morganfainberg: can't we get rid of some of the info like tenant description and if it's enabled? | 14:28 |
| bknudson | morganfainberg: shorter names? | 14:29 |
| bknudson | morganfainberg: take out the roles like we can take out the catalog? | 14:29 |
| morganfainberg | bknudson, we duplicate a lot of data by shoving "metadata" into the tokens, so we can strip that out (duplication of roles etc) | 14:29 |
| morganfainberg | bknudson, we can strip out the "enabled" flags from tenant etc | 14:30 |
| *** gabriel-bezerra has quit IRC | 14:30 | |
| *** gabriel-bezerra has joined #openstack-keystone | 14:30 | |
| bknudson | also, I opened a bug for the expires not being subsecond: https://bugs.launchpad.net/keystone/+bug/1347961 | 14:30 |
| uvirtbot | Launchpad bug 1347961 in keystone "Revocation events are broken with mysql" [Undecided,New] | 14:31 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove ec2 contrib dependency on token_api https://review.openstack.org/109173 | 14:31 |
| dstanek | morganfainberg: is anything more than id required in the tenant? | 14:31 |
| bknudson | it may be different depending on the DB server | 14:31 |
| nkinder | morganfainberg: let's limit the number of defined roles to 16 and make them a bit-field in the token;) | 14:31 |
| *** gabriel-bezerra has quit IRC | 14:31 | |
| * nkinder ducks | 14:31 | |
| *** shakamunyi has joined #openstack-keystone | 14:31 | |
| morganfainberg | nkinder, HAH! | 14:31 |
| morganfainberg | bknudson, i saw. | 14:31 |
| dstanek | nkinder: where i used to work our tokens were packed with python's struct | 14:32 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:32 | |
| dstanek | the first byte have version number and the rest of the token could vary in format | 14:32 |
| morganfainberg | i think the minimum viable token looks something like (scoped): | 14:33 |
| morganfainberg | {'token': {'issued_at': '2014-07-24T14:26:23.766970', 'expires': '2014-07-24T15:26:23.766970', ‘project': {'domain_id': ‘default', 'id': 'baz', 'name': 'BAZ'}}, 'user': {'username': 'TWO', 'id': 'e44c07606b674d7fa487ead80ae90639', 'roles': [{'name': '_member_'}], 'name': 'TWO'}} | 14:33 |
| bknudson | that's got user ID but not role ID | 14:34 |
| morganfainberg | bknudson, policy.json tends to use role names | 14:34 |
| morganfainberg | bknudson, not ids. | 14:34 |
| morganfainberg | bknudson, and v2 hid the role ids in metadata (never in *actual* location you'd expect) | 14:35 |
| morganfainberg | is we strip the username, and the extra 'name' field | 14:36 |
| morganfainberg | i think we're still going to see not much less than 1k in token size. | 14:36 |
| *** gabriel-bezerra has quit IRC | 14:36 | |
| morganfainberg | when run through cms | 14:36 |
| *** gabriel-bezerra has joined #openstack-keystone | 14:37 | |
| *** gordc has quit IRC | 14:40 | |
| *** gordc has joined #openstack-keystone | 14:44 | |
| bknudson | morganfainberg: cms overhead seems to be the limiting factor | 14:46 |
| bknudson | and base-64 encoding | 14:46 |
| morganfainberg | bknudson, yep | 14:46 |
| morganfainberg | s/mime may not be a good choice here. | 14:46 |
| bknudson | morganfainberg: what if you cms 1 byte? | 14:46 |
| morganfainberg | bknudson, i think you still get a reasonable size blob | 14:46 |
| *** andreaf has quit IRC | 14:47 | |
| *** lbragstad has quit IRC | 14:48 | |
| dolphm | morganfainberg: what made you deviate from purely ID's? | 14:49 |
| openstackgerrit | Nathan Kinder proposed a change to openstack/python-keystoneclient: Don't log sensitive auth data https://review.openstack.org/101792 | 14:50 |
| morganfainberg | dolphm, even if we strip down to pure ids (though roles need to be names i think) | 14:51 |
| morganfainberg | dolphm, we'll still end up with ~1k tokens i think | 14:51 |
| morganfainberg | (scoped) | 14:51 |
| *** gordc has quit IRC | 14:52 | |
| *** gordc has joined #openstack-keystone | 14:52 | |
| *** ukalifon1 has joined #openstack-keystone | 14:52 | |
| dolphm | morganfainberg: if roles were ID based in the token, you'd just have to call keystone and convert them, and cache the results | 14:52 |
| morganfainberg | and for the heirarchical stuff, would we encode that into the token? or make a service that need the hierarchy info ask keystone | 14:52 |
| morganfainberg | dolphm, sur,e but i think most role names are < role uuids | 14:52 |
| morganfainberg | dolphm, 32bytes is a lot of role name ;) | 14:53 |
| *** shakamunyi has quit IRC | 14:53 | |
| morganfainberg | either way | 14:53 |
| dolphm | morganfainberg: ++ but roles are a place where i see user-defined IDs fitting in as well | 14:53 |
| morganfainberg | sure | 14:53 |
| morganfainberg | and i just cheked we support role_name=255 | 14:54 |
| morganfainberg | so even still, move to uuids | 14:54 |
| *** ukalifon3 has joined #openstack-keystone | 14:54 | |
| *** ukalifon1 has quit IRC | 14:56 | |
| *** ayoung-phone is now known as ayoung | 14:58 | |
| *** tomoiaga has quit IRC | 14:58 | |
| *** lbragstad has joined #openstack-keystone | 14:59 | |
| ajayaa | morganfainberg, hi | 14:59 |
| ayoung | So glad I let morganfainberg explain that. I need to copy that discussion and post it where others can read it...let me pull up the evesdrop link | 14:59 |
| ayoung | http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2014-07-24.log | 15:01 |
| ayoung | that page is now now self referential | 15:01 |
| morganfainberg | dolphm, something like? http://pasteraw.com/k0vohepbo28aywm7egg89t10upu5jfm | 15:02 |
| morganfainberg | ayoung, ^ | 15:02 |
| morganfainberg | s/endpoint_lists/endpoints | 15:02 |
| *** chandankumar has joined #openstack-keystone | 15:02 | |
| morganfainberg | ooh forgot the token bind attribute | 15:03 |
| dolphm | morganfainberg: wouldn't 'endpoints' be part of scope if it's supposed to be used as authorization scope? | 15:03 |
| morganfainberg | dolphm, ++ | 15:03 |
| ayoung | I fielded a question yesterday about applying roles to objects. In SELinux, there is the concept of a "label" which is added to the inode of a file, and SELinux checks that the caller contains access to that label. I wonder if there is some way to standardize "label this resource with this role" in OpenStack. Do we just suggest that all resources have "role" field? Or that each service implements some sort of label t | 15:04 |
| ayoung | able? | 15:04 |
| dolphm | morganfainberg: also, roles -> role_ids & endpoints -> endpoint_ids | 15:04 |
| *** david-ly_ has joined #openstack-keystone | 15:04 | |
| morganfainberg | ayoung, how much data can/should go into a token bind? | 15:04 |
| ayoung | morganfainberg, binding a token to an authentication source? | 15:05 |
| ayoung | or to an endpoint? | 15:05 |
| dolphm | ayoung: auth source | 15:05 |
| morganfainberg | ayoung, auth | 15:05 |
| ayoung | morganfainberg, principal or subject; 128 Chars max, maybe? | 15:05 |
| dolphm | morganfainberg: you might also have OS-FEDERATION attributes (OS-FEDERATION:idp_id & OS-FEDERATION:protocol_id) | 15:06 |
| dolphm | morganfainberg: and group_ids | 15:06 |
| morganfainberg | ayoung ok | 15:06 |
| dolphm | morganfainberg: also, expires -> expires_at | 15:06 |
| morganfainberg | dolphm, ++ trying to get a "worst case" token together assuming a few roles (and some endpoint binding) | 15:06 |
| *** david-lyle has quit IRC | 15:06 | |
| dolphm | morganfainberg: so, a federated identity consuming a trust with token/auth binding | 15:07 |
| morganfainberg | dolphm, http://pasteraw.com/n1bh4hjmae1y3ynj7wskj7jogpnrc3i | 15:11 |
| morganfainberg | ? | 15:11 |
| morganfainberg | or would the Federation/trust stuff be dicts somewhere else? | 15:11 |
| morganfainberg | ayoung, ^ | 15:11 |
| dolphm | morganfainberg: group_ids | 15:12 |
| morganfainberg | dolphm, ah yep | 15:12 |
| dolphm | morganfainberg: also, bind is an object | 15:12 |
| *** Chicago has quit IRC | 15:12 | |
| morganfainberg | oh it is? bleh | 15:12 |
| dolphm | morganfainberg: "bind": {"x509": {"fingerprint": "0123456789ABCDEF", "algorithm": "sha1"}} | 15:13 |
| *** Chicago has joined #openstack-keystone | 15:13 | |
| ayoung | morganfainberg, lets just assume that, for someone, it is going to be too big | 15:14 |
| ayoung | 4K ish? | 15:14 |
| dolphm | morganfainberg: so, fingerprint = 40 bytes assuming we're not including colons in there | 15:15 |
| morganfainberg | dolphm, http://pasteraw.com/5cs18znqsm5rvnq235n86soroof1tjq | 15:16 |
| *** cjellick has joined #openstack-keystone | 15:17 | |
| morganfainberg | this doesn't mean the work towards non-persistent-otkens is bad, (it unifies the token handling in keystone and moves us to rev. events) but i think 4k is going to cause us problems token wise | 15:17 |
| *** vhoward has left #openstack-keystone | 15:18 | |
| *** kwss has joined #openstack-keystone | 15:18 | |
| *** tomoiaga has joined #openstack-keystone | 15:19 | |
| morganfainberg | people want the 32 byte uuid tokens :( | 15:19 |
| morganfainberg | from a user -> endpoint experience | 15:19 |
| *** lbragstad has quit IRC | 15:19 | |
| *** cjellick has quit IRC | 15:19 | |
| *** cjellick has joined #openstack-keystone | 15:20 | |
| *** gyee has joined #openstack-keystone | 15:23 | |
| dolphm | morganfainberg: set the bind fingerprint to 2bfe4c911c38cc51ecdcd04e232d4400c92095f2 for something more realistic | 15:24 |
| morganfainberg | dolphm, ++ | 15:24 |
| dolphm | morganfainberg: and... we actually only include group_ids on unscoped federated tokens, now that i think about it. so, if you're modeling a worst case scenario token, it probably wouldn't have groups | 15:25 |
| morganfainberg | ok | 15:25 |
| dolphm | morganfainberg: and if you care, i don't *think* the trust_id appears in the scope? but i could be wrong | 15:26 |
| morganfainberg | we call it a "trust-scoped" token | 15:26 |
| morganfainberg | but i can move it | 15:26 |
| dolphm | morganfainberg: yeah... https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-trust-ext.md | 15:26 |
| *** tomoiaga has quit IRC | 15:26 | |
| dolphm | morganfainberg: "scoped to a project according to the trust" would be a more verbose way of saying that | 15:27 |
| dolphm | morganfainberg: if you just include the trust_id, the rest can be obtained from keystone though | 15:28 |
| *** lbragstad has joined #openstack-keystone | 15:28 | |
| morganfainberg | dolphm, http://pasteraw.com/8it1s716fnvg0tlind9v7220htzy8j9 | 15:28 |
| morganfainberg | forgot we needed user's domain id in there so we can revoke on domain_id if needed | 15:29 |
| dolphm | morganfainberg: well now you're just making it bigger lol | 15:29 |
| morganfainberg | probably also need project's domain_id | 15:29 |
| morganfainberg | dolphm, i did a pretty-print that time | 15:29 |
| morganfainberg | easier to read | 15:29 |
| dolphm | morganfainberg: and you broke a bunch of stuff lol | 15:29 |
| morganfainberg | what did I break? | 15:30 |
| *** xianghuihuihui has quit IRC | 15:30 | |
| morganfainberg | should it be OS-FEDERATION:<thing> or is OS-FEDERATION a object? | 15:30 |
| dolphm | morganfainberg: OS-FEDERATION is a prefix, not an object / attribute | 15:30 |
| morganfainberg | ok | 15:30 |
| morganfainberg | sec | 15:30 |
| dolphm | morganfainberg: trust is still in scope | 15:30 |
| *** xianghuihuihui has joined #openstack-keystone | 15:30 | |
| dolphm | OS-TRUST is also a prefix, not an object | 15:30 |
| dolphm | trust_id is redudant with what i assume you meant to contain it in, but could be simplified to just "OS-TRUST:trust_id": "abc" | 15:31 |
| dolphm | morganfainberg: user_id now points to an object instead of an ID | 15:31 |
| dolphm | morganfainberg: apply coffee and try again :P | 15:32 |
| morganfainberg | lol | 15:32 |
| *** gyee has quit IRC | 15:33 | |
| morganfainberg | dolphm, ok | 15:35 |
| morganfainberg | lets see | 15:35 |
| morganfainberg | http://pasteraw.com/3n6tjskwfvmzog1th5lvlniq5muqmqw | 15:35 |
| morganfainberg | i think that is *better* | 15:35 |
| morganfainberg | or is "scope": type bad and it should just be scope: (project_id|domain_id) | 15:36 |
| morganfainberg | dolphm, please ignore the typo in FEDERATON | 15:37 |
| *** zzzeek has joined #openstack-keystone | 15:37 | |
| morganfainberg | :P | 15:37 |
| morganfainberg | dolphm, serialized i clock that at just under 800bytes pre-cms | 15:38 |
| morganfainberg | (pre compress) | 15:38 |
| dolphm | morganfainberg: i'd be fine with "scope": {"project_id" | 15:39 |
| morganfainberg | *nod* | 15:40 |
| dolphm | morganfainberg: move "OS-TRUST:trust_id": "---32-byte-trust-id-string-----" out of "scope" | 15:41 |
| morganfainberg | ok | 15:41 |
| richm | if the endpoint is explicitly set in keystone.conf, should it have the version in the url path? e.g. | 15:42 |
| *** gyee has joined #openstack-keystone | 15:42 | |
| richm | admin_endpoint=http://localhost/keystone/admin/v2.0 | 15:43 |
| richm | or | 15:43 |
| richm | admin_endpoint=http://localhost/keystone/admin | 15:43 |
| richm | ? | 15:43 |
| dolphm | richm: no | 15:44 |
| morganfainberg | dolphm, http://pasteraw.com/3d67hkybdzk54mfrr3vfywf7xyc1mvi | 15:44 |
| dolphm | morganfainberg: why bother including the user's domain_id ? | 15:45 |
| richm | dolphm: Then the client is responsible for adding the version? | 15:45 |
| morganfainberg | dolphm, if we revoke all tokens for a domain, do we need to revoke the tokens for users who live under that domain? | 15:46 |
| dolphm | richm: those configuration options determine what links the server builds and return to the client to achieve HATEOAS | 15:46 |
| morganfainberg | dolphm, if not, we can go back to plain user_id | 15:46 |
| dolphm | morganfainberg: oh right, so you need the project's domain ID for the same reason | 15:46 |
| morganfainberg | yeah | 15:46 |
| morganfainberg | let me add project domain_id in | 15:46 |
| morganfainberg | dolphm, http://pasteraw.com/frcyhsw2tqh6fy16lu4fmmio22e39wv | 15:48 |
| dolphm | morganfainberg: yep, i think that's the nightmare token you're looking for! | 15:49 |
| morganfainberg | dolphm, pre-compress, pre-cms, 832 bytes, and it could get worse with more roles or more endpoints | 15:51 |
| morganfainberg | i'm going to guess, barring 128bytes for krb5 binds, we're going to see 2k tokens regularly. | 15:51 |
| dolphm | morganfainberg: sounds right | 15:52 |
| morganfainberg | way better than 8k | 15:52 |
| morganfainberg | but, still | 15:52 |
| dstanek | morganfainberg: you can get crazy and cut the id sizes in half! | 15:52 |
| dolphm | dstanek: i proposed that once | 15:53 |
| dstanek | uuid.uuid4().bytes instead of .hex | 15:53 |
| morganfainberg | dstanek, how does that serialize? | 15:53 |
| dolphm | dstanek: i actually did base36 encoded uuid4 strings to get it down to 26 or so, and then added a conf option to truncate them | 15:53 |
| dolphm | dstanek: for example, 55nwozjm8479jyiztr9kvhdx7 | 15:53 |
| dolphm | dstanek: http://pasteraw.com/6u6bdvkx5hn5pjelf0wf8c5s5kyyacx | 15:54 |
| openstackgerrit | guang-yee proposed a change to openstack/keystone-specs: X.509 SSL certificate authentication https://review.openstack.org/105913 | 15:54 |
| dstanek | dolphm: why not base64 minus padding? | 15:55 |
| dolphm | dstanek: because i didn't know about base64's url safe mode at the time, and wanted to ensure url safety | 15:55 |
| dstanek | morganfainberg: as a Python string | 15:55 |
| morganfainberg | dstanek, ah | 15:55 |
| morganfainberg | dstanek, except we aren't guaranteed they'll be 32bytes even now, in fact | 15:56 |
| morganfainberg | going forward, i would assume we'll have user_ids that are ~64bytes | 15:56 |
| morganfainberg | henry's user_id thing | 15:56 |
| morganfainberg | doesn't change that we could use bytes | 15:56 |
| *** YorikSar_ has quit IRC | 15:57 | |
| *** david-ly_ is now known as david-lyle | 15:57 | |
| dstanek | right now i think uuids are 16 bytes | 15:57 |
| *** gabriel-bezerra has quit IRC | 15:57 | |
| *** lbragstad has quit IRC | 15:58 | |
| *** gabriel-bezerra has joined #openstack-keystone | 15:58 | |
| dstanek | morganfainberg: if we have 64byte uuids we'll have to increase column lengths right? | 15:58 |
| dolphm | dstanek: 16? | 15:58 |
| dstanek | or choose a different encoding | 15:59 |
| morganfainberg | dstanek, nah, our columns support 64bytes | 15:59 |
| *** arun_kant has joined #openstack-keystone | 15:59 | |
| morganfainberg | dstanek, it's why we defaulted to sha256 for the user_id thing | 15:59 |
| dstanek | morganfainberg: but a 16 byte uuid is 32 characters in hex | 15:59 |
| dolphm | $ python -c "import base64, uuid; print base64.urlsafe_b64encode(uuid.uuid4().bytes).replace('=', '')" | 15:59 |
| morganfainberg | dstanek, sorry we'll have 64 hex | 15:59 |
| dolphm | moObw7LcTpOs9KQJNzbEkA | 15:59 |
| dolphm | 22 bytes ^ | 15:59 |
| dolphm | is there a way to optimize that further? | 15:59 |
| dstanek | dolphm: yeah, the uuid rfc says 16 bytes (at least 1-4) | 15:59 |
| morganfainberg | in string form, 64bytes :P | 16:00 |
| dstanek | add move websafe characters like: - , . | 16:00 |
| dstanek | s/move/more | 16:00 |
| dstanek | dolphm: do ID's have to be web safe in the token? | 16:02 |
| morganfainberg | dstanek, nah | 16:02 |
| morganfainberg | as long as they can be converted back to somehting keystone knows. | 16:02 |
| dstanek | uuid.UUID(bytes='...') i think | 16:03 |
| dolphm | dstanek: not in the token, but i was also looking at this from the perspective of replacing v2 UUID tokens with something equivalent, but even shorter | 16:03 |
| morganfainberg | but if we're already base64 encoding the token, what is the point of encoding the values in the token? | 16:03 |
| *** ukalifon3 has quit IRC | 16:04 | |
| morganfainberg | dolphm, ahh | 16:04 |
| dstanek | dolphm: check this out https://bugs.launchpad.net/keystone/+bug/1347891 | 16:06 |
| uvirtbot | Launchpad bug 1347891 in keystone "mis-use of XML canonicalization in keystone tests" [Undecided,In progress] | 16:06 |
| dstanek | i was scratching my head for a while trying to understand why we've never seen the issue before | 16:06 |
| dolphm | someone reported that in the channel a couple days ago too | 16:07 |
| dolphm | dstanek: something must have changed recently? | 16:07 |
| dstanek | dolphm: not sure, i can't get the test to fail, but it looks like in zzzeek's environment the XML generated in the response has elements out of order | 16:08 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/106210 | 16:08 |
| dolphm | dstanek: then his version of etree is broken | 16:08 |
| dstanek | dolphm: what makes you say that? | 16:09 |
| dstanek | i was under the impression that c14n would order elements, but that's not the case | 16:09 |
| *** YorikSar has joined #openstack-keystone | 16:09 | |
| dolphm | dstanek: because your patch removes our use of the w3c xml canonicalization algorithm provided by the etree api in favor of something arbitrary | 16:10 |
| *** andreaf has joined #openstack-keystone | 16:11 | |
| *** andreaf has quit IRC | 16:11 | |
| dolphm | dstanek: is it a bad implementation of etree that doesn't order the elements? | 16:11 |
| dstanek | c14n doesn't re-order elements - i removed it from my patch because i didn't need it anymore | 16:11 |
| dstanek | dolphm: the test script - http://paste.openstack.org/show/87823/ | 16:12 |
| dolphm | dstanek: http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/#DocumentOrder | 16:12 |
| *** kwss has quit IRC | 16:13 | |
| dstanek | dolphm: i had to read that very carefully because it talks about reordering the attributes, but not the elements | 16:13 |
| dolphm | dstanek: please hold while i collect bits of my brain off the floor | 16:14 |
| dstanek | lol - this is a mirror of the conversation i had with zzzeek yesterday | 16:14 |
| dstanek | dolphm: so it seems like siblings won't be ordered | 16:15 |
| zzzeek | dstanek: ive found many bugs in openstack test suites in the past two months ive started and most of them seem to involve some degree of “convincing” :) | 16:15 |
| zzzeek | dstanek / dolphm - ignore the spec, run my test case on the issue. it doesnt work. the nodes arent reordered | 16:15 |
| dolphm | zzzeek: well i agree with dstanek, i don't see where in the spec it says that the elements will be re-ordered | 16:16 |
| zzzeek | dstanek / dolphm whether or not the spec says it, libxml isn’t doing it. libxml is *always* deviating from specs | 16:16 |
| zzzeek | dolphm: OK. i found the spec to be unsurpirsingly vague :) hence test case more useful | 16:16 |
| *** gokrokve has joined #openstack-keystone | 16:18 | |
| dolphm | i hate xml | 16:18 |
| dolphm | morganfainberg: for bonus points, you can nuke all whitespace between structural elements in the JSON | 16:20 |
| morganfainberg | dolphm, hmm. | 16:20 |
| morganfainberg | dolphm, not without writing a custom json encoder it looks like | 16:21 |
| morganfainberg | dolphm, aha | 16:23 |
| dolphm | morganfainberg: i might disagree | 16:23 |
| morganfainberg | print json.dumps(a, sort_keys=True, separators=(',', ':')) | 16:23 |
| dolphm | morganfainberg: ++ | 16:24 |
| *** marcoemorais has joined #openstack-keystone | 16:24 | |
| *** amcrn has joined #openstack-keystone | 16:24 | |
| morganfainberg | dolphm, c = zlib.compress(b) | 16:25 |
| morganfainberg | >>> sys.getsizeof(c) | 16:26 |
| morganfainberg | 346 | 16:26 |
| morganfainberg | >>> sys.getsizeof(b) | 16:26 |
| morganfainberg | 834 | 16:26 |
| morganfainberg | b is the serialized data | 16:26 |
| dolphm | morganfainberg: with whitespace removed? | 16:26 |
| morganfainberg | yep | 16:26 |
| dolphm | morganfainberg: what was it before? | 16:27 |
| *** syedawaisali has joined #openstack-keystone | 16:27 | |
| morganfainberg | oh w/ wite space? | 16:27 |
| morganfainberg | sec | 16:27 |
| dolphm | morganfainberg: 2894 | 16:27 |
| morganfainberg | dolphm, and compressed? | 16:28 |
| dolphm | morganfainberg: no, that was just an arbitrary number | 16:29 |
| *** lbragstad has joined #openstack-keystone | 16:29 | |
| morganfainberg | no whitespace, non-compressed: 869 | 16:29 |
| dolphm | so saving some chars for basically zero cost | 16:29 |
| morganfainberg | compressed = 350 | 16:29 |
| morganfainberg | yeah bascially we save a couple bytes | 16:29 |
| morganfainberg | about 30 bytes uncompressed, and 4 bytes compressed | 16:30 |
| dolphm | morganfainberg: i'm pushing a patch to do that to keystone now | 16:33 |
| morganfainberg | dolphm, ++ | 16:33 |
| morganfainberg | for our current toekns it should help a lot more. | 16:33 |
| *** lbragstad has quit IRC | 16:34 | |
| dstanek | dolphm: "i hate xml" - too bad i can't favorite irc like i can twitter | 16:36 |
| *** jsavak has joined #openstack-keystone | 16:37 | |
| arun_kant | ayoung: Can you please review https://review.openstack.org/#/c/95300/ as Yuriy is okay with changes now..will be good if it can get your and other core members blessing | 16:37 |
| openstackgerrit | Dolph Mathews proposed a change to openstack/keystone: Remove unnecessary whitespace from PKI & PKIZ tokens https://review.openstack.org/109343 | 16:38 |
| dolphm | morganfainberg: dstanek: ^ | 16:38 |
| dolphm | dstanek: fixed- https://twitter.com/dolphm/status/492348132026351617 | 16:38 |
| ayoung | arun_kant, only question I had left was on why the livetests are so different | 16:39 |
| *** joesavak has quit IRC | 16:40 | |
| ayoung | arun_kant, why should pool vs no pool affect things like test_password_change_with_auth_pool_disabled and test_password_change_with_auth_pool_enabled_long_lifetime | 16:40 |
| arun_kant | The difference is keystone uses end user ldap bind as way to authenticate and if we use pooling for binds..then it will not recoginize password change as existing user bind (with old password still exists).. | 16:42 |
| arun_kant | So the option is either no to use pooling for those kind of binds or use pooling with shorter lifetime | 16:43 |
| *** chandankumar has quit IRC | 16:44 | |
| *** lbragstad has joined #openstack-keystone | 16:44 | |
| *** afazekas_ has joined #openstack-keystone | 16:44 | |
| arun_kant | This came up in review..https://review.openstack.org/#/c/95300/15/keystone/common/ldap/core.py,cm Line # 702 | 16:45 |
| morganfainberg | dolphm, nightmare token "pkiz" signed: >>> sys.getsizeof(c) -> 2948 | 16:45 |
| dolphm | morganfainberg: ha | 16:46 |
| morganfainberg | that is w/o whitespace | 16:46 |
| arun_kant | ayoung: patches later than addressed that issue and added specific livetest around this issue. | 16:49 |
| ayoung | arun_kant, I can +2 that | 16:49 |
| ayoung | and +a | 16:49 |
| morganfainberg | dolphm, compressing the token data first gets us 300byte savings it looks like | 16:49 |
| morganfainberg | dolphm, so 2740, erm 200bytes | 16:49 |
| ayoung | morganfainberg, compressiong before signing? | 16:49 |
| arun_kant | what is +a ? | 16:49 |
| ayoung | Approved | 16:49 |
| ayoung | workflow +1 | 16:50 |
| morganfainberg | ayoung, yep, zlib.compress then pkiz = 200bytes savings | 16:50 |
| morganfainberg | ayoung, probably difference in zlib.compress defaults | 16:50 |
| ayoung | morganfainberg, there might be security implications around that. I know it came up when discussing compression vs signing, there was no issue if the signing happend before compression | 16:51 |
| morganfainberg | ayoung, but the PKI token, the signing process is adding ~2391 bytes | 16:51 |
| morganfainberg | *most* of the token data is the signing process | 16:51 |
| ayoung | morganfainberg, there is something wrong there, then | 16:53 |
| morganfainberg | ayoung, not really | 16:53 |
| morganfainberg | ayoung, smime has a high-overhead | 16:53 |
| ayoung | morganfainberg, hmmm, we don't need that | 16:53 |
| morganfainberg | you're usually not signing 400bytes of data | 16:53 |
| morganfainberg | you're usually signing more data. | 16:54 |
| ayoung | is there any need to convert to ASN1 first? | 16:54 |
| ayoung | I mean, any ral need, other than the standard? | 16:54 |
| *** YorikSar_ has joined #openstack-keystone | 16:54 | |
| ayoung | real | 16:54 |
| *** vhoward has joined #openstack-keystone | 16:54 | |
| ayoung | We need to know what was signed, and the end user needs to be able to reproduce that unambiguously | 16:55 |
| morganfainberg | ayoung, if we do cms sign of the raw data, compress, then b64urlendoce -> 1481 | 16:55 |
| morganfainberg | same data set | 16:55 |
| ayoung | So you don't want to parse the JSON. ASN1 should be a fairly small wrapper around that. Just a header and a length | 16:55 |
| morganfainberg | about 1k savings over pkiz | 16:55 |
| ayoung | there is some junk in there, then | 16:56 |
| morganfainberg | that is urlsafeencodeing btw | 16:56 |
| ayoung | what are we not doing that we should be doing? Stripping out the sert? | 16:56 |
| ayoung | cert | 16:56 |
| morganfainberg | 1.4k is better, but still over 3x the base size. | 16:57 |
| *** YorikSar has quit IRC | 16:57 | |
| *** rwsu has quit IRC | 16:58 | |
| ayoung | http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/common/cms.py#n191 that is what we do now, | 16:58 |
| morganfainberg | maybe we need to re-think this. maybe keystone needs to inject the signed data behind the scenes into something easy auth_token can query and we should be using a uuid-form, but instead of the full PKI token | 16:58 |
| ayoung | sign, compress, base64. What are you doing differently above? | 16:58 |
| morganfainberg | i did sign, compress b64 | 16:59 |
| morganfainberg | pkiz netted a bigger token | 16:59 |
| *** lbragstad has quit IRC | 16:59 | |
| ayoung | post your code, please | 16:59 |
| morganfainberg | not code, was all just hacked out. | 16:59 |
| morganfainberg | so i'll need to re-create | 16:59 |
| *** rwsu has joined #openstack-keystone | 16:59 | |
| morganfainberg | ah, i wasn't removing the -----end cms---- bit | 17:00 |
| morganfainberg | but still | 17:00 |
| morganfainberg | not that much difference | 17:00 |
| dstanek | morganfainberg: what does your final token look like? | 17:01 |
| morganfainberg | dstanek, like a urlsafe b64 string | 17:01 |
| morganfainberg | this is using the "worst-case-id-only" token | 17:01 |
| morganfainberg | http://pasteraw.com/frcyhsw2tqh6fy16lu4fmmio22e39wv | 17:02 |
| morganfainberg | even at 1.4k that is a significant improvement over what we have now. | 17:02 |
| dstanek | morganfainberg: that's not terrible | 17:02 |
| morganfainberg | dstanek, but 1.4k is a lot more than 32 or 64 bytes. | 17:02 |
| *** lbragstad has joined #openstack-keystone | 17:03 | |
| * morganfainberg shrugs | 17:03 | |
| openstackgerrit | A change was merged to openstack/identity-api: revise stability deadline to end of j3 https://review.openstack.org/108701 | 17:05 |
| openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke tokens under the same domain https://review.openstack.org/107194 | 17:09 |
| *** lbragstad has quit IRC | 17:10 | |
| *** lbragstad has joined #openstack-keystone | 17:11 | |
| *** gabriel-bezerra has quit IRC | 17:11 | |
| *** gabriel-bezerra has joined #openstack-keystone | 17:12 | |
| *** marzif has quit IRC | 17:12 | |
| *** lbragstad has quit IRC | 17:16 | |
| *** hrybacki has quit IRC | 17:20 | |
| *** gokrokve has quit IRC | 17:22 | |
| *** hrybacki has joined #openstack-keystone | 17:22 | |
| *** lbragstad has joined #openstack-keystone | 17:23 | |
| *** gokrokve has joined #openstack-keystone | 17:27 | |
| ayoung | morganfainberg, $ python tokenify.py | 17:31 |
| ayoung | 1641 from running http://paste.openstack.org/show/87980/ | 17:31 |
| ayoung | You lied | 17:32 |
| *** amcrn has quit IRC | 17:34 | |
| *** amcrn has joined #openstack-keystone | 17:35 | |
| *** harlowja has joined #openstack-keystone | 17:35 | |
| ayoung | morganfainberg, I just tried it with an string of length 0. | 17:37 |
| ayoung | $ python tokenify.py | 17:37 |
| ayoung | 757 | 17:37 |
| *** mtl1 has joined #openstack-keystone | 17:41 | |
| *** diegows has quit IRC | 17:47 | |
| openstackgerrit | Ajaya Agrawal proposed a change to openstack/keystone: Expand the caching layer in keystone https://review.openstack.org/108970 | 17:50 |
| ajayaa | dolphm, morganfainberg, ayoung, please review the above change. | 17:53 |
| mtl1 | Hi. I'm working on trying to get keystone to use https for endpoints, currently just on devstack. First problem is that I removed the endpoint for keystone itself, and need to get it back. Is that possible? | 17:54 |
| mtl1 | Second, is there a trick to changing the endpoints for keystone itself without first removing the endpoints? | 17:55 |
| ayoung | mtl1, easy | 17:55 |
| ayoung | mtl1, either use SQL or the admin token | 17:55 |
| ayoung | mtl1, which do you prefer | 17:55 |
| mtl1 | I have the admin token in my ENV, but I get this for any keystone command I try: WARNING:keystoneclient.httpclient:Failed to retrieve management_url from token | 17:56 |
| openstackgerrit | ayoung proposed a change to openstack/keystone: cache the catalog https://review.openstack.org/108970 | 17:57 |
| ayoung | ajayaa, ^^ is amuch better commit title | 17:57 |
| ajayaa | ayoung, thanks! Being a core member, do you get a special privilege to change the commits of a different person? :) | 18:00 |
| ayoung | ajayaa, anyone can | 18:00 |
| ayoung | I just edited it right in the Browser | 18:00 |
| ayoung | ajayaa, is expiration_time=EXPIRATION_TIME required? I don't see ever timing out the catalog cache, just invalidating if it is change from the API | 18:02 |
| *** marcoemorais has quit IRC | 18:02 | |
| ayoung | mtl1, you should be able to use the ADMIN_TOKEN to create an endpoi nt | 18:02 |
| ayoung | you need to set service url as well | 18:02 |
| ayoung | mtl1, see https://github.com/admiyo/keystone-examples/blob/master/client/initialize_keystone.py | 18:03 |
| ayoung | I use the OS_ENDPOINT https://github.com/admiyo/keystone-examples/blob/master/client/initialize_keystone.py#L86 to create the client | 18:03 |
| *** marcoemorais has joined #openstack-keystone | 18:03 | |
| ayoung | and then create the service catalog using it https://github.com/admiyo/keystone-examples/blob/master/client/initialize_keystone.py#L63 | 18:04 |
| mtl1 | ayoung: thanks, I'll have a look. | 18:04 |
| *** marcoemorais1 has joined #openstack-keystone | 18:04 | |
| *** marcoemorais1 has quit IRC | 18:05 | |
| ajayaa | ayoung, similar argument could be made for assignment cache as well, I suppose. I just copied the approach followed in assignment caching. | 18:06 |
| *** marcoemorais1 has joined #openstack-keystone | 18:07 | |
| ayoung | ajayaa, is that param required or optional? | 18:07 |
| ajayaa | optional. | 18:07 |
| *** diegows has joined #openstack-keystone | 18:07 | |
| *** marcoemorais has quit IRC | 18:08 | |
| ayoung | morganfainberg, is there any need to have a cache timeout value for the service catalog in ajayaa 's patch? | 18:09 |
| ayoung | ajayaa, do all of the other caches have a cache time out? | 18:10 |
| ajayaa | ayoung, yes. assignment cache does have a time out. | 18:11 |
| ayoung | ajayaa, I guess for multi backend SQL support, you need it. OK, it needs to be there, I just convinced myself | 18:11 |
| ajayaa | ayoung, Can you please tell me what multi backend sql support is in keystone? | 18:12 |
| ajayaa | Is it like there would be multiple sql databases to which keystone is talking? | 18:12 |
| ayoung | ajayaa, I mean multiple keystones talking to one sql backend | 18:13 |
| ayoung | ajayaa, I've +2ed. I'm sure Morgan will get back around to it, but it looks straightforward to me | 18:14 |
| ajayaa | ayoung, okay, In that case we would want all our caches to synced in regular intervals. Distributed caching would be an overkill, I guess. | 18:14 |
| ayoung | can never have too much overkill | 18:14 |
| dolphm | ayoung: cache invalidation is hard, we'll do it wrong, and timing out stale cache is a reliable fallback :) | 18:15 |
| ayoung | dolphm, ++ yup that is basically what I came to realize | 18:16 |
| dolphm | ayoung: alternatively, if you have multiple caches, you need a shorter timeout as one instance won't be able to invalidate the contents of the other (which is probably a more common problem) | 18:16 |
| ayoung | dolphm, the take away then is that all caching should have a timeout variable required | 18:17 |
| dolphm | ayoung: ++ | 18:17 |
| ajayaa | ayoung, thanks! | 18:17 |
| *** jimbaker has quit IRC | 18:21 | |
| *** jimbaker has joined #openstack-keystone | 18:22 | |
| *** jimbaker has quit IRC | 18:23 | |
| *** jimbaker has joined #openstack-keystone | 18:23 | |
| *** gyee has quit IRC | 18:25 | |
| *** gabriel-bezerra has quit IRC | 18:25 | |
| *** gabriel-bezerra has joined #openstack-keystone | 18:26 | |
| *** amcrn_ has joined #openstack-keystone | 18:35 | |
| *** ukalifon has joined #openstack-keystone | 18:35 | |
| *** marcoemorais1 has quit IRC | 18:36 | |
| *** amcrn has quit IRC | 18:37 | |
| *** ukalifon has quit IRC | 18:37 | |
| *** marcoemorais has joined #openstack-keystone | 18:39 | |
| *** radez is now known as radez_g0n3 | 18:42 | |
| bknudson | Can I get an unscoped token from a scoped token? | 18:42 |
| bknudson | Looks like it | 18:42 |
| bknudson | e.g., if I have a scoped token and then request a token with no scope I get an unscoped token? | 18:43 |
| bknudson | if so... if I create an unscoped token from a scoped token should the unscoped token be revoked? | 18:49 |
| *** gabriel-bezerra has quit IRC | 18:49 | |
| bknudson | I'm not sure how revocation events could know that the parent token was unscoped... | 18:50 |
| bknudson | I mean how could revocation events know that the child tokens are unscoped | 18:50 |
| *** gabriel-bezerra has joined #openstack-keystone | 18:50 | |
| *** ukalifon has joined #openstack-keystone | 18:50 | |
| openstackgerrit | Thiago Paiva Brito proposed a change to openstack/keystone: Hierarchical Projects https://review.openstack.org/108841 | 18:54 |
| *** marcoemorais has quit IRC | 18:56 | |
| *** jimbaker has quit IRC | 18:58 | |
| *** marcoemorais has joined #openstack-keystone | 18:58 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Add a test for revoking a scoped token from an unscoped https://review.openstack.org/109125 | 18:59 |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix revoking a scoped token from an unscoped token https://review.openstack.org/109389 | 18:59 |
| openstackgerrit | Diane Fleming proposed a change to openstack/identity-api: Add create, update, and delete user to admin API v2.0 https://review.openstack.org/108259 | 18:59 |
| *** jimbaker has joined #openstack-keystone | 19:00 | |
| *** jimbaker has quit IRC | 19:00 | |
| *** jimbaker has joined #openstack-keystone | 19:00 | |
| *** marcoemorais has quit IRC | 19:01 | |
| ayoung | bknudson, so we should not allow getting an unscoped token from a scoped. That is a hole on our story right now | 19:02 |
| ayoung | parent tokens were origianlly supposed to be "all revoked at the same time" | 19:02 |
| ayoung | but that broken Horizon | 19:02 |
| ayoung | We need to think about the implications of chaining. I would think something like this: | 19:03 |
| *** marcoemorais has joined #openstack-keystone | 19:03 | |
| ayoung | only unscoped to scoped is allowed. If a scope token is revoked, no other tokens are revoked. If an unscoped token is revoked, all tokens created from that unscoped token should be revoked, too | 19:03 |
| *** radez_g0n3 is now known as radez | 19:04 | |
| bknudson | ayoung: that's essentially this change: https://review.openstack.org/#/c/109389/1/keystone/tests/test_v3_auth.py | 19:05 |
| openstackgerrit | A change was merged to openstack/keystone: Adding support for ldap connection pooling. https://review.openstack.org/95300 | 19:06 |
| bknudson | ayoung: the change to test_list_delete_token_shows_in_event_list | 19:06 |
| ayoung | bknudson, we have no association between tokens right now. | 19:07 |
| bknudson | it still allows scoped to unscoped... test_list_delete_token_shows_in_event_list does that in the test... but only the scoped token is revoked and the child tokens aren't | 19:07 |
| ayoung | bknudson, if we generated a unique identifier at the authentication, and copied that from parent to child token, we could revoke on that. | 19:08 |
| *** YorikSar_ is now known as YorikSar | 19:09 | |
| bknudson | ayoung: current the unique ID is the expiration time. | 19:09 |
| bknudson | currently | 19:09 |
| ayoung | yeah, but that is going to break if we do the sliding window on session tokens | 19:09 |
| *** lbragstad has quit IRC | 19:10 | |
| *** jimbaker has quit IRC | 19:10 | |
| ayoung | bknudson, and it breaks Horizon today, as they revoke the scoped token when the user switches to a new project | 19:10 |
| *** jimbaker has joined #openstack-keystone | 19:11 | |
| *** jimbaker has quit IRC | 19:11 | |
| *** jimbaker has joined #openstack-keystone | 19:11 | |
| bknudson | ayoung: y. I thought I had a test for it but it turned out mysql gets the wrong expiration time so it wasn't revoking | 19:11 |
| *** andreaf has joined #openstack-keystone | 19:15 | |
| bknudson | I wonder how the regular token revocation code handles revoking a token with children... do they all get revoked? | 19:17 |
| ayoung | bknudson, no, there is no "chaining" today | 19:18 |
| bknudson | ok, so not revoking the children is more consistent with the current behavior | 19:19 |
| *** gabriel-bezerra has quit IRC | 19:19 | |
| ayoung | bknudson, yeah. If a user changes their password, we revoke all tokens for that user | 19:20 |
| *** gabriel-bezerra has joined #openstack-keystone | 19:21 | |
| *** Chicago has quit IRC | 19:24 | |
| bknudson | it does seem a little ridiculous to allow having a chain of tokens from tokens... not sure what the point would be | 19:27 |
| ayoung | bknudson, so you agree with what I wrote? | 19:32 |
| bknudson | ayoung: I agree that keystone should only allow creating a scoped token from an unscoped one. | 19:33 |
| ayoung | bknudson, and revoking an unscoped should revoke all of the scoped, but not the other way around? | 19:33 |
| *** ukalifon has quit IRC | 19:33 | |
| bknudson | ayoung: y, that makes sense | 19:33 |
| ayoung | bknudson, so, to avoid breaking things, first we need "explictly request unscoped" | 19:34 |
| morganfainberg | bknudson, ayoung, ++ | 19:34 |
| ayoung | https://review.openstack.org/#/c/109081/r | 19:34 |
| bknudson | ayoung: y, that's the part that's missing since you'll get a scoped token if you have a default project | 19:34 |
| bknudson | so if you have a default project then you couldn't ever rescope | 19:34 |
| ayoung | bknudson, and one we have that, I'll submit a patch to django-openstack-auth that consumes it | 19:34 |
| *** gokrokve has quit IRC | 19:35 | |
| ayoung | I'm working on that now | 19:35 |
| *** syedawaisali has quit IRC | 19:35 | |
| bknudson | seems like it has to continue to work with old keystones that don't support it | 19:35 |
| *** lbragstad has joined #openstack-keystone | 19:41 | |
| morganfainberg | bknudson, maybe thats a toggle in settings? | 19:45 |
| morganfainberg | bknudson, make juno+ horizon automatically set it | 19:45 |
| *** lbragstad has quit IRC | 19:45 | |
| bknudson | morganfainberg: y.. having a bunch of config options for backwards compat seems like the wrong way to handle everything | 19:45 |
| bknudson | what does keystone do now if you send "scope": {} ? | 19:46 |
| bknudson | or whatever we decide for how to request an unscoped token | 19:46 |
| morganfainberg | bknudson, not sure tbh, i think it does some magic on default_project? | 19:46 |
| morganfainberg | ayoung, has looked at that more recently | 19:46 |
| bknudson | I think that would be fine for backwards-compat... since the old server also supports rescoping a scoped token | 19:47 |
| ayoung | Good questions. If scope is none... | 19:48 |
| morganfainberg | bknudson, fairpoint | 19:51 |
| *** lbragstad has joined #openstack-keystone | 19:54 | |
| *** fish_ has quit IRC | 20:03 | |
| *** hrybacki has quit IRC | 20:06 | |
| *** gokrokve has joined #openstack-keystone | 20:06 | |
| *** AndChat|673521 has joined #openstack-keystone | 20:10 | |
| *** chandankumar has joined #openstack-keystone | 20:10 | |
| *** gokrokve has quit IRC | 20:11 | |
| *** gyee has joined #openstack-keystone | 20:12 | |
| *** chandankumar has quit IRC | 20:17 | |
| *** lbragstad has quit IRC | 20:18 | |
| *** lbragstad has joined #openstack-keystone | 20:19 | |
| *** marzif has joined #openstack-keystone | 20:19 | |
| openstackgerrit | A change was merged to openstack/keystone: cache the catalog https://review.openstack.org/108970 | 20:20 |
| dolphm | ayoung: did you ever email the list about the ldap thing in stable/havana? i just realized havana was security fixes only now | 20:25 |
| morganfainberg | dolphm, does the cache invalidation bit count as security-ish? | 20:25 |
| morganfainberg | dolphm, https://review.openstack.org/#/c/102692/ | 20:26 |
| morganfainberg | dolphm, because i'm perfectly happy to let those ones go. | 20:26 |
| *** gokrokve has joined #openstack-keystone | 20:26 | |
| morganfainberg | if they're not worth fixing/pushing to get in | 20:26 |
| dolphm | morganfainberg: good question... | 20:27 |
| dolphm | morganfainberg: that depends on a patch that i can't make a security argument for (that i can think of) | 20:27 |
| morganfainberg | it depends on the domains needing ot be enabled by default. | 20:27 |
| * morganfainberg shrugs, Havana is really close to EOL | 20:29 | |
| ayoung | dolphm, I had asked apevec to do so, but just realized he's on PTO | 20:30 |
| *** vhoward has left #openstack-keystone | 20:30 | |
| ayoung | dolphm, its OK if the answer is no, just means that RH carries the patch itself. We just have a policy that we need to submit upstream first | 20:30 |
| morganfainberg | ayoung, does RH mind carrying that one? because if not, i'd be inclined to say no [just so we don't need to argue about havana on the ML] | 20:31 |
| ayoung | morganfainberg, go ahead and say no. I think "security only" is a fine response | 20:32 |
| morganfainberg | ayoung, ++ works for me. | 20:32 |
| ayoung | nkinder, ^^ is that about right? | 20:32 |
| nkinder | I don't think there was a security reason. It's more a a problem for people trying to use AD with Keystone | 20:33 |
| *** amcrn_ has quit IRC | 20:34 | |
| ayoung | nkinder, yeah, and the Havana release is "Security fixes only" | 20:34 |
| ayoung | nkinder, So its really not appropriate for Havana | 20:34 |
| morganfainberg | nkinder, ayoung, this one right? https://review.openstack.org/#/c/93060/ | 20:36 |
| ayoung | morganfainberg, yep | 20:36 |
| *** lbragstad has quit IRC | 20:38 | |
| morganfainberg | ayoung, nkinder, tossed a -1 on there and link to the releases | 20:38 |
| *** lbragstad has joined #openstack-keystone | 20:38 | |
| morganfainberg | let me know if you need something else :) | 20:38 |
| *** jsavak has quit IRC | 20:46 | |
| *** mfainberg_phone has joined #openstack-keystone | 20:57 | |
| *** bobt has joined #openstack-keystone | 20:57 | |
| bknudson | we need to have a git repo for RH and IBM to put our common fixes that we want to carry | 20:59 |
| *** AndChat|673521 has quit IRC | 20:59 | |
| *** amcrn has joined #openstack-keystone | 21:02 | |
| bknudson | it looks like revocation events doesn't handle domain-scoped tokens correctly | 21:03 |
| *** mfainberg_phone has quit IRC | 21:05 | |
| *** amcrn has quit IRC | 21:08 | |
| *** hrybacki has joined #openstack-keystone | 21:08 | |
| ayoung | bknudson, its called RDO | 21:11 |
| ayoung | I raised the topic with some IBMers | 21:11 |
| ayoung | there was....resistance | 21:11 |
| ayoung | bknudson, if a domain is disabled, tokens are revoked if any of the domain values are unmatched | 21:12 |
| ayoung | this something in the code review? | 21:12 |
| bknudson | let me find the code | 21:13 |
| bknudson | ayoung: build_token_values: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/revoke/model.py#n267 | 21:14 |
| bknudson | for a project-scoped token, it adds token_values['project_id'] = project['id'] | 21:14 |
| bknudson | but for a domain-scoped token, build_token_value doesn't add token_values['domain_id'] = domain['id'] | 21:14 |
| bknudson | so the revocation code doesn't know if the token is domain-scoped | 21:14 |
| bknudson | doesn't the revocation code need to know that the token is domain-scoped like it needs to know that it's project-scoped? | 21:15 |
| bknudson | I tried just adding token_values['domain_id'] = domain['id'] but the revocation code still didn't find the domain-scoped token in the revocation events for some reason. | 21:16 |
| ayoung | bknudson, I think you are right. We actually test for it up in the tree, too | 21:17 |
| ayoung | _TOKEN_KEYS = ['identity_domain_id', | 21:17 |
| ayoung | 'assignment_domain_id', | 21:17 |
| *** topol has quit IRC | 21:17 | |
| bknudson | identity_domain_id is the user's domain ID from the token | 21:18 |
| bknudson | assignment_domain_id is the project's domain ID (if the token is project-scoped) | 21:18 |
| ayoung | bknudson, yep, I think you found a gap. Can we focus on getting it fixed in the client code? | 21:19 |
| ayoung | https://review.openstack.org/#/c/81166/ needs to go in, and I can put a fix on top of that | 21:19 |
| bknudson | ok, as long as it can be backported | 21:19 |
| ayoung | bknudson, yep | 21:21 |
| *** henrynash has quit IRC | 21:28 | |
| openstackgerrit | A change was merged to openstack/python-keystoneclient: Don't log sensitive auth data https://review.openstack.org/101792 | 21:30 |
| *** henrynash has joined #openstack-keystone | 21:31 | |
| *** henrynash has quit IRC | 21:32 | |
| bknudson | it looks like the revocation event model is a hierarchy of trust_id -> consumer_id -> access_token_id -> expires_at -> domain_id -> project_id -> user_id -> role_id -> issued_before | 21:38 |
| bknudson | but to handle domain-scoped tokens I think we'd need to have project_id OR domain_id there. | 21:39 |
| dolphm | bknudson: what's matt reidermann's nick? | 21:39 |
| bknudson | mriedem | 21:39 |
| bknudson | dolphm: also, he's left for the day | 21:39 |
| dolphm | bknudson: boo. i just realized we were both investigating the same bug | 21:40 |
| *** rwsu has quit IRC | 21:44 | |
| openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Trust unit tests should target additional threat scenarios https://review.openstack.org/109120 | 21:46 |
| bknudson | ok. I'm going to assume we don't have to handle domain-scoped tokens correctly since it's pretty much impossible. | 21:46 |
| bknudson | it should be easy to handle the case where the user has a domain-scoped token that's not the user's domain. | 21:47 |
| bknudson | I think I've got the change for that... | 21:47 |
| bknudson | but handling the case where the user has a domain-scoped token in their own domain is not doable... | 21:47 |
| bknudson | because of the mapping of 'domain_id': ['identity_domain_id', 'assignment_domain_id'] ... | 21:48 |
| bknudson | otherwise I think we'd need a new field in the revocation model and that requires a migration | 21:49 |
| *** lbragstad has quit IRC | 21:49 | |
| *** gordc has quit IRC | 21:52 | |
| *** nonameentername has joined #openstack-keystone | 21:53 | |
| ayoung | bknudson, handling the case where the user has a domain-scoped token in their own domain is doable | 21:55 |
| ayoung | that domain-scoped token would be assignment_domain_id | 21:56 |
| bknudson | ayoung: ah, good idea | 21:56 |
| nkinder | morganfainberg, jamielennox|away: now that https://review.openstack.org/#/c/101792/ is merged, what is the plan for a keystoneclient update that would include it? | 21:56 |
| *** radez is now known as radez_g0n3 | 22:00 | |
| *** lbragstad has joined #openstack-keystone | 22:01 | |
| *** henrynash has joined #openstack-keystone | 22:02 | |
| *** _afazekas is now known as afazekas | 22:03 | |
| dolphm | this would be great to help get people up and running with PKI, but i need a sanity check on the output redirecting https://review.openstack.org/#/c/51610/19/keystone/common/openssl.py | 22:04 |
| *** lbragsta_ has joined #openstack-keystone | 22:04 | |
| *** nonameentername has quit IRC | 22:04 | |
| david-lyle | time for the annoying Horizon developer to ask his keystone question of the day | 22:05 |
| david-lyle | can I rescope a project scoped token to a domain scoped token, or do I have to have the user log out and back in to get a domain scoped token? | 22:06 |
| *** lbragstad has quit IRC | 22:07 | |
| *** lbragsta_ has quit IRC | 22:08 | |
| *** dims_ has joined #openstack-keystone | 22:09 | |
| openstackgerrit | A change was merged to openstack/keystone: Disable a domain will revoke tokens under the same domain https://review.openstack.org/107194 | 22:09 |
| bknudson | david-lyle: I believe that you can do that rescoping currently | 22:10 |
| bknudson | david-lyle: although if ayoung gets his way it will not be allowed | 22:10 |
| david-lyle | bknudson: when I pass in the existing token id and a user_domain_id to the client (no project info) I just get a scoped token back to the project I was already scoped to | 22:11 |
| *** dims has quit IRC | 22:12 | |
| bknudson | david-lyle: I don't think that's requesting a domain-scoped token | 22:12 |
| david-lyle | if I then, trying to figure out the system call client.authenticate(domain_id=my_domain_id) I get "AuthorizationFailure: Authentication cannot be scoped to multiple targets. Pick one of: project, domain or trust" | 22:12 |
| bknudson | the user_domain_id is the domain for the user ... so if you pass in a user name you also need to supply the domain | 22:12 |
| david-lyle | so I have to use the domain name? | 22:13 |
| *** nkinder has quit IRC | 22:13 | |
| david-lyle | oh | 22:13 |
| bknudson | david-lyle: the call to do client.authenticate(domain_id=my_domain_id) is probably the way to do it. | 22:13 |
| david-lyle | I see a domain_id as well | 22:14 |
| bknudson | but where's the token? | 22:14 |
| ayoung | david-lyle, I'll answer in a moment...goal is to not log out. | 22:14 |
| david-lyle | ayoung: that's my hope too :) | 22:14 |
| *** dims_ has quit IRC | 22:16 | |
| *** marzif has quit IRC | 22:16 | |
| dolphm | ayoung: your spec to abandon REST altogether makes it tempting to abandon PKI completely | 22:17 |
| ayoung | dolphm, I think you misunderstand me if any of my specs come to abandoning rest. Which spec are you talking about? | 22:17 |
| dolphm | you can rename it to stateful-all-the-services if you'd like https://review.openstack.org/#/c/109295/ | 22:17 |
| *** lcheng has joined #openstack-keystone | 22:18 | |
| ayoung | dolphm, that is a way to formalize what Horizon is doing, but I do not agree that it is anti REST. | 22:19 |
| ayoung | they don't need to use it if they don't want to. The Swift folks were complaining about token size, and I mentioned this solution to them. It still keeps the service from going back to keystone. | 22:20 |
| dolphm | ayoung: well its a great argument in favor of UUID | 22:20 |
| ayoung | david-lyle, the idea for unscoped is this: user logs in with userid and password, gets unscoped token that is small enough to stick in a cookie as is. | 22:20 |
| david-lyle | ayoung, so I keep the unscoped and the scoped token around? | 22:21 |
| ayoung | dolphm, think through that statement and I think you will see it falls down on a number of counts. Add in a "same origin" mechanism to go along with this | 22:21 |
| ayoung | david-lyle, yep | 22:21 |
| david-lyle | ok | 22:21 |
| ayoung | the unscoped stays in the cookie, and is used whenever the user rescopes | 22:22 |
| david-lyle | what's another token amongst friends | 22:22 |
| ayoung | the scoped tokens are going to be bigger, say 4K, andwill be stored in memcached | 22:22 |
| ayoung | david-lyle, so to rescope, use the unscoped tokenm | 22:22 |
| ayoung | david-lyle, I'm pushing for more mechanisms than just that | 22:22 |
| ayoung | https://blueprints.launchpad.net/keystone/+spec/session-extendable-tokens david-lyle | 22:23 |
| ayoung | david-lyle, that would be just the unscoped token | 22:23 |
| david-lyle | ayoung, if I use the unscoped token for rescoping, don't I end up with just a scoped token? or does the unscoped remain valid as well? | 22:25 |
| ayoung | david-lyle, the unscoped remains valid | 22:25 |
| david-lyle | and that works now? | 22:26 |
| ayoung | david-lyle, it is Horizon that revokes the tokens, so, there would be no reason to revoke the unscoped | 22:26 |
| david-lyle | ok | 22:26 |
| david-lyle | stupid horizon | 22:26 |
| *** nkinder has joined #openstack-keystone | 22:26 | |
| ayoung | david-lyle, I'm working on code for django-openstack-auth right now | 22:26 |
| david-lyle | me too :) | 22:26 |
| david-lyle | ayoung, yours is probably further than mine given our exchange :) | 22:27 |
| ayoung | david-lyle, the first change is making d-o-a use Keystone sessions | 22:27 |
| ayoung | as part of that, it will store the "unscoped" token...but there is no guarantee you will get an unscoped token today | 22:28 |
| morganfainberg | dolphm, maybe the answer is UUID tokens, but uuid tokens + revocation events + memcache (or redis, or something) | 22:30 |
| morganfainberg | dolphm, where keystone injects the token data into the "in-cloud" service, and auth_token goes directly to that service to rtrieve the information (cms signed or not), instead of asking keystone for the data | 22:30 |
| morganfainberg | dolphm, i *think* amazon does something like that for their credentials | 22:31 |
| morganfainberg | ayoung, ^ | 22:34 |
| morganfainberg | dolphm, re: https://review.openstack.org/#/c/107561/ this is going to need a rebase, we just merged something to token.core | 22:35 |
| ayoung | morganfainberg, that is basically it. | 22:35 |
| morganfainberg | dolphm, going to rebase it in a few moments. | 22:35 |
| morganfainberg | ayoung, so why make auth_token do the work, just make keystone inject it and hand off the short-value | 22:35 |
| ayoung | except that the user sends the data as the mule | 22:35 |
| morganfainberg | ayoung, it seems odd to hand the tokent o the user and only benefit the requests beyond the first | 22:35 |
| morganfainberg | ayoung, i mean, i *think* UUID tokens were trying to do some of that but without the need for an external service that the endpoints can query directly | 22:36 |
| ayoung | morganfainberg, many ways to skin this cat, but the biggest one is that everything happens in the open | 22:36 |
| ayoung | giving it to the user scales better | 22:36 |
| ayoung | otherwise the user needs to tell keystone ahead of time where to create tokens, and needs to go back there for new operations | 22:37 |
| morganfainberg | ayoung, i'd argue minimally at best | 22:37 |
| morganfainberg | no, i mean you have keystone inject the tokens where the endpoints will ask for them | 22:37 |
| morganfainberg | chances are you're not running a memcache server on each endpoint | 22:38 |
| ayoung | morganfainberg, I need to take care of something right now. Think about it. I suspect you will convince yourself that the current architecture is correct. The cookie proposal is an optimization | 22:38 |
| dstanek | ha, back to this fun? | 22:39 |
| morganfainberg | ayoung, i jsut spent 15 minutes thinking about it, i'll let you convince me when you're back, because i'm not seeing it at the moment (table the discussion till a bit later) | 22:39 |
| morganfainberg | dstanek, maybe >.> :P | 22:40 |
| * morganfainberg is tempted to POC this up. | 22:41 | |
| * morganfainberg has some free dreamhost cloud stuffs | 22:41 | |
| *** dims_ has joined #openstack-keystone | 22:42 | |
| *** dims_ has quit IRC | 22:47 | |
| openstackgerrit | A change was merged to openstack/keystone: Add the new oslo.i18n as a dependency for Python 3 https://review.openstack.org/108810 | 22:49 |
| *** fish_ has joined #openstack-keystone | 22:56 | |
| openstackgerrit | A change was merged to openstack/keystone-specs: Explicity request an unscoped token https://review.openstack.org/108071 | 22:58 |
| morganfainberg | henrynash, running tests befor epushing that rebase up | 23:01 |
| morganfainberg | henrynash, added to the comment so it's clear why we clear the kvs registry | 23:01 |
| henrynash | morganfainberg: ok, great | 23:01 |
| *** nkinder has quit IRC | 23:01 | |
| *** jamielennox|away is now known as jamielennox | 23:01 | |
| henrynash | morganfainberg: will +2 once up | 23:01 |
| morganfainberg | henrynash, ++ :) | 23:01 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module https://review.openstack.org/107561 | 23:04 |
| jamielennox | gerrit login now sends you via ubuntu one? | 23:04 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Add the new Keystone TokenModel https://review.openstack.org/106917 | 23:05 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Make token_provider_api contain token persistence https://review.openstack.org/109041 | 23:05 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove assignment controller dependency on token_api https://review.openstack.org/109162 | 23:08 |
| jamielennox | gyee: i don't think version discovery would be affected at all by a catalog in an unscoped token | 23:09 |
| jamielennox | gyee: we don't generally do discovery for auth yet | 23:09 |
| gyee | jamielennox, so today, if user specify an auth_url, we do version discovery first | 23:10 |
| jamielennox | gyee: depends what you're using | 23:10 |
| gyee | keystoneclient? | 23:10 |
| jamielennox | keystoneclient.client.Client does | 23:10 |
| jamielennox | neither v2.Client or v3.Client do | 23:10 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Remove ec2 contrib dependency on token_api https://review.openstack.org/109173 | 23:10 |
| gyee | will we do that in the future? | 23:11 |
| gyee | I mean will it be part of standard auth flow | 23:11 |
| jamielennox | gyee: plugins like https://review.openstack.org/#/c/81147/ will | 23:11 |
| jamielennox | but i think they are often going to be the special case | 23:12 |
| gyee | jamielennox, so if discovery is done, you already have the url right, which is the same for both auth and management | 23:15 |
| gyee | I mean the base url is the same | 23:15 |
| jamielennox | could be - could not be, management url is generally the admin interface | 23:16 |
| jamielennox | which may or may not be the same as your auth | 23:16 |
| gyee | but I can't specify an auth url like this and have discovery return me something else right? http://host:35357/v3/auth/kerberos | 23:18 |
| gyee | obviously that's not for discovery | 23:18 |
| *** david-lyle has quit IRC | 23:19 | |
| gyee | so auth_url has to be a base URL | 23:20 |
| *** gabriel-bezerra has quit IRC | 23:20 | |
| *** gabriel-bezerra has joined #openstack-keystone | 23:20 | |
| jamielennox | gyee: so the whole non-standard route is an interesting concept that is not my main reason | 23:21 |
| jamielennox | because you don't specify /auth/kerberos as a auth_url | 23:21 |
| jamielennox | you specify /v3 and let it build it for you | 23:21 |
| ayoung | morganfainberg, with Kerberos or X.509 Authentication, there really is no reason to go to Keystone first. The user could go straight to Nova, and authenticate, then Nova would query the Authorization source. This is how things are typically done in the enterprise, with the authZ source being LDAP. Its one reason enterprises don't worrry about revoking Kerberos tickets: | 23:21 |
| jamielennox | if you want that to work you need to mount at like /kerberos/v3/ | 23:21 |
| ayoung | your authentication is never revoked, just your authorization | 23:21 |
| morganfainberg | ayoung, uhm. why are we bypassing keystone with x509 and kerberos? | 23:22 |
| morganfainberg | ayoung, don't we still need a token? | 23:22 |
| * morganfainberg is missing something. | 23:22 | |
| ayoung | morganfainberg, for that approach, no we would not | 23:22 |
| ayoung | so why do we even need keystone? | 23:22 |
| morganfainberg | ayoung, i agree, lets delete the service | 23:22 |
| gyee | :) | 23:22 |
| ayoung | And the answer is to add a layer of distributed authorization for openstack | 23:22 |
| * gyee thinking one of y'all is smoking something | 23:23 | |
| ayoung | see, if you go to LDAP, and LDAP is read only, you have no way to add your own authorization data | 23:23 |
| ayoung | With Keystone, we allo a middle ground; each service endpoint enforces its own policy, but the set of roles are OpenStack specific, and layered on top of authentication from some other service. | 23:24 |
| gyee | jamielennox, my point is the auth_url is a base url | 23:24 |
| ayoung | SAML and OpenID are attempting to solve the same problem, but they each have different short comings | 23:24 |
| ayoung | SAML is that it is issued by the IdP, and so you have no additional authorization attributes | 23:24 |
| ayoung | But we could have implemented keystone as SAML, and it would have made sense | 23:25 |
| ayoung | OpenID the problem is that there is no standard format for providing the authorization data. | 23:25 |
| morganfainberg | ayoung, i am now totallt lost how we ended up off in these weeds | 23:25 |
| ayoung | So, why do I insist that Keystone tokens are carried by the user? | 23:25 |
| ayoung | Look at the arguments for the OpenID and SAML approachs. | 23:26 |
| morganfainberg | both authn not authz (really) approaches. | 23:26 |
| ayoung | Both are desigend such that the Service does not need to know where the token will be used. Note that this is different from saying "cannot know" | 23:26 |
| ayoung | Er , where I said openID I should have said Oauth | 23:27 |
| *** gabriel-bezerra has quit IRC | 23:27 | |
| ayoung | I've OPenID on the brain due to launchpad | 23:27 |
| ayoung | morganfainberg, if it is backchannel, as you suggested, then a keystone server needs to know everywhere a token can and will be used up front. | 23:28 |
| *** gabriel-bezerra has joined #openstack-keystone | 23:28 | |
| ayoung | Now, you might argue with Token Binding to endpoints, that is exactly where we are headed. | 23:28 |
| ayoung | But I see that as a hardening, not a fundamental part of Keystone | 23:28 |
| gyee | jamielennox, the argument for service catalog for unscoped token is to get the management url right? but it is the same as the base_url | 23:29 |
| ayoung | With the K2K blueprint, we have the potential for something even wider, a distributed system with no backchannel | 23:29 |
| morganfainberg | ayoung, no actually i'm going to argue it is likely not going to *solve* the issue of reducing network traffic because you're *still* sending the 1,7k or 10k or <insert size of token> to the endpoint. | 23:29 |
| morganfainberg | ayoung, and tokens are meant to be *very* short lived [future talking] | 23:29 |
| morganfainberg | so the caching of the data is at best, minimal scaling benefit without solving the issue people are complaining about | 23:29 |
| morganfainberg | and using the cookie-model for looking up the cache | 23:29 |
| morganfainberg | if people really only want UUID tokens we should provide those not something that sort-of-behaves like them after the first request | 23:30 |
| ayoung | morganfainberg, an ethernet frame is 1K. Adding a token to a request at most adds a small handful of ethernet frames to the round trip. Doing an online token validation reuquires multiple round trips. | 23:30 |
| ayoung | morganfainberg, we'll be back to token being bearer tokens, with only admin users being able to validate. | 23:32 |
| morganfainberg | ayoung, i'm really not buying this. | 23:32 |
| morganfainberg | ayoung, sorry. | 23:32 |
| ayoung | No way to do ephemeral, no way for a non-privildeged user to validate | 23:32 |
| ayoung | no way to share tokens between untrusted sources | 23:32 |
| jamielennox | gyee: the argument for unscoped catalogs is to make the workflow less awkward when you're sometimes dealing with scoped tokens and sometimes dealing with unscoped and you have to go and figure out which | 23:32 |
| ayoung | A UUID token is the complete keys to the kingdon | 23:32 |
| morganfainberg | ayoung, and you're *not* really solving the complaint with your new cookie system | 23:33 |
| ayoung | cookies are an incremental optimization | 23:33 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Expose token revocation list via token_provider_api https://review.openstack.org/109170 | 23:33 |
| *** richm has quit IRC | 23:34 | |
| morganfainberg | ayoung, only sortof | 23:34 |
| morganfainberg | ayoung, it's not even a *good* optimisation afaict | 23:34 |
| ayoung | morganfainberg, cookies are between client and server only. Add on a form of "same source" lock down and there is no additional exposure | 23:34 |
| ayoung | morganfainberg, it is what most websites do already | 23:34 |
| jamielennox | is this the 'session tokens' thing? i though morganfainberg agreed with that one? | 23:34 |
| morganfainberg | jamielennox, no this is the cookie hashing thing the endpoint does | 23:35 |
| ayoung | when you do user-id/password auth (or Kerberos for that matter) it caches the authentication and issues you a session cookie | 23:35 |
| morganfainberg | then you keep using that cookie to talk to the endpoint | 23:35 |
| ayoung | https://review.openstack.org/#/c/109295/ jamielennox | 23:35 |
| jamielennox | i have not heard of this concept... | 23:35 |
| ayoung | morganfainberg, SAML and Oauth are built on that mechanism already | 23:36 |
| morganfainberg | ayoung, not really | 23:36 |
| ayoung | morganfainberg, yes really | 23:36 |
| morganfainberg | ayoung, no, not really | 23:36 |
| gyee | jamielennox, I am arguing you don't need to, you can always use the base url | 23:36 |
| ayoung | you don;t send the authorization data more than once | 23:36 |
| ayoung | after that it is cookied | 23:36 |
| *** ncoghlan_afk is now known as ncoghlan | 23:37 | |
| morganfainberg | ayoung, except... you would ask the original source each time you go to an endpoint *anyway* | 23:37 |
| ayoung | nope | 23:37 |
| morganfainberg | ayoung, a new endpoint, sorry | 23:38 |
| ayoung | you go to gerrit, and it redirects yo to laucnpad | 23:38 |
| ayoung | that is good for a while | 23:38 |
| morganfainberg | ayoung, you wouldn't use the same assertion on site XYZ and ZZZ | 23:38 |
| jamielennox | ayoung: sorry it just sounds kind of complicated and with not a lot of value | 23:38 |
| morganfainberg | you're arguing i login to gerrit via LP, then i go to wiki.openstack.org and don't need to login again | 23:38 |
| ayoung | jamielennox, It was a response to the Swift folks comlaining about the size of the tokens. Instead of telling them to Hash and hit keystone, they can cache for additional round trips | 23:39 |
| morganfainberg | but my auth data is already there | 23:39 |
| jamielennox | given that UUID tokens are memcached anyway it just seems like if this is a problem you should use uuids | 23:39 |
| morganfainberg | that isn't how those work | 23:39 |
| morganfainberg | i would need to login again at wiki.openstack.org, then it's a cookie i can use there. | 23:39 |
| ayoung | morganfainberg, no, I'm arguing that after you go to wiki.openstack.org and hand over your launchpad oauth token, wiki. sets a session cookie | 23:39 |
| ayoung | jamielennox, yes, it is using UUIDs, but the UUIDs would be generated by the service, and would not be usable on any other service | 23:40 |
| ayoung | that is a hell of a lot more secure than handing around a UUID token to ever one | 23:40 |
| morganfainberg | ayoung, i'm really not convinced this is solving the issue. | 23:40 |
| jamielennox | ayoung: yea, i see what you're trying to do | 23:40 |
| *** alex_xu has quit IRC | 23:41 | |
| ayoung | morganfainberg, I'm in no rush to implement that Blueprint, but if the question comes up, I have it to point to, and we can battle it out until then | 23:41 |
| ayoung | OK< family dinner time. | 23:42 |
| *** ayoung is now known as ayoung-food | 23:42 | |
| *** arun_kant has quit IRC | 23:42 | |
| *** dims_ has joined #openstack-keystone | 23:43 | |
| jamielennox | it's an interesting idea | 23:44 |
| *** oomichi has joined #openstack-keystone | 23:45 | |
| jamielennox | it means you would need an auth URL on every service? | 23:45 |
| *** dims_ has quit IRC | 23:47 | |
| jamielennox | i'm just not sure if we add another round trip if it's worth it for token size | 23:48 |
| morganfainberg | jamielennox, i have a few other thoughts on what can be done. | 23:49 |
| jamielennox | i've also got no idea how you would go about easing it in | 23:49 |
| morganfainberg | jamielennox, but i need to actually do a POC of them. | 23:49 |
| gyee | if discovery is going to be a permanent fixture, you'll always get back a base url anyway | 23:49 |
| morganfainberg | oh phew it's only 5. thought i missed an appointment | 23:50 |
| gyee | even JSON home have the base URL I think | 23:50 |
| * morganfainberg has been staring at too much token code | 23:50 | |
| morganfainberg | oh crap, i needed to bug marekd and stevemar today | 23:50 |
| stevemar | morganfainberg, bug me in a few hours? | 23:50 |
| morganfainberg | stevemar, sure, like ... uh... in like ~4hrs? | 23:51 |
| jamielennox | gyee: yes you'll get a base url back from discovery | 23:51 |
| stevemar | morganfainberg, that works for me | 23:51 |
| morganfainberg | or 3.5 | 23:51 |
| jamielennox | gyee: essentially my problem comes from the way that the client is structured i guess | 23:51 |
| morganfainberg | stevemar, it's about saml auth plugin...and that we have a custom-token format for it | 23:51 |
| morganfainberg | stevemar, so... be prepared :P | 23:51 |
| gyee | jamielennox, I totally understand the problem | 23:52 |
| jamielennox | it can make sense to re-use the auth_url if you called like auth_plugin.list_projects() - which is something i'm considering | 23:52 |
| jamielennox | the way the client is structured now is very indifferent to whether you have a scoped token or not - for 90% of calls it just fails if you don't have a scope | 23:53 |
| jamielennox | given that layout it would help things along a lot if the tokens were more similar - and i don't see any reason you shouldn't have the catalog there | 23:54 |
| gyee | changing protocol to accomplish code structure seem like a bad tradeoff though | 23:55 |
| gyee | s/accomplish/accompany/ | 23:55 |
| jamielennox | sure but to my thinking it really should always have been there | 23:55 |
| jamielennox | i mean the catalog is the list of services this token can interact with | 23:56 |
| gyee | first thing we need to figure out is a consistent flow | 23:56 |
| jamielennox | and the list of services that an unscoped token can interact with is keystone | 23:56 |
| stevemar | morganfainberg, go on... | 23:56 |
| morganfainberg | stevemar, you said in a couple hours! :P | 23:56 |
| morganfainberg | stevemar, >.> | 23:56 |
| gyee | jamielennox, from a purest standpoint, you are absolutely right, there's no unscoped token | 23:57 |
| morganfainberg | stevemar, i've got plenty to do between now and then if you're busy (or can even be tomorow) | 23:57 |
| gyee | an unscoped token is implicitly scoped to keystone | 23:57 |
| gyee | but since you already have the base url to begin with, there's no need to reconstruct it | 23:58 |
| jamielennox | gyee: ++, IMO service scoped tokens are something that is coming - an unscoped token is simply a keystone scoped token | 23:58 |
| morganfainberg | jamielennox, ++ | 23:58 |
| gyee | oh I am all for service-scoped token | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!