SessionInitiator triggering and return

[Cantor, Scott]

> I am configuring some advanced uses of multiple session types at the SP and
> I need to trigger different SessionInitiators based on different links at the SP.
> This is more than a discovery service because I might already have a session,
> but then will need to trigger another session from another source to provide
> additional data.

That's not a use case it supports. It doesn't understand multiple sessions on any level. If you have one, you have one.

> The first thing I thought should work, but didn't, was to use the following:
> <Location /myapp/Demo/LoginType2>
>     AuthType shibboleth
>     ShibRequestSetting applicationId its-admin-workstations
>     ShibRequestSetting requireSessionWith sessioninit-login-type-2
>     ShibRequestSetting requireSession true

There's no reason to ever have both of those, they would just stomp on each other. I'm not sure if it will honor the first one at all, but either way the first one would trump the second or vice versa. It's also not really needed much any more because you can set an entityID as a content setting, and because it doesn't do what you're thinking it does here.

> This apache rule set works fine to initiate the session if there is not already a
> session.  However, if there is already a session which was triggered under a
> different SessionInitiator, this rule is ignored even though it should be
> required to have a session under the SessionInitiator with the indicated
> identifier.

That isn't what it means. Sessions aren't tied to a session initiator. All it means is "if a session doesn't exist, require one, and initiate it with this plugin chain".

> I already found the workaround to go ahead and use the initiator location
> specified using the handlerURL plus the Location value.

Well, that works from an application layer piece of code, yes.

> However...  when I started using this method to trigger a session, I need it to
> return to a specific target URL at the SP when the session has been
> processed.  Luckily (I thought), there is an option for this which I thought was
> supposed to be "target" on the SessionInitiator config.

That should have worked.

> Using "target" did not achieve what appears to be the description on the
> SessionInitiator wiki page, which seems to be to act like an override to the
> homeURL setting.  Instead, I found that the target setting actually changed
> the handlerURL and my IdP began to reject requests because it was being
> asked to return attributes to an unregistered ACS URL.

That probably means you tried to specify a target on a different vhost from any that you have endpoints registered on. It computes the endpoint to use based on the vhost of the resource you're coming back to, because if it didn't, it couldn't possibly work (absent cookies with shared domains).

> Is there a correct way to override the homeURL setting on a per-
> SessionInitiator basis?

As long as its within a vhost that has endpoints in the metadata, it would work.

-- Scott