Disable SSO for Specific SP?

Cantor, Scott cantor.2 at osu.edu
Sat Apr 29 11:33:03 EDT 2017


On 4/28/17, 12:18 PM, "users on behalf of Timo Tunturi" <users-bounces at shibboleth.net on behalf of timo.tunturi at aalto.fi> wrote:

> p:defaultAuthenticationMethods-ref="StepupSAML2Principal" />

I'd be surprised if that worked, but Spring does some odd conversions and if it doesn't crash I guess it must. In any case, you don't show what that references, but the problem you're having is fundamentally misconfiguring your login flows. You also didn't explain what your login methods methods *are* and how they actually are intended to interact. Anything that's second-factor-only like Duo or U2F essentially has to be wired together with the first factor and scripted into correct behavior with the MFA flow, which you didn't indicate if you're using.

> However, the defaultAuthenticationMethods (asked from the SP side or 
> configured as above on the IdP) only works if there is no IdP session 
> yet. If a session with another auth method exists, it is used instead 
> for SSO.

Then you have configured the original login flow with a supportedPrincipals collection that include the value you're using in that Stepup principal.
 
> Yes. This is what I found to be the case. I can get a nice denial but 
> not the SP to ask the IdP to reauth to fulfill the same requirement.

Apache can handle errors of specific types with custom handling which you could use to route back into your application to allow it to detect the situation and invoke the SP to request a new session.

> I am not particularly knowledgeable about what exactly look-aheads 
> (LA-U-definitions) execute to do what they do. I know that auth layer 
> stuff should not be available, but look-aheads looked enticing enough 
> based on the documentation. If the SP session is there I didn't think it 
> would be a far reach.

The SP *is* auth layer, so it can't be making anything available that early.

-- Scott




More information about the users mailing list