entityID and multiple application instances

[Cantor, Scott]

> Should one entityID be used for -dev, -stg, and production; or three?  If
> either option is possible; which is preferred? Should I think of the entityID as
> representing my application, a particular instance of my application, or
> something that reflects the organization that owns the application?

Just to add my perspective, which is no more valid than the others, I tend toward 1 more than 2 in a lot of cases, but it usually depends on the viability of sharing keys.

If the same people are operating a set of systems, I tend to see little value in not just sharing keys across them, in which case using one entityID is often practical. I particularly advise that locally when there are dev and prod only. That keeps dev and prod in sync more easily.

If there's a QA added, I might advise dev be separate, and combine QA/Prod.

The reason the key issue matters is that you can't effectively have different decryption keys in the metadata for a single entityID. The IdP will pick one and that has to be available to all servers making up the entity.

The models I think less highly of are the ones that create separate entities by customer. Using one entity leads to lots of endpoints, but that problem might eventually be lessened by moving such cases to use signed requests and using the new IdP features in that area.

-- Scott