Is the .pfx file needed? I have done other implementations in Python where you do not need this file. Just the .cer file. Can you give some insights as to what this file does/is used for?
Thanks!
The .pfx file contain both the certificates public and private key where the .cer file only contain the public key. The public key is used to validate a SAML authn response in a relying party. The private key is needed to sign a request. According to the SAML 2.0 standard a relying party is required to sign SAML logout requests.
Furthermore, the project include an identity provider sample which signs the SAML authn response an therefore also needs a private key. A relying party use the corresponding public key to verify the signature.
Related
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
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.
I am using Azure Ad openidconnect using .Net core MVC, i can see the signin key provided by azure ad through discovery endpoint. Now i am confused how safe openidconnect is when anybody can see the signin key used to sign my token.
The key that is published is a so-called public key that belongs to a key pair that consists of that public key and the corresponding private key; the latter is supposed to be private to the owner, the former is not.
There are two cryptographically-linked keys involved (i.e. a key pair):
Private key: This is the key used to sign the token. In a typical scenario, only the token issuer (Azure AD, in this case) will ever have access to the private key.
Public key: This is the key used to verify a signature. In this scenario, the public key is used to test that the token signature was generated using the private key of this key pair.
If you know which issuer you trust (e.g. Azure AD), and you can open a secure communication channel to that issuer (e.g. https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration), you can use that public key to verify that a given signed token really was signed by the trusted token issuer.
I am trying to sign my HTTP-Redirect binding AuthenRequest so I can send it to the Idp. What is the logic behind signing the request? Do I sign it using my x509 and a private key? Do I sign it using my private key and Idp's x509 cert? Also, the Idp requires the signature query parameter. Do I simply extract the signature value from the request after I sign it?
I am developing in c# .net
Thanks
You always sign with your private key. The recipient will verify the signature using your public key.
In this case, you sign the SAML authn request with your private key and the identity provider will verify the signature with your public key.
Typically you supply the identity provider with your public key as a certificate file or as part of your SAML metadata.
If the IdP requires the signature as part of the query string, this means they want you to use the HTTP-Redirect binding to send the authn request. You need to look at the SAML v2.0 bindings specification to understand how to implement this. The signature is not part of the request and therefore isn't extracted from it.
The best and easiest solution to get the proper Signature value in HTTP-Redirect post is to use a 3rd party library for c# called ComponentPro. Below is what I used to get it to work:
NameValueCollection queryString = RedirectUtil.CreateQueryString("SAMLRequest", authnRequest.GetXml(), relayState, key, signatureAlgorithm);
The key is the private key.
I use Okta as my IDP and I have 2 use cases:
IDP-initiated SSO
when a user wants to login using his okta credentials to my system, I redirect him to okta, and okta send the response to a callback in my app.
I was wondering why I need the keystore? how is it used?
The messages to the IDP from the SP (my app) will be encrypted using this keystore key-pair? And if so, doesn't that mean that I need to somehow share my keys with okta?
I couldn't find any explanation on this.
Appritiate any help on this!
Thanks!
SAML Responses sent from a SAML Identity Provider ("IdP") like Okta will be signed using Okta's private key, these messages will be validated by a SAML Service Provider ("SP") like your application using the corresponding public key.
In your case, the keystore should only be used for Okta's public key (or public keys, if you federate with more than one Okta org). You will not need to share any keys with Okta, but you will need to get the public key from Okta somehow. The best way to get the public key from Okta would be via an IdP metadata URL, the next best way would be to have the Okta administrator paste Okta's X.509 encoded public key into your app somehow.
I would like to ask if I signed the saml response with idp private key and encrypt saml assertion with sp public key. Do I need to sign the saml assertion before encryption? Is it overkill? Do you know any standard from any official doc? Thanks.
Encrypting with the recipient's public key guarantees that only the recipient can read the contents. Anyone can encrypt data with the recipient's public key.
Signing with the sender's private key guarantees that only the real sender could have created the data. Anyone can validate that the data is indeed from the sender.
In SAML the most important thing for an SP is to being able to validate that the assertion is indeed from the IDP and not from some fake source. That can only be done through signing with the IDP's key. That's why signing is mandatory in the SAML standard. Encryption can be used to make sure nobody but the SP can read the contents of the assertion. That is optional in the standard.
For details see chapter 5 in the SAML2 core specification.
The best method is to encrypt and then sign the entire SAML response rather than just the assertion. This method is considered to be most secure and will be more widely accepted by SSO/Federation products.
The reason for signing the entire SAML response is a potential protocol vulnerability, where the origin of the SAML response could not be guaranteed (if the response itself weren't signed).