MCB SSO not requiring greater authentication methods

[Caskey, Paul]

If it is the SP that knows whether the user has opted-in, then it is in the best position to request the authn method.  I presume that the user can opt-in to some SPs, but not all...

So, apps would set authnContextClassRef in the login URL dynamically, based on whether or not the user has opted-in.

But, that's not saying you're wrong in how you want to do it, just presenting an alternative.


> -----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:14 AM
> To: Shib Users
> Subject: RE: MCB SSO not requiring greater authentication methods
> 
> 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/NativeSPSessionInitia
> tor#NativeSPSessionInitiator-CommonAttributes
> 
> For URL examples:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreat
> ionParameters
> 
> 
> > -----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
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net