| opendevreview | Tatsuya Hayashino proposed openstack/keystoneauth master: Output verification_uri_complete as stderr https://review.opendev.org/c/openstack/keystoneauth/+/907775 | 01:39 |
|---|---|---|
| opendevreview | Tatsuya Hayashino proposed openstack/keystoneauth master: Output verification_uri_complete as stderr https://review.opendev.org/c/openstack/keystoneauth/+/907775 | 01:53 |
| *** mhen_ is now known as mhen | 02:57 | |
| opendevreview | Ayumu Ueha proposed openstack/keystonemiddleware master: Add FT for External OAuth2.0 Server Support https://review.opendev.org/c/openstack/keystonemiddleware/+/899911 | 04:15 |
| opendevreview | Tatsuya Hayashino proposed openstack/keystoneauth master: Output verification_uri_complete by logger https://review.opendev.org/c/openstack/keystoneauth/+/907775 | 05:54 |
| WJeffs7 | Morning, I was wondering just a simple question, is an application credential created by a user with a "member" role tied to a project or that user? So on the user being removed the application ID is removed? | 10:38 |
| gtema | wjeffs7 - yes. Application credentials are tied to the user and are dropped with user being deleted | 10:39 |
| WJeffs7 | gtema - what is the best practise around creating a project application account/ID for some automation procedures? Are people creating manual accounts for this? | 10:41 |
| gtema | application credentials is still a best choice. What you mentioned is a safety measure to prevent people leaving company continue using app creds | 10:42 |
| gtema | of course you are also free to create "regular" machine accounts | 10:42 |
| gtema | but that would eventually bite on the password expiration rules | 10:43 |
| gtema | and MFA | 10:43 |
| WJeffs7 | indeed, for my side its just about advising them currently how to do it better, and their reply is if X leaves we loose our application creds - so how do we maintain that, so they want local accounts..... | 10:44 |
| gtema | before person leaves the company new creds must be created by staying user | 10:44 |
| WJeffs7 | this is exactly my feelings too, its part of product handover procedure. | 10:45 |
| gtema | right | 10:45 |
| WJeffs7 | An application ID can't be migrated between users, and should be recreated with the new user | 10:46 |
| gtema | right - a new creds must be created | 10:47 |
| WJeffs7 | Perfect confirmed exactly what I was thinking and recommending :) Thanks | 10:47 |
| gtema | welcom | 10:47 |
| *** tobias-urdin7 is now known as tobias-urdin | 14:07 | |
| nazan | Hello I want to do SAML integration in OpenStack keystone. How can SAML integration be done? How can I use Application credential and OpenStack CLI with SAML-OpenStack integration? Environment version openstack:stein keystone: 15.0.1-0ubuntu1~cloud0 keystone federation: SAML Authentication Flows: SAML2.0 WebSSO Apache authentication method: Mellon | 14:11 |
| gtema | nazan - you should read https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html for details | 14:14 |
| gtema | the interactive (webbrowser) auth for CLI is not present and not going to be present in the OpenStackClient anytime soon, but I am working currentl on alternative for that | 14:16 |
| *** tobias-urdin0 is now known as tobias-urdin | 14:20 | |
| nazan | Hi gtema I already on below links; https://docs.openstack.org/keystone/latest/admin/federation/introduction.html https://docs.openstack.org/keystone/pike/advanced-topics/federation/configure_federation.html https://docs.openstack.org/keystone/pike/admin/federated-identity.html https://docs.openstack.org/keystone/pike/advanced-topics/federation/mapping_combinations.html We can also use a different method instead of websso. Our only purpose i | 14:35 |
| nazan | We can also use a different method instead of websso. Our only purpose is to use cli and application credentials with SAML. My env; SP: OpenStack IDP: Cyberark | 14:36 |
| gtema | app credentials should not be affected with federation. | 14:37 |
| gtema | the only thing what I can imagine can go wrong is the user_id in the federated case which you "may use" for searching app creds | 14:38 |
| nazan | I'm currently using both keystone and saml. Keystone local user can create app cred in the same openstack, but saml federation user cannot use both cli and app cred. Error same as Unable to create application credentials | 14:41 |
| nazan | If you used Saml Federation Openstack, can you send me the config details? I don't know where the mistake . I can also share it with you via e-mail. | 14:43 |
| gtema | that means that the user your mapping does not allow federated users to create app creds (roles missing) | 14:44 |
| nazan | I created a group in Openstack, then I created a group in Active Directory and allowed the group in the relevant project. When you log in, it is created under the federated user group. openstack group create test openstack role add --group test --project Train _member_ | 14:46 |
| nazan | The user under the test group can log in to Openstack UI. There is no problem with the UI, there is a problem with the CLI and application cred. If there was an authorization problem, I would not be able to log in from the UI. | 14:47 |
| jrosser | gtema: there are a bunch of keystone cli + web browser auth things on GitHub from various organisations who want that enough to make their own extension, is there ever going to be a way to support that directly rather than needing a 3rd party plugin? | 14:48 |
| jrosser | we are one of those - and use keystone + keycloak + pkce for cli auth flow with a local browser | 14:49 |
| gtema | not a single one of those mentioned organizations tried to make this part of the OSC itself (not going to blame too much due to current OSC constraints). OSC in its current form will most likely not get the browser based auth anytime soon due to the way how auth is being treated under the hood. As said, I am working on that and there are just too many obstacles around | 14:54 |
| jrosser | I was told that contributions to keystone for this were not welcome because the whole SSO part was to be rewritten | 14:56 |
| nazan | https://docs.openstack.org/keystone/stein/admin/federation/configure_federation.html This document says that CLI can be used with ECP, but I have not tested it yet because Cyberark SOAP could not produce metadata. I requested this from the global team. But I couldn't find a solution for application cred. | 14:56 |
| gtema | :) you can read the OAuth2 and OpenIDConnect RFCs and I think you understand how many things are really understood under that. It is just impossible to implement everything properly. | 14:58 |
| gtema | jrosser: wrt federation - we are currently working on making possible to have ephemeral users belong to different domains (and not only to the single one) with support for dynamic roles/projects assignments | 14:59 |
| jrosser | I believe that there have recently been patches for pkce to keystone in other contexts | 14:59 |
| gtema | and while working on this also looking on how the CLI can be made usable | 14:59 |
| jrosser | that makes the size of the patch to support cli even smaller | 15:00 |
| gtema | definitely not. "Just" enabling web flow in cli is only tiny bit of usability. It just insane without any reasonable caching | 15:01 |
| jrosser | then I guess I don’t understand what the 3rd party extensions are doing wrong | 15:02 |
| gtema | show me one pls | 15:02 |
| nazan | Have you used cyberark? cyberark:identity provider | 15:03 |
| gtema | hear it first time ever | 15:03 |
| nazan | Do you think SAML federation supports CLI and app cred? | 15:04 |
| jrosser | gtema: an example would be https://github.com/IFCA-Advanced-Computing/keystoneauth-oidc | 15:04 |
| gtema | looks interesting. If only ever somebody from them has ever raised that to upstream. But anyway there is one problem: every invocation will lead to reauth | 15:06 |
| gtema | I tried recently to combine all my issues with auth in cli world of OpenStack (https://gtema.github.io/posts/rethinking_openstack_client_auth/) | 15:07 |
| jrosser | the way we use that is to issue a token | 15:11 |
| jrosser | once that is done there is no need to re-auth until the token expires and you are free to let loose with terraform or whatever else tooling you need | 15:12 |
| jrosser | that’s not our code, we use a fork/derivative of that and during the period we were implementing SSO I offered engineering effort to keystone to port the concepts into keystoneauth | 15:13 |
| jrosser | and unless I’m totally missing the point I don’t observe the issues you describe on GitHub when using tools like ansible | 15:17 |
| nazan | !logs | 15:32 |
| opendevmeet | nazan: Error: "logs" is not a valid command. | 15:32 |
| nazan | logs | 15:32 |
| nazan_ | The chat connection has been lost. How can I access past records? | 15:36 |
| nazan_ | HISTORY #channel | 17:57 |
| tkajinam | nazan_, https://meetings.opendev.org/irclogs/%23openstack-keystone/ ? | 17:59 |
| nazan_ | I was disconnected. I wrote for saml today, but I can't see past logs. | 18:05 |
| nazan_ | thanks tkajinam I see now | 18:06 |
| nazan_ | I need to discuss the issue with someone who uses the saml protocol. | 18:11 |
| opendevreview | Douglas Mendizábal proposed openstack/keystone master: Enable protection jobs https://review.opendev.org/c/openstack/keystone/+/909238 | 19:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!