MCB SSO not requiring greater authentication methods

[Hong Ye]

Hi Paul,

How to get SP’s entityID in resolver? Is there any document for that?

Thanks,
Hong

On Apr 9, 2015, at 12:33 PM, Caskey, Paul <pcaskey at utsystem.edu> wrote:

> Please correct if I'm wrong, but you could use a scripted attribute definition in the resolver for your MCB/assurance attribute and it would see the SP's ID and could just not issue 'password' as an acceptable method for that user in the case where you want to force 2-factor, correct?
> 
> 
> 
>> -----Original Message-----
>> From: users-bounces at shibboleth.net [mailto:users-
>> bounces at shibboleth.net] On Behalf Of Paul Hethmon
>> Sent: Thursday, April 09, 2015 10:47 AM
>> To: Shibboleth Users
>> Subject: Re: MCB SSO not requiring greater authentication methods
>> 
>> 
>>> On Apr 9, 2015, at 11:27 AM, Ho, PeiQuan <PeiQuan.Ho at tufts.edu> wrote:
>>> 
>>> 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?
>> 
>> MCB will look up a value for each user based on the resolver configuration
>> that lists the allowed context values for a user. That lookup is a normal
>> attribute resolver process. So the values returned to it will be effectively
>> static. What ever mechanism is used to acquire the value, the only thing it will
>> get from Shib/MCB is the user’s principal identity. Nothing about which SP
>> they are trying to access.
>> 
>> So, let’s say your user receives a value that indicates context values of
>> “password” and “token” are allowed. Typically the initial authentication for
>> the user would have been at the lowest context level (like password), so
>> assume “password” has been satisfied. If the SP requests the “password”
>> context then everything is done and the SAML response is sent to the SP. If
>> the SP doesn’t specify, then they get password as well. If a second SP the
>> user accesses specifies password or does not specify, then SSO works and
>> they get the same context value used. If a third SP says “token” is required,
>> then the MCB will force the user to upgrade their authentication to “token”
>> level.
>> 
>> That’s the basics of what it does. The Shibboleth wiki under the contributions
>> section has several pages on what it does and a list of test cases that might
>> help your understanding.
>> 
>> 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
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net