Here's the question:
Is there any benefit to securing a SAML assertion with a CA cert? I understand how using a CA cert is of benefit when establishing the SSL connection over which the SAML assertion is transported, but what about a CA cert for the PKI handshake that occurs when the SP accepts the SAML assertion itself? I have one side contending that within the SAML exchange there's no way for the SP to iterate through the chain of trust to the root CA cert, while on the other side I have someone saying that it can.
Bonus points if you can point me to an authoritative source that supports your answer.
If I understand you correctly you wonder if there is any point in using a certificate sign by a CA when signing the SAML assertion.
In my opinion you should not need this. When you establish the initial trust and exchange metadata you can include the public key of the entity in the metadata.
If you can trust that the exchange of metadata is secure, you can just verify the signature against the public key in metadata.
I can not see how a CA would give any value to this situation.
I agree too. Although in standard Shibboleth Metadata sharing mechanism (Federation) the whole published metadata block is sign by Federation certificate. So PKI may be (and probably is) used to distribute service and IdP metadata between security partners. But as Stefan wrote, there is no point in signing Assertion with Certificate signed by trusted CA
Related
I'm a Service Provider, and the SME for the Identity Provider has specified that they require that the SP provide them a certificate different from the standard server certificate.
Every SSO Integration I've accomplished so far has had the IdP provide me with the certificate.
Is a SP able create and provide a separate certificate to the IdP?
Currently, the IdP SME is advising that unless I can provide this, he won't enable Solicited SSO(SP-Initiated SSO).
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
I have a Spring SAML project that has a JKS with the public certificate of the IDP loaded into it. I have a theoretical question:
If I were to load in the issuing root or intermediate CA into the JKS, would that be sufficient for trusting the IDP and validating the IDP SAML messages? The benefit to doing this would be that future IDPs with a common issuer would be trusted without having to load in their certificate.
My understanding is that the actual public certificate of the IDP needs to be in the JDK so that Spring SAML can validate the request, however, isn't the X509 in the request sufficient for doing this and it's just a matter of validating that the certificate in the IDPs public metadata is from a trusted issuer?
I'm a bit over my head with this. Any insight or explanation will be greatly appreciated!
Yes, you can do that with the PKIX security profile. Loading the IDP certs into the keystore should be enough (provided the trustedKeys in extendedMetadata is null, which is the default).
See the manual, chapter security profiles for all the details.
From ADFS and ADFS 2.0 perspective is it possible to register Service Provider metadata that is using certificate (public key) that is not issued by signing authority ? I mean on self signing certificate.
Yes - you can use a self-signed certificate for the SP and that certificate is reflected in the SP metadata.
So you can generate it with the Java keytool etc.
Also ensure that you generate the certificate for a reasonable period - at least a year otherwise you will have to co0ntinually update the metadata on the ADFS side.
It should not be as described in following document -
Certificate Requirements for Federation Servers in section Determining your CA strategy
"ADFS does not require that certificates be issued by a CA. However, the SSL certificate (the certificate that is also used by default as the service communications certificate) must be trusted by the ADFS clients. We recommend that you not use self-signed certificates for these certificate types."
I am Authenticating all my users through a Microsoft product using SAML 2.0 with a X509 Certificate. The certificate is close to expiration, and I am not sure if after the certificate expires, my Service Providers will continue accepting my tokens.
I am very VERY new to SAML and SSO in general, so my apologies for not using the right terms.
If your Service Providers are compliant to the specification they will stop processing your SAML messages (Responses) once your signing certificate expires.
Unfortunately, there is no easy way to tell ahead of time. You will probably need to contact each one to find out how they handle this situation -- homegrown solutions may be more lenient than commercial products in this regard and allow SSO transactions to continue.