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