ApplicationOverride and sessionHook

[Cantor, Scott]

On 11/25/14, 6:08 PM, "Jeff Hall" <jefhall at lexmark.com> wrote:


>
>Our situation: we have three sites all (roughly) using the same SP and 
>IdP. Two of the sites need to invoke a sessionHook as part of a 
>provisioning/account validation process, but one of them should not.

A first step is to question why you're using overrides. What is the use 
case that you think requires them?

>  Originally, we tried to accomplish this by setting the sessionHook at 
>the applicationDefaults element level and "blanking out" the session hook 
>on a applicationOverride element. Apache uses ShibRequestSetting 
>applicationId xxx to invoke the desired "application" ... but all three 
>sites would use the sessionHook without respect to the override

Because the settings are inherited, there's no way to "remove" a setting 
defined as a default unless it's just changed to something else. Of course 
a simple workaround to that for the hook use case is to have a hook that 
does nothing but redirect back.

>In a different attempt, we removed the sessionHook directive from 
>applicationDefaults and tried to specify it in two different 
>applicationOverrides, leaving it unspecified in the third.  This also 
>didn't function as intended ... none of the sites would invoke 
>sessionHook.

Then you had an override configuration bug, which is why you really 
shouldn't use them to begin with in most cases. But that's the solution, 
not to rely on defaults and always map to an override. If the hook wasn't 
invoked, the SAML handler/endpoint requests were not being mapped to the 
override.

>We're running SP 2.5.3 in Apache. Any thoughts? Can I provide more/better 
>information?

Mainly the use case. There's essentially only one good reason to use 
overrides, to assign a different entityID to different vhosts.

-- Scott