*** pheadron has quit IRC | 00:51 | |
*** ncoghlan has joined #openstack-keystone | 00:52 | |
*** topol has joined #openstack-keystone | 00:57 | |
*** bknudson has left #openstack-keystone | 01:01 | |
*** ayoung-ZZzz is now known as ayoung | 01:08 | |
*** pheadron has joined #openstack-keystone | 01:09 | |
ayoung | jamielennox, I was thinking that we should probably keepo the "kerberos" Client plugin setting the "methdo" value to "external" as that way it works with the existing documentation we've been writing about Kerberos. The people that will want it the most are the people with existing kerberos setups | 01:09 |
---|---|---|
ayoung | and they will not have the flexibility to upgrade Keystone to use "kerberos" as the method in the short run | 01:09 |
jamielennox | ayoung: so at what point do we move away from 'external'? | 01:09 |
ayoung | Never? | 01:10 |
ayoung | If we ever decide to push for a Kerberos in Eventlet solution?> | 01:10 |
ayoung | Which I don't want to do, and Jose is OK with putting off? | 01:10 |
jamielennox | ayoung: the people who currently have kerberos working aren't using the 'external' method anyway - because external is run regardless of the information in the auth body | 01:11 |
ayoung | jamielennox, they don't have client support at all, or only custom | 01:11 |
jamielennox | right - but we aren't changing them too 'kerberos', the people with the current setup won't change | 01:11 |
jamielennox | we're saying for new deployments you should enable the kerberos plugin | 01:12 |
jamielennox | which will be exactly the same as the basic auth plugin if that ever happens | 01:12 |
ayoung | jamielennox, what I am saying is that we need kerberos support in the client, and we need it soon | 01:12 |
ayoung | so you think we should push for that? | 01:12 |
ayoung | method=kerberos? | 01:13 |
jamielennox | yes | 01:13 |
ayoung | https://review.openstack.org/#/c/95989/ | 01:13 |
jamielennox | ayoung: cool, i think you should assert AuthType == 'Negotiate' | 01:15 |
ayoung | Interesting. THat comes through in the env vars, I take it? | 01:15 |
jamielennox | yes | 01:15 |
jamielennox | AUTH_TYPE i think | 01:16 |
jamielennox | and we are saying there that KerberosDomain will be a plugin listed with the others - not external=KerberosDomain | 01:16 |
jamielennox | ie token,password,kerberos,external | 01:17 |
ayoung | ? | 01:17 |
ayoung | jamielennox, ah, yes...please annotate all in the review. | 01:17 |
ayoung | I'll redo it tomorrow. | 01:17 |
jamielennox | cool, sounds good | 01:18 |
jamielennox | ayoung: in future i like the idea of a 'landing page' for everything that doesn't go through the standard /auth/token URL so that kerberos would be more like the federated plugins - but this is a good step | 01:19 |
ayoung | jamielennox, so...I was also thinking about trying to pull the auth stuff out of the existing past pipeline and put it in its own...not sure what that would take. | 01:21 |
*** xianghui has joined #openstack-keystone | 01:22 | |
jamielennox | out of paste? | 01:22 |
ayoung | It might be that we need to have a paste pipeline for each of the modules | 01:22 |
ayoung | no leave it in past, just its own pipeline | 01:22 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n88 | 01:22 |
jamielennox | i've definetly heard this concept before - in theory i like it | 01:23 |
ayoung | instead of that going to /auth/token you would have a separate pipeline, and it could be how we throw different things in there | 01:23 |
ayoung | I have to learn more about paste. | 01:23 |
jamielennox | so i agree with morganfainberg that we should move /v3/auth/token so that it's not /v3 and we can seperate crud API version from token API version | 01:23 |
ayoung | I would like to take the standard pipeline filters and make on reusuable config for them, | 01:23 |
jamielennox | and once you've done that a new paste pipeline becomes easier | 01:23 |
ayoung | so AUTH_URL can point to anything...doesn't have to have /v3 in it? | 01:24 |
jamielennox | so we can do like keystone:5000/auth/v4 and keystone:5000/v3/users | 01:24 |
jamielennox | you can already mix and match token versions with API versions, so we make them two seperate things | 01:25 |
ayoung | jamielennox, so we can vary the API for /auth /user and so forth...hmmm | 01:25 |
ayoung | should be top level modules | 01:25 |
jamielennox | ayoung: not users | 01:25 |
jamielennox | users is still a v3 concept | 01:26 |
ayoung | like this /auth /identity /assignment /policy | 01:26 |
ayoung | ? | 01:26 |
jamielennox | it's just extracting the token producing part of the code into it's own top level | 01:26 |
ayoung | jamielennox, what would be the new set of "top levels" then? | 01:26 |
jamielennox | such that we can have a new token format without having to redo our entire CRUD UI | 01:26 |
jamielennox | v2 v3 auth i guess, it would depend on what you need to do as to whether auth/v2 and auth/v3 would need there own pipelines | 01:27 |
jamielennox | the word /auth may not be used | 01:28 |
ayoung | jamielennox, I'm already on board that the AUTH_URL might be its own thing...cuz you would want to protect it separately in HTTPD. But you'd still want v3 and v4 together, I' guessing | 01:30 |
ayoung | It would be decent if we could figure out a way to get the V3 pieces to work along with that scheme | 01:31 |
ayoung | it should be possible | 01:31 |
jamielennox | ayoung: yea not sure, i'd have to see it in practice | 01:31 |
ayoung | I mean, there is no reason the same thing can't be mounted under :35357/v3 and :35357/identity | 01:32 |
ayoung | have you messed around with that JSON HOME approach yet? | 01:32 |
jamielennox | ayoung: no, i don't have any particular interest in that one yet | 01:33 |
jamielennox | ayoung: it doesn't give us any new information over what we already expose, it's just another new format | 01:34 |
jamielennox | and there's still been no official adoption of it yet - just a project or two using it | 01:34 |
ayoung | It was my understanding that it gives us discovery from the top down? | 01:34 |
jamielennox | we could have worked that into our existing discovery | 01:34 |
jamielennox | it's been a while since i looked | 01:34 |
jamielennox | but i don't remember it giving us resources etc | 01:35 |
jamielennox | oh it does - that's cool | 01:35 |
ayoung | yeah, that seems to be the primary thing it does | 01:36 |
jamielennox | but i still haven't looked at it, there's enough formats i'm fighting with already | 01:36 |
ayoung | yeah...same here. I'm mostly working on getting the Kerberization of Horizon kicked off... had some success with S4U2Proxy last week. | 01:37 |
jamielennox | hmm, that will be cool - there are no python libraries or anything for it, i don't know how to work it in but that should be interesting | 01:38 |
jamielennox | pecan will be cool there | 01:39 |
jamielennox | ayoung: as in it will work without co-locating keystone and horizon? | 01:42 |
ayoung | right, you log in to horizon, and then horizon talks to a remote keystone | 01:44 |
ayoung | horizon uses your service ticket, and its own keytab, to get a service ticket against keystone on your behalf | 01:44 |
ayoung | very similar to the rule of trusts. | 01:45 |
jamielennox | excellent, i just know you had talked about simplifying the interaction as a first step | 01:46 |
ayoung | jamielennox, so I need a keystoneclient that I can stick into horizon. I'm using a modified one right now for coding and testing | 01:46 |
jamielennox | ok, that's why you're pushing this kerberos auth then | 01:46 |
ayoung | but looks like we'll need to upgrade the appraoch in Keystone, which is cool | 01:47 |
ayoung | yeah, just want to make sure we have a coherent approach | 01:47 |
ayoung | I'm OK waiting for the Kerberos change in Keystone to go through, just want to make sure it is a deliberate decision | 01:47 |
ayoung | and not "oh, though would be nice" | 01:47 |
ayoung | jamielennox, I posted about hte S4U2 Proxy on my blog last week. Its pretty straightforward, but it does lead to some questions about Horizon in the Non Kerberos cases...like SAML | 01:49 |
ayoung | http://adam.younglogic.com/2014/05/kerberos-federation-and-horizon/ | 01:49 |
ayoung | LIke: If I use SAML, and end up at Horizon, can horizon take the SAML assertion and forward it to Kerberos with any degree of actual security? | 01:50 |
ayoung | And what about if they are using X509 Client certs instead of Kerberos? What is the delegation story there? | 01:50 |
*** stevemar has joined #openstack-keystone | 01:56 | |
*** dims has quit IRC | 01:57 | |
*** diegows has quit IRC | 01:59 | |
*** dims has joined #openstack-keystone | 01:59 | |
*** dims has quit IRC | 02:00 | |
ayoung | jamielennox, BTW... https://github.com/admiyo/keystone-examples | 02:02 |
jamielennox | ayoung: oh, nice - i've had a bunch of little scripts i've thought i should put somewhere | 02:02 |
ayoung | Give em to me, I'll post em | 02:08 |
ayoung | Or clone my repo and we can share them....git hub is perfect for that | 02:09 |
ayoung | jamielennox, yeah, lets start using git hub for that... | 02:10 |
ayoung | I think its the right level tool for the goal: | 02:10 |
*** Chicago has quit IRC | 02:14 | |
*** ayoung is now known as ayoung-ZZzz | 02:16 | |
*** stevemar has quit IRC | 02:22 | |
*** stevemar has joined #openstack-keystone | 02:22 | |
*** ncoghlan is now known as ncoghlan_afk | 02:24 | |
*** dstanek_zzz is now known as dstanek | 02:25 | |
*** ncoghlan_afk is now known as ncoghlan | 02:46 | |
*** mberlin1 has joined #openstack-keystone | 02:54 | |
*** ncoghlan is now known as ncoghlan_afk | 02:57 | |
*** mberlin has quit IRC | 02:57 | |
*** gokrokve has joined #openstack-keystone | 03:09 | |
*** gokrokve has quit IRC | 03:14 | |
*** stevemar has quit IRC | 03:18 | |
*** lbragstad has joined #openstack-keystone | 03:23 | |
*** harlowja_ is now known as harlowja_away | 03:47 | |
*** dstanek is now known as dstanek_zzz | 03:49 | |
*** zhiyan_ is now known as zhiyan | 03:54 | |
*** henrynash has joined #openstack-keystone | 04:20 | |
*** ncoghlan_afk is now known as ncoghlan | 04:36 | |
*** gokrokve has joined #openstack-keystone | 04:41 | |
openstackgerrit | Brad Topol proposed a change to openstack/keystone: Add instructions for removing pyc files to docs https://review.openstack.org/97140 | 04:43 |
*** Abhijeet has joined #openstack-keystone | 04:56 | |
morganfainberg | topol, shouldn't you be asleep or something? :P | 04:57 |
topol | morganfanberg, this is my quiet get to have fun time. | 04:59 |
morganfainberg | topol, you want to review code for me while you're at it? sometimes i question my sanity when i commit to reviewing code over the weekend | 05:00 |
topol | morganfainberg, sure | 05:00 |
* morganfainberg smirks. | 05:01 | |
*** ncoghlan is now known as ncoghlan_afk | 05:03 | |
*** ncoghlan_afk is now known as ncoghlan | 05:03 | |
*** gokrokve has quit IRC | 05:06 | |
*** ajayaa has joined #openstack-keystone | 05:17 | |
openstackgerrit | Brad Topol proposed a change to openstack/keystone: Add cloud auditing notification documentation https://review.openstack.org/97146 | 05:42 |
topol | morganfainberg, I feel like a contributor again... Im going to bed | 05:43 |
morganfainberg | hehe | 05:43 |
morganfainberg | night dude | 05:43 |
*** topol has quit IRC | 05:49 | |
*** leseb has joined #openstack-keystone | 05:49 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/97005 | 06:00 |
*** leseb has quit IRC | 06:09 | |
ajayaa | Hi. When I do os endpoint list I don't see endpoint with v3 address. But I am able to call v3 api | 06:10 |
ajayaa | Is it expected behaviour? | 06:11 |
*** leseb has joined #openstack-keystone | 06:13 | |
*** jimbaker has quit IRC | 06:17 | |
*** tomoiaga has joined #openstack-keystone | 06:38 | |
*** afazekas has quit IRC | 06:49 | |
openstackgerrit | Andreas Jaeger proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/97005 | 07:03 |
*** leseb has quit IRC | 07:04 | |
*** leseb has joined #openstack-keystone | 07:05 | |
*** praneshp has joined #openstack-keystone | 07:06 | |
*** BAKfr has joined #openstack-keystone | 07:16 | |
marekd | mhu: hello. IN your PoC are you lookin at OpenID 2.0 or OpenID Connect protocol? | 07:32 |
marekd | mhu: I think OpenId 2.0 was superseded by OpenId Connect. | 07:33 |
*** ncoghlan is now known as ncoghlan_afk | 07:40 | |
*** ncoghlan_afk is now known as ncoghlan | 07:43 | |
*** toddnni has quit IRC | 07:46 | |
*** toddnni has joined #openstack-keystone | 07:46 | |
*** nsquare has quit IRC | 07:47 | |
*** huats has quit IRC | 07:48 | |
*** huats has joined #openstack-keystone | 07:49 | |
*** huats has quit IRC | 07:49 | |
*** huats has joined #openstack-keystone | 07:49 | |
*** jaosorior has joined #openstack-keystone | 07:50 | |
*** leseb has quit IRC | 07:53 | |
*** leseb has joined #openstack-keystone | 08:01 | |
openstackgerrit | Marcos Fermín Lobo proposed a change to openstack/keystone: Add information regarding HTTPS for SSL enabled endpoints https://review.openstack.org/95545 | 08:05 |
*** ncoghlan has quit IRC | 08:06 | |
*** florentflament has joined #openstack-keystone | 08:21 | |
*** _afazekas has joined #openstack-keystone | 08:24 | |
-openstackstatus- NOTICE: setuptools upstream has broken the world. it's a known issue. we're hoping that a solution materializes soon | 08:31 | |
*** ChanServ changes topic to "setuptools upstream has broken the world. it's a known issue. we're hoping that a solution materializes soon" | 08:31 | |
*** _afazekas is now known as afazekas | 08:36 | |
*** leseb has quit IRC | 08:36 | |
*** andreaf has joined #openstack-keystone | 08:37 | |
*** leseb has joined #openstack-keystone | 08:41 | |
openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 08:44 |
*** leseb_ has joined #openstack-keystone | 08:51 | |
*** leseb has quit IRC | 08:51 | |
*** henrynash has quit IRC | 08:59 | |
*** praneshp has quit IRC | 09:16 | |
*** ajayaa has quit IRC | 10:12 | |
*** leseb_ has quit IRC | 10:24 | |
*** ajayaa has joined #openstack-keystone | 10:36 | |
*** ajayaa has quit IRC | 10:42 | |
*** leseb has joined #openstack-keystone | 10:46 | |
*** leseb has quit IRC | 10:57 | |
*** ukalifon1 has joined #openstack-keystone | 11:01 | |
*** leseb has joined #openstack-keystone | 11:09 | |
*** ukalifon1 has quit IRC | 11:11 | |
*** zhiyan is now known as zhiyan_ | 11:19 | |
*** zhiyan_ is now known as zhiyan | 11:20 | |
*** diegows has joined #openstack-keystone | 11:27 | |
*** hrybacki has quit IRC | 11:27 | |
*** ajayaa has joined #openstack-keystone | 11:32 | |
*** henrynash has joined #openstack-keystone | 11:39 | |
*** Abhijeet has quit IRC | 11:41 | |
*** leseb has quit IRC | 11:43 | |
*** leseb has joined #openstack-keystone | 11:51 | |
*** erecio has joined #openstack-keystone | 12:10 | |
*** dims has joined #openstack-keystone | 12:12 | |
*** xianghui has quit IRC | 12:13 | |
*** tomoiaga1 has joined #openstack-keystone | 12:14 | |
*** tomoiaga has quit IRC | 12:14 | |
*** tomoiaga1 is now known as tomoiaga | 12:16 | |
*** dims has quit IRC | 12:23 | |
*** gordc has joined #openstack-keystone | 12:27 | |
*** henrynash has quit IRC | 12:28 | |
*** hrybacki has joined #openstack-keystone | 12:28 | |
*** dims has joined #openstack-keystone | 12:30 | |
*** dims has quit IRC | 12:32 | |
*** dims has joined #openstack-keystone | 12:32 | |
*** rodrigods has joined #openstack-keystone | 12:33 | |
*** rodrigods has joined #openstack-keystone | 12:33 | |
*** radez_g0n3 is now known as radez | 12:43 | |
*** henrynash has joined #openstack-keystone | 12:57 | |
openstackgerrit | Juan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail. https://review.openstack.org/93982 | 12:58 |
openstackgerrit | Juan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail. https://review.openstack.org/93982 | 12:59 |
*** ayoung-ZZzz is now known as ayoung | 13:01 | |
*** ericvw has joined #openstack-keystone | 13:02 | |
*** samuelmz_ is now known as samuelmz | 13:10 | |
*** nkinder has quit IRC | 13:13 | |
samuelmz | ayoung, ping | 13:19 |
ayoung | samuelmz, ping: unknown host ayoung | 13:19 |
samuelmz | ayoung, :D | 13:19 |
samuelmz | ayoung, I'd like to discuss with you about keystone default roles when using devstack | 13:20 |
samuelmz | ayoung, I think there is an inconsistence and I'd like to know what you think about it | 13:20 |
ayoung | 64 bytes from ayoung (127.0.0.1): icmp_seq=1 ttl=64 time=0.040 ms | 13:20 |
*** topol has joined #openstack-keystone | 13:21 | |
ayoung | samuelmz, write away...I'm listening...er....actively coming back to read what you write.... | 13:21 |
samuelmz | ayoung, when using devstack to install OS, it sets iniset operator_roles to 'Member' and 'admin' with 'iniset ${SWIFT_CONFIG_PROXY_SERVER} filter:keystoneauth operator_roles "Member, admin"' at https://github.com/cloudbuilders/devstack/blob/master/lib/swift | 13:21 |
samuelmz | ayoung, It may cause an inconsistence in some cases: suppose a cloud admin grants the '_member_' role to a user... then he will not be able to properly use swift | 13:22 |
samuelmz | ayoung, for me, having Member and _member_ roles is inconsistent | 13:22 |
*** topol has quit IRC | 13:24 | |
*** joesavak has joined #openstack-keystone | 13:24 | |
ayoung | samuelmz, then change the member role in keystone config | 13:28 |
ayoung | samuelmz, http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n69 | 13:29 |
samuelmz | ayoung, but devstack should consider a single member role, shouldn't? I don't know what is the best place to talk about devstack issues.. | 13:29 |
*** bknudson has joined #openstack-keystone | 13:30 | |
ayoung | samuelmz, we created _member_ specifically so it doesn't conflict with existing roles. a User could easily have _member and Member | 13:30 |
samuelmz | ayoung, do they have different semantics? I don't see any reason for having both of them | 13:31 |
*** gordc has quit IRC | 13:32 | |
ayoung | samuelmz, it was due to a migration issue | 13:32 |
ayoung | we had users assigned directly to projects | 13:32 |
ayoung | thus two different mechanisms for associating users with projects | 13:32 |
ayoung | if we blindly made everyone that was "in" a project a "Memeber" of the project we would have been stepping on Swift semantics | 13:33 |
samuelmz | ayoung, as I said, devstack consider Member and admin roles for using swift.. in our private OS cloud, the cloud admin just assigned _member_ to me and then I wasnt able to use swift .. | 13:33 |
ayoung | samuelmz, were you able to use it before? | 13:34 |
samuelmz | ayoung, no | 13:34 |
samuelmz | ayoung, but he assigned Member role to me ( != _member_ ), then I became able to use it | 13:34 |
*** gordc has joined #openstack-keystone | 13:35 | |
ayoung | samuelmz, that is a swift issue, then | 13:35 |
samuelmz | ayoung, if you have reasons for having both _member_ and Member, at least devstack should consider both as swift operator_roles | 13:35 |
ayoung | samuelmz, there is, as of now, no "standard set of roles" for OpenStack | 13:35 |
ayoung | _memeber_ was a migration tool | 13:36 |
samuelmz | ayoung, ok | 13:37 |
samuelmz | ayoung, I just do not agree with the way devstack set roles .. | 13:37 |
*** stevemar has joined #openstack-keystone | 13:37 | |
samuelmz | ayoung, so I think it's a bug in the devstack configuration of OS | 13:37 |
rodrigods | ayoung, samuelmz or a hardcoded check in Swift for Member role? =) | 13:38 |
ayoung | samuelmz, morganfainberg I need to step away from the keyboard. | 13:38 |
*** ayoung is now known as ayoung-afk | 13:38 | |
samuelmz | ayoung-afk, ok thanks | 13:38 |
morganfainberg | np i need to take a break. | 13:38 |
marekd | morganfainberg: what time do you have, 6:30? you are still awake or already awake? | 13:42 |
morganfainberg | already awake, but i need to meet someone for lunch today, so gonna head to a coffee shop. | 13:43 |
*** jimbaker has joined #openstack-keystone | 13:43 | |
*** jimbaker has quit IRC | 13:43 | |
*** jimbaker has joined #openstack-keystone | 13:43 | |
*** daneyon has joined #openstack-keystone | 13:44 | |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Fix tests to use UUID strings rather than ints for IDs https://review.openstack.org/90621 | 14:00 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Escape strings in URLs https://review.openstack.org/66137 | 14:00 |
*** codemonkey_ has joined #openstack-keystone | 14:01 | |
*** codemonkey_ has left #openstack-keystone | 14:01 | |
*** codemonkey_ has joined #openstack-keystone | 14:03 | |
*** codemonkey_ has quit IRC | 14:05 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Add v3 curl examples https://review.openstack.org/96973 | 14:05 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix curl example refs in docs https://review.openstack.org/96966 | 14:05 |
*** nkinder has joined #openstack-keystone | 14:06 | |
*** codemonkey_ has joined #openstack-keystone | 14:07 | |
*** afazekas has quit IRC | 14:12 | |
*** ajayaa has quit IRC | 14:12 | |
*** codemonkey_ has quit IRC | 14:13 | |
*** ChanServ changes topic to "J1 Milestone June 12th! J2 and beyond blueprints require a formalized spec doc: https://git.openstack.org/cgit/openstack/keystone-specs | Please review the proposed specs." | 14:16 | |
-openstackstatus- NOTICE: setuptools issue was fixed in upstream in 3.7.1 and 4.0.1, please, recheck on bug 1325514 | 14:16 | |
*** mgagne has joined #openstack-keystone | 14:17 | |
*** afazekas has joined #openstack-keystone | 14:27 | |
*** afazekas has quit IRC | 14:38 | |
*** andreaf has quit IRC | 14:40 | |
openstackgerrit | Eric N. Vander Weele proposed a change to openstack/keystone: Add documentation on LDAP 'user_id_attribute' https://review.openstack.org/93480 | 14:42 |
*** afazekas has joined #openstack-keystone | 14:50 | |
*** david-lyle has joined #openstack-keystone | 14:51 | |
*** vhoward has joined #openstack-keystone | 14:55 | |
*** tomoiaga has quit IRC | 14:55 | |
*** daneyon has quit IRC | 14:57 | |
*** pafuent has joined #openstack-keystone | 15:03 | |
pafuent | Hi. I'm using the V3 client and I'm getting this error: http://paste.openstack.org/show/82447/. I checked the code and seems that the HTTPClient is not setting the auth_url keyword argument. Is that a bug or I'm not using the Keystone client properly? | 15:09 |
*** smckinney has joined #openstack-keystone | 15:11 | |
*** smckinney has left #openstack-keystone | 15:12 | |
*** smckinney has joined #openstack-keystone | 15:15 | |
*** dc has joined #openstack-keystone | 15:24 | |
*** morganfainberg is now known as morganfainberg_Z | 15:25 | |
dc | are there security implications to having multiple users in a tenant? | 15:25 |
*** ayoung-afk is now known as ayoung | 15:25 | |
ayoung | dc, probably a somewhat. | 15:29 |
ayoung | dc the RBAC policy is not enough to keep on user from creating a VM and another destroying it, for example | 15:29 |
dc | ayoung: I am implementing keystone with swift. When would you want to have users in the same tenant and when would you want to separate it? | 15:30 |
ayoung | dc No idea. | 15:30 |
ayoung | dc It really is based on a lot of factors | 15:30 |
ayoung | dc when you want to share the administration of virtual machines ,put them in the same project. | 15:30 |
smckinney | hello, this is shawn, I met some of you in atlanta | 15:35 |
smckinney | wanted to reiterate my interest in participating in the authorization work being done in keystone | 15:36 |
ayoung | smckinney, welcom aboard | 15:36 |
smckinney | thanks | 15:36 |
ayoung | I know there was a lot of stuff we discussed about policy and RBAC....I think there are two trends | 15:36 |
ayoung | 1 is to make better use of the existing mechanisms | 15:37 |
ayoung | 2 is to make them more usable | 15:37 |
smckinney | well I have a shovel, need to know where to start digging | 15:38 |
ayoung | Heh | 15:38 |
ayoung | smckinney, well...one thing I'd love someone to look at is...(looking for Blueprint) | 15:39 |
ayoung | https://blueprints.launchpad.net/keystone/+spec/endpoint-policy | 15:40 |
smckinney | (looking at now) | 15:40 |
ayoung | smckinney, the short of it is that there is a policy repo in Keystone, but no one is using it | 15:40 |
ayoung | because you can only fetch policy by ID, not by context | 15:40 |
pafuent | Hi. I'm using the V3 client and I'm getting this error: http://paste.openstack.org/show/82447/. I checked the code and seems that the HTTPClient is not setting the auth_url keyword argument. Is that a bug or I'm not using the Keystone client properly? | 15:42 |
ayoung | pafuent, not using client properly | 15:43 |
ayoung | pafuent, client needs to know where to get a token in the first place | 15:43 |
ayoung | nothing else can work without that | 15:43 |
pafuent | ayoung: The thing that I'm not getting is why the HTTPClient is not storing internally the parameter auth_url that I'm passing during the client creation | 15:44 |
pafuent | ayoung: keystone_client.Client(**kwargs) | 15:45 |
pafuent | ayoung: kwargs contains auth_url | 15:45 |
ayoung | pafuent, really? Weird | 15:45 |
ayoung | I'd have to look deeper | 15:46 |
smckinney | ayoung, by context you mean subject (principal) ? | 15:46 |
pafuent | ayoung: OK. Thanks. | 15:46 |
*** leseb has quit IRC | 15:48 | |
*** gyee has joined #openstack-keystone | 15:53 | |
*** gokrokve has joined #openstack-keystone | 15:56 | |
*** leseb has joined #openstack-keystone | 15:57 | |
*** zhiyan is now known as zhiyan_ | 15:57 | |
*** gokrokve has quit IRC | 16:04 | |
*** browne has joined #openstack-keystone | 16:08 | |
smckinney | ayoung, er - tenant ? | 16:11 |
ayoung | smckinney, not project (tenant) but rather service or endpoint | 16:11 |
ayoung | projct would be follow on | 16:11 |
smckinney | ok, let me do some homework/research | 16:12 |
ayoung | smckinney, I intrigued by the idea of per-project policy, but also a little leary of it | 16:12 |
ayoung | I could see it really easy to lock a project so you could do nothing with it | 16:13 |
ayoung | and undoing that would leave it "open wide" | 16:13 |
smckinney | should always fail closed | 16:13 |
ayoung | ? | 16:13 |
smckinney | best practice for MAC (mandatory access control) is to fail closed - not open | 16:14 |
smckinney | think how unix does it as opposed to windows | 16:14 |
ayoung | smckinney, No, I ge that. but afterwads, if you are resetting the policy on a project, you have to remove some aspect of the project specific policy | 16:14 |
*** packet has joined #openstack-keystone | 16:14 | |
ayoung | so if you had an expectation that people need an extra role to do something, and there is no one with that role, nothing can be done | 16:15 |
ayoung | but if you remove that restriction, everything can be done. | 16:15 |
ayoung | smckinney, I think stackable policy is "a bridge too far" for Juno | 16:15 |
ayoung | but the "fetch policy for endpoint" call could be done easily | 16:16 |
ayoung | and is a good starting point | 16:16 |
smckinney | agreed | 16:16 |
smckinney | it will take me a while to get acclimated | 16:16 |
ayoung | of course. Let me know if you get stuck | 16:16 |
smckinney | ok | 16:17 |
*** jaosorior has quit IRC | 16:22 | |
*** topol has joined #openstack-keystone | 16:26 | |
*** pafuent has left #openstack-keystone | 16:30 | |
*** marcoemorais has joined #openstack-keystone | 16:32 | |
*** BAKfr has quit IRC | 16:35 | |
*** shakamunyi has joined #openstack-keystone | 16:36 | |
*** radez is now known as radez_g0n3 | 16:41 | |
*** morganfainberg_Z is now known as morganfainberg | 16:44 | |
*** daneyon has joined #openstack-keystone | 16:46 | |
*** rwsu has joined #openstack-keystone | 16:46 | |
*** afazekas has quit IRC | 16:51 | |
*** florentflament has quit IRC | 16:52 | |
*** harlowja_away is now known as harlowja_ | 16:54 | |
*** andreaf has joined #openstack-keystone | 16:54 | |
*** sbfox has joined #openstack-keystone | 17:04 | |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: test_user_mixed_case_attribute fails - mail, not email https://review.openstack.org/94668 | 17:21 |
openstackgerrit | henry-nash proposed a change to openstack/keystone: multi-backend support for identity https://review.openstack.org/74214 | 17:24 |
*** nsquare has joined #openstack-keystone | 17:27 | |
henrynash | dolphm: ping | 17:29 |
dolphm | henrynash: pong | 17:30 |
*** dims has quit IRC | 17:30 | |
henrynash | dolphm: Hi…could you remove your -2 from https://review.openstack.org/#/c/74214/ | 17:30 |
henrynash | dolphm: assuming that was there to block release into IceHouse? | 17:30 |
dolphm | henrynash: done | 17:31 |
dolphm | henrynash: going to have to propose a -spec for it though! | 17:31 |
henrynash | dolphm: really? I thought if we landed this in J-1 we were Ok? | 17:32 |
*** gokrokve has joined #openstack-keystone | 17:32 | |
henrynash | dolphm: if it’s felt we need a spec, sure I’ll create on of course | 17:32 |
dolphm | henrynash: if you think it'll land in j1! | 17:32 |
henrynash | dolphm: if it doesn’t…..I’ll create a spec…no issue | 17:33 |
dolphm | henrynash: i think a spec would be beneficial regardless, just not mandatory for j1 | 17:33 |
henrynash | dolphm: I think I agree….I’ll write one up anyway | 17:34 |
*** sbfox has quit IRC | 17:34 | |
*** amcrn has joined #openstack-keystone | 17:35 | |
morganfainberg | yay specs~ | 17:35 |
*** sbfox has joined #openstack-keystone | 17:36 | |
*** gokrokve has quit IRC | 17:45 | |
*** gokrokve has joined #openstack-keystone | 17:45 | |
ayoung | hrybacki, I'm not certain who else is looking into json-schema validation, but I am sure someone in here is | 17:50 |
morganfainberg | ayoung, hrybacki, i think stevemar, jamielennox are both. and I will be for some things. | 17:50 |
hrybacki | ayoung, nods | 17:50 |
ayoung | morganfainberg, which library we looking at? | 17:50 |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Invalid command referenced in federation documentation https://review.openstack.org/97298 | 17:51 |
morganfainberg | ayoung, sorry was lbragstad not stevemar https://review.openstack.org/#/c/95957/ | 17:51 |
stevemar | dolphm, morganfainberg easy review ^^ | 17:51 |
ayoung | hrybacki, there ya go | 17:52 |
stevemar | morganfainberg, yes, it's lbragstad | 17:52 |
hrybacki | ayoung, morganfainberg++ | 17:52 |
morganfainberg | stevemar, ouch. missed "install" there really? | 17:52 |
stevemar | morganfainberg, indeedy | 17:52 |
lbragstad | o/ | 17:53 |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported https://review.openstack.org/74897 | 17:55 |
marekd | jamielennox: o/ Accoding to the docstring here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L34 if I actually want to use requests.Session I must pass it in the keystoneclient.session.Session() constructor, right? | 17:56 |
*** dims has joined #openstack-keystone | 17:56 | |
lbragstad | morganfainberg: quick question here: https://review.openstack.org/#/c/95976/4/specs/juno/non-persistent-tokens.rst | 17:57 |
morganfainberg | lbragstad, sure | 17:57 |
*** sbfox has quit IRC | 17:57 | |
lbragstad | in the Data Model Impact section, do we just need to know that a migration is needed or should information be included for how that migration will be handled? | 17:58 |
lbragstad | modifying an existing table, or creating a new table for example | 17:58 |
bknudson | lbragstad: I'd expect the schema to be there. | 17:58 |
lbragstad | I think the reason I would agree would be that it would help detail the backward compat path too | 17:58 |
morganfainberg | hm. | 17:59 |
lbragstad | Ex. this is how we plan to suppor the old way, and with the fancy new migration, we plan to deliver XYZ... | 17:59 |
lbragstad | just curious if we were going into that kind of detail.. which could be tough given how mature the blueprint idea is... Maybe we don't know how we want to handle the migration, but we know we need one. | 18:00 |
morganfainberg | lbragstad, i don't think we'll get anything in this cycle with that depth | 18:00 |
bknudson | if there's a schema then it's obvious that a migration will be required | 18:00 |
bknudson | are there any nova specs that have an example? | 18:00 |
lbragstad | checking | 18:01 |
* morganfainberg goes and looks | 18:01 | |
*** dims has quit IRC | 18:01 | |
*** marcoemorais1 has joined #openstack-keystone | 18:01 | |
* lbragstad nova has a lot of specs | 18:01 | |
morganfainberg | https://github.com/openstack/nova-specs/blob/master/specs/juno/better-support-for-multiple-networks.rst#data-model-impact | 18:01 |
morganfainberg | not very detailed | 18:02 |
*** marcoemorais1 has quit IRC | 18:02 | |
ayoung | hrybacki, stevemar | 18:02 |
ayoung | https://etherpad.openstack.org/p/sample-user-json-schema | 18:02 |
*** marcoemorais1 has joined #openstack-keystone | 18:02 | |
*** marcoemorais has quit IRC | 18:02 | |
bknudson | why even have a data model section if it's not going to provide any info | 18:03 |
bknudson | doesn't seem like it's that hard to put some DDL in there. | 18:03 |
morganfainberg | bknudson, data model could be two things, object structure / class, and SQL schema | 18:04 |
lbragstad | https://github.com/openstack/nova-specs/blob/master/specs/juno/extensible-resource-tracking.rst#data-model-impact | 18:04 |
bknudson | morganfainberg: nova has database objects, so maybe that's what they're referring to. | 18:04 |
morganfainberg | bknudson, ++ perhaps. | 18:05 |
bknudson | also we've got an ldap backend so should describe how the feature is going to work with that | 18:06 |
stevemar | ayoung, i think lbragstad has a json schema for most keystone entities | 18:06 |
morganfainberg | bknudson, i'm ok with seeing how it goes as is and requiring DDL if its needed down the line. this one is going to be a lot more rigid than before because i'm going to be converting the ... token format up for that | 18:06 |
ayoung | hrybacki, edit your name in there | 18:06 |
ayoung | stevemar, of course he does... | 18:06 |
stevemar | lbragstad, https://etherpad.openstack.org/p/sample-user-json-schema | 18:06 |
morganfainberg | bknudson, in this case no LDAP, but i'd agree for assignment stuff | 18:06 |
morganfainberg | bknudson, and/or idenitty | 18:06 |
ayoung | lbragstad, you have these laid out already? | 18:07 |
lbragstad | ayoung yep some | 18:07 |
* lbragstad grabs link | 18:07 | |
lbragstad | ayoung something similar to https://review.openstack.org/#/c/96266/4/keystone/catalog/schema.py | 18:07 |
ayoung | lbragstad, any for identity? | 18:09 |
lbragstad | ayoung no, only for assignment and catalog at the moment | 18:09 |
stevemar | ayoung, ahh, i gave you false info :( | 18:10 |
ayoung | hrybacki, recommend that you do a code review of https://review.openstack.org/#/c/96266/4/keystone/catalog/schema.py and ask lbragstad about anything you don't undertand. Use the etherpad to document the identity ones | 18:10 |
lbragstad | which covers domain, project, role, regions, services, and endpoints | 18:10 |
hrybacki | ayoung, kk | 18:10 |
dolphm | ugh - i had made a bunch of unpublished/draft comments on a -spec on friday ... just went to go add a few more & publish and they all vanished :( | 18:10 |
dolphm | apparently they expire now or something? | 18:10 |
dolphm | aaand i refreshed and they all re-appeared. do not understand. | 18:11 |
morganfainberg | dolphm, new patch? | 18:11 |
morganfainberg | dolphm, loggedin/session timeout? | 18:11 |
dolphm | morganfainberg: nope, all on the exact same review/patchset/file | 18:11 |
lbragstad | dolphm: lol is it because your gerrit account is messed up? | 18:12 |
dolphm | morganfainberg: my session had definitely expired in the interim, but i was logged in when they vanished | 18:12 |
dolphm | lbragstad: i hope not! | 18:12 |
dolphm | lbragstad: it was on your -spec too! | 18:12 |
morganfainberg | dolphm, wierd | 18:12 |
lbragstad | dolphm: you got them back so you can publish them right? | 18:13 |
*** dims has joined #openstack-keystone | 18:13 | |
dolphm | lbragstad: yep, give me just a few mins | 18:13 |
lbragstad | cool | 18:13 |
dolphm | lbragstad: reviewing them since it was late on friday :) | 18:13 |
lbragstad | hrybacki: I tried pulling some of the more common schema validation types in a common place: https://review.openstack.org/#/c/86483/14/keystone/common/validation/parameter_types.py | 18:14 |
lbragstad | dolphm: I've been guilty of that | 18:14 |
lbragstad | hrybacki: so, feel free to leverage those | 18:15 |
hrybacki | lbragstad, looking over this too, thanks! | 18:15 |
lbragstad | hrybacki: that way if something changes in the future, it should minimize refactoring | 18:15 |
hrybacki | lbragstad++ | 18:15 |
*** nkinder has quit IRC | 18:18 | |
*** marcoemorais1 has quit IRC | 18:20 | |
*** marcoemorais has joined #openstack-keystone | 18:20 | |
dolphm | bknudson: published | 18:26 |
*** amcrn has quit IRC | 18:27 | |
morganfainberg | bknudson, ping https://review.openstack.org/#/c/91677 - we can abandon this right? we're not doing rally on stable/* iirc? | 18:27 |
bknudson | morganfainberg: abandoned. If we need it we can cherry-pick again. | 18:27 |
morganfainberg | bknudson, ++ | 18:28 |
bknudson | or restore it | 18:28 |
*** amcrn has joined #openstack-keystone | 18:28 | |
bknudson | dolphm: published what? | 18:29 |
dolphm | bknudson: oh my bad. lbragstad: published! | 18:29 |
*** nkinder has joined #openstack-keystone | 18:29 | |
lbragstad | dolphm: addressing now... | 18:29 |
lbragstad | thanks! | 18:29 |
lbragstad | dolphm: is there a way to change the blueprint in launchpad from keystone-api-validation to api-validation? | 18:30 |
morganfainberg | lbragstad, iirc no. | 18:30 |
lbragstad | ah yep... | 18:30 |
lbragstad | there is | 18:30 |
morganfainberg | there is? | 18:30 |
morganfainberg | you can chang ethe URL? | 18:30 |
lbragstad | sweet https://blueprints.launchpad.net/keystone/+spec/api-validation | 18:30 |
morganfainberg | oh neat.. | 18:30 |
lbragstad | 'Change details' | 18:30 |
* morganfainberg grumbles about non-intuativeness of LP | 18:31 | |
morganfainberg | except where it is intuative | 18:31 |
lbragstad | lol | 18:31 |
*** jaosorior has joined #openstack-keystone | 18:32 | |
htruta | stevemar: ping | 18:37 |
stevemar | htruta, pong, | 18:38 |
stevemar | i'm still waiting to hear back from dtroyer :( | 18:38 |
htruta | stevemar: sad :( | 18:38 |
dolphm | lbragstad: glad you found it :) | 18:40 |
*** openstackstatus has quit IRC | 18:50 | |
*** openstackstatus has joined #openstack-keystone | 18:51 | |
*** ChanServ sets mode: +v openstackstatus | 18:51 | |
EmilienM | Hi there, any core could have a look at https://review.openstack.org/#/c/95601/ ? it's a backport to stable/icehouse | 18:52 |
morganfainberg | EmilienM, the core team can look at it but dolphm and the stable maintenance team will the be people to can accept (cores can't approve/+2 code for stable/* releases) | 18:54 |
morganfainberg | EmilienM, just as an FYI. | 18:54 |
EmilienM | morganfainberg: it makes sense | 18:54 |
EmilienM | morganfainberg: i just wanted ti highlight a patch which is here for some days... | 18:54 |
morganfainberg | EmilienM, yeah stable takes a bit longer to get reviewed in some cases. | 18:55 |
EmilienM | morganfainberg: ok, I don't worry then. | 18:55 |
*** richm has joined #openstack-keystone | 18:56 | |
morganfainberg | EmilienM, added a couple people to the review specifically for you | 18:56 |
EmilienM | morganfainberg: awesome, thanks | 18:56 |
*** sbfox has joined #openstack-keystone | 18:56 | |
openstackgerrit | Richard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported https://review.openstack.org/74897 | 18:58 |
*** tristanC has quit IRC | 19:03 | |
morganfainberg | ayoung, dow e have a location where the start of FreeIPA is installed / packaged for ubuntu | 19:05 |
morganfainberg | or... is that not available anywhere yet? | 19:05 |
ayoung | morganfainberg, I think it is in timo's repo or something | 19:06 |
morganfainberg | hm. | 19:06 |
morganfainberg | ok. /me goes hunting further | 19:06 |
ayoung | https://launchpad.net/~tjaalton | 19:06 |
ayoung | morganfainberg, https://launchpad.net/freeipa | 19:07 |
morganfainberg | ayoung, yeah client, sssd, and python stuff is all packaged | 19:08 |
morganfainberg | but the server seems to be missing | 19:08 |
ayoung | hmmm | 19:08 |
morganfainberg | ayoung, well not packaged yet? | 19:08 |
ayoung | its somewhere | 19:09 |
ayoung | morganfainberg, what version Ubuntu you looking for? | 19:09 |
morganfainberg | ayoung, 14.04 or 12.04 | 19:09 |
ayoung | Is that Trusty? | 19:09 |
morganfainberg | 14.04 is | 19:09 |
* ayoung not keeping up | 19:09 | |
ayoung | https://launchpad.net/ubuntu/trusty/+source/freeipa | 19:09 |
morganfainberg | ayoung, yeah looks like it is client only? https://launchpad.net/ubuntu/trusty/+source/freeipa/3.3.4-0ubuntu3 | 19:10 |
ayoung | I thought they were in tjaalton's ppa | 19:11 |
morganfainberg | ayoung, nah his ppa doesn't have freeipa in it https://launchpad.net/~tjaalton/+archive/ppa | 19:12 |
*** marcoemorais has quit IRC | 19:12 | |
ayoung | morganfainberg, he and I are chatting in #freeipa | 19:12 |
morganfainberg | ah let me join that | 19:12 |
*** praneshp has joined #openstack-keystone | 19:14 | |
*** radez_g0n3 is now known as radez | 19:15 | |
*** andreaf has quit IRC | 19:17 | |
*** marcoemorais has joined #openstack-keystone | 19:22 | |
*** leseb has quit IRC | 19:24 | |
*** marcoemorais1 has joined #openstack-keystone | 19:26 | |
*** bobt_ has joined #openstack-keystone | 19:27 | |
*** marcoemorais1 has quit IRC | 19:27 | |
*** marcoemorais2 has joined #openstack-keystone | 19:27 | |
*** marcoemorais has quit IRC | 19:27 | |
*** bobt_ has quit IRC | 19:28 | |
*** andreaf has joined #openstack-keystone | 19:30 | |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone-specs: Purpose keystone-api-validation blueprint https://review.openstack.org/95957 | 19:32 |
*** sbfox has quit IRC | 19:33 | |
*** sbfox has joined #openstack-keystone | 19:34 | |
*** leseb has joined #openstack-keystone | 19:40 | |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Make gen_pki.sh bash8 compliant https://review.openstack.org/93438 | 19:40 |
*** gyee has quit IRC | 19:41 | |
*** sbfox1 has joined #openstack-keystone | 19:42 | |
*** nsquare has quit IRC | 19:43 | |
*** sbfox has quit IRC | 19:46 | |
jaosorior | is there any template to fill or something of the kind of blueprints? | 19:46 |
morganfainberg | dolphm, bknudson, ping https://review.openstack.org/#/c/93982/5/keystone/assignment/controllers.py - we definitely want a hard lookup on user/group for grant creation? | 19:49 |
morganfainberg | dolphm, bknudson, misread some of the comments and placed -2 on it... now re-reading and i'm confused. i thought we wanted to support non-existent users having grants pre-seeded (e.g. LDAP backend) | 19:49 |
bknudson | morganfainberg: for now it makes sense. If I assign a role to a user there's no reason that user shouldn't exist. | 19:50 |
bknudson | morganfainberg: I don't follow the pre-seeded user grants for ldap... why would I need to do that? | 19:51 |
morganfainberg | bknudson, hm. ok. | 19:51 |
morganfainberg | bknudson, it was an argument made earlier | 19:51 |
morganfainberg | bknudson, i remember participating in that discussion | 19:52 |
morganfainberg | bknudson, but if it isn't the case, i'm fine with requiring the user/group to exist | 19:52 |
bknudson | morganfainberg: in my opinion it seems like either behavior is ok... | 19:53 |
bknudson | since keystone doesn't know if a user was deleted the role grant could be pointing to a user that doesn't exist anyways., | 19:53 |
bknudson | in the case of ldap | 19:53 |
morganfainberg | bknudson, right | 19:53 |
morganfainberg | bknudson, i think the case was LDAP, e.g. "I know i'm adding a user called XYZ but user hasn't been added to LDAP yet, so create the grant anyway" | 19:54 |
morganfainberg | though... that becomes more work once henry's uuid mapping patch lands | 19:55 |
bknudson | we'll probably have to change it in the future anyways if we split out the identity backend | 19:55 |
morganfainberg | bknudson, yeah. | 19:55 |
morganfainberg | bknudson, i'm tempted to say unless there is a very good reason to start enforcing it, i don't know if we should start now (keep it as is) | 19:55 |
bknudson | or if we allow federation to map to users instead of groups | 19:55 |
morganfainberg | bknudson, ++ | 19:56 |
dolphm | morganfainberg: bknudson: i personally don't care one way or the other, but we need to make it very clear if we support the non-obvious behavior (bp, keystone docs, tests with explanation, etc), otherwise we will get confused bug reports all day long | 19:58 |
stevemar | morganfainberg, i liked the comment "ahhh re-reading now" | 19:58 |
*** openstackgerrit has quit IRC | 19:58 | |
morganfainberg | dolphm, i'd prefer keeping it as is allowing for the grants w/o the hard lookup and fix the docs / explicitly test etc | 19:58 |
dolphm | (but i don't see an *immediate* use case for supporting arbitrary assignments, we've only talked about potential ones) | 19:58 |
morganfainberg | dolphm, but that is because i believe we're going to get asked for direct assignment to federation users vs groups | 19:59 |
morganfainberg | dolphm, and the long term desire to split identity out (somewhat) | 19:59 |
morganfainberg | dolphm, if we put the stake in the sand and validate, i woudn't want to change the behavior back to not validating. | 20:00 |
bknudson | I'd expect federated role assignments to come about by some mapping, not assigning users to roles directly | 20:00 |
bknudson | attribute values -> roles | 20:00 |
morganfainberg | bknudson, if we can commit to that, i'm ok with this change. - i just don't want to end up waffling on this api | 20:00 |
morganfainberg | bknudson, and the behabior | 20:01 |
bknudson | not attribute -> id -> role assignments -> roles | 20:01 |
morganfainberg | behavior | 20:01 |
morganfainberg | omg... i sewar i can type. | 20:01 |
* morganfainberg grumbles. | 20:01 | |
stevemar | behaviour* | 20:01 |
morganfainberg | stevemar, ... thanks ... | 20:02 |
morganfainberg | :P | 20:02 |
stevemar | i try | 20:02 |
morganfainberg | ok got some time for oauth? | 20:02 |
bknudson | I think there was a bp for not checking user / group exists on assignment | 20:02 |
morganfainberg | bknudson, in the drivers. | 20:02 |
bknudson | but then it was also based on faulty idea of how federation was going to work | 20:03 |
morganfainberg | bknudson, controllers are the logical area to do the work cross subsystem. | 20:03 |
*** leseb has quit IRC | 20:03 | |
*** nsquare has joined #openstack-keystone | 20:03 | |
morganfainberg | bknudson, that way we don't need to do the same implementation in every driver | 20:03 |
bknudson | bp no-check-id | 20:04 |
morganfainberg | bknudson, hm. | 20:04 |
bknudson | https://blueprints.launchpad.net/keystone/+spec/no-check-id | 20:05 |
morganfainberg | oh so i twas more than just taking it out of the driver | 20:05 |
bknudson | "Even in LDAP and SQL cases, an admin may need to create role assignments prior to a valid user object being available." | 20:06 |
bknudson | still, not sure why an admin may need to create role assignments before the user is there | 20:06 |
*** amcrn has quit IRC | 20:08 | |
*** openstackgerrit has joined #openstack-keystone | 20:10 | |
morganfainberg | bknudson, i remember the discussions | 20:12 |
bknudson | if it's an important use case then I guess a tempest scenario would be good to have. | 20:14 |
*** marcoemorais2 has quit IRC | 20:14 | |
bknudson | I think even with all sorts of docs and tests out there that verify the behavior we're still going to get a constant stream of bugs | 20:14 |
*** marcoemorais has joined #openstack-keystone | 20:14 | |
*** gyee has joined #openstack-keystone | 20:15 | |
*** hrybacki has quit IRC | 20:15 | |
*** topol has quit IRC | 20:17 | |
ayoung | running tests for a backport, and realized how spoiled I've become by tox and the speedier tests | 20:19 |
morganfainberg | ayoung, havana or icehouse | 20:20 |
ayoung | icehouse right now... | 20:20 |
morganfainberg | ayoung, yeah, havana makes me blink each time because it's the old nosetests style | 20:21 |
ayoung | its almost done...had to remember to test_mount | 20:21 |
ayoung | Didn't want to destroy my tox | 20:21 |
morganfainberg | hehe | 20:21 |
morganfainberg | ayoung, besides the backport stuff - you still working on compressed tokens or off on something else? trying to prioritze what i'm starting to work on (besides spec approvals) | 20:23 |
*** leseb has joined #openstack-keystone | 20:24 | |
morganfainberg | bknudson, ok i'm sold, lets hard verify user/group exists again | 20:26 |
morganfainberg | bknudson, if we need something federated, we do mapping(s) | 20:26 |
morganfainberg | dolphm, ^ | 20:26 |
morganfainberg | stevemar, ^ | 20:26 |
morganfainberg | bknudson, if we split identity out, we will have a whole other mess to deal with anyway...likely it will have to work just like federation | 20:27 |
dolphm | morganfainberg: sounds good | 20:27 |
bknudson | morganfainberg: at first I expect keystone to just forward requests to the identity server but then switch to federation at some point. | 20:27 |
morganfainberg | dolphm, if Pablo isn't interested in continuing https://review.openstack.org/#/c/86025/ i'll pick that one up. | 20:27 |
bknudson | a federation plugin | 20:28 |
stevemar | yeah, i was going to ask to just revert bknudson's patch | 20:28 |
morganfainberg | bknudson, ++ yeah if it's proxy/forward i expect the same. | 20:28 |
morganfainberg | stevemar, i think bknudson's patch also removed things from the drivers we should keep cross-subsystem chatter to controllers in either case. | 20:28 |
*** nkinder has quit IRC | 20:28 | |
dolphm | morganfainberg: give him 24 hours or so to respond? | 20:28 |
morganfainberg | dolphm, yep | 20:29 |
dolphm | morganfainberg: know his name on IRC? | 20:29 |
morganfainberg | dolphm, eh, till the end of the week | 20:29 |
morganfainberg | dolphm, i know he's been on irc before.... | 20:29 |
dolphm | me too | 20:29 |
morganfainberg | pcargnel | 20:29 |
lbragstad | https://launchpad.net/~pablo-fernando-cargnelutti | 20:30 |
morganfainberg | dolphm, nick isn't registerted w/ freenode, so can't see when he was around last | 20:30 |
morganfainberg | dolphm, what the heck... | 20:34 |
morganfainberg | dolphm, we have a role grant crud test to ensure non-existent user raises 404, but... we don't check it at the controller? | 20:35 |
* morganfainberg blinks | 20:35 | |
dolphm | morganfainberg: checked in the driver? | 20:36 |
morganfainberg | dolphm, perhaps. | 20:36 |
morganfainberg | dolphm, looking but https://github.com/openstack/keystone/blob/master/keystone/tests/test_v3_identity.py#L829 don't see how that is passing at the moment | 20:36 |
morganfainberg | oh. | 20:38 |
dolphm | morganfainberg: ? | 20:38 |
morganfainberg | is that a domain role? | 20:38 |
morganfainberg | it's testing | 20:38 |
*** dims has quit IRC | 20:38 | |
morganfainberg | not a project role | 20:38 |
*** nkinder has joined #openstack-keystone | 20:40 | |
dolphm | morganfainberg: i don't follow | 20:40 |
morganfainberg | that test is claiming it should 404 if the user doesn't exist, it's trying to create a domain grant for the user | 20:41 |
morganfainberg | it is obviously raising a 404. | 20:41 |
morganfainberg | the test passes | 20:41 |
*** smckinney has quit IRC | 20:41 | |
morganfainberg | the controller / driver don't check for user existence | 20:41 |
morganfainberg | something else is causing the 404 | 20:41 |
dolphm | morganfainberg: why is that obvious? | 20:41 |
morganfainberg | dolphm, it's not obvious, i'm confused why the test is passing | 20:42 |
morganfainberg | dolphm, afaict it should be failing | 20:42 |
dolphm | morganfainberg: i'm confused as to why you think it should be failing | 20:42 |
dolphm | morganfainberg: AFAICT you be crazy, yo | 20:42 |
morganfainberg | https://github.com/openstack/keystone/blob/master/keystone/tests/test_v3_identity.py#L846 | 20:42 |
morganfainberg | it's looking for a 404, grants don't check for existence of the user | 20:43 |
dolphm | morganfainberg: if you change it to self.user_id does it pass? | 20:43 |
dolphm | err, fail | 20:43 |
* morganfainberg checks | 20:44 | |
morganfainberg | dolphm, huh so it does check. | 20:45 |
morganfainberg | dolphm, wow i'm totally not following this code atm correctly | 20:45 |
dolphm | morganfainberg: apply caffeine and reboot | 20:45 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: Spec for V3 extension advertisement https://review.openstack.org/95973 | 20:51 |
morganfainberg | dolphm, i think i found it. i think this is a side effect of the filter protect callback | 20:52 |
*** amcrn has joined #openstack-keystone | 20:53 | |
morganfainberg | dolphm, https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L488 | 20:53 |
morganfainberg | erm protect (not filter protect) | 20:53 |
morganfainberg | dolphm, so in V3, it wouldn't succeed even without the changes in https://review.openstack.org/#/c/93982/ because the v3 api has a callback that tries to lookup the user/group if they are part of the request | 20:56 |
morganfainberg | dolphm, the V2 one has no such callback doing the work | 20:56 |
morganfainberg | dolphm, the question is, do we want explicit checks, or is a side effect of that callbck sufficient? | 20:56 |
morganfainberg | bknudson, ^ | 20:57 |
dolphm | morganfainberg: lol that's terrible :( | 20:57 |
*** amcrn has quit IRC | 20:57 | |
dolphm | morganfainberg: v2 and v3 should behave identically in that regard | 20:58 |
morganfainberg | dolphm, agreed | 20:58 |
bknudson | morganfainberg: we shouldn't be relying on the side-effect | 20:58 |
morganfainberg | dolphm, and we should do explicit checks in V2 for sure, but with the change from that review we'll be doing extra lookups on user/group in the decorator callback. | 20:58 |
morganfainberg | dolphm, i guess we're already bad about lookup things to lookup things then do the work again | 20:59 |
bknudson | might want to change the server so that there isn't a side-effect | 20:59 |
morganfainberg | bknudson, yeah. i think that might be a massive policy implementation re-think | 20:59 |
morganfainberg | bknudson, i'm gonna say we should drive that separately. | 21:00 |
morganfainberg | from this review. | 21:00 |
ayoung | morganfainberg, WHAT | 21:00 |
ayoung | I stop paying attention and we decide to backpedal! | 21:00 |
morganfainberg | ayoung, V3 does a hard check of users/groups on grant creation | 21:00 |
morganfainberg | ayoung, it's a side effect of our policy implementation | 21:01 |
ayoung | morganfainberg, and that never made sense. | 21:01 |
morganfainberg | ayoung, the call back | 21:01 |
ayoung | lets drop it | 21:01 |
morganfainberg | ayoung, i think if we're talking federated users, all the mappings to roles shoud come from mapping. | 21:01 |
morganfainberg | user/groups/etc | 21:01 |
ayoung | what argument did I miss? | 21:01 |
* ayoung reads further up | 21:01 | |
morganfainberg | for non federated users what is the use case for greating grants for non-existant users? | 21:02 |
morganfainberg | ayoung, so direct IDP (Sql, or LDAP) why is it bad to check for user/group existence before creating the grant [lets ignore federation atm] | 21:03 |
ayoung | morganfainberg, they haven't been entered by HR yet | 21:03 |
ayoung | morganfainberg, it couples the two backends | 21:03 |
ayoung | it makes no difference if they are there or not | 21:03 |
morganfainberg | ayoung, i don't care which way we go as long as V2 and V3 end up consistent. | 21:04 |
openstackgerrit | Rodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add role assignments as concept in Client API V3 docs https://review.openstack.org/97345 | 21:04 |
ayoung | morganfainberg, and we can't just "assume away" Federation. That is the approach that should drive the LDAP work | 21:04 |
ayoung | not the other way around | 21:04 |
ayoung | V2 needs to die | 21:04 |
ayoung | We need to stop pandering to the "I need to look up every one of my 100000000000000 users" crowd | 21:05 |
*** dims has joined #openstack-keystone | 21:05 | |
openstackgerrit | Rodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add role assignments as concept in Client API V3 docs https://review.openstack.org/97345 | 21:05 |
bknudson | in V2, I think create user, modify user, etc, is an extension | 21:05 |
morganfainberg | ayoung, we can do all the federation stuff via mapping: (attribute, attribute, etc) == Role | 21:05 |
bknudson | so maybe we should look at deprecating the extensions | 21:05 |
ayoung | bknudson, user_crud | 21:05 |
bknudson | leaving the core v2 supported | 21:05 |
ayoung | bknudson, um...that would be cool | 21:05 |
morganfainberg | ayoung, which is why i said ignore federation - we can work aroudn federation stuff atm. and this change wouldn't affect current OS-FEDERATION items. | 21:05 |
bknudson | maybe that would be more acceptable | 21:05 |
morganfainberg | ayoung, so more to the point, just address the direct IDP scenario | 21:06 |
morganfainberg | ayoung, the rest will follow fine. | 21:06 |
ayoung | morganfainberg, the sooner we convince the world that storing users in a custome SQL database is a dumb idea, the better. | 21:07 |
*** topol has joined #openstack-keystone | 21:07 | |
*** dims has quit IRC | 21:09 | |
morganfainberg | so.. with henrynash's universal user_id thing, i think we can fix the callback. | 21:10 |
morganfainberg | maybe. | 21:10 |
* morganfainberg needs to think on the fix if we're making V3 not check users (consistent with v2) | 21:10 | |
morganfainberg | because a change to this might brak anyone who is using advanced policy on grant creation (e.g. ensuring user.domain_id == project.domain_id) | 21:11 |
*** arborism has joined #openstack-keystone | 21:13 | |
ayoung | What the who now? | 21:13 |
ayoung | user.domain_id == project.domain_id is a bad assumption | 21:13 |
openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authentication https://review.openstack.org/92166 | 21:13 |
*** daneyon has quit IRC | 21:14 | |
marekd | ^^ strange, when I use keystoneclient.session.Session, even with requests.Session() injected it will eventually complain with error keystoneclient.openstack.common.apiclient.exceptions.BadRequest: Expecting to find application/json in Content-Type header. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400). If I inject pure requests.Session() to t | 21:15 |
morganfainberg | ayoung, no i mean the rich v3 cloud policy capabilities | 21:16 |
morganfainberg | ayoung, it relies on being able to lookup any user / group / domain / project / etc attributes in some cases and pass it to enforcement engine | 21:16 |
ayoung | morganfainberg, but that particular rule representat a misunderstanding of how policy and role assignments should work | 21:17 |
morganfainberg | ayoung, in v3 cloud policy you could enforce all users can only have roles on their domains | 21:17 |
ayoung | there is no relationship between user domain and project domain | 21:17 |
morganfainberg | ayoung. could, not required to. | 21:17 |
ayoung | morganfainberg, um...that would be just the kind of thing I would take much glee in trashing | 21:18 |
morganfainberg | dolphm, ^ is this a ML topic to see what people are doing [if anything] or can we merrily break things like that. | 21:18 |
ayoung | morganfainberg, but...actually I don;t even see how that is not enforcable | 21:19 |
ayoung | it would be quite enforceable | 21:19 |
dolphm | morganfainberg: what's the use case that would be broken? | 21:19 |
ayoung | when you assign a role, you would check on the user object passed in, not on a lookup in IdP | 21:19 |
dolphm | user.domain_id == project.domain_id as an assumption? (where?) | 21:19 |
morganfainberg | dolphm, ok so - if we don't do the hard lookup (fix the grant engine) we need to break some of the more rich v3 cloud policy capabilities | 21:19 |
ayoung | http://www.youtube.com/watch?v=s9bT4B1kEvc | 21:20 |
morganfainberg | dolphm, e.g. the ability to say all users can only have grants on projects in their owning domain | 21:20 |
morganfainberg | ayoung, except policy enforcement happens in the decorator | 21:20 |
ayoung | morganfainberg, an...it looks at the arguments | 21:21 |
morganfainberg | ayoung, yep | 21:21 |
ayoung | not at the objects fetched from the DB in this case | 21:21 |
morganfainberg | ayoung, you got it | 21:21 |
ayoung | it would fetch project from DB,but user would be passed in | 21:21 |
morganfainberg | ayoung, only user_id is passed in | 21:21 |
ayoung | ah...but only oin that whoe eveil USer ID insanity we have....crud | 21:21 |
morganfainberg | ayoung, exactly | 21:21 |
* ayoung goes back under his rock | 21:21 | |
morganfainberg | ayoung, it might be easier for consistency to make the standard grant stuff all do hard lookups. and enhance the mapping engine to get around it (even for local IDP) - move everything to mapping? | 21:22 |
morganfainberg | dolphm, bknudson, ^ [thoughts] | 21:22 |
ayoung | its wrong and backwards and we are enabling disfunctional behavior | 21:23 |
ayoung | ..soo pretty much status quo | 21:23 |
dolphm | morganfainberg: what does the mapping engine have to "get around?" | 21:24 |
morganfainberg | dolphm, the mapping engine can do all the work of mapping <any combination of attributes> to a role. vs needing to know a specific user/group id | 21:25 |
dolphm | morganfainberg: with scope? | 21:25 |
morganfainberg | dolphm, scope? | 21:25 |
dolphm | morganfainberg: "to a role" ... in what scope? | 21:26 |
bknudson | morganfainberg: I'm not understanding what you're suggesting breaking... isn't it broken as is? | 21:26 |
bknudson | morganfainberg: the server doesn't check if the user exists now, so cloud policy is broken | 21:26 |
morganfainberg | bknudson, except it does in the decorator callback: https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L488 which is what is passed to the enforcement engine | 21:27 |
morganfainberg | dolphm, we could map, i guess? to role in <project>? | 21:27 |
morganfainberg | or role in <thing>? | 21:28 |
bknudson | morganfainberg: ok, so I think you're saying that keystone actually requires a user now, and to change it to not require a user requires changing the policy code. | 21:28 |
morganfainberg | bknudson, correct, sorry wasn't clear on that (jumping around the conversation some). | 21:28 |
bknudson | good god no wonder people complain keystone is slow! | 21:29 |
morganfainberg | bknudson, and possibly changing the richness of what policy can enforce. | 21:29 |
bknudson | The server could try to get the user, role, etc., and if it fails with not found set the value to None there | 21:30 |
bknudson | or don't set it | 21:30 |
bknudson | or set it to some dummy value | 21:30 |
* morganfainberg finds the more entertaining rabbitholes. | 21:30 | |
bknudson | the policy code should be smart enough to handle the missing value | 21:30 |
bknudson | missing attribute | 21:31 |
bknudson | I could swear I had a unit test... seems like it would have faile.d | 21:31 |
bknudson | maybe it didn't go through the policy code | 21:31 |
*** arborism is now known as amcrn | 21:32 | |
*** raildo has quit IRC | 21:34 | |
*** henrynash has quit IRC | 21:35 | |
openstackgerrit | Rodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Changes expcetion raised by v3.trusts.update() https://review.openstack.org/97355 | 21:50 |
*** Guest70585 has joined #openstack-keystone | 21:52 | |
*** anteaya has quit IRC | 21:54 | |
*** Guest70585 is now known as anteaya | 21:54 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: Add spec for using JSON Home https://review.openstack.org/97359 | 21:54 |
bknudson | wrote up a spec for using JSON Home since people were asking about it | 21:55 |
morganfainberg | dolphm, back tick all the things: ``All`` ``references`` ``to`` ``token_api.get_token`` ``(````excluding`` ``the`` ``UUID`` ``token provider````)`` .. :P | 21:55 |
*** david-lyle has quit IRC | 21:55 | |
stevemar | morganfainberg, our consistency with the back ticks is awful | 21:56 |
*** andreaf has quit IRC | 22:02 | |
*** nkinder has quit IRC | 22:02 | |
*** dims has joined #openstack-keystone | 22:03 | |
*** andreaf has joined #openstack-keystone | 22:07 | |
*** dims has quit IRC | 22:08 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens https://review.openstack.org/95976 | 22:08 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens https://review.openstack.org/95976 | 22:10 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens https://review.openstack.org/95976 | 22:11 |
*** andreaf has quit IRC | 22:12 | |
*** jamielennox is now known as jamielennox|away | 22:12 | |
*** dims has joined #openstack-keystone | 22:12 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone-specs: Add spec for using JSON Home https://review.openstack.org/97359 | 22:13 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Properly invalidate cache for get_*_by_name methods https://review.openstack.org/97082 | 22:14 |
*** praneshp has quit IRC | 22:17 | |
*** bknudson has quit IRC | 22:20 | |
*** leseb has quit IRC | 22:21 | |
morganfainberg | ls | 22:26 |
*** gordc has quit IRC | 22:27 | |
*** jaosorior has quit IRC | 22:32 | |
*** sbfox1 has quit IRC | 22:35 | |
*** sbfox has joined #openstack-keystone | 22:38 | |
*** jamielennox|away is now known as jamielennox | 22:43 | |
jamielennox | marekd that's not good - did you figure it out/ | 22:47 |
*** stevemar has quit IRC | 22:54 | |
*** amerine_ has joined #openstack-keystone | 22:54 | |
*** nkinder has joined #openstack-keystone | 22:58 | |
*** amerine has quit IRC | 22:58 | |
*** harlowja_ has quit IRC | 23:04 | |
*** harlowja has joined #openstack-keystone | 23:04 | |
*** dc has quit IRC | 23:07 | |
jamielennox | hey guys, this one fairly trivial and getting in the way: https://review.openstack.org/#/c/91216/ would appreciate a few looks | 23:09 |
*** leseb has joined #openstack-keystone | 23:22 | |
*** andreaf has joined #openstack-keystone | 23:23 | |
*** leseb has quit IRC | 23:26 | |
*** andreaf has quit IRC | 23:29 | |
*** sbfox has quit IRC | 23:32 | |
*** rodrigods_ has joined #openstack-keystone | 23:33 | |
*** joesavak has quit IRC | 23:35 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization https://review.openstack.org/96315 | 23:36 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization https://review.openstack.org/96315 | 23:39 |
jamielennox | morganfainberg: much prefer that way to the idea of generating new single use tokens | 23:42 |
morganfainberg | :) | 23:42 |
jamielennox | also no idea how to handle that in middleware | 23:43 |
morganfainberg | jamielennox, how to accept another header and present the data? | 23:46 |
morganfainberg | jamielennox, should be easy | 23:46 |
jamielennox | yea, just thinking about blowing out the number of headers we are going to have to present | 23:47 |
morganfainberg | jamielennox, we already have that code. | 23:47 |
jamielennox | need a better way | 23:47 |
morganfainberg | jamielennox, 1 extra header? | 23:47 |
morganfainberg | oh oh | 23:47 |
morganfainberg | yeah | 23:47 |
morganfainberg | well i mean, how else do you pass data from the middleware to the service? | 23:47 |
morganfainberg | and... does it matter? | 23:47 |
morganfainberg | the service token should be very small, no catalog, etc | 23:48 |
morganfainberg | really just user, scope (probably usually none) and roles | 23:48 |
morganfainberg | SC and all the other mojo (trusts, etc) would be left out | 23:48 |
morganfainberg | maybe a while list of service token headers to provide | 23:49 |
morganfainberg | white list even | 23:49 |
*** diegows has quit IRC | 23:54 | |
*** stevemar has joined #openstack-keystone | 23:56 | |
*** sbfox has joined #openstack-keystone | 23:57 | |
jamielennox | you're right it really doesn't matter i think | 23:58 |
*** amerine_ has quit IRC | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!