How do you import or configure the certificate for a Remote IDP after certificate rollover?
Is it possible to validate the SAML response in AM just by adding the x509 public certificate in the SAML assertion that is sent by the IDP so we don’t to worry about CA rollover?
The IDP can be configured to send the x509 certificate in the SAML Response to AM.
The IDP is a third party software, SP and both the IDP have been configured in AM - but now we need to manage the rollover of the signing certificate from the IDP.
You will need to get a new version of the SAML metadata and then delete/re-import your IDP’s metadata to get the new certificate picked up.
You should not trust random certificates you receive in SAML responses, that is a terrible idea.
Hi @peter.major.idf,
We have control over sending party of SAML response, as it is within organization and trust the certificate of as specific IDP that is linked over a certificate chain to a Root CA.
Please support with steps, if signature can be verified by X509 Cert (public key) from SAMLResponse.
Regards,
Hi @atul-k-db - From everything I can see looking at the code it really doesn’t matter if you trust the certificate itself, the important thing is that you’ve associated that certificate with the SAML entity within your configuration and this is done via the import of the SAML metadata.
With signature verification you are not validating the details of the certificate itself, you are validating either that a) the public key provided in the assertion matches a public key you have associated to the SAML entity AND the key generates the same signature for the assertion or b) the key you have already associated with the SAML entity generates the same signature for the assertion.
To trust a certificate in an assertion simply because you trust the root CA and without prior association of the certificate to the SAML entity would open you up to the risk of anyone who can get a certificate from that root CA generating an unsolicited SAML response to your application and your application trusting the response simply because you trust the root CA.
tl;dr - yes the signature can be verified by the x509 cert in the SAML response, but only if the certificate has been previously associated with the SAML entity that the response is coming from. The method to associate a certificate to a SAML entity is through the import of the SAML metadata. If you have extensively configured the IDP within AM, the best approach would be to export the entity via Amster, update the X509Certificate in the $.data.metadata property, and re-import the entity via Amster. Otherwise, simply having the IDP re-generate the metadata and then deleting the entity and re-importing the metadata.
In AM 7.x, you can import more than one certificate for IDP/SP configurations yet only 1 can be active. This allows you to “prep” for the cert roll-over in advance then “flip” the key material at the appropriate time.
In ForgeRock Identity Cloud, there’s a feature to have 2 active certs, this feature will be incorporated into the stand-alone AM as a new feature in the near future.
Hi @peter.strifas, hope you are doing well! Does the functionality you’ve described apply to the signature of remote IDPs? The documentation in AM on secrets rotation via secret stores (which I believe is what you are referring to) only indicates that (for this use case) we can rotate the keys used by AM for signing outbound (SP to IDP) request and decrypting inbound (IDP to SP) assertions (see Map and rotate secrets :: AM 7.3.0 and Knowledge - ForgeRock BackStage). The use case covered here is around the signature of the inbound assertion (IDP to SP).
Hi Peter - yes, the table shows both SP and IDP, but the key here is which role AM is playing as that is the only certificate(s) which AM manages via the secret store. In the case of an inbound assertion from an IDP where AM is the SP, none of these values would come in to play as it is the IDP that is signing the assertion. The only corresponding entry in that table for SP signing is am.default.applications.federation.entity.providers.saml2.sp.signing, which only applies to the signature of requests made by the SP.
SAML 2.0 secrets for hosted SP or IDP entities are managed by the secrets API
@riponmann and @atul-k-db have asked about a means for rolling remote IDP certificates, and I believe that as previously stated the only way to manage that is via the metadata.