MCB SSO not requiring greater authentication methods

[Caskey, Paul]

See 'SAMLMessageContext' here: https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinition#ResolverScriptAttributeDefinition-InformationAvailabletotheScript





> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Hong Ye
> Sent: Thursday, April 09, 2015 11:52 AM
> To: Shib Users
> Subject: Re: MCB SSO not requiring greater authentication methods
> 
> 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
> 
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net