idp 4 upgrade, tuning MFA implementation

[Cantor, Scott]

On 4/23/20, 8:50 PM, "users on behalf of Paul B. Henson" <users-bounces at shibboleth.net on behalf of henson at cpp.edu> wrote:

> Basically, I would like a reuseCondition which says "if a user actually did MFA the last time through, this can be reused as
> is, otherwise it needs to be run again to determine if they have to do MFA this time". If someone has an established
> session that already did MFA, there is currently no need to check anything, they are good to go for whatever service
> they are trying to access. But if they didn't do MFA, they might either need to do it (if it has been enabled for them since
> this authentication) or be denied access to something.

My way of doing this is generally to carefull stick to making sure that the resulting Principal set in each result always accurately reflects what methods the user did, so if I wanted to check later to see what happened, I could just scan the Subject for an AuthnContextClassRefPrincipal of a certain value.

Diving in deeper into the Subject will give you access to the AuthenticationResultPrincipals, which are the "subresults" inside the MFA result carrying the individual results that were done previously. But that's more complex IMHO than just relying on the class refs.

> On the relying party side, I could use the defaultAuthenticationMethods override such that the entityid's in question
> would require the appropriate MFA context. However, it seems that would also require using the disallowedFeatures
> override to prevent an SP from actually requesting a specific context, and I've seen complaints that this can sometimes
> cause interoperability issues with SP's. Also, I don't think it can be used for CAS services?

I believe it works for CAS if you want it to, and I can't say I've had a ton of problems with it. If the SP is making requests I just tell it to stop. If you're already invoking the MFA method anyway though, you don't really need to "cause" that to happen in a new way. The override could have nothing in it, just a way of grouping the services under a special RelyingPartyConfiguration with an ID that you can check for in your script later to know that it was one of those IDs. The RelyingPartyContext has the configuration object, which has the ID field.

> So instead I was considering using metadata entity attributes, with the EntityAttributes filter to set them for SP's in
> federation metadata, and adding them by hand to ad hoc peer to peer SP's and CAS services (CAS metadata can have 
> entity attributes? I don't see anywhere saying it can, but I don't see anywhere saying it can't).

They can. All you'd be doing though is repeating the same logic that the RelyingPartyByTag override method is doing for you, so I think it's easier to just let the RP resolver handle it for you.

> Finally, if someone might also be kind enough to point me to an example or documentation on how to go about looking > up what metadata entity attributes exist for the relying party in the MFA check script?

There's an example of it in the ActivationConditions page under Relying Party By Tag.

-- Scott