A complete guide to understand and implement the SAML security standard
MOHAMMAD HASAN NEMER | WEB APPLICATION SECURITY |5-12-2023
2.2 How is SAML used with web applications
5.2.1 Create ASP.NET Core Web App
5.2.2 Configure a view to display user claims
This project aims to provide a comprehensive understanding of the SAML (Security Assertion Markup Language) security standard, by examining the main concepts underlying this authentication standard. Including its workflow, strengths, weaknesses, and potential vulnerabilities. Additionally, this project includes a step-by-step implementation guide, offering practical insights into deploying SAML effectively within a web application environment.
SAML is an open standard used for authentication it first started in 2001, the version 2.0 came in 2005. Based upon the XML format, web applications use SAML to transfer authentication data between two parties - the identity provider (IdP) and the service provider (SP). SAML works by exchanging user information, such as logins, authentication state, identifiers, and other relevant attributes between the identity and service provider. As a result, it simplifies and secures the authentication process as the user only needs to log in once with a single set of authentication credentials using the SSO (single sign on) concept. So, when the user tries to access a site, the identity provider passes the SAML authentication to the service provider, who then grants the user entry.
SAML is widely adopted enterprise solution it provides:
- Improved user experience by sign in once to access multiple web apps.
- Speed up the authentication by remembering one set of credentials
- Less calls for IT technical to change/rest passwords
- Server provider doesn’t need to store user credentials because the identity provider stores all login information
- Service provider don’t need to worry about the authentication of accounts because it is IdP’s responsibility that provide extra layer of security by implementing MFA
SAML protocol has three entities:
- User agent (user’s web browser)
- Service provider SP, our web application (RSK is used in this project)
- The identity provider IdP (Okta is used in this project)
Identity Providers (IdP) provide online resources to give authentication to end users over the network. Sometimes these are also called an identity Service Provider or an Identity Assertion provider.
Service Providers (SP) provide resources to an end user for Single Sign On (SSO).
A trust relationship is established between IdP and SP
The main components of SAML are:
- Assertions which defines the structure and content of the information being transferred
- A binding defines the communication protocols (such as HTTP or SOAP) over which the SAML protocol can be transported
- How an assertion is requested by, or pushed to, a service provider is defined as a request/response protocol encoded in its own structural guidelines
- Together, these three components create a profile (such as Web Browser Artifact or Web Browser POST)
- Metadata defines how configuration information shared between two communicating entities is structured. For instance, an entity's support for specific SAML bindings, identifier information, and public key information is defined in the metadata. The structure of the metadata is based on the SAML v2 metadata schema. The location of the metadata is defined by Domain Name Server (DNS) records.
- The user tries to access the SP must first authenticate to the IdP
- If the user manages to successful authenticate
- The IdP generates a SAML assertion
- The assertion is sent to the application
- since the application trust the IdP
- the user now is allowed to access the application
- since user is authenticated into IdP user can Single Sign On to other apps that are in the same area of trust
- The IdP know about our users and their attributes, and the SP has its own knowledge about the users
- The IdP generates an assertion and populate it with user identifier, sign it and send it to the SP. Note that both sides must agree on the SAML configuration for the user identifier for correct mapping in the SP side.
- The SP validate the assertion, and reads user identifier, allowing access to that user.
- The configuration for integration is critical to successfully establish SAML federation, these configurations can be entered manually to SP, or IdP as XML metadata file that contains the settings and the certificate of system
- These files now can be exchanged to configure federation
Trust is established between the SP and IdP
The metadata file contains the format of the user identifier called the NAMEID format which is standardized
The metadata contains the certificate that validate the assertion
The entity ID that indicate sender/reciever
- The user reaches the SP
- User is directed to IdP using request for authentication message
- The user asks the IdP for authentication
- If user is validated the IdP generates the SAML assertion
- The assertion is sent to user
- The assertion then is sent from user to SP
- The session starts
The main issue is if the user input is directly included in XML messages and sent to the backend server without being encoded, filtered and sanitized. The attacker then can inject additional XML, and modify the request.
This attack is mainly done at the IdP side if the used libraries are not strict to user input, that could insert the data into the template string (that the SAML XML is built from) using a template language, regex match/replace, or simple concatenation.
When constructing SAML responses, the identity provider often includes user-controlled data like SAML NameID (identifying the user) and additional attributes requested by service providers (e.g., full name, phone number).
Less evident fields, typically sourced from the SAML request, may also affect SAML responses:
InResponseTo Attribute: Contains the SAML request ID, commonly included in SAML responses, making it a prime target for probing XML injection vulnerabilities.
Issuer Field: Identifies the issuer of the SAML request, potentially included in the Audience field of SAML assertions.
IssueInstant: Indicates the time of SAML request generation, possibly included in assertion conditions like NotBefore.
Destination Field: Specifies the SAML request endpoint, which might be used in the Audience element of assertions.
In some instances, external data sources might influence SAML responses. For example, an unauthenticated client's SAML request might trigger a server redirect to a login page with a GET parameter containing the request's ID. Modifying this ID parameter during login could enable injecting XML into the resulting SAML response.
For more information, see https://research.nccgroup.com/2021/03/29/saml-xml-injection/
- Visual studio
- .net SDK version 6.0.0
- IdP will be Okta in this project
- SP service provider, RSK component is used in this project to be the SAML SP
Select the .NET 6.0 option, and make sure “configure for HTTPS” box is checked
Add this code to the Home controller
Create a page named Details.cshtml in the Views folder in the Home section
Configure this page to display user claims
Add it to the default _layout.cshtml page
Navigate for the NuGet package manager
Search for Rsk.Saml.IdentityServer4 package
Ask the IdentityServer.com for the license key, register, an email will be sent as follows:
Configure the Program.cs page
Sign in to Okta and create a new application
Create a SAML2.0 application
Configure the sign-on URL as the callback path we set above ,then click NEXT
Select I’m an Okta customer and click FINISH
Navigate for the “Sign on” section , you can find the metadata URL
Configure the Program file with the metadata URL
The user is directed to IdP to be authenticated
After user is verified, he is directed to the application
User claims are displayed; user is authenticated using SAML integration
- went deep in the SAML standard
- understand its components and its workflow
- know where and when to use it
- introduced SAML security risks
- simple implementation
The SAML security standard significantly enhances enterprise efficiency by centralizing security and authentication responsibilities under the Identity Provider (IdP). However, for a manager overseeing software services, trust in the chosen IdP is crucial. Ensuring the reliability and security measures of the contracted IdP becomes a critical task. Evaluating the IdP's security protocols, level of trustworthiness, and storage limitations is essential. By making informed decisions about IdP partnerships, managers can confidently fortify their systems and user data, ensuring robust security measures align with their operational needs.
This article is written using the following resources:
https://www.onelogin.com/learn/saml
https://youtu.be/SvppXbpv-5k?si=Er0zAH3atNWdF2y-
https://docs.oracle.com/cd/E19854-01/819-5209/gbpkr/index.html
https://research.nccgroup.com/2021/03/29/saml-xml-injection/