SessionInitiator equivalent of SSO

[Matt MacAdam]

Thanks, Scott.

I also discovered that the <SSO> element is responsible for all the
ACS endpoints being created locally.  If I take out <SSO> and just
have a SessionInitiator, I have to manually create the endpoints with
<md:AssertionConsumerService.... />.

At least that's what I observed while helping out one of our users
here--I could be misinterpreting something.  *If* I'm correct...I
assume the <SSO> element registers whatever is listed in
protocols.xml?

For the curious...this all started because Word handles links in
documents partly through an internal browser and often breaks SSO.
One of our users wanted to fix this, and was using a workaround
published at:

https://admin.kuleuven.be/icts/services/aai/documentation/sp/linksfromofficetosp.html

It works, but you have to either keep the <SSO> element, or create the
ACS endpoints manually (blech).

Thanks everyone,

-----
Matt MacAdam
Identity & Access Management Specialist
UW Information Technology
206-616-9842


On Fri, Nov 21, 2014 at 1:40 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/21/14, 9:26 PM, "Matt MacAdam" <mattjm at uw.edu> wrote:
>
>>What's the equivalent in a SessionInitiator element?   That is, which
>>attributes of SessionInitiator are given default values (and what are
>>the values?) when using the SSO element?
>
> It installs a chain of them with the protocols identified. All the
> properties you set are set on each of the chained plugins, so they have
> the same meaning/use. You can in general set anything that you can set on
> those older elements and they'll be picked up, or ignored, as the case may
> be.
>
>>But, looking at the settings for, say, the SAML2 SessionInitiator,
>>it's still not entirely clear what attributes are set, and what their
>>values are (the docs give some hints, however).
>
> The probable answer is that it's not set. I don't know which ones you're
> wondering about, but setting entityID basically sets, well, entityID.
> That's it. The rest are not set or defaulted.
>
>>I can consistently set up working SessionInitiator elements, but it's
>>not entirely clear to me in what ways they may differ in functionality
>>from the SSO elements.
>
> There are few cases where it would ever make sense to do them anymore
> unless you're using plugins other than Shib1, SAML2, WAYF, or SAMLDS.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net