Date: Fri, 29 Mar 2024 01:57:41 +0000 (UTC) Message-ID: <493149985.7387.1711677461864@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7386_871945996.1711677461861" ------=_Part_7386_871945996.1711677461861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This article discusses the use of X.509 certificates in Federation metad= ata. It has security implications so please read it carefully.
A SAML entity uses public key cryptography to secure the data transmitte= d to trusted partners. Public keys are published in the form of X.509 certi= ficates in metadata whereas the corresponding private keys are held securel= y by the entity. These keys are used for message-level signing and encrypti= on, and to create secure back channels for transporting SAML messages over = TLS. They are not used for browser-facing TLS transactions= on port 443. See the Key= Usage topic for more information.
Uses of Certificates in Metadata
Certificates in metadata are used for message-level signing and encrypti= on, not browser-facing TLS transactions on port 443.<= /p>
The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. Consequently, the us= e of long-lived, self-signed certificates in metadata is s= trongly recommended. Certificates signed by a Certification Authority (CA) = are allowed, and in most situations will work just fine, but the use of cer= tificates other than self-signed certificates is discouraged. See the Background information a= nd the Interopera= bility notes below for further discussion.
Trust the Key, Not the Certificate
=From a security perspective, the only element of a certificate in metada= ta that matters is the public key. Conforming software wil= l ignore all other certificate content.
Any certificates you want to use with your SAML software are uploaded vi= a the Federation Mana= ger. Typically only one certificate is required per entity but multiple= certificates may be uploaded and used as needed. In particular, multiple c= ertificates may be used to facilitate the controlled rollover of expired ce= rtificates or compromised keys. To avoid interoperability problems, refer t= o the Certificate = Migration topic for recommended guidelines regarding the rollover proce= ss.
It is easy to create a= self-signed certificate with the OpenSSL command-line tool. Before you= do this, however, take a moment to consider how best to handle the all-imp= ortant private key.
Before generating a new private signing key for your IdP, read the IdP Key Handling topic.<= /p>
Contents
In the base SAML metadata specification [1], a certificate signing autho= rity (CA) has no assumed relevance to the trust model that secures the inte= ractions among a federation's participants. In fact, certificates signed by= a CA are discouraged since they can create interoperability issues in cert= ain situations and lead to configurations that mistakenly establish trust b= ased on the certificate signer. Allowing self-signed certificates simplifie= s the work of participants who may be required to join multiple federations= , or who support local systems that are not registered in the Federation.= p>
InCommon conforms to the SAML V2.0 Metadata Interoperability Pr= ofile [2] from OASIS. Participant site administrators securely transmi= t X.509 certificates and metadata to InCommon via the administrative web in= terface. InCommon signs the entire metadata file, securing the keys of its = participants whether those keys are bound to self-signed certificates or ce= rtificates signed by a CA. The critical element in the certificate is the p= ublic key, which is associated with an entity via its entity ID. Theoretica= lly, if all the relevant software systems could accept a public key without= a certificate wrapper, InCommon would only need to include the public key = of each entity. As it is, the certificate is a convenient container for the= public key, the critical element being that the key is bound to a particul= ar entity in the metadata.
InCommon sets the following security and trust requirements around certi= ficates included in Federation metadata:
Consider the following interoperability issues as you set up and maintai= n your deployment:
<md:EntityDescriptor> element containing more than one encryption key.
[1] Metadata for the OASIS Security Assertion Markup Language (SAML)=
V2.0 http://saml.xml.org/saml-specifications
[2] SAML V2.0 Metadata Interoperability Profile http://wiki.oasis-open.org/security/SAML2MetadataIOP
[3] X.509 Certificates in the Federation Metadata: A technical we=
binar presented by the InCommon Technical Advisory Committee (Octo=
ber 22, 2009)
[4] The Shibboleth ExplicitKey Trust Engine https://wiki.shibboleth.net/confluence/display/SHIB2/Explic=
itKeyTrustEngine
]5] Shibboleth Security and Networking https://wiki.shib=
boleth.net/confluence/x/VoEOAQ