authn context comparison per relying party

[Scott Cantor]

Mike covered the issues well. Salesforce is broken and not compliant with SAML or OpenID in a number of ways without even getting into the question of what PHR even means. It is not allowed to substring match things the way they are doing. it's a hack in the face of them realizing you can't do what they want to do across a set of non-cooperating IdPs.

All I'll say is that with the Shibboleth hat on, the idea is you define additional AC class ref Principals as supported and asserted and then you satisfy different SPs needs with them at the same time. If need be, the weight map will help prioritize them, but it can't create them nor suppress them, you have to implement the configuration you need for that, which in the case of Duo generally means separate integrations that would lead to different Principal sets, much as is demonstrated in the HowTo I wrote around REFEDS MFA usage.

With a REFEDS hat on as a participant in the WG(s), the original REFEDS MFA profile was not meant to be phishing resistant to the level that Salesforce is thinking about and that others have started to coalesce around. There is a second, new REFEDS MFA profile for that that adds a second context class for those cases.

Actually preventing misuse of all those when using Duo? That's out of scope, but it is very non-trivial without having pretty limited rules in place for factors, turning off Remember Me, etc.

We extended the plugin to include some code to help with using their new AMR claim from Duo to help drive production of particular Principals on the Shibboleth IdP end.

-- Scott