Shibboleth Developers

["Scott Cantor" <>]

> The wording of my question regarding the EntityID for the WAYF was
> certainly horrific.  I was referring to a comment I noticed in the
> shibboleth2.xml configuration file.  Clearly I misinterpreted the comment:
> 
>  <!-- An example using an old-style WAYF, which means Shib 1 only unless
> an entityID is provided. -->

The comment isn't clear at all. It's referring to the overall chain inside
that set. Generally SessionInitiators run in a chain that represents a
protocol precedence policy. You stack a set of protocol initiators first, in
the order you want them, and then end with a discovery handler (WAYF or DS)
that will catch any cases where no entityID is provided.

The comment is trying to say that the chain in that case means "uses only
Shibboleth 1.x IdPs unless an explicit entityID is provided that supports
SAML 2.0". Meaning that if you have to drop through to the WAYF handler, it
will send the user away from the SP and the only outcome in that case would
be a Shib/SAML1 response unless the WAYF has atypical capabilities.

An entityID can be supplied (to bypass discovery) by passing it in a request
to the initiator endpoint, setting it in the RequestMap based on the URL, or
hardcoding it in the SessionInitiator element. In that event, discovery
handlers never run because the entityID is known. Either a supported IdP
will be found in the metadata and a request made, or it falls through and
fails.

The examples in the file at the moment are supposed to offer what I thought
were the common (or new) cases of "use a fixed IdP", "use a WAYF", or "use a
DS".

It's all backward compatible with everything the old SP does, it's just more
flexible and decomposed into simpler plugins that only do one piece.

-- Scott