MCB SSO not requiring greater authentication methods

[Paul Hethmon]

> On Apr 8, 2015, at 4:31 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 4/8/15, 8:11 PM, "Ho, PeiQuan" <PeiQuan.Ho at tufts.edu> wrote:
> 
> 
> 
>>               We’re working on getting Shibboleth to work with the MCB 
>> here at Tufts.  Recently we noticed an issue where if a user has logged 
>> into an SP where the attributeResolverID for the MCB returns 
>> username/password, the user logs in fine.  But then if the same user logs 
>> into an SP where the attributeResolverID for the MCB returns DUO 2-factor 
>> authentication, the IDP does not go forward and require the two-factor 
>> and just lets the user into the SP.
> 
> I'm not going to speak for the MCB, but what you're describing in the 
> abstract is simply wrong. The attribute being resolved has nothing to do 
> with the SP, it's about the user's ability to use other methods in 
> general. If the SP doesn't request anything in particular, the existing 
> password authentication context is perfectly acceptable, and the MCB 
> *should* do exactly what you described.
> 

You’re not going to get different behavior based on returning a different set of allowed contexts. That data is per user, not per user per SP. So once it’s resolved, those are the values that are used. Since the user is allowed username/password, that context will be used for any SP that sends it in its request (or doesn’t send any context).

Paul


-----
Paul Hethmon
Chief Software Architect
paul.hethmon at clareitysecurity.com