Hi Lennart!

I actually don't know how to solve your problem, but would like to warn you regarding a bug/security issue that we have discovered when service providers (or OIDC clients) are using forcedAuthn and users are authenticating at external IDP.

Note: we have forcedauthn set on external IDP, so this is not same issue as yours, but maybe this info can save you some gray hair.

Hypothetical situation:

• User A needs access to AM and authenticates (regardless how - local or external IDP)

Then imagine that User B comes to this computer and User A has not properly logged out/closed the browser (this customer is using shared computers).

1. User B tries to access Service provider with forcedauthn enabled
2. User B is redirected to Access Manager login page, where selects authentication with external IDP
3. User B is redirected to External IDP where successfully authenticates
4. User B is redirected back to AM with SAML token from external IDP
5. AM generates token for Service Provider, but this token is for User A
6. User A is logged in to Service provider

You can imagine a confusion since forcedauthn is normally used as a security measure to be absolutely sure that correct user is logging in.

Looking at debug traces, it looks like error happens in step 4 where AM gets SAML token from external IDP and just decides that "user is logged in" and does not even try to do a matching to determine that wrong user is logged in.

Please note that this does not happen if User B authenticates with local authentication.

Kind regards,

Sebastijan

Hello Sebastijan,

that we actually seen in real life at one of our customers. We raised a SR for that, I don't really recall how it was solved, will see if I can find something in my archives

/Lennart

I would appreciate any information you have