IBM Security Verify

Expand all | Collapse all

Federation Best Practice certificates

  • 1.  Federation Best Practice certificates

    Posted 10 days ago
    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.  
    1. 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.
    2. 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?  
    3. SSL 3 is the RP protecting the SP and will provide access to all application once authorized.  Same question as number 2. 
    4. 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
    ------------------------------


  • 2.  RE: Federation Best Practice certificates

    Posted 9 days ago
    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
    ------------------------------



  • 3.  RE: Federation Best Practice certificates

    Posted 9 days ago
    Hi Jon.. this is a BIG help. I was not specific about the digital signature but for sure we plan to implement that. I am about to research the HTTPArtifact profile, I'm guessing this what you mean by Browser Artifact SAML 2.0 profile. The target SP is a windows server application that uses AssertionConsumerService. We can make a direct connection idP -> RP and windows (SP). I love the fact that we can  potentially keep the SAML assertion in house and never expose to the client. 

    At some point we may have a client that will have their own idP, will the HTTPArtifact implementation preclude this? In this case the SP will be unique for that client.  
    Thanks!

    ------------------------------
    Kelly Kerr
    ------------------------------



  • 4.  RE: Federation Best Practice certificates

    Posted 9 days ago
    Hi Kelly,

    Using the Artifact binding requires that the SP be able to make a direct connection to the IdP (or IdP Reverse Proxy if IdP is Verify Access).

    In cases where the IdP is exposed to the internet, this is usually no issue.  It gets more tricky when the IdP is hosted on an Intranet (and clients outside the network connect via VPN) because in that case an SP in another organization can't make that direct communication.  That's one reason why Browser POST binding is more popular because it only requires connectivity from browser to IdP and browser to SP.  No direct SP->IdP connection needed.

    Both bindings exist to give you the choice depending on architecture and security requirements.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 5.  RE: Federation Best Practice certificates

    Posted 9 days ago
    What I usually do is to have different stores based on their used.
    Keystore for document signing used in federations
    Keystore for encryption used in federations
    Keystore for SSL communication with partners used in federations
    Keystores for SSL with reverse Proxy (pdsrv)

    And for different backend servers, if required for mutual authentication or one-way authentication, usually one keystore is enough.

    For user authentication, I use different ones.

    I also use a different keystore for external services (DB Server, LDAP servers).
    And of course for the internal services (rt-profile-keys)

    I believe I covered most of them!
    Good luck

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    ------------------------------