Application Stages and Metadata Generation

[Cantor, Scott]

On 11/8/11 9:18 AM, "Jonathan Champ" <jonathan_champ at ncsu.edu> wrote:
>
>My questions are: What does a correct example of SP Metadata look like
>for the situation I described?

You list every endpoint required in the metadata. There's no trick
involved. All locations in the metadata are absolute, so if you want to
allow for multiple vhosts, then you have to make sure they're all listed.

> Is the only way to generate the correct
>metadata by hand or is there a way to describe the multi-stage situation
>in the /etc/shibboleth configuration files?

There are advanced configuration elements described in the documentation.
They are not easy to use or reliable and they produce various things that
can be invalid or incorrect.

>I started with the Shibboleth.sso/Metadata xml and duplicated the
>AssertionConsumerService definitions, replacing myapp-dev.example.com
>with myapp-qa.example.com in the duplicates and then renumbered them
>from 0-5 to 6-11 so that they would all have unique indices.

Right.

> The remaining instances of myapp-dev.example.com are in the
>RequestInitiator, ArtifactResolutionService and SingleLogoutService
>definitions. Only the ArtifactResolutionService has an index, but should
>I duplicate all of those rows to create a myapp-qa.example.com
>equivalent?

Unlikely to matter, but if there's something you don't understand, and
you've read the relevant specification(s), feel free to ask. None of those
are used in any likely capacity by a Shibboleth IdP. That doesn't mean
they should be wrong though.

> How does the IdP know which pieces of this information
>should be given attention?

The IdP uses the metadata that pertains to the profiles and bindings its
asked to use.

> Does it only use the SP Metadata as a
>whitelist of possible input values and is not responsible for choosing
>which endpoint to contact on the SP?

That depends on what the SP is configured to do. By default, for SSO, the
response location is explicit in the request, and the metadata is a
whitelist. For other profiles, the response location may be left implied,
which is a problem for vhosted systems sharing an entityID for exactly the
reason you're worried about. Logout is the best example of that. You can't
count on the response getting back to the vhost you start from.

The ability to combine vhosts in one entity is a feature, but it's not a
perfect or universal one.

-- Scott