Add support for mapping proxied Attribute into issued AuthnContext

, I added a utility class that will make this a matter of some Spring bean definitions to plugin, but only into 4.1 so if you have a test system you want to trial something with I can write up an example to try.

My intention was make use of the existing SimpleAttributePredicate to evaluate a specific attribute/value to check for, and then map that to a constant collection of objects to populate. So should just be wiring, I don't think a script will be necessary.

Since the function here ultimately comes from the ProfileConfiguration, probably I would need to define a second slot for that, perhaps getAuthnContextTranslationStrategyEx, and make that version fully generic using the PRC as input and then probably just supply an example that can be applied. I don't think it's fair to make life hard for people using non-broken IdPs.

On the subject of portability, the signature of the mapping function is a Function<AuthnContext,Collection<Principal>>, making it generic on the mapped side to anything, not just SAML context classes.

Unfortunately that signature also is too limiting to allow for other inputs, it was only meant to deal with AuthnContext elements since that's exactly what SAML requires be used.

I don't know yet how to extend this while not breaking anything. A more generic input could work but would be a breaking change.

If the acr were used, then the existing machinery should work already with just the addition of new mappings in the table. What MS is doing in OIDC terms would be like passing it as a custom claim instead of via the acr, so it requires a different sort of rule.

I'll make sure the original mapping logic is generic, it's supposed to be but it might have been coded to be AuthnContextClassRef-specific.

Thanks for tracking this a few days ago. I was going to add this in as an RFE and will tag on to this as 'yes, this please.'

For more detail:

When an additional factor is used in Azure AD, the claim 'http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod'

is set to Value = "http://schemas.microsoft.com/claims/multipleauthn"

The desire is to ingest this claim during proxying practice and then adjust the AuthNContext accordingly.

A mapping table of attributes,their values, and transitions to which context would be useful to permit things being adjusted.

It may also be useful to signal that the authentication context is being materially changed somehow as a way to instrument or diagnose the behaviour to ensure it's in alignment with expectations and testing.

While these two links are for adfs, they lend insight to the MFA/practices around additional factors:

https://docs.microsoft.com/en-us/archive/blogs/ramical/under-the-hood-tour-on-multi-factor-authentication-in-adfs-part-1-policy

and

https://www.enowsoftware.com/solutions-engine/ad-fs-claims-rules-and-modern-authentication

Forward looking, if inbound requests could be OIDC (plausible?) the technique to observe/ingest the inbound OIDC claim may be useful as well but by no means necessary for this feature request. 

It appears the OIDC there may be value in techniques to ingest the 'acr' claim and it's value :

https://openid.net/specs/openid-connect-core-1_0.html#acrSemantics

**https://openid.net/specs/openid-connect-modrna-authentication-1_0.html#acr_values

https://stackoverflow.com/questions/52632690/can-someone-explain-acr-return-values-in-oidc

While I'm really reaching on this part, I wanted to bring it up if it influences the design/implementation decisions.

Thanks for tracking this item. the Azure AD SAML claims influencing the outbound Shib IDP claim is key. An inbound OIDC use of acr and influencing outbound SAML proxied claim is entirely optional.