Multiple Certificate Scenario

[Kristen Judd]

Hello All,

I am new to the mailing list and wanted to ask about the multiple
certificate scenario outlined in the Shibboleth documentation here:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials#NativeSPMultipleCredentials-MultipleCertificateScenarios

I have two questions:

1. Would this work federation-wide if the federation's entity ID is
specified for the RelyingParty?
It appears that in the example on the wiki-page for RelyingParty, it
could work at a Federation level:

" <RelyingParty Name="SpecialFederation" keyName="special.example.org"/> "

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRelyingParty

2. Can anyone explain why the documentation warns against using this
multiple certificate scenario and what downsides there are?

Thank you!

[Cantor, Scott]

Post by Kristen Judd
1. Would this work federation-wide if the federation's entity ID is
specified for the RelyingParty?

Federations don't have entityIDs (in fact they don't exist in purely SAML
terms). What you're doing is relying on something called "containment"
based on how the metadata is carried around, and that breaks as soon as
less primitive ways of consuming metadata are used.

There aren't any widely deployed/supported ways right now of associating
an entity with something like a federation that is future proof, so you're
baking in a dependency on something that's eventually going to change. We
know how that goes when the time comes to fix it.

Post by Kristen Judd
It appears that in the example on the wiki-page for RelyingParty, it
" <RelyingParty Name="SpecialFederation"
keyName="special.example.org"/> "

That page is sending a bad message but it's a very old page.

What it's doing is referring to an EntitiesDescriptor name. That is not a
federation except by convention, and EntitiesDescriptors have no future
once we stop passing around giant files.

Post by Kristen Judd
2. Can anyone explain why the documentation warns against using this
multiple certificate scenario and what downsides there are?

It's more complex and has no benefits. It makes key rollover even harder
than it already is. Controlling it based on an EntitiesDescriptor is not a
forward-looking strategy, and there are no good alternatives right now. It
breaks in unpredictable ways when an IdP shows up in more than one
metadata source. It creates a scenario in which a system's metadata is
necessarily different depending in who's asking, which is extremely
difficult to manage without making mistakes, and the instant you make a
mistake or somebody else does, users can't log in.

The only reason for doing this is because of misguided policies that need
to be resisted. Usually it's a vendor forcing this kind of thing on
universities, but it's equally wrong when it's happening in the other
direction. The proper response to it is "no".

If it's done in very isolated cases for an IdP or two, it can be carefully
manageable. It is not an isolated case to do this at the level of an
entire federation. That will break, it's just a question of when.

-- Scott

[Tom Scavo]

Post by Cantor, Scott
There aren't any widely deployed/supported ways right now of associating
an entity with something like a federation that is future proof

I thought we were going to rely on the <mdrpi:RegistrationInfo>
extension element attached to each entity descriptor? The value of the
registrationAuthority XML attribute is a persistent identifier for the
federation, is it not?

Tom

[Ian Young]

Post by Tom Scavo

Post by Cantor, Scott
There aren't any widely deployed/supported ways right now of associating
an entity with something like a federation that is future proof

I thought we were going to rely on the <mdrpi:RegistrationInfo>
extension element attached to each entity descriptor? The value of the
registrationAuthority XML attribute is a persistent identifier for the
federation, is it not?

The spec intentionally steers clear of talking about federations and instead talks about registrars. At the moment there's a one-to-one mapping in most cases between federations and registrars, but that isn't necessarily always going to be the case.

Whether you can use registrationAuthority as a proxy for "a federation" depends on the particular property of "a federation" that you want to distinguish, and what purpose you want to put the information to.

-- Ian

[Tom Scavo]

Post by Ian Young

Post by Tom Scavo

Post by Cantor, Scott
There aren't any widely deployed/supported ways right now of associating
an entity with something like a federation that is future proof

I thought we were going to rely on the <mdrpi:RegistrationInfo>
extension element attached to each entity descriptor? The value of the
registrationAuthority XML attribute is a persistent identifier for the
federation, is it not?

The spec intentionally steers clear of talking about federations and instead talks about registrars. At the moment there's a one-to-one mapping in most cases between federations and registrars, but that isn't necessarily always going to be the case.

Well, I happen to think that registrar is the correct granularity in any case.

Post by Ian Young
Whether you can use registrationAuthority as a proxy for "a federation" depends on the particular property of "a federation" that you want to distinguish, and what purpose you want to put the information to.

I claim that registrationAuthority is all that matters since the
notion of a "federation" is too abstract (as Scott mentions).

The point is moot, however, since AFAIK the SP does not support the
MDRPI extension elements, right?

Tom

[Ian Young]

Post by Tom Scavo
Well, I happen to think that registrar is the correct granularity in any case.

[...]

Post by Tom Scavo
I claim that registrationAuthority is all that matters since the
notion of a "federation" is too abstract (as Scott mentions).

I agree.

-- Ian

[Cantor, Scott]

Post by Tom Scavo
The point is moot, however, since AFAIK the SP does not support the
MDRPI extension elements, right?

Correct, that's why (since the OP is talking about an SP) I'm saying
there's no currently supported mechanism that is future-proof, even if we
do in fact reach consensus on using the RPI extension.

I'm sure I can get a 2.6 done in relatively short order next year to
support it, but for now, there's really nothing but EntityAttributes.

-- Scott