SAML Security Best Practices
Introduction
This document provides SecureAuth team members and customers best practices when configuring Security Assertion Markup Language (SAML) integrations, and assumes the reader has basic knowledge of SAML and the SecureAuth IdP product. These best practices ensure sensitive information within the SAML Assertion is transmitted securely between SecureAuth IdP and a service provider (SP).
Applies to
SecureAuth IdP Version | OS Version |
|---|---|
7.x+ |
|
Discussion
Product Version Considerations
SecureAuth recommends customers use a recent version of the product in order to leverage security enhancements and bug fixes provided in newer releases. If an older SecureAuth IdP version is currently in use, consider upgrading to a more recent version. Upgrades are free of charge with any support agreement in good standing. Contact the support team at support.secureauth.com for more information about upgrading SecureAuth IdP.
Communication Guidelines
When communicating with an SP, implement these best practices whenever possible
Do not use the SSL v2, SSL v3, and TLS v1 protocols to establish a connection to an SP – these protocols are insecure and therefore should not be used
TLS v1.2 is the preferred protocol to use when establishing a connection to the SP – it is the only version providing modern authenticated encryption
Whenever possible, only communicate with an SP that has a SHA-2 certificate
Choosing a Certificate
SAML workflows use an X.509v3 certificate to secure various parts of the Assertion and AuthnRequest. These best practices provide guidance on how to choose the right type of certificate
Use only SHA-2 certificates when designing new SAML workflows
In existing SAML workflows, replace SHA-1 certificates with a SHA-2 certificate at the earliest possible opportunity
A Self-signed certificate should never be used in a SAML workflow – use only a certificate issued from a trusted PKI CA
Though SecureAuth runs a PKI CA, SecureAuth advises not to use these certificates in SAML integrations. Use instead a certificate from a third-party vendor (e.g. GoDaddy, Symantec, etc.) – segregating these responsibilities enhances security
AuthnRequest
A Service Provider (SP) wanting to validate a user identity transmits an AuthnRequest to the Identity Provider (in this case SecureAuth IdP). The AuthnRequest can be signed to help ensure the request is being sent by a trusted SP. An SP that supports signing the AuthnRequest should be used in the integration. In configurations that do not sign the AuthnRequest, an intruder might spoof a request.
SAML Assertion
The SAML Assertion should be encrypted if this feature is supported by the SP. In a scenario in which an intruder can obtain a completed assertion, this practice of encrypting the SAML Assertion protects the information contained within.