Why do we need SAML?

Consider a service provider that hosts multiple applications for a company. The company’s users need seamless access to these applications. In a traditional setup, the service provider would need to maintain a separate user database for the company. This creates several challenges for the involved stakeholders:

• The service provider must ensure the security of user data.
• The company must validate users and keep their data up to date in both its own database and the service provider’s database. For example, if a user is removed from the company’s database, they must also be removed from the service provider’s database.
• Users are required to log in separately to each application hosted by the service provider.

SAML authentication addresses these issues by offering the following benefits:

• The service provider no longer needs to maintain a user database for the company, allowing it to focus on providing better services.
• The company no longer has to ensure that its user database is synchronized with the service provider’s database.
• Users can log in once to any hosted application, and they will automatically be logged into other applications on the same platform.

NetScaler SAML

NetScaler SAML (Security Assertion Markup Language) is a feature provided by Citrix NetScaler that enables Single Sign-On (SSO) authentication for web applications. It allows for seamless identity federation and secure authentication between an identity provider (IdP) and a service provider (SP).

Identity Provider And Service Provider

In the context of SAML (Security Assertion Markup Language) and Single Sign-On (SSO), the terms Identity Provider (IdP), Service Provider (SP), and Principal are essential to understanding the authentication and authorization process:

1. Identity Provider (IdP)

• The IdP is the entity that authenticates users and manages their identity.
• It is responsible for verifying the identity of the principal (user) and issuing authentication tokens (SAML assertions) that are used to grant access to services. Once the user is authenticated, identity provider produces an authentication assertion for the user to present to the service provider.
• The IdP typically manages user credentials (username, password) and may also support multi-factor authentication (MFA).
• Examples of IdPs include services like Okta, Active Directory, Google Identity,Radius and others.

2. Service Provider (SP)

• The SP is the application or system the user is trying to access, which relies on an IdP to authenticate users.
• It does not handle the authentication process directly but instead redirects the user to the IdP for authentication.
• Service provider is responsible for providing the resource or service requested by a user. It requires a SAML assertion to be presented as proof of authentication and verifies the assertion claim with the identity provider before granting access for the user.
• After successful authentication, the IdP returns a SAML assertion to the SP, which contains user identity information (claims) that the SP uses to authorize access.
• Examples of SPs include Salesforce, G Suite, Amazon Web Services (AWS), or any other cloud or on-premises application that requires secure access.

3. Principal

• The Principal is the user or entity attempting to access a resource. The principal can be a human user, a service, or a machine that requires authentication.
• In SAML terminology, the principal is typically the user who interacts with the IdP to get authenticated.
• The IdP identifies the principal and, after successful authentication, sends the principal’s identity and attributes to the SP via the SAML assertion.

Summary of Roles:

• IdP (Identity Provider): Authenticates the principal and provides identity assertions to the SP.
• SP (Service Provider): A web application or service that relies on the IdP to authenticate the principal.
• Principal: The user (or entity) who is trying to access a resource, whose identity is authenticated by the IdP and authorized by the SP.

In the SAML flow:

1. The principal (user) tries to access the SP (e.g., an application).
2. The SP redirects the user to the IdP for authentication.
3. The IdP authenticates the principal, generates a SAML assertion, and sends it back to the SP.
4. The SP uses the assertion to grant the principal access to the resource or service.

Few other SAML definitions

Definitions of Key SAML Terms:

1. Assertion: A SAML assertion is an XML document issued by the Identity Provider (IdP) that contains statements about the user’s identity, attributes, and permissions. The Service Provider (SP) uses the assertion to verify that the user is authenticated and authorized to access resources.

2. ACS (Assertion Consumer Service) URL: This is the endpoint on the Service Provider (SP) where the Identity Provider (IdP) sends the SAML response after user authentication. The ACS URL processes and validates the assertion to grant or deny access to the requested resources.

3. Protocol: In SAML, the protocol defines the set of rules and steps for exchanging authentication and authorization data between the IdP and SP. The primary protocol used in SAML is the HTTP Redirect and POST protocols, which govern how messages are transmitted during authentication.

4. Binding: A binding in SAML specifies the transport mechanism or method used for exchanging messages (e.g., HTTP-POST, HTTP-Redirect). For instance, the HTTP-POST binding transmits data in an HTML form, while HTTP-Redirect binding sends information via URL parameters. Bindings ensure that data flows securely and consistently.

5. Profile: A SAML profile is a predefined use case that details how SAML should be used in specific scenarios, such as Web SSO (Single Sign-On). Profiles standardize SAML usage across applications, ensuring compatibility and simplifying implementation.

6. Authentication Context: This element describes the authentication method or strength used by the IdP to verify a user’s identity, such as multi-factor authentication, password, or biometrics. The SP can specify required authentication contexts, and the IdP responds by detailing how the user was authenticated.

7. Skew Time: Skew time is the allowed time difference between the clocks of the IdP and SP servers, accommodating minor clock discrepancies. This is important for validating timestamps in SAML assertions, where even small mismatches can lead to assertion rejection. Typical skew time tolerance is 1-3 minutes.

8. Metadata: Metadata in SAML is an XML file containing configuration details for each party (IdP and SP). It includes information like entity IDs, ACS URLs, certificates, and supported bindings. Metadata files are exchanged to establish a trusted relationship between the IdP and SP, allowing seamless communication and secure data exchanges.