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