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