MCB SSO not requiring greater authentication methods

[Ho, PeiQuan]

Wouldn't that be a static value though?  We need the SP that has opt-in two-factor to present either password, or for opted-in users two-factor.  

Also, we didn't really want to do this configuring at the SP level because that would mean all our existing SPs have to be reconfigured to desired auth method.  That's why we're looking to see if we can take care of it at one IDP with MCB.

Thanks,
-PQ


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Caskey, Paul
Sent: Friday, April 10, 2015 12:08 PM
To: Shib Users
Subject: RE: MCB SSO not requiring greater authentication methods

The SP can set authnContextClassRef in the SesionInitiator (either in config or in the URL) -- more info here:

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionInitiator#NativeSPSessionInitiator-CommonAttributes

For URL examples: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters


> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Ho, PeiQuan
> Sent: Friday, April 10, 2015 11:03 AM
> To: Shib Users
> Subject: RE: MCB SSO not requiring greater authentication methods
> 
> In the way you suggested, how would the SP know which auth method the
> user should use and dynamically send a different one to the IDP?
> 
> The way we have our IDP setup is we have a backend DB that has a lookup
> table for the SPs.  If the table says the SP requires two-factor, or if the SP
> offers opt-in and the user has opt-in, the MCB theoretically should two-
> factor the user.
> 
> Thanks,
> -PQ
> 
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Paul Hethmon
> Sent: Friday, April 10, 2015 11:56 AM
> To: Shibboleth Users
> Subject: Re: MCB SSO not requiring greater authentication methods
> 
> The correct (and easiest) way to do that is to have the SP request it. Either
> initially or it could send the user back to the IdP with the higher context value
> to “upgrade” their authentication.
> 
> The MCB does a lot, but it can’t mind read the SP.
> 
> > On Apr 10, 2015, at 11:47 AM, Ho, PeiQuan <PeiQuan.Ho at tufts.edu>
> wrote:
> >
> > The reason we are using a scripted attribute is because we want to give the
> SP the option of offering user opt-in two-factor.  We maintain the user opt-in
> information in the backend and the IDP needs to determine the value for
> each SP and user before deciding which authentication method to present.
> 
> -----
> 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