Forcing Duo by Service Provider

[Michael A Grady]

> On Mar 31, 2017, at 4:39 PM, Cantor, Scott <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 on behalf of 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/7d133853/attachment.html>