application override not working on some clients

[Archuleta, Marc]

> I would start by eliminating all uses of the RequestMap. This is Apache, so you have no reason to be using it, and if your Apache configuration is off in some way, that's possibly related to the problem.
>>Htaccess file contents for the resource:

>>ShibApplicationId virtual

>That should be all that's needed in a <Location /> block for the virtual host to set the override.

Thanks Scott, this is very helpful. Our Shibboleth2.xml had been on an IIS machine before my time and so I think that's why we had path statements in the RequestMap element. I've now commented out the RequestMap section, removed the .htaccess file and have created <Location> blocks in the apache config as such:
<Location /path/to/secure/resource>
        ShibRequestSetting applicationId default
        AuthType Shibboleth
        ShibRequestSetting requireSession On
        Require shibboleth
</Location>
<Location /path/to/secure/resource>
        ShibRequestSetting applicationId <vhostappid>
        AuthType Shibboleth
        ShibRequestSetting requireSession On
        Require shibboleth
</Location>

The main <www> host and the second <vhostnamehere> host have both been registered with the idP. I've also removed the <Session> element from the ApplicationOverride and tested our existing protected resources.  Everything is working as it had before but I still find it the second <vhostappid> item hanging on my android phone so I presume that will be the case for the others that encountered this problem.

Could there be any other remnant configurations from IIS that would cause this? What can I try next?

Marc


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, June 05, 2014 4:49 PM
To: Shib Users
Subject: Re: application override not working on some clients

On 6/5/14, 4:38 PM, "Archuleta, Marc" <archuleta.2 at osu.edu> wrote:
>
>I suspect the issue is related to my configuration of the 
>ApplicationOverride host, but my understanding is that this behavior is 
>symptomatic of a cookie issue. I've copied and pasted my configurations 
>below. I'd love to trace the cookies but I'm not sure how to do that on 
>my android phone. I do have access to one of the people who has a mac 
>on a limited basis, so I'll try to get fiddler on his machine and 
>figure out how I can see what cookies are being set when I can meet 
>with him. In the meantime, I hope someone can suggest some things to 
>check with my configuration to try to resolve the issue.

I would start by eliminating all uses of the RequestMap. This is Apache, so you have no reason to be using it, and if your Apache configuration is off in some way, that's possibly related to the problem.

>Htaccess file contents for the resource:

>ShibApplicationId virtual

That should be all that's needed in a <Location /> block for the virtual host to set the override.

However, why are you using overrides at all? For what purpose?

><ApplicationOverride id="virtual"
>entityID="https://virtual.psy.ohio-state.edu/shibboleth">
>                <Sessions lifetime="28800" timeout="3600"
>checkAddress="false"
>                handlerURL="/Shibboleth.sso" handlerSSL="true"
>cookieProps="https" />
></ApplicationOverride>

You don't need a Sessions element there, but more to the point, all you're doing is setting up a second entityID, and that entityID isn't one that you've been assigned (by me), so I suspect you are confused about the need for an override here at all.

If you're hosting a different service on the box, and need a second entityID to distinguish it, that's ok, but I would start by leaving that out, registering the additional vhost for the existing entityID (that's between you and webauth-admin at OSU), and yank all of that extra complexity. At least until there aren't any cookie problems, and then revisit.

But you can't just make up an entityID. It's not a location, and using one that isn't registered with the IdP in question will just fail anyway. So you're on the wrong track there.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net