AuthenticationContext with MFA

Andrew Morgan morgan at orst.edu
Wed Aug 16 15:30:55 EDT 2017


On Fri, 11 Aug 2017, Cantor, Scott wrote:

> On 8/11/17, 5:37 PM, "users on behalf of Eric Goodman" 
> <users-bounces at shibboleth.net on behalf of Eric.Goodman at ucop.edu> wrote:
>
>> I'd love to hear any statistics on this you come across. I'd like to 
>> recommend that we return the MFA context whenever it's used as long as 
>> it doesn't violate the request (i.e., if they ask for PPT return PPT, 
>> if the ask for MFA or unspecified return MFA), probably with some 
>> flag/mechanism to override for any (hopefully few) broken SPs. But I'd 
>> also like to know if that would end up being a recommendation for a DoA 
>> approach.
>
> I certainly am returning the MFA value, and I've yet to run into 
> anything that broke, so I definitely wouldn't call it a DOA approach. 
> It's been over a year now.
>
> I don't think there's any particularly easy way to override this in a 
> fine grained way, what you'd pretty much have to do is forcibly set a 
> defaultAuthenticationMethod for the broken SP(s) to get them to 
> effectively request something else.

We went live with Duo for a few pilot users yesterday.  Today, we 
discovered they couldn't login to Webex.  :)

Webex doesn't send an authContextClassRef in the SAML request, but it 
checks for a (configurable) list of them in the SAML response.  Our Duo 
users were able to authenticate again after I updated the Webex config to:

   urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport;https://refeds.org/profile/mfa

It takes a semicolon separated list of authContextClassRefs.

We considered setting the defaultAuthenticationMethod for Webex in 
relying-party.xml, but this seems more correct.

Thanks,
 	Andy


More information about the users mailing list