Application Stages and Metadata Generation

[Jonathan Champ]

On 11/07/2011 08:12 PM, Cantor, Scott wrote:
> On 11/7/11 5:03 PM, "Jonathan Champ" wrote:
>>
>> The issue that I don't know how to solve is what I should send to the
>> IdP. My original plan was to group it by logical application such that
>> the Metadata for the entityID https://myapp.example.com/shibboleth would
>> have the ACS endpoints for https://myapp.example.com/,
>> https://myapp-qa.example.com/ and https://myapp-dev.example.com/. Then,
>> I would have a second EntityDescriptor for the hostedapps* hosts.
> 
> That's a fairly typical approach.
> 
>> Is this possible?
> 
> Yes.
> 
>> It seems like this would be the recommended behavior,
>> so that the IdP Metadata doesn't gain an entity for each stage of each
>> logical application.
> 
> There is no "recommended" approach because it's not a technical question,
> it's policy and organization of systems and policies pertaining to them.
> Even if you do this, it doesn't answer questions like whether to share
> credentials or not. This is art, not science. If you want it to be a
> science, then you'd use a separate entityID and keypair for every vhost.
> Anything else is subjective by nature. Some approaches would seem more
> sensible than others, but there's not going to be universal agreement.
> 
>> Please let me know what is recommended as none of the examples I found
>> on the Shibboleth 2.x wiki provided any example of the way to implement
>> the given requirement: "Note that each virtual host (combination of
>> scheme, hostname, and port) operating within a particular SP MUST have
>> its own set of endpoints expressed in the metadata."
> 
> I don't know what you're looking for exactly, but your statement above
> suggests you understood the requirement.
> 
> So, what's your question?

My questions are: What does a correct example of SP Metadata look like
for the situation I described? 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?

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. 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? How does the IdP know which pieces of this information
should be given attention? 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?

Current status: http://pastebin.com/iYx3XFjM

Thank you,

Jonathan Champ