0

We provided a SAML2 Service Provider to our client, so they can use that to configure their Identity Provider to our Service Provider.

My questions is about our client certificate, I'm worried that if I stored their certificate to our APP_Data folder so that it could be accessed in our codebase for configuring both Service Provider and Identity Provider. So I'm thinking to setup an new bucket in our AWS and stored those certificate in that bucket. Any suggestion to this approach or is there a better way to at least secure the certificates?

1

Which certificate is this? Is it just the public key used to validate the token?

If it's just the public key, then the only thing you need to be worried about is someone overwriting it with a different key.

If you're that concerned with it, you can instead store it in the certificate store, and ACL it such that it require admin permissions to change. The practical issue is that you'd then need to store the thumbprint or subject of the cert somewhere so you can look it up in the store. Storing it in AWS would make it slightly more difficult for someone to mess with it. You'd want to make it readonly from your service so an attacker on the box can't use the same creds to overwrite it.

On the other hand if you're talking about the private key used to decrypt an encrypted token... that's another story. You really need to consider what sort of attacks you're looking to prevent.

  • You can store it locally on disk and anyone with read access can, well, read the key.
  • You can store it as a PFX file on disk with a password, but you need the password to decrypt it, and that needs to be stored somewhere securely, and down we go the rabbit hole.
  • You can ACL the key so only the web app can read it, but odds are it's running as network service, so that's pretty open.
  • You can switch the app to use a named account with password, and ACL the file so only that user can read the key, but an administrator can still read it, because: admin.
  • You can store it in the certificate store, but the previous 2 points still apply.
  • You can store it in AWS, but this requires a key to connect, and that key needs to be stored somewhere securely. Again down the rabbit hole. Additionally, this key needs to be pulled down to be used, which can either be stored on disk or in memory. On disk makes this all moot.
  • Lastly, you can store it in a proper key container like an HSM (see e.g. Amazon HSM, or Azure Key Vault) where the key never leaves the store, and you send encrypt/decrypt commands to it. At this point you still need a way to connect, but you can't extract they key, though you can send arbitrary data to decrypt.

This is where a threat model comes in. You evaluate the risks associated with each method, and only then can you determine whether the risk justifies the effort and impact of method.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.