Q: Shib IdP behaviour for key roll over and ADFS

[Chris Phillips]

Thanks for the reply on this Scott.

Digging deeper, much of the challenge has been (for me)  around IdPs
automatically encrypting assertions when the key I have in metadata is
really a signing key which was the wrong key to use without properly
decorating it with 'use=signing'.

I will likely pursue the approach of tagging the key 'use=signing' like
others I've seen in inCommon metadata once I've exercised it internally.

It is also good to know the signature verifier must try all keys as well.


FWIW for the archives, setting an ADFS certificate to a longer duration
than a year can be done and is described here[1]*, otherwise it is a 1
year duration by default.

I realize the post sounds more ADFS than Shibboleth like but it's more
about how ADFS can interop with Shibboleth and SAML..

Thanks..
Chris.

[1] 
http://www.benjaminathawes.com/2013/07/31/how-to-renew-your-adfs-2-0-token-
signing-certificate-in-sharepoint/
* I have not tried a 10 yr key so YMMV..


On 14-02-18 11:12 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 2/18/14, 10:48 AM, "Chris Phillips" <Chris.Phillips at canarie.ca> wrote:
>>
>>I have a new (auto generated by ADFS) cert in hand that I can put into
>>the metadata and intend to apply the use=signing designation for that and
>>only that key.
>
>Unless you're signing requests, the signing keys at an ADFS SP probably
>won't come into play, will they?
>
>So given that we're talking encryption, I'm not sure you can actually do
>key rollover with ADFS for encryption, because IIRC, they don't allow more
>than one to be locally configured. The only way to safely roll over
>encryption is to configure it locally as a second key so it's in place,
>and will try both, and then you change the metadata to swap to the new key
>from the old one.
>
>Unless you can locally try both keys, there is no way to do this.
>
>>- Will the Shibboleth IdPs automatically use the most recent certificate
>>or the older one until it expires?
>
>Are you talking about encryption or signatures? A signature verifier MUST
>try all keys. What order it tries them is implementation dependent.
>
>For encryption, SAML does not specify any rules for selecting a key to
>use, and we don't specify any behavior. In practice, it will take the
>first one that's usable. A certificate never matters for any purpose where
>encryption is concerned in the IdP.
>
>>I presume that once IdP's see a newer certificate they will use that one,
>>but am unsure. 
>
>No.
>
>>-  Also, can I co-mingle the certificates with distinct use=xxxxx
>>designations without issue?
>>(i.e. Must I post my new cert like my other one currently in the metadata
>>with no 'use=signing' designation?)
>
>The IdP honors the attribute fully. You can have many keys, but if only
>one is marked for encryption, then it will always be the one used.
>
>>I presume that this is ok as well to do because ADFS has both
>>certificates that it can properly validate the signatures whether it is
>>signed with the old cert or new cert.
>
>I'm lost now as to which end you're rolling over. And I know very little
>about what ADFS will or won't allow.
>
>>The last question I have is that I also presume that once the older cert
>>is expired that I MAY leave it in the metadata past the expiry date and
>>it will not be used by Shibboleth IdPs, but only the newest one.
>
>No. Shibboleth does not care about certificates included in a
>KeyDescriptor. The only interpretation of that in SAML that is defined is
>the IOP, which is a key-only profile. Any use of certificates semantically
>has to be done via KeyName and KeyAuthority extensions only.
>
>It also never applies to encryption, by definition, since a key must be
>known via the metadata to encrypt.
>
>>I realize that this is ADFS focused(as an SP and gateway to Sharepoint),
>>but I'm really asking about the Shibboleth IdP behaviour in a key roll
>>over situation and have read this [1] already and seeking a bit more
>>clarity/confirmation about expected behaviour.
>
>Your issue here is ADFS. And I don't really think you can be successful
>based on what little I know, but I do know that the scenario with the
>problem is encryption.
>
>With signing, you don't need multiple keys locally, nor do you need
>multiple keys in the metadata consumed by ADFS (only that consumed by the
>IdP). With encryption, it's the opposite.
>
>-- Scott
>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net