Hi Kelly,
I think you're OK for SSL1. As you say, this should be a certificate signed by a well-known CA so that browsers can connect without any warning/error. Just the same as for any other web server. Private key lives in the Reverse Proxy key database.
SSL2 is a server certificate for the IdP backend. Private key lives on the backend server. The signer certificate (same cert if self-signed) needs to be loaded to Reverse Proxy. In most cases it's not necessary to use a different key database for the junctions but it doesn't hurt. In most cases a self-signed certificate works fine for this connection given that it is essentially only providing point-to-point trust. Make sure you put the expiry of this cert in your diary so it doesn't expire.
SSL3 has same considerations as SSL2.
If you want to encrypt the SAML 2.0 token then you have a (decryption) private key on the SP and you provide the associated certificate to the IdP. Usually this certificate is provided in the SP metadata. You are correct that only the SP needs to decrypt the assertion. You should use different key+certificate for this, yes.
I would comment that usually when you want to prevent SAML token from being visible to browser, it is more common to move to using the Browser Artifact SAML 2.0 profile so that the SAML token doesn't flow via the browser in the first place. If networking allows SP to make a direct connection to IdP (maybe via Reverse Proxy) then this is probably a better solution in my opinion.
In this flow you have not mentioned SIGNING certificates. These are the most important certificates in the security of the SAML 2.0 assertion so worth considering them too. The signing certificate can also be self-signed. It is a private key that lives on the IdP. Associated certificate is provided to all SPs so they can validate signatures. Certificate is provided in IdP metadata. Security of this key is important - attacks against federations often involve stealing the IdP signing private key (allowing assertion to any SP as any user). Best practice dictates that you should use a different keys for signing and encryption.
I hope this helps.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Tue May 04, 2021 04:17 PM
From: Kelly Kerr
Subject: Federation Best Practice certificates
I'm trying to determine best practice for certificates in a new federation that we are setting up. Our organization controls the Reverse Proxy (RP) and all components behind. They are in our protected space.
- SSL 1 is fairly straight forward as long as we have a CA produced private/public in the keystore. Referenced in Config file with entry webseal-cert-keyfile.
- SSL 2 /isam junction to idP. Should we create a separate keyfile for the junction and use config entry jct-cert-keyfile? Is there a best practice for this given all services behind the junction is within our secure network?
- SSL 3 is the RP protecting the SP and will provide access to all application once authorized. Same question as number 2.
- Let me see if I understand the idP encryption. My guess is that the SAML 2.0 token would be encrypted, then unreadable on the browser trace as the redirect to the SP. The SP would be the only component that would need to decrypt the SAML token. Please correct me if this is wrong. Should I create separate certificates for this piece?
Thanks..
------------------------------
Kelly Kerr
------------------------------