*** phalmos has quit IRC | 00:00 | |
samueldmq | gagehugo: lbragstad: I will be going through project tags in a bit | 00:00 |
---|---|---|
*** thorst has quit IRC | 00:00 | |
samueldmq | needed to go afk for a bit earlier today | 00:00 |
*** ducttape_ has joined #openstack-keystone | 00:05 | |
*** phalmos has joined #openstack-keystone | 00:05 | |
*** ducttape_ has quit IRC | 00:10 | |
*** phalmos_ has joined #openstack-keystone | 00:21 | |
*** phalmos has quit IRC | 00:23 | |
*** aselius has joined #openstack-keystone | 00:32 | |
*** masber has joined #openstack-keystone | 00:35 | |
*** boris-42_____ has joined #openstack-keystone | 00:54 | |
*** boris-42_____ is now known as boris_42 | 00:54 | |
*** masber has quit IRC | 00:54 | |
*** catintheroof has quit IRC | 00:57 | |
*** masber has joined #openstack-keystone | 01:08 | |
*** harlowja has quit IRC | 01:10 | |
*** catintheroof has joined #openstack-keystone | 01:18 | |
*** catintheroof has quit IRC | 01:25 | |
*** edmondsw has joined #openstack-keystone | 01:25 | |
samueldmq | gagehugo: you around? | 01:29 |
*** edmondsw has quit IRC | 01:30 | |
*** ducttape_ has joined #openstack-keystone | 01:45 | |
*** ducttape_ has quit IRC | 01:50 | |
*** masber has quit IRC | 01:50 | |
*** masber has joined #openstack-keystone | 01:52 | |
*** thorst has joined #openstack-keystone | 01:57 | |
*** thorst has quit IRC | 02:02 | |
*** jmlowe has joined #openstack-keystone | 02:04 | |
*** ducttape_ has joined #openstack-keystone | 02:21 | |
*** ducttape_ has quit IRC | 02:25 | |
*** lbragstad has joined #openstack-keystone | 02:27 | |
*** ChanServ sets mode: +o lbragstad | 02:27 | |
*** lbragstad has quit IRC | 02:29 | |
*** zhurong has joined #openstack-keystone | 02:30 | |
*** tobberydberg has joined #openstack-keystone | 02:37 | |
*** tobberydberg has quit IRC | 02:41 | |
*** aselius has quit IRC | 02:41 | |
*** markvoelker has quit IRC | 02:50 | |
*** prashkre has joined #openstack-keystone | 03:04 | |
*** masber has quit IRC | 03:13 | |
*** edmondsw has joined #openstack-keystone | 03:13 | |
*** edmondsw has quit IRC | 03:18 | |
*** thorst has joined #openstack-keystone | 03:23 | |
*** zhurong has quit IRC | 03:31 | |
*** thorst has quit IRC | 03:37 | |
*** boris_42 has quit IRC | 03:43 | |
*** masber has joined #openstack-keystone | 03:48 | |
*** nicolasbock has joined #openstack-keystone | 04:08 | |
*** links has joined #openstack-keystone | 04:20 | |
*** harlowja has joined #openstack-keystone | 04:32 | |
*** aojea has joined #openstack-keystone | 04:41 | |
*** aojea has quit IRC | 04:46 | |
*** markvoelker has joined #openstack-keystone | 04:51 | |
*** prashkre has quit IRC | 04:55 | |
*** edmondsw has joined #openstack-keystone | 05:02 | |
*** aojea has joined #openstack-keystone | 05:05 | |
*** edmondsw has quit IRC | 05:06 | |
*** gyee has quit IRC | 05:13 | |
*** markvoelker has quit IRC | 05:25 | |
*** harlowja has quit IRC | 05:28 | |
*** zhurong has joined #openstack-keystone | 05:30 | |
*** aojea has quit IRC | 05:37 | |
*** aojea has joined #openstack-keystone | 05:40 | |
*** harlowja has joined #openstack-keystone | 05:41 | |
*** ducttape_ has joined #openstack-keystone | 05:52 | |
*** ducttape_ has quit IRC | 05:56 | |
*** thorst has joined #openstack-keystone | 06:00 | |
*** oomichi has quit IRC | 06:05 | |
*** oomichi has joined #openstack-keystone | 06:06 | |
*** aojea has quit IRC | 06:06 | |
*** thorst has quit IRC | 06:06 | |
*** oomichi has quit IRC | 06:10 | |
*** oomichi has joined #openstack-keystone | 06:11 | |
*** rcernin has joined #openstack-keystone | 06:15 | |
*** markvoelker has joined #openstack-keystone | 06:22 | |
*** prashkre has joined #openstack-keystone | 06:31 | |
openstackgerrit | Colleen Murphy proposed openstack/keystonemiddleware master: Remove notice about system time https://review.openstack.org/488308 | 06:41 |
*** harlowja has quit IRC | 06:48 | |
*** edmondsw has joined #openstack-keystone | 06:50 | |
*** ducttape_ has joined #openstack-keystone | 06:52 | |
*** edmondsw has quit IRC | 06:54 | |
*** ducttape_ has quit IRC | 06:54 | |
*** ducttape_ has joined #openstack-keystone | 06:55 | |
*** markvoelker has quit IRC | 06:55 | |
*** ducttape_ has quit IRC | 06:59 | |
*** ducttape_ has joined #openstack-keystone | 07:00 | |
*** ducttape_ has quit IRC | 07:04 | |
*** oomichi has quit IRC | 07:05 | |
*** oomichi has joined #openstack-keystone | 07:06 | |
openstackgerrit | Merged openstack/oslo.policy master: Updated from global requirements https://review.openstack.org/488097 | 07:13 |
*** masber has quit IRC | 07:13 | |
*** baffle_ has quit IRC | 07:13 | |
*** baffle has joined #openstack-keystone | 07:13 | |
*** masber has joined #openstack-keystone | 07:20 | |
*** aojea has joined #openstack-keystone | 07:22 | |
*** masber has quit IRC | 07:38 | |
*** cristicalin has joined #openstack-keystone | 07:41 | |
*** markvoelker has joined #openstack-keystone | 07:52 | |
*** cristicalin has quit IRC | 08:00 | |
*** prashkre has quit IRC | 08:00 | |
*** ducttape_ has joined #openstack-keystone | 08:01 | |
*** thorst has joined #openstack-keystone | 08:03 | |
*** ducttape_ has quit IRC | 08:03 | |
*** phalmos_ has quit IRC | 08:03 | |
*** ducttape_ has joined #openstack-keystone | 08:03 | |
*** ducttape_ has quit IRC | 08:07 | |
*** thorst has quit IRC | 08:07 | |
*** ducttape_ has joined #openstack-keystone | 08:10 | |
openstackgerrit | Pavlo Shchelokovskyy proposed openstack/keystoneauth master: Add release note for 'none' auth plugin https://review.openstack.org/478839 | 08:10 |
*** ducttap__ has joined #openstack-keystone | 08:12 | |
*** ducttape_ has quit IRC | 08:12 | |
*** ducttap__ has quit IRC | 08:16 | |
*** openstackgerrit has quit IRC | 08:18 | |
*** markvoelker has quit IRC | 08:26 | |
*** BlackDex_ is now known as BlackDex | 08:33 | |
*** mvk has quit IRC | 08:36 | |
*** openstackgerrit has joined #openstack-keystone | 08:37 | |
openstackgerrit | Jose Castro Leon proposed openstack/keystone master: Fix ec1tokens validation in v2 after regression in metadata_ref removal https://review.openstack.org/465530 | 08:37 |
openstackgerrit | Jose Castro Leon proposed openstack/keystone master: Fix ec2tokens validation in v2 after regression in metadata_ref removal https://review.openstack.org/465530 | 08:45 |
*** ducttape_ has joined #openstack-keystone | 09:00 | |
*** ducttap__ has joined #openstack-keystone | 09:03 | |
*** ducttape_ has quit IRC | 09:03 | |
*** rha has quit IRC | 09:06 | |
*** ducttap__ has quit IRC | 09:07 | |
*** markvoelker has joined #openstack-keystone | 09:23 | |
*** cristicalin has joined #openstack-keystone | 09:26 | |
*** cristicalin has quit IRC | 09:37 | |
*** kaisers1 has joined #openstack-keystone | 09:41 | |
kaisers1 | Hey! Can somebody give me a hint on how to workaround https://bugs.launchpad.net/keystone/+bug/1697458 ? I'm in dire need of an ocata based setup for testing some backports but so far I'm unable to do this. The setup runs with default devstack settings for keystone. | 09:44 |
openstack | Launchpad bug 1697458 in OpenStack Identity (keystone) "Cannot deploy stable/ocata" [Undecided,Confirmed] | 09:44 |
kaisers1 | (I'm asking the same question on the qa channel, btw. Just desperately looking for a way to spin up the ocata based env) | 09:44 |
*** rha has joined #openstack-keystone | 09:46 | |
*** markvoelker has quit IRC | 09:57 | |
*** ducttape_ has joined #openstack-keystone | 10:03 | |
*** thorst has joined #openstack-keystone | 10:04 | |
*** ducttap__ has joined #openstack-keystone | 10:06 | |
*** ducttape_ has quit IRC | 10:08 | |
*** thorst has quit IRC | 10:09 | |
*** ducttap__ has quit IRC | 10:10 | |
*** edmondsw has joined #openstack-keystone | 10:26 | |
*** edmondsw has quit IRC | 10:30 | |
*** kornicameister has quit IRC | 10:45 | |
*** kornicameister has joined #openstack-keystone | 10:46 | |
*** zhurong has quit IRC | 10:53 | |
*** markvoelker has joined #openstack-keystone | 10:55 | |
*** kornicameister has quit IRC | 11:03 | |
*** masber has joined #openstack-keystone | 11:04 | |
*** ducttape_ has joined #openstack-keystone | 11:07 | |
*** ducttape_ has quit IRC | 11:11 | |
openstackgerrit | Merged openstack/keystoneauth master: Add release note for 'none' auth plugin https://review.openstack.org/478839 | 11:15 |
*** cristicalin has joined #openstack-keystone | 11:15 | |
*** cristicalin has quit IRC | 11:20 | |
*** markvoelker has quit IRC | 11:27 | |
*** thorst has joined #openstack-keystone | 11:40 | |
*** AlexeyAbashkin has joined #openstack-keystone | 11:40 | |
*** thorst has quit IRC | 11:44 | |
*** AlexeyAbashkin has quit IRC | 11:47 | |
*** catintheroof has joined #openstack-keystone | 11:48 | |
openstackgerrit | zhiguo.li proposed openstack/keystone master: Add the step to install apache2 libapache2-mod-wsgi https://review.openstack.org/488386 | 11:48 |
*** rcernin has quit IRC | 11:55 | |
*** Dinesh_Bhor is now known as Dinesh_Bhor|afk | 12:01 | |
*** Dinesh_Bhor|afk is now known as Dinesh_Bhor | 12:02 | |
Dinesh_Bhor | cmurphy: Hi, I have updated the request-id patches. Whenever you get time please take a look at them: https://review.openstack.org/#/c/329913/, https://review.openstack.org/#/c/329913/, https://review.openstack.org/#/c/329913/ | 12:03 |
cmurphy | Dinesh_Bhor: sure, will try | 12:04 |
Dinesh_Bhor | cmurphy: thank you so much | 12:04 |
*** ducttape_ has joined #openstack-keystone | 12:05 | |
*** ducttape_ has quit IRC | 12:11 | |
*** adriant has joined #openstack-keystone | 12:12 | |
*** edmondsw has joined #openstack-keystone | 12:13 | |
*** catintheroof has quit IRC | 12:14 | |
*** rcernin has joined #openstack-keystone | 12:16 | |
samueldmq | morning | 12:16 |
*** thorst has joined #openstack-keystone | 12:16 | |
*** markvoelker has joined #openstack-keystone | 12:24 | |
*** markvoelker has quit IRC | 12:25 | |
*** jdennis has quit IRC | 12:26 | |
*** markvoelker has joined #openstack-keystone | 12:29 | |
*** jdennis has joined #openstack-keystone | 12:29 | |
openstackgerrit | Jose Castro Leon proposed openstack/keystoneauth master: Parameter to tune mutual authentication in kerberos https://review.openstack.org/455330 | 12:36 |
*** ducttape_ has joined #openstack-keystone | 12:38 | |
*** ducttape_ has quit IRC | 12:39 | |
*** ducttape_ has joined #openstack-keystone | 12:41 | |
*** cristicalin has joined #openstack-keystone | 12:42 | |
openstackgerrit | Jose Castro Leon proposed openstack/keystoneauth master: Parameter to tune mutual authentication in kerberos https://review.openstack.org/455330 | 12:43 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/488007 | 12:50 |
*** catintheroof has joined #openstack-keystone | 12:50 | |
*** cristicalin has quit IRC | 12:53 | |
*** ducttape_ has quit IRC | 12:54 | |
*** ducttape_ has joined #openstack-keystone | 12:56 | |
*** ducttape_ has quit IRC | 13:01 | |
*** jaosorior has quit IRC | 13:04 | |
*** lbragstad has joined #openstack-keystone | 13:04 | |
*** ChanServ sets mode: +o lbragstad | 13:04 | |
lbragstad | gagehugo: any luck with the hybrid_property attribute? | 13:07 |
*** links has quit IRC | 13:16 | |
*** rcernin has quit IRC | 13:38 | |
*** jistr is now known as jistr|mtg | 13:45 | |
*** dansmith is now known as superdan | 13:45 | |
*** ducttape_ has joined #openstack-keystone | 13:47 | |
*** ducttape_ has quit IRC | 13:49 | |
*** ducttape_ has joined #openstack-keystone | 13:49 | |
samueldmq | lbragstad: ping | 13:55 |
samueldmq | I was looking at https://review.openstack.org/#/c/485302/ and was wondering if that is being tested somehow | 13:55 |
lbragstad | samueldmq: not really - we don't have a way to functionally test it :-/ | 13:56 |
knikolla | o/ | 13:57 |
samueldmq | lbragstad: kk I left a couple of comments to try to understand it better at least | 14:00 |
samueldmq | lbragstad: thanks for confirming | 14:00 |
samueldmq | knikolla: hi | 14:00 |
lbragstad | samueldmq: it'd be nice to expand our tempest/devstack plugin stuff to support an ldap deployment | 14:00 |
lbragstad | then it would be easier to test things like that | 14:00 |
*** rcernin has joined #openstack-keystone | 14:00 | |
knikolla | wasn't rodrigods working on that with an intern? | 14:01 |
samueldmq | I was wondering exactly the same | 14:01 |
lbragstad | possibly | 14:01 |
samueldmq | it's been a while we support ldap, and we don't test it :( | 14:01 |
knikolla | https://review.openstack.org/#/c/483576/ | 14:01 |
lbragstad | ah - nice | 14:03 |
samueldmq | cool | 14:04 |
rodrigods | yep, this is exactly lwanderley's project :P | 14:05 |
knikolla | if i get more time to work on this https://review.openstack.org/#/c/466406/ we could also support these cases within unit tests. | 14:05 |
rodrigods | cool | 14:07 |
knikolla | wasn't there a bot that posted the title of reviews and bugs? | 14:07 |
lbragstad | knikolla: yeah - that'd be nice | 14:08 |
lbragstad | knikolla: i know the openstack-ansible folks were interested in an ldap backed identity deployment | 14:08 |
lbragstad | they wanted to run functional tests against it | 14:08 |
knikolla | lbragstad: that should already be supported by the ldap service in devstack. | 14:10 |
knikolla | what's missing is tests that exploit it. | 14:10 |
*** spilla has joined #openstack-keystone | 14:13 | |
lbragstad | gagehugo: lamt i've proposed pike-3 (ttx came knocking for it), but if you think you can get the rest of the project tags work done soon we can think about an FFE | 14:14 |
samueldmq | lbragstad: ++ | 14:15 |
lbragstad | gagehugo: lamt spilla we also have to keep in mind string freeze in order to give the translation team time before we release | 14:15 |
knikolla | is it waiting on reviews or needs changes? | 14:15 |
lbragstad | https://review.openstack.org/#/c/470317/ | 14:16 |
lbragstad | https://review.openstack.org/#/q/topic:bp/project-tags | 14:18 |
*** AlexeyAbashkin has joined #openstack-keystone | 14:18 | |
lbragstad | a couple of those, specifically the policy and json schema validation bits look good, | 14:18 |
*** gyee has joined #openstack-keystone | 14:19 | |
knikolla | ++, will give the implementation a review now. | 14:21 |
openstackgerrit | Jose Castro Leon proposed openstack/keystone master: Fix ec2tokens validation in v2 after regression in metadata_ref removal https://review.openstack.org/465530 | 14:21 |
*** sbezverk has quit IRC | 14:22 | |
spilla | lbragstad for review.openstack.org/#/c/481223 comment, just using add_tag for example, just change the call on L60 in keystoneclient/v3/projects.py to self.manager.add_tag(tag)? | 14:27 |
spilla | https://review.openstack.org/#/c/481223 | 14:27 |
*** otleimat has joined #openstack-keystone | 14:28 | |
spilla | and use self (the project object) instead of the project_id | 14:28 |
lbragstad | spilla: that could work | 14:31 |
lbragstad | i'd be nice to get morgan's feedback there too | 14:31 |
lbragstad | since it's client related | 14:31 |
lbragstad | if we want to keep pursuing project tags for pike though - i'd be inclined to get the server code in and worry about the client stuff next cycle | 14:31 |
spilla | okay, and yeah agreed on server over client. | 14:32 |
*** aojea has quit IRC | 14:36 | |
*** efried is now known as fried_rice | 14:36 | |
*** spilla has quit IRC | 14:37 | |
*** spilla has joined #openstack-keystone | 14:43 | |
*** jistr|mtg is now known as jistr | 14:46 | |
*** Dinesh_Bhor has quit IRC | 14:46 | |
*** masber has quit IRC | 14:46 | |
*** sbezverk has joined #openstack-keystone | 14:50 | |
*** harlowja has joined #openstack-keystone | 14:51 | |
*** Drankis has joined #openstack-keystone | 14:58 | |
*** spilla has quit IRC | 14:59 | |
knikolla | lbragstad: for project tags, supporting head on both /projects/{project_id}/tags/{value} and /projects/{project_id}/tags will cause the same bug as https://bugs.launchpad.net/keystone/+bug/1669070 | 15:02 |
openstack | Launchpad bug 1669070 in OpenStack Identity (keystone) "Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200" [Medium,Confirmed] | 15:02 |
*** edmondsw has quit IRC | 15:06 | |
*** spilla has joined #openstack-keystone | 15:08 | |
lbragstad | knikolla: yeah - i'm sure there are other places in the API that are subject to that | 15:11 |
lbragstad | knikolla: i was asking morgan about that earlier this week ^ | 15:11 |
*** rcernin has quit IRC | 15:13 | |
knikolla | lbragstad: yeah, i don't think there's much that we can do about that in this api version. | 15:13 |
knikolla | maybe handle it at the client side and reject values as None. | 15:14 |
lbragstad | yeah - i don't see how we can distinguish the difference between the two | 15:17 |
*** edmondsw has joined #openstack-keystone | 15:19 | |
*** spilla has quit IRC | 15:20 | |
*** links has joined #openstack-keystone | 15:24 | |
*** aselius has joined #openstack-keystone | 15:24 | |
lbragstad | flwang: regarding https://bugs.launchpad.net/django-openstack-auth/+bug/1531003 | 15:26 |
openstack | Launchpad bug 1531003 in django-openstack-auth "region used during login can vary" [Undecided,Fix released] - Assigned to Eric Peterson (ericpeterson-l) | 15:26 |
lbragstad | flwang: how are your keystone regions named now? | 15:26 |
gagehugo | lbragstad halfway with the hybrid_property, creating projects with tags works, but creating tags for projects separately is not | 15:33 |
lbragstad | gagehugo: hmmm | 15:34 |
openstackgerrit | Kristi Nikolla proposed openstack/keystone master: WIP - Added keystone identity provider installation to Devstack plugin https://review.openstack.org/484121 | 15:37 |
timothyb89 | hi all, I've got a question about accessing keystone via a tunneled connection | 15:40 |
timothyb89 | say I've got a client behind a firewall with no public internet connection, but I do have a tunnel straight to a public keystone, e.g. http://localhost:5000/v3/ forwards to https://example.com:5000/identity/v3/ | 15:40 |
timothyb89 | python-keystoneclient connects through the tunnel, discovers versions, and then tries to connect directly to a public URL from the versions list ... but this is not accessible | 15:40 |
timothyb89 | is there a way to force the keystoneclient to use the correct localhost url? | 15:40 |
knikolla | timothyb89: one easy thing you can do is set up your hosts file to redirect that url to localhost. | 15:41 |
timothyb89 | knikolla: that was the first thought, but unfortunately the endpoints are different (/identity vs just /) so that would require a full proxy server | 15:42 |
*** Drankis has quit IRC | 15:43 | |
knikolla | timothyb89: hmm… right. lemme check the docs. last i remember you can't force an endpoint. | 15:44 |
*** aojea has joined #openstack-keystone | 15:46 | |
*** jessegler has joined #openstack-keystone | 15:47 | |
lbragstad | stevemar: responded to https://review.openstack.org/#/c/484167/ | 15:50 |
*** aojea has quit IRC | 15:50 | |
*** harlowja has quit IRC | 15:51 | |
*** jmlowe has quit IRC | 15:51 | |
*** thorst_ has joined #openstack-keystone | 16:02 | |
gagehugo | lbragstad looking at nova's tag sql models | 16:02 |
lbragstad | gagehugo: do they use hybrid_properties ? | 16:02 |
gagehugo | not that I can see, currently looking at https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L1462-L1478 | 16:04 |
gagehugo | hybrid_property works for creating a project with tags | 16:04 |
gagehugo | but looking at tying creating a project tag back to project | 16:04 |
knikolla | timothyb89: if you feel adventurous http://paste.openstack.org/show/616882/ | 16:05 |
*** thorst has quit IRC | 16:05 | |
timothyb89 | knikolla: heh, I like it! we'll give it a try - thanks a ton! | 16:06 |
*** aojea has joined #openstack-keystone | 16:06 | |
knikolla | timothyb89: np, anytime. | 16:07 |
openstackgerrit | Doug Hellmann proposed openstack/keystone master: use the show-policy directive to show policy settings https://review.openstack.org/488508 | 16:07 |
*** aojea has quit IRC | 16:10 | |
*** jmlowe has joined #openstack-keystone | 16:12 | |
*** david-lyle has quit IRC | 16:14 | |
*** david-lyle has joined #openstack-keystone | 16:16 | |
*** david-lyle has quit IRC | 16:22 | |
*** aojea has joined #openstack-keystone | 16:24 | |
*** openstackstatus has quit IRC | 16:41 | |
*** openstack has joined #openstack-keystone | 16:42 | |
*** openstackstatus has joined #openstack-keystone | 16:43 | |
*** ChanServ sets mode: +v openstackstatus | 16:43 | |
*** links has quit IRC | 16:44 | |
*** catinthe_ has joined #openstack-keystone | 16:54 | |
*** harlowja has joined #openstack-keystone | 16:54 | |
*** harlowja_ has joined #openstack-keystone | 16:55 | |
*** catintheroof has quit IRC | 16:58 | |
*** harlowja has quit IRC | 16:59 | |
-openstackstatus- NOTICE: The Gerrit service on review.openstack.org is being taken offline for roughly 5 minutes to perform a database backup and reconfiguration | 17:12 | |
*** junbo has quit IRC | 17:15 | |
*** gyee has quit IRC | 17:23 | |
*** gyee has joined #openstack-keystone | 17:25 | |
*** openstackgerrit has quit IRC | 17:33 | |
*** openstackgerrit has joined #openstack-keystone | 17:38 | |
openstackgerrit | Doug Hellmann proposed openstack/oslo.policy master: fix formatting for empty defaults https://review.openstack.org/488546 | 17:38 |
openstackgerrit | Doug Hellmann proposed openstack/oslo.policy master: throw an exception when sphinxext cannot find the config file https://review.openstack.org/488547 | 17:38 |
*** mjax has joined #openstack-keystone | 17:45 | |
mjax | Hi, is this the right chat to ask questions about keystone config? I want to have keystone trust a token that comes from my company IdP, and use it to determine a user's roles and projects. The token has a signature that I can use the public keys to verify, and I was wondering what scope of change would I need to make to the keystone code base in o | 17:50 |
mjax | rder to make this happen | 17:50 |
*** mjax is now known as mjaxx | 17:55 | |
*** mjaxx is now known as mjax | 17:56 | |
*** aojea has quit IRC | 17:59 | |
*** gyee has quit IRC | 18:03 | |
knikolla | mjax: what type of token is that? | 18:04 |
*** aojea has joined #openstack-keystone | 18:05 | |
*** gyee has joined #openstack-keystone | 18:06 | |
*** catinthe_ has quit IRC | 18:08 | |
*** catintheroof has joined #openstack-keystone | 18:10 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: Add database migration for project tags https://review.openstack.org/484456 | 18:11 |
*** openstackstatus has quit IRC | 18:11 | |
*** openstack has joined #openstack-keystone | 18:12 | |
*** openstackstatus has joined #openstack-keystone | 18:13 | |
*** ChanServ sets mode: +v openstackstatus | 18:13 | |
*** gyee has quit IRC | 18:15 | |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: use the show-policy directive to show policy settings https://review.openstack.org/488508 | 18:21 |
openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: throw an exception when sphinxext cannot find the config file https://review.openstack.org/488547 | 18:26 |
openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: fix formatting for empty defaults https://review.openstack.org/488546 | 18:26 |
mjax | knikolla: its an athens role token, structure is similar to PKI. | 18:30 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: use the show-policy directive to show policy settings https://review.openstack.org/488508 | 18:31 |
openstackgerrit | Jaewoo Park proposed openstack/keystone master: Add new tags attribute to project https://review.openstack.org/470317 | 18:33 |
mjax | I was thinking of looking at the old PKI/PKIZ token support from a previous version as reference, but thought it would be faster if someone knowledgeable about the code base could give me a few pointers on what to focus on | 18:34 |
rm_work | can keystone issue a token from another token? | 18:34 |
rm_work | like, I use password-auth to get a token once, and then can I use the same token to issue another token before it expires? essentially, extending the life of my auth | 18:34 |
knikolla | rm_work: the expiration of the second token will be at most the one used to get it. | 18:35 |
knikolla | so you can't extend it. | 18:35 |
rm_work | hmm ok | 18:35 |
knikolla | mjax: is federation a possibility? if your idp supports saml2/oauth you could use that. | 18:35 |
rm_work | so it's possible to get another token, but keystone is aware of that possible loophole and forces it to be closed | 18:36 |
knikolla | rm_work: yes. | 18:36 |
rm_work | kk thanks! | 18:37 |
*** dave-mccowan has joined #openstack-keystone | 18:38 | |
openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: throw an exception when sphinxext cannot find the config file https://review.openstack.org/488547 | 18:39 |
fried_rice | mordred Well, shit, we have a problem with the only-undeprecated thing. | 18:39 |
fried_rice | mordred https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/adapter.py#L172 in fact raises if interface isn't registered. | 18:41 |
mordred | fried_rice: oh. because ... gah. that's just a bug fix | 18:41 |
mordred | fried_rice: lbragstad is going to kill us | 18:41 |
fried_rice | mordred I knoooowwww. | 18:41 |
mordred | fried_rice: you need to protect c.interface witha hasattr(c, 'interface') | 18:42 |
*** openstackstatus has quit IRC | 18:42 | |
* fried_rice cancels Denver itinerary | 18:42 | |
*** openstack has joined #openstack-keystone | 18:42 | |
fried_rice | mordred Either way. Call it. | 18:42 |
mordred | fried_rice: oh - you could fake it | 18:42 |
mordred | fried_rice: in nova | 18:42 |
fried_rice | mordred By registering the opt and then somehow disabling it but leaving it in place? | 18:43 |
mordred | fried_rice: conf[group].interface = None before you pass it in | 18:43 |
*** openstackstatus has joined #openstack-keystone | 18:43 | |
*** ChanServ sets mode: +v openstackstatus | 18:43 | |
mordred | nope- don't register it - just set that right before passing conf and group to load_from_conf_options | 18:43 |
fried_rice | mordred Ew, yeah, got it. | 18:44 |
mordred | fried_rice: then we'll make the bugfix to ksa and can release it at leisure | 18:44 |
fried_rice | mordred Roger wilco. | 18:44 |
mordred | put in a note in nova to remove the hack once we get a new ksa with the fix | 18:44 |
mordred | fried_rice: you want to make the ksa patch or want me to? | 18:44 |
fried_rice | flip for it | 18:44 |
* lbragstad flips a quarter | 18:45 | |
openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Protect against missing interface attribute https://review.openstack.org/488568 | 18:46 |
mordred | fried_rice, lbragstad: ^^ | 18:46 |
mjax | knikolla: don't think there is support for oauth/saml yet but I'll ask them about it. However, we wanted to just pass around our token to decrease the amount of database calls. Have keystone itself accept and understand the token, passing it on to the component, which will verify the token using I guess the keystone middleware? and execute the comm | 18:46 |
mjax | and for us | 18:46 |
fried_rice | mordred Cool. Throw in a test and I'm +1 | 18:46 |
mordred | will do | 18:47 |
fried_rice | mordred Oh, I think you may need it a few lines down as well. | 18:47 |
fried_rice | Cause I can register only undeprecated, but leave both out. | 18:47 |
knikolla | mjax: keystone will also need the ability to issue a token. but basically you need to implement this interface https://github.com/openstack/keystone/blob/master/keystone/token/providers/base.py | 18:48 |
mordred | fried_rice: yes. yes you do | 18:48 |
openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient master: Add project tags to keystoneclient https://review.openstack.org/481223 | 18:48 |
knikolla | mjax: honestly. the federation approach i think is the way to go. since you're going to have an external idp. | 18:49 |
mjax | knikolla: yup saw that one. Does that mean that there isn't a way for keystone to unconditionally trust an externally passed in token? | 18:49 |
openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: WIP Protect against missing interface attribute https://review.openstack.org/488568 | 18:49 |
mordred | fried_rice: ^^ marked WIP so it's clear we need tests | 18:50 |
mjax | we do want to federate everything using the external token, since it contains all of the information needed to determine a user's domain, project and roles within that project | 18:50 |
lbragstad | mjax: can't you do that with mappings in keystone? | 18:50 |
lbragstad | and give keystone the saml assertion? | 18:50 |
fried_rice | mordred Need a bug report too | 18:51 |
knikolla | lbragstad: ++ | 18:51 |
knikolla | mjax: keystone can't unconditionally trust a token because when validating it, it needs to get the user's information from the identity backend (when not using federation). so you'll need to write a identity backend to go with it. | 18:51 |
knikolla | lbragstad: correct me if i'm wrong. | 18:52 |
mjax | lbragstad: Could you tell me a bit more about that? I am not familiar with how saml works | 18:52 |
lbragstad | right | 18:52 |
lbragstad | mjax: so you have an idp, right? | 18:52 |
lbragstad | mjax: which is the thing that stores all your users (and possibly groups) | 18:53 |
lbragstad | so when you go to prove your identity, or authenticate, you do it against some identity provider, since it owns the source of truth about your account | 18:54 |
lbragstad | one thing you can do - depending on the identity provider, is have it issue you a SAML assertion | 18:54 |
lbragstad | with is a signed document from the identity provider that contains a bunch of information about the authentication interaction you just performed | 18:55 |
lbragstad | s/with/which/ | 18:55 |
lbragstad | what you can do is give that saml assertion to keystone | 18:55 |
mjax | and then how does keystone use that information? | 18:56 |
lbragstad | and keystone will verify it's validity, pull properties out of the assertion, and "map" the user in assertion to resources in openstack | 18:56 |
lbragstad | so - for example | 18:56 |
lbragstad | you could have a mapping in keystone that says "any user that is a member of the 'product' group or has the 'product' group in their saml assertion - place them in the 'product' group in openstack' | 18:57 |
lbragstad | you can then give that product group specific access to certain projects, or whatnot | 18:58 |
lbragstad | among other things | 18:58 |
lbragstad | but the point is that you can give keystone a SAML assertion and keystone will apply a mapping to it to determine what things that use should have access to | 18:59 |
lbragstad | s/use/user/ | 18:59 |
* lbragstad can't type today | 18:59 | |
mjax | mmm | 18:59 |
lbragstad | mjax: does that make sense? | 19:00 |
lbragstad | mjax: if not - that's totally cool | 19:00 |
mjax | i think I understand, so this is basically what I need, except keystone needs the saml assertion to trust the information sent in? | 19:01 |
lbragstad | mjax: right - that's part of how you set federation | 19:01 |
lbragstad | mjax: keystone is acting as the "service provider" in this case | 19:01 |
lbragstad | because it's protecting resources provided by a service | 19:02 |
lbragstad | so - one required thing you have to do when setting up federation is to establish trust between keystone and the thing providing the saml assertion, which is the identity provider | 19:02 |
mjax | right | 19:02 |
lbragstad | that way keystone can say "yes - this is a valid saml assertion and I can trust it" | 19:02 |
lbragstad | or "no - this isn't valid" | 19:03 |
knikolla | mjax: i think that's the way you wanna go rather than write your own token provider/identity backend. | 19:03 |
mjax | does that mean that alternatively, if athenz does not provide support for saml or oauth, I would need to go into the keystone code to write custom logic to trust a token sent in by athenz? | 19:03 |
lbragstad | mjax: https://goo.gl/RCCUsf | 19:03 |
openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient master: Add project tags to keystoneclient https://review.openstack.org/481223 | 19:04 |
lbragstad | mjax: yes - the current federation implementation requires SAML or OAUTH | 19:04 |
fried_rice | mordred You open that bug yet? If not, I'm gonna - need the number to put in my comment around the nova hack. | 19:05 |
*** dave-mccowan has quit IRC | 19:05 | |
knikolla | technically you could also do kerberos. but i've never tried. | 19:05 |
mjax | can you point me to the code that does the saml/oauth validation? | 19:09 |
lbragstad | mjax: so - that's where things get interesting | 19:09 |
knikolla | mjax: it's handled by apache. | 19:09 |
lbragstad | ^ | 19:09 |
lbragstad | we use an apache plugin to handle the validation of the SAML, which means you have to give it metadata so that it can validate the saml | 19:09 |
lbragstad | mjax: we do have some documentation here - https://docs.openstack.org/keystone/latest/admin/federated-identity.html | 19:11 |
knikolla | let us know if there's any dead links. | 19:11 |
mjax | I guess the problem is still that I'm not sure whether we have support for saml or oauth :( | 19:12 |
lbragstad | mjax: that's going to be the first step | 19:12 |
fried_rice | mordred https://bugs.launchpad.net/keystoneauth/+bug/1707273 | 19:12 |
openstack | Launchpad bug 1707273 in keystoneauth "get_adapter_conf_options(include_deprecated=False) results in NoSuchOptError" [Undecided,New] | 19:12 |
mordred | fried_rice: I have no - can you? I'm juggling a pile of things today | 19:12 |
*** nicolasbock has quit IRC | 19:12 | |
mordred | fried_rice: you read my mind :) | 19:12 |
fried_rice | I'll add the Closes-Bug tag to the change set. | 19:12 |
lbragstad | mjax: all federated approaches that i know about base the implementation off some sort of standard (like SAML) | 19:12 |
openstackgerrit | Eric Fried proposed openstack/keystoneauth master: WIP Protect against missing interface attribute https://review.openstack.org/488568 | 19:13 |
lbragstad | otherwise the contracts between the thing providing the identity and the thing consuming it because extremely coupled | 19:13 |
openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient master: Add project tags to keystoneclient https://review.openstack.org/481223 | 19:13 |
lbragstad | and that kinda defeats the purpose | 19:13 |
lbragstad | s/because/becomes/ | 19:14 |
* lbragstad sighs | 19:14 | |
openstackgerrit | Nicolas Helgeson proposed openstack/keystone master: Add new tags attribute to project https://review.openstack.org/470317 | 19:14 |
mjax | lbragstad: our architect outlined this approach, since he wanted UUIDs for a user to be the same across all openstack clusters, so that we can federate glance later down the line. Unfortunately, my scope of knowledge isn't quite wide enough to tell you all of the details involved | 19:15 |
mjax | I think the intent was to make them very coupled | 19:18 |
lbragstad | mjax: is each region or deployment suppose to have a separate identity backend? | 19:19 |
mjax | each deployment is supposed to unconditionally trust the info given by the athenz token, and delete/update/add users to their separate databases based on that... I'm not sure if that answers your question | 19:22 |
lbragstad | mjax: sorry - i could have framed my question a little better | 19:22 |
lbragstad | mjax: what is the definition of an openstack cluster in your statement above? | 19:23 |
mjax | it would be a region/deployment with its own keystone + openstack components | 19:24 |
lbragstad | ok | 19:24 |
*** ducttape_ has quit IRC | 19:24 | |
*** ducttape_ has joined #openstack-keystone | 19:25 | |
lbragstad | mjax: and you want each user to have the same uuid across all deployments? | 19:25 |
mjax | yes | 19:26 |
lbragstad | mjax: is there anything preventing you from using a single/global keystone deployment? | 19:26 |
mjax | i've been told that athenz doesn't support saml or oauth, but will be adding support for okta in | 19:26 |
openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient master: Add project tags to keystoneclient https://review.openstack.org/481223 | 19:33 |
*** aojea has quit IRC | 19:34 | |
mjax | a single keystone deployment might have some problems with scale and latency I think | 19:37 |
lbragstad | you can have local keystone nodes in each region - but they'd all share the same backend - so users and projects would be visible across the entire deployment | 19:39 |
lbragstad | creating and validating tokens issued from keystone are both read-only operations | 19:40 |
lbragstad | the default token provider in keystone doesn't actually persist the token | 19:40 |
mjax | i will be back in a bit thanks for help so far | 19:44 |
lbragstad | mjax: anytime - i'm curious to hear more about your use case | 19:45 |
*** spilla has joined #openstack-keystone | 19:45 | |
*** raildo has quit IRC | 19:49 | |
*** prashkre has joined #openstack-keystone | 20:07 | |
*** prashkre has quit IRC | 20:07 | |
*** catintheroof has quit IRC | 20:08 | |
*** boris_42 has joined #openstack-keystone | 20:20 | |
openstackgerrit | Nicolas Helgeson proposed openstack/keystone master: Add new tags attribute to project https://review.openstack.org/470317 | 20:26 |
*** jmlowe has quit IRC | 20:39 | |
mjax | hi lbragstad, I went ahead and reread some of our previous conversation, and I wanted to clarify that the currently proposed implementation would not need a new identity backend from keystone, but rather our athenz token will specify the required fields, and have a one-one mapping to the current identity backend that keystone uses. It sounds like i | 20:43 |
mjax | t would be feasible to get the athens token in the create token method and return that. | 20:43 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove duplicat sample files https://review.openstack.org/488609 | 20:43 |
*** raildo has joined #openstack-keystone | 20:46 | |
lbragstad | mjax: so the only thing you'd need to do is write your own token provider, right? | 20:48 |
mjax | The token will have some part of its string include: d=project_name;u=user_name;r=user_roles_in_project;s=signature; I would parse those attributes and check them against the keystone db. I think we will also be using the username to calculate a unique UUID, and use that for any openstack commands that require uuid, but that part has yet to be fina | 20:48 |
mjax | lized. Then I could send this token along | 20:48 |
mjax | yes i believe I only need to write a token provider | 20:48 |
lbragstad | it sounds like you'll have the same keystone database across the entire deployment, too? | 20:49 |
mjax | yea, the deployment should only have 1 db for keystone identity | 20:50 |
*** otleimat has quit IRC | 20:53 | |
lbragstad | for keystone identity or all of keystone (i ask because we have a specific table in keystone's database for "identity") | 20:53 |
mjax | I believe all of keystone. That one contains tables for projects/users/roles right? | 20:54 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Move credential encryption docs to admin-guide https://review.openstack.org/488612 | 20:55 |
lbragstad | yeah | 20:55 |
*** otleimat has joined #openstack-keystone | 20:55 | |
lbragstad | mjax: are users in your deployment going to be getting tokens from something other than keystone? | 20:56 |
mjax | The idea is to use the athenz tokens, which we will get once from their api | 20:57 |
* lbragstad googles | 20:59 | |
lbragstad | this https://github.com/yahoo/athenz ? | 20:59 |
mjax | thats the one | 20:59 |
lbragstad | interesting | 21:00 |
lbragstad | does it issue the token is a specific format? | 21:00 |
lbragstad | like a json web token or something? | 21:00 |
mjax | yea, always in the same format, but it's by default just a string | 21:02 |
mjax | it looks like a cookie | 21:02 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Move url safe naming docs to admin guide https://review.openstack.org/488625 | 21:03 |
openstackgerrit | OpenStack Release Bot proposed openstack/keystoneauth master: Update reno for stable/pike https://review.openstack.org/488641 | 21:03 |
openstackgerrit | OpenStack Release Bot proposed openstack/keystonemiddleware master: Update reno for stable/pike https://review.openstack.org/488644 | 21:03 |
openstackgerrit | OpenStack Release Bot proposed openstack/oslo.policy master: Update reno for stable/pike https://review.openstack.org/488708 | 21:05 |
openstackgerrit | OpenStack Release Bot proposed openstack/python-keystoneclient master: Update reno for stable/pike https://review.openstack.org/488782 | 21:07 |
*** thorst_ has quit IRC | 21:09 | |
*** ducttap__ has joined #openstack-keystone | 21:11 | |
mjax | https://thepasteb.in/p/r0hwJv7j7K1FK | 21:14 |
mjax | maybe that will be more clear? lbragstad (words from our architect) | 21:14 |
*** ducttape_ has quit IRC | 21:14 | |
lbragstad | mjax: interesting | 21:16 |
lbragstad | so athens needs to have access to the user in order to issue tokens | 21:16 |
lbragstad | er - access to where the user is stored | 21:17 |
lbragstad | so - by the wording of the paste - it sounds like the users are stored in athens | 21:17 |
*** ducttape_ has joined #openstack-keystone | 21:17 | |
lbragstad | which is where the identity backend for keystone comes into play | 21:17 |
mjax | not quite, we'll have athens maintaining its own db keeping track of that, and keystone will be updating its dbs to match the athens info | 21:17 |
lbragstad | oh - so users are duplicated in both systems | 21:18 |
mjax | from my understanding thats what should be happening | 21:18 |
lbragstad | i wonder how much trouble it would be to write an identity backend that spoke to athens | 21:18 |
lbragstad | so when you do a GET /v3/users/{user_id} it actually validates the user in athens | 21:19 |
mjax | I think the problem with that is we don't want to make so many database or net calls | 21:20 |
mjax | so once we have a token that keystone recognizes, we will do validation based on the public key and token signature | 21:20 |
*** ducttap__ has quit IRC | 21:20 | |
lbragstad | so athens creates tokens using asynchronous keys? | 21:21 |
mjax | yup | 21:21 |
lbragstad | signing and/or encrypting with private | 21:21 |
mjax | exatly | 21:21 |
mjax | mhm | 21:21 |
lbragstad | how often do you expect the user data to change? | 21:22 |
lbragstad | is it something you can cache for a given period of time/ | 21:22 |
mjax | could you tell me what you mean by user data exactly? | 21:22 |
lbragstad | sure - user data as in user information that athens owns | 21:22 |
*** spilla has quit IRC | 21:23 | |
*** edmondsw has quit IRC | 21:23 | |
lbragstad | mjax: it sounds like keystone is going to be in some sort of pub/sub relationship with athens to keep users in sync between the two systems | 21:24 |
*** edmondsw has joined #openstack-keystone | 21:24 | |
mjax | yes that is the intent | 21:24 |
mjax | I am not sure how often the user info will change | 21:25 |
lbragstad | mjax: if it doesn't change often - caching could alleviate some of the concerns around making backend checks over the network | 21:26 |
*** aojea has joined #openstack-keystone | 21:26 | |
mjax | Would that be secure? when would you decide to use the cached information as opposed to doing a network check? | 21:27 |
lbragstad | mjax: well - that'd be the trade off | 21:28 |
lbragstad | the longer you hold the cache the higher the risk of relying on stale data | 21:28 |
*** edmondsw has quit IRC | 21:28 | |
lbragstad | the trick with caching is trying to figure out how long you can confidently assume something is still valid | 21:29 |
lbragstad | which is why i asked how long you expect user information to change in athens | 21:29 |
mjax | I understand | 21:30 |
*** david-lyle has joined #openstack-keystone | 21:30 | |
lbragstad | you might also benefit from token caching in keystone - where we cache the token, which includes all information obtained from the call that went over the network to validate things in athens | 21:31 |
lbragstad | so the first time you validate a token in keystone - you can expect it to take a bit, but after that it's just a cached response in memcached keystone fetches based on arguments | 21:32 |
mjax | If I write a my own token provider for athens, then I could just use the public key to validate the athens token right? | 21:33 |
lbragstad | yeah - you'd have to make sure keystone knows how to deal with that though | 21:33 |
lbragstad | keystone users symmetric encryption to create tokens currently, which would be a good example to look at | 21:34 |
mjax | I am able to verify the token signature, it uses standard openSSL ecdsa encryption | 21:34 |
lbragstad | we use to have bits that did that in keystone when we supported PKI tokens | 21:34 |
lbragstad | but that has since been removed | 21:34 |
mjax | yea, I was looking at an older version to get some idea of how the PKI tokens were handled | 21:35 |
lbragstad | as far as i remember, they were only encoded and signed | 21:35 |
lbragstad | before getting put on the wire | 21:35 |
mjax | what about validation? | 21:36 |
lbragstad | same process, the signature would be validated and the payload would get unpacked | 21:36 |
lbragstad | well - i guess that might not be 100% accurate | 21:37 |
mjax | So it sounds like I could put some of the PKI code from an earlier release into my devstack instance to do some testing, and modify it to get it to the point that I want | 21:37 |
lbragstad | it depends on how you want to deal with token validation | 21:37 |
lbragstad | is the token *always* going to be validated using keystone? | 21:37 |
lbragstad | which implies a round trip? | 21:38 |
mjax | this is the part that i''m not too clear on since I haven't found out how the keystone middleware plays into things | 21:38 |
lbragstad | right now - keystone supports two token format (uuid and fernet), both of which require online validation | 21:39 |
mjax | i see | 21:39 |
lbragstad | meaning keystonemiddlware, sitting in front of the service, has to ask keystone "hey, is this token valid" | 21:39 |
mjax | so then I want the keystone middleware to pull up the list of public keys, and verify the message directly, instead of calling keystone | 21:40 |
lbragstad | which PKI - given the nature of asynchronous signing, it was possible to implement validation at the service, in keystonemiddlware | 21:40 |
lbragstad | but - the caching thing kinda comes back into play here because the token could be invalid, or the user could be gone, or the project could be deleted, etc... and the service won't know to validate that much of the token | 21:41 |
mjax | I didn't quite get that last part | 21:41 |
lbragstad | ok - here's a better example | 21:42 |
lbragstad | say i get a token from keystone that is scoped to a specific project, call it 'demo' | 21:42 |
lbragstad | then i go pass that token to nova to create an instance | 21:42 |
mjax | ok | 21:42 |
lbragstad | but before i passed my token to nova, let's say an admin disabled my account or deleted the 'demo' project | 21:43 |
mjax | ah I see | 21:43 |
lbragstad | when my token gets to nova, and if it is validated by verification of using a public key, there isn't anything stopping me from making a request when i should be | 21:43 |
lbragstad | shouldn't* | 21:43 |
lbragstad | so - the strategy that keystone and keystonemiddleware use today as a result of the token formats supported is a round trip | 21:44 |
lbragstad | when the token gets to keystonemiddleware, it is required to make a trip back to keystone to get validated | 21:44 |
mjax | through a net call to make sure that nothing's changed | 21:45 |
lbragstad | yeah - keystonemiddlware also has a caching layer to help cut down on some of the traffic though | 21:45 |
lbragstad | (in case that helps) | 21:45 |
mjax | yea | 21:45 |
lbragstad | one of the token providers has a *hard* requirement on this | 21:45 |
lbragstad | and that is the uuid provider | 21:46 |
lbragstad | because it's a random string stuffed in the keystone database | 21:46 |
lbragstad | so you have to go back to keystone to validate it | 21:46 |
mjax | I see | 21:46 |
lbragstad | the other, which is fernet, has a somewhat hard requirement | 21:46 |
lbragstad | we use symmetric encryption with fernet tokens | 21:46 |
lbragstad | which means we don't have to persist them anywhere but it makes sharing the keys used to encrypt and decrypt the tokens harder | 21:47 |
*** david-lyle has quit IRC | 21:48 | |
mjax | hmm | 21:48 |
lbragstad | fwiw - if i had to write a token provider tomorrow, i would take every opportunity to have it be non-persistent, but it doesn't sound like you'll have to worry about that since keystone will only be validating tokens, right? | 21:49 |
mjax | right | 21:49 |
lbragstad | keystone, in your deployment, will never need to issue a token, will it? | 21:49 |
lbragstad | ok - cool | 21:49 |
*** raildo has quit IRC | 21:51 | |
mjax | let's say that we ignore the problems with the token going bad or project getting deleted during the call, the only place I would need to write a token validation method is in the keystone middleware right? | 21:51 |
lbragstad | would you need to write it in keystone too? | 21:52 |
lbragstad | or are your users never expecting to use keystone to validate tokens? | 21:52 |
lbragstad | if you take the offline validation approach in keystonemiddleware and you know your users aren't going to be validating tokens using keystone, then the only place you'd need to implement token validation would be ksm | 21:53 |
lbragstad | but - it also depends on how much validation you want do | 21:53 |
lbragstad | are you only checking the signature or are you pulling out all the information and validating it? | 21:54 |
mjax | both | 21:54 |
lbragstad | so - if you're doing both, part of me things having it supported in keystone would be a good choice | 21:54 |
lbragstad | because when keystonemiddleware gets the token, it validates it with the public key, then starts making a bunch of calls to keystone to validate the project, the role, the user, etc... | 21:55 |
lbragstad | maybe it'd be easier to make a single call to keystone (GET /v3/auth/tokens) and have it validate everything and give back a single yay or nay | 21:55 |
mjax | i see | 21:56 |
lbragstad | but at that point - checking the signature with the public key doesn't really make a whole lot of sense | 21:56 |
mjax | The other possibility that was mentioned is to just validate the message, and trust the message details | 21:56 |
lbragstad | (because you're already making the round trip) | 21:56 |
mjax | yea | 21:57 |
lbragstad | right | 21:57 |
lbragstad | validate the signature and move along | 21:57 |
mjax | sorry I guess I would only be checking the message | 21:57 |
mjax | yea | 21:57 |
lbragstad | and risk the case i mentioned before - which is what we did when we supported PKI | 21:57 |
mjax | I will have to ask our architect how he intends to handle that | 21:58 |
lbragstad | we went down another rabbit hole in keystone | 21:58 |
mjax | in the case the user gets his account deleted, it's not a problem since he wouldn't be able to access to overall system anyway | 21:58 |
lbragstad | where we implemented an API to list all revoked tokens so that the middleware could compare the token it was validation to the values in the list | 21:58 |
lbragstad | (which is yet another API to keystone to avoid making an API call to keystone) | 21:59 |
lbragstad | API call* | 21:59 |
*** thorst has joined #openstack-keystone | 22:01 | |
*** thorst has quit IRC | 22:05 | |
mjax | lbragstad: thanks, sounds like for now, since this project is still in testing phase, we will just keep the expiry time on the tokens small to lower the risk of anything like that happening, and implement further safeguards as it gets closer to production. So now, I want to know some information about how to write a driver for establishing trust be | 22:17 |
mjax | tween athens and keystone | 22:17 |
mjax | could you point me in the direction of where to look for reference? | 22:17 |
*** jmlowe has joined #openstack-keystone | 22:18 | |
openstackgerrit | Eric Fried proposed openstack/keystoneauth master: WIP Protect against missing interface attribute https://review.openstack.org/488568 | 22:22 |
*** aojea has quit IRC | 22:29 | |
*** ducttap__ has joined #openstack-keystone | 22:30 | |
*** thorst has joined #openstack-keystone | 22:31 | |
*** ducttape_ has quit IRC | 22:33 | |
fried_rice | mordred Had to get a tad more aggressive with that workaround in nova FYI: https://review.openstack.org/#/c/488137/2..3 | 22:33 |
fried_rice | mordred Otherwise oslo cfg freaked out when it actually tried accessing the opt. | 22:34 |
fried_rice | mordred ...because of ConfigOpts.__getattr__ | 22:35 |
fried_rice | Found another buglet in Adapter loader while I was there. Patched it into https://review.openstack.org/488568 - hope nobody will mind. | 22:36 |
* fried_rice out | 22:36 | |
*** fried_rice is now known as efried_zzz | 22:36 | |
mordred | efried_zzz: great work - thanks! | 22:36 |
efried_zzz | \o/ | 22:37 |
*** ducttap__ has quit IRC | 22:42 | |
mjax | eiddccgeilrlcfkgdckhhltgndcfbijeblkjujeitnjj | 22:44 |
mjax | woops | 22:44 |
*** ducttape_ has joined #openstack-keystone | 22:45 | |
*** ducttape_ has quit IRC | 22:50 | |
*** ducttape_ has joined #openstack-keystone | 22:52 | |
*** ducttape_ has quit IRC | 22:56 | |
*** otleimat has quit IRC | 23:03 | |
*** gagehugo has quit IRC | 23:50 | |
*** gagehugo has joined #openstack-keystone | 23:56 | |
*** markvoelker has quit IRC | 23:56 | |
*** ducttape_ has joined #openstack-keystone | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!