SAML private and public key sharing

0
votes

Our client (the IDP) has requested our private key so that they can register our service as an SP, which seems like a very strange request to me since giving them our private key gives them the ability to decrypt any of our other clients SAML requests and even create requests and attack other IdP's we're connected to.

I shut this down immediately but they then had me refer to Azure AD B2C documentation

To build a trust relationship between your service provider and Azure AD B2C, you need to provide X509 certificates and their private keys.

Is this normal? I've been under the assumption that they only need our x509 certificate

1
azure-active-directorysaml-2.0
Yeah, there are two certificates. The first one is required, the IdP has the private key and they sign the token with their key. The second one is optional, they have your private key and use it to encrypt the token. You can't mix the two (use the same for both purposes) as it's against security. - Wiktor Zychla

1 Answers

2
votes

From the documentation it seems that your private key always stays with you:

Certificate with a private key stored in your Web App

the private key resides in the SP application (the web app that provides the SP functionality) and is used to sign a SAML Request to the IdP. The IdP only needs the SP's public key certificate from the SP's metadata in order to validate the signature.

(Optional) Certificate with a private key stored in your Web App

this is optional for the IdP to encrypt the SAML Response using the SP's public key certificate from the SP's metadata. The SP then uses its private key to decrypt the response.

The wording isn't great as it seems to say to hand over both the public and private keys to the IdP. That's not how SAML works though. It makes much more sense when read as 'hand over the public key and keep the corresponding private key in your SP webapp'.

I can't see any reason why an entity must divulge its private key to anything.