This is more or less the reverse of what's asked in this question.

I recently added SSO with SAML to a SaaS Web application making said application the Service Provider (SP). This is done so customers (companies) can use their existing Identity Provider (IdP) such that the users (the companies' employees) don't have to maintain credentials in our Web application but can simply continue to use their existing local accounts.

In SAML, the SP sends an authentication request to the IdP which answers with an assertion that provides authentication information about the user that wants to log in. In order for both parties (SP and IdP) to be sure that request and response are not fabricated by a wire tapper, they are signed with a private key. The certificate used to check the signatures of requests and responses have been exchanged beforehand as part of the SAML Metadata exchange that is done manually by the administrators of the involved parties.

The question is: Are there significant downsides to the security of this system if I use the same public/private key pair for all customers or is it advisable to go through the hoops of creating a separate key pair for each individual customer?

I'm explicitly asking about the security of this issue. I know that if I have to exchange the key due to a security problem, all customers will have to update their IdP to incorporate the new certificate. I haven't made up my mind yet but I lean towards thinking that this is an acceptable risk. Those keys would be stored next to each other; a breach of any description would require new keys for all customers anyway.

  • Ok, so are you asking if the IDP can have only one key to communicate with SPs? And the SPs will have one key each? Apr 23, 2015 at 7:11
  • There is only one SP and that is the Web application I work on.
    – musiKk
    Apr 23, 2015 at 7:13
  • Ok, in this case the IDP should have one key pair and the SP should have one Apr 23, 2015 at 11:16
  • What do you mean by customers? If by customers you mean the identity provider then I would say use different certificates for each different IdP. But do not use different certificate for each end user (companies' employees)
    – Ubaidah
    Mar 17, 2016 at 22:23

2 Answers 2


Best practice is that every IDP and every SP has its own key pair. Easier if you need to issue a new certificate for one of them and it prevents one of them from posing as another etc.

But this is the key pairs for the IDP and your web application. You are asking if the customers need different keys. If it is really is a question if the end user should have separate keys than the answer is definitely yes. In the same way that they should have different passwords.

  • Thanks for your input. I'm just wondering about this because at the Web layer, customers don't get individual SSL certificates. Why is it different in SAML?
    – musiKk
    Apr 22, 2015 at 7:24
  • Client certificates that you assign to the SP and IDP is used mainly to authenticate the SP/IDP. The users typiclly authenticate using password. Apr 22, 2015 at 10:03
  • I represent the SP, I don't care how the users authenticate against the IdP. I don't involve client certificates or use them for authentication. They (along with the private key) merely sign the SAML messages. Should I clarify the question a bit more?
    – musiKk
    Apr 22, 2015 at 11:54
  • Ok, when you say the customers, you dont mean the users. Apr 22, 2015 at 12:20
  • Exactly. I think my question wasn't too good. I hope my edit clarifies a lot.
    – musiKk
    Apr 22, 2015 at 14:26

While I have seen a few SPs sign AuthnRequests with unique keys, this doesn't last long as they start to scale. They usually determine that managing all those private keys is a serious pain as they grow larger, and then they switch to using a single private key for signing them. There's nothing wrong with this - signing the AuthnRequest proves that it came from the holder of the private key, and it can be validated by anyone that has the public key. As an example, you can go get the certificate that Salesforce uses to sign its requests right from here.

In many instances, large SPs (like Salesforce) also put the onus of keeping the certificate that the IdP uses to sign its responses onto the IdP as well. As the IdP, you log into the administrator interface at the SP, and upload your public key. If you let it expire, that's your problem, not theirs, and the process scales.

  • Thanks. No doubt using unique keys is a pain. I just wasn't sure if this opens up obvious security risks. I agree that the IdP is responsible for their key management. I'm not familiar with Salesforce... it seems they can be an IdP, not an SP, no?
    – musiKk
    Apr 22, 2015 at 12:04
  • Salesforce as an SP has been around for years (see here). They only started performing the IdP role last year.
    – Andrew K.
    Apr 22, 2015 at 12:10
  • You say "AuthnRequest proves the validity of the issuer of the AuthnRequest" but if everyone has the same private key you can only validate that the issuer is one of the SPs. A propper way to solve this is to let every SP generate and store its own keys. The public part of the key is then delivered to the IDP in SAML metadata Apr 22, 2015 at 12:19
  • Not everyone has the same private key. Only the SP has the private key that they sign their AuthnRequests with. Everyone has access to the public key, and can validate the signature that the SP has placed on the AuthnRequest. This is how PKI works... Anyone can have your public (hence the term "public"), and only you have the private (hence, "private"). Every SP should have its own signing (private) key. Every IdP should have its own...
    – Andrew K.
    Apr 22, 2015 at 12:28
  • Ok, I must have misunderstood your answer. So we agree every SP and IDP should have their own public private key pair. What I understood from your answer you say that all SPs use the same key pair when they start to scale. What was you intention? Apr 22, 2015 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .