Application Stages and Metadata Generation

[Tom Scavo]

On Tue, Nov 8, 2011 at 9:18 AM, Jonathan Champ <jonathan_champ at ncsu.edu> wrote:
> 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

Some comments:

- You can remove "urn:oasis:names:tc:SAML:1.0:protocol" since it is
mutually exclusive with "urn:oasis:names:tc:SAML:1.1:protocol".

- You can remove <ds:KeyName> and <ds:X509SubjectName> elements.

- I only know of one IdP implementation (not Shib) that will consume
an artifact, so you can probably remove the
<md:ArtifactResolutionService> element.

- Same comment for the <md:SingleLogoutService> elements.

Hope this helps,
Tom