MCB SSO not requiring greater authentication methods

[Ho, PeiQuan]

First, I can't say I'm too familiar with Shibboleth or MCB.  But, what we're looking to do is have SPs point to an IDP and then the IDP will choose an authentication method to use for the SP based on a calculated value.  The value is the attributeResolverID attribute which the MCB then uses to determine the authentication method.  Currently this works in cases where the user logs into the SP directly, but when the user does an SSO connection on another SP handled by the same IDP, it does not check whether the authentication level is sufficient enough to log into the SP.  I don't know if the MCB has this functionally, but I thought that was the idea behind it.  Can you please clarify if not, or if there are other ways we can achieve this?

Thanks,
-PQ

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Wednesday, April 08, 2015 4:41 PM
To: Shibboleth Users
Subject: Re: MCB SSO not requiring greater authentication methods

> 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


-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net