Here is the part of SP metadata.
Reference: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0
...
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
...
Are there any benefits to choose same (or different) certificate in both signing and encryption certificate ?
What is the purpose of including signing certificate here ?
If the message is sent through https, a transport layer encryption is provided. Do we still need to include encryption certificate here ?
In Service Provider (SP) initiated SAML, a SAML request is prepare by the SP. The SP digitally signs the request using a private key. When the request is received by the Identity Provider (IdP), the digital signature is verified using the public key sent by the SP in a certificate.
The SAML metadata file contains information about the various SAML Authorities that can be used in SAML 2.0 protocol message exchanges. This metadata identifies Identity Provider endpoints and the certificates to secure SAML 2.0 message exchanges.
Metadata configuration. SAML metadata is an XML document which contains information necessary for interaction with SAML-enabled identity or service providers. The document contains e.g. URLs of endpoints, information about supported bindings, identifiers and public keys.
In SAML 2.0 Web SSO's metadata providers typically declare the same certificate for both signing and encryption usage.
There are some use-cases where usage of different keys makes sense - e.g. when SP itself is not supposed to be able to decrypt data provided by IDP (e.g. nameID or attributes), but this is only done by the ultimate recipient of the Assertion; or when a different party provides content for creation of assertion than the party who actually creates the SAML messages - but those use-cases are rare and more relevant for other profiles than Web SSO.
The signing certificate is included in order to inform users of the metadata on how to verify messages provided by the issuer of the metadata. For example, when SP receives a message from IDP, it uses signing certificate defined in IDP's metadata in order to verify whether the message was created by the IDP and wasn't tampered with during transport.
You typically don't need to include the encryption certificate in case encryption is done on transport layer and you don't perform any encryption on message level (e.g. of whole message, assertion, nameID or attributes).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With