| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Allow for more robust config checking with keystone-manage https://review.openstack.org/589308 | 00:02 |
|---|---|---|
| *** gyee has quit IRC | 00:06 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Allow for more robust config checking with keystone-manage https://review.openstack.org/589308 | 00:14 |
| *** zhurong has joined #openstack-keystone | 00:22 | |
| *** harlowja has quit IRC | 00:26 | |
| *** mvkr has quit IRC | 00:26 | |
| *** mvkr has joined #openstack-keystone | 00:27 | |
| *** mvkr has quit IRC | 00:39 | |
| *** mvkr has joined #openstack-keystone | 00:40 | |
| *** mvkr has quit IRC | 00:50 | |
| *** mvkr has joined #openstack-keystone | 00:51 | |
| *** mvkr has quit IRC | 01:01 | |
| *** mvkr has joined #openstack-keystone | 01:02 | |
| openstackgerrit | Merged openstack/keystone master: Add a release note for bug 1785164 https://review.openstack.org/589241 | 01:11 |
| openstack | bug 1785164 in OpenStack Identity (keystone) "Identity API v3: POST method for "Create Limits" is abnormal for a domain-id" [Undecided,Fix released] https://launchpad.net/bugs/1785164 - Assigned to wangxiyuan (wangxiyuan) | 01:11 |
| openstackgerrit | Merged openstack/oslo.policy master: import zuul job settings from project-config https://review.openstack.org/588703 | 01:25 |
| *** zhurong has quit IRC | 01:26 | |
| *** lbragstad has quit IRC | 02:18 | |
| *** jhesketh_ is now known as jhesketh | 03:14 | |
| *** dave-mccowan has quit IRC | 03:31 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Remove redundant get_project call https://review.openstack.org/589027 | 03:50 |
| *** spsurya has joined #openstack-keystone | 03:54 | |
| *** sonuk has joined #openstack-keystone | 04:40 | |
| *** sonuk has quit IRC | 04:56 | |
| *** sonuk has joined #openstack-keystone | 04:59 | |
| vishakha | wxy-xiyuan , cmurphy : Hi, Regarding this bug https://bugs.launchpad.net/keystone/+bug/1473292. Can I propose a blueprint for "Implementing trust_flush via keystone-manage". Is this seems valid ? Thanks. | 05:08 |
| openstack | Launchpad bug 1473292 in OpenStack Identity (keystone) "Cannot delete or show a trust with an expired date" [Wishlist,Triaged] - Assigned to Vishakha Agarwal (vishakha.agarwal) | 05:08 |
| *** shyambiradar has joined #openstack-keystone | 05:12 | |
| *** jaosorior has quit IRC | 05:26 | |
| *** shyambiradar has quit IRC | 05:39 | |
| *** shyambiradar has joined #openstack-keystone | 05:39 | |
| *** nicolasbock has joined #openstack-keystone | 05:46 | |
| openstackgerrit | wangqi proposed openstack/oslo.policy master: Remove PyPI downloads https://review.openstack.org/589368 | 06:00 |
| *** jaosorior has joined #openstack-keystone | 06:05 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Remove redundant get_project call https://review.openstack.org/589027 | 06:27 |
| *** hoonetorg has quit IRC | 06:33 | |
| *** pcaruana has joined #openstack-keystone | 06:36 | |
| openstackgerrit | Vishakha Agarwal proposed openstack/keystone master: Implement Trust Flush via keystone-manage. https://review.openstack.org/589378 | 06:48 |
| *** hoonetorg has joined #openstack-keystone | 06:49 | |
| openstackgerrit | Vishakha Agarwal proposed openstack/keystone master: Implement Trust Flush via keystone-manage. https://review.openstack.org/589378 | 06:50 |
| cmurphy | vishakha: we don't really use blueprints, I would just propose a patch with closes-bug (looks like that's what you already did) | 06:54 |
| vishakha | cmurphy: thanks :) | 06:55 |
| vishakha | cmurphy: https://review.openstack.org/#/c/588211/ need one more +2. Pl review. | 06:59 |
| *** shyambiradar has quit IRC | 07:00 | |
| *** shyambiradar has joined #openstack-keystone | 07:00 | |
| *** shyambiradar has quit IRC | 07:13 | |
| *** shyambiradar has joined #openstack-keystone | 07:23 | |
| wxy-xiyuan | vishakha: Closing the bug is fine. I have to reread the bug context before looking your fix. Thanks for picking it up. | 07:29 |
| *** shyambiradar has quit IRC | 07:47 | |
| *** jaosorior has quit IRC | 07:49 | |
| *** slunkad has quit IRC | 07:58 | |
| *** jaosorior has joined #openstack-keystone | 08:02 | |
| *** rcernin has quit IRC | 08:11 | |
| *** Emine has joined #openstack-keystone | 08:16 | |
| *** sayalilunkad has joined #openstack-keystone | 08:31 | |
| *** shyambiradar has joined #openstack-keystone | 08:47 | |
| *** jaosorior has quit IRC | 09:02 | |
| *** josecastroleon has joined #openstack-keystone | 09:14 | |
| vishakha | wxy-xiyuan: thanx for the reply | 09:49 |
| *** shyambiradar has quit IRC | 09:50 | |
| openstackgerrit | Merged openstack/oslo.policy master: Remove PyPI downloads https://review.openstack.org/589368 | 09:50 |
| vishakha | wxy-xiyuan, cmurphy : I am a little confused for this https://review.openstack.org/#/c/588211/. Is this on hold for now? | 09:50 |
| *** shyambiradar has joined #openstack-keystone | 09:51 | |
| cmurphy | vishakha: no, there's nothing preventing someone else from merging it | 09:53 |
| vishakha | ok thanks | 09:54 |
| *** shyambiradar has quit IRC | 10:34 | |
| *** jaosorior has joined #openstack-keystone | 10:46 | |
| *** shyambiradar has joined #openstack-keystone | 10:49 | |
| *** dave-mccowan has joined #openstack-keystone | 10:51 | |
| *** zeus has quit IRC | 10:53 | |
| *** shyambiradar has quit IRC | 10:54 | |
| *** shyambiradar has joined #openstack-keystone | 11:41 | |
| *** s10 has joined #openstack-keystone | 11:57 | |
| *** jaosorior has quit IRC | 11:59 | |
| *** raildo has joined #openstack-keystone | 12:02 | |
| *** raildo has quit IRC | 12:03 | |
| *** raildo has joined #openstack-keystone | 12:03 | |
| *** edmondsw has joined #openstack-keystone | 12:04 | |
| *** raildo has quit IRC | 12:04 | |
| *** raildo has joined #openstack-keystone | 12:05 | |
| *** raildo has quit IRC | 12:06 | |
| *** raildo has joined #openstack-keystone | 12:06 | |
| *** raildo has quit IRC | 12:07 | |
| *** s10 has quit IRC | 12:09 | |
| *** s10 has joined #openstack-keystone | 12:10 | |
| *** s10 has quit IRC | 12:10 | |
| *** raildo has joined #openstack-keystone | 12:12 | |
| *** raildo has quit IRC | 12:14 | |
| *** raildo has joined #openstack-keystone | 12:15 | |
| *** jaosorior has joined #openstack-keystone | 12:18 | |
| *** jaosorior has quit IRC | 12:27 | |
| *** jaosorior has joined #openstack-keystone | 12:42 | |
| *** glb has quit IRC | 12:50 | |
| *** shyambiradar has quit IRC | 12:54 | |
| *** dklyle has quit IRC | 12:59 | |
| *** bigdogstl has joined #openstack-keystone | 13:00 | |
| *** shyambiradar has joined #openstack-keystone | 13:01 | |
| *** shyambiradar has quit IRC | 13:10 | |
| *** lbragstad has joined #openstack-keystone | 13:11 | |
| *** ChanServ sets mode: +o lbragstad | 13:11 | |
| *** s10 has joined #openstack-keystone | 13:15 | |
| *** bigdogstl has quit IRC | 13:36 | |
| *** _ix has quit IRC | 14:06 | |
| kmalloc | cmurphy: ++ to figuring out how to manage group names vs IDs. | 14:11 |
| cmurphy | kmalloc: any suggestions? | 14:13 |
| cmurphy | how important is it that the saml assertion use names instead of IDs? | 14:14 |
| *** jrist has quit IRC | 14:15 | |
| *** nicolasbock has quit IRC | 14:18 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Allow for more robust config checking with keystone-manage https://review.openstack.org/589308 | 14:24 |
| *** mbuil has joined #openstack-keystone | 14:26 | |
| *** jrist has joined #openstack-keystone | 14:27 | |
| *** dklyle has joined #openstack-keystone | 14:33 | |
| *** josecastroleon has quit IRC | 14:35 | |
| mbuil | hello Keystone community! I am planning to run a proof of concept with the architecture you guys suggested to the edge computing group. As far as I understood, a central openstack will act as a IdP for various openstack deployments with limited resources. Is there any link with useful documentation where I could start? I already have two openstack deployments that can ping each other :P | 14:35 |
| *** josecastroleon has joined #openstack-keystone | 14:36 | |
| lbragstad | mbuil: o/ | 14:42 |
| *** _ix has joined #openstack-keystone | 14:42 | |
| lbragstad | are you familiar with federated identity at all? | 14:42 |
| lbragstad | or federation in general? | 14:43 |
| lbragstad | if not - https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html might be a good place to start | 14:43 |
| cmurphy | mbuil: o/ in addition to the official docs i have some notes here that might be useful http://www.gazlene.net/demystifying-keystone-federation.html | 14:44 |
| mbuil | lbragstad: I have just watched https://www.youtube.com/watch?v=jwXenfEOSOk and read http://www.gazlene.net/demystifying-keystone-federation.html. I guess Keystone to Keystone is what I am after | 14:44 |
| lbragstad | lol - perfect | 14:44 |
| cmurphy | heh | 14:45 |
| mbuil | :) | 14:45 |
| lbragstad | kmalloc: you want me to base the policy conversion on https://review.openstack.org/#/c/589282/ ? | 14:46 |
| lbragstad | mbuil: yeah - it sounds like k2k has been the popular target for edge discussions | 14:46 |
| mbuil | lbragstad, cmurphy: let me read that and try to come back with good questions. I guess I need to figure out how to configure keystone_1 as IdP and keystone_2 as Federated pointing to keystone_1 for IdP | 14:47 |
| mbuil | does that make sense? Or I am totally confused? | 14:47 |
| lbragstad | right - that's the gist of it | 14:47 |
| lbragstad | you'll need to setup one keystone deployment to be the identity provider | 14:48 |
| cmurphy | there's also been an idea about using regular federation and then using application credentials on the service providers | 14:48 |
| lbragstad | yeah, that's right | 14:48 |
| lbragstad | mbuil: the other keystone will be the service provider, so you'll need to set it up to trust the identity provider of your deployment (the fact that both deployments are keystone is the keystone-to-keystone part) | 14:50 |
| lbragstad | there is always the option to setup federation the other identity providers, or anything that speaks SAML (like ADFS) | 14:51 |
| lbragstad | s/the/with/ | 14:51 |
| mbuil | cmurphy what does application mean in keystone context? | 14:52 |
| mbuil | lbragstad: ok, thanks. I think we will start with Keystone to Keystone as first step | 14:53 |
| cmurphy | mbuil: we have a special credential type called 'application credentials' https://docs.openstack.org/keystone/latest/user/application_credentials.html so it means any automated thing but a human could use it too if they wanted | 14:53 |
| *** josecastroleon has quit IRC | 14:55 | |
| lbragstad | cmurphy: can you jog my memory on how we were going to work that into federated use cases? | 14:55 |
| *** wxy|xiyuan has joined #openstack-keystone | 14:57 | |
| *** hoonetorg has quit IRC | 14:57 | |
| *** josecastroleon has joined #openstack-keystone | 14:57 | |
| cmurphy | lbragstad: i think the idea is during the times your sites are connected you use your user to create application credentials on the keystones in different sites, so that during the times the sites aren't connected you can use the application credential to log in locally | 14:57 |
| *** Emine has quit IRC | 14:58 | |
| lbragstad | aha - ok, that's right | 14:58 |
| *** jaosorior has quit IRC | 15:01 | |
| *** lamt has joined #openstack-keystone | 15:02 | |
| mbuil | cmurphy: I am confused now. If keystone_2 is federated and uses keystone_1 as IdP, when the connection is broken, how can keystone_2 provide tokens if it cannot validate users? | 15:03 |
| *** nicolasbock has joined #openstack-keystone | 15:07 | |
| cmurphy | lbragstad: kmalloc knikolla what was the idea there ^ ? shadow users on keystone_2? | 15:09 |
| lbragstad | i think so | 15:09 |
| lbragstad | mbuil: when a user authenticates using federation, the keystone acting as a service provider creates something called a "shadow user" | 15:10 |
| lbragstad | which is stored in the keystone SP database | 15:10 |
| mbuil | aaah I see. Thanks | 15:11 |
| *** pcaruana has quit IRC | 15:11 | |
| lbragstad | the theory behind it is that if a federated user creates an application credential, the application credential will be associated to the shadow user, meaning keystoen SP won't have to make a round trip to the identity provider | 15:11 |
| *** s10 has quit IRC | 15:12 | |
| *** s10 has joined #openstack-keystone | 15:15 | |
| knikolla | reading up | 15:29 |
| *** gyee has joined #openstack-keystone | 15:32 | |
| kmalloc | lbragstad: yeah | 15:33 |
| knikolla | yeah, with regards to authN that was the plan | 15:33 |
| lbragstad | kmalloc: cool | 15:33 |
| knikolla | with regards to authZ there are two options | 15:33 |
| knikolla | use groups and get permissions at authentication time based on the groups you have. | 15:34 |
| kmalloc | cmurphy: i defer to knikolla, but i don't like transmitting only group_ids, what do those ids mean... we need some kind of translation | 15:34 |
| knikolla | we discussed about having "refreshable" application credentials which store the permissions at authentication time | 15:34 |
| kmalloc | lbragstad: i made some formatting changes in the __init__, etc so that we are less-likely to conflict and can parallelize some of the work. | 15:35 |
| knikolla | or just have a concrete role assignment on the shadow user | 15:35 |
| kmalloc | knikolla: i think we wanted both, refreshable app-cred and concrete role assignment | 15:35 |
| kmalloc | two different use-cases | 15:35 |
| kmalloc | local-only and possibly disconnected sync case. | 15:36 |
| knikolla | yup, that's why i said to options, depending on the use case | 15:37 |
| knikolla | i'll start writing a spec for stein | 15:38 |
| kmalloc | ++ | 15:39 |
| *** s10 has quit IRC | 15:39 | |
| *** s10 has joined #openstack-keystone | 15:40 | |
| kmalloc | lbragstad: note that some /policy bits are in end-point-policy | 15:47 |
| kmalloc | lbragstad: but just extract those parts when you port /policy [i messed up the _path_prefix thing for endpoint policy] | 15:47 |
| *** ayoung has joined #openstack-keystone | 16:03 | |
| *** wxy|xiyuan has quit IRC | 16:05 | |
| *** spilla has joined #openstack-keystone | 16:21 | |
| kmalloc | And now, for your viewing pleasure... | 16:28 |
| kmalloc | https://usercontent.irccloud-cdn.com/file/IgM9ga54/nori+the+shiba.jpg | 16:28 |
| cmurphy | omg she got huge | 16:29 |
| *** devx has quit IRC | 16:29 | |
| cmurphy | where did the mini floofball go | 16:29 |
| *** devx has joined #openstack-keystone | 16:31 | |
| *** lbragstad[m] has quit IRC | 16:32 | |
| kmalloc | yeah, she's gotten big | 16:34 |
| kmalloc | she's like 20lbs now. | 16:34 |
| kmalloc | and still not even full size (~4.5mo) | 16:35 |
| kmalloc | prob will be growing still for another month or so, then will fill out, we're guessing she's going to be close to 30lbs | 16:35 |
| kmalloc | she's a very silly dog. | 16:36 |
| *** s10 has quit IRC | 16:38 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Pass path into full_url and base_url https://review.openstack.org/589546 | 16:43 |
| *** Emine has joined #openstack-keystone | 16:55 | |
| lbragstad | #startmeeting keystone-office-hours | 17:00 |
| openstack | Meeting started Tue Aug 7 17:00:17 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| openstack | The meeting name has been set to 'keystone_office_hours' | 17:00 |
| lbragstad | cmurphy: i suppose this is an inconvenient time for you | 17:00 |
| cmurphy | not at all | 17:01 |
| * lbragstad is all ears | 17:01 | |
| cmurphy | so this is the bug that captures it i think https://bugs.launchpad.net/keystone/+bug/1470205 | 17:01 |
| openstack | Launchpad bug 1470205 in OpenStack Identity (keystone) "Keystone IdP SAML metadata insufficient for websso flow" [Wishlist,Triaged] | 17:01 |
| knikolla | ++ | 17:01 |
| knikolla | though we're not in the business of being a webapp | 17:02 |
| cmurphy | when keystone is set up as a SAML IdP it isn't capable of doing the WebSSO profile, all it does is this very weird IdP-initiated ECP flow which is not a real profile | 17:02 |
| knikolla | and the websso flow kinda requires that. | 17:02 |
| cmurphy | yeah | 17:02 |
| lbragstad | ahh | 17:02 |
| knikolla | we'd need a form to login, and session cookies. | 17:03 |
| lbragstad | so we have gaps in our federated IdP implementation specifically | 17:03 |
| kmalloc | so, fwiw, with flask, i'll be moving us towards having an actual non-json page | 17:03 |
| kmalloc | if possible | 17:03 |
| kmalloc | which leads towards possibly being able to render websso things more cleanly | 17:03 |
| knikolla | kmalloc: that would be really helpful | 17:03 |
| kmalloc | flask opens doors in ways webob was a REAL pain | 17:03 |
| kmalloc | i already have some logic for "accept header" variations and rendering different content | 17:04 |
| kmalloc | so, we can head down that path | 17:04 |
| lbragstad | which i think we needed for json/home | 17:04 |
| kmalloc | yes | 17:04 |
| kmalloc | in flask that was a lot easier to do than in webob | 17:04 |
| kmalloc | and once we're 100% on flask-restful, i'll be making a push to go to restplus | 17:05 |
| kmalloc | so we get swagger documentation | 17:05 |
| kmalloc | if we already have that, we can line up some views for web-rendering that can be webapp/sso flow compatible | 17:05 |
| kmalloc | so, think in S release we might be able to head down that path. | 17:05 |
| knikolla | sounds reasonable | 17:05 |
| kmalloc | depending on how the rest of flask conversion goes | 17:06 |
| lbragstad | cmurphy: you have colleagues asking for this specifically? | 17:06 |
| lbragstad | or customers? | 17:06 |
| kmalloc | lbragstad: change of plans, use https://review.openstack.org/#/c/589546/ [if it passes check] as the base for /policy API | 17:06 |
| lbragstad | kmalloc: ack | 17:06 |
| kmalloc | lbragstad: i changed the way full_url and base_url work | 17:06 |
| kmalloc | so you can pass in a path to them and get /v3 added automatically | 17:07 |
| kmalloc | etc | 17:07 |
| cmurphy | lbragstad: colleages/project managers | 17:07 |
| cmurphy | ignoring the SAML part, the other part I have a hard time wrapping my head around is how a not-openstack application would know how to use keystone fernet tokens - i guess it would have to use keystonemiddleware or have some other kind of middleware that knows to redirect users to keystone for auth and requires the x-auth-token header for all requests | 17:07 |
| lbragstad | yeah... | 17:08 |
| cmurphy | and then what does it do with information about projects? what would not-openstack do with projects and role assignments | 17:08 |
| lbragstad | right | 17:08 |
| knikolla | if we implemented openid connect, we would already be compatible with most apps | 17:08 |
| lbragstad | we also have a derivative of RBAC that's isn't exaclty an industry standard | 17:08 |
| knikolla | the problem is the RBAC, more or less. | 17:09 |
| knikolla | yeah | 17:09 |
| lbragstad | i agree | 17:09 |
| lbragstad | i think this same kinda problem came up when we talked about oauth2 support | 17:09 |
| lbragstad | i guess it depends on what's using keystone and what they are trying to protect (without sounds overly vague) | 17:11 |
| lbragstad | how are the resources grouped? | 17:11 |
| knikolla | yeah | 17:12 |
| lbragstad | depending on the answers, could you generalize keystone enough to work for each? | 17:12 |
| knikolla | oauth2.0 has the concept of scopes (think roles). but nothing really project based | 17:14 |
| knikolla | i'm also not familiar with other implementations of scoped rbac like in openstack. | 17:15 |
| lbragstad | i'm not aware of any other implementations of scoped-rbac | 17:15 |
| lbragstad | i want to say scoped-rbac is openstack-specific | 17:16 |
| knikolla | in that case, does the application care about the project at all? | 17:16 |
| lbragstad | which application? | 17:16 |
| knikolla | external application that want to integrate with keystone | 17:16 |
| lbragstad | i think the answer to that depends on what the application is responsible for | 17:16 |
| knikolla | if all they care is users and roles (and have no concept of scoped rbac), but just plain rbac | 17:16 |
| *** orange_julius has joined #openstack-keystone | 17:16 | |
| knikolla | that should be doable in a generalizable way | 17:17 |
| cmurphy | knikolla: hmm so maybe there'd be a dummy project and the application only pays attention to the role name? | 17:17 |
| lbragstad | if the application in question is something like nova that provides APIs for managing all sorts of things across different authorization levels, then i think keystone needs to care about scoped-rbac | 17:17 |
| orange_julius | Hey guys. Had a quick question about Keystone + LDAP. I have 3 controllers configured and Keystone seems to be sending an authentication request from Horizon off to LDAP 3 times, assumingly one per controller. This is causing an issue because our lockout policy in LDAP is 3 bad passwords... so if a user enters 1 bad password we get an instant locko | 17:18 |
| orange_julius | ut. Is this expected behaviour? Why would keystone be sending the authentication request 3 times for the same request? | 17:18 |
| knikolla | cmurphy: yeah, something like that | 17:18 |
| lbragstad | that's essentially what we started with, i think | 17:19 |
| lbragstad | deploy keystone with a single "level" of authorization and only use that layer | 17:19 |
| cmurphy | orange_julius: your haproxy should be configured to forward requests to just one keystone, three keystones making the same request at once would indeed all go to ldap | 17:20 |
| knikolla | depends on how they want to do the integration. if they care about users, use a dummpy project. if they care about projects (as in the webapp provides services to extend an existing openstack deployemnt therefore project isolation matters), we can send the project_id as the username in the assertion. | 17:20 |
| *** spilla has quit IRC | 17:20 | |
| _ix | Maybe this is actually a quick question... if I'm using passwords, is there a reason that I'd specify `v3password` instead of `password`? | 17:20 |
| cmurphy | lbragstad: heh yeah i guess this sort of takes us back to pre-multitenancy | 17:20 |
| _ix | I don't know why, but some of the services I'm working on have a v3password specified in the conf files. | 17:20 |
| cmurphy | _ix: in theory they should both be the same, `password` i think either looks at the url or does a discovery step to figure out what version to use | 17:21 |
| knikolla | cmurphy: so the question is, in the webapp, do you want to act on behalf of the user (username in assertion = user_id, webapp will have no concept of projects). do you want to act on behalf of a project (username in assertion is project_id, webapp will have no concept of individual users) | 17:22 |
| _ix | Ah. So if I'm explicit with the endpoint, I'll be in good shape. Thanks! | 17:22 |
| cmurphy | knikolla: that's a good way to look at it | 17:23 |
| lbragstad | knikolla: in the first example, i'm inclined to say we already support that pretty easily | 17:23 |
| *** spilla has joined #openstack-keystone | 17:24 | |
| * lbragstad feels like we're coming up with various deployment models | 17:24 | |
| knikolla | ++ | 17:25 |
| lbragstad | protecting apps the have no concept of scope or individual projects is a pretty low bar since most of that can be done between keystone and ksm | 17:25 |
| lbragstad | if an app starts caring about tenancy, then it becomes a question of where that logic lives, imo | 17:26 |
| knikolla | lbragstad: in the case that the app cares about tenancy, that would probably be tied to an attribute/claim of the assertion. | 17:26 |
| knikolla | we could make that configurable | 17:27 |
| knikolla | Keycloak for example allows you to map user attributes -> claims for each specific client which is using it for auth. | 17:28 |
| lbragstad | but the app being protected needs to understand those claims, right? | 17:28 |
| knikolla | assuming it's already using a standard openid connect / saml idp. it probably already does | 17:29 |
| *** harlowja has joined #openstack-keystone | 17:31 | |
| knikolla | we just need to document the mapping between keystone terminology -> openid connect / saml, and deployment strategies. | 17:31 |
| knikolla | like the two cases i mentioned above. | 17:32 |
| lbragstad | and the resources managed by the webapp? | 17:32 |
| knikolla | it's up to the webapp, based on the roles keystone says u have | 17:33 |
| knikolla | not any different than what it is now | 17:33 |
| lbragstad | today - that's done by policy | 17:33 |
| lbragstad | or our specific policy engine | 17:33 |
| lbragstad | because that's where we say "instances are project resources, endpoints are system resources" | 17:34 |
| knikolla | you can flatten that into the webapp checking instances require the project_member role, endpoint require the system_member role. | 17:34 |
| lbragstad | yeah - using a policy file is an implementation detail | 17:35 |
| knikolla | yup | 17:35 |
| lbragstad | i guess what i'm seeing is that the resource can make a difference in that mapping depending on the app | 17:36 |
| knikolla | lbragstad: you could also say that scope is an implementation detail | 17:37 |
| knikolla | user has access to project which owns resource | 17:37 |
| knikolla | user acts on behalf of project which owns resource. | 17:38 |
| knikolla | like i don't think most openstack project care about users | 17:38 |
| knikolla | they store resources with a project_id in their database | 17:38 |
| knikolla | therefore given (project_id, role) a webapp has enough information to enforce policy | 17:40 |
| lbragstad | sure | 17:41 |
| knikolla | i also remember the early discussions about making system a part of the project tree | 17:41 |
| *** harlowja has quit IRC | 17:43 | |
| lbragstad | true | 17:43 |
| lbragstad | we decided against that because we thought there was a difference between the resources in openstack's case | 17:44 |
| orange_julius | Could keystone be picking up the authentication requests from RabbitMQ? It doesn't seem like HAProxy is forwarding the requests to all 3 keystone servers | 17:45 |
| *** markvoelker_ has quit IRC | 17:45 | |
| lbragstad | orange_julius: keystone doesn't support authentication via the message bus | 17:47 |
| orange_julius | hmmm ok. Didn't think so but am running out of ideas. | 17:47 |
| lbragstad | does the problem go away if you only route requests so a single keystone node? | 17:48 |
| orange_julius | Not sure yet. We have to schedule an outage for that sort of test. | 17:51 |
| *** ayoung has quit IRC | 17:53 | |
| lbragstad | i suppose you could try and recreate it by making the same request to a single keystone node, too | 17:57 |
| lbragstad | as opposed to taking nodes out of the pool | 17:57 |
| * lbragstad grabs lunch quick | 17:57 | |
| kmalloc | lbragstad: our tests are still spewing the "scope check" fail message | 17:59 |
| kmalloc | lbragstad: do we have a fix for that? | 17:59 |
| kmalloc | this is a LOT of extra logging that seems like it is not actionable atm. | 17:59 |
| kmalloc | oslo_context. | 18:00 |
| kmalloc | because this makes me want to push a change to squash all logging from oslo_context | 18:01 |
| kmalloc | by default | 18:01 |
| *** spilla has quit IRC | 18:15 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Allow wrap_member and wrap_collection to specify target https://review.openstack.org/589288 | 18:16 |
| *** spilla has joined #openstack-keystone | 18:25 | |
| *** fiddletwix has quit IRC | 18:37 | |
| *** fiddletwix has joined #openstack-keystone | 18:38 | |
| *** openstackgerrit has quit IRC | 18:49 | |
| lbragstad | kmalloc: i had a wip series of patches for that | 18:58 |
| lbragstad | https://review.openstack.org/#/c/551337/ | 18:59 |
| lbragstad | and https://review.openstack.org/#/c/551411/1 | 18:59 |
| *** s10 has joined #openstack-keystone | 19:17 | |
| lbragstad | kmalloc: i don't need to depend on https://review.openstack.org/#/c/589288/2 to convert the policy API? just https://review.openstack.org/#/c/589546/1 ? | 19:28 |
| orange_julius | So it doesn't look like HAProxy is forwarding the keystone authentication requests to all keystone controllers. I tested with a similiar configuration and saw an HTTP request hit just one HTTP server sitting behind haproxy with similiar configs | 19:35 |
| lbragstad | but the user is still getting locked out? | 19:40 |
| *** openstackgerrit has joined #openstack-keystone | 19:49 | |
| openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: Move _capture_stdout to a common place https://review.openstack.org/534440 | 19:49 |
| orange_julius | Yes the user is still getting locked out | 19:50 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Update release notes for the rocky release https://review.openstack.org/589578 | 19:52 |
| kmalloc | Yeah | 19:54 |
| kmalloc | lbragstad: just convert the api | 19:54 |
| lbragstad | ok - working on that now | 19:54 |
| kmalloc | lbragstad: and you can base on the patch preceeding that one you linked | 19:55 |
| kmalloc | The one that changes base_url and full_url | 19:55 |
| lbragstad | orange_julius: are your users in sql or ldap? | 19:56 |
| lbragstad | orange_julius: you're using the [security_compliance] section of keystone.conf, yeah? | 19:56 |
| orange_julius | Users are in active directory. Not using security_compliance. The only lockout policy is defined in active directory | 19:57 |
| lbragstad | ahh... | 19:57 |
| orange_julius | I see two possibilites. Let me know if I am wrong. Either a single keystone instance is sending multiple requests to AD, or all 3 keystone instances are seeing the login attempt and then asking AD for authorization | 19:58 |
| lbragstad | are you able to pin point which user is getting locked out? is it the user that's authenticating or the bind user being used to query ldap? | 19:58 |
| orange_julius | Its the user that is authenticating and its actually any user. We were able to replicate with my account (that sucked) | 19:59 |
| lbragstad | do you have a different value for that? | 19:59 |
| lbragstad | er - does your account have a different lockout setting? | 19:59 |
| orange_julius | No, its a "global" policy. 3 bad attempts | 20:00 |
| lbragstad | and just to confirm, this is what users are doing POST /v3/auth/tokens ? | 20:00 |
| lbragstad | s/what/when/ | 20:00 |
| orange_julius | Yes. well its through horizon and a POST /v3/auth/tokens is seen in the logs when they attempt. I believe we were seeing that come through the keystone.log on all three controllers | 20:00 |
| lbragstad | ok - that makes sense | 20:01 |
| lbragstad | horizon is building a request to keystone to get a token for the user trying to log in | 20:01 |
| lbragstad | and they are using usernames and passwords? | 20:01 |
| orange_julius | correct | 20:02 |
| *** raildo has quit IRC | 20:02 | |
| lbragstad | orange_julius: which release are you using? | 20:02 |
| lbragstad | master, queens, pike? | 20:02 |
| orange_julius | newton actually =( | 20:03 |
| lbragstad | oh ok | 20:03 |
| lbragstad | luckily, i don't think the ldap bits of the identity driver have changed drastically since then | 20:03 |
| orange_julius | We will be turning on verbose logging on keystone + ldap which will hopefully help identify the problem. For now we don't have a whole lot unfortunately. Its a "production" system so we can't bounce things without an approval process | 20:04 |
| orange_julius | That won't happen until Friday though | 20:04 |
| lbragstad | right now does the user just get an 'Invalid user / password' error? | 20:05 |
| orange_julius | Correct. They log into their windows workstation, go to horizon, fatfinger the horizon password, and then their AD account is locked out | 20:06 |
| orange_julius | and receive bad password on horiozn | 20:06 |
| orange_julius | horizon* | 20:06 |
| *** raildo has joined #openstack-keystone | 20:07 | |
| kmalloc | horizon might be making multiple attempts | 20:07 |
| kmalloc | fwiw | 20:07 |
| lbragstad | at a high level - we start getting into that logic here https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/core.py#L907 | 20:08 |
| lbragstad | which calls into the ldap specific implementation https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/backends/ldap/core.py#L60-L78 | 20:09 |
| lbragstad | and there are some common utilities for getting connections to ldap | 20:09 |
| lbragstad | https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/backends/ldap/common.py#L1214-L1238 | 20:09 |
| *** ckonstanski has joined #openstack-keystone | 20:10 | |
| lbragstad | but afaict, i just see one connection getting initiatied? | 20:10 |
| orange_julius | Sweet that is going to be very helpful. Horizon access logs only show up on the controller with the VIP which is only showing one POST to /dashboard/auth/login. | 20:11 |
| lbragstad | orange_julius: do you know if you're setting this in your deployment? | 20:13 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/conf/ldap.py#L409-L417 | 20:13 |
| orange_julius | No we are not. At least not explicitly | 20:13 |
| lbragstad | i wonder if that would have an impact | 20:13 |
| lbragstad | it attempts to reconnect 3 times before failing | 20:14 |
| lbragstad | if using connection pooling (which appears to be enabled by default) | 20:14 |
| lbragstad | so - if that's the case, that could be where your 3 attempts are getting used up | 20:14 |
| orange_julius | Would the fact that the POST to auth/tokens showing up on all controllers keystone.log indicate that keystone is probably making the request 3 times? one per controller node? | 20:14 |
| orange_julius | Wouldn't it only attempt to reconnect if it failed? | 20:14 |
| lbragstad | right - that's the part i'm curious about | 20:15 |
| lbragstad | if the password is wrong, are we attempting to reconnect? | 20:16 |
| lbragstad | and burning password attempts accidentally? | 20:16 |
| orange_julius | Ahh I see | 20:16 |
| orange_julius | So we could set that to... 50. and have our max lockouts be also set at 50 and receive the same result | 20:17 |
| lbragstad | orange_julius: do you have the ability to stand up a test node and point it to your adfs? | 20:17 |
| lbragstad | orange_julius: or just disable it.. | 20:17 |
| lbragstad | yes | 20:17 |
| orange_julius | I'll start standing up a test infra to validate. Won't be able to test disabling until Friday at the earliest | 20:18 |
| lbragstad | sure - that makes sense | 20:18 |
| lbragstad | just to be clear, i have no idea if this is actually the problem :) | 20:18 |
| lbragstad | but it looks suspicious | 20:18 |
| lbragstad | and might just be an unfortunate coincidence | 20:18 |
| lbragstad | that our default for that particular setting happens to match your lockout setting in AD | 20:19 |
| lbragstad | i guess if you have read access to your AD deployment, a single keystone node would be able to recreate this | 20:19 |
| lbragstad | by keeping those default set, and trying to authenticate using POST /v3/auth/tokens with the wrong password | 20:20 |
| orange_julius | No worries. Its worth investigating for sure. Is the retry logic around those links you sent earlier? I see it is supposed to raise an invalid credentials error, but not sure how that is handled | 20:20 |
| lbragstad | https://developer.openstack.org/api-ref/identity/v3/index.html#password-authentication-with-unscoped-authorization | 20:20 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.limit master: add python 3.6 unit test job https://review.openstack.org/589599 | 20:21 |
| openstackgerrit | Doug Hellmann proposed openstack/oslo.policy master: add python 3.6 unit test job https://review.openstack.org/589603 | 20:21 |
| lbragstad | we use another library for ldappool functionality, but i think if retries fail, that exception bubbles up to the user | 20:21 |
| lbragstad | https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/backends/ldap/common.py#L25 | 20:22 |
| lbragstad | https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/backends/ldap/common.py#L708-L716 | 20:23 |
| lbragstad | and we pass that configuration option into the constructor for that object https://github.com/openstack/keystone/blob/582cab391a10714a4ec8bab1a6cce9b49867f8d4/keystone/identity/backends/ldap/common.py#L711 | 20:24 |
| *** ckonstanski has left #openstack-keystone | 20:24 | |
| orange_julius | Ok thanks. I have some things to investigate =D | 20:27 |
| lbragstad | hopefully it helps | 20:27 |
| *** raildo has quit IRC | 20:28 | |
| lbragstad | i'm curious to know if that's actually the problem | 20:29 |
| *** hoonetorg has joined #openstack-keystone | 20:29 | |
| orange_julius | I will report back once I have the test case. | 20:30 |
| lbragstad | ++ | 20:30 |
| orange_julius | except ldap.LDAPError as error: I wonder if an ldap authentication error is of type LDAPError | 20:31 |
| orange_julius | HmmmmMMmMM | 20:31 |
| orange_julius | https://github.com/python-ldap/python-ldap/blob/e8cc39db0990bfb56e95c6ae1bd2f8be10e88683/Doc/reference/ldap.rst#exceptions | 20:36 |
| orange_julius | It is! | 20:36 |
| lbragstad | https://github.com/openstack/ldappool/blob/master/ldappool/__init__.py#L248-L265 | 20:37 |
| orange_julius | 248-https://git.openstack.org/cgit/openstack/ldappool/tree/ldappool/__init__.py#n248-265 | 20:37 |
| orange_julius | damnit bragstad | 20:37 |
| orange_julius | =P | 20:38 |
| orange_julius | Yea so that is totally what is happening right? LDAPError is the base class, so that exception will catch all errors including auths. ldappool will retry 3 times in .3 seconds and lock a user out instantly | 20:38 |
| lbragstad | it's looking to be more and more the case | 20:39 |
| lbragstad | totally and unfortunate combination of configuration options between two systems lol | 20:39 |
| orange_julius | haha | 20:39 |
| orange_julius | I'm just surprised this hasn't come up before | 20:39 |
| lbragstad | yeah... me, to | 20:39 |
| lbragstad | too* | 20:40 |
| lbragstad | but i guess it depends on what people are setting their locks out to on AD | 20:40 |
| lbragstad | if they set it to 5, then the likelihood of hitting this drops significantly (i would assume) | 20:40 |
| orange_julius | Yea seems like it. I'm going to set up a VM and play with the connection pooling settings to see if I can replicate. If I can... what do you want me to submit for this? | 20:42 |
| lbragstad | i mean - we could document this as a bug and just write down the coincidence and mark it as invalid | 20:42 |
| -openstackstatus- NOTICE: Due to a bug, Zuul has been unable to report on cherry-picked changes over the last 24 hours. This has now been fixed; if you encounter a cherry-picked change missing its results (or was unable to merge), please recheck now. | 20:42 | |
| lbragstad | that would make it discoverable in case other people are randomly hitting this | 20:43 |
| lbragstad | otherwise, i'm not sure we can adjust the defaults in keystone, just because what would you choose? | 20:43 |
| lbragstad | it becomes a guessing game as to what you'd expect a reasonable retry to be and assuming that's what people are doing | 20:44 |
| lbragstad | but the net would be | 20:44 |
| orange_julius | Well why would you ever retry on a bad password? | 20:44 |
| orange_julius | I guess that would be something for ldappool | 20:44 |
| lbragstad | right | 20:44 |
| lbragstad | you could teach ldappool to try and distinguish the difference | 20:44 |
| lbragstad | so - a bug to ldappool is probably more appropriate | 20:45 |
| orange_julius | I think getting it documented would be a great start. You are right, you can't increase the number of retries or you might break more people. 3 is fairly low already | 20:45 |
| *** nicolasbock has quit IRC | 20:45 | |
| lbragstad | we can just document the workaround in the ldappool bug | 20:46 |
| orange_julius | Sounds good to me | 20:46 |
| lbragstad | "if you're relying ldap to enforce user lock outs, just be sure to set retry_max to 0 until ldappool knows how to distinguish different authentication failure types" | 20:47 |
| orange_julius | (y) | 20:47 |
| lbragstad | otherwise you risk locking users out prematurely | 20:47 |
| orange_julius | You also could introduce strange behaviors which might have been masked by the retries, but its better than an instant lock out.. especially when people have to call to get their account unlocked =p | 20:48 |
| lbragstad | right - i can see that being totally frustrating | 20:49 |
| lbragstad | want me to open a bug or have you already started? | 20:49 |
| orange_julius | I can open it if you are busy, but I havn't started yet. | 20:50 |
| lbragstad | kmalloc: we're putting ldappool bugs here - yeah? https://bugs.launchpad.net/ldappool | 20:51 |
| kmalloc | kmalloc: i think so | 20:52 |
| kmalloc | kmalloc: i mean, that is where i'd put them ;) | 20:52 |
| lbragstad | me too, we just haven't had one opened yet ;) | 20:52 |
| orange_julius | oh man nice! A first! | 20:52 |
| * lbragstad cringes watching ldappool paint suffer it's first scratch | 20:53 | |
| lbragstad | i'll leave the honors to orange_julius heh | 20:54 |
| orange_julius | Maybe I'm just dumb, but I don't see a button to report bugs. Its usually on the far rightyea? | 20:58 |
| lbragstad | https://bugs.launchpad.net/ldappool/+filebug | 20:58 |
| orange_julius | w00t thanks | 20:59 |
| lbragstad | you should see a Report Bug hiding in the upper right corning of the page | 20:59 |
| orange_julius | Thanks for helping troubleshoot this lbragstad. Much appreciated | 21:09 |
| orange_julius | Submitted: https://bugs.launchpad.net/ldappool/+bug/1785898 | 21:10 |
| openstack | Launchpad bug 1785898 in ldappool "Connection Pooling Retries Failed Passwords" [Undecided,New] | 21:10 |
| orange_julius | I had to reallllly restrain myself from putting "first" somewhere in there =P | 21:10 |
| *** spilla has quit IRC | 21:12 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert regions API to flask native dispatching https://review.openstack.org/589640 | 21:15 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert services api to flask native dispatching https://review.openstack.org/589641 | 21:15 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert endpoints api to flask native dispatching https://review.openstack.org/589642 | 21:15 |
| kmalloc | lbragstad: ^ annnnnnnnd there is another subsystem done. | 21:15 |
| kmalloc | lbragstad: i.. i think we're down to the "really hard"(tm) ones | 21:15 |
| lbragstad | sweet | 21:24 |
| lbragstad | orange_julius: anytime - i'll wait to confirm the bug once we know it's recreateable with your system | 21:24 |
| *** edmondsw has quit IRC | 21:29 | |
| orange_julius | Sounds good. I'll probably get around to reproducing tomorrow in a test environment and then hopefully we can our change request approved for Friday. Once I confirm it there I'll update the bug | 21:29 |
| orange_julius | hopefully we can get our change request approved** | 21:30 |
| lbragstad | ++ | 21:32 |
| *** spilla has joined #openstack-keystone | 21:33 | |
| *** rcernin has joined #openstack-keystone | 22:20 | |
| *** spilla has quit IRC | 22:50 | |
| *** edmondsw has joined #openstack-keystone | 22:54 | |
| *** edmondsw has quit IRC | 22:59 | |
| *** _ix has quit IRC | 23:05 | |
| openstackgerrit | Merged openstack/keystone master: Convert OS-AUTH1 paths to flask dispatching https://review.openstack.org/588064 | 23:16 |
| *** s10 has quit IRC | 23:37 | |
| *** s10 has joined #openstack-keystone | 23:38 | |
| *** s10 has quit IRC | 23:38 | |
| *** s10 has joined #openstack-keystone | 23:39 | |
| *** s10 has quit IRC | 23:39 | |
| *** s10 has joined #openstack-keystone | 23:39 | |
| *** s10 has quit IRC | 23:40 | |
| *** s10 has joined #openstack-keystone | 23:40 | |
| *** s10 has quit IRC | 23:41 | |
| *** s10 has joined #openstack-keystone | 23:41 | |
| *** s10 has quit IRC | 23:41 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert regions API to flask native dispatching https://review.openstack.org/589640 | 23:53 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert services api to flask native dispatching https://review.openstack.org/589641 | 23:54 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert services api to flask native dispatching https://review.openstack.org/589641 | 23:54 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
