idp 4 upgrade, tuning MFA implementation

[Paul B. Henson]

Our current campus policy for MFA opportunistically uses MFA for all SSO services if a user has it available, and then optionally requires MFA for certain services such that a user without MFA is unable to access those and receives an explanatory error instead, and finally requires MFA for all services for some users such that if they don't have MFA they can't get into anything.

We currently have a checkSecondFactor script in the MFA config that accomplishes this by looking up a few attributes for the authenticating user and having a hardcoded list of entity-id's of services that strictly require MFA.

While this is currently functional, I was hoping to tune this to be a bit more efficient as part of our migration to idp 4.

We have been using the reuseCondition parameter for the MFA flow, hardcoded to false. While reviewing documentation, I found the comment "if you can include at least some of your logic in the reuse condition rather than the MFA logic itself, that can improve efficiency" and thought that I certainly could do that, if I could figure out how :).

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.

I'm sure a scripted check for this would be simple to write for someone that knows all of the Java classes like the back of their hand :), but I haven't found an example that seems similar to this and was hoping someone would be kind enough to point me in the right direction.

Second, it is annoying to have a hardcoded list of entity-id's in the MFA configuration, as that cannot be dynamically reloaded :(. I'd like to move that out to a different configuration section that can be reloaded, either relying party or metadata.

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?

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).

We standardized on the https://refeds.org/profile/mfa authentication context for signaling MFA, would it be okay to do something like this:

<mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Attribute Name="https://refeds.org/profile/mfa" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>1</saml:AttributeValue>
    </saml:Attribute>
</mdattr:EntityAttributes>

Or is that abusing the name and I should make something up in our own domain?

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? I already have a RelyingPartyContext I'm using to get the id:

	rpid = rpCtx.getRelyingPartyId();

I thought the metadata/entity attributes might be somewhere in there, but I don't see them in the documentation unless I'm missing something:

https://build.shibboleth.net/nexus/service/local/repositories/site/content/java-identity-provider/4.0.0/apidocs/net/shibboleth/idp/profile/context/RelyingPartyContext.html#getConfiguration()

Thanks much...

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768