Metadata format

[Peter Schober]

* Roy Spectech <roygspectech8 at gmail.com> [2013-09-16 17:16]:
> We thought, perhaps wrongly, that each "customer" should have their own
> CERT, Key, and ACS lines. The reason for that is because, in this case,
> there's are NOT separate VHOSTS for each customer. The application is
> implemented in "paths" from the file tree:
> 
> /home/wwwroot/customer01\app01022
> /home/wwwroot/customer02\app010310
> [...etc...]
> 
> We have to have some way to segregate the customers as many have different
> released variables (so different REMOTE_USER values), different Session
> elements (lifetime/timeout lengths), etc.

If you know you need have seperate logical SPs based on paths
(REQUEST_URI) you'll need to use ApplicationOverride and you'll end up
with  seperate SPs each with its own SAML metadata <EntityDescriptor>.

So all of your ACS URL and index questions don't really matter here,
as you'll have seperate, complete metadata instances, one for each
logical SP.
If needed/wanted you can combine these within a single XML file, as I
have described in my previous message.

> So without VHOSTS, we thought each customer should have their own CERT and
> key.
> If that is not a good idea, or has no positive side, we'll drop it.

My first reaction would be that it doesn't make much sense for what
really is the same entity (or service) to be using differing keys for
each IdP it exchanges protocol messages with /but/ if you need to
interop with M$-ADFS SAML IDPs you're bascally forced to do that.
Note the third bullet on the page
https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop#MicrosoftInterop-Metadata

-peter