17:03:16 <lbragstad> #startmeeting keystone-office-hours 17:03:18 <openstack> Meeting started Tue Sep 25 17:03:16 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:21 <openstack> The meeting name has been set to 'keystone_office_hours' 17:03:41 <lbragstad> in reality though... i'm not sure meetbot is the best idea for office hours... 17:03:46 <ayoung> cmurphy, we can map to a local account, I remember. What is the "force create a user" option? 17:04:31 <cmurphy> ayoung: we can map to a local or ephemeral user 17:04:41 <cmurphy> ayoung: explain what is "force create a user" ? 17:04:58 <ayoung> cmurphy, I think that is what happened to Anakin in episode 1 17:05:05 <cmurphy> lol 17:05:08 * ayoung ducks 17:05:38 <ayoung> OK, so say I am trying to keep 19 different openstack deployments in sync 17:06:14 <ayoung> I am using a handful of LDAP sources 17:06:25 <ayoung> the user IDs from each one will be different 17:07:03 <ayoung> If I can say "the LDAP domain_id is AABBCC123 then they will all have the same userid as well 17:07:52 <ayoung> that is the absolute simplest case I can think of. 17:08:12 <ayoung> I'd like to be able to match that logic in Federation, so I can get away from Simple Bind 17:08:22 <ayoung> but not treat users as Ephemeral 17:08:39 <ayoung> and not have to modify the mapping files for any user-to-group assignments 17:09:48 <ayoung> I'd like to be able to say "The BOS Keystone can control the RedSox domain and the SFO Keystone can control the Giants domain" 17:10:13 <ayoung> and so forth. Galera does not really let you do that. as all writes have to be synced everywhere 17:10:20 <ayoung> before a commit is OKed 17:10:43 <cmurphy> i'm not pushing galera i just know zzzeek we working on it 17:10:46 <cmurphy> was* 17:11:01 <ayoung> Galera is necessary, and will support a good number of use cases 17:11:05 <ayoung> but not all 17:11:31 <cmurphy> is this just a question of usability? mapping rules are complicated and annoying but as far as i can tell they accomplish what you're trying to do 17:12:05 <ayoung> If you break the mapping, you break Keystone 17:12:14 <ayoung> modifying the mapping rules for an Idp is going to be a no-no 17:12:49 <ayoung> it would be like recompiling your kernel just to launch a new executable 17:14:22 <ayoung> You don't have object level granularity, which denies RBAC access to manage it 17:18:05 <cmurphy> I don't think it's fair to compare it to recompiling your kernel, it's more comparable to say modifying the mapping rules is like modifying your policy files, it's a pita and you could get it wrong but it's doable and sometimes necessary 17:19:36 <kmalloc> hrybacki: appt is tomorrow, I expect to be free by 10am Pacific ( 1pm est) 17:20:02 <kmalloc> hrybacki: that again might change later today (appt might be cancelled), but it is unlikely. 17:20:44 <kmalloc> lbragstad: meetbot is useless for office hours, we already log the channel 17:21:01 <hrybacki> kmalloc: okay, I'll move the meeting to that time (assuming I don't see others w/ conflicts) 17:21:06 <lbragstad> yeah.. i agree 17:21:19 <lbragstad> for the most part i think the pattern is established 17:21:40 <lbragstad> i'm not sure how often people reference the meetbot logs though 17:28:19 * cmurphy runs away for a few minutes 17:41:24 <lbragstad> FYI - http://lists.openstack.org/pipermail/openstack-dev/2018-September/135016.html 17:43:36 <lbragstad> does anyone else have suggestions for https://etherpad.openstack.org/p/BER-keystone-forum-sessions ? 17:51:02 <kmalloc> hrybacki: need to push back the flask thing until later today 17:51:19 <kmalloc> Like... 1.5 hrs 17:51:33 <kmalloc> If that is ok, just finished appointment and need food. 18:00:37 <kmalloc> hrybacki: sorry. 18:01:25 <hrybacki> kmalloc: no worries 18:39:25 <ayoung> I wish we could hide deprecation warnings in the unit tests 18:41:42 <openstackgerrit> Merged openstack/keystoneauth master: Reformat Adapter docstring https://review.openstack.org/605042 18:51:12 <ayoung> lbragstad, any reason to maintain a strict 255 limit for Fernet tokens? 18:53:37 <jdennis> knikolla, cmurphy: I found the problem with your SAML ECP message (can't find signature) and send knikolla an email with the explanation. 18:55:12 <cmurphy> jdennis: \o/ 18:55:54 <ayoung> jdennis, Did you ever tell me if/how it is possible to do SAML with HAProxy? 18:56:53 <openstackgerrit> ayoung proposed openstack/keystone master: Replace UUID with sha256 generator for Federated users https://review.openstack.org/605169 18:59:50 <openstackgerrit> Colleen Murphy proposed openstack/keystone master: Convert legacy functional jobs to Zuul-v3-native https://review.openstack.org/602452 19:01:02 <ayoung> kmalloc, hrybacki ^^ is using the LDAP approach to generated IDs for Federated Identity. The LDAP code is wicked convoluted, due to the whole "Mapping Backend" legacy stuff...This one hard codes the ID generator (which is another provider API) but really it should be injected 19:01:10 <jdennis> ayoung: it's in the federation doc I wrote: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/federate_with_identity_service/ 19:01:32 <cmurphy> jdennis: knikolla can you give me a tldr or forward me the details (colleen@gazlene.net) ? i've been meaning to come back to that for a while 19:01:41 <ayoung> jdennis, thanks. I was actually looking at that earlier today, and was wondering if that was the issue you had raised. Cool 19:02:08 <jdennis> cmurphy: I just forwarded the email I sent to knikolla to you 19:02:11 <cmurphy> jdennis: thanks 19:02:47 <jdennis> ayoung: not sure what issue you're referring to ... 19:03:04 <ayoung> jdennis, this, specifically https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/federate_with_identity_service/introduction#haproxy_overview 19:03:41 <ayoung> jdennis, I know that you were working on a fix of mod_auth_mellon to address it, and was not sure if that was something in the future. 19:04:22 <ayoung> I think you said that the mellon fix was an improvement over just assuming that you were hitting the same HA proxy instance. I need to present on this in a couple weeks, and had hoped to get that clarified before I lie to people on stage 19:04:23 <jdennis> ayoung: oh, you mean supporting shared session caches? 19:04:23 <kmalloc> ayoung: the backend is complex/indirect, the behavior is all i'd like to see. 19:04:45 <kmalloc> ayoung: take a known value and a supplied (from assertion) value and generate from that 19:05:03 <kmalloc> i don't care if we use the current code or something new/retro fit to make the current system suck less. 19:05:10 <ayoung> kmalloc, that is basically what I did in that commit: 19:05:14 <kmalloc> ++ 19:05:26 <ayoung> just I don't have a clean way to swap sha256 for shawhatevercomesnext 19:05:34 <jdennis> ayoung: if so, that code is 95% done, I'm in the process of testing it, then it will be sent upstream for review, so don't count on it soon (whatever soon means) 19:05:54 <kmalloc> ayoung: look at how the pbkdf (bcrypt, scrypt) works, encode it like that 19:06:06 <ayoung> jdennis, thank you. That confirms what I was suspecting 19:06:16 <ayoung> kmalloc, look at the review. it is tiny 19:06:25 <ayoung> https://review.openstack.org/605169 19:06:35 <kmalloc> right. follow up -> allow for shaxxxx -> newfangledhashingthing 19:07:22 <kmalloc> hmm 19:07:33 <kmalloc> ayoung: i worry, will that break anything for "current" federated users? 19:07:42 <ayoung> kmalloc, nope 19:07:47 <kmalloc> cool. 19:07:52 <ayoung> kmalloc, the concern I have is that it will break fernet 19:07:58 <kmalloc> hmm. 19:07:59 <ayoung> as, I think, it makes IDs slightly longer 19:08:09 <kmalloc> fernet doesn't care about strict id length 19:08:14 <kmalloc> it cares about total token length 19:08:16 <ayoung> but...that means fernet would fall down on LDAP ids, too 19:08:24 <kmalloc> iirc. 19:08:30 <kmalloc> i'll need to dig to be sure. 19:08:36 <ayoung> I saw a few warnings that lenght was 289, longer than max of 255 19:08:44 <kmalloc> yeah, then it might be a concern 19:09:19 <ayoung> is that for revocations? 19:09:40 <ayoung> if so, it is going to be a problem for LDAP as well, as those IDs are already sha256 19:12:28 <errr> jdennis: on osp do you know if yall have plans to make it so you can set the needed bits in the haproxy config from one of the yaml puppet over ride files for the deploy-osp.sh file? 19:12:55 <errr> jdennis: also the apache overrides.. 19:13:38 <errr> jdennis: lots of manual steps to get federation working on that platform because of that :( 19:15:22 <jdennis> errr: yes that is a well know issue. We do have plans to integrate it into tripleo sometime soon but the exact schedule has not been set yet 19:15:29 <ayoung> kmalloc, what is interesting is that I saw that message before I changed the lengths in that test, but once I did, the lenght warning went away, too. 19:15:47 <errr> jdennis: ok, well its good to know its at least on the radar 19:16:19 <jdennis> errr: not to worry, customers are faced with the issue and customers get attention :-) 19:16:27 <errr> ;) 19:16:28 <ayoung> 'Fernet token created with length of 290 characters, which exceeds 255 characters' 19:16:38 <ayoung> errr, from people like me 19:17:31 <errr> ayoung: me too :) 19:46:13 <hrybacki> kmalloc: I'm gonna have to depart in about ~45 mins. Think you'll have a chance to gander at my projects review on gerrit today? I've finally got it to where I can start to fix the failing tests but could use a sanity check before diving too deep 19:46:31 <kmalloc> ok almost done 19:46:37 <hrybacki> for simplicity: https://review.openstack.org/#/c/603451/ 19:46:37 <kmalloc> sec. winding down a call 19:46:47 <hrybacki> kmalloc: ack -- me fetches a quick coffee 19:48:33 <kmalloc> ok done 19:48:40 <kmalloc> i'll go get coffee too 19:48:43 <kmalloc> then we can chat 19:48:53 <kmalloc> hrybacki: sorry for the delay, has been a long day 19:51:02 <hrybacki> kmalloc: no worries -- I live a life of sliding timelines :) 19:58:38 <kmalloc> back 19:58:47 <kmalloc> bluejeans? 19:58:51 <kmalloc> or irc? 20:00:30 <hrybacki> kmalloc: bluejeans is preferred (I'm visual) 20:00:38 <hrybacki> https://bluejeans.com/u/hrybacki/ 20:28:04 <mcape> Hello all! 20:28:09 <mcape> I've run into trouble after queens->rocky keystone upgrade. 20:28:13 <mcape> My s3 authorization is broken, clients receive message '<Code>SignatureDoesNotMatch</Code>' 20:28:38 <mcape> In keystone logs, i see many 404 like "POST /v2.0/s3tokens HTTP/1.1. " 20:28:51 <mcape> I do not understand why swift proxy goes to the wrong address, any clues? Any help will be greatly appreciated. 20:30:23 <lbragstad> mcape i believe the entire /v2.0/ path was removed in rocky, some of it was removed in queens but the s3 stuff was pulled afterwords 20:30:44 <mcape> i just realized that probably this is wrong channel to ask support questions 20:31:05 <mcape> thanks for your answer, and have a great day! 20:31:17 <lbragstad> mcape yep! 20:35:28 <cmurphy> mcape: no this is the right channel to ask questions about keystone 20:35:38 <cmurphy> we don't bite 20:47:23 <kmalloc> mcape: please feel free to ask any questions about keystone, keystonemiddleware, keystoneauth, [and a myriad of other things we maintain] here... if it's thr wrong channel we're good about helping you find the right one 20:48:22 <kmalloc> cmurphy: i wont tell Nori (teh shiba) this channel is teeth free. She'd be a sad pupper (but she'll share her cow sans head stuffie with you) 20:59:59 <lbragstad> ok - i have two proposals for the forum submitted 21:00:05 <lbragstad> one for generic operators and user feedback 21:00:15 <lbragstad> and another for a session dedicated to keystone as an identity provider proxy 21:01:48 <mcape> kmalloc: thank you for your willingness to help! i'm still stuck trying to fix my upgrade 21:02:16 <mcape> with help of @timburke i've managed to change the proxy' request to keystone to correct one 21:02:43 <lbragstad> mcape so you're using v3 now instead of v2.0? 21:03:28 <mcape> yes i've added "auth_version = 3" to the [filter:s3token] section of proxy-server.conf 21:03:37 <cmurphy> kmalloc: :'D 21:04:20 <mcape> but now i receive error 500 21:04:45 <mcape> <?xml version="1.0" encoding="UTF-8"?>#015#012<Error>#015#012 <Code>InvalidURI</Code>#015#012 <Message>Could not parse the specified URI</Message>#015#012</Error>#015#012: #012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/swift3/middleware.py", line 80, in __call__#012 resp = self.handle_request(req)#012 File "/usr/lib/python2.7/site-packages/swift3/middleware.py", line 107, in handle_ 21:05:28 <mcape> it is not complete, sorry 21:05:51 <lbragstad> you might be able to throw it in paste.openstack.org 21:06:30 <mcape> http://paste.openstack.org/show/730906/ 21:08:34 <timburke> looks like a swift3 problem more than a keystone one -- we might want to move this to #openstack-swift (and get some proxy-server logs) 21:09:00 <timburke> but while we're here... do we see the requests making it all the way to keystone? what's the response code if/when it gets there? 21:11:17 <mcape> no, keystone is not receiving requests 21:14:15 <timburke> mcape: mind hopping over to swift's channel? i'll write up a bug for the first and most-obvious problem, then we'll get to figuring out the next step :-) 21:15:19 <mcape> okay, thanks! 21:15:32 <openstackgerrit> ayoung proposed openstack/keystone master: Allow an explicit_domain_id parameter when creating a domain https://review.openstack.org/605235 21:16:34 <ayoung> hrybacki, kmalloc, there is the other one. I can file bugs or specs or whatever we want to do with them, or just release note it 21:18:31 <kmalloc> hm. 21:18:48 <kmalloc> release note should be fine, but a bug for tracking is nice. 21:20:30 <aning> cmurphy: I setup another devstack, this time it's stable/rocky. But when I type in user name and password (myself/myself), and click on Login, I got an error: 21:20:37 <aning> cmurphy: Error Message: No peer endpoint available to which to send SAML response 21:20:48 <aning> cmurphy: have you ever seen this? 21:25:42 <cmurphy> aning: check the testshib logs, it seems like there's a mismatching url between the metadata you gave to testshib and the endpoint the request is trying to return to 21:27:13 <aning> cmurphy: k 21:28:33 <aning> cmurphy: so that could mean I misconfig my entityID in metadata ... 21:30:38 <aning> cmurphy: on my SP side, which would be the "peer endpoint" that the Idp sends the SAML2 response? 21:31:35 <cmurphy> aning: probably not the entityID, that's just a unique string and not a real URL, but it could be the keystone endpoint in horizon's local_settings.py 21:32:02 <aning> cmurphy: that endpoint is serviced by the browser, or by shibboleth mod? 21:32:21 <aning> cmurphy: or Horizon? 21:36:01 <cmurphy> aning: it's horizon that generates the special auth url where the saml response gets sent, and that endpoint is the one you set up in the keystone vhost 22:47:13 <jdennis> aning: entityID's are URN's not URI's, they are just a name, the endpoints are defined in the metadata with the triplet <service, binding, url> 23:30:03 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Add build_target arguement to enforcer https://review.openstack.org/601881 23:32:20 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Add build_target arguement to enforcer https://review.openstack.org/601881 23:46:22 <stewie925> hi keystonians 00:22:05 <stewie925> hey guys i have a question/ issue about keystone roles and tenants 00:39:54 <lbragstad> stewie925 what's up? 00:42:18 <stewie925> hi lbragstad 00:42:31 <stewie925> let me post it in pastern and share the link - very strange 00:44:53 <stewie925> lbragstad: here it is : paste.openstack.org/show/730910 00:46:12 <lbragstad> and this is just a basic devstack installation? 00:46:25 <stewie925> um yeah 00:46:59 <lbragstad> what's the outcome you're expecting? 00:47:24 <stewie925> Im expecting that the policy would see the role:admin under tenant admin 00:48:37 <stewie925> lines 3 and 4 of the log shows Checking against policy role:admin - role check result: True 00:49:20 <stewie925> but 5 and 6 says Checking tenant:admin - Tenant check result: False. 00:49:26 <lbragstad> ok 00:49:39 <lbragstad> so you have a custom policy that you're testing this against? 00:49:47 <stewie925> yes I do 00:50:06 <stewie925> let me get it 00:53:16 <stewie925> lbragstad: here it is : paste.openstack.org/show/730912 00:54:56 <lbragstad> and this with master/ 00:55:18 <stewie925> master? 00:55:25 <lbragstad> what version of keystone are you using? 00:55:32 <stewie925> version 3 00:55:42 <lbragstad> ok - cool 00:55:44 <lbragstad> what release? 00:56:08 <stewie925> here is my openstack role assignment list results - paste.openstack.org/show/730913 00:56:25 <stewie925> sorry how do i check the release 00:57:24 <stewie925> I ran pip freeze and grepped keystone - it shows: keystoneauth1==2.18.0 00:57:45 <lbragstad> no worries 00:57:56 <lbragstad> you might want to try referencing project instead of tenant 00:58:43 <stewie925> its strange cause my other teammate ran and he passed the policy check 00:58:56 <stewie925> we compared notes and we did the same :( 00:59:18 <lbragstad> strange 00:59:31 <lbragstad> we renamed tenant -> project along time ago 00:59:42 <stewie925> ahhh 00:59:47 <lbragstad> but we do have some documentation in oslo.policy that goes through how some of this works nge cause m 00:59:57 <lbragstad> bag... bad paste 01:00:03 <lbragstad> https://docs.openstack.org/oslo.policy/latest/admin/policy-yaml-file.html 01:04:21 <stewie925> lbragstad: thank you - let me check 01:36:47 <lbragstad> #endmeeting