MCB SSO not requiring greater authentication methods

[Ho, PeiQuan]

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.

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 11:33 AM
To: Shib Users
Subject: RE: MCB SSO not requiring greater authentication methods

At some point, this should be as easy as specifying the authn method in your relying-party.xml file (no need for scripted attribute), but that isn't yet working in the MCB - there's a bug filed for it.

Any MCB folks want to weigh in on a) what's the best version of the MCB to be running and b) if/when there will be another release of the MCB?





> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Ho, PeiQuan
> Sent: Friday, April 10, 2015 10:29 AM
> To: Shib Users
> Subject: RE: MCB SSO not requiring greater authentication methods
> 
> We are using two test SPs that are practically identical except for the entityID
> passed to the IDP.  They even use the same wildcard cert.  Not sure if that
> has any effect.  Also, we're using version 1.2.2 of the MCB as distributed
> here:
> 
> https://github.com/Internet2/Shibboleth-Multi-Context-
> Broker/tree/master/distribution
> 
> Maybe we should update to the latest version....
> 
> 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 11:09 AM
> To: Shib Users
> Subject: RE: MCB SSO not requiring greater authentication methods
> 
> No, that's OK to keep in that section.
> 
> Just make sure you are using a different SP.  If it's the same SP, you have to
> use ApplicationOverride to trigger a new session at the SP for the app that
> requires 2-factor.
> 
> Otherwise, it's some config issue in the MCB because step-up is definitely a
> capability that the MCB has, although I think there were some bugs present
> in some versions.
> 
> >From what I know, the issue8 version of the MCB is the best
> (https://github.com/langedb/Shibboleth-Multi-Context-Broker/tree/issue-
> 8), but I'd love to know the real truth on that.  Seems like development of
> the MCB has stalled for a while now.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: users-bounces at shibboleth.net [mailto:users-
> > bounces at shibboleth.net] On Behalf Of Ho, PeiQuan
> > Sent: Friday, April 10, 2015 9:48 AM
> > To: Shib Users
> > Subject: RE: MCB SSO not requiring greater authentication methods
> >
> > Yes I have.   But the MCB documentation suggests something such as
> below
> > in the handler.xml file, which has the PreviousSession as the last item.
> > Should I remove that?
> >
> > <ph:LoginHandler xsi:type="mcb:MultiContextBroker"
> > authenticationDuration="PT4H0M0.000S" previousSession="true"
> > depends-on="mcb.Configuration">
> >
> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspec
> > i
> > fied</ph:AuthenticationMethod>
> >
> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Passwo
> > rd</ph:AuthenticationMethod>
> >
> <ph:AuthenticationMethod>http://id.incommon.org/assurance/bronze</ph
> > :AuthenticationMethod>
> >
> <ph:AuthenticationMethod>http://id.incommon.org/assurance/silver</ph:
> > AuthenticationMethod>
> >
> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Passwo
> > rdProtectedTransport</ph:AuthenticationMethod>
> >
> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSy
> > ncToken</ph:AuthenticationMethod>
> >
> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:OTPDev
> > ice</ph:AuthenticationMethod>
> > <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Previo
> > u sSession</ph:AuthenticationMethod></ph:Login
> >  Handler>
> >
> > 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 10:44 AM
> > To: users at shibboleth.net
> > Subject: RE: MCB SSO not requiring greater authentication methods
> >
> > Did you disable/comment out the PreviousSession LoginHandler in
> > handler.xml?
> >
> >
> >
> >
> > Sent from phone
> >
> > -----Original Message-----
> > From: Ho, PeiQuan [PeiQuan.Ho at tufts.edu]
> > Received: Friday, 10 Apr 2015, 9:11AM
> > To: Shib Users [users at shibboleth.net]
> > Subject: RE: MCB SSO not requiring greater authentication methods
> >
> > This is what I'm currently doing.   I'm using a scripted attribute resolver call
> > "authContext" that is determine by checking the value of the SP ID and
> > another value for the user.  This value is then passed to the MCB as
> > its attributeResolverID which I thought would then set the MCB
> > authnContext to the one specified by the authContext generated value.
> > Currently, this does work.  It just doesn't work when doing SSO...
> > such as when I first go to an SP that the MCB determines to only
> > require password, then go to a second SP that the MCB determines
> > requires two-factor, the second SP does not force the two-factor step.
> > Is this do-able with Shib and MCB?  We're currently using shib IDP 2.4.1.
> >
> > Thanks,
> > -PQ
> >
> > -----Original Message-----
> > From: users-bounces at shibboleth.net [mailto:users-
> > bounces at shibboleth.net] On Behalf Of Cantor, Scott
> > Sent: Thursday, April 09, 2015 12:40 PM
> > To: Shib Users
> > Subject: Re: MCB SSO not requiring greater authentication methods
> >
> > On 4/9/15, 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?
> >
> > It depends on whether/how the MCB populates the resolution context
> > that ends up in the scripting layer with that information or not. It's
> > not the IdP- proper running the resolver in this case, it's a sort of
> > extra resolver invocation with a fair amount of mocked up context, at
> > least if it's done how that sort of thing usually gets done with the old APIs.
> >
> > -- Scott
> >
> > --
> > 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
> --
> 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