Disable SSO for Specific SP?

[Timo Tunturi]

On 28/04/2017 18.50, Cantor, Scott wrote:
> On 4/28/17, 11:42 AM, "users on behalf of Timo Tunturi" <users-bounces at shibboleth.net on behalf of timo.tunturi at aalto.fi> wrote:
>> A client browser already has a valid global IdP session with a lower
>> grade authentication method. How can I disregard that session on the IdP
>> side for specific SPs and require them to to authenticate again with a
>> different method? Any pointer would be nice.
> 
> By specifying a defaultAuthenticationMethods property in a relying-party override, and appropriately configuring all the various pieces to handle the right supported custom AuthnContextClassRefPrincipals so that the system will invoke the proper authentication logic at the right times, generally with the MFA flow to orchestrate things.

Doesn't seem to be working for me. I tried it before asking.

---clip---
         <bean parent="RelyingPartyByName" c:relyingPartyIds="SP_entityID">
             <property name="profileConfigurations">
                 <list>
                     <bean parent="SAML2.SSO" 
p:postAuthenticationFlows="attribute-release" p:signResponses="false" 
p:signAssertions="true" p:encryptAssertions="false"
 
p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT"
 
p:defaultAuthenticationMethods-ref="StepupSAML2Principal" />
                 </list>
             </property>
         </bean>
---clip---

The entityID is valid, though obfuscated, for being discrete. It would 
be a dead giveaway as to which company's service/product we are talking 
about.

The above config works swimmingly as long as the client browser does not 
have a session with the IdP yet. The correct authentication method is 
invoked.

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.

> The SP can deny access but it's an application function to route such a denial into logic that would cause a new session to be requested. It's also possible to use ApplicationOverrides to handle that case.

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.

>> Having exhausted my understanding with configuring the SP, the
>> authentication context class apache httpd env variable isn't available
>> during rewrite phase even with look-ahead.
> 
> It isn't there early enough for that, that's not how Apache works.

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.

-- Timo Tunturi