Bug in SP evaluation of nested Path statements?

[Michael W. Brogan]

Scott,

Thanks for the help. The reason for the application override is to force a user with an existing session back to the authentication system to challenge them for a second factor (hw token in this case) when they either request a confidential resource or they attempt a privileged operation such as impersonation of another user in an app. Maybe there are better ways to do this, but this method has been working so far.

The previously omitted override section looks like this:

<!-- Step-up 2-factor for diafine3 -->
<ApplicationOverride id="stepup2f">
    <Sessions lifetime="28800" timeout="3600" checkAddress="false"
                handlerURL="/stepup/Shibboleth.sso" handlerSSL="false" >
        <SessionInitiator type="Chaining" Location="/SecureLogin" isDefault="false" id="uwtoken"
                 relayState="cookie" entityID="urn:mace:incommon:washington.edu"
                 authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken" >
            <SessionInitiator type="SAML2" template="bindingTemplate.html"/>
        </SessionInitiator>
    </Sessions>
</ApplicationOverride>

As you suggested, the problem was that both /stepup and /test/stepup were referencing the same application override. Originally it appeared that both paths worked properly and that commenting out the /stepup path broke the /test/stepup path, thus my question. In reality, /test/stepup wasn't really working. The failure was disguised by cashing issues on my test pages.

Each path has its own application override now and everything is working.

--Michael



-----Original Message-----
From: dev-bounces at shibboleth.net<mailto:dev-bounces at shibboleth.net> [mailto:dev-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, January 06, 2012 2:33 PM
To: Shib Dev
Subject: Re: Bug in SP evaluation of nested Path statements?

Please direct follow up to users (Outlook won't let me, so just advising)...

On 1/6/12 5:22 PM, "Michael W. Brogan" <mbrogan at u.washington.edu<mailto:mbrogan at u.washington.edu>> wrote:

>I have a Shib SP configuration that isn¹t working as I expect it to.

Your issue is improper set up of the overrides, not the request map itself. When you play with path-based overrides the usual outcome is pain and agony, but that aside, you MUST follow the rule the documentation tries to make explicit:

The handleURL for an override MUST map in the RequestMap to the overridden applicationId. Yours is probably not in at least one of the cases you're trying because you're flipping it between /path and /test/path.

I don't now what your handlerURL is overridden to be, it's not in your message, but it's the underlying problem, it doesn't map to the right applicationId in the case that results in the message.

As a related point, you almost never need overrides if entityID isn't overridden, and the best starting point might be to explain what you need it for and see if you really do.

-- Scott

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net<mailto:dev-unsubscribe at shibboleth.net>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120109/0428dfb2/attachment.html