Alistair Young wrote:
> Would it ever be likely that, say, an IdP could have the same entityID in
> two different federations but each federation used the shibboleth method
> of trust, i.e. the federation metadata for both federations would contain
> the KeyAuthority extensions for root CAs. However, fed1 was the uk
> federation, which trusts a lot of root CAs but fed2 is a high security
> federation, say medical image sharing and it only trusts one CA, itself.
> It issues its own certificates to entities.
This does already happen. InCommon issues its own certificates, for
example, and doesn't currently accept anyone else's. An entity that
works in both InCommon and the UK federation has to do one of:
1) use different credentials for different sets of partners
2) use a different entity name when talking to different sets of partners
3) persuade the UK federation to publish the credentials acquired for
InCommon
The question of who issues certificates is largely a red herring, by the
way. What's important is the nature of the process by which keys and
certificates are bound to entities.
> Is this ever likely to be seen in the wild?
All three of the above solutions have been used in appropriate
situations. If you look carefully in the UK federation metadata, you
can see a number of cases where we've done quite tailored things for
particular entities to work round issues in this and other areas.
In the longer term, I'd like to think the technical consensus in most
places is moving towards using long-lived, self-signed certificates for
trust purposes rather than federation-issued or commercial certificates.
This move away from the Shibboleth-invented extensions should give
better interoperability in the long run, as well as addressing the
problem you're describing. Again, we've done this with selected
entities in the UK federation when it has been the most appropriate way
to solve a particular member's deployment issues.
> Or should an entity, such as
> an IdP, identify itself differently in different federations? i.e. have a
> different entityID (providerId) for each federation?
In general, it makes sense for an entity to use the same name in all
contexts, because federations don't really exist at the protocol level.
There are problems that can occur if an IdP and SP both belong to
multiple federations with the same name and have different metadata in
each. Given that IdPs don't appear in multiple federations nearly as
much as SPs do, the easiest way to avoid this is to have IdPs in this
situation either have identical metadata in every federation, or to have
different entity names in each federation. There are other techniques too.
The far more common case is of service providers, which frequently serve
customers in multiple federations. It's still best for them to have a
single entity name and identical metadata in every federation (some
software can't cope with anything more complicated than that) but
because all the IdPs see of an SP at run-time is the certificate used
for authenticating attribute requests (unlike an IdP, they don't need to
have TLS-protected SOAP endpoints) things usually just work anyway for
an SP.
-- Ian
|