[Ext] Re: Forcing Duo by Service Provider

[Bryan Wooten]

This has been an interesting conversation.

But in my opinion requiring MFA for some apps and not others is just added complication to the underlying issue that passwords alone are insufficient for all access.

I believe it just adds to user confusion and more help desk calls.

We went from 1k users using MFA to over 30k in 6 weeks. All employees are required to use MFA for all Web apps whether the app is SaaS / SAML or in house CAS.

But this is a policy decision not a technical one. Policy decisions can create technical complexity.

I used to work for Novell, the inventor of NetWare (Drew Major)  once said “minimal but sufficient” was a guiding motto.

-B

From: Michael Grady <mgrady at unicon.net<mailto:mgrady at unicon.net>>
Reply-To: "users at shibboleth.net<mailto:users at shibboleth.net>" <users at shibboleth.net<mailto:users at shibboleth.net>>
Date: Friday, March 31, 2017 at 3:48 PM
To: "users at shibboleth.net<mailto:users at shibboleth.net>" <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: [Ext] Re: Forcing Duo by Service Provider


On Mar 31, 2017, at 4:39 PM, Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:

On 3/31/17, 5:31 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of mgrady at unicon.net<mailto:mgrady at unicon.net>> wrote:

To ensure you get an "entityID" whether a SAML or CAS service, you need to get it this way currently in a scripted attribute: That
reminds me we need to create an issue to ask that resolutionContext.getAttributeRecipientID() is populated for CAS also.

Are you sure it's not? The ResolverAttributes action isn't SAML-specific, and if the relyingPartyId field you referenced accessing is set, that should be copied over into the AttributeRecipientId during normal attribute resolution.

If you're talking routine attribute resolution, it should be set for CAS. If you're talking MFA, *you* have to set it for either SAML or CAS, or anything else, it's literally using whatever you tell it to use.

-- Scott


We had an email chain back in mid-February on this, where it was noted that Marvin wasn't populating resolution context for CAS, and to create an Issue for that. Which I just (finally) did. From back in mid-February:

On Tue, Feb 14, 2017 at 2:29 PM Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:
That's probably something Marvin could fix depending on how/when it's invoking it. Josh's workaround is the same place the SAML flows populate the resolution context from.

Yes, should be straightforward. File an issue and I'll attempt to make it work like the SAML flows.

Best,
Marvin

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170331/39a3c0d8/attachment-0001.html>