Today I would like to focus on SAML protocol and how it is used for SSO authentication. Since I have discovered this option, I really liked it. The configuration is quite user friendly and I believe understanding its components may be useful and time saving.
Let’s dive in! When we talk about Single Sign-On (SSO), one of the most common protocols you’ll come across, is SAML, which stands for Security Assertion Markup Language. It’s an open standard that allows identity providers (IdPs) to securely pass authentication and authorization data to service providers (SPs).
In simple terms, SAML makes it possible for a user to log in once – usually with their corporate credentials – and then gain access to multiple applications without having to sign in again. For example, when you sign in to your company’s portal – you will also be able to access tools like Jira, Salesforce, ServiceNow, or Microsoft 365 – that’s SAML at work.
The way it works is straightforward:
- The user tries to access an application (the service provider).
- The service provider redirects the user to the identity provider for authentication.
- The identity provider verifies the user’s credentials and sends back a SAML “assertion” (a secure XML-based message) confirming their identity.
- The service provider grants access based on that assertion without a need of a separate login.
How do you configure such an application?
Connect to Azure Portal using URL https://portal.azure.com with the account that have rights to create Enterprise applications. Search for Enterprise Applications if it’s not displayed in Azure services.
Click New application.
You will be redirected to the Browse Microsoft Entra Gallery which is a catalog of applications that makes it easy to deploy and configure single sign-on authentication. If you can’t find your desired app in the gallery, you can create your own using a non-gallery option.
In the application properties, you can choose whether the assignment is required or not:
Assignment required = Yes means that:
- Only users and groups that are explicitly assigned to the application in Azure AD can sign in.
- If someone tries to access the app without being assigned, they’ll get an error (e.g. “You can’t access this application”).
- This is typically used when you want to tightly control access — for example only the HR team should see the HR system.
Assignment required = No means that:
- Any user in the tenant can try to sign in (assuming the app accepts their login).
- This is more “open” and sometimes used for apps that everyone in the organization should be able to use.
It is important because it’s a security control: you don’t want unlicensed or unauthorized users accessing sensitive apps. It’s also used for license management: some SaaS apps charge per assigned user, so restricting access avoids unexpected costs. Combined with self-service access, you can even let users request assignments to apps, subject to approval. For example: If you configure Assignment required = Yes for Salesforce, then you must assign users to a group in Azure AD → Enterprise Application → Users and groups. Otherwise, nobody can log in.
Interesting point: It is not possible to fully automate the creation of a non-gallery enterprise application with SAML configuration visible in the portal solely via PowerShell or Microsoft Graph API. The “SAML” single sign-on method only appears for apps created through the Enterprise Applications blade in the portal, using the “Create your own application” flow. Scripts (PowerShell/Graph) can create custom apps and set SAML preferences, but they do not expose the SAML configuration wizard in the portal UI – it’s a limitation confirmed by Microsoft. The only reliable method to make the SAML configuration is available from GUI.
Let’s cut to the chase. The configuration is fairly easy:
You need to select Single sign-on on the left pane then select SAML.
Once SAML is activated you can upload XML metadata file provided by application owner.
If no XML metadata file is not provided, you can configure Identifier, Reply URL, claims and attribute in this section.
Identifier and Reply URL are two core values needed for SAML SSO to work. They basically tell Azure AD what the application is and where to send the SAML response.
Identifier (Entity ID)
- The Entity ID uniquely identifies the Service Provider (the application) in the federation.
- It’s usually a URI/URL string defined by the app vendor (but it doesn’t need to be a resolvable link).
Reply URL (Assertion Consumer Service URL, or ACS URL)
- The ACS URL is where Azure AD sends the SAML response after authenticating the user.
- It must be an HTTPS endpoint on the application side, and the app must be listening for SAML tokens there.
- The app validates the token, establishes the user session, and logs the user in.
When you configure that, the next step is to configure attributes and claims.
They are not mandatory but it’s good to understand what they do.
In fact, this is the point where Azure AD determines which user information is included in the token and sent to the target application (the Service Provider), whether it’s a SAML assertion or a JWT for OpenID Connect/OAuth. Attributes are the pieces of information (user properties or directory data) that can be sent. Examples: userPrincipalName, givenName, surname, email, department. Whereas claims are the actual statements issued inside the token, based on attributes such as “email”: luke@contoso.com.
When you create a new non-gallery Enterprise Application and enable SAML SSO, Azure AD typically sends these default claims:
- http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier → by default maps to user.userprincipalname (this is the SAML NameID).
- givenname → user.givenname
- surname → user.surname
- emailaddress → user.mail
- name → user.displayname
These defaults can be customized. Applications often require specific identifiers for users. For example: Some apps require email as a unique identifier (NameID) while others may require an employee ID or UPN. You may need to add custom claims like groups or roles to drive app-specific authorization.
Once configuration is done, you will need to download Federation metadata XML and send it to the application owner in order to configure his application with SAML.
Configuring SSO with SAML in Azure AD may seem complex at first, but once you understand the purpose of the Entity ID, Reply URL, and attributes & claims, the process becomes much clearer. With a non-gallery enterprise application, you can connect almost any service to Azure AD and give users a seamless, secure sign-in experience. I hope this article will be useful for all the people who struggle with that configuration.
Leave a Reply