Application Stages and Metadata Generation

[Jonathan Champ]

On 11/08/2011 10:13 AM, Cantor, Scott wrote:
> On 11/8/11 9:18 AM, "Jonathan Champ" 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.

I meant that I was interested in seeing a literal example. I understand
that the absolute endpoints for each vhost must be in the metadata.

>> 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.

Ok, I'll just use the base Metadata as a starting point.

>> 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.

Ok.

>> 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.

The Shibboleth.sso/Metadata on each vhost is correct for that vhost. I'm
just trying to generate the SP Metadata that I'm supposed to hand to the
IdP. It sounds like you are saying that "The IdP software does not use
the RequestInitiator, ArtifactResolutionService or SingleLogoutService
portions of the SP Metadata".

>> 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.

My understanding of your response is: "When a user hits a Shibboleth
page that requires a new session, the page sends the response location
with the Login request. The response location is one of the
AssertionConsumerService endpoints which is listed in the Metadata
provided by the SP to the IdP." If that is correct, then I fully expect
the Metadata that I linked to in my previous e-mail will function
correctly for Login.

If possible, I would like for Logout to work correctly. Does the
response location get sent by the SP during Logout or does the IdP
attempt to trigger Logout from its end?

Thank you,

Jonathan Champ