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.
Related
How do I install a signing certificate in Keycloak when using Keycloak as a Service Provider (SP) that should connect to a (non-Keycloak) Identity Provider (IdP)?
To be more precise, Keycloak should be used as an Identity Broker (as described in the Keycloak documentation) and the communication between the Keycloak SP and the IdP is going to be facilitated via the SAML 2.0 protocol.
The Keycloak documentation contains information on how to install SSL certificates for doing "normal" HTTPS communication e.g. in the browser, but I cannot find anything regarding the installation of signing certificates to be used in the backend-to-backend SAML communication with the IdP. Does anyone know how to do this?
(Maybe only one certificate is installed into Keycloak, i.e. this certificate is used for both SAML communication and other non-SAML Keycloak HTTPS communication?)
How do you see which Certificate is used by your SP for signing/encrypting SAML messages for/to the external IDP?
Go to Identity Providers -> your configured SAML IDP -> Export. The export contains the certificate which is used for signing/encryption. There must be at least one activated signing/encryption config in your IDP, otherwise you will not see a cert in the export
How can I change the Certificate used by my configured IDP?
When creating a realm, keycloak generates a RSA-SHA256 Cert which will by default be used by your configured IDP-Brokering Settings.
Go to Realm Settings -> Keys and you will see this one RS256 (RSA) with the provider (rsa-generated)
If you need another cert, switch to Providers Tab, Add Keystore e.g. rsa. Import your private key and certificate (both as PEM format!)
Back on the overview, disable the rsa-generated provider, your new generated provider should be the only active one with type RS256
If you now check the Export of your IDP again, the imported cert should be used inside the XML
I have set up a keycloak server. Then I created a realm an in that realm an SAML-IDP. So my keycloak server is a SAML-SP that uses that IDP for authentication. The IDP needs the SAML-Metadata. I can export it in the keycloak admin console in the "export" tab of the IDP Entry. I can also download it here:
http[s]://{host:port}/auth/realms/{realm-name}/broker/{broker-alias}/endpoint/descriptor
But the metadata does not contain a X509 certificate:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://keycloak.sample/auth/realms/nodejs-example">
<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol http://schemas.xmlsoap.org/ws/2003/07/secext">
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://keycloak.sample/auth/realms/nodejs-example/broker/idp.devel/endpoint"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
</NameIDFormat>
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://keycloak.sample/auth/realms/nodejs-example/broker/idp.devel/endpoint"
index="1" isDefault="true" />
</SPSSODescriptor>
</EntityDescriptor>
How do I get one into the metadata?
Question:
The SAML SP metadata does not contain a X509 certificate.
How do I get one into the metadata?
Answer:
It is OK that SAML SP metadata of Keycloak does NOT contain a X509 certificate if (I) Keycloak SAML SP does NOT need to sign SAML authentication request or (II) SAML IdP is NOT require to encrypt SAML assertion for Keycloak SAML SP.
(1) SAML SP metadata does NOT necessarily contain a X509 certificate. That is, X509 certificate is NOT mandatory for SAML SP metadata.
For example, both Google G Suite and ComponentSpace provide SAML SP metadata without X509 certificate.
(I) SAML SP metadata of Google G Suite does NOT contain a X509 certificate. I uploaded SAML SP metadata of Google G Suite into Shibboleth SAML IdP server and then logged in to Google G Suite through SAML authentication provided by Shibboleth SAML IdP successfully.
For your reference on SAML SP metadata without X509 certificate, I have made the 14th commit to upload the Google G Suite SAML SP metadata and corresponding SAML configuration to How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository.
(II) The ComponentSpace Development provides the guidance on how to generates SAML service provider metadata with no certificates.
No signature or encryption certificates were specified so no certificates were included in the generated metadata.
ExportMetadata.exe
SAML configuration file to export [saml.config]:
X.509 signature certificate file [None]:
X.509 encryption certificate file [None]:
Assertion Consumer Service URL [None]: http://localhost:51901/SAML/AssertionConsumerService.aspx
Single Logout Service URL [None]:
Partner Identity Provider Name [None]:
SAML metadata file [metadata.xml]:
(2) SAML SP metadata needs to contain a X509 certificate if SAML SP needs to sign SAML authentication request or SAML IdP needs to encrypt SAML assertion.
(3) Quite different from SAML SP, SAML IdP metadata should contain at least one X509 certificate for signing SAML response/assertion.
Follow-up answer provided by Galdor:
If you require SAML IdP to encrypt SAML assertion for Keycloak SAML SP
(I) Set "Want Assertions Encrypted" in the IDP-Configuration to ON and instantly the X509Certificate entry appears in the Export tab.
(II) Download SAML SP metadata of Keycloak, which should contain X509 certificate for encryption.
According to winstonhongs answer the keycloak server doesn't need a certificate in this configuration.
I set "Want Assertions Encrypted" in the IDP-Configuration to ON and instantly the X509Certificate entry appears in the Export tab.
You can now in KC 13.0.1 sing your metadata with your realm keypair.
Check more here: https://www.keycloak.org/docs/latest/server_admin/#saml-v2-0-identity-providers
Sign Service Provider Metadata - If true, it will use the realm’s keypair to sign the SAML Service Provider Metadata descriptor.
deploying WSO2 Identity Server as SAML IdP - there can be several keypairs (private key / certificate) in play:
SSL keypair / certificate for administration console or/and services
this seems to be configured in carbon.xml
keypair / certificate to sign the SAML responses - apparently the same keypair is used. Is it possible / where to configure the SAML IdP certificate?
Best regards
Gabriel
Apparently the resident IdP uses the key configured in the carbon.xml / Security / Keystore
To update the default keystores check the resources:
http://sencs.blogspot.be/2015/03/how-to-change-default-keystores-and.html
https://docs.wso2.com/display/MB220/Changing+Default+Keystores
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."
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