MCB SSO not requiring greater authentication methods

[Caskey, Paul]

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