entityID and multiple application instances

[Cantor, Scott]

> The point of "Unlike the endpoint locations, the entity ID accurately reflects
> the organization that owns the entity. Endpoint locations, on the other hand,
> are resolvable DNS names." is to say that the entityID will be composed with
> a hostname inside of it that can be traced back to the organization that
> controls the metadata;

As a policy matter. In SAML terms, it's a name, it doesn't matter what it is.

> The key point with regard to my question is that there is a one-to-one
> relationship between entityID and sp-key.pem/sp-cert.pem created by
> `make install` ; one entityID for all instances is possible but requires manually
> creating metadata XML.

Manually handling metadata is requirement regardless, you cannot perform essential operational functions like key rollover using generated metadata.

But yes, there are issues with decryption if you don't share keys. Keys for signing or authentication can be multiply occurring more easily. It depends how you manipulate the metadata.

> I have another related question re: " However, SAML V2.0 defines a fairly
> obvious way of obtaining metadata about a given entity by resolving an
> entityID URL (see section 4.1 of the SAML Metadata Specification)." on
> https://wiki.shibboleth.net/confluence/display/SHIB2/EntityNaming -- does
> this suggest I should use http://nuxeo-
> dev.cdlib.org/Shibboleth.sso/Metadata as my entityID?  It seems to meet
> the section 4.1 requirements.

No. You should never serve up generated metadata for consumption by another paty, ever. Other than for purely testing purposes or if you understand the system well enough to know what the implications are. One reason the default entityID convention doesn't match that is to avoid that mistake.

-- Scott