| *** lamt has quit IRC | 00:02 | |
| *** chris_hultin is now known as chris_hultin|AWA | 00:06 | |
| *** asettle has joined #openstack-keystone | 00:10 | |
| *** itisha has quit IRC | 00:12 | |
| *** asettle has quit IRC | 00:14 | |
| openstackgerrit | Merged openstack/keystone: Do not manually remove /etc/shibboleth folder https://review.openstack.org/410356 | 00:14 |
|---|---|---|
| *** rcernin has quit IRC | 00:22 | |
| *** spzala has quit IRC | 00:26 | |
| *** stingaci has joined #openstack-keystone | 00:28 | |
| *** aselius has quit IRC | 00:30 | |
| *** harlowja has joined #openstack-keystone | 00:30 | |
| *** ravelar has quit IRC | 00:41 | |
| *** guoshan has joined #openstack-keystone | 00:43 | |
| *** hoangcx has joined #openstack-keystone | 01:01 | |
| *** Zer0Byte__ has quit IRC | 01:06 | |
| *** asettle has joined #openstack-keystone | 01:13 | |
| *** guoshan has quit IRC | 01:16 | |
| *** asettle has quit IRC | 01:18 | |
| *** zhangjl has joined #openstack-keystone | 01:22 | |
| *** markvoelker has quit IRC | 01:29 | |
| *** guoshan has joined #openstack-keystone | 01:33 | |
| *** liujiong has joined #openstack-keystone | 01:50 | |
| *** chrisplo has quit IRC | 01:51 | |
| *** zhugaoxiao has quit IRC | 01:51 | |
| *** zhugaoxiao has joined #openstack-keystone | 01:52 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms https://review.openstack.org/409289 | 01:52 |
| *** tqtran has quit IRC | 02:07 | |
| *** dave-mccowan has quit IRC | 02:10 | |
| *** dave-mccowan has joined #openstack-keystone | 02:11 | |
| *** stingaci has quit IRC | 02:57 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Add tests for password requirements API https://review.openstack.org/410515 | 03:01 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: WIP implementation for password requirements API https://review.openstack.org/410516 | 03:01 |
| lbragstad | stevemar i want to get some eyes on the tests for password requirements here - https://review.openstack.org/#/c/410515/1/keystone/tests/unit/test_v3_domain_config.py | 03:03 |
| lbragstad | stevemar let me know if that's missing anything big - but i think it primarily boils down to only being able to read things from the security_compliance section, and never being able to update things in the security compliance section | 03:03 |
| lbragstad | i want to try and expose everything in the tests as i write the code for it | 03:04 |
| lbragstad | stevemar hmm - domain config is v3 only... is horizon expecting to be able to apply this stuff to v2.0? | 03:08 |
| *** stingaci has joined #openstack-keystone | 03:10 | |
| *** stingaci has quit IRC | 03:14 | |
| *** phalmos_ has quit IRC | 03:14 | |
| *** phalmos has joined #openstack-keystone | 03:15 | |
| *** EmilienM has quit IRC | 03:19 | |
| *** EmilienM has joined #openstack-keystone | 03:19 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Add tests for password requirements API https://review.openstack.org/410515 | 03:30 |
| *** markvoelker has joined #openstack-keystone | 03:30 | |
| *** markvoelker has quit IRC | 03:35 | |
| *** dave-mccowan has quit IRC | 03:39 | |
| *** chrisplo has joined #openstack-keystone | 03:40 | |
| *** stingaci has joined #openstack-keystone | 03:50 | |
| *** dikonoo has joined #openstack-keystone | 03:51 | |
| *** dikonoor has joined #openstack-keystone | 03:51 | |
| *** stingaci has quit IRC | 03:54 | |
| *** tqtran has joined #openstack-keystone | 04:03 | |
| *** hoangcx has quit IRC | 04:04 | |
| *** guoshan has quit IRC | 04:05 | |
| *** nicolasbock has quit IRC | 04:05 | |
| *** tqtran has quit IRC | 04:08 | |
| *** udesale has joined #openstack-keystone | 04:14 | |
| *** adrian_otto has joined #openstack-keystone | 04:29 | |
| *** adrian_otto has quit IRC | 04:42 | |
| stevemar | lbragstad: isn't the pci stuff v2 only? i think the v3 limitation for the config options is fine | 04:42 |
| *** chlong has joined #openstack-keystone | 04:44 | |
| *** links has joined #openstack-keystone | 04:57 | |
| *** adrian_otto has joined #openstack-keystone | 04:59 | |
| *** guoshan has joined #openstack-keystone | 05:06 | |
| *** tqtran has joined #openstack-keystone | 05:06 | |
| *** chrisplo has quit IRC | 05:07 | |
| breton_ | https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers -- New NIST password guidelines: don't require character types or rotation | 05:08 |
| *** tqtran has quit IRC | 05:10 | |
| *** adrian_otto has quit IRC | 05:10 | |
| *** guoshan has quit IRC | 05:11 | |
| *** asettle has joined #openstack-keystone | 05:14 | |
| *** asettle has quit IRC | 05:21 | |
| *** kfox1111 has quit IRC | 05:30 | |
| *** kfox1111 has joined #openstack-keystone | 05:30 | |
| *** markvoelker has joined #openstack-keystone | 05:31 | |
| *** chrisplo has joined #openstack-keystone | 05:34 | |
| *** markvoelker has quit IRC | 05:37 | |
| *** chrisplo_ has joined #openstack-keystone | 05:38 | |
| openstackgerrit | Merged openstack/keystone: Add id to conflict error if caused by duplicate id https://review.openstack.org/409010 | 05:39 |
| *** chrisplo has quit IRC | 05:40 | |
| *** jaosorior has joined #openstack-keystone | 05:50 | |
| *** adriant has quit IRC | 05:53 | |
| *** hyakuhei has quit IRC | 06:03 | |
| *** guoshan has joined #openstack-keystone | 06:08 | |
| *** guoshan has quit IRC | 06:12 | |
| *** guoshan has joined #openstack-keystone | 06:14 | |
| *** liujiong has quit IRC | 06:28 | |
| *** liujiong has joined #openstack-keystone | 06:28 | |
| *** stingaci has joined #openstack-keystone | 06:35 | |
| openstackgerrit | Merged openstack/keystone: Refactors _get_names_from_role_assignments https://review.openstack.org/408074 | 06:38 |
| *** stingaci has quit IRC | 06:40 | |
| *** richm has quit IRC | 06:40 | |
| *** afazekas has quit IRC | 06:40 | |
| *** afazekas has joined #openstack-keystone | 06:42 | |
| *** edmondsw has joined #openstack-keystone | 06:54 | |
| *** stingaci has joined #openstack-keystone | 06:56 | |
| *** edmondsw has quit IRC | 06:59 | |
| *** markvoelker has joined #openstack-keystone | 07:00 | |
| *** stingaci has quit IRC | 07:00 | |
| *** tobberydberg has joined #openstack-keystone | 07:04 | |
| *** markvoelker has quit IRC | 07:06 | |
| *** tobberyd_ has joined #openstack-keystone | 07:06 | |
| *** tobberyd_ has quit IRC | 07:06 | |
| *** tobberyd_ has joined #openstack-keystone | 07:06 | |
| *** maestropandy has joined #openstack-keystone | 07:07 | |
| *** tobberydberg has quit IRC | 07:09 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 07:09 | |
| *** maestropandy has left #openstack-keystone | 07:14 | |
| *** jdennis has joined #openstack-keystone | 07:17 | |
| *** asettle has joined #openstack-keystone | 07:18 | |
| *** bapalm has quit IRC | 07:18 | |
| *** jdennis1 has quit IRC | 07:18 | |
| *** asettle has quit IRC | 07:25 | |
| *** chrisplo_ has quit IRC | 07:36 | |
| *** bapalm has joined #openstack-keystone | 07:38 | |
| *** zhangjl1 has joined #openstack-keystone | 07:55 | |
| *** rcernin has joined #openstack-keystone | 07:56 | |
| *** rcernin has quit IRC | 07:56 | |
| *** zhangjl has quit IRC | 07:57 | |
| *** rcernin has joined #openstack-keystone | 07:57 | |
| *** pcaruana has joined #openstack-keystone | 07:59 | |
| *** tqtran has joined #openstack-keystone | 08:08 | |
| *** tqtran has quit IRC | 08:12 | |
| *** jaosorior has quit IRC | 08:16 | |
| *** jaosorior has joined #openstack-keystone | 08:16 | |
| *** henrynash has joined #openstack-keystone | 08:30 | |
| *** ChanServ sets mode: +v henrynash | 08:30 | |
| *** henrynash has quit IRC | 08:34 | |
| *** henrynash has joined #openstack-keystone | 08:37 | |
| *** ChanServ sets mode: +v henrynash | 08:37 | |
| *** Zer0Byte__ has joined #openstack-keystone | 08:40 | |
| *** henrynash has quit IRC | 08:42 | |
| *** daemontool has joined #openstack-keystone | 08:44 | |
| *** openstackgerrit has quit IRC | 08:48 | |
| *** zhangjl1 has left #openstack-keystone | 08:51 | |
| *** dikonoor has quit IRC | 08:54 | |
| *** dikonoo has quit IRC | 08:54 | |
| *** dikonoor has joined #openstack-keystone | 08:54 | |
| *** edmondsw has joined #openstack-keystone | 08:55 | |
| *** daemontool_ has joined #openstack-keystone | 08:55 | |
| *** amoralej|off is now known as amoralej | 08:56 | |
| *** daemontool has quit IRC | 08:58 | |
| *** edmondsw has quit IRC | 08:59 | |
| *** zzzeek has quit IRC | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:00 | |
| *** markvoelker has joined #openstack-keystone | 09:02 | |
| *** markvoelker has quit IRC | 09:07 | |
| *** tobberyd_ has quit IRC | 09:10 | |
| *** openstackgerrit has joined #openstack-keystone | 09:10 | |
| openstackgerrit | yunfeng zhou proposed openstack/keystone: Internationalization (i18n) Strings https://review.openstack.org/410622 | 09:10 |
| openstackgerrit | yunfeng zhou proposed openstack/keystone: Internationalization (i18n) Strings https://review.openstack.org/410622 | 09:15 |
| *** tobberyd_ has joined #openstack-keystone | 09:21 | |
| *** tobberyd_ has quit IRC | 09:26 | |
| *** itisha has joined #openstack-keystone | 09:39 | |
| *** Zer0Byte__ has quit IRC | 09:41 | |
| *** asettle has joined #openstack-keystone | 09:44 | |
| *** tobberydberg has joined #openstack-keystone | 09:52 | |
| *** pnavarro has joined #openstack-keystone | 09:57 | |
| *** liujiong has quit IRC | 10:01 | |
| *** tobberydberg has quit IRC | 10:03 | |
| *** tobberydberg has joined #openstack-keystone | 10:04 | |
| *** tobberydberg has quit IRC | 10:08 | |
| *** tqtran has joined #openstack-keystone | 10:09 | |
| *** brad[] has quit IRC | 10:11 | |
| *** tqtran has quit IRC | 10:13 | |
| *** tobberydberg has joined #openstack-keystone | 10:14 | |
| *** tobberydberg has quit IRC | 10:19 | |
| *** mvk has quit IRC | 10:24 | |
| *** chrisplo_ has joined #openstack-keystone | 10:32 | |
| *** tobberydberg has joined #openstack-keystone | 10:36 | |
| *** chrisplo_ has quit IRC | 10:36 | |
| *** links has quit IRC | 10:38 | |
| *** links has joined #openstack-keystone | 10:38 | |
| *** guoshan has quit IRC | 10:40 | |
| *** tobberydberg has quit IRC | 10:47 | |
| *** tobberydberg has joined #openstack-keystone | 10:56 | |
| *** mvk has joined #openstack-keystone | 10:56 | |
| *** tobberydberg has quit IRC | 11:01 | |
| *** markvoelker has joined #openstack-keystone | 11:02 | |
| *** udesale has quit IRC | 11:05 | |
| *** pnavarro has quit IRC | 11:06 | |
| *** markvoelker has quit IRC | 11:07 | |
| *** richm has joined #openstack-keystone | 11:10 | |
| *** jaosorior has quit IRC | 11:19 | |
| *** brad[] has joined #openstack-keystone | 11:24 | |
| *** tobberydberg has joined #openstack-keystone | 11:29 | |
| *** jaosorior has joined #openstack-keystone | 11:30 | |
| *** nicolasbock has joined #openstack-keystone | 11:32 | |
| *** tobberyd_ has joined #openstack-keystone | 11:38 | |
| *** tobbery__ has joined #openstack-keystone | 11:40 | |
| *** guoshan has joined #openstack-keystone | 11:41 | |
| *** tobberydberg has quit IRC | 11:41 | |
| *** tobber___ has joined #openstack-keystone | 11:41 | |
| *** tobberyd_ has quit IRC | 11:43 | |
| *** tobbery__ has quit IRC | 11:44 | |
| *** tobberydberg has joined #openstack-keystone | 11:44 | |
| *** tobber___ has quit IRC | 11:45 | |
| *** guoshan has quit IRC | 11:46 | |
| *** tobberydberg has quit IRC | 11:49 | |
| *** tobberydberg has joined #openstack-keystone | 11:50 | |
| *** pnavarro has joined #openstack-keystone | 11:56 | |
| *** stingaci has joined #openstack-keystone | 12:03 | |
| *** dave-mccowan has joined #openstack-keystone | 12:04 | |
| *** stingaci has quit IRC | 12:07 | |
| *** tqtran has joined #openstack-keystone | 12:11 | |
| *** tqtran has quit IRC | 12:15 | |
| openstackgerrit | Julia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone https://review.openstack.org/399472 | 12:26 |
| *** jamielennox is now known as jamielennox|away | 12:43 | |
| *** guoshan has joined #openstack-keystone | 12:43 | |
| *** nklenke has joined #openstack-keystone | 12:47 | |
| *** jamielennox|away is now known as jamielennox | 12:50 | |
| *** amoralej is now known as amoralej|lunch | 12:55 | |
| *** nklenke has quit IRC | 12:57 | |
| *** guoshan has quit IRC | 12:58 | |
| *** markvoelker has joined #openstack-keystone | 13:03 | |
| *** markvoelker has quit IRC | 13:08 | |
| *** edmondsw has joined #openstack-keystone | 13:13 | |
| *** mvk has quit IRC | 13:15 | |
| *** edmondsw_ has joined #openstack-keystone | 13:20 | |
| *** edmondsw_ has quit IRC | 13:20 | |
| *** markvoelker has joined #openstack-keystone | 13:24 | |
| *** brad[] has quit IRC | 13:28 | |
| *** daemontool_ has quit IRC | 13:30 | |
| *** chlong has quit IRC | 13:32 | |
| *** lamt has joined #openstack-keystone | 13:35 | |
| *** lamt has quit IRC | 13:39 | |
| samueldmq | morning keystone | 13:40 |
| *** brad[] has joined #openstack-keystone | 13:52 | |
| *** guoshan has joined #openstack-keystone | 13:55 | |
| *** guoshan has quit IRC | 13:59 | |
| *** hrybacki is now known as hrybacki|mtg | 14:01 | |
| *** ayoung has quit IRC | 14:04 | |
| *** amoralej|lunch is now known as amoralej | 14:07 | |
| *** tqtran has joined #openstack-keystone | 14:12 | |
| *** tqtran has quit IRC | 14:17 | |
| *** pnavarro has quit IRC | 14:19 | |
| rderose | morning | 14:26 |
| *** asettle has quit IRC | 14:31 | |
| *** asettle has joined #openstack-keystone | 14:32 | |
| rderose | samueldmq: just left you a note on this one: https://review.openstack.org/#/c/409946 | 14:32 |
| samueldmq | rderose: looking | 14:32 |
| dstanek | lbragstad: i'm looking at the shadow mapping spec again and it seems to overlap with what rderose is doing with idps | 14:32 |
| samueldmq | rderose: nice. do you mind adding that to the commit message so it's clear to everyone ? | 14:33 |
| samueldmq | rderose: it was not clear to me, for example | 14:33 |
| rderose | samueldmq: sure | 14:33 |
| dstanek | lbragstad: it's not entirely clear to me that the spec actually changes the JSON at all so it may be better to use a separate spec | 14:34 |
| dstanek | oh rderose you're mentioned on that spec too | 14:36 |
| rderose | dstanek: shadow mapping? | 14:36 |
| *** mvk has joined #openstack-keystone | 14:36 | |
| dstanek | rderose: yeah | 14:37 |
| dstanek | rderose: it talks about adding a domain_id key, but with what you are doing now you wouldn't need to do that anymore right? | 14:37 |
| *** phalmos has quit IRC | 14:38 | |
| rderose | dstanek: correct | 14:38 |
| rderose | dstanek: to me that part was a flaw because an IdP can have multiple protocols; multiple mappings | 14:39 |
| rderose | dstanek: so you could end up with multiple domains if tied to the mapping | 14:39 |
| rderose | dstanek: so now the mapping can get the domain from the IdP | 14:39 |
| rderose | with: https://review.openstack.org/#/c/399684/ | 14:40 |
| dstanek | rderose: ok, that's what i was thinking | 14:42 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Make user to nonlocal_user a 1:1 relationship https://review.openstack.org/409946 | 14:43 |
| rderose | samueldmq: ^ | 14:43 |
| lbragstad | stevemar you mean v3 only? | 14:44 |
| dstanek | rderose: so basically we have to find a way to get the IdP information into the mapping engine | 14:44 |
| rderose | dstanek: no, when processing the mapping, you would get the domain from the IdP | 14:45 |
| dstanek | rderose: how? | 14:45 |
| dstanek | rderose: or will the creation of resources come after the mapping has occurred? (actually that's probably ideal from an implementation perspective anyway) | 14:46 |
| *** udesale has joined #openstack-keystone | 14:47 | |
| samueldmq | rderose: looking nice. just another question inline (in the test) | 14:47 |
| rderose | dstanek: creation of resources happen when the user federates into keystone | 14:48 |
| rderose | dstanek: at that point, you know the IdP, right? | 14:49 |
| lbragstad | rderose I would think so | 14:49 |
| dstanek | rderose: i was asking specifically about the mapper which does not | 14:49 |
| dstanek | but i don't think you would create resources in there anyway | 14:49 |
| dstanek | something after that should probably take the resulting dictionary and inspect it | 14:50 |
| lbragstad | dstanek rderose when dolphm and i originally looked at the shadow mapping stuff, we didn't really have a good way to incorporate the domain_id in the mapping | 14:50 |
| rderose | dstanek: mapping is just a set of rules that gets processed by the mapping engine | 14:50 |
| dstanek | rderose: right | 14:50 |
| rderose | dstanek: so you could pass in the domain to the mapping engine when it does the provisioning | 14:51 |
| dstanek | rderose: where do you anticipate creating the resources? not in the mapper right? | 14:52 |
| rderose | dstanek: mapper? mapping engine or mapping? | 14:53 |
| lbragstad | rderose are you expecting the mapping engine to create the domain? | 14:53 |
| rderose | lbragstad: no | 14:53 |
| rderose | the domain would be created as part of the idp creation | 14:53 |
| dstanek | mapper is the rule processing engine...or anything in keystone.federation.utils | 14:53 |
| lbragstad | ok - just checking | 14:53 |
| dstanek | rderose: i would expect things to be created after that has run by the calling code | 14:54 |
| rderose | dstanek: the mapper is processing the rules and would call code to do the provisioning | 14:54 |
| rderose | dstanek: at the time of federated auth | 14:55 |
| dstanek | i don't think it should. i think i should remain as generic as possible. | 14:55 |
| rderose | dstanek: what do you mean by generic? | 14:55 |
| *** guoshan has joined #openstack-keystone | 14:56 | |
| dstanek | rderose: all it knows is processing rules and nothing about the drivers right now. i don't know why we wouldn't keep it that way if we could. | 14:56 |
| rderose | dstanek: shadow mapping is about enhancing the mapping engine to do auto provisioning | 14:56 |
| dstanek | rderose: i think the calling code should do it | 14:57 |
| *** links has quit IRC | 14:57 | |
| lbragstad | dstanek what's the calling code? | 14:57 |
| rderose | dstanek: the controller? | 14:57 |
| rderose | or actually the manager | 14:57 |
| rderose | or the auth plugin? | 14:58 |
| dstanek | right now it's in the driver base i think | 14:58 |
| rderose | dstanek: whatever does the provisioning will be calling the api (core); not drivers | 14:59 |
| rderose | dstanek: but I could see the mapping engine returning a set of provisioning tasks and something else does the provisioning | 14:59 |
| dstanek | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/core.py#n100 | 14:59 |
| *** jaugustine has joined #openstack-keystone | 15:00 | |
| *** guoshan has quit IRC | 15:00 | |
| rderose | dstanek:++ | 15:00 |
| rderose | dstanek: makes sense | 15:00 |
| *** jlk has quit IRC | 15:01 | |
| lbragstad | rderose well - if the mapping engine doesn't do the provisioning, all it would need to do would be to pass back the values of whatever the mapping evaluated to | 15:02 |
| *** hrybacki|mtg is now known as hrybacki | 15:02 | |
| dstanek | because right now not even that code knows about the resource manager let alone utilties like the mapping engine | 15:02 |
| *** mvk has quit IRC | 15:02 | |
| rderose | lbragstad dstanek: agree | 15:02 |
| dstanek | lbragstad: take a look at that method. it gets them from the eninge and also retuns them | 15:02 |
| *** jlk has joined #openstack-keystone | 15:03 | |
| *** jlk has quit IRC | 15:03 | |
| *** jlk has joined #openstack-keystone | 15:03 | |
| lbragstad | dstanek you're talking about keystone.federation.core:Manager.evaluate() | 15:03 |
| dstanek | lbragstad: are you getting my email on you rax account? | 15:03 |
| dstanek | lbragstad: right | 15:04 |
| lbragstad | dstanek i think so | 15:04 |
| rderose | dstanek: so evaluate is doing this, just returning the mapping results | 15:05 |
| rderose | dstanek: and something else is doing the processing | 15:05 |
| dstanek | lbragstad: ok, it didn't seem to work and jorge just responded with what i was suggesting anyway :-) | 15:05 |
| SamYaple | hello. im seeing "NoMatchingPlugin: The plugin v3scopedsaml could not be found" in a new virtualenv and I can't understand why. Any suggestions? | 15:06 |
| dstanek | rderose: correct. that's the auth plugin for federation | 15:06 |
| SamYaple | More info: http://paste.openstack.org/show/592355/ | 15:06 |
| dstanek | rderose: errr....mapped. we renamed it some time ago | 15:06 |
| lbragstad | https://github.com/openstack/keystone/blob/c30b539bda5acf80d22f98f0712e688022b4b20b/keystone/auth/plugins/mapped.py#L198-L199 | 15:06 |
| SamYaple | /win 22 | 15:06 |
| dstanek | SamYaple: nope, you're still here! | 15:06 |
| SamYaple | dstanek: :) | 15:07 |
| dstanek | SamYaple: hmmm...is that the right entrypoint name? | 15:07 |
| SamYaple | dstanek: its what is in setup.cfg | 15:07 |
| SamYaple | the entry point is correct... but when i debug stevedore is getting namespace 'keystoneauth1.plugins' which i think is wrong | 15:08 |
| dstanek | SamYaple: hmmm...that should be picked up unless maybe it fails silently on import error or something | 15:08 |
| lbragstad | dstanek rderose so in that case you're thinking about making https://github.com/openstack/keystone/blob/c30b539bda5acf80d22f98f0712e688022b4b20b/keystone/auth/plugins/mapped.py#L198-L199 process whatever the mapped_properties are and doing the provisioning? | 15:08 |
| SamYaple | dstanek: im not sure, this works in one environment, and i cant get it to work with either mitaka containts python-openstackclient, or latest | 15:08 |
| rderose | lbragstad: yeah, I think so | 15:09 |
| dstanek | lbragstad: yes, because https://github.com/openstack/keystone/blob/c30b539bda5acf80d22f98f0712e688022b4b20b/keystone/auth/plugins/mapped.py#L32 | 15:09 |
| dstanek | it already knows the identity_api | 15:09 |
| lbragstad | ah - sure | 15:09 |
| lbragstad | that makes sense | 15:09 |
| dstanek | err... resource api | 15:09 |
| lbragstad | well - it knows both | 15:09 |
| lbragstad | it would need to know about the assignment api, too | 15:10 |
| dstanek | SamYaple: what happens when you just import the code? | 15:10 |
| lbragstad | but that's probably not that big of a deal | 15:10 |
| dstanek | lbragstad: yep, but that's an easy leap since it knows about everything else :-) | 15:10 |
| rderose | lbragstad dstanek: or, you could let the federation API to the provisioning; called from the mapped plugin | 15:10 |
| lbragstad | dstanek rderose so what happens if we ever have another plugin that does something similar to mapped? | 15:10 |
| SamYaple | dstanek: I can import https://github.com/openstack/python-keystoneclient/blob/master/setup.cfg#L37 | 15:11 |
| rderose | lbragstad: hmm... | 15:11 |
| dstanek | rderose: sure you could possibly do that. i'd be open for which ever seems better | 15:11 |
| dstanek | rderose: i just didn't want my mapper to grow a third arm unnecessarily :-) | 15:11 |
| lbragstad | rderose dstanek i guess a better question would be, do we think the mapped plugin will *always* handle all federated authentications? | 15:12 |
| dstanek | SamYaple: 'import keystoneclient.contrib.auth.v3.saml2' worked ok? | 15:12 |
| rderose | dstanek lbragstad: true and I don't wan the auth plugin to grow a 3rd arm | 15:12 |
| rderose | :) | 15:12 |
| SamYaple | dstanek: yea | 15:13 |
| lbragstad | so - it sounds like the real questions is "who wants to grow a third arm?" | 15:13 |
| *** spzala has joined #openstack-keystone | 15:13 | |
| lbragstad | if we *really* need a third arm to grow, who should do it] | 15:13 |
| dstanek | SamYaple: hmmm...how did you create the virtualenv? i'll like to try to test it | 15:13 |
| rderose | lbragstad: ++ | 15:14 |
| rderose | lbragstad: federation_api seems more appropriate to me | 15:14 |
| dstanek | lbragstad: rderose: ideally it won't be a third arm at all. the logic should belong somewhere. ideally were we are already process that data or creating related objects. | 15:14 |
| lbragstad | dstanek rderose so - what creates the shadow user now? | 15:15 |
| * dstanek takes off his software engineering hat and puts on a Beer Guzzler Helmet (filled with coffee of course) | 15:15 | |
| rderose | lbragstad: identity_api | 15:16 |
| rderose | identity_api calls shadow backend | 15:16 |
| *** mvk has joined #openstack-keystone | 15:16 | |
| lbragstad | rderose what calls the identity api to do that | 15:16 |
| SamYaple | dstanek: nope! found it. got my environments mxed up | 15:16 |
| rderose | auth | 15:16 |
| dstanek | lbragstad: the plugin | 15:16 |
| rderose | lbragstad: auth plugin | 15:17 |
| SamYaple | dstanek: good ol' missing python-lxml | 15:17 |
| *** narasimha_SV has joined #openstack-keystone | 15:17 | |
| dstanek | SamYaple: ha | 15:17 |
| SamYaple | dstanek: thank you! | 15:17 |
| dstanek | glad you got it working before i started creating a new env :-) | 15:17 |
| lbragstad | rderose dstanek ah - here https://github.com/openstack/keystone/blob/c30b539bda5acf80d22f98f0712e688022b4b20b/keystone/auth/plugins/mapped.py#L155 | 15:17 |
| narasimha_SV | http://docs.openstack.org/developer/keystone/federation/federated_identity.html#keystone-as-an-identity-provider-idp I followed this link to have k2k federation | 15:18 |
| dstanek | narasimha_SV: did it work? | 15:18 |
| *** jaugustine has quit IRC | 15:18 | |
| narasimha_SV | how to check that I am confused how to check this ? | 15:18 |
| dstanek | narasimha_SV: how you do see if it's working? | 15:19 |
| narasimha_SV | i can see both IDP and SP keystone commands are working | 15:19 |
| stevemar | o/ | 15:19 |
| dstanek | narasimha_SV: what's the issue? | 15:20 |
| narasimha_SV | but how to test this that I can confirm both are working | 15:20 |
| *** chlong has joined #openstack-keystone | 15:21 | |
| narasimha_SV | if I create users in IDP keystone do they need to be reflected in SP keystone ??? | 15:21 |
| narasimha_SV | will that be my validation of working setup ? | 15:21 |
| dstanek | narasimha_SV: http://docs.openstack.org/developer/keystone/federation/federated_identity.html#testing-it-all-out | 15:22 |
| lbragstad | dstanek rderose so - would we just make another method in the federation api called auto_provision() that takes the mapping creates everything/ | 15:22 |
| dstanek | narasimha_SV: you don't explicitly create users in your SP at all. you just need them in the IdP so that you can login to the SP | 15:22 |
| lbragstad | dstanek rderose then that would be called from within the mapped plugin? | 15:23 |
| rderose | lbragstad: that could work | 15:23 |
| dstanek | your SP will need a mapping for your IdP and whatever projects you need already created | 15:23 |
| lbragstad | rderose is that where you guys were headed or am I still in left field? | 15:23 |
| dstanek | lbragstad: that would be reasonable | 15:23 |
| rderose | lbragstad: that's where I was headed :) | 15:23 |
| lbragstad | rderose sweet | 15:23 |
| * lbragstad stands with rderose in left field | 15:24 | |
| narasimha_SV | http://docs.openstack.org/developer/keystone/federation/federated_identity.html#add-identity-provider-s-mapping-s-and-protocol-s | 15:24 |
| narasimha_SV | this is what you are talking about right ? | 15:24 |
| narasimha_SV | the mapping which needs to be created for all the keystone related stuff ? | 15:24 |
| dstanek | narasimha_SV: yes the stuff from that link | 15:25 |
| lbragstad | and I suppose that federation_api.auto_provision(mapped_properties) would be called somewhere around here - https://github.com/openstack/keystone/blob/c30b539bda5acf80d22f98f0712e688022b4b20b/keystone/auth/plugins/mapped.py#L155-L157 | 15:25 |
| narasimha_SV | so if i created that mapping file and add to the IDP then what ever i have created over IDP can be used in SP right ? | 15:26 |
| rderose | rodrigods: you around? | 15:27 |
| *** nklenke has joined #openstack-keystone | 15:27 | |
| rodrigods | rderose, in a meeting... but can try to respond | 15:28 |
| lbragstad | stevemar were you expecting horizon to use the password requirements API for v2 calls at all ? | 15:28 |
| rderose | rodrigods: just left you a comment on: https://review.openstack.org/#/c/399157/12 | 15:28 |
| rderose | rodrigods: I'm not following "we also need to have the possibility to list identity providers by domain_id" | 15:29 |
| rodrigods | rderose, ahh... | 15:29 |
| rodrigods | rderose, so... you are adding a field to IdPs, right? | 15:29 |
| *** chris_hultin|AWA is now known as chris_hultin | 15:29 | |
| rderose | rodrigods: yes | 15:29 |
| *** phalmos has joined #openstack-keystone | 15:29 | |
| rodrigods | rderose, it is expected that i can filter IdPs based on that field | 15:29 |
| stevemar | lbragstad: if the right move architecturally is to make it v3 only then i'm OK with not extending v2 features | 15:29 |
| stevemar | lbragstad: more encouragement for folks to move to v3 | 15:30 |
| *** jefrite_ has quit IRC | 15:30 | |
| rderose | rodrigods: not necessarily | 15:30 |
| rodrigods | rderose, at least, for this case i think it is | 15:30 |
| rderose | rodrigods: why? | 15:30 |
| *** chrisplo_ has joined #openstack-keystone | 15:31 | |
| rodrigods | rderose, listing idps per domain? | 15:31 |
| rodrigods | it is not a 1:1 relationship, right? | 15:31 |
| *** chrisplo_ has quit IRC | 15:31 | |
| rderose | rodrigods: it is a 1:1 | 15:31 |
| lbragstad | stevemar true | 15:31 |
| dstanek | narasimha_SV: no, the mapping allows the SP to map the IdP user into a local user. you will still have to create the projects in the SP ahead of time | 15:31 |
| rodrigods | rderose, hmm so something to get the idp based on the domain_id? | 15:32 |
| rodrigods | and vice versa | 15:32 |
| rderose | rodrigods: seems reasonable, but it's not a requirement | 15:32 |
| dstanek | rodrigods: is there a case where you would need to do that? | 15:33 |
| rodrigods | dstanek, rderose, to list the assignments of users of a given idp | 15:34 |
| rderose | rodrigods: you would list by domain | 15:35 |
| *** chrisplo has joined #openstack-keystone | 15:35 | |
| dstanek | rodrigods: i don't get that one. idp wouldn't matter at that point right? | 15:35 |
| narasimha_SV | dstanek: so you are saying I can map users to be from IDP to SP | 15:35 |
| rodrigods | rderose, dstanek, it matters if i want to revoke tokens, for example (if i delete an IdP) | 15:36 |
| rderose | rodrigods: if you delete an idp, we don't delete the domain | 15:36 |
| dstanek | rodrigods: they you would already know the idp | 15:36 |
| rderose | stevemar: missed your ping yesterday, you want to chat about idp and domain now? | 15:37 |
| rodrigods | rderose, and the other way around it works via fks, right? | 15:38 |
| rodrigods | if i delete a domain, the idp is deleted | 15:38 |
| rderose | rodrigods: yes | 15:38 |
| rodrigods | hmm | 15:38 |
| *** adrian_otto has joined #openstack-keystone | 15:39 | |
| rodrigods | yeah... so i guess i don't have use case after all :) | 15:39 |
| rderose | :) | 15:39 |
| openstackgerrit | Merged openstack/keystone: Add doctor tests on security_compliance and rename https://review.openstack.org/408743 | 15:39 |
| dstanek | i think the only time anyone cares about the IdP is when they CRUD it or auth against it | 15:39 |
| dstanek | narasimha_SV: that's the point of federation. allows users from some other system to login to yours | 15:40 |
| rodrigods | rderose, can we update the domain_id? | 15:40 |
| narasimha_SV | ok | 15:41 |
| rderose | rodrigods no | 15:41 |
| rderose | rodrigods updates are not allowed | 15:41 |
| *** Marcellin__ has joined #openstack-keystone | 15:41 | |
| rodrigods | rderose, need to add this to the API ref? | 15:41 |
| rderose | rodrigods that updates are not allowed? | 15:41 |
| rodrigods | rderose, yep | 15:41 |
| rderose | rodrigods oh, you just had to find something, right? | 15:42 |
| rderose | :) | 15:42 |
| rodrigods | rderose, lol :) | 15:42 |
| *** pnavarro has joined #openstack-keystone | 15:44 | |
| rderose | rodrigods: domain_id is not in the update request: https://review.openstack.org/#/c/399157/12/api-ref/source/v3-ext/federation/identity-provider/idp.inc | 15:45 |
| rderose | rodrigods so may be good after all | 15:45 |
| rodrigods | rderose, it isn't but we need to say that | 15:45 |
| rodrigods | otherwise, in the future, we can just think "oh, we forgot to document updates" | 15:45 |
| rderose | rodrigods why, if it's not in the docs | 15:45 |
| rodrigods | rderose, because it is a field from the API object | 15:46 |
| rderose | rodrigods right, but it's not updatable, so can't be in an update request | 15:46 |
| rodrigods | but if you provide it, an error is returned | 15:46 |
| *** dave-mccowan has quit IRC | 15:46 | |
| *** udesale has quit IRC | 15:47 | |
| rderose | rodrigods 409? | 15:47 |
| rderose | rodrigods but if we already to this, then we should be consistent | 15:48 |
| rodrigods | rderose, not sure about the error code | 15:48 |
| rodrigods | but if i send an update of a field, i expect a return | 15:48 |
| rderose | rodrigods perfect | 15:48 |
| rodrigods | either a success or an error | 15:48 |
| rderose | rodrigods and appreciate the review btw | 15:49 |
| rodrigods | rderose, np :) | 15:49 |
| rodrigods | sorry for being picky | 15:49 |
| rderose | rodrigods nah, it's all good | 15:49 |
| dstanek | rderose: i think it's a validation error and not a 409 | 15:49 |
| rderose | dstanek: cool | 15:49 |
| *** henrynash has joined #openstack-keystone | 15:50 | |
| *** ChanServ sets mode: +v henrynash | 15:50 | |
| *** spilla has joined #openstack-keystone | 15:51 | |
| *** ngupta has joined #openstack-keystone | 15:51 | |
| *** henrynash has quit IRC | 15:53 | |
| *** ravelar has joined #openstack-keystone | 15:55 | |
| *** stingaci has joined #openstack-keystone | 15:56 | |
| *** tobberyd_ has joined #openstack-keystone | 15:56 | |
| *** jaugustine has joined #openstack-keystone | 15:57 | |
| *** ayoung has joined #openstack-keystone | 15:57 | |
| *** ChanServ sets mode: +v ayoung | 15:57 | |
| *** tobberydberg has quit IRC | 15:59 | |
| *** stingaci has quit IRC | 16:00 | |
| *** tobberyd_ has quit IRC | 16:00 | |
| lbragstad | policy meeting ping ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ayoung, ruan_05 | 16:00 |
| lbragstad | happening in #openstack-meeting-cp now | 16:00 |
| gagehugo | thanks | 16:01 |
| *** adrian_otto has quit IRC | 16:02 | |
| *** rcernin has quit IRC | 16:14 | |
| *** dave-mccowan has joined #openstack-keystone | 16:17 | |
| *** jaosorior has quit IRC | 16:20 | |
| *** jaosorior has joined #openstack-keystone | 16:20 | |
| *** nicolasbock has quit IRC | 16:25 | |
| *** adrian_otto has joined #openstack-keystone | 16:31 | |
| *** mvk has quit IRC | 16:32 | |
| *** dikonoor has quit IRC | 16:34 | |
| *** pnavarro has quit IRC | 16:35 | |
| *** nicolasbock has joined #openstack-keystone | 16:35 | |
| mfisch | stevemar: did you guys ever get all the special "is_admin" code out of the tree? The code that bypasses policy rules | 16:41 |
| * stevemar ropes in ayoung to answer mfisch | 16:43 | |
| mfisch | I hope I'm describing that right | 16:43 |
| stevemar | mfisch: you are | 16:43 |
| stevemar | mfisch: lets see if i know it | 16:44 |
| ayoung | mfisch, can you wait 20 mins? In the policy meeting | 16:44 |
| mfisch | sure | 16:44 |
| mfisch | no rush | 16:44 |
| stevemar | mfisch: you have to specify 'admin_project_name' and 'admin_project_domain_name' in keystone.conf first | 16:44 |
| stevemar | mfisch: and use the latest policy files for each project | 16:44 |
| mfisch | we're about to do that for something heat needs | 16:44 |
| stevemar | (those that have the policy changes anyway) | 16:44 |
| mfisch | I want to make a policy file that has a super-admin role basically | 16:45 |
| mfisch | meaning that you need admin + a special role to delete a project | 16:45 |
| mfisch | (for example) | 16:45 |
| *** chlong has quit IRC | 16:45 | |
| mfisch | "identity:delete_group": "rule:admin_required and role:project_deleter", | 16:46 |
| *** rcernin has joined #openstack-keystone | 16:46 | |
| akrzos | when will fernet tokens replace uuid as the default in tripleo clouds? (Not sure this is the right place over #tripleo to ask this question) | 16:47 |
| lbragstad | akrzos we've already made the switch in keystone | 16:48 |
| lbragstad | akrzos and I believe tripleo was working on it | 16:48 |
| lbragstad | ayoung and EmilienM might have better information than I though | 16:48 |
| *** jaosorior has quit IRC | 16:48 | |
| *** jaosorior has joined #openstack-keystone | 16:48 | |
| akrzos | lbragstad: rgr that thanks for the update | 16:48 |
| EmilienM | akrzos: I think it's done | 16:49 |
| EmilienM | akrzos: in Ocata | 16:49 |
| lbragstad | akrzos anytime | 16:49 |
| EmilienM | we just don't have key rotations yet | 16:49 |
| akrzos | EmilienM: cool I'll have to try and deploy some of the ocata bits | 16:49 |
| *** diazjf has joined #openstack-keystone | 16:50 | |
| *** guoshan has joined #openstack-keystone | 16:56 | |
| *** chlong has joined #openstack-keystone | 16:58 | |
| *** ruan_05 has joined #openstack-keystone | 17:00 | |
| *** guoshan has quit IRC | 17:01 | |
| *** Zer0Byte__ has joined #openstack-keystone | 17:03 | |
| ayoung | mfisch, OK so....maybe? | 17:05 |
| ayoung | mfisch, ADMIN_TOKEN can and should be disabled | 17:05 |
| ayoung | is_admin was based on that, so if you actively disable ADMIN_TOKEN, is_admin goes away | 17:06 |
| ayoung | the idea is that the functionality that ADMIN_TOKEN provided is done by bootstrap now | 17:06 |
| *** ruan_05 has quit IRC | 17:07 | |
| bknudson | mfisch: I was going to warn you about the v2 apis not using policy file, but they actually do use is_admin. | 17:08 |
| bknudson | as in, you can prevent someone using v3 to delete a project but not v2. | 17:08 |
| mfisch | bknudson: ayoung thanks | 17:09 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Add domain_id to the user table https://review.openstack.org/409874 | 17:09 |
| mfisch | so is_admin is more than just using the ADMIN_TOKEN right? | 17:09 |
| ayoung | mfisch, usual caveats apply: I lie. I make shit up. Verify everything I say against the source code. | 17:10 |
| mfisch | sure | 17:10 |
| mfisch | its easy enough to tr | 17:10 |
| mfisch | try | 17:10 |
| *** nklenke has quit IRC | 17:12 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Add domain_id to the user table https://review.openstack.org/409874 | 17:12 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Add domain_id to the user table https://review.openstack.org/409874 | 17:13 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 17:13 |
| *** edtubill has joined #openstack-keystone | 17:14 | |
| *** nklenke has joined #openstack-keystone | 17:14 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Add domain_id to the user table https://review.openstack.org/409874 | 17:16 |
| *** tqtran has joined #openstack-keystone | 17:21 | |
| *** diazjf has quit IRC | 17:24 | |
| *** diazjf has joined #openstack-keystone | 17:34 | |
| *** AlexeyAbashkin has quit IRC | 17:41 | |
| *** asettle has quit IRC | 17:48 | |
| *** jaosorior has quit IRC | 17:54 | |
| *** ngupta has quit IRC | 17:54 | |
| *** ngupta has joined #openstack-keystone | 17:55 | |
| *** guoshan has joined #openstack-keystone | 17:57 | |
| rderose | stevemar: you free? | 17:57 |
| dstanek | rderose: in my mind you should get enough information for the mappings to create the same unique_id, but i could see why that wouldn't be the case always | 17:58 |
| *** ngupta has quit IRC | 18:00 | |
| rderose | dstanek: I'm not getting info from the mappings | 18:00 |
| rderose | dstanek: I'm getting the info during auth or during an api call | 18:00 |
| stevemar | rderose: somewhat, will be more free in about 30 minutes | 18:02 |
| rderose | stevemar: no rush, just ping me when you have some time | 18:02 |
| *** guoshan has quit IRC | 18:02 | |
| dstanek | rderose: when we create users as the login we get that from the mapping output right? | 18:03 |
| *** asettle has joined #openstack-keystone | 18:04 | |
| dstanek | rderose: specifically here: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/plugins/mapped.py#n217 | 18:04 |
| dstanek | it wouldn't have to be something that is provided in the assertion. it can be something based off of that. | 18:04 |
| dstanek | rderose: for example, in my testshib environments i do this: https://github.com/dstanek/ansible-role-keystone-sp/blob/master/templates/mapping.json.j2#L6 | 18:05 |
| dstanek | that give me testshib:urlencoded_email as my unique ids | 18:05 |
| rderose | dstanek: you're right, the unique_id comes from the mapping | 18:06 |
| rderose | dstanek: currently, it's being set as the mapped user name or ID | 18:07 |
| dstanek | rderose: yep | 18:07 |
| openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 18:09 |
| dstanek | rderose: so a potential incompatibility is getting an email via SAML and and encoded email via openidc (we just to investigate those possibilities more) | 18:10 |
| rderose | dstanek: you could change the mapping to ensure they were the same unique id | 18:11 |
| rderose | dstanek: and when say federation, I think we should only be talking saml and openidc | 18:11 |
| dstanek | rderose: it depends on the source data. in that case there may be nothing you can do | 18:11 |
| dstanek | rderose: i'm not sure we want to say that. what about straight up oauth and i'm sure there's other things | 18:12 |
| rderose | dstanek: oauth is authorization | 18:13 |
| rderose | :) | 18:13 |
| dstanek | in keystone don't we have a very similar flow for it? | 18:14 |
| rderose | dstanek: not sure | 18:15 |
| dstanek | oidc is just oauth2++ anyway | 18:15 |
| rderose | dstanek: true | 18:15 |
| dstanek | and ayoung's kerberos example using REMOTE_USER is also very similar | 18:15 |
| dstanek | if the cases are similar does it make sense to have many different code paths? | 18:16 |
| rderose | dstanek: while depends on the source data, the source data is the same (the idp) | 18:16 |
| dstanek | i don't know the answer. i'm just posing the quesiton | 18:16 |
| rderose | dstanek: yeah, just think when it goes down the federation flow, it should be saml or openidc | 18:16 |
| rderose | those are the "federation" protocols we support | 18:17 |
| rderose | dstanek: to me, remote user is something different | 18:17 |
| *** asettle has quit IRC | 18:17 | |
| dstanek | isn't kerberos usable as a federation protocol? | 18:17 |
| dstanek | rderose: why do you say it's something different? | 18:18 |
| rderose | dstanek: it's a single sign-on implementation for sure, but is it a federation protocol? | 18:19 |
| stevemar | dstanek: its a bit different | 18:19 |
| dstanek | shibboleth is dropping a REMOTE_USER and that's how i do my mappings https://github.com/dstanek/ansible-role-keystone-sp/blob/master/templates/mapping.json.j2#L16 | 18:19 |
| stevemar | rderose: what was it you wanted to chat about? | 18:19 |
| rderose | the idp + domain patch | 18:20 |
| rderose | stevemar: ^ | 18:20 |
| stevemar | rderose: k, i'm looking at https://etherpad.openstack.org/p/keystone-idp-domain-questions | 18:20 |
| rderose | cool | 18:21 |
| openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 18:21 |
| *** david-lyle has quit IRC | 18:21 | |
| dstanek | stevemar: the question ayoung implied is if it is possible that a single IdP using different protocols could have different unique_ids because there is different information available to the mapping engine | 18:24 |
| ayoung | dstanek, I'm going to pull up jdennis' proposal | 18:25 |
| dstanek | rderose: easier to chat here. what if the domain you automatically create already exists? | 18:25 |
| ayoung | he did a very in depth mapping ,used for Open Daylight I think | 18:25 |
| *** ngupta has joined #openstack-keystone | 18:27 | |
| rderose | dstanek: the domain name would have to be the same as the idp_id for it to exist | 18:28 |
| rderose | dstanek: but it's a good point, that I'm not currently accounting for | 18:29 |
| *** markvoelker has quit IRC | 18:29 | |
| rderose | dstanek: my thought is, is that we would user a new uuid for the name in the situation | 18:29 |
| *** nklenke has quit IRC | 18:30 | |
| ayoung | dstanek, rderose so lets use the case where we have Kerberos, X509, and SAML all in play. For Kerberos REMOTE_USER is going to come in as ayoung@REDHAT.COM for X509 it will DN=cn=ayoug,ou=redhat,ou=com, and for saml is will be REMOTEUSER=ayoung@redhat.com | 18:30 |
| ayoung | all three should map to me | 18:30 |
| *** david-lyle has joined #openstack-keystone | 18:30 | |
| rderose | dstanek: the domain description indictates that it is a federated domain for IdP: idp_id | 18:30 |
| rderose | ayoung: is a remote user federation? | 18:31 |
| ayoung | rderose, yes. I want all users done via Federation | 18:31 |
| ayoung | I'd like to make even the internal Keystone users be considered Federated users | 18:31 |
| rderose | ayoung: my thinking is that saml and openidc are the only federation protocols we support | 18:31 |
| ayoung | rderose, and Kerberos and X509 | 18:32 |
| ayoung | rderose, I've had those working for years | 18:32 |
| ayoung | and it should be fine | 18:32 |
| *** diazjf has quit IRC | 18:32 | |
| dstanek | ayoung: but will you have enough other information to construct a unique id? | 18:32 |
| ayoung | X509 is used for Tokenless now | 18:32 |
| ayoung | dstanek, you should, yes | 18:32 |
| rderose | ayoung: but those aren't federation protocols; should go down a different flow | 18:32 |
| ayoung | rderose, they are absolutelty Federation | 18:32 |
| dstanek | rderose: why a different flow? how do you know saml vs kerberos? | 18:32 |
| ayoung | https://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/ | 18:33 |
| dstanek | fundamentially they both use remote_user | 18:33 |
| ayoung | and it does not matter even the Name of the the variable | 18:33 |
| ayoung | the set of known variables is listed here, BTW. Good reference: http://www.freeipa.org/page/Environment_Variables | 18:33 |
| dstanek | rderose: i guess the question is why do you want to limit it? | 18:34 |
| *** markvoelker has joined #openstack-keystone | 18:35 | |
| rderose | dstanek: simpler API and because saml and openidc are the industry standards | 18:35 |
| ayoung | rderose, limiting it is not an option. The question is how can we transform the unique identifier from the Assertion, regardless of protocol, into a canonical version that we can then match as the unique id | 18:35 |
| ayoung | rderose, no and no | 18:35 |
| rderose | :) | 18:36 |
| ayoung | Kerberos SSSD is acatiualy about 10000.2% easier | 18:36 |
| ayoung | and Kerberos has been the standard for Industry since Gates was still in charge of Microsoft | 18:36 |
| dstanek | rderose: you'd have to convince me that it's a simplier api | 18:36 |
| rderose | dstanek: by simpler, I'm talking about the user API | 18:37 |
| *** nklenke has joined #openstack-keystone | 18:37 | |
| dstanek | rderose: in the future if i don't supply a domain_id i'll get one created right? how do you pick the name you will use? | 18:37 |
| *** ayoung has left #openstack-keystone | 18:37 | |
| rderose | dstanek: currently using the idp_id | 18:37 |
| *** ayoung has joined #openstack-keystone | 18:37 | |
| *** ChanServ sets mode: +v ayoung | 18:37 | |
| dstanek | rderose: you'll have to show here is with the limit and here is without to see why it's more complicated | 18:37 |
| ayoung | OK...what key did I just hit to close this room by accident | 18:37 |
| dstanek | rderose: do we reject the idp create if the domain already exists? | 18:38 |
| ayoung | rderose, Federation is protocol agnostic | 18:38 |
| dstanek | ayoung: "i give up" | 18:38 |
| dstanek | it's right next to esc | 18:38 |
| rderose | ayoung: okay | 18:38 |
| ayoung | rderose, even if it was just SAML and OpenIDC, you would have this problem | 18:38 |
| stevemar | rderose: added more stuff to the etherpad | 18:39 |
| ayoung | rderose, we can use jdennis' engine, and it will make this all much clearer | 18:39 |
| rderose | ayoung: really? | 18:39 |
| rderose | stevemar: okay | 18:39 |
| stevemar | ayoung: get jdennis to push a patch upstream! | 18:39 |
| rderose | dstanek: if domain exists with the idp_id as the name, I'll use a new uuid | 18:40 |
| rderose | dstanek: either case, the domain description will be: "Federated domain for Identity Provider: idp_id" | 18:40 |
| ayoung | stevemar, so I think that is in cards | 18:40 |
| ayoung | if the version mapping thing that dstanek proposed goes through, it would work very nicely | 18:41 |
| stevemar | ayoung: doesn't even have to work properly with the current code base, just get the dang engine somewhere for us to look at | 18:41 |
| stevemar | we can make it fit | 18:41 |
| rderose | ayoung: if only SAML and OpenIDC, the unique_id would be different? | 18:41 |
| rderose | should be the same, same identity source | 18:41 |
| dstanek | rderose: we should document that as a test case | 18:42 |
| ayoung | rderose, not the format necessarily | 18:42 |
| ayoung | rderose, that is what I was getting at above. Kerberos is the most obvious example, as it does that weird ALL_CAPS_REALM | 18:42 |
| rderose | stevemar: currently, I'm not allowing updating the domain for an IdP | 18:43 |
| dstanek | ayoung: we control the format via mapping, but do we get the same context information to build it? | 18:43 |
| stevemar | rderose: any reason why? | 18:43 |
| rderose | stevemar: just the implications of changing the domain | 18:43 |
| dstanek | stevemar: because you'd switch the domain of all the federated users | 18:43 |
| stevemar | rderose: what if my fat fingers make a mitake? | 18:43 |
| rderose | stevemar: if you change the domain, what happens to all of the federated users created under the old domain | 18:44 |
| ayoung | rderose, please don't even propose dropping things like that. My blood pressure is already right at the max. Any higher and they say I need meds. | 18:44 |
| rderose | stevemar: delete the idp and create a new idp | 18:44 |
| rderose | ayoung: alright | 18:44 |
| ayoung | so long as deleting the IdP does not delete the domain, that is sufficient for now | 18:44 |
| rderose | ayoung: just wanted to go down that road one more time | 18:44 |
| ayoung | these are going to be rare operations. Just don't make things irreversable | 18:45 |
| rderose | before starting the user API work | 18:45 |
| rderose | ayoung: correct, deleting the idp does not delete the domain | 18:45 |
| ayoung | I'm almost tempted to say that the domain needs to be specified and explicit | 18:46 |
| ayoung | what happens now? We assume they go into the Federated domain as specified in theconfig file, right? | 18:46 |
| rderose | ayoung: would love it, but need to be backwards compatible | 18:46 |
| rderose | ayoung: users are associated to a hardcoded "Federated" domain | 18:47 |
| ayoung | so, no IdP specified, it stays there. IdP specified, go into the specified domain | 18:47 |
| rderose | stevemar: you okay with delete/create for fat finger issue? | 18:47 |
| ayoung | and then deprecate the default | 18:47 |
| rderose | ayoung: idp will be associated to a real domain either way | 18:49 |
| ayoung | yep | 18:50 |
| ayoung | I'm flexible. This stuff is done so infrequently, so long as we let people know, we could even break it and report it and it would be OK. | 18:51 |
| ayoung | Puppet module support is not even there yet for Federation | 18:51 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms https://review.openstack.org/409292 | 18:52 |
| ayoung | rderose, stevemar jdennis seems to be in, but not answering. I did find his old docs on it, though | 18:54 |
| ayoung | https://jdennis.fedorapeople.org/federated_mapping/mapping.html | 18:54 |
| ayoung | https://jdennis.fedorapeople.org/federated_mapping/strategy.html | 18:54 |
| ayoung | the second link documents the issues | 18:56 |
| samueldmq | rderose: are there any discussion going on regarding adding domain_id to IdP ? | 18:57 |
| samueldmq | rderose: I remember we had created an etherpad to that in the last meeting | 18:57 |
| rderose | samueldmq: yes, here: https://etherpad.openstack.org/p/keystone-idp-domain-questions | 18:57 |
| samueldmq | rderose: I've +2ed it, looks pretty good to me | 18:57 |
| rderose | samueldmq: sweet! | 18:58 |
| samueldmq | rderose: https://review.openstack.org/#/c/408332 is where we'll make use of that idp's domain_id to its users, right ? | 18:58 |
| rderose | samueldmq: yes | 18:59 |
| rderose | correct | 18:59 |
| lbragstad | stevemar quick question for you on the domain config stuff | 18:59 |
| lbragstad | stevemar right now we have this - https://github.com/openstack/keystone/blob/31713100f9f4dbf19caef6d54a81518c8cc45b5a/etc/policy.json#L194 | 18:59 |
| samueldmq | rderose: but if users don't have fderated attributes yet, how can you identify what users belong to what idp? | 18:59 |
| lbragstad | stevemar and https://github.com/openstack/keystone/blob/31713100f9f4dbf19caef6d54a81518c8cc45b5a/etc/policy.v3cloudsample.json#L221 | 18:59 |
| rderose | samueldmq I get the IdP from the auth plugin | 19:00 |
| lbragstad | in order for this to work - we'll have to loosen that up, but i remember you mentioning a way to get around that as we were talking about the spec | 19:00 |
| samueldmq | rderose: so you'll update it on-demand ? | 19:00 |
| samueldmq | rderose: and new users will get it set upon creation | 19:00 |
| rderose | samueldmq oh no, I'll do a migration to update the domain for federated users | 19:00 |
| jdennis | ayoung, stevemar, rderose: I'm not sure but I think the document ayoung found might be out of date, this ODL doc is current, it includes other stuff but see the section "The Mapping Rule Processor" https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf | 19:00 |
| rderose | samueldmq and users will get it on creation | 19:01 |
| samueldmq | rderose: ok but how does that migration will know what user belongs to what idp? | 19:01 |
| ayoung | jdennis, thanks. | 19:01 |
| rderose | samueldmq the idp_id is in the federated_user table | 19:01 |
| samueldmq | rderose: because there are federated users in the table, but no clue on what idp they belong to fill in the users' domain_id | 19:01 |
| ayoung | jdennis, is it a stand alone python packaged on PyPI? Is there any plan to make it into one? | 19:01 |
| rderose | samueldmq we capture during creation | 19:01 |
| samueldmq | rderose: ah sweet, easy peasy then | 19:02 |
| samueldmq | :) | 19:02 |
| rderose | samueldmq, | 19:02 |
| rderose | yeah | 19:02 |
| rderose | :) | 19:02 |
| ayoung | ah....that is also SSSD | 19:02 |
| *** lamt has joined #openstack-keystone | 19:03 | |
| ayoung | jdennis, so could sssd handle SAML, OpenIDC, and X509 authentication, and then perform the mapping? | 19:04 |
| ayoung | I know it can do Kerberos | 19:04 |
| ayoung | can mod_auth_mellon pass the variables to sssd and have mod_lookup_identity get them in the post mapped state? | 19:04 |
| rderose | stevemar: I've updated the etherpad, let me know if you have further questions | 19:08 |
| *** stingaci has joined #openstack-keystone | 19:09 | |
| jdennis | ayoung: the code is living in my private git repo, I could upload it to github | 19:11 |
| *** jdennis has quit IRC | 19:11 | |
| ayoung | hah | 19:11 |
| ayoung | run away! | 19:11 |
| *** amoralej is now known as amoralej|off | 19:11 | |
| *** jdennis has joined #openstack-keystone | 19:11 | |
| dstanek | rderose: i'm still a little concerned thats working policy for the 'federated' domain wouldn't work after the migration | 19:13 |
| jdennis | ayoung: I'm not sure SSSD is the right place to do the mapping simply because SSSD is not the right place to do federated authentication | 19:15 |
| *** nklenke has quit IRC | 19:16 | |
| *** nklenke has joined #openstack-keystone | 19:17 | |
| jdennis | ayoung: which goes to your second question as well, also the mapping is specific to a <service,idp> pair so I don't think you want SSSD to be managing all those unique pairs | 19:18 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor token_fernet symptoms https://review.openstack.org/410926 | 19:18 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms https://review.openstack.org/409289 | 19:19 |
| ayoung | jdennis, yeah, but code deployed is code usable | 19:19 |
| ayoung | dstanek, jdennis has the Python version of the mapping code he wrote in a private repo. It is released on ODL, but in Java. Want him to post it to a github or comparable, and see if it works in with you mapping -versioning scheme? | 19:20 |
| dstanek | jdennis: thx for the pdf link. reading it now | 19:20 |
| dstanek | ayoung: jdennis: i'd love to take a look | 19:21 |
| rderose | dstanek: so you have some policy rules based on the hardcoded 'Federated' domain? | 19:21 |
| *** ngupta has quit IRC | 19:21 | |
| dstanek | rderose: correct. could you do that today? | 19:22 |
| *** ngupta has joined #openstack-keystone | 19:22 | |
| rderose | dstanek: it's definitely something we'll have to address, however this patch is not changing that | 19:22 |
| dstanek | rderose: if you change the domains of all federated users wouldn't you change that? | 19:22 |
| rderose | dstanek: yes, but this patch is not changing the domains for federated users | 19:23 |
| rderose | dstanek: I have another patch for that | 19:23 |
| rderose | :) | 19:23 |
| dstanek | rderose: i just talking about the domain_id etherpad | 19:23 |
| rderose | dstanek: okay, I'll update my comment there | 19:24 |
| *** ngupta has quit IRC | 19:24 | |
| dstanek | rderose: i'm ok saying we won't be backward compatible there, but we need to call it out | 19:24 |
| *** ngupta has joined #openstack-keystone | 19:24 | |
| rderose | dstanek: agree | 19:25 |
| dstanek | lbragstad: did you see my message earlier about the mapping spec stuff? | 19:26 |
| jdennis | dstanek, ayoung: I don't really believe in mapping engines, to be powerful enough they start to look like programming languages so why not just an existing scripting language? The only issue with allowing an embedded script interpreter to evaluate a block of code to implement mapping is the problem of sandboxing the interpreter to prevent any loaded mapping code from being nefarious, my recommendation for OpenStack would be mapping is implement | 19:26 |
| lbragstad | dstanek i remember we were talking about it a bit this morning | 19:27 |
| lbragstad | dstanek was there something specific that i missed? | 19:27 |
| dstanek | lbragstad: do you think it's worth augmenting the existing spec or should it go into its own? | 19:28 |
| lbragstad | dstanek oh - you're talking about the auto-provisioning code and where that should live? | 19:28 |
| dstanek | lbragstad: specifically if you thnk i should update the shadow mapping spec with versioning or create a new one | 19:29 |
| lbragstad | dstanek ah - well, should the mapping changes required to achieve auto-provisioning be versioned? | 19:30 |
| lbragstad | dstanek i don't think those changes *require* a version, but *should* they? | 19:30 |
| dstanek | lbragstad: not really since you don't change anything about how the mapping actually works | 19:31 |
| lbragstad | dstanek well - we're changing the format of the mapping to include other things... | 19:31 |
| lbragstad | dstanek and also changing the mapping engine to pull those things out | 19:31 |
| lbragstad | dstanek but - this is all additive change | 19:32 |
| stevemar | rderose: i think that's good for now | 19:32 |
| rderose | stevemar: cool | 19:32 |
| stevemar | ayoung: want to take a look at https://etherpad.openstack.org/p/keystone-idp-domain-questions -- rderose and i jotted down some notes | 19:32 |
| dstanek | lbragstad: right. all mappings that already exist will continue to work | 19:33 |
| lbragstad | hm | 19:34 |
| lbragstad | which is good | 19:34 |
| lbragstad | dstanek well - how much work do you think it will be to introduce a version to the mapping? | 19:34 |
| lbragstad | dstanek and make the mapping engine understand it? | 19:35 |
| *** diazjf has joined #openstack-keystone | 19:36 | |
| dstanek | lbragstad: well, the first step is really just allowing the version through, which should be trivial. the second step will be more interesting and I'll have to take a deeper look, but it only matter when we have to have a version change | 19:37 |
| lbragstad | dstanek what's the second step? | 19:37 |
| lbragstad | dstanek incorporating the version into different mapping capabilities? | 19:38 |
| dstanek | dispatching based on version | 19:38 |
| lbragstad | dstanek ok - yeah the first step doesn't sound too bad at all | 19:38 |
| ayoung | stevemar, what if we disable existing IdPs until they have a domain_id set? | 19:38 |
| lbragstad | dstanek but the second might be more work, which makes me think we should isolate all the mapping version work into a separate spec | 19:39 |
| dstanek | lbragstad: not at all. add a new column and allow the data to flow through. in the absence of a value use the default | 19:39 |
| lbragstad | dstanek sure | 19:39 |
| dstanek | spec freeze this what day this week? | 19:39 |
| narasimha_SV | what is the importane of enabling a user in keystone ? | 19:39 |
| lbragstad | dstanek friday at the absolute latest | 19:40 |
| dstanek | narasimha_SV: disabled users can't auth | 19:41 |
| dstanek | lbragstad: then today it is! i'll just create a new one then | 19:41 |
| narasimha_SV | ok | 19:41 |
| lbragstad | dstanek so - should the auto-provisioning work wait for it? | 19:42 |
| lbragstad | would it be easier to implement the auto-provisioning work with a specific mapping version? | 19:42 |
| *** ngupta has quit IRC | 19:42 | |
| lbragstad | dstanek because if that is the case, then i'd be fine to push all that work to pike | 19:42 |
| *** ngupta has joined #openstack-keystone | 19:43 | |
| dstanek | lbragstad: no i don't think you need it for auto provisioning | 19:44 |
| lbragstad | dstanek ok | 19:45 |
| dstanek | lbragstad: based on what i saw this morning you won't even need to change anything in the mapping at all | 19:45 |
| dstanek | lbragstad: i mentioned to rderose that the added domain_id isn't useful since you will have a domain tied to the IdP | 19:45 |
| stevemar | ayoung: that's definitely possible | 19:46 |
| lbragstad | dstanek it's just a hook in the mapped plugin to call a federated method to auto-provision stuff based on whats in the mapping | 19:46 |
| lbragstad | but we do need to make the mapping engine handle keystone resource values | 19:46 |
| *** nklenke has quit IRC | 19:46 | |
| ayoung | stevemar, something like this: | 19:46 |
| dstanek | lbragstad: what do you mean? nothing in your spec seems different | 19:47 |
| ayoung | we make all IdPs disabled with no domain set in the migration | 19:47 |
| *** ngupta has quit IRC | 19:47 | |
| ayoung | when running bootstrap, provide an option to default domains | 19:47 |
| lbragstad | dstanek what about the additional attributes in http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html ? | 19:47 |
| lbragstad | dstanek http://cdn.pasteraw.com/mnx3bq9rpmu964h2h1adqpr75r4asow specifically | 19:47 |
| lbragstad | dstanek does the mapping engine just pass those through when processing mapping and assertion? | 19:48 |
| *** nklenke has joined #openstack-keystone | 19:49 | |
| dstanek | lbragstad: yes, that should be fine the local comes out as a dict of what you put in it with substitution applied. i don't think anything would have to change to impolement that | 19:49 |
| lbragstad | dstanek huh - awesome | 19:50 |
| *** stingaci has quit IRC | 19:50 | |
| lbragstad | dstanek so it's really just a conditional in the mapped plugin to pass the mapping to the federation_api | 19:50 |
| *** stingaci has joined #openstack-keystone | 19:50 | |
| lbragstad | and then a method in the federation_api to use the resource managers to create all the things | 19:50 |
| *** stingaci_ has joined #openstack-keystone | 19:52 | |
| narasimha_SV | http://paste.openstack.org/show/592394/ does this mapped rules file is sufficient ? | 19:53 |
| narasimha_SV | for k2k federation ? | 19:53 |
| *** stingaci has quit IRC | 19:55 | |
| dstanek | lbragstad: brb. have to get my kids | 19:55 |
| lbragstad | dstanek sounds good | 19:55 |
| *** guoshan has joined #openstack-keystone | 19:58 | |
| *** ayoung has quit IRC | 19:59 | |
| *** guoshan has quit IRC | 20:02 | |
| *** spzala has quit IRC | 20:04 | |
| dstanek | lbragstad: back! | 20:09 |
| lbragstad | dstanek fast! | 20:09 |
| lbragstad | dstanek grabbing coffee quick | 20:15 |
| *** adrian_otto has quit IRC | 20:16 | |
| *** asettle has joined #openstack-keystone | 20:18 | |
| dstanek | lbragstad: i lied to you a little | 20:20 |
| stevemar | ravelar: looking forward to your doctor patches! | 20:20 |
| *** asettle has quit IRC | 20:22 | |
| *** ngupta has joined #openstack-keystone | 20:23 | |
| lbragstad | dstanek why?! | 20:27 |
| openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 20:28 |
| lbragstad | dstanek alrighty - i'm caffinating, what's up? | 20:30 |
| dstanek | grrr...jas | 20:31 |
| dstanek | lbragstad: there is an additive change required | 20:31 |
| lbragstad | dstanek to the mapping engine? | 20:33 |
| lbragstad | for the auto provisioning stuff? | 20:33 |
| *** pcaruana has quit IRC | 20:33 | |
| *** rm_work has quit IRC | 20:34 | |
| *** rm_work has joined #openstack-keystone | 20:34 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Adds role mapping to the mapping engine https://review.openstack.org/410949 | 20:38 |
| dstanek | lbragstad: rderose: something like that ^ | 20:38 |
| *** tobberydberg has joined #openstack-keystone | 20:39 | |
| *** narasimha_SV has quit IRC | 20:39 | |
| lbragstad | dstanek ah - right | 20:40 |
| lbragstad | dstanek we never had to deal with the roles in the mapping because that was always done with the group assignments | 20:40 |
| dstanek | lbragstad: right. i thought we just pushed values through, but apparently we actually cherry pick what we want | 20:41 |
| dstanek | we also never supported lists | 20:41 |
| lbragstad | huh | 20:41 |
| lbragstad | that sucks | 20:41 |
| lbragstad | kind of | 20:42 |
| rderose | dstanek: nice | 20:42 |
| rderose | dstanek: groups are a list | 20:42 |
| lbragstad | dstanek so we will have a few more additive changes to make sure the provisioning bits from the mapping are pulled out. | 20:42 |
| *** ayoung has joined #openstack-keystone | 20:46 | |
| *** ChanServ sets mode: +v ayoung | 20:46 | |
| *** nklenke has quit IRC | 20:46 | |
| *** mvk has joined #openstack-keystone | 20:46 | |
| dstanek | rderose: it's not a list in the json sense | 20:48 |
| *** ayoung has quit IRC | 20:49 | |
| stevemar | lbragstad: o/ | 20:49 |
| rderose | dstanek: ah, I see | 20:50 |
| stevemar | lbragstad: so, thoughts on https://review.openstack.org/#/c/408837/ ? turns out it's not a trivial backport | 20:50 |
| lbragstad | stevemar but only for stable/mitaka? | 20:50 |
| stevemar | lbragstad: right | 20:52 |
| lbragstad | stevemar hmmm | 20:52 |
| lbragstad | that's weird | 20:53 |
| *** phalmos has quit IRC | 20:53 | |
| stevemar | lbragstad: the "make_request" method is not there: https://github.com/openstack/keystone/blob/74d4b58368dea07eab6653e5d91f93b474d6c8ca/keystone/tests/unit/core.py#L565 | 20:53 |
| lbragstad | stevemar ah... | 20:53 |
| stevemar | lbragstad: i tried to add that in and it depends on a bunch of changes we made to context | 20:53 |
| lbragstad | stevemar if i remember correctly - that was a large refactor that jamielennox did | 20:53 |
| stevemar | so don't go down that path | 20:53 |
| stevemar | yep | 20:53 |
| stevemar | lbragstad: was there something we used in tests that did a similar request? | 20:54 |
| lbragstad | right - i remember that | 20:54 |
| lbragstad | stevemar i thought so, because we needed that information regardless | 20:54 |
| stevemar | lbragstad: https://github.com/openstack/keystone/commit/da6ea7e2243aa13e626a2dbd5407477fcbd79c9c | 20:55 |
| lbragstad | ohhhh | 20:56 |
| lbragstad | context was just a dictionary | 20:56 |
| lbragstad | and you never really knew what was in it... | 20:57 |
| stevemar | lbragstad: eh maybe i got it | 20:58 |
| *** phalmos has joined #openstack-keystone | 21:02 | |
| *** lamt has quit IRC | 21:02 | |
| lbragstad | stevemar did you happen to see my comment about the security requirements api? | 21:03 |
| lbragstad | stevemar specifically around the default policy files? | 21:03 |
| stevemar | lbragstad: i did not | 21:04 |
| lbragstad | stevemar so - we do this https://github.com/openstack/keystone/blob/31713100f9f4dbf19caef6d54a81518c8cc45b5a/etc/policy.v3cloudsample.json#L221 | 21:05 |
| lbragstad | and this https://github.com/openstack/keystone/blob/31713100f9f4dbf19caef6d54a81518c8cc45b5a/etc/policy.json#L194 | 21:05 |
| lbragstad | so - we are going to have either loosen that or add a hack to the protected method for it | 21:06 |
| *** tobberydberg has quit IRC | 21:06 | |
| lbragstad | stevemar i thought i remember you having a way to get around that when we were discussing the spec but i couldn't remember it. | 21:06 |
| ravelar | stevemar: just needs a few more tests and should be all done :) | 21:07 |
| ravelar | gagehugo: ping? | 21:07 |
| gagehugo | ravelar: pong | 21:07 |
| ravelar | gagehugo ha! I just had a question about the last test. Just saw your review | 21:08 |
| gagehugo | ravelar what's up? | 21:08 |
| ravelar | to cause the method to return true would need cause configparser to throw and exception configparser.Error | 21:09 |
| ravelar | but I was wondering how one would be thrown without configparser checking for nosection, ect, in the method? Is there a way to get that to be raised? | 21:09 |
| *** diazjf has quit IRC | 21:11 | |
| gagehugo | yeah, if you put something invalid in the config, ie some key without an '=' and value, it will throw | 21:11 |
| stevemar | lbragstad: can't we have a new one? | 21:12 |
| gagehugo | ravelar: the Error is there to just catch anything wrong that configparser finds | 21:12 |
| stevemar | lbragstad: like: https://github.com/openstack/keystone/blob/31713100f9f4dbf19caef6d54a81518c8cc45b5a/etc/policy.json#L96-L97 | 21:12 |
| stevemar | lbragstad: https://github.com/openstack/keystone/blob/fc93521ed1fca2e8393cf2e53e0f79a61dec7222/keystone/assignment/controllers.py#L985-L999 | 21:13 |
| lbragstad | stevemar huh - interesting | 21:14 |
| ravelar | gagehugo: ahh okay then :) | 21:14 |
| lbragstad | stevemar what calls list_role_assignments_wrapper ? | 21:14 |
| lbragstad | the router? | 21:14 |
| stevemar | lbragstad: if config group == security compliance, return list_security_stuff (which is wrapped with a different policy); else call the other thang | 21:14 |
| stevemar | lbragstad: you betcha; https://github.com/openstack/keystone/blob/3e5ead0a45f698eed4162787b723090cee4733f8/keystone/assignment/routers.py#L200 | 21:15 |
| gagehugo | ravelar: np! | 21:15 |
| lbragstad | ah ha - https://github.com/openstack/keystone/blob/fc93521ed1fca2e8393cf2e53e0f79a61dec7222/keystone/assignment/routers.py#L200 | 21:15 |
| lbragstad | ok | 21:15 |
| stevemar | lbragstad: i wasn't a big fan of it when i first saw it | 21:15 |
| stevemar | but it won be over | 21:15 |
| lbragstad | stevemar yeah - interesting | 21:17 |
| stevemar | lbragstad: you're allowed to not like it :D | 21:19 |
| stevemar | lbragstad: we could always nix the whole damn thing | 21:19 |
| *** guoshan has joined #openstack-keystone | 21:20 | |
| lbragstad | stevemar true - but at the same time i'm not sure what I'd do instead? | 21:20 |
| *** r-daneel has joined #openstack-keystone | 21:20 | |
| *** asettle has joined #openstack-keystone | 21:21 | |
| *** chrisplo_ has joined #openstack-keystone | 21:22 | |
| lbragstad | stevemar the obviously solution would be to make it its own dedicated API, but then we're not holding to the conventions already in place with the domain config API | 21:22 |
| lbragstad | so that's out | 21:22 |
| lbragstad | the only other option i was thinking would work would be to hack the protected method, but that feels dirty and counter-intuitive to policy | 21:22 |
| *** chrisplo has quit IRC | 21:24 | |
| *** guoshan has quit IRC | 21:24 | |
| *** catintheroof has joined #openstack-keystone | 21:24 | |
| *** asettle has quit IRC | 21:25 | |
| stevemar | lbragstad: what you mean about "hack the protected method" | 21:28 |
| lbragstad | stevemar something to make it so that the protected method would not enforce admin policy on that specific call | 21:28 |
| lbragstad | but i don't like that | 21:28 |
| stevemar | lbragstad: could go with the wrapper route | 21:31 |
| lbragstad | stevemar like for list assignments? | 21:31 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor tokens symptoms https://review.openstack.org/410964 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Add tests for password requirements API https://review.openstack.org/410515 | 21:35 |
| lbragstad | stevemar are you ok with the contracts in those tests? ^ | 21:36 |
| *** diazjf has joined #openstack-keystone | 21:38 | |
| *** adriant has joined #openstack-keystone | 21:39 | |
| *** itisha has quit IRC | 21:42 | |
| lbragstad | stevemar hmm - apparently we have this https://github.com/openstack/keystone/blob/fc93521ed1fca2e8393cf2e53e0f79a61dec7222/keystone/resource/routers.py#L94-L114 | 21:43 |
| lbragstad | stevemar i totally didn't see that fact we already have a dedicated api for reading the default domain | 21:44 |
| stevemar | lbragstad: ah thats not the default domain | 21:47 |
| stevemar | lbragstad: that's reading the defaults of a specific config option | 21:47 |
| lbragstad | ah | 21:47 |
| lbragstad | nevermind | 21:47 |
| stevemar | lbragstad: http://developer.openstack.org/api-ref/identity/v3/index.html?expanded=show-default-configuration-settings-detail,show-default-configuration-for-a-group-detail,show-default-option-for-a-group-detail#show-default-configuration-settings | 21:48 |
| lbragstad | stevemar so accessing should still be done with /domains/{default_domain_id}/config/security_compliance | 21:48 |
| stevemar | lbragstad: i think so | 21:48 |
| lbragstad | ok | 21:48 |
| stevemar | lbragstad: fyi: just updated https://review.openstack.org/#/c/408837/4 and https://review.openstack.org/#/c/408838/4 | 21:49 |
| lbragstad | stevemar looks good minus the whitespace | 21:50 |
| stevemar | dammittttt | 21:50 |
| *** ravelar has quit IRC | 21:50 | |
| stevemar | fixed | 21:51 |
| stevemar | lbragstad: that took longer than i wanted | 21:53 |
| lbragstad | stevemar happens to the best of us | 21:53 |
| stevemar | lbragstad: not many commits between now and 2 weeks ago for ksc/ksm/ksa | 21:55 |
| stevemar | not going to both releasing til 2017 probably | 21:55 |
| lbragstad | stevemar works for me | 21:55 |
| stevemar | unless jamielennox really wants his token expiry thing merged | 21:55 |
| stevemar | lbragstad: easy merge: https://review.openstack.org/#/c/410964/1 | 21:56 |
| lbragstad | stevemar oh - yes, i wanted to review that | 21:56 |
| jamielennox | i do want it merged, it's harder than expected | 21:57 |
| stevemar | jamielennox: i left a comment on it | 22:02 |
| stevemar | jamielennox: isn't it only backwards incompatible if you intend to use the allow_expires flag? | 22:02 |
| stevemar | jamielennox: or are service users fundamentally affected? | 22:02 |
| jamielennox | stevemar: oh nice, that worked! | 22:03 |
| jamielennox | the first version was definitely incompatible, and ideally that's what we'd want | 22:03 |
| stevemar | jamielennox: it did indeed work | 22:04 |
| jamielennox | but i wanted to try it that way and see how if it still affected things and how we turn that policy check on | 22:04 |
| jamielennox | then yea, i think we need to make an effort to get that out asap | 22:05 |
| jamielennox | i'll clean up the docs etc now | 22:05 |
| stevemar | jamielennox: please do, i'll be able to mark the bp complete then ^_^ | 22:06 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: WIP: remove LDAP write support https://review.openstack.org/374482 | 22:07 |
| openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 22:10 |
| *** ayoung has joined #openstack-keystone | 22:11 | |
| *** ChanServ sets mode: +v ayoung | 22:11 | |
| jamielennox | stevemar, lbragstad: so there's a comment from edmondsw about whether the policy should be all roles in the list or any role in the list. thoughts? | 22:13 |
| jamielennox | also does this roles in middleware thing mean that oslo.policy is going to be in keystonemiddleware anyway? | 22:14 |
| edmondsw | jamielennox was there a reason you thought it should be all? | 22:14 |
| edmondsw | or even why it should be a list? | 22:15 |
| *** chrisplo_ has quit IRC | 22:15 | |
| edmondsw | and no, olso.policy would not be in keystonemiddleware with the spec you're referring to | 22:16 |
| lbragstad | jamielennox the spec sounded like it was any role in the list | 22:16 |
| jamielennox | edmondsw: well i thought it should be an oslo.policy rule, but that's a PITA - but that's why the bad variable name | 22:16 |
| lbragstad | jamielennox as far as i know, oslo.policy is still it's own thing that can do it's own checks | 22:16 |
| edmondsw | lbragstad ++ | 22:17 |
| *** lamt has joined #openstack-keystone | 22:17 | |
| jamielennox | i didn't really think much beyond a single item list however i can see that ['service', 'admin'] makes sense | 22:17 |
| jamielennox | and would have fixed the problem we had in devstack | 22:17 |
| lbragstad | the part i'm not quite clear on is if role checks can or should be refactored out of the policy files now that they won't be checked by oslo.policy | 22:17 |
| stevemar | jamielennox: so either role makes sense | 22:17 |
| jamielennox | its also likely that anyone using keystonemiddleware is also using oslo.policy so maybe just fix it properly that wway | 22:18 |
| lbragstad | jamielennox what do you mean by fix properly? | 22:18 |
| jamielennox | lbragstad: well theres a bunch of stuff you can do to assert service if you wanted, like role:service project_name:service domain_name:service | 22:19 |
| *** catintheroof has quit IRC | 22:19 | |
| jamielennox | just checking role is how we got into the admin everywhere mess to begin with | 22:19 |
| edmondsw | lbragstad, the only role that is checked in default policy files today is admin, and we probably need that to stay so that things work as they do today if you haven't used this new middleware approach (which is optional for deployers) | 22:20 |
| jamielennox | now it probably doesn't matter as much for services, but depending how people expect to lock that down it may be worth just hacking up oslo.policy so we can just assert one rule | 22:20 |
| lbragstad | ah | 22:21 |
| edmondsw | lbragstad and some of the references to admin in policy would have to stay so that you can do less scope checking if you're an admin than if you aren't | 22:22 |
| edmondsw | e.g. admin_or_owner... only does a scope check if you're NOT an admin | 22:23 |
| lbragstad | right | 22:23 |
| ayoung | I hate naming things | 22:24 |
| ayoung | jamielennox, I origianlly had it as a single role | 22:25 |
| ayoung | any expansion would be done via implied roles | 22:25 |
| edmondsw | though ideally I think the "or owner" piece of that should move into code and out of policy... it would never make sense for someone using a token scoped to project A to access a VM scoped to project B, so that project scope check should happen in code, not in policy where someone can mess it up | 22:25 |
| ayoung | edmondsw insisted on multiple roles per API, and I didn't have a good counter argument | 22:25 |
| edmondsw | ayoung that's not what we're talking about | 22:25 |
| *** edtubill has quit IRC | 22:26 | |
| ayoung | edmondsw, I'm processing througjh it as I read it | 22:26 |
| edmondsw | ++ | 22:26 |
| ayoung | edmondsw, but you really messed up my naming | 22:26 |
| ayoung | api_role was simple | 22:26 |
| ayoung | now I need a name for two things | 22:26 |
| ayoung | api_role_set? | 22:27 |
| edmondsw | I didn't say anything that should have caused to to have two things | 22:27 |
| ayoung | and api_role_set entry | 22:27 |
| ayoung | edmondsw, it was a single table before. Now I have two | 22:27 |
| edmondsw | in fact, I said you should only have one thing | 22:27 |
| edmondsw | there should only be one table | 22:27 |
| ayoung | edmondsw, and how do I do multiple roles per API? Duplicate the VERB+SERVICE+URL_PATTERN? | 22:27 |
| edmondsw | ayoung the roles field would hold a list | 22:28 |
| ayoung | NONONONONONONONONONONONONO | 22:28 |
| edmondsw | or what you said | 22:28 |
| ayoung | This is a relational database | 22:28 |
| ayoung | We belive in normalization | 22:28 |
| ayoung | VERB+SERVICE+URL_PATTERN is the api | 22:29 |
| edmondsw | yes | 22:29 |
| ayoung | and the other table is api_id and role_id | 22:29 |
| edmondsw | fine | 22:29 |
| ayoung | right. but the second table is the one that should be called the api_role table | 22:29 |
| jamielennox | so i've been out of keystone-sepcs for a bit but is that a dict of key -> list? | 22:29 |
| ayoung | so what is the first table then | 22:29 |
| ayoung | jamielennox, roughly | 22:30 |
| ayoung | I can point to the spec line, one sec | 22:30 |
| jamielennox | how is the list processed? any or all | 22:30 |
| edmondsw | what goes in the first except verb, service, url? | 22:30 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/keystone/ongoing/role-check-from-middleware.rst#n252 | 22:30 |
| edmondsw | jamielennox any | 22:31 |
| *** chrisplo_ has joined #openstack-keystone | 22:31 | |
| ayoung | jamielennox, any, but there is also a default which is only evaluated if none of the APIs match | 22:31 |
| jamielennox | ok, so if i make that service_role_policy process any then there is precedent | 22:31 |
| jamielennox | because it's too hard to do oslo.policy | 22:31 |
| ayoung | jamielennox, I might have missed the start of what you are tryiubng to do...I'm gonna go check evesdrop, one sec | 22:32 |
| edmondsw | ayoung, the role_id column for the api table doesn't seem to make sense | 22:32 |
| ayoung | but this was done in support of your standard policy effort. | 22:32 |
| *** adrian_otto has joined #openstack-keystone | 22:32 | |
| edmondsw | the interaction is with the api_roles table, not the role table | 22:33 |
| jamielennox | ayoung: https://review.openstack.org/#/c/382100/3/keystonemiddleware/auth_token/__init__.py L377 | 22:33 |
| ayoung | edmondsw, yeah, but the pkey that you pass in is the id of the api table | 22:33 |
| edmondsw | and there would be multiple rows potentially in api_roles, so not a single id to point to there | 22:33 |
| jamielennox | for checking the service token on allow_expired, i've done all roles in config must be present | 22:33 |
| ayoung | edmondsw, I think I would like to keep a single ID for each distinct API | 22:33 |
| edmondsw | that's API.id... not API.role_id | 22:34 |
| ayoung | edmondsw, right. | 22:34 |
| edmondsw | ayoung I think your API table should only have id, service, pattern, and verb | 22:35 |
| edmondsw | ayoung and then the api_role table is as you have it... api_id and role_id | 22:35 |
| ayoung | edmondsw, though, I made the url GET https://hostname:port/v3/api_roles?service=compute | 22:35 |
| ayoung | and I don't like that | 22:35 |
| ayoung | so would it be weird to make it | 22:35 |
| ayoung | GET https://hostname:port/v3/api?service=compute | 22:35 |
| *** chrisplo_ has quit IRC | 22:35 | |
| ayoung | an API API is wierd | 22:35 |
| edmondsw | ayoung why don't you like api_roles in the URI? | 22:36 |
| ayoung | so I was thinkging maybe the main table, instead of API should be api_role_set | 22:36 |
| edmondsw | don't confuse the db table with the API | 22:36 |
| ayoung | edmondsw, yeah, I know, but people are going to confuse them anyway. I want to keep the names distinct | 22:36 |
| edmondsw | ayoung there is nothing about roles in that first table, so api_role_set would be a crazy name | 22:36 |
| ayoung | edmondsw, maybe the api should be | 22:37 |
| *** browne has joined #openstack-keystone | 22:37 | |
| ayoung | GET https://hostname:port/v3/api_role_set?service=compute | 22:37 |
| edmondsw | ayoung I don't see why anyone would confuse them... the api_roles API would go through the api_roles table, which will then pull info from the api table... but the api_roles table is the starting point | 22:37 |
| edmondsw | nono | 22:38 |
| edmondsw | oh, let me backup... no, the api table would be the starting point, and then pull info from api_roles | 22:38 |
| edmondsw | I had that backwards | 22:38 |
| edmondsw | you'd query api, find the ids you want, and then go to api_roles via api_roles.api_id | 22:39 |
| edmondsw | ayoung I still think api_roles makes the most sense for the URL | 22:40 |
| edmondsw | ayoung and that you need to update the spec to pull role_id out of the api table | 22:40 |
| ayoung | edmondsw, put you pass in the api_id to the controller, in the case of | 22:41 |
| edmondsw | I assume that was just mistakenly left behind when you split role out to the api_roles table | 22:41 |
| ayoung | GET https://hostname:port/v3/api_roles/{uuid} | 22:41 |
| *** phalmos has quit IRC | 22:42 | |
| ayoung | OK, I think I can work with that...that is where I was headed, just needed to talk through it | 22:42 |
| edmondsw | GET v3/api/roles and GET v3/api/{uuid}/roles ? | 22:42 |
| ayoung | and GET v3/api/role?service=compute | 22:42 |
| edmondsw | yeah | 22:43 |
| edmondsw | s/role/roles/ | 22:43 |
| ayoung | and that way if we have other things we want to hang off the API, we can do it...ok | 22:43 |
| ayoung | right | 22:43 |
| ayoung | OK....dad mode ACTIVATE! | 22:43 |
| *** ayoung is now known as ayoung_dadmode | 22:43 | |
| edmondsw | bye | 22:43 |
| *** edmondsw has quit IRC | 22:45 | |
| *** edmondsw has joined #openstack-keystone | 22:46 | |
| *** edmondsw has quit IRC | 22:51 | |
| *** chrisplo_ has joined #openstack-keystone | 22:52 | |
| *** spilla has quit IRC | 22:53 | |
| *** dave-mccowan has quit IRC | 22:56 | |
| *** ngupta has quit IRC | 22:57 | |
| *** ngupta has joined #openstack-keystone | 22:58 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 23:00 |
| *** ngupta has quit IRC | 23:02 | |
| *** rcernin has quit IRC | 23:05 | |
| *** jaugustine has quit IRC | 23:12 | |
| *** ngupta has joined #openstack-keystone | 23:12 | |
| *** diazjf has quit IRC | 23:15 | |
| *** dave-mccowan has joined #openstack-keystone | 23:15 | |
| *** guoshan has joined #openstack-keystone | 23:21 | |
| *** asettle has joined #openstack-keystone | 23:22 | |
| *** guoshan has quit IRC | 23:25 | |
| *** dave-mccowan has quit IRC | 23:27 | |
| *** asettle has quit IRC | 23:27 | |
| *** edmondsw has joined #openstack-keystone | 23:29 | |
| *** edmondsw has quit IRC | 23:33 | |
| *** chris_hultin is now known as chris_hultin|AWA | 23:37 | |
| *** chlong has quit IRC | 23:37 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 23:47 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 23:52 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Pass ?allow_expired https://review.openstack.org/382100 | 23:53 |
| jamielennox | stevemar, lbragstad: ^ reasonably happy with that, i'd like to wait for something like it before next release | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!