| *** henrynash has joined #openstack-keystone | 00:03 | |
| *** viswanathsomanch has quit IRC | 00:16 | |
| *** Viswanath has joined #openstack-keystone | 00:18 | |
| *** Viswanath_ has quit IRC | 00:19 | |
| *** Viswanath has quit IRC | 00:23 | |
| *** dims__ has joined #openstack-keystone | 00:26 | |
| *** dims__ has quit IRC | 00:32 | |
| *** dims__ has joined #openstack-keystone | 00:32 | |
| *** diegows has joined #openstack-keystone | 00:41 | |
| *** henrynash has quit IRC | 00:49 | |
| *** viswanathsomanch has joined #openstack-keystone | 01:36 | |
| *** viswanathsomanch has quit IRC | 01:37 | |
| *** viswanathsomanch has joined #openstack-keystone | 01:37 | |
| *** viswanathsomanch has quit IRC | 01:38 | |
| *** viswanathsomanch has joined #openstack-keystone | 01:38 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 01:49 | |
| *** diegows has quit IRC | 02:23 | |
| *** viswanathsomanch has quit IRC | 02:40 | |
| *** alex_xu has joined #openstack-keystone | 02:52 | |
| *** alex_xu has quit IRC | 02:57 | |
| *** alex_xu has joined #openstack-keystone | 03:10 | |
| *** dims__ has quit IRC | 03:12 | |
| *** dims__ has joined #openstack-keystone | 03:12 | |
| *** stevemar has quit IRC | 03:56 | |
| *** stevemar has joined #openstack-keystone | 03:56 | |
| *** viswanathsomanch has joined #openstack-keystone | 04:07 | |
| *** alex_xu has quit IRC | 04:31 | |
| *** alex_xu has joined #openstack-keystone | 04:31 | |
| *** stevemar has quit IRC | 04:42 | |
| *** k4n0 has joined #openstack-keystone | 04:44 | |
| *** amerine has quit IRC | 05:23 | |
| *** ajayaa has joined #openstack-keystone | 05:50 | |
| *** jaosorior has joined #openstack-keystone | 06:01 | |
| *** ajayaa has quit IRC | 06:10 | |
| *** ukalifon1 has joined #openstack-keystone | 06:13 | |
| *** ajayaa has joined #openstack-keystone | 06:23 | |
| *** viswanathsomanch has quit IRC | 06:32 | |
| *** ajayaa has quit IRC | 06:37 | |
| *** amirosh has joined #openstack-keystone | 06:55 | |
| *** ajayaa has joined #openstack-keystone | 07:01 | |
| *** afazekas has joined #openstack-keystone | 07:02 | |
| *** nikunj2512 has joined #openstack-keystone | 07:04 | |
| nikunj2512 | what is different between update_password & update_own_password methods in keystoneclient> | 07:05 |
|---|---|---|
| nikunj2512 | ? | 07:05 |
| *** henrynash has joined #openstack-keystone | 07:29 | |
| *** henrynash has quit IRC | 07:42 | |
| *** miqui has quit IRC | 07:54 | |
| *** henrynash has joined #openstack-keystone | 08:21 | |
| *** boris-42 has joined #openstack-keystone | 08:27 | |
| *** ukalifon1 has quit IRC | 08:29 | |
| *** jcastro has joined #openstack-keystone | 08:31 | |
| *** jcastro has quit IRC | 08:32 | |
| *** jcastro has joined #openstack-keystone | 08:32 | |
| *** jcastro has quit IRC | 08:33 | |
| *** jcastro has joined #openstack-keystone | 08:34 | |
| *** jcastro has quit IRC | 08:34 | |
| *** jcastro has joined #openstack-keystone | 08:35 | |
| *** jcastro has quit IRC | 08:36 | |
| *** jcastro has joined #openstack-keystone | 08:37 | |
| *** ajayaa has quit IRC | 08:37 | |
| *** jcastro is now known as josecastroleon | 08:39 | |
| *** josecastroleon has quit IRC | 08:40 | |
| *** josecastroleon has joined #openstack-keystone | 08:40 | |
| *** ajayaa has joined #openstack-keystone | 09:02 | |
| *** ajayaa has quit IRC | 09:07 | |
| *** ukalifon has joined #openstack-keystone | 09:11 | |
| *** alex_xu has quit IRC | 09:17 | |
| *** aix has joined #openstack-keystone | 09:17 | |
| *** nellysmitt has joined #openstack-keystone | 09:25 | |
| *** jistr has joined #openstack-keystone | 09:27 | |
| *** ajayaa has joined #openstack-keystone | 09:32 | |
| *** henrynash has quit IRC | 09:55 | |
| *** henrynash has joined #openstack-keystone | 09:55 | |
| *** henrynash has quit IRC | 10:00 | |
| *** nellysmitt has quit IRC | 10:26 | |
| *** nellysmitt has joined #openstack-keystone | 10:38 | |
| *** diegows has joined #openstack-keystone | 10:50 | |
| *** aix has quit IRC | 11:02 | |
| *** dims__ has quit IRC | 11:08 | |
| *** dims__ has joined #openstack-keystone | 11:08 | |
| *** nellysmitt has quit IRC | 11:14 | |
| *** nellysmitt has joined #openstack-keystone | 11:17 | |
| *** aix has joined #openstack-keystone | 11:29 | |
| *** nikunj2512 has quit IRC | 11:34 | |
| *** nellysmitt has quit IRC | 11:38 | |
| *** nellysmitt has joined #openstack-keystone | 11:39 | |
| *** ajayaa has quit IRC | 11:47 | |
| *** nellysmitt has quit IRC | 11:49 | |
| *** afazekas is now known as afazekas_on_food | 11:54 | |
| *** ajayaa has joined #openstack-keystone | 11:59 | |
| *** nikunj2512 has joined #openstack-keystone | 12:10 | |
| *** boris-42 has quit IRC | 12:17 | |
| *** henrynash has joined #openstack-keystone | 12:20 | |
| *** raildo has joined #openstack-keystone | 12:25 | |
| ekarlso | jamielennox|away: ping | 12:27 |
| *** amakarov has joined #openstack-keystone | 12:31 | |
| *** henrynash has quit IRC | 12:32 | |
| *** nellysmitt has joined #openstack-keystone | 12:45 | |
| *** pc-m has joined #openstack-keystone | 12:49 | |
| *** htruta has joined #openstack-keystone | 12:51 | |
| *** henrynash has joined #openstack-keystone | 12:55 | |
| henrynash | marekd: ping | 12:57 |
| *** mflobo has joined #openstack-keystone | 13:02 | |
| mflobo | Is there some schelude for python-keystoneclient deprecation? https://launchpad.net/python-keystoneclient/+milestone/1.0.0 | 13:03 |
| marekd | henrynash: hey | 13:14 |
| *** afazekas_on_food is now known as afazekas | 13:15 | |
| *** henrynash has quit IRC | 13:19 | |
| *** dims__ has quit IRC | 13:29 | |
| *** dims has joined #openstack-keystone | 13:30 | |
| *** elynn_ has joined #openstack-keystone | 13:37 | |
| marekd | henrynash: ping | 13:41 |
| *** boris-42 has joined #openstack-keystone | 13:48 | |
| *** jistr has quit IRC | 13:55 | |
| *** amirosh has quit IRC | 13:56 | |
| *** jistr has joined #openstack-keystone | 13:57 | |
| *** openstackgerrit has joined #openstack-keystone | 14:04 | |
| *** pc-m has quit IRC | 14:07 | |
| *** amakarov has quit IRC | 14:14 | |
| *** p01s0n has joined #openstack-keystone | 14:23 | |
| *** amakarov has joined #openstack-keystone | 14:28 | |
| lbragstad | morganfainberg: pong (from rogue ping above ^^), not sure if that was from the summit or not? | 14:29 |
| openstackgerrit | Marek Denis proposed a change to openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 14:31 |
| *** elynn_ has quit IRC | 14:31 | |
| rodrigods | marekd, thanks! was fixing that error right now =) | 14:35 |
| marekd | rodrigods: ah, sorry ;/ | 14:35 |
| marekd | hope this will work now. | 14:35 |
| rodrigods | marekd, np, you saved some minutes here =), about here https://review.openstack.org/#/c/133130/5/keystone/tests/config_files/test_auth_plugin.conf, I think it must be "oidc" | 14:36 |
| marekd | rodrigods: yes yes, but i feel this should be aother patch (build on top of this one) | 14:37 |
| marekd | i can add it now. | 14:38 |
| rodrigods | marekd, ++ | 14:38 |
| marekd | rodrigods: once i am back in Geneva I will have time to read carefully your blog post. | 14:39 |
| marekd | rodrigods: ah, and thanks for that: https://review.openstack.org/#/c/130564/ | 14:39 |
| rodrigods | marekd, great! np, just a quick rebase | 14:42 |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone-specs: Authenticated Encryption Tokens https://review.openstack.org/130050 | 14:44 |
| *** joesavak has joined #openstack-keystone | 14:51 | |
| *** ajayaa has quit IRC | 14:53 | |
| openstackgerrit | Marek Denis proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 14:56 |
| marekd | rodrigods: ^^ | 14:56 |
| *** pc-m has joined #openstack-keystone | 14:56 | |
| lbragstad | dstanek: are you migrating unit tests to keystone/tests/unit/ in any particular order? | 14:56 |
| *** htruta has quit IRC | 14:58 | |
| *** saipandi has joined #openstack-keystone | 15:06 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:08 | |
| *** saipandi has quit IRC | 15:10 | |
| openstackgerrit | Marek Denis proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 15:11 |
| *** topol has joined #openstack-keystone | 15:12 | |
| *** henrynash has joined #openstack-keystone | 15:14 | |
| *** k4n0 has quit IRC | 15:14 | |
| *** ukalifon has quit IRC | 15:17 | |
| *** p01s0n has quit IRC | 15:20 | |
| *** nikunj2512 has quit IRC | 15:20 | |
| *** jistr has quit IRC | 15:30 | |
| marekd | dolphm: ping. | 15:30 |
| *** jistr has joined #openstack-keystone | 15:32 | |
| marekd | dolphm: so, during mid cycle meetun in TX there was some long discussion about proper method name for all federated auth methods. I have a string feeling that we were talking that all of them should be named 'mapped', however, the code seems to keep per protocol name. Can you recall such ideas for using one generic 'mapping' auth method? | 15:32 |
| *** zzzeek has joined #openstack-keystone | 15:32 | |
| marekd | rodrigods: no, DAvid says what I said earlier today | 15:36 |
| marekd | rodrigods: use one mapping auth method and call it 'mapped' | 15:36 |
| marekd | rodrigods: for some reason this sits deeply somewhere in my head | 15:36 |
| *** ajayaa has joined #openstack-keystone | 15:39 | |
| rodrigods | marekd, hmm cool | 15:39 |
| rodrigods | marekd, let's see what will be decision this time | 15:39 |
| marekd | rodrigods: this is all more like academic talk. | 15:41 |
| marekd | rodrigods: he is right at some point, but....do you want to put auth method to 'modshib' ? | 15:42 |
| marekd | rodrigods: it's stupid | 15:42 |
| rodrigods | marekd, and strongly "connects" with Apache only stuff | 15:43 |
| marekd | rodrigods: i doubt there is apache alternative atm. | 15:45 |
| marekd | but essentially you are right. | 15:45 |
| rodrigods | marekd, i think i saw keystone + ngnix stuff somewhere (probably online tutorials) | 15:45 |
| rodrigods | anyway... | 15:45 |
| marekd | rodrigods: now, i'd rather say: use auth methods like saml2, oidc but call classes plugin specific (if needed): MappedShibboleth, MappedWeirdApachePlugin etc | 15:46 |
| marekd | then yo will have a strong connection between plugin handlig input from a specific apache module. | 15:46 |
| *** Viswanath has joined #openstack-keystone | 15:47 | |
| rodrigods | marekd, since are plugins, lgtm | 15:47 |
| *** Viswanath has quit IRC | 15:50 | |
| *** ajayaa has quit IRC | 15:52 | |
| *** jistr has quit IRC | 15:52 | |
| *** jistr has joined #openstack-keystone | 15:53 | |
| marekd | henrynash: ping. | 15:53 |
| henrynash | marked: hi | 15:53 |
| marekd | henrynash: a question. Is OS-INHERIT different on putting role assignments on a domain and a user? | 15:54 |
| marekd | henrynash: if i put a role on a user marek and domain pepsi | 15:54 |
| henrynash | marked: not sure I understand the question | 15:54 |
| henrynash | marked: ok | 15:54 |
| henrynash | marked: it can be inherted or non-inherited | 15:55 |
| marekd | ok, what can is do concerning domains/ role assignments without OS-INHERIT? | 15:55 |
| henrynash | marked: so without OS-INHERIT, anyting you can assign to a proejct you can also assign to a domain | 15:55 |
| henrynash | marked: i.e. a user role or a group role | 15:55 |
| marekd | henrynash: ok, lets sa i will assign role member on my user and a domain | 15:56 |
| henrynash | marked: with OS-INHERIT, on a per assignmnet basis, you can decide if that assignment should be inherited or not | 15:56 |
| henrynash | marked: ok | 15:56 |
| marekd | henrynash: this would mean that my user will have role member on every project in that domain? | 15:56 |
| *** wwriverrat has joined #openstack-keystone | 15:56 | |
| henrynash | marked: ONLY if you explicitely mark teh assignment as inherited at the time of creating the assignment | 15:57 |
| henrynash | marked: it’s a boolean you pass to the create_grant API | 15:57 |
| *** wwriverrat has left #openstack-keystone | 15:57 | |
| *** Viswanath has joined #openstack-keystone | 15:57 | |
| marekd | henrynash: and this is core of OS-INHERIT | 15:57 |
| henrynash | marked: (Actually I think it’s a string, but same idea) | 15:57 |
| marekd | henrynash: so, lets say i would have that role member on a domain withut inheritance enabled - is there any place i can use it? | 15:58 |
| henrynash | marked: on the domain…i.e. in a domain scoped token | 15:58 |
| henrynash | marked: for instance, a role taht allows you to create users in that domain | 15:59 |
| marekd | henrynash: yeah, but what can i do with that? i guess nothing | 15:59 |
| henrynash | marked: or manage grousp | 15:59 |
| henrynash | marked: or create projects | 15:59 |
| henrynash | marked: user on-boarding is the classic example | 15:59 |
| marekd | henrynash: i thought this would be more a work for admin not average member, but we are talking theory here. | 16:00 |
| henrynash | marekd:…and of couse the domain admin IS mosy likely a role on the domain | 16:00 |
| marekd | so, only with os-inherit me having a member role in a domain will mean that i am a member in every project => i can even boot a machine there. | 16:00 |
| henrynash | marked: correct | 16:01 |
| *** Viswanath has quit IRC | 16:01 | |
| marekd | is this role assignment resolved dynamically? | 16:01 |
| henrynash | marked: yes | 16:01 |
| henrynash | marekd: yes | 16:01 |
| henrynash | marekd: when we build a token (scoped to a project), we check the project domain to see if the user has a role on that | 16:02 |
| marekd | which is either a role assignment specifically for that user and project, or inherited role assignment for a domain and that user. | 16:04 |
| marekd | henrynash: ^^ | 16:04 |
| henrynash | marked:… or a group role, of which the user is a member, on either | 16:05 |
| marekd | ah, yes, forgot the groups. | 16:05 |
| marekd | henrynash: ok, thanks, it clarifies a little bit. | 16:06 |
| henrynash | marekd: np | 16:06 |
| *** Viswanath has joined #openstack-keystone | 16:08 | |
| marekd | henrynash: one more question. So, once I have domain role which is inherited I should see this role while listing it or a that role assigned to all projects from this domain? | 16:08 |
| *** htruta has joined #openstack-keystone | 16:09 | |
| henrynash | marekd: you mean in a keystone api call? | 16:09 |
| marekd | henrynash: yes, for instance when I will be listing my role assignments. | 16:10 |
| henrynash | marekd: syes…but yor need to make sure you use the API properly… i | 16:11 |
| henrynash | marekd: e.g. call list_role_assignments with the ?effective filter on it | 16:11 |
| henrynash | marekd: which will tell it to give the list of “effective” rolea ssignments on a given project | 16:12 |
| marekd | henrynash: so, for instance here: https://review.openstack.org/#/c/132826/2/keystone/tests/test_v3_federation.py the test from line 1079 should fail because scoping to a domain should be not allowed, because the roles are inheriting to a project, right? | 16:13 |
| henrynash | marekd: if you call list_grants, then it will show you the explicit grants…i.e. you WON’T see the inherited role show up on the project, since that API is designed to manage the grants themselves | 16:13 |
| henrynash | marekd: exactly | 16:14 |
| *** Viswanath has quit IRC | 16:14 | |
| marekd | and without inheriting i'd get role assignments on domain, but not on project. | 16:14 |
| marekd | (just making sure i understand it completely) | 16:14 |
| marekd | henrynash: so, for an admin, who should be able to a) manage domain projects/users b) maanage projects (like evacuate vms from projects) i need two role assignments - one with inheriting to projects and another one *not* inheriting to projects? | 16:16 |
| henrynash | marekd: well the grant made to the domain would have been marked explictly as inherited or not (at the time teh grant was made)….the bug was that we weren’t honouring the flag when we searched for roles | 16:16 |
| henrynash | marekd: yes, although might well want to have separate “roles” for those two administrative duties…rather than use the same role name | 16:17 |
| marekd | henrynash: ok, i might bug you about it later. Thanks for now! | 16:18 |
| henrynash | marekd: say role “user_manager” non-inherited on the domain, and “vm_manager” assigned as inherited on the domain (and hence effective on projects_ | 16:18 |
| *** afazekas has quit IRC | 16:21 | |
| *** thedodd has joined #openstack-keystone | 16:22 | |
| *** wwriverrat has joined #openstack-keystone | 16:22 | |
| *** wwriverrat has left #openstack-keystone | 16:23 | |
| *** stevemar has joined #openstack-keystone | 16:36 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 16:37 |
| raildo | morganfainberg, ping | 16:38 |
| *** richm has joined #openstack-keystone | 16:38 | |
| *** thedodd has quit IRC | 16:42 | |
| *** thedodd has joined #openstack-keystone | 16:44 | |
| *** marcoemorais has joined #openstack-keystone | 16:44 | |
| *** gyee has joined #openstack-keystone | 16:45 | |
| *** nkinder has joined #openstack-keystone | 16:52 | |
| *** amerine has joined #openstack-keystone | 17:00 | |
| *** _cjones_ has joined #openstack-keystone | 17:00 | |
| *** jsavak has joined #openstack-keystone | 17:01 | |
| *** joesavak has quit IRC | 17:04 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: Ensure controllers and managers reference new resource manager. https://review.openstack.org/133525 | 17:05 |
| *** wwriverrat1 has joined #openstack-keystone | 17:22 | |
| *** jaosorior has quit IRC | 17:23 | |
| *** ajayaa has joined #openstack-keystone | 17:24 | |
| *** wwriverrat1 has left #openstack-keystone | 17:24 | |
| *** Viswanath has joined #openstack-keystone | 17:29 | |
| *** saipandi has joined #openstack-keystone | 17:30 | |
| *** marcoemorais has quit IRC | 17:30 | |
| *** marcoemorais has joined #openstack-keystone | 17:30 | |
| *** marcoemorais has quit IRC | 17:31 | |
| *** marcoemorais has joined #openstack-keystone | 17:31 | |
| openstackgerrit | ayoung proposed a change to openstack/keystone-specs: WebSSO https://review.openstack.org/133529 | 17:32 |
| *** ayoung has joined #openstack-keystone | 17:32 | |
| *** Viswanath has quit IRC | 17:34 | |
| *** marcoemorais has quit IRC | 17:36 | |
| *** marcoemorais has joined #openstack-keystone | 17:36 | |
| ayoung | nkinder, https://review.openstack.org/#/c/133529/ I tried to break it down as fine as possible. | 17:37 |
| henrynash | ayoung, morganfainberg, dstanek, stevemar, bknudson, lbragstad: have a long series of dependant patches that fix a series of defects that I suspect we will want to backport…if you have time if you could follow teh chain up from https://review.openstack.org/#/c/132826/ that would be great | 17:37 |
| *** david-lyle has joined #openstack-keystone | 17:38 | |
| morganfainberg | Morning. | 17:38 |
| morganfainberg | raildo: pong | 17:38 |
| *** marcoemorais has quit IRC | 17:38 | |
| morganfainberg | raildo: I need to run shortly but can respond later. | 17:38 |
| morganfainberg | If you're not here right now. | 17:38 |
| *** marcoemorais has joined #openstack-keystone | 17:38 | |
| raildo | ok, just a doubt | 17:38 |
| morganfainberg | raildo: go for it. | 17:39 |
| raildo | i have to create one spec for all discussion about HM | 17:39 |
| raildo | ? | 17:39 |
| raildo | or a have to create a spec for update discussion, delete discussion, reseller... | 17:39 |
| morganfainberg | raildo: well we have the one for the current stuff. | 17:39 |
| morganfainberg | The reseller stuff needs a new spec specifically. | 17:40 |
| ayoung | morganfainberg, https://review.openstack.org/#/c/133529/ bascially needs token-provider-as-pipeline. | 17:40 |
| raildo | morganfainberg, ok | 17:40 |
| ayoung | I think I can do it without too much rewriting | 17:40 |
| raildo | so, i will create two specs, one for reseller use case, and other for HM stuffs | 17:40 |
| morganfainberg | raildo: wait. What other hm stuff? | 17:41 |
| rodrigods | raildo, there is also the schema evolution: regarding scalability (dolph's blog post) | 17:41 |
| raildo | this link? http://dolphm.com/hierarchical-multitenancy/ | 17:41 |
| htruta | rodrigods: I don't think this is the current priority | 17:41 |
| rodrigods | htruta, I mean, where it is gonna be placed (spec) | 17:42 |
| rodrigods | we need to have the update leaf projects stuff | 17:42 |
| rodrigods | even it is not going to be implemented right now | 17:42 |
| morganfainberg | ayoung: let me discuss that with you when I'm not on my phone. Will be setup to talk later today. | 17:42 |
| raildo | morganfainberg, the other hm stuff = recursive deletion, update project, quotas... | 17:42 |
| htruta | rodrigods: yeah, sure | 17:43 |
| ayoung | morganfainberg, sounds good. | 17:43 |
| morganfainberg | ayoung: a little jet lagged - just got home at 1am this morning. | 17:43 |
| ayoung | Heh | 17:43 |
| ayoung | morganfainberg, bummer about bailing on your trip. | 17:43 |
| morganfainberg | ayoung: eh better than really injuring myself right? Can always vacation else time. | 17:44 |
| ayoung | morganfainberg, not if CERN releases the Higgs Bosun on us all and destroys the planet | 17:44 |
| ayoung | raildo, reseller: we are going to cut at domains, right? Some sort of property on a domain object that says "people above this line can't see things below this line...." | 17:46 |
| raildo | ayoung, right | 17:46 |
| morganfainberg | ayoung: yes. The namespace roles is something (the bigger part) that henrynash is working on. | 17:47 |
| ayoung | raildo, I like this. | 17:47 |
| raildo | morganfainberg, ++ | 17:47 |
| morganfainberg | Reseller doesn't work w/o that. | 17:47 |
| *** Viswanath has joined #openstack-keystone | 17:47 | |
| htruta | ayoung: it will be optional, right? | 17:48 |
| htruta | And will the domain owner also be able to give some kind of temporary access to the reseller in case things go wrong? | 17:48 |
| *** joesavak has joined #openstack-keystone | 17:49 | |
| morganfainberg | raildo: so yes we need a reseller spec that depends on/works with Henry's work(might be 1 spec). But the other items might need smaller specs. Eg: update (change hierarchy for leaf nodes and recursive delete). Then we have quota | 17:49 |
| morganfainberg | raildo: does that breakdown make sense? | 17:50 |
| raildo | morganfainberg, great. I'll talk with henrynash later | 17:50 |
| morganfainberg | htruta: yes it is optional and yes you can grant a role to someone to help fix. | 17:51 |
| raildo | thank you | 17:51 |
| morganfainberg | raildo: the update / delete one is one spec (if that wasn't clear) | 17:51 |
| morganfainberg | ayoung: I also have not read your email on trusts. Was flying near 100% of yesterday. | 17:51 |
| ayoung | morganfainberg, no problem. | 17:52 |
| *** jsavak has quit IRC | 17:52 | |
| morganfainberg | ayoung: reminds me. Need to send the reminder email tomorrow's meeting is cancelled. | 17:52 |
| raildo | morganfainberg,ok, I get it. I'll start with the part of update/delete which is simpler and then I talk to henrynash about the reseller | 17:53 |
| ayoung | morganfainberg, why cancel it? We can hold. I suspect there is enough to discuss | 17:53 |
| morganfainberg | ayoung: we just did a full week of in-person face to face work. I think there isn't a lot to discuss directly that can't be a smaller crowd on IRC. | 17:54 |
| ayoung | morganfainberg, maybe focus on "who is doing what, and what is not going to get done?" | 17:55 |
| morganfainberg | Or via email. Would you say the same thing if the meeting was today? | 17:55 |
| ayoung | morganfainberg, possibly. I'm still trying to pull together the details from last week, but that will likely be the case for a while. | 17:56 |
| openstackgerrit | Marek Denis proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 17:56 |
| ayoung | Perhaps a summary for people that were not able to make it to the summit, or a pointer to the artifacts would be in order. | 17:56 |
| ayoung | maybe a Q&A meeting for people to inquire about details? | 17:57 |
| morganfainberg | ayoung: largely the same and I'm try to write up summary of our sessions to publish. | 17:57 |
| ayoung | fair enough. I'm willing to stand by IRC for an hour to field questions about the summit sessions for people that weren't there | 17:57 |
| morganfainberg | ayoung: my thought is we will largely do that next week with some summary of the sessions already written up. | 17:58 |
| *** Viswanath has quit IRC | 17:59 | |
| morganfainberg | I think the benefit will be bigger that way. Besides, we all *do* have things to do that don't need lots of extra discussion (review HM stuff, spec writing etc - some things are absolutely on the deck for kilo) | 18:00 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone-specs: API documentation for Hierarchical Multitenancy https://review.openstack.org/130103 | 18:01 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone-specs: API documentation for Inherited Roles to Projects https://review.openstack.org/130277 | 18:01 |
| raildo | morganfainberg, ++ | 18:01 |
| *** jistr has quit IRC | 18:02 | |
| *** Viswanath has joined #openstack-keystone | 18:02 | |
| rodrigods | morganfainberg, raildo, reseller is for Kilo? | 18:03 |
| raildo | rodrigods, yes | 18:03 |
| morganfainberg | rodrigods: I would hope so :) | 18:03 |
| rodrigods | morganfainberg, raildo, nice | 18:04 |
| rodrigods | busy is good =) | 18:04 |
| *** marcoemorais has quit IRC | 18:05 | |
| *** marcoemorais has joined #openstack-keystone | 18:05 | |
| *** Viswanath has quit IRC | 18:07 | |
| *** marcoemorais has quit IRC | 18:08 | |
| marekd | rodrigods: one more comment regarding fed auth methods | 18:08 |
| marekd | and we should be good to fo. | 18:09 |
| marekd | go | 18:09 |
| *** marcoemorais has joined #openstack-keystone | 18:09 | |
| *** marcoemorais has quit IRC | 18:09 | |
| *** marcoemorais has joined #openstack-keystone | 18:09 | |
| *** Viswanath has joined #openstack-keystone | 18:15 | |
| rodrigods | marekd, is it ok to put 'List of federation authentication methods. It must be a subset of \'methods\' list. Examples: \'saml2, oidc\'' (backslashed) ? | 18:16 |
| rodrigods | marekd, the generated conf looks good IMO | 18:18 |
| rodrigods | will update the patchset | 18:18 |
| *** marcoemorais has quit IRC | 18:18 | |
| *** thedodd has quit IRC | 18:19 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 18:19 |
| *** Viswanath has quit IRC | 18:19 | |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 18:20 |
| *** marcoemorais has joined #openstack-keystone | 18:21 | |
| *** marcoemorais has quit IRC | 18:24 | |
| *** marcoemorais has joined #openstack-keystone | 18:24 | |
| *** diegows has quit IRC | 18:29 | |
| *** saipandi has quit IRC | 18:34 | |
| *** jistr has joined #openstack-keystone | 18:37 | |
| *** Viswanath has joined #openstack-keystone | 18:42 | |
| *** thedodd has joined #openstack-keystone | 18:42 | |
| *** jaosorior has joined #openstack-keystone | 18:44 | |
| *** amcrn has joined #openstack-keystone | 18:44 | |
| *** Viswanath has quit IRC | 18:44 | |
| *** saipandi has joined #openstack-keystone | 18:45 | |
| *** diegows has joined #openstack-keystone | 18:46 | |
| *** aix has quit IRC | 18:48 | |
| *** Viswanath has joined #openstack-keystone | 18:48 | |
| *** wwriverrat has joined #openstack-keystone | 18:50 | |
| *** wwriverrat has left #openstack-keystone | 18:50 | |
| *** diegows has quit IRC | 18:51 | |
| *** Viswanath has quit IRC | 18:54 | |
| *** jsavak has joined #openstack-keystone | 18:59 | |
| *** joesavak has quit IRC | 19:01 | |
| *** jsavak has quit IRC | 19:05 | |
| *** joesavak has joined #openstack-keystone | 19:09 | |
| *** diegows has joined #openstack-keystone | 19:11 | |
| *** Viswanath has joined #openstack-keystone | 19:12 | |
| *** Viswanath has quit IRC | 19:17 | |
| *** amakarov is now known as amakarov_away | 19:19 | |
| *** Viswanath has joined #openstack-keystone | 19:27 | |
| *** Viswanath has quit IRC | 19:33 | |
| *** ajayaa has quit IRC | 19:33 | |
| *** rwsu has joined #openstack-keystone | 19:35 | |
| ayoung | nonameentername, so...MFA. as Goldman once penned "I do not think it means what you think it means." | 19:41 |
| ayoung | To wit: I think that MFA to create a token is not really MFA once you present the (bearer) token to the end service | 19:42 |
| lbragstad | ayoung: nonameentername is still bouncing around Europe somewhere.. | 19:42 |
| gyee | MFA is a concept, not a protocol | 19:43 |
| ayoung | gyee, um, ok. Its still not implemented with bearer tokens | 19:44 |
| ayoung | gyee, lets say you want to do a nova boot. The user should authenticate to Nova with multiple factors, not to Keystone | 19:45 |
| lbragstad | so... | 19:45 |
| lbragstad | that would be MFA for *every* operation | 19:45 |
| gyee | ayoung, definitely not bearer token | 19:46 |
| ayoung | lbragstad, no, but I would say for the first operation, and then require TLS and session reuse | 19:47 |
| *** marcoemorais has quit IRC | 19:47 | |
| lbragstad | so, use MFA for the authenticate call | 19:47 |
| *** marcoemorais has joined #openstack-keystone | 19:47 | |
| lbragstad | and then use that token for booting a server in Nova | 19:47 |
| ayoung | lbragstad, and then when someone steals that token> | 19:47 |
| ayoung | you have no MFA | 19:48 |
| gyee | but token and MFA are two different thing, once you get a token, MFA is out of the picture | 19:48 |
| gyee | unless we are taking about replacing token with MFA | 19:49 |
| gyee | talking | 19:49 |
| ayoung | http://epeus.blogspot.com/2002/12/douglas-adams-on-digital-id.html | 19:50 |
| ayoung | once you have a token, security is out of the picture | 19:51 |
| *** Viswanath has joined #openstack-keystone | 19:51 | |
| gyee | for bearer token yes | 19:51 |
| *** Viswanath has quit IRC | 19:53 | |
| lbragstad | isn't that the case with all bearer tokens? Once it's compromised, it's compromised... | 19:54 |
| ayoung | lbragstad, We should be authenticating to the services themselves, not just to Keystone | 19:54 |
| gyee | simple, 2 way SSL :) | 19:54 |
| ayoung | lbragstad, Keystone really should just be saying "if the user is really who they claim to be, then here is what roles they should have" | 19:55 |
| ayoung | gyee, yep | 19:55 |
| ayoung | 2ways SSL | 19:55 |
| ayoung | or TLS since SSL is now a dirty word | 19:55 |
| gyee | haha | 19:55 |
| ayoung | stevemar, https://review.openstack.org/#/c/133037/ you don't need mapped. You can use the external plugin | 19:59 |
| ayoung | gyee, then MFA would be a second factor after client cert, right? | 20:00 |
| gyee | ayoung, no, MFA usually involves one time passcode | 20:04 |
| gyee | pin + one time passcode | 20:04 |
| gyee | pin is something you know | 20:05 |
| gyee | one time passcode comes from something you have (keyfab) | 20:06 |
| lbragstad | or could be generated based on a time algorithm or HMAC | 20:07 |
| lbragstad | TOTP (time-based) or HOTP (HMAC-based) | 20:07 |
| gyee | right | 20:08 |
| *** david-lyle has quit IRC | 20:08 | |
| *** marcoemorais has quit IRC | 20:09 | |
| *** marcoemorais has joined #openstack-keystone | 20:10 | |
| stevemar | ayoung, most of the apache module for federation end up setting REMOTE_USER to some value, so we still want to use the mapping engine for the other properties | 20:11 |
| ayoung | stevemar, I'm missing something then, as I thought that REMOTE_USER would be one of the inputs to the mapper anyway. | 20:12 |
| marekd | ayoung: external simply takes REMOTE_USER value and does the user lookup in the db i think | 20:13 |
| ayoung | yeah, pretty much | 20:13 |
| marekd | ayoung: which is clearly not stevemar's case | 20:13 |
| stevemar | ayoung, right, this just makes the mapping even easier, so the admin doesn't have to specify the 'user' part of the rule | 20:13 |
| ayoung | I thought any input variables could be used in the mapping case? | 20:13 |
| morganfainberg | god i hope we're not talking about totp/hotp IN A TOKEN | 20:14 |
| gyee | mapping to groups is the right balance | 20:14 |
| morganfainberg | to get a token, sure. | 20:14 |
| gyee | its going to a foggin nightmare auditing the permissions if we do individual maps | 20:14 |
| gyee | morganfainberg, no, MFA is for auth only | 20:15 |
| gyee | authn | 20:15 |
| morganfainberg | good | 20:15 |
| * ayoung goggles hotp | 20:16 | |
| stevemar | ayoung, yes they can, this is just a convenience thing - rather than specifying that input variable in the mapping, if we notice REMOTE_USER + one of the federation protocols, then we can assume that's the user id | 20:16 |
| lbragstad | ayoung: http://www.ietf.org/rfc/rfc4226.txt | 20:16 |
| * gyee really hope *hotp* is not some pron site | 20:16 | |
| *** gmurphy has left #openstack-keystone | 20:17 | |
| morganfainberg | ayoung, hotp = 1 time use | 20:17 |
| morganfainberg | ayoung, totp = time based (what you think of when someone says google authenticator, even though it can do hotp as well) | 20:17 |
| ayoung | I got the OTP part | 20:17 |
| morganfainberg | it's HMAC One Time Password | 20:17 |
| ayoung | as opposed to totp which is time based | 20:18 |
| lbragstad | right, so it's based on increments | 20:18 |
| morganfainberg | yep | 20:18 |
| morganfainberg | hotp is still time-based, but it has an incrementing identifier each time you burn a token (create it) | 20:18 |
| morganfainberg | so your token + server need to be in sync (there is magic to try multiples from the server side to help limit "issues") | 20:19 |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 20:19 | |
| ayoung | OK...so last week, I realized we should unify role-assignements, trusts, and oauth all into one single delegation mechanism. Tokens are kindof one of those two, but tokens are dumb and should just go away. We should instead provide a mechanism for the users to authenticate to the services themselves, and provide a pointer to a delegation agreement | 20:19 |
| ayoung | if you were to think: authenticate with X509 + trustID, you wouldn't be far off | 20:19 |
| morganfainberg | we talked about this one right? | 20:20 |
| ayoung | Keystone gets out of the authentication business except for the case where Keystone is itself the IdP | 20:20 |
| * morganfainberg tries to beat back jetlag | 20:20 | |
| *** r1chardj0n3s has left #openstack-keystone | 20:20 | |
| morganfainberg | this is all sounding *very* similar to about 3 conversations | 20:20 |
| ayoung | and for those cases, we use Barbiacn in CA mode to issue an X509 | 20:20 |
| morganfainberg | 1 of which was over congac | 20:20 |
| gyee | heh | 20:20 |
| ayoung | Was not Cognac. Amarac? | 20:21 |
| gyee | I don't remember that conversation | 20:21 |
| lbragstad | +1 for "Bar Track Design Session" | 20:21 |
| lbragstad | we fixed all the problems | 20:21 |
| lbragstad | but we can't remember how... | 20:21 |
| gyee | damn straight! | 20:21 |
| ayoung | Armagnac | 20:22 |
| lbragstad | :) | 20:22 |
| morganfainberg | ayoung, well i drank plenty of both | 20:23 |
| morganfainberg | lbragstad, #afterstack | 20:23 |
| ayoung | morganfainberg, I cannot speak to the Cognac discussions then. Only the Armagnac one | 20:23 |
| morganfainberg | ayoung, i think the armagnac was the second drink that night, you had beer prior and i cognac | 20:24 |
| ayoung | Ah | 20:24 |
| morganfainberg | ayoung, anyway | 20:24 |
| morganfainberg | fwiw i did get my whiskey fix as well ... just day 2 afterstack ;) | 20:24 |
| ayoung | Anyway, the only reason we have tokens as a proxy for authentication is because ... | 20:24 |
| ayoung | NIH? | 20:25 |
| ayoung | NIMH? | 20:25 |
| morganfainberg | well 2 thinks. | 20:25 |
| morganfainberg | things | 20:25 |
| morganfainberg | maybe 3 | 20:25 |
| ayoung | Little Speaking rats? | 20:25 |
| morganfainberg | 1) We don't have a good story for conveying the AuthN information outside of our AuthZ mechanism [this is largely historical and original design] | 20:26 |
| morganfainberg | 2) we already convey authz in a "workable" way (not good, but workable) so we imposed limits that made this proxy for authn reliable - think in the context of UUID tokens anyway to start | 20:26 |
| morganfainberg | 3) backwards compat - we can't break the contract (can't remove this mechanism) in the very short term | 20:27 |
| morganfainberg | we can provide a better alternative though. | 20:27 |
| morganfainberg | and i can't speak as to why it was done this way or not using some other standard/thing/something. predates my working on OpenStack. | 20:28 |
| ayoung | hmmm....OK. 1) There are preexisting mechanisms for that. If people care about security they should use them. 2) Yes, but the assumptions for when it is workable have never been explicitly stated. I think we've passed beyond them. 3) We don't need to break in order to provide a better mechanism, but we should have a moritorium on new features for tokens | 20:33 |
| ayoung | But here's a thought: A token is a delegation agreement. Not really diffferent than a role assignment or a trust | 20:34 |
| ayoung | If I ask Nova to boot a VM for me, It requires that I supply proof of an acceptable role assignment | 20:35 |
| ayoung | anything that fulfills that proof should be acceptable | 20:35 |
| ayoung | If I can authenticate to Nova, nova could even query Keystone for me | 20:35 |
| *** david-lyle has joined #openstack-keystone | 20:36 | |
| morganfainberg | ayoung, you were asking why, i was providing my understanding of hte context of where we were and why | 20:36 |
| ayoung | morganfainberg, it predates my involvement in Keystone as well, but I can deduce from what I know: it started with a single password file for one service, and then the need to share the password between services. As I recall, it was origianlly synchronized, and Keystone was the solution ot not copying the passwords around. | 20:37 |
| morganfainberg | sure. | 20:37 |
| *** afazekas has joined #openstack-keystone | 20:38 | |
| gyee | hey, tokens are mindnumbingly simple to use, isn't usability count for something? :) | 20:43 |
| gyee | just saying | 20:43 |
| ayoung | gyee, I think that is your way of saying you agree with me? | 20:46 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 20:47 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 20:47 |
| rodrigods | stevemar, marekd, ^ | 20:47 |
| ayoung | We have this bizarre suspension of skepticism when it comes to tokens. We don't just trust all of the service users, but then we blindly hand over tokens to them that have all powers for the users that request things | 20:47 |
| morganfainberg | ayoung, you are right and i want that solved regardless of if we change tokens | 20:48 |
| morganfainberg | ayoung, we *can* fix that even without ripping apart tokens | 20:49 |
| ayoung | morganfainberg, part of the problem is this: when a user goes direct to Nova, we understand that Nova already has full power over its resources. If it wanted to, it could kill all our VMs, create new ones, empty our quota, etc. Delegation Only comes in to play to convince Nova to do something on our behalf. | 20:49 |
| morganfainberg | ayoung, but it's a crossproject thing | 20:49 |
| morganfainberg | ayoung, it *might* be easier to rip apart tokens for it, just saying it's not the only way | 20:49 |
| ayoung | morganfainberg, So, there is certainly a place where tokens, even UUID tokens, are the most appropriate | 20:50 |
| ayoung | its for small, all in one deployments | 20:50 |
| morganfainberg | ayoung, i'm not arguing with you ;) | 20:50 |
| *** jamielennox|away is now known as jamielennox | 20:50 | |
| ayoung | and they avoid all the need for larger infrastructure, etc | 20:50 |
| ayoung | those cases could have been just as well handled by usind mod_auth_mysql | 20:51 |
| ayoung | or whatever it is called | 20:51 |
| ayoung | but for eventlet.... | 20:51 |
| morganfainberg | ayoung, i think we're on the same page for the most part | 20:52 |
| ayoung | It is the larger deployments that interest me | 20:52 |
| ayoung | and in the larger cases, deploying Kerberos or a CA is viable anyway | 20:52 |
| morganfainberg | and i think even in the medium cases it is likely as well | 20:52 |
| ayoung | yeah | 20:53 |
| morganfainberg | and if we have a super easy way to deploy <IDP>, it might be reasonable in the small cases as well. but we're talking down the line. solve the big cases and cascade it down | 20:53 |
| ayoung | So If a user can authenticate to Nova directly, they probably should do so. | 20:53 |
| morganfainberg | small deployments are served fine as is | 20:53 |
| morganfainberg | ok, so lets start small and build on this iteratively | 20:54 |
| ayoung | And then Keystone provides the authorization data...which is basically "this user has been delegated role R on project P | 20:54 |
| morganfainberg | yep. | 20:54 |
| *** arunkant has joined #openstack-keystone | 20:55 | |
| ayoung | so, lets staryt by unifying the delegation approach | 20:55 |
| morganfainberg | what are the steps we need to get there. | 20:55 |
| ayoung | trusts are a model of what we want: a chain from user to user of role delegations | 20:55 |
| morganfainberg | ok, so oauth (the separate table/thing), trusts, and role assignments? | 20:55 |
| ayoung | so when a role assignment happens, we start be keeping track of the trail | 20:55 |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Move functional tests to keystone/tests/functional https://review.openstack.org/133556 | 20:55 |
| lbragstad | marekd: stevemar ^ | 20:55 |
| ayoung | all assignments are delegations | 20:56 |
| lbragstad | stevemar: marekd on the federation stuff, WIP so you can get an idea of what I'm doing | 20:56 |
| morganfainberg | ayoung, great. can we make this a core part of assignment (leverage the "role assigment" api) not in os-trusts? | 20:56 |
| ayoung | and in order to do a delegation, you need to have the role being delegated | 20:56 |
| ayoung | yep | 20:56 |
| morganfainberg | perfect | 20:56 |
| marekd | lbragstad: thanks | 20:56 |
| *** arunkant has quit IRC | 20:56 | |
| ayoung | I think we want role inheritance first, so we can split a big role into multiple little ones | 20:57 |
| morganfainberg | we can mark os-trusts as deprecated then, since there is an alternative (we will need to update heat to use the alternative etc) | 20:57 |
| ayoung | not a hard requirement, but we'll want it soon | 20:57 |
| ayoung | otherwise we have to explicitly give the superadmin all of the roles we know about.... | 20:57 |
| morganfainberg | ayoung, lets have that come from henrynash's namespaced roles. | 20:57 |
| morganfainberg | ayoung, since initially we're levering it as a "grouping" capable | 20:57 |
| ayoung | kindof, but his is even more specific | 20:57 |
| morganfainberg | lets just work to make that the base construct across the board | 20:57 |
| ayoung | I think inheritnace is more basic, and namespaced builds on it | 20:58 |
| morganfainberg | so we don't have 2 ways we do the permission -> role X -> role-including-role-X | 20:58 |
| morganfainberg | but it can be the *same* internal structures | 20:58 |
| morganfainberg | just who "owns | 20:58 |
| morganfainberg | " the namespaced role is the difference. | 20:59 |
| ayoung | lets push namespaced roles to the side for a moment. I think they are a distraction right now. We'll come back to them in a bit | 20:59 |
| ayoung | lets start with where we are now | 20:59 |
| ayoung | 1. we start with an inventory of capabilties | 21:00 |
| morganfainberg | ayoung, my point was, lets make namespaced dependent on this, not separate - meaning it pushes namespaced to an easy addon | 21:00 |
| ayoung | agreed | 21:00 |
| ayoung | so the inventory can be done now | 21:00 |
| morganfainberg | but the "inherited" / "Hierarchical Roles" can be done separate from the delegation bit you're talking about | 21:00 |
| ayoung | with the caveat that we need to make sure we catch new things as they are added | 21:00 |
| ayoung | I don't think so.. hear me out | 21:00 |
| morganfainberg | trying to keep the work isolated to workable bits and not lumped onto you, me, or henry exclusively | 21:00 |
| morganfainberg | etc | 21:01 |
| ayoung | I think the inheritance thing needs to be first | 21:01 |
| ayoung | it can be really simple in a first implementation | 21:01 |
| *** gyee has quit IRC | 21:01 | |
| ayoung | because once we have the mechanisms, it gets much easier to morph | 21:01 |
| ayoung | lets say we have two roles, like we do today | 21:01 |
| ayoung | admin and member | 21:01 |
| ayoung | member can do a bunch of things, but admin can do all that and more | 21:02 |
| ayoung | so we start by mapping cpabilities to member, and the rest to admin, and saying that admin inherits from member | 21:02 |
| ayoung | So we have a three level hierarchy: admin, member, individual capability | 21:03 |
| morganfainberg | my biggest concern is i don't want to block the delegation work - it will be largely the same code - on cataloging the capabilities | 21:03 |
| morganfainberg | and capturing new capabilities | 21:03 |
| ayoung | I think we can parallelize, so long as we all understand where we are going | 21:03 |
| ayoung | I'm pulling this all together into a document, but it is getting big.... | 21:04 |
| morganfainberg | thats fine, again i *think* this can be done without blocking one side for the other except at certain merge points. | 21:04 |
| ayoung | Once I have the overall picture, we'll see finer and finer tasks that can be chipped off and implemented | 21:04 |
| ayoung | One question is whether to start by putting the implied roles in the token, and then moving that to the policy file once we have a mechanism for generating the policy file | 21:05 |
| morganfainberg | i think that is a call we can make, again, separate from the other code. | 21:06 |
| ayoung | namespaced roles will be tricky without the ability to compose them out of finer scoped roles...otherwise, the namespaced roles will end up in the policy file | 21:06 |
| morganfainberg | we already said the initial implementation of the namespaced roles will resolve to the underlying roles | 21:06 |
| ayoung | And I don't think we want full expansion of the role hierarchy in each token | 21:06 |
| morganfainberg | and we can't split a capability off the underlying role | 21:06 |
| ayoung | So we create an implicit role for each capability? | 21:07 |
| morganfainberg | it still relies on a rich role definition frmo the deployer to start | 21:07 |
| morganfainberg | you could. | 21:07 |
| *** topol has quit IRC | 21:07 | |
| *** raildo is now known as raildo_away | 21:08 | |
| morganfainberg | and the best part is it allows the deployer to even create the same effect the current admin/member role is today and communicate how to use the better role system | 21:08 |
| ayoung | morganfainberg, I did post the three-in-one review for policy here https://review.openstack.org/#/c/133480/ | 21:09 |
| morganfainberg | this is laying out the stepping stones to get us in the right place without breaking anyone. | 21:09 |
| ayoung | Maybe I should collect up all of the specs on policy into one review | 21:09 |
| morganfainberg | don't do that. | 21:09 |
| morganfainberg | please. | 21:09 |
| ayoung | https://review.openstack.org/#/c/125704/ is the other one | 21:09 |
| morganfainberg | make it a chain if they are dependent | 21:09 |
| ayoung | I'm not yet certain of the dependencies, or if they can be parallelized | 21:10 |
| morganfainberg | i can already say i am happy to comment but wont approve (and will block approval) if they are in all one review | 21:10 |
| morganfainberg | they *should* be separate reviews | 21:10 |
| ayoung | that is fine, and I can split them out when it makes sense to do so...wasn't even sure if they should be separate specs | 21:10 |
| morganfainberg | yeah. | 21:10 |
| morganfainberg | good for comment to start | 21:11 |
| morganfainberg | i also expect to spend most of tomorrow writting up the summaries of the summit. | 21:11 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 21:11 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 21:12 | |
| morganfainberg | so we'll have that as well. some of this will be included in that summary | 21:12 |
| ayoung | morganfainberg, actually, when you (others) do review, the ordering between the specs is probably one thing that you should evalutate | 21:12 |
| morganfainberg | ayoung, thats fine. | 21:12 |
| ayoung | I think the ordering is something like this: | 21:12 |
| ayoung | enforce policy in library is first | 21:12 |
| ayoung | fetch policy from keystone by that library is second | 21:13 |
| ayoung | unified policy file is third, but might be a requirement for the second step to be viable | 21:13 |
| morganfainberg | reminds me i need to ask dhellmann about timeline for fileutils to move out of incubator | 21:13 |
| morganfainberg | *and* if we need to split oslo.config dep off oslo.policy [To be renamed] | 21:13 |
| ayoung | generating policy file from Keystone is a possible fourth, and then hierarchical roles to feed in to that | 21:14 |
| morganfainberg | so uh.. dhellmann ^ ;) | 21:14 |
| ayoung | once we have those..."maintaing the delegation chain on role assignemnts" would be next | 21:14 |
| ayoung | unifying trust with role assignements would follow after that | 21:15 |
| ayoung | I don't think we would delegate trusts, though. Just make them an alternate mechanism for a temporary role assignment | 21:15 |
| ayoung | if "maintain the delegation chain on role assignments" gives each delegation a unique identifier, we could replace "call with a token" with "call with full authentication and delegation agreement" | 21:17 |
| morganfainberg | ayoung, i think trusts disappear | 21:17 |
| ayoung | and by replace I mean "either/or" | 21:17 |
| morganfainberg | ayoung, we just cant remove them until everyone is on the new system | 21:17 |
| morganfainberg | who is doing the redelegation work, cause that work doesn't go into trusts in this case. | 21:18 |
| ayoung | morganfainberg, so long as any thing we do with trusts can be handled by the role assignment/delegation system, sure | 21:18 |
| morganfainberg | ayoung, hm. impersonation *might* be the one feature we leave to trusts. | 21:18 |
| morganfainberg | ayoung, not sure how that fits into delegation. | 21:18 |
| ayoung | ugh, that might be all that trusts do...and then I 'd *want* to deprecate them | 21:19 |
| ayoung | but...maybe we won't need it by then | 21:19 |
| morganfainberg | ayoung, it's the only thing i can think of that doesn't line in with the delegation plans | 21:19 |
| ayoung | once we have that, we've given people a mechanism for authorization for long lived tasks | 21:20 |
| ayoung | and a unified one at that | 21:20 |
| morganfainberg | and i'm fine with that being a trust-only thing. if we find it is still heavily uses/has a place we can then look at moving it over somehow so trusts can actually go away | 21:20 |
| ayoung | I wonder if we could sweep all of this into "tokens" somehow | 21:20 |
| ayoung | like the tokenid is the delegation agreement | 21:20 |
| morganfainberg | now you're scaring me | 21:20 |
| morganfainberg | :P | 21:21 |
| ayoung | and we distinguish between tokens with expiry and authentication data in them | 21:21 |
| morganfainberg | lets not jump to that yet. | 21:21 |
| morganfainberg | lets get the base stuff done and then look at building on top of it | 21:21 |
| ayoung | We need gyee to finish off the X509 stuff he was working on | 21:22 |
| ayoung | IU think that is the baseline authentication mechanism for the service users | 21:22 |
| morganfainberg | ayoung, again, does not block anything we've talked about (the simple/basic stuff) | 21:22 |
| ayoung | agreed...parallel | 21:23 |
| morganfainberg | ayoung, so we can move forward on these fronts. | 21:23 |
| ayoung | just needed to have a minimal viable product | 21:23 |
| *** nellysmitt has quit IRC | 21:28 | |
| *** gyee has joined #openstack-keystone | 21:32 | |
| *** nellysmitt has joined #openstack-keystone | 21:35 | |
| ayoung | jamielennox, does pecan replace the paste.ini approach? | 21:42 |
| *** afazekas is now known as __afazekas | 21:43 | |
| *** joesavak has quit IRC | 21:45 | |
| *** _cjones_ has quit IRC | 21:46 | |
| *** _cjones_ has joined #openstack-keystone | 21:46 | |
| *** Viswanath_ has joined #openstack-keystone | 21:51 | |
| *** Viswanath has joined #openstack-keystone | 21:51 | |
| jamielennox | ayoung: no | 21:53 |
| *** Viswanath_ has quit IRC | 21:53 | |
| *** Viswanath has quit IRC | 21:54 | |
| ayoung | jamielennox, ok. I was looking at some limitations of paste, wondering if they were worth working around: | 21:54 |
| jamielennox | it can and IMO should replace some of it - however it doesn't have to | 21:54 |
| ayoung | jamielennox, specifically, the number of places where we duplicate the long list of filters | 21:54 |
| jamielennox | ayoung: i think that's something that you can fix | 21:54 |
| jamielennox | paste has some form of grouping i think | 21:54 |
| ayoung | each of the pipelines have: standard-filters sizelimit url_normalize build_auth_context token_auth admin_token_auth xml_body_v2 json_body | 21:55 |
| ayoung | some with v3, but still... | 21:55 |
| jamielennox | right, and so some of that is what i would like to rip out of paste | 21:55 |
| ayoung | I was writing a filter that was a filter_list | 21:55 |
| jamielennox | if you remove some of those filters then the whole process doesn't work - that breaks my definition of middleware and should be handle by keystone itself | 21:56 |
| ayoung | but paste doesn't expose the details of what is configured | 21:56 |
| ayoung | I don't want to remove them, just have something like this: | 21:56 |
| jamielennox | ayoung: yep, i had some issue with paste and trying to reach back up | 21:56 |
| ayoung | [filter:filter_list] | 21:56 |
| ayoung | filters = standard-filters sizelimit url_normalize build_auth_context token_auth admin_token_auth xml_body_v2 json_body | 21:57 |
| ayoung | then in a pipeline | 21:57 |
| jamielennox | you can subclass the paste builder class and make one that will give you what you need - and at which point i gave up on fixing paste | 21:57 |
| ayoung | pipeline = standard-filters public_service | 21:57 |
| ayoung | none of our filters accept config parameters, so I could make it work | 21:58 |
| ayoung | but then I wanted to make a filter with config values for content_types | 21:58 |
| ayoung | so you would specify which class to use for json, html, xml.... | 21:58 |
| *** ayoung is now known as ayoung-dadmode | 22:01 | |
| *** aix has joined #openstack-keystone | 22:02 | |
| jamielennox | ayoung-dadmode: i don't know how to do that with paste | 22:04 |
| morganfainberg | jamielennox, i think it's likely the wrong approach. | 22:04 |
| jamielennox | morganfainberg: as i said, if you start removing some of those middlewares from paste then keystone starts to act very strangely | 22:05 |
| morganfainberg | jamielennox, i think the right approach is to use accepts headers and make it a set of renderers, i hear that is kindof how pecan worked [haven't looked] | 22:05 |
| jamielennox | by my defintion that means it doesn't belong in paste | 22:05 |
| morganfainberg | and stevedore for the *actual* provider | 22:05 |
| jamielennox | morganfainberg: yes, that's more of less how it works | 22:05 |
| jamielennox | generally you specify it as a decorator per function though | 22:05 |
| morganfainberg | ah. sure. | 22:05 |
| morganfainberg | thats fine. | 22:06 |
| jamielennox | it makes sense if you think that JSON is generally not the default returned, normally it sends out to some html renderer | 22:06 |
| morganfainberg | anyway, i think the whole "tokens are a pipeline" in the sense of "paste pipeline" is wrong | 22:06 |
| jamielennox | in the patch i did at least i hacked my own renderer to do some compatibility stuff - so we can do whatever we like there | 22:06 |
| jamielennox | ummm | 22:06 |
| morganfainberg | especially considering the talking we did at the summit (and more importantly this discussion) | 22:06 |
| jamielennox | not sure - but in general you shouldn't do it _via_ paste | 22:07 |
| morganfainberg | right. | 22:07 |
| morganfainberg | i was referring to ayoung's implementation he's trying to do. | 22:07 |
| jamielennox | i don't care either way on the pipeline thing, that's been in discussion for a while | 22:07 |
| morganfainberg | the filters are *not* optional | 22:07 |
| morganfainberg | if they aren't optional, they shouldn't be configured as such | 22:07 |
| jamielennox | if you can break down the process into enough 'providers' then it shouldn't matter | 22:07 |
| jamielennox | morganfainberg: ++ | 22:07 |
| *** lbragstad_ has joined #openstack-keystone | 22:19 | |
| *** Viswanath has joined #openstack-keystone | 22:25 | |
| rodrigods | needing reviews in some patches with a +2 already... candidates? hehe | 22:27 |
| *** Viswanath has quit IRC | 22:28 | |
| gyee | rodrigods, which one | 22:38 |
| *** shakamunyi has joined #openstack-keystone | 22:39 | |
| rodrigods | gyee, \o/ https://review.openstack.org/#/c/131319/ | 22:39 |
| gyee | jamielennox, whenever you have a chance, https://review.openstack.org/#/c/105900/ | 22:39 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Rename openid to oidc in test_auth_plugins.conf https://review.openstack.org/133494 | 22:43 |
| openstackgerrit | Rodrigo Duarte proposed a change to openstack/keystone: Adds dynamic checking for mapped tokens https://review.openstack.org/133130 | 22:43 |
| rodrigods | marekd, stevemar, ^ | 22:43 |
| marekd | ok | 22:43 |
| rodrigods | gyee, https://review.openstack.org/#/c/132311/ that one is well, minor one =P | 22:44 |
| *** nellysmitt has quit IRC | 22:44 | |
| *** lbragstad_ has quit IRC | 22:49 | |
| rodrigods | gyee, thanks!!! | 22:50 |
| *** jistr has quit IRC | 22:51 | |
| *** lbragstad_ has joined #openstack-keystone | 22:52 | |
| jamielennox | gyee: set +1, i haven't had a chance to actually run it but he's addressed what i was concerned about | 22:53 |
| jamielennox | anything left is minor and can be addressed later | 22:53 |
| gyee | jamielennox, thanks | 22:54 |
| gyee | yeah, followon patch | 22:54 |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient-federation: Updated from global requirements https://review.openstack.org/133570 | 23:04 |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Move functional tests to keystone/tests/functional https://review.openstack.org/133556 | 23:04 |
| morganfainberg | lbragstad, i like that change ^ cause it's minimal just shuffling things around | 23:07 |
| morganfainberg | lbragstad, however... | 23:08 |
| morganfainberg | lbragstad, please don't use nose as a default test runner. | 23:09 |
| morganfainberg | lbragstad, unless there really is no other way. | 23:09 |
| lbragstad | morganfainberg: gotcha, I saw that it was being used for the py3* testing | 23:09 |
| morganfainberg | yeah | 23:10 |
| morganfainberg | py3 is a special case... and should likewise be converted to testr if possible | 23:10 |
| lbragstad | can we pass in that location (keystone/tests/functional/) with something else? | 23:10 |
| lbragstad | or testr? | 23:10 |
| morganfainberg | lbragstad, yeah there is a way to convince subunit to do it (what testr uses) | 23:10 |
| morganfainberg | lbragstad, it'll be related to https://testrepository.readthedocs.org/en/latest/MANUAL.html#listing-tests | 23:11 |
| morganfainberg | lbragstad, give me a moment and i'll have a real answer for you | 23:12 |
| lbragstad | morganfainberg: yeah, I tried parsing that doc but couldn't come up with something simple enough | 23:12 |
| morganfainberg | lbragstad, https://github.com/openstack/neutron/blob/master/tox.ini#L24-L27 | 23:12 |
| lbragstad | morganfainberg: gotcha, I saw that | 23:12 |
| lbragstad | we'll have to sync lockutils. | 23:13 |
| morganfainberg | and: https://github.com/openstack/neutron/blob/master/tox.ini#L29-L36 need to see how OS_TEST_PATH works | 23:13 |
| morganfainberg | nah | 23:13 |
| morganfainberg | lockutils is just loaded cause thier tests require it - ours don't (at the moment) | 23:13 |
| morganfainberg | they use it for synchronising against db schemas or some such | 23:13 |
| lbragstad | ah | 23:13 |
| morganfainberg | see https://github.com/openstack/neutron/blob/master/tox.ini#L16 | 23:14 |
| morganfainberg | their base testenv uses it too | 23:14 |
| morganfainberg | so you'll need to see how OS_TEST_PATH is handled in neutron's test framework | 23:14 |
| morganfainberg | but.. that is basically what they're doing. | 23:14 |
| *** nkinder has quit IRC | 23:15 | |
| *** zzzeek has quit IRC | 23:18 | |
| *** shakamunyi has quit IRC | 23:18 | |
| *** henrynash has quit IRC | 23:19 | |
| openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Move functional tests to keystone/tests/functional https://review.openstack.org/133556 | 23:22 |
| lbragstad | morganfainberg: ^ better ? | 23:22 |
| *** thedodd has quit IRC | 23:30 | |
| *** dims has quit IRC | 23:36 | |
| *** dims has joined #openstack-keystone | 23:37 | |
| *** zzzeek has joined #openstack-keystone | 23:39 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:43 | |
| *** _cjones_ has quit IRC | 23:50 | |
| *** kobtea has joined #openstack-keystone | 23:50 | |
| *** _cjones_ has joined #openstack-keystone | 23:50 | |
| openstackgerrit | A change was merged to openstack/keystone: Change ca to uppercase in keystone.conf https://review.openstack.org/132311 | 23:51 |
| openstackgerrit | A change was merged to openstack/keystone: Doc about deleting a domain specific backend domain https://review.openstack.org/131319 | 23:51 |
| *** _cjones_ has quit IRC | 23:55 | |
| *** esp has left #openstack-keystone | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!