Skip to main content

SAML Security Best Practices


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


  • Windows Server 2008

  • Windows Server 2008 R2

  • Windows Server 2012

  • Windows Server 2012 R2


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 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


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.