-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance to work with OIDC Authentication #1649
Comments
I was initially thinking of protecting ui/service under OIDC (web redirects with Apache config changes ManageIQ/manageiq-appliance#287), even if we fetched the X-Remote-User and related headers, this is not going to help us. Since we're running as an SPA, the API calls are going through Apache (not on server side locally), so sending any of those headers will be ignored, essentially rendering any API calls from SUI unauthorized. Unless we have the Apache/IDP fetch an access token for the SPA in the headers, not even sure if this is even an option generally, the next solution is to support resource owner password grant authentication in Apache for the API, see lower priority issue in ManageIQ/manageiq#19867, with this we'd be able to do basic auth with the API, which will just have the SUI work with OIDC with no change. Not web SSO like classic, but users will be able to enter their OIDC IDP credentials in the SUI login screen. /cc @himdel |
Thanks @chessbyte for adding me to the discussion! In our sandbox implementation, the authentication process is indeed handled at the Apache level (using apache2 mod_auth_openidc module with Keycloak as an IDP) exactly as for the admin UI (as described in the official documentation). So we do are using X-Remote-User and related headers in the SUI (in the authentication-api.factory.js). It might look quite tinkered, but it is working. Don't hesitate if you have any question. |
Ok, beating my head on this a bit more, it's actually a lot simpler than I thought for Jansa. Once you protect a page with OIDC, i.e.:
The redirect that occurs from the IDP (Keycloak in this case) to the protected page actually includes the access token for the authenticated user. We receive the OIDC access_token as
The SUI can simply use that access token (if there) to target the /api/auth with that access token as a Bearer authorization:
To get the API token for that user, without having to show the login screen in the SUI giving us OIDC SSO and no changes needed in the API for this. The SUI login would still need to trigger the /oidc_login/redirect_uri?logout=https:/..../ui/service |
We may still need to enhance the /api/product_info endpoint similar to @guilrom did in Plemi/manageiq-api@d2a25af#diff-0ef0779741ad3209b46314a66c353351 to expose the current authentication settings needed for the SUI to drive the login screen logic if no HTTPD_OIDC_ACCESS_TOKEN is found, i.e. present the Login to corporate system button or just redirect automatically if enable sso is checked. |
Moved to OP |
Need to add the following to the OP - I can't edit it. |
And related documentation ... |
sorry, closed too soon, I guess |
Related PRs/Issues:
The text was updated successfully, but these errors were encountered: