Bug 1884233

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