Jump to:
Managing signing and encryption keys using Federation Manager
Log into the Federation Manager as a Site Administrator(SA).
Click on the entity you wish to update to bring up the View/Edit page.
On the left navigation, click "Signing/Encryption Keys" to bring up the IdP SSO Keys (or SP SSO Keys) section.
The "Add a New Key-containing Certificate" form allows you to upload a new certificate in PEM format. Use the checkboxes to the right to designate whether it is used for signing, encryption, or both.
IMPORTANT: When registering a service provider, make sure to read signaling-sp-encryption-method-support first to make sure you are choosing the right encryption algorithm options when uploading encryption keys.
If you have previously uploaded other keys, they will appear first. The edit button lets you change the usage (signing or encryption) of these previously uploaded keys.
Remember: your metadata is not published to the InCommon metadata until you submit it for publishing using the "Submit This Entity for Publishing" button in the Review and Submit section. When you are ready to publish your metadata, don't forget to press that button.
Message signing and encryption in SAML rely on public key cryptography. Both Identity Providers (IdP) and Service Providers (SP) include in their respective metadata the public keys they intend to use for signing and/or encryption. Do not upload your private keys.
Each key uploaded to a SAML metadata is packaged in a digital certificate and encoded in the Privacy-Enhanced Mail (PEM) format, a de facto format used to encode digital certificates.
A signed SAML message lets the message recipient verify that the message delivered is sent by a trusted sender and has not been altered while in transit. A encrypted SAML message ensures that only the recipient of the SAML message can access its content.
InCommon Federation supports both signing and encryption of SAML messages. To enable message signing and/or encryption for your entity, use Federation Manager to add signing and encryption keys in your entity's metadata.
NOTE: these keys are used for message-level signing and encryption, 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.
Keys published by an Identity Provider
When an IdP designates a key as a signing key, the key is used by interoperating SP’s to verify a signed message from the IdP: the IDP signs a SAML message using its private key; the receiving SP verifies the signature using the IdP's published public "signing" key in metadata.
When an IdP designates a key as a encryption key, the key is used by interoperating SP’s to encrypt a SAML message destined for the IdP: the SP encrypts the SAML message using the IdP's published public "encryption" key in metadata; the IdP decrypts the message using its matching private key.
When an SP designates a key as a signing key, the key is used by interoperating IdP's to verify a signed message from the SP: the SP signs a SAML message using its private key; the receiving IdP verifies the signature using the SP's published public "signing" key in metadata.
When an SP designates a key as a encryption key, the key is used by interoperating IdP’s to encrypt a SAML message destined for the SP: the IdP encrypts the SAML message using the SP's published public "encryption" key in metadata; the SP decrypts the message using its matching private key.
A cryptographic key published in SAML metadata is by convention packaged in a x.509 digital certificate and uploaded in the Privacy-Enhanced Mail (PEM) format. PEM is a de facto format used to encode digital certificates. This packaging convention often leads to implementors using the term "x.509 certificate" when discussing signing and encryption keys in SAML metadata.
In fact, keys in SAML metadata, at least when applied in the research and education federation model (ala the InCommon model), does not rely on the certificate authority trust model typically associated with x.509 certificates. When you publish your metadata in InCommon, the Incommon Federation is vouching that you in fact issued the keys (along with other data elements) embedded in your metadata. It does not matter who signed the certificate used to package the key. In fact, packing your keys in long-lived, self-signed certificates is the preferred way to go. It is easy to create a self-signed certificate with the OpenSSL command-line tool.
In the base SAML metadata specification [1], a certificate signing authority (CA) has no assumed relevance to the trust model that secures the interactions among a federation's participants. In fact, certificates signed by a CA are discouraged since they can create interoperability issues in certain situations and lead to configurations that mistakenly establish trust based on the certificate signer. Allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not registered in the Federation.
InCommon conforms to the SAML V2.0 Metadata Interoperability Profile [2] from OASIS. Participant site administrators securely transmit X.509 certificates and metadata to InCommon via the administrative web interface. InCommon signs the entire metadata file, securing the keys of its participants whether those keys are bound to self-signed certificates or certificates signed by a CA. The critical element in the certificate is the public key, which is associated with an entity via its entity ID. Theoretically, 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 particular entity in the metadata.
InCommon sets the following security and trust requirements around certificates included in Federation metadata:
Consider the following interoperability issues as you set up and maintain 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 webinar presented by the InCommon Technical Advisory Committee (October 22, 2009)
[4] The Shibboleth ExplicitKey Trust Engine https://wiki.shibboleth.net/confluence/display/SHIB2/ExplicitKeyTrustEngine
]5] Shibboleth Security and Networking https://wiki.shibboleth.net/confluence/x/VoEOAQ
Can't find what you are looking for?