ApplicationOverride and sessionHook
cantor.2 at osu.edu
Tue Nov 25 21:24:40 EST 2014
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
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
>We're running SP 2.5.3 in Apache. Any thoughts? Can I provide more/better
Mainly the use case. There's essentially only one good reason to use
overrides, to assign a different entityID to different vhosts.
More information about the users