Open abellotti opened 4 years ago
One thing to note is that if central admin requests are initiated from a UI session, there may not be a JWT to use, so we may need to take the userid in the miqtoken on the receiving api at face value (i.e. taking the stored info from the user object) and forgo the authorization for OIDC.
Just a note (so I don't forget). The need for this issue is because the current implementation for Central Admin token authorization leverage DBUS which is not available in the OIDC configuration.
This is the code segment that currently implements the authorization for the Central Admin case https://github.com/ManageIQ/manageiq/blob/master/app/models/authenticator/httpd.rb#L138-L173
Correct, Central Admin was tested with external auth using IPA, so all wired up with SSSD and DBUS which we used the DBUS API to fetch information about the passed in userid.
I thought central admin used a system token... Are you expecting to create a jwt token from the system token or something? I'm not sure I follow how or why system tokens will or won't work.
Central admin uses a system token (MiqServer, userid and Timestamp), the API re-authorizes the userid on the receiving end, this fetches any user info (or update) to the user including group membership. This capability (authorize only) was added at some point because requests coming in from the global to one of the subregion where the user never logged into would fail as the user object was not there, the user can now be created there with trusted information from the IDP. With MiqLdap, and the External-Auth with DBUS/SSSD, we can query the IDP for the information. With OIDC and SAML this is not possible. For OIDC, while we can support JWT, we cannot require it for central admin as it may not be there in a UI session. One option is to include the user metadata in the system token for allowing us to recreate the user object if needed.
Sorry for the long explanation (took a while to remember the scenario).
Come to think of it, bundling the user metadata with the system token, would enable the authorize only scenario for SAML too.
This issue corresponds with the manageiq-api issue:
Add support for region to region system tokens for OIDC #844
Minor update to above, API system token enhancement tracked here: https://github.com/ManageIQ/manageiq-api/issues/842
@abellotti so is this issue resolved via https://github.com/ManageIQ/manageiq-api/issues/842 ?
This issue https://github.com/ManageIQ/manageiq-api-client/issues/91 is unrelated to/not solved with https://github.com/ManageIQ/manageiq-api/issues/842.
842 enhanced our system token to work with OIDC and SAML to region to region operations will with OIDC (where we don't necessarily have a JWT token when using the UI). This issue 91, allows one to use the API client if they had a JWT token.
With the enhancement in the core API to support OIDC authentication with Access tokens via the Authorization Bearer Header, the API Client needs to support the same so we can enable Central admin via OIDC.
Current ManageIQ::API::Client.new supports,
We need to add support for:
which can be specified alone or in addition to an miqtoken and group.
/cc @Fryguy @jvlcek