AuthenticationContext with MFA
Andrew Morgan
morgan at orst.edu
Thu Aug 10 16:05:26 EDT 2017
On Thu, 10 Aug 2017, Cantor, Scott wrote:
>> Why doesn't it return the "http://id.incommon.org/assurance/mfa"
>> authContext in this case?
>
> If the request or defaultAuthenticationMethods property doesn't
> specifically express a requirement, then the result of any given request
> will be legally anything from the set contained in the result, and
> generally that's going to be pretty arbitrary. There's a "weight map"
> feature inside general-authn.xml that teaches the system to favor some
> values over others in an arbitrary comparison to work around that.
That worked great. I used:
<util:map id="shibboleth.AuthenticationPrincipalWeightMap">
<entry>
<key>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="https://refeds.org/profile/mfa" />
</key>
<value>2</value>
</entry>
<entry>
<key>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
</key>
<value>1</value>
</entry>
</util:map>
A couple follow-up questions:
1. If an SP explicitly requests PasswordProtectedTransport, will the IDP
still return PasswordProtectedTransport even if password+Duo is performed?
The comments in general-authn.xml say so.
2. Will SPs have a problem if they get https://refeds.org/profile/mfa in
the SAML response when they haven't requested a specific
AuthnContextClassRef? I realize this is not really a technical question.
I'm just curious if there are known bad SPs that are going to barf if they
don't see a well-known AuthnContextClassRef, such as
PasswordProtectedTransport, in the response.
Thanks,
Andy
More information about the users
mailing list