Skip to Content.
Sympa Menu

shibboleth-dev - [Shib-Dev] lessons learned from AD FS 2.0

Subject: Shibboleth Developers

List archive

[Shib-Dev] lessons learned from AD FS 2.0


Chronological Thread 
  • From: Tom Scavo <>
  • To: Shibboleth Development <>
  • Subject: [Shib-Dev] lessons learned from AD FS 2.0
  • Date: Sun, 24 Oct 2010 14:38:27 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KSzehveZ0YwISYnWqZqaS72y8s4cI+zt6Q4s6+KJtf0PqN1JzTnllo75PRTdgyiuzO 4zemhWKeYygkhxyATEtK0SH2Mot46SIiW/zF6o51KKVpbqR27RrVkm79avhwSIFwr3IT FvLRc42Qbh2BMjdQTj5K4cutRqdIPFfFzJqFo=

I'm getting a lot of mileage from the most recent "step-by-step guide"
from Microsoft:

AD FS 2.0 Step-by-Step Guide: Federation with Shibboleth 2 and the
InCommon Federation (October 2010)
http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=e4770f44-93a1-4641-8add-32e076f0aae7&pf=true

(If the above link doesn't work for you, try removing the pf parameter
from the query string.)

As a result, I will recommend the following deployment requirements
within the InCommon Federation:

1. Every <md:KeyDescriptor> element in IdP metadata MUST have an
explicit use="signing" XML attribute.
2. Using forms-based submission, a site admin MUST be able to bind
separate signing and encryption keys, even if those keys are
identical.
3. Every role descriptor SHOULD have at most one encryption key.
4. Where multiple keys are listed within a single role descriptor,
unexpired certs SHOULD precede expired certs.
5. The same certificate SHOULD NOT be used by two different entities.
6. A certificate in metadata SHOULD NOT have a CRL Distribution Point
(CDP) certificate extension.

The following software requirements should be documented as well:

1. To support key rollover, an implementation MUST be able to consume
and utilize up to two <md:KeyDescriptor use="signing"> elements in a
single role descriptor.
2. To support key rollover, if an implementation supports encryption,
it MUST be configurable with up to two decryption keys.
3. If an implementation produces metadata on-the-fly, it SHOULD
produce metadata with at most one encryption key.

It's this very last requirement that is the purpose of this message
(since the previous two are already met by Shib). Regardless of the
number of decryption keys configured, does the SP produce metadata
with at most one encryption key?

After reading the following wiki article, I suspect the answer is no:

https://spaces.internet2.edu/display/SHIB2/NativeSPMultipleCredentials

If every <md:KeyDescriptor> element in metadata has a 'use' XML
attribute, multiple encryption keys in metadata are not strictly
required. So the first step of the key rollover process should be to
replace a <md:KeyDescriptor> element having no 'use' attribute with
two <md:KeyDescriptor> elements having explicit 'use' attributes. Was
this intentionally overlooked?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page