Security Assertion Markup Language, or SAML for short, is an XML-based, open authentication standard. It enables the secure exchange of authentication and authorization data between different, trusted parties. These are usually an identity provider (IdP), such as Engity, and an application, also known as a service provider (SP). The SAML standard allows users to access multiple applications with a single authentication or login (Single Sign-On, (SSO)). This is achieved through the use of XML-based database packages (also called assertions) that transmit authentication and authorization information between the entities.
By centralizing identity management and reducing the number of passwords required, SAML simplifies user access to enterprise applications and cloud services. This improves both security and user-friendliness.
SAML was developed from 2001 onwards by the OASIS consortium. OASIS stands for Organization for the Advancement of Structured Information Standards and is an international, non-profit organization. It focuses on the further development of e-business and web service standards, such as OpenDocument and DocBook, and maintains security-relevant standards like SAML.
There are currently three main versions of SAML: SAML 1.0, SAML 1.1, and the current, widely used version, SAML 2.0. This replaced its predecessors from 2005 onwards and offers improved features such as Single Logout (SLO) or name ID management and more robust security such as encryption of communication between identity provider and service provider. SAML 2.0 is the current standard, although many systems still support earlier versions like SAML 1.1 for compatibility reasons.
How SAML Works: A Technical Overview
The SAML process begins when a user attempts to access a protected resource provided by the service provider. The service provider detects that the user is not authenticated, generates an authentication request, and redirects the user to the identity provider. The identity provider prompts the user to log in, for example, with an e-mail address and password, and upon successful authentication, generates an SAML assertion - a signed XML document (a more detailed explanation follows in the next chapter). This assertion contains information about the user’s identity and all relevant attributes (e.g., roles), which are then sent back to the service provider via the browser. The service provider validates the assertion by checking the signature and, if necessary, other security aspects such as the validity period. It then grants the user access to the requested resource.
Key SAML Components: Assertions, Protocols, Bindings, and Profiles
SAML is based on several key components to enable secure access via a Single Sign-On (SSO) process. These components define how messages are created, transmitted, and processed, ensuring secure and efficient communication between the identity provider and the service provider. They comprise four different types: Assertions, Protocols, Bindings, and Profiles.
SAML assertions
The foundation of the SAML framework consists of SAML assertions (XML documents containing user data). These are created by the identity provider (IdP) and contain statements about a user’s identity, authentication, and authorization. There are three types of SAML assertions, which are digitally signed to ensure their integrity and authenticity.
- Authentication Assertion: These assertions confirm that a user has been authenticated by the identity provider and include the method and time of authentication.
- Attribute Assertion: This assertion contains specific information about the authenticated user. In the form of attributes such as name, role, and permissions, this information is packaged into a certified statement to confirm and transmit identity, authentication, or authorization.
- Authorization Decision Assertion: These assertions indicate whether the authenticated user is granted access to a specific resource or not.
SAML protocols
Protocols in SAML define the rules for requesting and exchanging assertions between the respective entities and each fulfills a specific function in the SAML workflow. These protocols are encoded using predefined XML tags, similar to SAML assertions. The following describes the most important core protocols that ensure authentication and authorization processes are carried out securely and efficiently.
- Authentication Request Protocol: This protocol defines how a service provider sends an authentication request to the identity provider, asking it to verify the user’s identity.
- Artifact Resolution Protocol: This protocol is used for transporting SAML messages between the IdP and the SP. It involves requesting and transmitting small artifacts, which simplifies the exchange of specific protocol messages.
- Single Logout Protocol: This protocol manages the process of simultaneously logging a user out of multiple applications and allows all active sessions to be terminated at the same time.
- Name Identifier Management Protocol: This protocol allows the management or modification of user identities (name identifiers), such as changing the username during federated single sign-on. It also allows the removal of connections between a service provider (SP) and an identity provider (IdP) for a specific user.
- Assertion Query and Request Protocol: This protocol defines how existing or new authentication assertions can be requested.
SAML bindings
SAML bindings define how SAML messages are transported between an identity provider (IdP) and a service provider (SP) over various transport protocols such as HTTP, SOAP, or others. Each binding has its own use cases and advantages. Among the most important are HTTP Redirect Binding, HTTP POST Binding, SOAP Binding, and HTTP Artifact Binding.
- HTTP Redirect Binding: Used for transferring SAML messages into URL parameters via HTTP redirection; often for requests from the SP to the IdP.
- HTTP POST Binding: Transports SAML messages in an HTML form. Sent from the user’s browser to the SP.
- HTTP Artifact Binding: The IdP sends a small “artifact” (a reference) via the browser to the SP, which then requests the assertion from the IdP. The key feature is that the actual communication between the IdP and SP occurs via a direct server-to-server query (back channel). This reduces the attack surface for attackers.
- SOAP Binding: SOAP bindings use the Simple Object Access Protocol (SOAP) for exchanging SAML messages. These are encapsulated in SOAP envelopes (digital envelopes) and sent via HTTP or HTTPS.
SAML profiles
SAML profiles are the “blueprints” that define how assertions, protocols, and bindings work together to make SAML function in practice. For example, while assertions provide the data, profiles provide the rules and flow to implement federated identity management and single sign-on. Below are some examples of important SAML profiles:
- Web Browser SSO Profile: Enables SSO via web browser, allowing users to log in once to seamlessly access multiple services.
- Name Identifier Management Profile: Manages user aliases and enables notifications of changes. For example, if an employee leaves a company, access can be disabled across the entire federated environment using their profile.
- Single Logout Profile: Defines how the logout process is handled simultaneously for all connected services that are currently active for a specified user.
- Attribute Query Profile: Describes how a service provider can request additional user attributes from the identity provider after initial authentication.
Advantages of Implementing SAML for Identity Management
One of the main advantages of implementing SAML is improved security through Single Sign-On (SSO). With SSO, users only need to authenticate once to access multiple applications, reducing the risk of password fatigue and the likelihood of weak passwords. This streamlined authentication process not only improves security but also the user experience, as multiple logins are no longer required.
Furthermore, SAML shifts the responsibility for managing and storing user credentials to an identity provider. This ensures that authentication data is not shared with service providers or stored within individual applications, further reducing the risk of credential theft. Centralizing authentication also allows organizations to enforce robust password policies, granular access controls, and stricter security measures such as multi-factor authentication, creating a more resilient and secure environment. SAML also saves time and money by reducing tasks associated with managing multiple accounts and passwords, resulting in fewer help desk calls and password resets.
Another advantage of SAML is its support for Federated Identity Management (FIM). Federated identity allows users to access resources across different organizations and domains with a single set of credentials. By enabling federated identity, SAML facilitates seamless collaboration and resource sharing while maintaining robust security controls. This is particularly beneficial for organizations operating in complex, interconnected ecosystems or multi-domain environments, or those collaborating with external partners and therefore requiring integration with third-party services.
Furthermore, SAML offers scalability and flexibility, making it suitable for companies of all sizes. And thanks to its open standard, it can be implemented in diverse environments and on a wide variety of platforms, ensuring compatibility with existing systems and future technologies.
SAML Compared to Other Identity Management Protocols
While SAML is a widely used standard for identity management, it is not the only available protocol and is being used less frequently compared to others. This is because other protocols such as OAuth 2.0, OpenID Connect (OIDC), and Kerberos are playing a significant role. Each protocol has its own strengths and use cases, and understanding the differences between them can help in selecting the most suitable solution for specific requirements.
SAML vs. OAuth 2.0
OAuth 2.0 (Open Authorization) is a widely used open standard for access delegation. It is frequently used to grant third-party applications restricted access to user resources without exposing login credentials. Unlike SAML, which focuses on authentication and authorization, OAuth primarily concerns authorization and can be used with either OpenID Connect or SAML to enable single sign-on. Therefore, OAuth 2.0 and SAML are not alternatives, but rather complementary technologies.
SAML vs. OpenID Connect (OIDC)
OpenID Connect (OIDC) and SAML are both protocols for user authentication, offering federated identities and single sign-on (SSO) functionality. Historically, SAML remains widespread, particularly in enterprise environments, as many existing enterprise applications support this protocol. OIDC, on the other hand, takes a more modern and simpler approach to authentication. Besides its traditional enterprise use, OIDC is therefore especially popular in web and mobile applications. It is considered easier to integrate, is gaining wider acceptance, and has established itself as the preferred standard in modern architectures. Consequently, OIDC is increasingly replacing SAML, leading to a rise in the use of OIDC infrastructures instead of the SAML protocol in modern environments.
SAML vs. Kerberos
Kerberos is another authentication protocol. It is older than SAML and widely used in many enterprise networks, especially Windows domains. It relies on a trusted third-party service, the Key Distribution Center (KDC), to authenticate the identity of users and services. To do this, Kerberos provides cryptographic tickets for accessing resources without sending passwords over the network. Kerberos is particularly secure and efficient for internal network authentication. However, compared to SAML, it is less suitable for web-based and federated identity scenarios.
Common Use Cases for SAML in Companies
SAML was frequently used in enterprise environments to enable single sign-on (SSO) for multiple applications and services, but is now regularly replaced by OpenID Connect (OIDC) in new projects. However, especially in existing infrastructures where OIDC is not yet fully established, SAML remains a stable and proven solution.
Educational institutions, such as schools and universities, have frequently used SAML to provide their students and teachers with access to a variety of online resources, such as library databases and collaboration tools. SAML enabled seamless access to these resources, improving the user experience and reducing the administrative overhead that automatically comes with managing multiple accounts. In addition, SAML’s support for federated identity management allowed educational institutions to collaborate with other organizations and securely share resources.
Public sector organizations and authorities also still use SAML’s functions. These entities often need to provide citizens, employees, and contractors with secure access to sensitive information and services. The support for federated identities and the robust security features made SAML an ideal solution for these environments at the time. It enabled agencies to ensure that only authorized individuals had access to critical resources while simultaneously facilitating secure collaboration with external partners and other agencies. This enhanced both security and operational efficiency, making SAML a valuable tool for the public sector.
Best Practices for the Secure Implementation of SAML
Before deciding to implement SAML, it should be considered whether it would be more sensible to use the more modern and powerful OpenID Connect protocol.
Should the decision to implement SAML be made after careful consideration, it is essential to follow best practices to ensure the security and integrity of the identity management system. One of the most important aspects is ensuring that all SAML assertions are signed and encrypted. This prevents tampering and unauthorized access to sensitive information. The use of strong cryptographic algorithms and the regular updating of encryption keys are also important measures for maintaining the security of SAML messages. Furthermore, organizations should validate SAML assertions to ensure they originate from trusted identity providers.
Another best practice is to implement robust access controls and policies. This includes defining clear roles and permissions for users and ensuring that access is granted according to the principle of least privilege. Regularly reviewing and updating access controls is crucial to prevent unauthorized access and ensure that users can only access the resources they need. Implementing multi-factor authentication (MFA) can further enhance security by adding an extra layer of verification for users accessing sensitive resources.
Monitoring and audits are also essential components of a secure SAML implementation. Organizations should implement logging and monitoring mechanisms to track SAML transactions and detect suspicious activity. Regular audits of the SAML infrastructure can help identify and address potential vulnerabilities and ensure compliance with security policies and regulations. By following these best practices, organizations can leverage the full potential of SAML while maintaining a secure and robust identity management system.
Troubleshooting for Common SAML Problems
Even with SAML, organizations can encounter common problems during implementation and operation. One frequent issue is misconfiguration, which can lead to authentication failures and access problems. This can occur if the identity provider and service provider are not correctly configured to communicate with each other. Ensuring that metadata, certificates, and endpoint URLs are configured correctly can prevent such problems. Regular testing of the SAML setup and thorough configuration reviews can also identify and resolve potential issues before they impact users.
Another common problem is time synchronization between the respective servers of the identity provider and service provider. SAML relies on highly accurate timestamps to ensure the validity of assertions. If the clocks on the servers are not synchronized, this can lead to authentication failures. Implementing the Network Time Protocol (NTP) on all servers involved in the SAML process helps maintain accurate time synchronization and avoid problems caused by time discrepancies. Furthermore, configuring appropriate time discrepancy tolerances can provide some flexibility in handling minor time differences.
Mapping user attributes is another area where problems can arise. If the identity provider (IdP) and the service provider (SP) cannot agree on the format and names of user attributes, this can lead to issues with user provisioning and access control. A clear definition and mapping of user attributes between the identity provider and the service provider is essential to ensure that the correct information is exchanged and used for authentication and authorization. Regularly reviewing and updating attribute mappings can help prevent problems and ensure a smooth SAML implementation.