| *** erus has quit IRC | 00:44 | |
| *** erus has joined #openstack-keystone | 00:45 | |
| *** jistr has quit IRC | 01:00 | |
| *** jistr has joined #openstack-keystone | 01:01 | |
| *** erus has quit IRC | 01:05 | |
| *** erus has joined #openstack-keystone | 01:05 | |
| *** markvoelker has joined #openstack-keystone | 01:23 | |
| *** markvoelker has quit IRC | 01:28 | |
| *** dklyle has joined #openstack-keystone | 01:32 | |
| *** blake has quit IRC | 01:33 | |
| *** blake has joined #openstack-keystone | 01:46 | |
| *** trident has quit IRC | 01:50 | |
| *** blake has quit IRC | 01:51 | |
| vishakha | lbragstad, cmurphy : The query is regarding with K2K usage in production. Do the remote user always login through horizon or use CLI for issuing token . I was just looking for some live examples of k2K running in production. Thank you. | 01:54 |
|---|---|---|
| *** gyee has quit IRC | 01:54 | |
| *** trident has joined #openstack-keystone | 01:55 | |
| *** blake has joined #openstack-keystone | 01:57 | |
| *** blake has quit IRC | 02:02 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 02:11 | |
| *** Dinesh_Bhor has quit IRC | 02:12 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 02:15 | |
| *** markvoelker has joined #openstack-keystone | 02:30 | |
| lbragstad | konetzed i'd probably start here https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py#L424 | 02:47 |
| lbragstad | the TokenModel object is meant to represent a keystone token in a pythonic way | 02:48 |
| lbragstad | so calling token.roles() on a application credential token should give you the roles that application credential has via the user's direct and indirect role assignment via group membership | 02:49 |
| lbragstad | we're hitting this bit - https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py#L433-L434 | 02:49 |
| lbragstad | we could elaborate on this method - https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py#L409-L419 | 02:50 |
| lbragstad | or we could extend the logic that creates application credentials to populate group memberships unless explicitly restricted to a set of roles. | 02:50 |
| *** rcernin has quit IRC | 02:58 | |
| konetzed | lbragstad: thank you! I am just about to give up for the night but your second link is exactly where I was hacking. I did borrow some code from https://github.com/openstack/keystone/blob/master/keystone/models/token_model.py#L396-L405 which works but it seem to grant same roles as the user has no any subset the app cred might have. Probably not the best solution but it was what i hacked out tonight :D | 03:23 |
| konetzed | thanks for all your help! | 03:23 |
| *** openstackgerrit has joined #openstack-keystone | 03:36 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Clarify docstrings for domain flask refactor https://review.openstack.org/620409 | 03:36 |
| *** rcernin has joined #openstack-keystone | 03:38 | |
| *** dklyle has quit IRC | 03:58 | |
| *** dave-mccowan has quit IRC | 04:34 | |
| *** dave-mccowan has joined #openstack-keystone | 04:35 | |
| *** dave-mccowan has quit IRC | 04:49 | |
| vishakha | lbragstad gmann frickler I have updated etherpad regarding the successful run of jobs of keystone repos on bionic. https://etherpad.openstack.org/p/devstack-bionic | 05:26 |
| *** imacdonn has quit IRC | 05:38 | |
| *** imacdonn has joined #openstack-keystone | 05:39 | |
| *** jackivanov has joined #openstack-keystone | 05:49 | |
| gmann | vishakha: frickler thanks. may be you can remove the DNM from this and merge the federation job keep running on xenial. and later you can check with lbragstad about how to fix that by installation from source etc - https://review.openstack.org/#/c/611563/ | 05:55 |
| *** blake has joined #openstack-keystone | 05:58 | |
| *** blake has quit IRC | 06:02 | |
| *** ondrejme has quit IRC | 06:40 | |
| *** nehaalhat__ has joined #openstack-keystone | 07:13 | |
| *** shrasool has quit IRC | 07:18 | |
| *** rcernin has quit IRC | 07:35 | |
| cmurphy | vishakha: you can use the cli with k2k, example here https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#testing-it-all-out | 07:37 |
| cmurphy | konetzed: that's been on my list to look at for a while, if you get something working ping me and i'll review asap :D | 07:40 |
| *** amoralej|off is now known as amoralej | 08:31 | |
| *** takamatsu has quit IRC | 08:31 | |
| *** dims has quit IRC | 08:32 | |
| *** dims has joined #openstack-keystone | 08:33 | |
| openstackgerrit | wangxiyuan proposed openstack/python-keystoneclient master: Add release notes for return-request-id-to-caller https://review.openstack.org/276644 | 08:43 |
| *** pcaruana has joined #openstack-keystone | 08:48 | |
| *** markvoelker has quit IRC | 08:50 | |
| openstackgerrit | Merged openstack/keystone master: Move test utility to common location https://review.openstack.org/620155 | 09:00 |
| *** takamatsu has joined #openstack-keystone | 09:13 | |
| *** sapd1 has quit IRC | 09:36 | |
| *** sapd1 has joined #openstack-keystone | 09:36 | |
| *** shrasool has joined #openstack-keystone | 09:44 | |
| *** markvoelker has joined #openstack-keystone | 09:51 | |
| *** blake has joined #openstack-keystone | 09:58 | |
| openstackgerrit | Merged openstack/oslo.policy master: Enhance test to prevent JSON parsing regression https://review.openstack.org/620173 | 09:59 |
| *** blake has quit IRC | 10:03 | |
| *** shrasool has quit IRC | 10:24 | |
| *** markvoelker has quit IRC | 10:24 | |
| *** nehaalhat__ has quit IRC | 10:27 | |
| *** sayalilunkad has quit IRC | 10:33 | |
| *** mbuil has quit IRC | 10:33 | |
| *** Dinesh_Bhor has quit IRC | 10:44 | |
| *** sayalilunkad has joined #openstack-keystone | 11:12 | |
| *** markvoelker has joined #openstack-keystone | 11:21 | |
| *** takamatsu has quit IRC | 11:25 | |
| *** takamatsu has joined #openstack-keystone | 11:31 | |
| *** aloga has quit IRC | 11:33 | |
| *** aloga has joined #openstack-keystone | 11:33 | |
| *** nehaalhat has joined #openstack-keystone | 11:34 | |
| *** raildo has joined #openstack-keystone | 11:45 | |
| *** rafaelweingartne has joined #openstack-keystone | 11:48 | |
| rafaelweingartne | Is somebody here using OpenStack federation with multiple IdPs? | 11:48 |
| *** markvoelker has quit IRC | 11:55 | |
| *** erus has quit IRC | 11:57 | |
| *** erus has joined #openstack-keystone | 11:57 | |
| *** amoralej is now known as amoralej|lunch | 11:58 | |
| *** takamatsu has quit IRC | 12:06 | |
| *** xek_ has joined #openstack-keystone | 12:12 | |
| *** dave-mccowan has joined #openstack-keystone | 12:15 | |
| *** xek_ has quit IRC | 12:21 | |
| *** erus has quit IRC | 12:22 | |
| *** erus has joined #openstack-keystone | 12:28 | |
| *** Nel1x has joined #openstack-keystone | 12:38 | |
| rafaelweingartne | Is somebody here using OpenStack federation (using OIDC protocol) with multiple IdPs? | 12:40 |
| openstackgerrit | Jens Harbott (frickler) proposed openstack/keystone master: Keep federation jobs running on Xenial https://review.openstack.org/611563 | 12:40 |
| frickler | lbragstad: cmurphy: amended as gmann suggested, so this should be able to be merged now with no impact, allowing QA to migrate to bionic without impacting keystone | 12:41 |
| cmurphy | frickler: zuul doesn't seem to like that | 12:47 |
| frickler | cmurphy: ah, yes, I'm introducing the new nodeset in devstack together with the bionic patch. need to split that probably | 12:48 |
| *** markvoelker has joined #openstack-keystone | 12:52 | |
| openstackgerrit | Jens Harbott (frickler) proposed openstack/keystone master: Keep federation jobs running on Xenial https://review.openstack.org/611563 | 13:00 |
| rafaelweingartne | Is somebody here using OpenStack federation (using OIDC protocol) with multiple IdPs? | 13:19 |
| *** markvoelker has quit IRC | 13:24 | |
| *** shrasool has joined #openstack-keystone | 13:34 | |
| *** blake has joined #openstack-keystone | 13:35 | |
| *** shrasool has quit IRC | 13:38 | |
| *** blake has quit IRC | 13:40 | |
| cmurphy | rafaelweingartne: sorry I haven't, do you have a specific question about it? are you just wondering how to set it up? | 13:41 |
| rafaelweingartne | I have a specific question regarding the WAYF process | 13:42 |
| rafaelweingartne | more specifically about the design implemented | 13:42 |
| rafaelweingartne | I deployed it, and it is indeed working, but the WAYF process is a little odd | 13:42 |
| *** awalende has joined #openstack-keystone | 13:42 | |
| cmurphy | you might ask the mod_auth_openidc maintainers or forums/ml/issue tracker about it | 13:42 |
| rafaelweingartne | the user selects the IdP to authenticate in Horizon (I have more then one), then horizon redirects the user to keystone to execute the authentication | 13:42 |
| rafaelweingartne | then, in Keystone the authentication is handled by the modOIDC of apache, and this module has its own WAYF process | 13:43 |
| rafaelweingartne | this means, the users is telling the system twice where he/she wants to authenticate | 13:43 |
| rafaelweingartne | I do not know if I miss something, but I have not found anything related to this in the docs | 13:43 |
| *** amoralej|lunch is now known as amoralej | 13:43 | |
| rafaelweingartne | so I was wondering if the problem is my setup or if it like that by design, and people are not using multiple IdPs, or handling this issue in some other manner | 13:44 |
| cmurphy | i don't really know how WAYF works, but if the apache module is handling the discovery of other idps then you could just not add them all to horizon and just configure it with one | 13:45 |
| awalende | Hi there, if I have an valid OIDC-AccessToken, can I transform it for an Keystone-Token via the REST-API? If yes, how? | 13:45 |
| rafaelweingartne | yes that is what I thought, but I wanted a complete solution. So, I am wondering, should I fix this in Keystone or Horizon. | 13:46 |
| rafaelweingartne | Then, I can push this fix to the community | 13:46 |
| cmurphy | rafaelweingartne: what do you think needs to be fixed? just don't add all the idps in your local_settings.py | 13:46 |
| rafaelweingartne | that is shallow | 13:46 |
| rafaelweingartne | Horizon can use "auth_request_params" from modOIDC | 13:46 |
| rafaelweingartne | to tell it what IDPs to use | 13:47 |
| rafaelweingartne | otherwise, I will need to customize the WAYF page in modOIDC | 13:47 |
| rafaelweingartne | Horizon page is nice already | 13:47 |
| rafaelweingartne | by using that parameter when building the authentication request URL to keystone, we can configure that parameter and tell modOID which IdP to use | 13:48 |
| rafaelweingartne | then, the WAYF process is not executed in Keystone, and everything will work nicely as if we had only a single IdP | 13:48 |
| knikolla | o/ | 13:48 |
| *** shrasool has joined #openstack-keystone | 13:50 | |
| rafaelweingartne | \send | 13:51 |
| rafaelweingartne | cmurphy I guess this would need to be coordinated with people that work with Horizon and Keystone. Do you have an idea how to check if this problem indeed exist, or if I am doing some misconfiguration? | 13:53 |
| cmurphy | rafaelweingartne: as far as I know we don't already have a solution for that in either keystone or horizon | 13:54 |
| rafaelweingartne | so, you guys were aware of this problem already then? | 13:55 |
| cmurphy | like I said I don't really have experience with WAYF in openidc so I can't offer much advice but it sounds like a reasonable thing to implement in horizon | 13:55 |
| cmurphy | maybe knikolla has thoughts | 13:55 |
| *** takamatsu has joined #openstack-keystone | 13:56 | |
| knikolla | reading back | 13:56 |
| knikolla | rafaelweingartne: so you have multiple idps in horizon, and when the user is redirected to keystone, they have to reselect the idp in the discovery page? | 14:03 |
| rafaelweingartne | Yes | 14:03 |
| rafaelweingartne | that is it | 14:03 |
| rafaelweingartne | I do understand why that is happening, because the module OIDC has no idea that the whole process started in Horizon | 14:03 |
| rafaelweingartne | it is protecting a resource in "Keystone only" | 14:04 |
| knikolla | horizon needs a way to pass a "hint" | 14:04 |
| knikolla | in oidc that is iss= | 14:04 |
| rafaelweingartne | yes | 14:04 |
| rafaelweingartne | that is it | 14:04 |
| knikolla | you could do some apache redirect hackery | 14:04 |
| rafaelweingartne | that sounds nasty in the long run to maintain it | 14:04 |
| rafaelweingartne | is that how you do it? | 14:05 |
| knikolla | no, because i have one idp | 14:05 |
| knikolla | which does brokering with multiple idps | 14:05 |
| knikolla | but that is something that horizon needs to add. | 14:06 |
| knikolla | support for passing hints. | 14:06 |
| knikolla | do you have sql users as well as federated users? | 14:07 |
| rafaelweingartne | no | 14:07 |
| rafaelweingartne | I mean, yes | 14:08 |
| rafaelweingartne | in theory we might use in in the future | 14:08 |
| rafaelweingartne | but for now, the idea is to start with federated users | 14:08 |
| rafaelweingartne | Thanks Knikolla, you clarified my doubt | 14:09 |
| knikolla | because horizon doesn't really save any state on that initial page. all that matters is when a user gets posted back to https://horizon/auth/websso/ | 14:09 |
| rafaelweingartne | so the problem exist, and I can then modify Horizon to create the URL for OIDC with a hint regarding the IdP | 14:09 |
| knikolla | so you could have the user be redirected to keystone directly and skip the first horizon step | 14:09 |
| rafaelweingartne | yes | 14:09 |
| rafaelweingartne | but horizon has a nice screen already :) | 14:09 |
| rafaelweingartne | I would not like to implement a maitain another page to provide a nice WAYF page | 14:10 |
| knikolla | i know. though because i don't have insight into horizon, workarounds is all i can suggest :) | 14:10 |
| rafaelweingartne | ah no proble | 14:11 |
| rafaelweingartne | I can manage that | 14:11 |
| knikolla | cool | 14:11 |
| rafaelweingartne | I only wanted to confirm that I was not missng something | 14:11 |
| rafaelweingartne | and that the problem indeed exist | 14:11 |
| knikolla | cmurphy: i'm working on the renewable app creds spec and would like to get a second opinion if you have time | 14:12 |
| cmurphy | knikolla: sure | 14:13 |
| *** tosky has joined #openstack-keystone | 14:14 | |
| knikolla | cmurphy: my first thought is to extend the current application credential model with the fields "expiring_roles", "roles_expire_at", and "roles_last_renewed_at" | 14:15 |
| knikolla | the other option would be to have a different type of app cred | 14:15 |
| cmurphy | knikolla: why does it need expiring_roles? wouldn't the regular roles list and a second expiration field do the trick? | 14:19 |
| cmurphy | having a different type of app cred sounds like it could get confusing for users | 14:20 |
| *** hoonetorg has quit IRC | 14:20 | |
| knikolla | cmurphy: there is a check that the user has that role in the project by querying the assignments. | 14:22 |
| knikolla | cmurphy: for ephemeral roles it would only check the token. | 14:23 |
| knikolla | another option would be to have a "renewable" bool, and have the current "expires_at" be the expiration time | 14:23 |
| knikolla | we do allow users to have app_creds that don't expire in the current implementation. with roles from the mapping, we want them to be short lived, and require periodic renewal. | 14:29 |
| cmurphy | i don't think we should reuse expires_at | 14:32 |
| cmurphy | that one should be controllable by the user, this new one should be forced i think | 14:33 |
| *** hoonetorg has joined #openstack-keystone | 14:33 | |
| knikolla | however i don't think we want to enforce expiration for app creds that don't have mapped roles. | 14:34 |
| cmurphy | right | 14:34 |
| knikolla | hence my dilemma. | 14:35 |
| knikolla | i don't want to make this confusing. | 14:35 |
| cmurphy | i think adding new fields will work | 14:36 |
| knikolla | alright. i'll write the spec now and elaborate on the "alternatives" section | 14:41 |
| * knikolla runs to pick up laundry | 14:41 | |
| *** awalende has quit IRC | 14:52 | |
| *** awalende has joined #openstack-keystone | 14:53 | |
| *** awalende has quit IRC | 14:53 | |
| *** awalende has joined #openstack-keystone | 14:53 | |
| *** xek has joined #openstack-keystone | 15:00 | |
| *** rafaelweingartne has quit IRC | 15:35 | |
| *** shrasool has quit IRC | 15:36 | |
| *** itlinux has quit IRC | 15:38 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update service provider policies for system reader https://review.openstack.org/620156 | 15:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update service provider policies for system member https://review.openstack.org/620157 | 15:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update service provider policies for system admin https://review.openstack.org/620158 | 15:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for domain users interacting with sps https://review.openstack.org/620159 | 15:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for project users interacting with sps https://review.openstack.org/620160 | 15:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove service provider policies from v3cloudsample.json https://review.openstack.org/620161 | 15:43 |
| *** awalende has quit IRC | 15:51 | |
| *** awalende has joined #openstack-keystone | 15:52 | |
| *** awalende has quit IRC | 15:56 | |
| *** dklyle has joined #openstack-keystone | 16:01 | |
| *** awalende has joined #openstack-keystone | 16:02 | |
| * lbragstad finds more coffee | 16:03 | |
| *** awalende_ has joined #openstack-keystone | 16:04 | |
| *** awalende_ has quit IRC | 16:05 | |
| *** awalende has quit IRC | 16:07 | |
| *** ayoung has joined #openstack-keystone | 16:09 | |
| *** erus has quit IRC | 16:17 | |
| *** erus has joined #openstack-keystone | 16:29 | |
| *** blake has joined #openstack-keystone | 16:30 | |
| *** blake has quit IRC | 16:30 | |
| *** fiddletwix has joined #openstack-keystone | 16:43 | |
| *** itlinux has joined #openstack-keystone | 16:54 | |
| *** ayoung has quit IRC | 16:56 | |
| nsmeds | morning/evening. difference between `limit` and `registered limit`? appears that registered limit is system default and limit is project specific overrides | 17:02 |
| nsmeds | just wanting to confirm | 17:02 |
| *** david-lyle has joined #openstack-keystone | 17:04 | |
| *** dklyle has quit IRC | 17:05 | |
| *** gyee has joined #openstack-keystone | 17:09 | |
| cmurphy | nsmeds: that's correct | 17:27 |
| kmalloc | cmurphy, knikolla: hmm | 17:27 |
| kmalloc | i really am unsure if we need *another* mechanism for communicating when an app cred expires | 17:27 |
| kmalloc | added fields for "ephemeral roles" and "refreshable" are things | 17:27 |
| kmalloc | but really we should lean on the technology / code we already have for pure expiration | 17:28 |
| kmalloc | expiry time is not changable after an app cred is created (they are "immutable" outside of the refresh parts) | 17:28 |
| cmurphy | kmalloc: what if a federated user wants to set a non-refreshable expiration on an app cred | 17:29 |
| kmalloc | knikolla, cmurphy: also the question is for emphemerally communicated roles, do we invalidate the cred (in whole) if the roles are gone or do we minimize the app cred roles to what has been removed. | 17:29 |
| kmalloc | cmurphy: if it doesn't contain ephemeral roles, no problem. | 17:29 |
| kmalloc | ephemerally communicated roles (IDP supplied) would require expiration | 17:30 |
| cmurphy | kmalloc: invalidate the cred in whole, same as we do if one role is revoked | 17:30 |
| kmalloc | cmurphy: ++ ok good on that. | 17:30 |
| kmalloc | and expiration would be the fixed timeframe for refresh | 17:30 |
| kmalloc | we could go with an alternative with a create/refresh timestamp and a configuration (for the IDP) on how long the app cred is good for | 17:30 |
| kmalloc | but if you're going to do it as a strict expiration timestampe, use the column we have | 17:31 |
| kmalloc | if that makes sense. | 17:31 |
| * kmalloc is actually inclined to say we do it as creation/last-refreshed and the IDP...or somesuch supplies how long their app creds are good for | 17:31 | |
| cmurphy | i don't think that makes sense, because i can imagine a user wants to create an app cred that expires at a certain time regardless of whether the user happens to log in to do other things | 17:31 |
| kmalloc | hm. | 17:31 |
| kmalloc | i don't want to have two fixed expiration times... if that makes sense | 17:32 |
| kmalloc | the reason for the last-refreshed and a time communicated by the IDP means we can do a check | 17:32 |
| kmalloc | IS_EXPIRED(expired_time), IS_EXPIRED(last-refreshed+IDP Window) | 17:33 |
| kmalloc | in that order | 17:33 |
| kmalloc | but having a refresh_expires_at Timestamp seems contrary to the "this is a configurable value" | 17:33 |
| kmalloc | because a misconfiguration could communicate a very very long refresh that is inappropriatly exempted from refreshing for much longer than expected | 17:34 |
| * kmalloc is catching up. | 17:35 | |
| cmurphy | kmalloc: what is "IDP Window"? who sets that? is that a property on the app cred? | 17:36 |
| kmalloc | a property on the source of Identity for the role(s) | 17:37 |
| kmalloc | for the user | 17:37 |
| kmalloc | e.g. if the user adds a role communicated from an IDP, the app cred references that IDP's refresh requirements | 17:37 |
| kmalloc | so the appcred has: expires_at (set by user). and *if* a role is included from an IDP source (that is also non-concretely assigned), the app cred has, Refreshable_roles(roleX,...) and RefreshTime() | 17:38 |
| cmurphy | kmalloc: okay yes that sounds good | 17:39 |
| kmalloc | when we check expiration we check expires_at *and* refreshed_at (RefreshTime()) + the shortest IDP "refresh time requirement" of the roles communicated | 17:39 |
| kmalloc | that way IDPs are configured with a timewindow that affects all app creds that use it's roles. | 17:39 |
| kmalloc | and we don't end up with app creds that snuck in before/after the refresh-rquirement was changed | 17:39 |
| cmurphy | if expires_at is always user set and there's a whole other thing to do the refresh expiration that works for me | 17:40 |
| kmalloc | yes | 17:40 |
| kmalloc | and i want it tied to the IDP | 17:40 |
| kmalloc | not just a timestamp value | 17:40 |
| cmurphy | sure | 17:40 |
| kmalloc | i just didn't want expires_at(static timestamp) and refresh_expires_at(static timestamp) | 17:40 |
| kmalloc | i think we're on the same page then. | 17:41 |
| cmurphy | yep | 17:42 |
| *** amoralej is now known as amoralej|off | 18:05 | |
| *** david-lyle has quit IRC | 18:15 | |
| knikolla | kmalloc: thanks, i do see the issues with static timestamps | 18:19 |
| *** jistr has quit IRC | 18:19 | |
| *** jistr has joined #openstack-keystone | 18:19 | |
| knikolla | so new fields renewed_at, renewable_roles | 18:19 |
| knikolla | and app_cred_renew_window should be on a per idp basis | 18:20 |
| kmalloc | yeah | 18:20 |
| knikolla | when user tries to renew but doesn't have one or more of the roles, invalidate entire app cred | 18:21 |
| kmalloc | the renewable_roles should reference the static assignments (preferred if it exists) and then renewable roles. | 18:21 |
| kmalloc | erm | 18:21 |
| kmalloc | wait | 18:21 |
| kmalloc | no | 18:21 |
| kmalloc | app_cred roles should reference concrete roles first if assigned. then renewable/communicated roles | 18:22 |
| kmalloc | and we reference the IDPs configuration for the renewable time window | 18:22 |
| kmalloc | if multiple IDPs communicate the role we should ... select which IDP for the refresh window? | 18:23 |
| kmalloc | this should be a reference that checks the IDP config each time not some static value on the app_Cred. | 18:23 |
| knikolla | then that means we need a per idp list in the app cred | 18:24 |
| knikolla | per idp role list | 18:24 |
| knikolla | or we can restrict it one app cred per 1 idp | 18:25 |
| kmalloc | that is what i'm not sure about. | 18:32 |
| kmalloc | we could chose to select the IDP with the longest expiration window | 18:32 |
| kmalloc | for each role | 18:33 |
| kmalloc | which at least makes it easier. | 18:33 |
| kmalloc | but we probably need to communicate to the user which IDP communicated the role(s) anyway | 18:33 |
| kmalloc | so they can be sure to refresh it | 18:34 |
| kmalloc | so yeah we need a list-per-idp | 18:34 |
| kmalloc | we have to track this information anyway. | 18:34 |
| knikolla | makes sense | 18:41 |
| knikolla | i'll jot this down in the spec and maybe we can have a discussion with the rest of the team during next week's meeting. | 18:41 |
| *** dklyle has joined #openstack-keystone | 18:45 | |
| *** ayoung has joined #openstack-keystone | 18:46 | |
| kmalloc | ++ | 18:48 |
| *** fiddletwix has quit IRC | 18:58 | |
| *** dklyle has quit IRC | 19:07 | |
| *** xek has quit IRC | 19:23 | |
| *** shrasool has joined #openstack-keystone | 19:26 | |
| *** markvoelker has joined #openstack-keystone | 19:36 | |
| *** markvoelker has quit IRC | 19:40 | |
| *** shrasool has quit IRC | 19:48 | |
| *** shrasool has joined #openstack-keystone | 19:49 | |
| *** shrasool has quit IRC | 19:51 | |
| *** itlinux has quit IRC | 19:56 | |
| *** markvoelker has joined #openstack-keystone | 20:00 | |
| *** fiddletwix has joined #openstack-keystone | 20:04 | |
| nsmeds | curious about `is_admin_project:True` | 20:09 |
| nsmeds | what can I query to find out if a project has this label? | 20:09 |
| nsmeds | I've attempted applying the v3cloudpolicy to Keystone but a user outside of the cloud_admin domain was able to create users in domains besides their own | 20:10 |
| lbragstad | is_admin_project was an attempt to try and isolate system-specific operations behind a project | 20:11 |
| lbragstad | for example, if users had a role assignment on the "admin" project, they would be given elevated privileges to do things (even if they fell outside of project scope) | 20:11 |
| lbragstad | is_admin_project:True and system-scope are meant to solve the same problem | 20:12 |
| nsmeds | ok. But how can I tell what project is the "admin" project? | 20:15 |
| nsmeds | using python client, `openstack project show <project>` doesn't reveal anything | 20:15 |
| *** awalende has joined #openstack-keystone | 20:17 | |
| *** awalende_ has joined #openstack-keystone | 20:18 | |
| *** shrasool has joined #openstack-keystone | 20:18 | |
| *** shrasool has quit IRC | 20:19 | |
| nsmeds | https://gist.github.com/nikosmeds/b643120db46736164cf67ebcb33bc1cf has some info - I'm able to create a user when I believe policy should restrict it | 20:20 |
| *** awalende has quit IRC | 20:22 | |
| lbragstad | nsmeds the admin_project is a configuration option | 20:23 |
| lbragstad | it's not consistent across deployments | 20:23 |
| lbragstad | https://docs.openstack.org/keystone/latest/configuration/config-options.html#resource.admin_project_name | 20:24 |
| nsmeds | just grepped `keystone.conf` and dont have it configured | 20:26 |
| nsmeds | so, based on my rules in the above gist, unsure why I was able to create a user | 20:26 |
| nsmeds | hmm | 20:27 |
| *** awalende has joined #openstack-keystone | 20:30 | |
| *** awalend__ has joined #openstack-keystone | 20:30 | |
| *** awalende_ has quit IRC | 20:31 | |
| lbragstad | nsmeds when you authenticate for a token, do you see the admin_project property set? | 20:33 |
| *** awalende has quit IRC | 20:34 | |
| lbragstad | like, in the token response body? | 20:35 |
| nsmeds | so I just have `OS_` environment values set, and using python client to run `openstack ...` commands | 20:36 |
| nsmeds | let me see if I can find that | 20:36 |
| lbragstad | if you do something like ``openstack token issue --debug`` you'll see the actual response body because osc will log it for you | 20:36 |
| lbragstad | for example - https://pasted.tech/pastes/a678e488f58bb3a2f98fde9796ee06f1372ed877.raw | 20:37 |
| nsmeds | amazing, thanks | 20:38 |
| nsmeds | openstack token issue --help doesn't suggest --debug, but it works =) | 20:38 |
| openstackgerrit | Merged openstack/python-keystoneclient master: Add return-request-id-to-caller function(v3/contrib) https://review.openstack.org/268003 | 20:40 |
| openstackgerrit | Merged openstack/python-keystoneclient master: Add release notes for return-request-id-to-caller https://review.openstack.org/276644 | 20:40 |
| nsmeds | this looks questionable (part of the response) | 20:41 |
| nsmeds | https://gist.github.com/nikosmeds/e016954d80f0fe64f33e573dd0c09282 | 20:41 |
| nsmeds | the `project_domain_id` is set to `default` | 20:41 |
| *** erus has quit IRC | 20:42 | |
| nsmeds | nothing related to admin_project however | 20:42 |
| lbragstad | ok - nevermind | 20:43 |
| lbragstad | that might only be present if you have an admin project configured | 20:44 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/common/render_token.py#L94-L101 | 20:44 |
| nsmeds | updated https://gist.github.com/nikosmeds/e016954d80f0fe64f33e573dd0c09282 - token seems correctly scoped for the test domain/project | 20:47 |
| nsmeds | :shrug: I'll keep playing around and try to make sense of this world | 20:48 |
| lbragstad | are you use you're specifying the policy file through config? | 20:50 |
| lbragstad | https://docs.openstack.org/keystone/latest/configuration/config-options.html#oslo_policy.policy_file | 20:50 |
| *** raildo has quit IRC | 20:50 | |
| *** raildo has joined #openstack-keystone | 20:51 | |
| *** raildo has quit IRC | 20:51 | |
| nsmeds | nope (just using default). Deploy with openstack-ansible, which handles most of this for us. But my changes (via OSA) to the policy file have been applying, as I broke something else earlier | 20:51 |
| nsmeds | just grepped keystone.conf, no overwriting `policy_file`, but overwrites are going to `policy.json` in same dir | 20:52 |
| lbragstad | ok - so you should be picking up those changes in policy.json | 20:54 |
| nsmeds | correct - all the v3cloud policy changes appear in policy.json | 20:55 |
| nsmeds | by default its an empty file | 20:55 |
| nsmeds | https://gist.github.com/nikosmeds/d53e014365e444b62fcf08486b8f58a6 (just spamming the channel with gists) | 20:56 |
| nsmeds | somehow related to running Queens? (though everything I've read suggests this should work on queens) | 21:00 |
| *** erus has joined #openstack-keystone | 21:06 | |
| *** dklyle has joined #openstack-keystone | 21:10 | |
| nsmeds | I'm wondering if openstack-ansible is somehow related. Ran into interesting error when trying to make small change https://gist.github.com/nikosmeds/6bc29b00c05222f94fa62a3adfffff5a . I'll bring this issue over to them | 21:20 |
| lbragstad | nsmeds that last error looks unrelated to policy? | 21:26 |
| nsmeds | lbragstad: agreed - but it only occurs when I try to make that 1 line change | 21:27 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add registered limit protection tests https://review.openstack.org/621014 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update registered limit policies for system member https://review.openstack.org/621015 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update registered limit policies for system admin https://review.openstack.org/621016 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for domain users interacting with registered limits https://review.openstack.org/621017 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for project users interacting with registered limits https://review.openstack.org/621018 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove registered limit policies from policy.v3cloudsample.json https://review.openstack.org/621019 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add limit protection tests https://review.openstack.org/621020 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update limit policies for system member https://review.openstack.org/621021 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update limit policies for system admin https://review.openstack.org/621022 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for domain users interacting with limits https://review.openstack.org/621023 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add tests for project users interacting with limits https://review.openstack.org/621024 | 21:34 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove limit policies from policy.v3cloudsample.json https://review.openstack.org/621025 | 21:34 |
| *** markvoelker has quit IRC | 21:38 | |
| *** markvoelker has joined #openstack-keystone | 21:38 | |
| *** dklyle has quit IRC | 21:39 | |
| *** markvoelker has quit IRC | 21:43 | |
| *** rcernin has joined #openstack-keystone | 21:57 | |
| *** markvoelker has joined #openstack-keystone | 22:01 | |
| *** awalend__ has quit IRC | 22:05 | |
| *** xek has joined #openstack-keystone | 22:11 | |
| *** erus has quit IRC | 22:14 | |
| *** dklyle has joined #openstack-keystone | 22:19 | |
| *** dklyle has quit IRC | 22:24 | |
| *** dklyle has joined #openstack-keystone | 22:32 | |
| *** dklyle has quit IRC | 22:44 | |
| *** xek has quit IRC | 22:44 | |
| openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: Make upgrades more robust with policy overrides https://review.openstack.org/614195 | 22:45 |
| nsmeds | lbragstad: found the underlying Ansible role and disabled `no_log`, https://gist.github.com/nikosmeds/6bc29b00c05222f94fa62a3adfffff5a has been udpated with the error | 22:57 |
| nsmeds | looks like something depends on the admin_project being configured | 22:57 |
| lbragstad | aha - interesting | 23:11 |
| jdennis | lbragstad: is there a way to view the log file you pointed me with line breaks, it's hard to read with everything squashed toegher | 23:45 |
| jdennis | lbragstad: never mind, getting rid of the query params in the url seemed to work | 23:47 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!