Security Assertion Markup Language, or SAML, provides numerous benefits to enterprises, organizations and governments. One of its greatest assets is Single Sign-On (SSO), the ability to enable users to securely access multiple applications with a single set of credentials, entered once. With SAML, users and organizations can conduct business faster and more efficiently by seamlessly accessing multiple applications on the same domain or on multiple domains.
In the modern era of computing, security is of the utmost importance when it comes to enterprise applications. SAML is used to provide a single point of authentication at a secure identity provider, meaning that user credentials never leave the firewall boundary, and then SAML is used to assert the identity to others. There are five security checkpoints though that should be considered when implementing SAML SSO to your architecture.
1. Protect SAML Tokens being processed
Data in motion is protected by transport layer security. Data at rest can be protected by data encryption. Data being processed should be protected inside a secured container.
SAML tokens store private authentication and authorization data. Processing the token requires reading that data and making access control decisions. At that point of processing, the SAML data is no longer protected by encryption. So the platform where SAML tokens are processed is a major point of vulnerability.
That is why it’s critical to use hardened security for your identity federation or SSO platform. By intent, a hardened security platform removes vulnerabilities that would allow the platform and the data residing on it to be compromised. So wherever SAML Tokens are unpacked and processed for authentication or authorization, that platform must be designed with hardened security in order to protect the private identity data that is being processed.
2. Protect SAML Tokens in Motion
Transport layer security is critical for protecting SAML assertions moving between clients, servers, and identity providers. But not all TLS solutions are built to the same high levels of quality assurance. Some inherently lack security.
OpenSSL has had known quality issues for many years. Security flaws continue to be uncovered in OpenSSL each year (over 60 found since Heartbleed…so far). A SAML SSO solution using OpenSSL is not a secure choice for protecting access tokens in motion.
It’s an entirely unnecessary concession to accept after-the-fact patching as a strategy. There are far more reliable SSL/TLS solutions available that don’t depend on OpenSSL.
3. Securely Federate Identities
ADFS is a common case I encounter where teams wish to federate, via SAML, out to external cloud applications, or into enterprise hosted resources.
ADFS is not a secure platform and should not be directly exposed to the outside world. Case in point: ServerFault.com – Opening ADFS to the Public
The recommended architecture requires a secure proxy to broker identity data between internal and external clients and applications. If implemented correctly this segregates and protects your internal identity infrastructure, and enables internal users to securely access external cloud-hosted applications.
And again a hardened security platform should be used for identity federation, to ensure the identity data can be processed without risk of compromise.
4. SAMLs XML Vulnerabilities
In the rush to stand up a functioning SSO solution, the security implications of opening an XML-based pathway into a system can be missed. OWASP injection attacks that are readily detected in website HTML forms, may avoid detection if delivered in a different guise; such as in a SAML XML message. This XML vulnerability found in Facebook servers illustrates such a case.
Strong XML validation and XML content inspection is needed, at a minimum, to protect a SAML interface. Also, a strong XML processor should, by default, block XML vulnerabilities such as the XXE exploit on the Facebook servers.
5. Signature Verification is Key
The integrity and authenticity of a SAML token is ensured using digital signatures. It’s a way for the service provider to know that the information in the token is from a trusted source. It’s an absolutely key part of the system.
Like anything else, digital signatures can be compromised if not implemented correctly. Some basic points to cover in a design or review should include:
- Securely manage your keys and certs. Strictly control how keys are stored, where keys can be moved, and who has access to them at any time
- Track and enforce the latest industry recommended protocols, algorithms, and key sizes. Security is a moving target and you need to keep up!
- Offload the heavy crypto-processing to a device specialized for the task, to reduce the burden and increase the capacity of your servers. Look for a device that delivers on both high-performance and secure processing.
- Protect against Signature Wrapping Attacks, which targets weak signature verification in order to impersonate a valid user or identity provider. Schema validation with schema tightening is a good approach.
To learn more about SAML SSO its benefits and best practices for implementation download our whitepaper “How to Implement Enterprise SAML SSO”