assignment required sso

Mickaël Derriey's blog

© 2024 Mickaël Derriey

Powered by Jekyll and GitHub Pages Theme based on Hyde by @mdo with modifications by @todthomson

The consequences of enabling the 'user assignment required' option in AAD apps

Introduction.

Applications in Azure Active Directory have an option labelled “user assignment required”. In this blog post, we’ll talk about how this affects an application.

💡 Quick heads-up — all the examples in this blog post are based on a web application using AAD as its identity provider through the OpenID Connect protocol.

By default, applications created in Azure Active Directory have the “user assignment required” option turned off, which means that all the users in the directory can access the application, both members and guests.

While this might sound like a sensible default, we find ourselves at Readify with a growing number of guests in the directory as we collaborate with people from other companies. Some of our applications contain data that should be available to Readify employees only, so we decided to make use of the “user assignment required” option.

To access this option, in the Azure portal, go to “Azure Active Directory > Enterprise applications > your application > Properties” and the option will be displayed there.

Some of the behaviour changes were expected, but others were not! Let’s go through them.

1. People not assigned to the application can’t use it

Well, duh, isn’t that what the option is supposed to do?!

You’re absolutely right! If someone that hasn’t been explicitly assigned to the application tries to access it, then AAD will reject the authorisation request with a message similar to the following:

AADSTS50105: The signed in user ‘Microsoft.AzureAD.Telemetry.Diagnostics.PII’ is not assigned to a role for the application ‘<application-id>’ (<application-name>)

The message is straightforward and the behaviour expected.

There are several ways to assign someone to the application. I typically use the Azure portal, navigate to “Azure Active Directory > Enterprise applications > my application > Users and groups” and add them there.

2. Nested groups are not supported

This is the first surpise we had. It’s our bad, because it’s well documented on that documentation page in the “Important” note: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-saasapps

In other words, if you assign a group to an application, only the direct members of that group will gain access to the application. So instead of using our top-level “all employees” type of group, we had to assign several lower-level groups which only had people inside of them.

3. All permissions need to be consented to by an AAD administrator

Applications in Azure Active Directory can request two types of permissions:

• the permissions which are scoped to the end user, like “Access your calendar”, “Read your user profile”, “Modify your contacts” — these permissions are shown to the user the first time they access an application, and they can consent to the application performing those actions on behalf of them;
• another type of permissions usually have a broader impact, outside of the user’s scope, like “Read all users’ profiles” or “Read and write all groups” — those permissions need to be consented to by an AAD administrator on behalf of all the users of the application.

When the access to the application is restricted via the “user assignment required”, an Azure Active Directory administrator needs to consent to all the permissions requested by the application, no matter whether users can normally provide consent for them.

As an example, I created an application with only one permission called “Sign in and read user profile”. After enabling the “user assignment required” option, I tried to log in through my web application and got prompted with a page similar to the screenshot below:

While I don’t fully understand that behaviour, it is alluded to in the tooltip associated with the “user assignment required” option, shortened for brevity and emphasis mine.

This option only functions with the following application types: […] or applications built directly on the Azure AD application platform that use OAuth 2.0 / OpenID Connect Authentication after a user or admin has consented to that application .

The solution is to have an AAD admin grant consent to the permissions for the whole directory. In the Azure portal, go to “Azure Active Directory > Enterprise application > your application > Permissions” and click the “Grant admin consent” button.

4. Other applications not assigned to the application can’t get an access token

It’s not uncommon to see integration between applications. As an example, an application “A” could run a background job every night and call the API of application “B” to get some data.

Before we enabled the “user assignment required” option in application “B”, it was possible for application “A” to request an access token to AAD, allowing it to call the API of application “B”. This is done using the client_credentials OAuth2 flow, where application “A” authenticates itself against AAD with either a client secret (it’s like a password, but an app can have different secrets) or a certificate.

However, after requiring users to be assigned to the application “A”, the token request returns the following error:

AADSTS501051: Application ‘<application-b-id>’ (<application-b-name>) is not assigned to a role for the application ‘<application-a-id>’ (<application-a-name>).

While it’s similar to the first error we talked about in this post, the resolution is different, as the Azure portal doesn’t let us assign applications to another application in the “User and groups” page.

I found the solution in this Stack Overflow answer which advises to take the following steps:

• create a role in application “A” that can be assigned to applications;
• have application “B” request this permission; and
• get an AAD admin to grant consent for the permissions requested by application “B”.

Let’s go through these steps one by one.

4.1 Create a role that can be assigned to applications

If you want to get some background information on AAD app roles, I highly suggest reading the following pages on docs.microsoft.com : Application roles and Add app roles in your application and receive them in the token .

To create a role aimed at applications, we’ll use the “Manifest” page and replace the appRoles property with the following:

4.2 Request that permission in application “B”

Wait, we were talking about creating a role and now we request a permission?

I agree, sorry about the confusion, but the following will hopefully make sense. There’s a change in the terminology we use because assigning that role to application “B” is actually done the other way around, by requesting that role from the settings of application “B”.

To do so, we navigate in the Azure portal to “Azure Active Directory > App registrations > application “B” > Required permissions” and then click on the “Add” button. In the new “Add API Access”, we look for application “A”, select it, then pick the “Access application A” application permissions we created in the previous step:

💡 Another heads-up — at the time of writing, the Azure portal has a new App registrations experience in preview. The steps mentioned above are for the GA App registrations blade, but the experience is pretty similar in the preview one. If you want to try it out, follow “App registrations (preview) > application “B” > API permissions > Add a permission > APIs my organization uses > application “A” > Application permissions”, then finally pick the “Access application A” one.

4.3 Grant consent for application “B” to access application “A”

Because there’s no user involved, application permissions automatically require admin consent. Follow the steps taken previously, but this time for application “B”. After doing so, the token request from application “B” to access application “A” will work as expected.

When we first used that “user assignment required” option, I was only expecting unassigned users to be bounced by AAD when trying to log in. Little did I know we would encounter all those “bumps” along the way 🤣.

This was a great learning opportunity, and hopefully it’ll be useful to others.

Related Posts

Ensure node.js opentelemetry instrumentations are compatible with installed packages 08 apr 2024, a new and easy way to use aad authentication with azure sql 23 jul 2021, how to lock down your csp when using swashbuckle 14 dec 2020.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Azure AD application - User assignment required option enabled, newly added user can't login

We have an application setup to use Azure AD. The 'User Assignment Required' option is enabled because we wanted to restrict access to a specific set of AD users. It's working fine for existing users.

However, we recently added a new user from the Enterprise Applications section for that app, and he is not able to log in. He gets the 'Need admin approval' message. When we disable the 'User Assignment Required' option, it works fine for him as well.

Please advise.

• azure-activedirectory

When you enable the 'User Assignment Required' option you have to give Admin Consent for that Applications permissions. When enabling this option normal users can not give consent on their own anymore, they only can give consent when that option is off. But you probably want that option on so you can control who can access the Application so you need an Admin (Global admin, Cloud Application admin or Application Admin) to give the consent for that App.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged azure azure-activedirectory ..

• The Overflow Blog
• Why configuration is so complicated
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network
• Google Cloud will be Sponsoring Super User SE

Hot Network Questions

• University is killing my passion [for mathematics]
• What is this strake near the nose of the MD-80 for?
• Can a function have a set as its value?
• C-17 Globemaster III Question
• Is it impossible to protect an API from data redistribution?
• Can Alireza Firouzja be accused of tournament manipulation in the 2024 FIDE Candidates?
• (Potentially) Politically Motivated Manuscript rejection from a journal director
• Electromagnetism in 2+1 dimensions?
• Is there a way to make a series change signs every 2 terms?
• When I am pedaling harder on a slope, the chain sometimes skips or get detached
• Double parenthesis in academic writing
• What type of cable is this (optic fiber) connecting to router?
• Why is "creating jobs" seen as good and "destroying jobs" seen as bad, even when there are major labour shortages?
• Looking for mid-1980's list of Science Fiction Landmark works
• How do objects reach terminal velocity?
• "I didn’t see her again (until) a few days afterwards." — How does "until" affect the meaning of the sentence?
• 8-hour stopover in Kuala Lumpur: visiting Batu Caves?
• Using an Irish passport in the EU but my wife only has a UK passport
• Create a snail matrix
• Can a state force someone to sell it something?
• I can be crooked, I can be slanted
• Review my power MOSFET motor control circuit - rev4
• How many lands in total can be put into play with Map the Frontier?
• Can a judge decide a case based on their own legal knowledge?

Getting started with Azure AD App Provisioning and single-sign-on

My first-ever blog post walks through how to configure automated user provisioning and single-sign-on from azure ad to saas apps, specifically for workplace from facebook.

Azure AD has many key strengths and features, automated user provisioning and single-sign-on (SSO) capabilities for a number of SaaS apps being two of them.

I’ve worked in consultancy focusing on identity, access and security the last five years - and I must honestly say that there’s nothing as cool as automating and controlling identity lifecycle and governance with modern and built-in capabilities like the ones Azure AD is offering.

Having users (and groups) automatically created, maintained and disabled/removed in connected SaaS apps gives organizations full control of the identities, while enabling single-sign-on for the same apps makes it painless for end-users to sign in, and lowers the volume of Service Desk tickets categorized as sign-in issues. Win-win!

In the Enterprise Gallery you will, at the time of writing, find 230 SaaS apps supporting automated user provisioning ( SCIM standard ), and 1675 SaaS apps supporting SSO ( SAML or OpenID Connect ). Let’s take one of those SaaS apps, “Workplace from Facebook” which many organizations use today, and see how we can enable both of these features.

Prerequisites

Configuring single-sign-on, configuring automated user provisioning, testing and enabling automated user provisioning.

Note: As always, test well and get to know the features in a demo environment before planning for production!

You’ll need an Azure AD environment. I have a demo environment with Azure AD and M365 E5 licenses ready to go, but the Free Tier of Azure AD is sufficient for automated user provisioning to SaaS apps. Note that automated group provisioning requires Azure AD P1 licenses .

You need to be either a Global Administrator, Application Administrator or Cloud Application Administrator in the Azure AD tenant for adding the Workplace app and enabling the provisioning and SSO features.

Go to the Azure AD Gallery , search for “Workplace from Facebook” and create the app in Azure AD.

Signing up for a “Workplace from Facebook” trial grants 30 days of core capabilities, which is required both for automated user provisioning and for single-sign-on to Workplace. Be sure to sign up with a user where the email/UPN is for the same domain as in your Azure AD tenant, as this domain will have to be verified in Workplace before enabling SSO.

Once signed up with a trial, we can continue with enabling the features.

Configuring single-sign-on in Azure AD for “Workplace from Facebook” is documented by Microsoft , but I’ll go through the steps here:

Navigate to the Azure Portal -> Enterprise Applications -> Workplace from Facebook (which you added earlier) -> Properties , set User assignment required to Yes and save.

Go to Users and groups and assign your admin account (the one you registered the Workplace environment with), as this account is needed for testing SSO before being allowed to save the SSO settings in Workplace.

In a separate browser tab, navigate to the Workplace from Facebook website and log in to your new trial environment, then go to Admin Panel -> Security -> Authentication .

Activate the Single-sign on (SSO) option listed under Log in and set Default for new users to SSO .

Now click the + Add new SSO provider button and copy the following values to notepad:

Note: Do not use the example values above, make sure to fetch the correct values from your Workplace environment!

Go to the Azure Portal browser tab, navigate to Single sign-on in the Workplace from Facebook Enterprise App and select SAML

Click Edit on Basic SAML Configuration and paste in the values you copied to notepad in step 2:

Note: Set the new value in ‘Identifier (Entity ID)’ as default, and remove the ‘https://www.facebook.com/company/*’ value from the list before clicking Save !

Then click Save and close the Basic SAML Configuration - choose No, I’ll test later if you’re asked to test single-sign-on

In the Azure Portal browser tab, under SAML Signing Certificate , click Download on Certificate (Base64) , and open the downloaded Workplace from Facebook.cer file in notepad to view the base64 value.

Under Set up Workplace from Facebook on the same page, click the Configuration URLs dropdown and copy the following values to notepad:

Note: Do not use the example values above, make sure to fetch the correct values from your Azure AD app!

In the Workplace website browser tab, paste in the values you copied to notepad in step 4:

Once the values have been added, click the Test SSO button. If everything has been done correctly, you should see a new tab stating Your SSO is working properly

Now click Save Changes on the Single Sign-On (SSO) Setup dialog box in the Workplace website.

Still in the Workplace website browser tab, go to Admin Panel -> Settings -> Email Domains and follow the instructions to verify the email domain.

Once verified, go back to Admin Panel -> Security -> Authentication , click the Assign Email Domains button and add your verified domain - click Save . Also verify that Allow people to authenticate using is set to Single-sign on (SSO) and Default for new users is set to SSO

Note: Remember to click Save Changes on the Authentication page once everything is configured.

This concludes the setup of single-sign-on. Any Azure AD users assigned to the Workplace from Facebook app, which also exists as a user in Workplace, will now be able to use single-sign-on.

Configuring automated user provisioning in Azure AD for “Workplace from Facebook” is documented by Microsoft , but I’ll also go through the steps here:

Navigate to the Azure Portal -> Enterprise Applications -> Workplace from Facebook -> Provisioning , click Get started and set Provisioning Mode to Automatic .

Then click the Admin Credentials dropdown, click Authorize and authenticate with your Workplace administrator account. Then proceed with authorizing Azure AD SCIM Provisioning to create, manage and disable users in Workplace by clicking Add to Workplace .

Back in the Azure Portal, proceed by clicking the Mappings dropdown. Since the Workplace from Facebook gallery app comes with a default set of attributes mapping, there is no need to change this configuration. However, if you need to synchronize additional attributes then this is the place to do those changes.

Now click the Settings dropdown and configure email notification, Azure AD will email the configured email address if a synchronization failure occurs.

Click Save at the top of the page to save the configuration, then refresh the page to reveal all the configuration options. To get back to the configuration page, click Edit provisioning on the Provisioning page on the Workplace from Facebook app. You will see that the settings are saved, but that Provisioning Status is Off - meaning that the synchronization job has not yet been activated.

The configuration of automated user provisioning is completed. But prior to activating the synchronization job it is important to test and verify that user provisioning is working correctly.

Use the Provision on demand feature in Azure AD to test user provisioning, this feature enables you to synchronize one user at a time to verify that the SCIM operation, object matching and attribute flow works as expected. This is a good exercise to get confident with the provisioning process.

To provision on demand, navigate to the Azure Portal -> Enterprise Applications -> Workplace from Facebook -> Provisioning -> Provision on demand . Type in the UserPrincipalName of a user already assigned to the app, and click Provision .

Note: If the user already exists in Workplace you will see an Update operation, if the user does not exist you will se a Create operation. Note that users disabled in Azure AD will not be provisioned to any target systems through Azure AD App Provisioning, as being enabled is a requirement. Also, since the app was configured to require user assignment, only users assigned to the app will be provisioned to Workplace. Lastly, Azure AD will never delete users in Workplace, as Workplace does not allow it by default. Azure AD will only disable the account (soft-delete) in Workplace when the account is disabled in Azure AD.

Once you have provisioned a few users on demand and are satisfied with the results, make sure to enable the automated synchronization job by clicking Start provisioning . Azure AD will from now on automatically create, update and disable assigned users in Workplace. An initial full synchronization cycle will run first, whereafter a delta synchronization will run every 40 minutes indefinitely.

Keep an eye on the Provisioning logs for the app to gain visibility into the operations carried out by Azure AD App Provisioning service, including any errors, created/updated objects and modified properties. The Audit log for the app will also contain valuable information both for troubleshooting and for visibility into the service.

Tip : If you need Workplace to automatically invite a new user created by Azure AD, instead of requiring an admin to click the Invite button on their user profile which is the default setting, go to Workplace -> Admin Panel -> Integrations , edit Azure AD SCIM Provisioning and enable Automatically invite people to Workplace as soon as they’re added using this integration

And that concludes this blog post, thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn .

• Next Post →

Support Hub

How can we help you today.

• Integrations
• CollaborNation API
• File Transfer
• CypherWorx Accelerate - Add CypherWorx courses to your LMS
• Revenue Share
• Single Sign-On

Single Sign-On (SSO) With Azure AD

• Single Sign-On (SSO) with Google Workspace
• Single Sign-On with Canvas LMS
• Learning Tools Interoperability (LTI)

1. In the Azure AD management blade in the Azure portal (portal.azure.com) select Enterprise applications .

2. Select New application .

3. Select Create your own application .

4. When creating your own application, enter the following settings.

• What's the name of your app? CollaborNation
• What are you looking to do with your application? Integrate any other application you don't find in the gallery (Non-gallery)

Then select Create .

5. Select Properties in the Manage pane of the newly created application.

6. Note the three yes/no toggles. 

• Enabled for users to sign-in: This is basically the global on/off switch for the app, should all users ever need to be locked out of it. 
• Assignment required: Allows administrators to assign specific users or groups access to the application.
• Visible to users? Controls whether or not the app is visible in the My Apps and Office 365 apps portals. This is useful if a particular application’s SSO mode is Service Provider (SP) initiated and an IDP-initiated link in the portals may cause confusion. If you keep “assignment required” set to yes, you will need to use the Users and Groups pane of the app to assign users/groups as appropriate before they can SSO.

7. Set up SSO by navigating to the Single sign-on section of the CollaborNation Enterprise Application’s management pane and selecting SAML as the SSO method.

8. Begin navigating through the SAML configuration steps, beginning with the Edit option of Step 1 . Alternately, if provided with a SP metadata file you can upload it on this page instead of manually entering the SAML config parameters.

9. Enter the following required fields. 

• Identifier (Entity ID): collabornation
• Reply URL (Assertion Consumer Service URL): This will be provided to you
• Logout Url: This will be provided to you

Click Save .

10. Step 2 in the Set up Single Sign-On with SAML area is available to edit. Typically, Name ID will be a user’s unique identifier such as SAMAccountName or UserPrincipalName, the latter of which is Azure AD’s default, so likely won’t have to be changed.

11. Delete all the default Additional claims as we will be adding these per spec.

12. Add four new claims .

13. Provide the relevant metadata from Steps 3 & 4 to the vendor. 

• App Federation Metadata Url
• Certificate (Base64)
• Federation Metadata XML
• Azure AD Identifier

You will need to provide at a minimum the Azure AD Identifier URL and the Certificate (Base64). This information can also be provided by providing the App Federation Metadata URL or Federation Metadata XML file. 

Please note the Expiration Date – this is the expiration date of the signing certificate. You may wish to edit this section to add additional email addresses to notify in advance of expiration, as SSO will break if this certificate expires and is not replaced.

14. SSO is complete and ready for testing!

Did you find it helpful? Yes No

Email Security Cloud Gateway - Azure Standard SSO Configuration

This article describes how to configure a default sso authentication profile for azure. mar 11, 2023 • knowledge, article details.

Single Sign On through Azure AD allows your organization to integrate authentication to Mimecast with Azure. This fully supports all Microsoft authentication functions, such as Multi-Factor Authentication and Integrated Authentication, Azure AD Seamless SSO, and Conditional Access. In addition, you can also configure Azure SSO to work with the Mimecast Personal Portal.

Considerations

• Mimecast Single Sign On through Office Azure uses the mail  attribute as the primary SMTP address- in Azure AD to identify users. This will accommodate your users with a different User Principal Name (UPN).
• End users can access Mimecast Services using the Mimecast website or a bookmark in their browser via a Service Provider (SP) Initiated Login.
• End users can access Mimecast Services via the Azure MyApps Portal and Identity Provider (IDP) Logins.
• The end-user's Email address must be entered under their  Contact Information  in Azure for SAML to work correctly.
• Azure Premium will enable you to build custom Enterprise Apps with more control if you restrict access to a specific Mimecast Service. (This can also be controlled within the Mimecast Administration Console).
• Azure Premium enables you to build Applications in the Azure MyApps Portal (Identity Provider Logins). See  How to Configure SSO SP/IDP-Initiated logins using Azure Premium  when using Azure Premium.

Configuring SSO SP-Initiated Logins using Azure Standard

Login into your Azure Administrator Portal .

• Navigate to Azure Active Directory | Enterprise Applications | New Application.
• Search for Mimecast  on the Search application textbox.
• On the pop-up Panel, give the SSO Application a Name .
• Click on the  Create button.
• Select Properties  from the Manage  section. Make sure:
• Enabled for users to sign in is set to Yes .
• The user assignment required is set to No .
• Visible to users is set to No.
• Click Save.
• Select Single Sign-On  from the Manage section.
• Select SAML as the Single Sign-On method.

• In the  Identifier (Entity ID)  field, enter the value for your region from the table below.
• Insert the link for your region from the chart below into the Reply URL (Assertion Consumer Service URL) and Sign-on URL boxes.
• Click the Save button in the top left corner of the Panel.
• Click Close to close the Panel and return to the main menu
• Click the Edit button in the User Attributes & Claims panel.
• Click on the Value user.userprincipalname .
• Select user.mail as the Source Attribute in the Manage claim panel.
• In the choose name identifier format dropdown, select Email address if it has not been selected already.
• Click Save at the top of the Panel and close it.
• Copy the App Federation Metadata URL from the SAML Signing Certificate panel.
• Login to the Mimecast Administration Console.
• Navigate to Administration | Services | Applications | Authentication Profiles .
• Click the Authentication Profile  to which you want to add SSO or create a New Authentication Profile .
• Choose the Mimecast Application you want to use SSO with and check the Enforce SAML Authentication Box for that app.
• The steps below will be the same for all the applications. Repeat for any other application you would like to use SSO on.

Click Save and Exit.

See Also...

• How to Configure SSO SP/IDP-Initiated logins using Azure Premium

Article Properties

Was this article helpful, can't find what you're looking for, explore the knowledge hub.

Find how-to-articles, videos, and support resources for all Mimecast products in our Knowledge Hub.

Explore Education support resources and start your training journey now.

© 2020 Mimecast Services limited.

Entra ID - Configuring Single Sign-On Authentication

Learn how to configure Single Sign-On using SAML protocol in Microsoft Entra ID to authenticate users to your Staffbase platform.

In this article, you will learn how to set up Single Sign-On (SSO) using the SAML protocol in Microsoft Entra ID (formerly known as Azure Active Directory / Azure AD). SSO is an authentication method that allows users access to multiple applications with a single account. This will allow you to onboard your users using SSO and let them access the Staffbase platform using the same credentials they use to access other platforms in your organization.

SSO is optional for user management. You can choose an option based on your business requirements. Learn more about other options .

• Prerequisites
• You have an Entra ID tenant.
• Application Administrator
• Cloud Application Administrator
• Global Administrator
• Creating an Enterprise Application

You need to create an enterprise application in Entra ID to set up SSO.

Staffbase recommends creating a dedicated application to maintain users for your Staffbase platform. If you want to configure SCIM for user provisioning , you are able to use a single enterprise application for both SSO and SCIM for your user management.

• In Microsoft Azure, under Azure services, click Microsoft Entra ID .
• Navigate to Enterprise applications .
• Click New application .
• Click Create your own application . The Create your own application dialog opens.

• Provide a name for the application. For example, Staffbase SSO or something similar to help you instantly identify the application.
• Select Integrate any other application you don't find in the gallery (Non-gallery) .
• Click Create . You have created an application to authenticate users using SSO.
• Assigning Users

After creating the enterprise application, you can decide on which Entra ID users need access to the Staffbase platform using SSO.

Staffbase recommends adding a few users initially to test that everything works as expected.

• In the enterprise application you created, click Users and groups .

The Users and groups page opens.

• Click Add user/group .

• Click None Selected . The Users and groups dialog opens.
• Search for the user or group you want to add and click Select .

• Click Assign . You have assigned users or groups to the application.
• Setting up SSO With SAML

Once you have created the application, you need to define the SAML protocol. Learn how the Microsoft identity platform uses the SAML protocol .

• Select SAML Method
• In the enterprise application, navigate to Overview .
• Under Set up single sign on , click Get Started .
• Select SAML as the single sign-on method.

The Set up Single Sign-On with SAML page opens.

To continue the setup process, you will need to work closely with the Staffbase Support team. First, contact the team and inform them that you're setting up SSO with Entra ID. You will receive the information needed to proceed with the setup and have to provide them with the information listed below.

• Exchange Information With Staffbase Support

To continue setting up SSO with SAML, you need to:

• Receive Information From Staffbase

You will receive the following to complete the SSO setup:

• Reply URL (Assertion Consumer Service URL) : The Reply URL directs Entra ID where to send its SAML Response after authenticating a user.
• Identifier (Entity ID) : The Identifier acts as a unique identifier for your Staffbase platform domain in Entra ID.
• Provide Staffbase Your Enterprise Application Details

Provide the following information to Staffbase:

• App Federation Metadata Url

You can copy App Federation Metadata Url from Set up Single Sign-On with SAML page under the SAML Signing Certificate section.

For now, you can ignore the warning that you need to complete Step 1 before adjusting the other Steps. You will get the details in order to complete the other steps after you provide all the required information to Staffbase Support.

• Your Entra ID session lifetime

If the session lifetime is not configured, you are using the default session lifetime. Learn more here .

Staffbase recommends disabling persistent browser sessions , as they could lead to sign-in issues for users with older sessions. Notify your Staffbase Support team if it cannot be disabled.

• Complete the SSO Configuration

After receiving the information from Staffbase, you can complete the SSO configuration.

• Step 1: Basic SAML Configuration
• In the Set up Single Sign-On with SAML page, click Edit under Basic SAML Configuration .

• Enter the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) you received from Staffbase.
• Step 2: Attributes & Claims
• Under SAML Signing Certificate , click Edit . The Attributes & Claims page opens.

You can modify a claim and adjust its values according to your business requirements. At minimum, you need the following claims configured:

• Unique User Identifier (Name ID)
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

The Unique User Identifier (Name ID) value and the identifier in your Staffbase platform must match for each user using SSO.

If you want to use a different value from the one already in place for your users in your Staffbase platform, you will need to update the user identifiers in your Staffbase platform first. In such a case, ensure that all future user management also includes these new identifiers.

Click Add new claim . The Manage claim dialog opens.

Provide a name and assign a Source attribute for the claim.

• Step 3: SAML Signing Certificate

The values are auto-filled based on your enterprise application and Entra ID tenant.

• Step 4: Set up
• Step 5: Test single sign-on
• Under Test single sign-on , click Test .
• Select a way to test sign in and click Test sign in . The sign in page opens for you to test.
• Ensure the sign in functions as expected.
• Assigning All Users

After testing the SSO authentication works as expected, you can add all users in Entra ID to the enterprise application.

• In the enterprise application you created, click Properties .
• Set Assignment required? to No .

• Click Save .

You have configured and enable SSO for your Staffbase platform.

You can configure the SAML domain hints to ensure that users don't attempt to authenticate with the identity provider (IdP) using domains that are not allowed when using the Staffbase platform. To activate this feature, contact Staffbase Support or your Customer Success Manager. Learn more about domain hints .

• Additonal Helpful Information
• Microsoft Entra ID Single Sign-On SAML protocol
• How the Microsoft identity platform uses the SAML protocol
• Microsoft Entra ID: Customize claims issued in the SAML token for enterprise applications
• Microsoft Entra ID: Problems signing in to SAML-based single sign-on configured apps

On this page

• SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our Cookie Policy .

Search SolarWinds Support

Microsoft entra (azure ad) sso configuration.

On this page

Introduction

To configure Azure with your SolarWinds Service Desk account you will need to access both your Azure Service Portal and SolarWinds Service Desk ( SWSD ). SolarWinds recommends having them both open at the same time but on separate browser tabs, as you will be going back and forth between the two.

You may connect simultaneously Microsoft Entra (Azure AD) and Google .

Learning options

You can follow the instructions that guide you through the SSO Configuration process or you can view a video.

Navigation is dependent upon the steps below in the section titled Configure SSO with Azure .

Provisioning

Some customers choose to provision users with Microsoft Azure Active Directory. See Provisioning with Microsoft Azure (Entra Connect Cloud Sync) for instructions.

Configure SSO with Azure

Step 1: add solarwinds service desk to your azure active directory.

• Open your Azure Portal.
• Navigate to Azure Active Directory, and then in the left pane under Manage, click Enterprise applications.
• Click the New application tab, and under Application type, search for SolarWinds .
• Click SolarWinds Service Desk .
• At the bottom of the new pane that displays on the right, click Create.

Azure adds SolarWinds Service Desk and opens it.

Step 2: Change the User Assignment Requirement

• In SolarWinds Service Desk ( SWSD ) from within Azure, under Manage in the left pane, click Properties.
• Scroll down to User assignment required? and switch the toggle to No. This allows anyone within your Active Directory to authenticate through single sign-on with Azure.
• Scroll to the top and click Save.

Step 3: Set up Basic SAML Configuration in Azure

In Azure, under Manage on the left pane, click Single sign-on.

Click SAML.

• In the first section titled Basic SAML Configuration, click Edit.
• Identifier (Entity ID) : Solarwinds.com

At a minimum, two Reply URLs are required, as shown below.

In addition, you will need your [ACCOUNTNAME], which can be found in SWSD under Setup > Account > Account Summary. Your account name comes from the first part of your Account URL. For example, if the Account URL were samanagemarketing .samanage.com, your account name would be samanagemarketing .

Here are the Reply URLs you will need:

https://[ACCOUNTNAME].samanage.com/saml/[ACCOUNTNAME]

If you are using the Domain Management feature in SWSD you will need a third Reply URL, replacing your Account Name with the custom domain you are using in SWSD . For example: https://[ ACCOUNTNAME ].samanage.com/saml/[ACCOUNTNAME] would become: https://[ DOMAINNAME ]/saml/[ACCOUNTNAME]

ESM customers need to edit all domain/account name references to redirect SSO to the organization level. For example:

https:// org- ACCOUNTNAME.samanage.com/saml/metadata or https:// org. [DOMAINNAME]/saml/metadata

Sign on URL : https://[ACCOUNTNAME].samanage.com/saml/[ACCOUNTNAME] To get the sign-on URL , go to SWSD (Account > Single Sign-On > Azure AD), and then copy the Login URL.

Click Save.

Step 4: Verify Attributes & Claims Accuracy

Determine which approach you want to use:

If you plan to use both SSO and User Provisioning , in Azure go to the second section labeled Attributes & Claims, and then click Edit.

If you do not plan to use User Provisioning , skip to Step 5: Set up SAML Signing Certificate .

In Attributes & Claims, verify that the two different Active Directory fields below contain the same information.

Unique Principal Name - see Required claim > Claim name > Edit > Unique User Identifier (Name ID)

User Email Address - see Additional claims > Claim name

If the two do not match exactly, SolarWinds suggests you contact Technical Support for assistance.

Step 5: Set up SAML Signing Certificate

In Azure, go to the third section, labeled SAML Signing Certificate.

Next to Certificate (Base64), click Download. Leave the file on your task bar, but do not open it immediately.

If you are using Domain Management, add a reply URL using your custom domain. For example: https://[customdomain]/saml/[account name] .

If you are configuring SSO prior to completion of User Provisioning , disable User Assignment Required within the Properties menu in SWSD .

Step 6: Set up Login URL, Logout URL, Identifier, and Certificate

In Azure, go to the fourth section, labeled Set up SolarWinds Service Desk .

Next to Login URL, click Copy to Clipboard.

Navigate to SWSD > Account > Single Sign-On.

In the Login URL field, paste the contents of the Clipboard.

In the Logout URL field, enter https://login.windows.net/common/wsfederation?wa=wsignout1.0 or your desired Logout URL.

Scroll down to the Azure Identifier field and type in solarwinds.com .

In a text editor, open the downloaded certificate file (downloaded in Step 5.2 above).

Copy the entire contents of the certificate file.

Return to SWSD , scroll down to the text field labeled Paste your Identity Provider x.509 Certificate below, and paste the contents of your clipboard.

Under the text field:

• Add a check mark next to Create users if they do not exist.
• Remove the check mark next to Redirect to the SAML login page when logging into SolarWinds Service Desk by default.

During initial configuration and testing, Solarwinds recommends leaving the second checkbox above unmarked.

Click Update.

Step 7: Test Single Sign-On

Open an incognito tab (or private browsing session) in an internet browser.

Enter your account URL, and then test logging in.

After a successful test, return to SWSD , and add check marks to both boxes under the text field.

Create users if they do not exist.

Redirect to the SAML login page when logging in by default.

Click Update. Your single sign-on configuration is complete.

If you receive an error after testing, contact Technical Support for assistance.

Related topics

• Single sign-on and provisioning
• Provisioning with Microsoft Azure (Entra Connect Cloud Sync)

To learn more about Smartsheet Regions,  click here .

For more information about plan types and included capabilities, see the Smartsheet Plans page.

Capabilities

Who can use this capability.

You must be a sysadmin on Smartsheet and Azure to configure Azure for OIDC or SAML with Smartsheet

Find out if this capability is included in Smartsheet Regions or Smartsheet Gov .

Configure Azure for plan-level OIDC or SAML with Smartsheet

You can use Azure for SSO with Smartsheet in two ways. Both methods are effective.

Permissions

In both configurations, Azure controls your Azure's authentication settings. Azure controls all SSO policies and settings adjustments, not Smartsheet. 

• Open ID Connect (OIDC): Use the built-in Microsoft button and the corresponding Enterprise App in Azure (3290e3f7-d3ac-4165-bcef-cf4874fc4270). To restrict to Azure-only, use Smartsheet's authentication settings. 
• SAML: Create a new Enterprise app for Smartsheet in Azure and configure the SAML setup and user attribution in the app directly. This method provides more control over specific user attributes. 

Smartsheet offers SCIM provisioning with the Azure provisioning service, but it isn't a requirement for SSO. 

Keep in mind that Azure for OIDC or SAML is a plan-level configuration .

Set up SSO with OIDC

• In Azure Enterprise Apps, browse to or search for the pre-built Smartsheet Enterprise App (ID 3290e3f7-d3ac-4165-bcef-cf4874fc4270).
• Review Azure's settings, such as visibility to users and assignment required. User.read is the only required claim Smartsheet uses.
• Activate and test the Microsoft Azure AD option in Smartsheet’s authentication settings.
• When the test works, communicate the change to your users and disable any other authentication options. 

Configure Azure for SAML with Smartsheet

If you need more control over the login specifics, configure SAML with Azure as the SAML Identity Provider (IdP). As with OIDC, most configuration changes take place in Azure, not Smartsheet. 

When you set up SAML configuration between Smartsheet and Azure AD, users see the Your Company Account button on the Smartsheet login screen.

To configure Azure AD with SAML: 

You can't set up SAML on the Smartsheet-owned gallery app (ID 329..) in Azure. The built-in app offers control over OIDC SSO, a different option. To set up SAML in Azure, create a new enterprise app as follows:

In the basic SAML configuration, enter the following:

• Entity ID: https://sso.smartsheet.com/saml
• Reply URL: https://sso.smartsheet.com/Shibboleth.sso/SAML2/POST
• Sign-on URL: https://app.smartsheet.com/b/home

In User Attributes & Claims, Azure provides the following defaults:

• Unique User Identifier : user.userprincipalname
• Email address : user.mail
• Name : user-userprincipalname

The default Additional Claim of Name : user-userprincipalname causes an unexpected error. Delete it for SAML via Azure to work.

Under SAML signing certificate: 

• Make sure Status = Active
• Confirm your notification email. You receive a notification at this email when the certificate approaches expiry. 
• Download Federation Metadata XML and open the file in Notepad or another raw text editor.
• From the left panel, under Manage , select Properties,  and scroll to the bottom to turn off User assignment required? Turning this feature off makes testing easier, and users are already managed in the Smartsheet userlist.  
• Log in to Admin Center and select Authentication >  SAML .
• Select Edit Configuration next to SAML and select  Add IdP .
• Name the IdP (e.g., AzureSAML) and paste in the downloaded metadata. Save your changes. 
• In the Edit IdP window, select Activate .
• Close the Edit IdP window and the SAML Administration window.
• In the Authentication window, select  SAML .
• Save your changes. 

The Company Account button for login via SAML should appear on the login screen. The newly created IdP for Azure SAML provides an SSO URL as a shortcut to SAML.

Set your SSO method in Smartsheet's Admin Center

• On the left navigation bar, select Account . 
• In the Account menu, select Admin Center . 
• Select Security/Safe Sharing List . For more information about the other options on this page, see Security Controls.
• In the Authentication section, select Edit .
• Select your desired authentication options. You must select at least one.

Can I use a single Azure enterprise app to power SSO for multiple Smartsheet userlists?

Yes, Smartsheet allows you to use the same entity ID across multiple user lists.

Can I change user attributes or claims in the “built-in” OIDC “Microsoft” button SSO?

No. Use  SAML to control the specifics of the SSO experience.

Can I set up exceptions or grouping to apply different login experiences to different sets of users?

No, the only exception is the optional email and password fallback for System Admins under SAML.

Does Azure SSO affect external Smartsheet users?

Only users in the Azure SSO enabled Smartsheet user list are affected by changes to authentication settings , including Azure SSO. Only managed users invited by a System Admin or provisioned by Smartsheet can log in via SSO.  

How do I account for new users after enabling SSO?

Use Smartsheet’s built-in User Auto Provisioning for your domain. You can also use Azure SCIM. Setting up Azure SCIM is a complex process, so start with Smartsheet UAP; you may find it meets your needs.

• Synerise Hub

Identity & Access Management

• Single sign-on tutorials

Single sign-on with Azure Active Directory

• Introduction to cloning
• Cloning analyses to other workspaces
• Cloning AI recommendations to other workspaces
• Cloning campaigns and campaign templates to other workspaces
• Cloning workflows to other workspaces
• Password settings
• IP allow-listing
• Two-factor authentication
• Managed domains
• Single sign-on
• Troubleshooting
• Access management
• Third-party authentication
• Access Control

Apps & Integration

• Enabling the Freshmail integration
• Enabling the ExpertSender integration
• Enabling the SendGrid integration
• Enabling the custom SMTP server integration
• Enabling the Twilio integration
• Enabling the Vonage integration
• Enabling the Redlink integration
• Enabling the SMSAPI integration
• Enabling the Materna integration
• Enabling the Infobip integration
• Enabling the TideMobile integration
• Enabling the SMSBIZ integration
• Scheduling synchronization of data between Magento and Synerise
• Integrating Magento with Synerise
• Legacy Magento Plugin

Configuration

• Configure AI engine for AI Search
• Configure AI Engine for Propensity
• Configure AI engine for Recommendations
• Model status
• Monitoring item feed status

This is a guide to the integration between Synerise and Microsoft Azure Active Directory (Azure AD), which enables your users to authorize with their Azure AD accounts. The integration with Microsoft Azure AD is offered through the SAML 2.0 protocol.

Centralized user management - With Azure AD, you get to administer users from one central place in your organization.

Increased security - The benefit of a single user account in many applications helps to maintain a single identity and credentials, so users don’t have to remember too many credentials. Authentication takes place only with Azure AD, with a single set of security-related policies regardless of the application.

Improved user experience - Your users only need to sign in once to use multiple applications. This approach ensures faster authentication, saves time and relieves users from remembering multiple credentials.

Prerequisites

To get started, you need the following items:

• An Azure AD subscription with permission to create Azure AD applications
• At least one verified domain
• User permissions to access Settings and perform Identity provider configuration in Synerise

Configuring SAML application in Microsoft Azure

The first step is to add the Synerise application to your Microsoft Azure AD account.

• Log in to Microsoft Azure Portal .
• Go to Azure Active Directory > Enterprise Applications .
• Select All applications and then click New application .
• In the Add from the gallery section, in the search box type Synerise AI Growth Operating System .
• From the results, select Synerise AI Growth Operating System and add the application. Result : Your application is added.

• In the Basic SAML Configuration section, on the right side, click the Edit button.

• Reply URL (Assertion Consumer Service URL)
• Sign on URL
• In SAML Signing Certificate , download Certificate (Base64) .
• From Set up Synerise Growth Cloud , note down Login URL .
• Go to the Overview section in the Azure MD application and note down Application ID (it’s required in the further part of the integration process).

Configuring user assignment to the application

You can assign users to the Synerise application in several ways within Microsoft Azure depending on your needs. The configuration settings allow you to let all your users use Synerise or only the selected user groups/individuals.

• Select the Synerise application.
• Go to Users and groups and click Add user .
• Select individual users or groups who will be granted access to the Synerise application.
• Confirm the selection by clicking Assign .
• All users and groups have access to the application.
• If you want to grant access to specific user groups, you can map those user groups in Dynamic group assignment in Synerise.
• If there was no role assignment mapping, whenever a user accesses the Synerise app, this user receives information about the lack of access and a request to contact Organization admin.

Configuring application access based on Azure AD security groups

Go to Azure Active Directory > Groups .

Select the security groups you want to enable access for.

Note down the Object Ids of the security groups for which you want to enable access to Synerise. In this example, access will be granted for three security groups:

• SYN_ADMIN with Object Id : 9338ee1f-f662-48df-b286-7b93c9816e38 ) where we want to assign the PROFILE_ADMIN role in Synerise
• SYN_MANAGER with Object Id : 1826c186-ec0d-4ac0-a939-53d964b0e157 where we want to assign the PROFILE_MANAGER role in Synerise
• SYN_USER with Object Id : 731e7b07-604a-4ce5-b26e-e1a73c4e440f where we want to assign the PROFILE_USER role in Synerise WARNING: These are just example Object Ids . While performing the procedure, replace them with the actual IDs for your security groups.
• Switch the Dynamic role assignment option on.
• Follow the instructions described here .

Configuring application access based on Synerise SAML app assignment

• Select the Synerise application (which was created in the Configuring SAML application in Microsoft Azure section).
• In the Overview section (which you’re currently in), select 1. Assign users and groups .
• Select Add user > Users and groups and select the groups you want to assign to the Synerise application.
• After assigning all users or groups, to confirm selection, click the Assign button.
• Continue the set up within Synerise as described in this step in Configuring Azure AD as an Identity Provider in Synerise .

Configuring group claims

In order to pass role or group claims within Microsoft Azure, you must:

• Go to Azure Active Directory > App registrations .
• Go to Token configuration section.
• If you want to enable access to the application based on Active Directory security group assignment for users, click Security groups .
• If you want to enable access to the application based only on groups assigned to the Synerise application, click Groups assigned to the application .
• If you select it, the claim will use the following attribute name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role
• If you leave this checkbox unselected, the SAML integration will use the following attribute name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groups or http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
• If you selected Security groups , continue to this procedure .
• If you selected Groups assigned to the application , continue to this procedure .

Configuring Azure AD as an Identity Provider in Synerise

Log in to Synerise.

Select the workspace you want to configure single sign-on for.

In the General settings section:

• From the Authentication methods dropdown list, select the authentication method to the value of your choice. Read more information about it here . Tip: At the beginning, we suggest to set it to Allow signing in with both methods unless you have a separate account that’s in different domain than you will be setting up SSO for.
• In the Sign-in button label field, type the name that is displayed on the sign-in button, for example Sign in with Azure AD .

In the Authentication settings section:

• From the Managed domains , select the domains you want to use for your SSO.
• Enable Use attribute containing email address instead of subject . Result : The Identity Provider email attribute text field appears.
• In the Identity Provider email attribute , enter the email attribute name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress (use it only for Azure AD integration).

In the Just-in-Time provisioning section, follow the procedure described here .

If you kept the default role assignment:

Result : In this model, every authenticated person has a role (or roles) assigned according to the settings defined here regardless of any configuration on Identity Provider side and depending on setup in the Update user roles while signing in field.

If you selected dynamic role assignment:

Result : Every authenticated person has a role (or roles) assigned based on group/role mapping between Azure AD and Synerise depending on setup in the Update user roles while signing in field.

In the SAML protocol settings section:

• In the Identity Provider Entity ID and SSO endpoint (https) fields, enter the Login URL obtained from the Microsoft Azure Portal (you copied the URL while performing step 11 in the Configuring SAML application in Microsoft Azure procedure).
• In the Identity Provider application ID field, paste the Application ID obtained from Microsotf Azure Portal (you copied the URL while performing step 12 in the Configuring SAML application in Microsoft Azure procedure ).
• The Service Provider redirect URI is filled in by default (you used it in step 9 in the Configuring SAML application in Microsoft Azure procedure ).
• Select Request signature and upload certificate downloaded from Microsoft Azure Portal (you downloaded it in step 10 in the Configuring SAML application in Microsoft Azure procedure ).

Next to the Identity Providers headline, click Apply .

After completing the Azure AD setup, test the integration.

• If you are logged in to Synerise, log out.
• Enter your email address.
• Click Continue .
• Click the Sign in with Azure AD (the text on the button depends on the value you entered in this step ). Result : You will be redirected to Microsoft where you will be authenticated immediately if there is an active session or you will be asked to authenticate and as a result you’ll be redirected back to Synerise.

In the Synerise application, review the SAML setup for any typos or errors in the Just-In-Time provisioning configuration.

In Azure AD portal:

Alternatively, Synerise is available in https://myapplications.microsoft.com/ if you didn’t set the Visible to users? option to No in the Enterprise application setup.

Congratulation! You signed in through Azure AD.

Did this article answer your question?

We are sorry to hear that

Thank you for helping improve out documentation. If you need help or have any questions, please consider contacting support.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Plan a single sign-on deployment

• 26 contributors

This article provides information that you can use to plan your single sign-on (SSO) deployment in Microsoft Entra ID. When you plan your SSO deployment with your applications in Microsoft Entra ID, you need to consider the following questions:

• What are the administrative roles required for managing the application?
• Does the Security Assertion Markup Language (SAML) application certificate need to be renewed?
• Who needs to be notified of changes related to the implementation of SSO?
• What licenses are needed to ensure effective management of the application?
• Are shared and guest user accounts used to access the application?
• Do I understand the options for SSO deployment?

Administrative Roles

Always use the role with the fewest permissions available to accomplish the required task within Microsoft Entra ID. Review the different roles that are available and choose the right one to solve your needs for each persona for the application. Some roles might need to be applied temporarily and removed after the deployment is completed.

To learn more about Microsoft Entra administrative roles, see Microsoft Entra built-in roles .

Certificates

When you enable federation on SAML application, Microsoft Entra ID creates a certificate that is by default valid for three years. You can customize the expiration date for that certificate if needed. Ensure that you have processes in place to renew certificates before their expiration.

You change that certificate duration in the Microsoft Entra admin center. Make sure to document the expiration and know how to manage your certificate renewal. It’s important to identify the right roles and email distribution lists involved with managing the lifecycle of the signing certificate. The following roles are recommended:

• Owner for updating user properties in the application
• Owner On-Call for application troubleshooting support
• Closely monitored email distribution list for certificate-related change notifications

Set up a process for how to handle a certificate change between Microsoft Entra ID and your application. By having this process in place, you can help prevent or minimize an outage due to a certificate expiring or a forced certificate rollover. For more information, see Manage certificates for federated single sign-on in Microsoft Entra ID .

Communications

Communication is critical to the success of any new service. Proactively communicate to your users about the upcoming experience change. Communicate when change is to take place, and how to gain support if they experience issues. Review the options for how users are to access their SSO-enabled applications, and craft your communications to match your selection.

Implement your communication plan. Make sure you're letting your users know that a change is coming, when it arrives, and what to do now. Also, make sure that you provide information about how to seek assistance.

Ensure the application is covered by the following licensing requirements:

Microsoft Entra ID licensing - SSO for preintegrated enterprise applications is free. However, the number of objects in your directory and the features you wish to deploy might require more licenses. For a full list of license requirements, see Microsoft Entra pricing .

Application licensing - You need the appropriate licenses for your applications to meet your business needs. Work with the application owner to determine whether the users assigned to the application have the appropriate licenses for their roles within the application. If Microsoft Entra ID manages the automatic provisioning based on roles, the roles assigned in Microsoft Entra ID must align with the number of licenses owned within the application. Improper number of licenses owned in the application might lead to errors during the provisioning or updating of a user account.

Shared accounts

From the sign-in perspective, applications with shared accounts aren't different from enterprise applications that use password SSO for individual users. However, there are more steps required when planning and configuring an application meant to use shared accounts.

• The set of users in the organization who are to use the application.
• The existing set of credentials in the application associated with the set of users.
• For each combination of user set and credentials, create a security group in the cloud or on-premises based on your requirements.
• Reset the shared credentials. After the application is deployed in Microsoft Entra ID, individuals don't need the password of the shared account. Microsoft Entra ID stores the password and you should consider setting it to be long and complex.
• Configure automatic rollover of the password if the application supports it. That way, not even the administrator who did the initial setup knows the password of the shared account.

Single sign-on options

There are several ways you can configure an application for SSO. Choosing an SSO method depends on how the application is configured for authentication.

• Cloud applications can use OpenID Connect, OAuth, SAML, password-based, or linked for SSO. Single sign-on can also be disabled.
• On-premises applications can use password-based, Integrated Windows Authentication, header-based, or linked for SSO. The on-premises choices work when applications are configured for Application Proxy .

This flowchart can help you decide which SSO method is best for your situation.

The following SSO protocols are available to use:

OpenID Connect and OAuth - Choose OpenID Connect and OAuth 2.0 if the application you're connecting to supports it. For more information, see OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform . For steps to implement OpenID Connect SSO, see Set up OIDC-based single sign-on for an application in Microsoft Entra ID .

SAML - Choose SAML whenever possible for existing applications that don't use OpenID Connect or OAuth. For more information, see single sign-on SAML protocol .

Password-based - Choose password-based when the application has an HTML sign-in page. Password-based SSO is also known as password vaulting. Password-based SSO enables you to manage user access and passwords to web applications that don't support identity federation. It's also useful where several users need to share a single account, such as to your organization's social media app accounts.

Password-based SSO supports applications that require multiple sign-in fields for applications that require more than just username and password fields to sign in. You can customize the labels of the username and password fields your users see on My Apps when they enter their credentials. For steps to implement password-based SSO, see Password-based single sign-on .

Linked - Choose linked when the application is configured for SSO in another identity provider service. The linked option lets you configure the target location when a user selects the application in your organization's end user portals. You can add a link to a custom web application that currently uses federation, such as Active Directory Federation Services (ADFS).

You can also add links to specific web pages that you want to appear on your user's access panels and to an app that doesn't require authentication. The Linked option doesn't provide sign-on functionality through Microsoft Entra credentials. For steps to implement linked SSO, see Linked single sign-on .

Disabled - Choose disabled SSO when the application isn't ready to be configured for SSO.

Integrated Windows Authentication (IWA) - Choose IWA single sign-on for applications that use IWA, or for claims-aware applications. For more information, see Kerberos Constrained Delegation for single sign-on to your applications with Application Proxy .

Header-based - Choose header-based single sign-on when the application uses headers for authentication. For more information, see Header-based SSO .

• Enable single sign-on for applications by using Microsoft Entra ID .

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources