Shibboleth Developers

["Howard Gilbert" <>]

> Is the value of the shire parameter always the same for a given SP
> shire=https://sp.com/shibboleth/SSO
> or does it depend on the profile used

Maybe neither. Let me try a different cut at it.

[The following is a more complete statement of an alternate view based on
the code and standards. I believe that it is an admissible view (it doesn't
contradict a standard or break any existing implementation). It may not,
however, be shared by everyone.]

The HS generates an Authentication Assertion and sends it as a SAML Reply in
POST data. There never was a SAML request per se. However, this Reply is in
response to a Redirect that started at the Resource Manager and may have
passed through the WAYF. So in a sense, the shire, target, and providerId
parameters are part of the implied "Request" carried in the Redirect itself.

The AA gets a SAML request and generates a reply. It knows to reply to the
source of the request, and may (or may not) check that source in Metadata to
verify that it is permitted to make the request. The HS doesn't get a
request directly, so it either has to get the reply destination from the
Redirect parameters or the Metadata.

The problem is that the SAML 2 Metadata doesn't constrain any Entity (Site)
to have unique anything. There can be multiple Roles, and each role can have
multiple types. Even the Shibboleth 1.2 Metadata allows multiples.

More than one AA might provide load balancing or fail over, just like having
a primary and backup DNS name server. If you can have more than one server,
you sure as hell can have more than one requester of a service.

Thus, there can be more than one SHIRE in an SP.

The most obvious example is when an institution will deploy both the
existing C++ SP for Apache and IIS resources, and the Java SP for Servlet
resources. At this point, are there two SP's?

Yes if you look at the code. There are two different sets of objects with
separate state maybe on different machines.

Not necessarily if you look at the Metadata and Trust. Both SHIREs could be
configured in the same Metadata and, if they are administered by the same
people, they could clearly share the same keys. There is nothing in the
schema or standard that says that there is only one SHIRE, or even only one
Authentication Consumer with the same profile.

At the standards level, this is one SP. The implementation is an internal
matter outside the standard. For that matter, the Redirect is more an
implementation detail than a fully specified part of the standard.

Different resource managers generate different "requests" with different
SHIRE parameters to tell the HS to send the authentication back to different
blocks of code. Each type of resource manager chooses the particular SP
implementation to which it can communicate best (Java, C++, .NET, whatever).
Except for the SHIRE parameter, all this is transparent to the Origin sites.

[Or I could be wrong.]