Description of problem: After configuring RHV to use RH-SSO as authentication source a login with a user from that source is reported with a missleading domain: "User <user>@openidc-authz connecting from 'xxx.xxx.xxx.xxx' using session..." This message should read: "User <user>@openidchttp connecting from 'xxx.xxx.xxx.xxx' using session..." Version-Release number of selected component (if applicable): ovirt-engine-4.3.10.4-0.1.el7.noarch How reproducible: Always Steps to Reproduce: 1. Enable RH-SSO for RHV 2. Login as RH-SSO provided user 3. See missleading messages in engine.log and UI events. Actual results: "User <user>@openidc-authz connecting from 'xxx.xxx.xxx.xxx' using session..." Is reported Expected results: "User <user>@openidchttp connecting from 'xxx.xxx.xxx.xxx' using session..." Or whatever ovirt.engine.aaa.authn.profile.name is configured. Additional info:
After successful login all users within RHV are identified as <USERNAME>@<PROFILE NAME>. This is by design, because: 1. You may have several authn instances connected to single authz instance 2. At authorization phase we don't care which instance authenticated the user There is no difference in that approach between internal RHV SSO implentation and delegated SSO (like RH SSO). As you mentioned above user correctly identified as <USERNAME>@<PROFILE NAME>, so closing as NOTABUG
Hi Martin, I have to re-open, as the messages clearly state something different. My login profile was reported as "openidc-authz". while the name for this was "openidchttp". # cat /etc/ovirt-engine/extensions.d/openidc-authn.properties ovirt.engine.extension.name = openidc-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.misc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.misc.http.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = openidchttp <== this *should* be reported ovirt.engine.aaa.authn.authz.plugin = openidc-authz <== this is reported ovirt.engine.aaa.authn.mapping.plugin = openidc-http-mapping config.artifact.name = HEADER config.artifact.arg = OIDC_CLAIM_preferred_username If that only applies to RH-SSO, than this should be treated differently. Currently a user expects that the username reported in the logs and events would also qualify as a valid login - which it clearly does not and is a bug IMHO. Best regards, /Andreas
OK, let's investigate. We should aim for consistency and have the same behavior in RHV SSO and delegated SSO usecases
Still seeing: User user1@openidc-authz connecting from 'ip' using session 'token' logged in. in events even though there is clearly set openidchttp as profile name in authn.conf Seeing this on ovirt-engine-4.4.5-0.11.el8ev.noarch however the same appeared on ovirt-engine-4.4.4.7-0.1.el8ev.noarch Only mention of openidchttp is in log: 2021-01-15 16:00:29,614+01 INFO [org.ovirt.engine.core.sso.service.NegotiateAuthService] (default task-28) [] User user1@openidc-authz with profile [openidchttp] successfully logged in with scopes : ovirt-app-admin ovirt-app-api ovirt-app-portal ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access
(In reply to Petr Matyáš from comment #9) > Still seeing: > User user1@openidc-authz connecting from 'ip' using session 'token' logged > in. > in events even though there is clearly set openidchttp as profile name in > authn.conf > > Seeing this on ovirt-engine-4.4.5-0.11.el8ev.noarch however the same > appeared on ovirt-engine-4.4.4.7-0.1.el8ev.noarch > > Only mention of openidchttp is in log: > 2021-01-15 16:00:29,614+01 INFO > [org.ovirt.engine.core.sso.service.NegotiateAuthService] (default task-28) > [] User user1@openidc-authz with profile [openidchttp] successfully logged > in with scopes : ovirt-app-admin ovirt-app-api ovirt-app-portal > ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all > ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search > ovirt-ext=token-info:validate ovirt-ext=token:password-access That is actually an expected behaviour. It is done this way because at that point profile is irrelevant. Profile is being used only during the sso authentication process and once it is over, username@<one_of_the_possible_multiple_profiles> is resolved to unique username@authz. IMO that makes sense because in audit log there is only one user reference everywhere ie. jbond.uk instead of jbond, jbond or jbond depending who is he actually simultaneously impersonating. Please let me know if you still have some objections before moving it to QA again.
One view is expected behavior for the developer and another one for the reporter, in this case I would like to hear if this is enough for the reporter. For me this works and doesn't break anything and thus OK from my point of view, although I can see that nothing (almost) has changed and it might not be enough for the reporter.
(In reply to Petr Matyáš from comment #11) > One view is expected behavior for the developer and another one for the > reporter, in this case I would like to hear if this is enough for the > reporter. > For me this works and doesn't break anything and thus OK from my point of > view, although I can see that nothing (almost) has changed and it might not > be enough for the reporter. The biggest and most visible change is that after successful login user will see username@autzhname in top right corner (previously was username@profile). Additionally, engine.log will contain profile and authz for authentication/login/logout flow. During the implementation we had in mind introducing consistency and verbosity where possible and that was provided with the best effort taking into account existing limitations.
user1@openidc-authz in the events is fine for me. I stumbled upon the missleading messages during debug of RH-SSO integration and for that specific scenario, one will take a look at the engine.log rather than the events-tab. So having the proper OIDC-name in engine.log and also in the top right corner is absolutely fine for me. Thanks for solving that issue.
Well, in top right corner this is showing authz.name for all extensions now. Profile is shown only in engine log.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1169