requiring 2FA for a service (Shibboleth 2 & MCB) (update)

[Michael A Grady]

> On Oct 16, 2015, at 8:03 PM, IAM David Bantz <dabantz at alaska.edu> wrote:
> 
> In the relying-party.xml config for the SP I want to use 2FA,
> I set defaultAuthenticationMethod to designate our Duo 2FA context rather than usual PPT:
> 
> from:
>     defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
> to:
>     defaultAuthenticationMethod="https://iam.alaska.edu/trac/wiki/mfa <https://iam.alaska.edu/trac/wiki/mfa>"
> 
> Unfortunately, users not explicitly provisioned Duo 2FA context simply authenticate with password instead.
> 
> Is there some MFB configuration that could avoid that - could enforce 2FA or deny if the user cannot use 2FA?
> 
> [AWS alas is accessed via unsolicited SSO request.  While I can write the request to ask for 2FA context, it would of course be trivial for someone to write their own request dropping that part of the request and thus gain access with just PPT.  So I need some way of
> enforcing use of 2FA. If I cannot do that with some combination of metadata, relying-party, and mcb configuration, I'm thinking I 
> could conditionally release required attributes based on AuthenticationMethodString in the attribute-filter.xml; that would drop the user into an AWS session, but with no roles to accomplish anything.]

That would indeed be an approach (using AuthenticationMethodString in your filter file) you can take full control over, and, as you say, at least "somewhat inhibit" the integration if your desired authn context/method did not occur. Of course, the other approach would be for the SP to enforce the authn context, but you don't control that side for this integration.

What I think is becoming more clear is that there are a number of "edge cases" where the combo of Shib IdPv2/MCB is not easy to ensure the behavior you desire. Another problem that I don't think got fixed (not sure) is that the user attribute did not get re-computed for each time, meaning that if you had that attributes's value set dependent on the SP asking, a new value wasn't being taken into account if there was already a satisfactory SSO session established.

That makes it time to consider Shib IdPv3 (which, of course, you want to be looking at for lots of reasons at this point). While there isn't a "perfect story" yet for integrating additional factors, there's a reasonable story that already works, and active work to evolve that closer to "perfect". (For some definition of "perfect"? :-) As edge cases arise, there is active discussion and work to deal with those.


--
Michael A. Grady
IAM Architect, Unicon, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151018/993a2e3e/attachment.html>