Thursday, 2019-02-21

*** jamesmcarthur has quit IRC00:01
*** itlinux has joined #openstack-keystone00:05
*** itlinux has quit IRC00:06
*** erus has quit IRC00:06
*** erus has joined #openstack-keystone00:06
*** markvoelker has joined #openstack-keystone00:19
*** erus has quit IRC00:36
*** erus has joined #openstack-keystone00:37
*** mvkr has quit IRC00:40
*** mvkr has joined #openstack-keystone00:42
*** marst has joined #openstack-keystone00:50
openstackgerritLance Bragstad proposed openstack/keystone master: Implement system reader for role_assignments  https://review.openstack.org/60921001:08
openstackgerritLance Bragstad proposed openstack/keystone master: WIP: Additional work for testing assignment protection  https://review.openstack.org/63682501:08
openstackgerritLance Bragstad proposed openstack/keystone master: Reorganize role assignment tests for system users  https://review.openstack.org/63830901:08
openstackgerritLance Bragstad proposed openstack/keystone master: Add role assignment test coverage for system members  https://review.openstack.org/63831001:08
openstackgerritLance Bragstad proposed openstack/keystone master: Add role assignment test coverage for system admin  https://review.openstack.org/63831101:08
*** whoami-rajat has joined #openstack-keystone01:12
*** erus has quit IRC01:44
*** erus has joined #openstack-keystone01:45
*** gyee has quit IRC02:06
*** jamesmcarthur has joined #openstack-keystone02:10
lbragstadpas-ha https://pasted.tech/pastes/ec9618b32aa49b7bbca9c4f32a014c83995d79da.raw02:21
*** jamesmcarthur has quit IRC02:37
*** Dinesh_Bhor has joined #openstack-keystone02:41
*** jamesmcarthur has joined #openstack-keystone02:42
*** marst has quit IRC02:46
*** erus has quit IRC02:46
*** erus has joined #openstack-keystone02:47
*** dklyle has quit IRC03:03
*** jamesmcarthur has quit IRC03:08
lbragstadpas-ha http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2019-02-21.log.html#t2019-02-21T02:03:3803:13
*** dklyle has joined #openstack-keystone03:17
*** vishakha has joined #openstack-keystone03:18
*** markvoelker has quit IRC03:20
*** jamesmcarthur has joined #openstack-keystone03:32
*** spsurya has joined #openstack-keystone03:34
*** imus has joined #openstack-keystone03:48
*** imus has quit IRC03:56
*** jamesmcarthur has quit IRC04:00
*** jamesmcarthur has joined #openstack-keystone04:01
*** jamesmcarthur has quit IRC04:05
*** markvoelker has joined #openstack-keystone04:21
lbragstadpas-ha https://review.openstack.org/#/c/638327/04:25
*** gagehugo has joined #openstack-keystone04:29
*** markvoelker has quit IRC04:55
*** erus has quit IRC05:04
*** erus has joined #openstack-keystone05:05
*** shyamb has joined #openstack-keystone05:19
*** erus has quit IRC05:41
*** erus has joined #openstack-keystone05:42
*** erus has quit IRC05:48
*** erus has joined #openstack-keystone05:48
*** markvoelker has joined #openstack-keystone05:52
*** lbragstad_ has joined #openstack-keystone05:53
*** ChanServ sets mode: +o lbragstad_05:53
*** lbragstad has quit IRC05:55
*** lbragstad has joined #openstack-keystone06:04
*** ChanServ sets mode: +o lbragstad06:04
*** lbragstad_ has quit IRC06:04
*** lbragstad_ has joined #openstack-keystone06:09
*** ChanServ sets mode: +o lbragstad_06:09
*** lbragstad has quit IRC06:10
*** lbragstad has joined #openstack-keystone06:16
*** ChanServ sets mode: +o lbragstad06:16
*** lbragstad_ has quit IRC06:18
*** markvoelker has quit IRC06:25
*** spsurya has quit IRC06:25
*** erus has quit IRC06:26
*** erus has joined #openstack-keystone06:26
*** shyamb has quit IRC06:55
*** shyamb has joined #openstack-keystone07:06
*** rcernin has quit IRC07:13
*** spsurya has joined #openstack-keystone07:17
*** pcaruana has joined #openstack-keystone07:19
*** markvoelker has joined #openstack-keystone07:22
*** shyamb has quit IRC07:37
*** Dinesh_Bhor has quit IRC07:49
*** markvoelker has quit IRC07:55
*** jaosorior has quit IRC08:08
*** awalende has joined #openstack-keystone08:15
*** erus has quit IRC08:23
*** tkajinam has quit IRC08:23
*** erus has joined #openstack-keystone08:23
*** lbragstad has quit IRC08:25
*** josecastroleon has quit IRC08:34
*** aloga has quit IRC08:48
*** erus has quit IRC08:48
*** aloga has joined #openstack-keystone08:48
*** erus has joined #openstack-keystone08:48
*** markvoelker has joined #openstack-keystone08:52
*** shyamb has joined #openstack-keystone08:58
openstackgerritMerged openstack/keystone master: Add tests for project users interacting with mappings  https://review.openstack.org/61961608:59
openstackgerritMerged openstack/keystone master: Remove mapping policies from policy.v3cloudsample.json  https://review.openstack.org/61961708:59
*** markvoelker has quit IRC09:25
*** shyamb has quit IRC09:41
*** shyamb has joined #openstack-keystone09:50
*** awalende has quit IRC09:52
*** awalende has joined #openstack-keystone09:52
*** awalende has quit IRC09:57
*** jaosorior has joined #openstack-keystone09:57
*** awalende has joined #openstack-keystone09:59
*** markvoelker has joined #openstack-keystone10:17
*** spsurya has quit IRC10:22
*** shyamb has quit IRC10:46
*** jaosorior has quit IRC10:55
*** erus has quit IRC10:56
*** erus has joined #openstack-keystone10:57
*** yan0s has joined #openstack-keystone11:02
openstackgerritVishakha Agarwal proposed openstack/keystone master: WIP: Additional work for testing assignment protection  https://review.openstack.org/63682511:04
*** jaosorior has joined #openstack-keystone11:15
*** shyamb has joined #openstack-keystone11:15
openstackgerritPavlo Shchelokovskyy proposed openstack/keystone master: Add hint for order of keys during distribution.  https://review.openstack.org/63839711:17
openstackgerritPavlo Shchelokovskyy proposed openstack/keystone master: Mention allow_expired_window in fernet FAQ  https://review.openstack.org/63839811:17
vishakhalbragstad: Added few more test cases in https://review.openstack.org/#/c/636825.11:25
vishakhalbragstad: Do I need to update anything in https://review.openstack.org/#/c/609210?11:26
*** erus has quit IRC11:27
*** erus has joined #openstack-keystone11:28
*** awalende has quit IRC11:28
*** awalende has joined #openstack-keystone11:30
*** raildo has joined #openstack-keystone11:33
*** FlorianFa has joined #openstack-keystone11:47
*** FlorianFa has quit IRC11:51
*** awalende has quit IRC11:52
*** erus has quit IRC11:52
openstackgerriterus proposed openstack/keystone master: Add new attribute to the federation protocol API  https://review.openstack.org/63730511:52
*** awalende has joined #openstack-keystone11:52
*** erus has joined #openstack-keystone11:52
*** FlorianFa has joined #openstack-keystone11:54
*** FlorianFa has quit IRC11:56
*** FlorianFa has joined #openstack-keystone11:56
*** awalende has quit IRC11:57
*** shyamb has quit IRC12:41
*** errr has joined #openstack-keystone12:47
*** awalende has joined #openstack-keystone12:50
errrhello, Im using queens and have federation setup using shibboleth. When I try to login my IDP is successfully giving me a valid session. But I dont seem to be getting redirected to horizon..12:50
errrI am instead stuck at a page that says "Please wait..." its like https://mysite.com:5000/v3/auth/OS-FEDERATION/websso/mapped?origin=https://mysite.com/auth/websso/12:51
errrdoes this mean I am missing the sso callback file in horizon? Im not sure where to look to fix this problem..12:52
cmurphyerrr: the "Please wait..." message comes from the callback file so you are not missing it, there should be some javascript embedded in it that POSTs the token to horizon which should trigger the login, so check the horizon logs to see if horizon didn't handle the request for some reason12:59
*** erus has quit IRC13:00
*** erus has joined #openstack-keystone13:01
errrcmurphy: I see the POST happen, but no errors or anything show up after that.. it just shows the POST and thats it13:02
cmurphyerrr: not sure what it is then, seems like an issue on horizon's side :( you could try turning up the debug logging in horizon if you haven't already13:04
errrcmurphy: I havent, what is the directive I use to enable debug?13:05
cmurphyerrr: in local_settings.py there is a LOGGING variable with a python dict in it, i usually set LOGGING -> handlers -> console -> level to DEBUG but there are a whole lot of knobs in there13:09
errrah, well it looks like I do already have that all set to DEBUG13:09
*** markvoelker has quit IRC13:17
*** markvoelker has joined #openstack-keystone13:18
*** markvoelker has quit IRC13:22
*** shyamb has joined #openstack-keystone13:35
*** jamesmcarthur has joined #openstack-keystone13:43
*** erus has quit IRC13:44
*** shyamb has quit IRC13:44
*** erus has joined #openstack-keystone13:45
*** erus has quit IRC13:56
*** erus has joined #openstack-keystone13:56
*** lbragstad has joined #openstack-keystone13:57
*** ChanServ sets mode: +o lbragstad13:57
*** jamesmcarthur has quit IRC13:58
*** jamesmcarthur has joined #openstack-keystone13:58
*** erus has quit IRC14:03
*** jamesmcarthur has quit IRC14:03
*** aning has quit IRC14:04
*** erus has joined #openstack-keystone14:04
*** aning has joined #openstack-keystone14:08
*** jaosorior has quit IRC14:08
*** erus has quit IRC14:10
*** erus has joined #openstack-keystone14:10
*** markvoelker has joined #openstack-keystone14:18
openstackgerritMerged openstack/keystone master: Deprecate cache_on_issue configuration option  https://review.openstack.org/63569014:24
*** jamesmcarthur has joined #openstack-keystone14:29
*** jaosorior has joined #openstack-keystone14:30
*** erus has quit IRC14:30
*** imacdonn has quit IRC14:31
*** erus has joined #openstack-keystone14:31
*** jamesmcarthur has quit IRC14:34
gagehugoo/14:46
erus\o14:46
lbragstado/14:48
*** markvoelker has quit IRC14:53
*** erus has quit IRC14:54
*** erus has joined #openstack-keystone14:55
*** mvkr has quit IRC15:00
*** erus has quit IRC15:04
*** erus has joined #openstack-keystone15:04
*** jaosorior has quit IRC15:08
*** jamesmcarthur has joined #openstack-keystone15:10
*** awalende has quit IRC15:12
*** awalende has joined #openstack-keystone15:13
vishakhao/15:16
*** jamesmcarthur has quit IRC15:17
*** awalende_ has joined #openstack-keystone15:17
*** awalende_ has quit IRC15:17
*** awalende has quit IRC15:17
*** jistr is now known as jistr|afk15:22
*** erus has quit IRC15:23
*** mvkr has joined #openstack-keystone15:24
*** erus has joined #openstack-keystone15:24
vishakhalbragstad: Added few more test cases in https://review.openstack.org/#/c/636825.15:29
vishakha  Do I need to update anything in https://review.openstack.org/#/c/609210?15:29
lbragstadvishakha if you wanted to consolidate those patches with git rebase, you could15:30
lbragstadso long as you feel comfortable with those changes15:31
*** jistr|afk is now known as jistr15:32
vishakhaok. Doin the same15:32
*** erus has quit IRC15:34
*** erus has joined #openstack-keystone15:35
zzzeekkmalloc: I'm being told that dogpile.cache 0.7.x was uncapped in oslo.cache and the whole world is breaking now : https://bugs.launchpad.net/oslo.cache/+bug/181703215:39
openstackLaunchpad bug 1817032 in oslo.cache "Unit test fails during cache region testing" [Undecided,New] - Assigned to Herve Beraud (herveberaud)15:39
zzzeekkmalloc: do you recall the dicsussion we wer having about use of the decorator module, and someone was abusing it in some way we decided should be fixed downstream ?15:39
*** erus has quit IRC15:40
*** dave-mccowan has joined #openstack-keystone15:41
*** erus has joined #openstack-keystone15:41
openstackgerritVishakha Agarwal proposed openstack/keystone master: Additional work for testing assignment protection  https://review.openstack.org/63682515:43
lbragstadvishakha from there - we should be able to keep stacking commits in that series15:45
lbragstadit looks like we have everything for system users15:45
lbragstads/everything/tests/15:45
*** dave-mccowan has quit IRC15:45
lbragstadso - we can try and take those tests and reuse some of them for domain users (admins, members, and readers)15:45
lbragstadand then fill in the gaps that make sense15:46
*** jaosorior has joined #openstack-keystone15:46
vishakhaYeah for system users all patches are up.  After rebasing I can update for domain users15:46
zzzeekkmalloc: I found the thread, that was about openstacksdk.15:48
*** jamesmcarthur has joined #openstack-keystone15:48
*** markvoelker has joined #openstack-keystone15:50
*** jamesmcarthur has quit IRC15:53
lbragstadvishakha cool - that sounds good15:54
lbragstadthe series starting at https://review.openstack.org/#/c/619373/5 and https://review.openstack.org/#/c/619277/4 close a few bugs (and already have a +2)15:56
lbragstadif anyone is looking for reviews15:57
*** jamesmcarthur has joined #openstack-keystone15:58
*** jamesmcarthur has quit IRC15:58
*** jamesmcarthur has joined #openstack-keystone15:58
knikollao.15:59
knikollao/15:59
kmalloczzzeek: cool .16:07
kmalloczzzeek: it was, as I recall, silly behavior someone was doing.16:08
kmallocAnd dogpile just started doing more correct things.16:08
kmallocI am a little pre-coffee ATM.16:09
kmallocSo brain fuzzed16:09
openstackgerritVishakha Agarwal proposed openstack/keystone master: Implement system reader for role_assignments  https://review.openstack.org/60921016:10
erushii knikolla and kmalloc o/16:10
knikollahi erus!16:10
erushow are you?16:10
knikollai'm good. took the day off today. i have too many vacation days accumulated which will go to waste if i didn't use them soon.16:11
knikollahow are you?16:11
erushahaha ohh vacation great16:12
erusi'm really hungry :D16:12
knikollamore like drink coffee and play super mario odyssey day. :p16:12
erusbut i'm fine, in my last weeks :( haha16:13
zzzeekkmalloc: yeah i found it, just shared w/ the oslo.cache person in case they have similar issues16:13
kmallocknikolla: good plan.16:13
kmalloczzzeek: ++16:13
*** jamesmcarthur has quit IRC16:13
openstackgerritVishakha Agarwal proposed openstack/keystone master: Additional work for testing assignment protection  https://review.openstack.org/63682516:13
kmallocOh gotta send you a message, sec.16:13
erusohh sounds really good, just play super mario odyssey once16:13
knikollamy video game backlog is almost as bad as my code review backlog :)16:14
erushahaha16:15
erusthe last game i played was life is strange16:17
erusi don't play since december :(16:17
knikollawhat platform do you play on?16:19
kmallocknikolla: I think the next game for me is mankind divided, its been on my.list for a couple years. Or Shadow of the Tomb raider16:19
knikollakmalloc: i think i got that for free on ps plus a while back. haven't booted it yet.16:21
erusright now in my notebook knikolla16:21
erusonly pc for now16:21
*** markvoelker has quit IRC16:23
lbragstadhttps://playwarcraft3.com/en-us/ is coming out this year *and* was built/hosted/will be hosted using OpenStack16:24
lbragstadso...16:25
* lbragstad thanks eandersson 16:27
*** jamesmcarthur has joined #openstack-keystone16:27
knikollalbragstad: whoaaaa... hopefully they don't screw it up16:32
knikollai have lost complete faith in activision/blizzard.16:32
knikollaand warcraft 3 is a childhood classic.16:32
eruswoow great lbragstad16:32
lbragstadeandersson works for blizzard ;)16:32
erushahaha16:32
lbragstadi was a huge fan of warcraft 2 and 316:33
knikollathe blizzard side is fine, activision not so much, haha.16:33
* gagehugo is waiting for classic wow16:33
lbragstaddiablo 3 was fun, too16:33
knikollai guess the only thing i'm really waiting is bayonetta 3.16:33
knikollai'm pretty much stocked up for this year.16:34
gagehugoknikolla: do you play smash ultimate?16:34
knikollagagehugo: don't really have anyone in my circle who plays that, so i mostly skipped on the smash train.16:35
knikollaevery social opportunity was mostly FIFA/PES, haha.16:35
knikollaif anyone wants to add me as a friend on PSN/Switch/Steam, do send me a message16:36
cmurphyoh man did I accidentally /join #nerd16:37
lbragstadwelcome16:37
knikollathere's a strong correlation16:38
cmurphylol warcraft2 was pretty good16:38
*** imacdonn has joined #openstack-keystone16:38
lbragstad"pretty good" she says ;)16:38
lbragstadcmurphy how was BF2?16:39
eruswhat is your steam user knikolla? haha xD16:40
cmurphylbragstad: not bad, i was slightly underwhelmed16:40
cmurphyi liked the campaign but it was too short16:40
* lbragstad nods16:40
*** rafaelweingartne has joined #openstack-keystone16:40
lbragstadthat's the feedback i heard from others, too16:40
knikollaerus: sent u a private message16:40
rafaelweingartneHello Guys, when using identity federation with keystone, can't I map my federated users to specific domains (that I already have), instead of mapping them to Default16:41
rafaelweingartneand then OpenStack creates a domain to represents the IdP?16:41
knikollarafaelweingartne: when you create the identity provider, you specify which domain to use16:41
lbragstadrafaelweingartne when you create an identity provider you can specify a domain in the request16:42
rafaelweingartnehmm16:42
lbragstadrafaelweingartne if a domain isn't supplied, keystone will automatically generate one for you16:42
rafaelweingartneI did not know that16:42
rafaelweingartneI thought that was done in the mapping16:42
rafaelweingartnewhat is the domain in the mapping used for then?16:42
lbragstadit depends on what you want your users to do when they access your service provider16:43
lbragstadthe domain for the identity provider is really just a name space for the users coming from that identity provider16:43
rafaelweingartneyes, that is our idea, to bind the users from an identity provider to a domain16:43
rafaelweingartnethat is why we have defined the domain in the mapping16:43
lbragstadbut you're not limited to keeping all role assignments for a user within the domain they are namespaced to16:44
gagehugoknikolla: I played a LOT of gamecube smash so I tend to keep picking it back up each release16:44
rafaelweingartnewhat do you mean by that?16:44
rafaelweingartneI am actually assigining the permissions/roles to a group16:45
rafaelweingartneand then I assign users to that group16:45
lbragstadrafaelweingartne for example, if you have a user in the Default domain, they can have direct or indirect role assignments on other domains in the deployment16:45
rafaelweingartneok16:47
*** dave-mccowan has joined #openstack-keystone16:47
rafaelweingartneyou mean, users from default domain (root) can have assignemtn (permissions) to other domain, is that it?16:47
lbragstadcorrect16:48
*** gyee has joined #openstack-keystone16:48
rafaelweingartneok, and the other way around is not possible16:48
lbragstadboth ways are possible16:48
rafaelweingartneah16:48
rafaelweingartnebut talking about the attribute mapping, if I define a domain that already exist there16:49
lbragstadi'm just saying we don't have anything in keystone that restricts assignments across domains depending on the user's domain (associated to their user reference)16:49
rafaelweingartnewhy is openstack always creating a domain for the IdP?16:49
knikollarafaelweingartne: the domain is created upon creating an idp16:49
knikollaeven before you create a mapping16:49
lbragstadcorrect ^16:49
lbragstadso - one thing you might do instead16:49
knikollayou can have multiple idps with one domain though16:49
lbragstadis to create an identity provider and specify the domain you want user to map into16:50
knikollaby using an existing one16:50
lbragstadthen - create a mapping using that same domain16:50
knikollathere's a `--domain <domain>` property when creating an idp.16:50
rafaelweingartneah16:50
rafaelweingartneok16:50
rafaelweingartnenow I get it16:50
rafaelweingartneI need to define a domain for the IdP16:50
lbragstadusers coming in through federation will be namespaced to the same domain that is used in the mapping16:50
rafaelweingartneothewise, Openstack aways creates one16:50
lbragstadcorrect - we leave that up to you16:51
rafaelweingartnegot it16:51
rafaelweingartneI have another question now16:51
lbragstadkeystone just needs to have a domain for the users coming in, so that we namespace them properly16:51
knikollayou shouldn't use the domain property for users in mappings. for groups and projects it's fine.16:51
rafaelweingartnehmm16:52
rafaelweingartneI was trying to use it, because that is what is shown in the documentation16:52
rafaelweingartneso, we are not supposed to use it?16:52
lbragstadrafaelweingartne what docs were you using?16:52
rafaelweingartnehttps://docs.openstack.org/keystone/rocky/advanced-topics/federation/federated_identity.html16:53
lbragstadgotcha - nearly that entire document has been revised and updated16:53
lbragstadhttps://docs.openstack.org/keystone/latest/admin/federation/federated_identity.html16:54
lbragstad^ that is the newer version16:54
rafaelweingartneah16:54
rafaelweingartnethat is better16:54
rafaelweingartneso, now I have other question, if I map the e-mail attribute from the IdP to the username in OpenStack, and if there is already a user with that username in the same domain16:55
knikollarafaelweingartne: when you set the user type to local. you can map to an actual existing user in the keystone db. that is when you use domain.16:55
rafaelweingartnegot you16:55
rafaelweingartneSo, it was not working here, because I did not register a domain when registering an IdP16:55
lbragstadit could be due to the fact the domains were mismatched? cmurphy or knikolla could correct me though16:56
*** erus has quit IRC16:56
*** erus has joined #openstack-keystone16:57
knikollarafaelweingartne: it type is set to local. the user will get that user. but every user not matching will get denied.16:58
knikollarafaelweingartne: if type is set to not local. a new user will be created with the same email / username.16:58
knikollai know, that is confusing.16:58
knikollathe uniqueness contraint on federated users is on the entity id coming from the idp.16:59
rafaelweingartneby type, you mean the "local" property of the mapping attribute, right?16:59
openstackgerriterus proposed openstack/keystone master: Add new attribute to the federation protocol API  https://review.openstack.org/63730516:59
knikollarafaelweingartne: "type": "local" in "local": "user": {}17:01
knikollaread the mapping compinations documentation cause it describes that.17:01
knikollacombinations*17:01
knikollahttps://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html#mappings-examples17:01
rafaelweingartnesure got it17:02
rafaelweingartneIn the other documentation I do not recall to have seen this "type: local"17:02
rafaelweingartnenow I see how it works, but it creates a problem17:02
rafaelweingartneso, if I have already a few users in the domain17:02
rafaelweingartnethe new users in the IdP would not be created17:02
rafaelweingartnecan I have more than one attribute mapping for the same IdP?17:03
knikollain the general mapping setup that i recommend (not using type: local) they would,.17:03
knikollaa new user will be created for every unique (entity id, protocol, idp).17:04
rafaelweingartnewhat do you consider the entity id? the "sub" attribute in OIDC?17:06
*** erus has quit IRC17:06
*** erus has joined #openstack-keystone17:06
*** pcaruana has quit IRC17:07
knikollarafaelweingartne: yes.17:08
knikollai don't exactly remember the specifics at this moment.17:09
knikollahaven't played around in some time.17:09
rafaelweingartneok, no problem17:09
rafaelweingartnebut I get the picture17:10
knikollait might be that it uses whatever you have mapped to the username attribute, as i don't quite recall a configuration setting for specifiying which attribute that is.17:11
rafaelweingartneok, thanks17:11
rafaelweingartneit helped a lot17:12
knikollarafaelweingartne: https://github.com/openstack/keystone/blob/ace45841943ed6b698b8a5aea35a80c119c3cae3/keystone/identity/backends/sql_model.py#L34217:17
knikollaas per sql model above, a federated user is unique on (unique_id, idp, protocol)17:18
knikollaso you can have multiple users with same email from different idps in same domain17:18
knikollaalright, enough info. i don't want to confuse you further.17:19
*** erus has quit IRC17:19
rafaelweingartneaha, no worries17:19
rafaelweingartnenow these tables are starting to make more sense17:19
*** markvoelker has joined #openstack-keystone17:20
knikollawe like to keep the barrier to entry high. job security and stuff, haha.17:21
*** yan0s has quit IRC17:23
*** jamesmcarthur_ has joined #openstack-keystone17:24
*** jamesmcarthur has quit IRC17:27
rafaelweingartneahaha17:27
rafaelweingartneactually, I find it easier here, as you guys use the same terms as I am used to such as metadata, IdP, SP, and so on17:28
rafaelweingartneso, for someone with an academic background, it gets easier17:28
rafaelweingartnejust the documentaation pages that I was reading, which were not very accurate, but with these new docs, I guess I will not have problems17:29
*** erus has joined #openstack-keystone17:29
rafaelweingartnethanks for the help ;)17:29
knikollano problem :)17:29
knikollaping me if u have any more questions, i'm generally around.17:29
rafaelweingartnesure will17:31
rafaelweingartneI just need to learn how to ping people on IRC :P17:31
rafaelweingartneI am used to using @, but it does not work here17:31
*** zzzeek has quit IRC17:44
*** zzzeek has joined #openstack-keystone17:49
*** markvoelker has quit IRC17:53
*** rafaelweingartne has quit IRC18:05
*** mvkr has quit IRC18:12
gagehugolbragstad: one comment on https://review.openstack.org/#/c/614549/18:37
lbragstadgagehugo sure - debug logging ok?18:40
lbragstadbut - remember that is going to get noisy18:40
lbragstadif you have many public keys on every token validation18:41
gagehugohmm18:41
*** erus has quit IRC18:44
gagehugoI was just thinking if I was trying to debug why auth was failing, it would be nice to see if keystone is unhappy with the pub keys18:45
gagehugobut yeah, I can see that getting quite chatty if there's old keys18:45
lbragstador just many keys18:45
lbragstadif you have 40 APIs servers for example18:45
lbragstadalso - since key rotation for JWT is quite different from fernet18:50
lbragstadwe don't bother attempting to prune keys18:50
gagehugoyeah18:50
*** markvoelker has joined #openstack-keystone18:50
lbragstadso - a server could have 40 valid keys and 100 invalid keys that are no longer used18:50
gagehugomaybe decodeerror could be a separate except and then log that, otherwise yeah there would be 100 log messages18:51
gagehugofor each invalid/expired18:51
*** vishakha has quit IRC18:52
gagehugolets leave it for now and see about it with a follow up change18:52
lbragstadsounds good18:52
gagehugoit's fine for now tbh, I was just curious18:53
lbragstadsomething to think about18:53
gagehugolbragstad: done, lgtm18:58
lbragstadthanks gagehugo18:58
*** mvkr has joined #openstack-keystone18:59
kmalloclbragstad: you know, asyncio is super rad.19:13
kmallocif it fits a usecase*19:13
* kmalloc has been looking at it.19:13
*** markvoelker has quit IRC19:23
*** s10 has joined #openstack-keystone19:36
s10Hello. I have a question about LDAP integration. Is there any way to use LDAP identity driver _and_ sql backend for users in specific domain?19:48
*** jamesmcarthur_ has quit IRC19:56
*** jamesmcarthur has joined #openstack-keystone19:57
*** jamesmcarthur has quit IRC20:01
*** whoami-rajat has quit IRC20:02
*** jamesmcarthur has joined #openstack-keystone20:18
*** markvoelker has joined #openstack-keystone20:21
*** awalende has joined #openstack-keystone20:31
*** awalende has quit IRC20:36
*** jdennis has quit IRC20:38
*** jamesmcarthur has quit IRC20:40
*** jamesmcarthur has joined #openstack-keystone20:40
*** jdennis has joined #openstack-keystone20:41
*** jamesmcarthur has quit IRC20:45
gagehugocmurphy: do we want to hold off on those ksa changes?20:48
*** jamesmcarthur has joined #openstack-keystone20:53
*** markvoelker has quit IRC20:55
cmurphygagehugo: I think https://review.openstack.org/636074 is fine to go in now, it's the one on top of that that I'm not sure about20:56
cmurphyworking on an email now20:56
gagehugookedoke20:57
ayoungI think we lied in our policy 101 talk.  What does  "" mean in a policy file?21:04
ayoungI thought it was "always true" same as @  but now I can't see where that parses21:05
ayoungits default, right?21:06
ayoung    # Empty rule defaults to True21:08
ayoung    if not rule:21:08
ayoung        return _checks.TrueCheck()21:08
ayoungI think Ozz got that confused21:08
gagehugoThe rule is an empty string meaning “always”.21:10
gagehugohttps://docs.openstack.org/oslo.policy/queens/admin/policy-json-file.html#examples21:10
*** rcernin has joined #openstack-keystone21:11
ayounggagehugo, I know that is what we document, but I can't figure out how that happens21:12
gagehugoayoung: ah ok21:12
ayoungit must be a compination of skipping the token and an empty rule defaults to true21:13
lbragstadwe should use gerrit for team presentation talk submissions ;)21:13
cmurphylbragstad ayoung kmalloc gagehugo knikolla http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003031.html21:13
ayounggot a customer seeins different behavior between CLI and Horizon, and I'm not sure what the rule is supposed to evaluate to21:13
ayoungcmurphy, you rock21:15
lbragstadholy email, batman21:15
kmalloccmurphy: whoa.21:15
kmalloccmurphy: that is going to take me a bit to parse21:16
cmurphyyeah sorry21:16
ayoungcmurphy, keying on service type means we can't have different policy per endpoint21:16
ayoungcmurphy, I think you are on the right approach.  Might suggest * be replaced with something that is not a greedy token as it is supposed to be stopped by a /21:18
ayoungso  /{1}/bla/{2}  vs /*/bla/*/  But I am ok if you tink you can make that work21:18
ayoungI do think, tho. that we are better off keeping with the keys that the services use for the Paths21:18
cmurphyayoung: you want different policy per endpoint? i never thought of that21:19
ayoungso even if we don't match values from the token, please allow the old syntax.21:19
ayoungcmurphy, it was one of the requests, yes21:19
cmurphyayoung: * here is not greedy, it doesn't include /21:19
cmurphy** includes /21:19
cmurphyayoung: in the spec?21:19
ayoungok...so no problem with that21:19
ayoungI origianlly wanted to be able to seed the rules from the APIs policy21:19
ayoungwe'd have to convert from what nova produces to the * format21:20
ayoungis there a way we can keep the format, and ignore the keys?21:20
cmurphyayoung: if it wasn't in the spec then I probably didn't remember and/or didn't read your mind21:20
ayoungthey will also be better documentation of intent, even if we don't use it21:20
ayoungit was part of the discussion way back when, but it might not have made its way into the app creds spec.  It was in the rbac-enforce-in -middleware spec21:21
cmurphywe could probably keep the format and ignore the keys, it's just a different regex21:21
ayoungthat is not a deal killer:  we could potentially have service nickanmes21:21
cmurphy* and ** were nice because they are shell standards21:21
ayoungso compute-gold is a nickname for compute, but only supports a higher class of service21:22
ayoungso, of all your changes, the only one I request you roll back is the format of the paths.  THe rest is golden21:23
cmurphyayoung: okay so the request is to switch eg /v2/servers/* to /v2/servers/{server_id} so it looks more like what's in the api-ref and existing policies correct?21:24
ayoungyes21:24
cmurphyokay wfm21:24
ayoungI like your name choices21:24
cmurphywe could support different policies for different endpoints by keying on endpoint url instead of service type21:25
ayoungright now, an endpoiung does not know its service or endpoint ids anyway.  We had a deployers rebellion when we suggested editing the config files post setup to put the uuids into them generated from keystone.  My last thought was that we put the value into , say nova.conf that tells it "you are a compute server" and let that field be overridden21:26
ayoungendpoints don't even know their URLs, so putting in a value a-priori is essential;21:27
cmurphyyes, this hinges on having something set in [keystone_authtoken] or set in code in nova that tells the service who it is21:28
cmurphys/nova/the project21:28
ayoungright21:28
ayoungwe can default those to the good names, but there is no reason they have to stick with them21:29
cmurphyright21:29
ayoungwe couldalso do a naming scheme like policy21:29
ayoungnova by default, or nova:gold21:29
ayoungwehre :gold means grab the gold specific rules.  That allos us to stick with the majority of the default policy, but layer on an additional check, too21:30
ayoungso, I don't think that has to be this round.21:30
cmurphyokay21:30
ayoungjust keep it in mind as you go, and we can revisit once we have a working code base.  Think how a customer would be able to divide up a cloud so that some region was for a special class of customers.  And that might be better done via K2K21:31
ayoungon allow_chained....21:31
kmallochm.21:33
ayoungI might be OK with killing that21:34
ayoungIf we don't make allowed_chained=True by default it might just break everywhere21:34
ayoungor people will just add it to every call anyway21:34
ayoungbut21:34
ayoungwhat if it is OK to createan ephemeral server, but not to create stoarge for it?21:34
cmurphyugh yeah we need to keep it for that21:36
cmurphyi think we'll need to change it to be part of the capability rule and not an attribute of the app cred itself, since different apis will have different needs for chaining service calls21:38
*** erus has joined #openstack-keystone21:42
lbragstadallow_chained is really specific to if nova can reuse an cap cred token for something in another service, for example, right?21:42
cmurphythat's one case but it could also be for if heat or magnum want to make requests to other services21:43
cmurphyor if you want glance to store images in swift21:44
lbragstadok21:44
lbragstadbut it's specific to any service _behind_ the service the user made the request against?21:44
cmurphyright21:44
* lbragstad nods21:44
* cmurphy will try to think of better names for it21:46
lbragstadif it wasn't a boolean - it's almost easier to think of it as a depth21:47
lbragstader - service_depth21:47
lbragstadbut - that feels really complicated for users to have to deal with21:49
lbragstadidk if something like that would even be discoverable21:49
cmurphyyeah, i don't think the depth of the chaining is the issue, no matter how many services deep you are it's still some other service making a request on behalf of you21:50
lbragstadtricky21:51
*** erus has quit IRC21:51
*** erus has joined #openstack-keystone21:51
*** markvoelker has joined #openstack-keystone21:53
*** jamesmcarthur has quit IRC21:57
*** erus has quit IRC21:57
*** erus has joined #openstack-keystone21:58
*** jamesmcarthur has joined #openstack-keystone22:05
*** jamesmcarthur has quit IRC22:07
*** markvoelker has quit IRC22:25
*** dave-mccowan has quit IRC22:40
*** dave-mccowan has joined #openstack-keystone22:40
*** erus has quit IRC22:40
*** erus has joined #openstack-keystone22:41
*** dave-mccowan has quit IRC22:46
*** tkajinam has joined #openstack-keystone23:01
*** erus has quit IRC23:11
*** erus has joined #openstack-keystone23:11
*** markvoelker has joined #openstack-keystone23:22
*** gyee has quit IRC23:38
*** raildo has quit IRC23:39
*** gyee has joined #openstack-keystone23:52
*** markvoelker has quit IRC23:55

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!