MCB SSO not requiring greater authentication methods

[Caskey, Paul]

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:unspeci
> 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:Previou
> 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