map OIDC ACRs to SAML authnContexts in proxied authentication?

I removed the Principal type downcasting in the add ACRs handler. There was only one type coming through from the default lookup function in this case, but this allows custom functions to work as expected (and to future-proof against changes to the default function).

Makes sense. I will add a ticket to commons tomorrow and change that to Principal (same as your commit).

The only place I left in the assumption about the Principal type was in the metadata-driven config wiring, it has to have a concrete class to use to wrap strings from a metadata tag and create the Principals to return. But when the objects just come directly in, I fixed the SAML and CAS cases to accept them as is.

What I think we need to do is fix all those implementations (as I just did) to use Principal alone and stop screwing with the types. That interferes with all the mapping logic essentially and it matches the actual contract of the getter on the interface.

The calling code already had to accept that because that was the return type on AuthenticationProfileConfiguration, but of course there may be assumptions made that weren’t strictly correct in doing that.

Correction, in the RP’s case, it is using the OIDC commons interface AuthenticationProfileConfiguration. The default implementation of this, namely;AbstractOAuth2ClientAuthenticableProfileConfiguration, limits the result to AuthenticationContextClassReferencePrincipal. Although the ones that are passed through if no mapping exists are those type—before they just get converted to an ACR string list.