Enabling single sign-on (SSO) for SaaS applications adds convenience for end users, as well as reduces security risks and enables you to better meet compliance requirements. Forcing users to remember where to go to sign-in, and then remember a separate username and password for every application, is a surefire way to increase Help desk calls and create end-user frustration. When you combine this constraint with manual processes to add and remove employees from applications when they join or leave the organization, you decrease the chance that you’ll get the task of adding and removing users done on time—which increases the risk of opening yourself up to compliance issues.
Using Entra ID (formerly Azure Active Directory) Premium to add SSO to your applications can solve all of these challenges. However, there are a few things you need to plan for if you’re going to take this approach. You’ll need to consider changes in the end-user experience, data cleanup tasks, and hidden costs of enabling SSO.
End User Experience Changes
The way end users sign in to applications might change when you add SSO. Depending on the application, the change might be nearly seamless. Some applications are smart enough to simply redirect a user to the SSO provider when the user enters his or her username or email address.
Other applications aren’t so smart, unfortunately. You might need to teach end users to click a new link on the application’s sign-in page, or users might need to go to a completely different URL to sign in with SSO.
You might decide to switch to the Entra Access Panel, shown below, to give users a single place to go for all their applications. However, this won’t solve years of bookmarks and habits.
Data Cleanup
Years of manually managing users in countless applications inevitably leads to inconsistencies in data, such as usernames, employee numbers, email addresses, and so forth. As you transition an application to SSO, consistent identifying data will be critical to successfully enabling SSO. For each application, you’ll need to identify the field or attribute in the application that the application uses to uniquely identify users.
That field or attribute will need to be sent in the Security Assertion Markup Language (SAML) assertion from Entra ID. You’ll need to make sure that each user in the application has the correct data populated. If you don’t do this, when you switch to SSO, users won’t be able to sign in, or they might sign in and discover that they don’t see their data. This is also a good opportunity to make sure you don’t have any inactive users whose accounts need to be cleaned up. Some applications even support outbound provisioning from Entra ID, which will let you automate the creation, maintenance, and deletion of user accounts.
Hidden Costs
For each application for which you’re planning to enable SSO, make sure you ask the application vendor about any one-time or recurring costs you might encounter. Although SSO greatly enhances security, some vendors choose to take advantage of this and translate the added value into an added cost. We’ve seen these costs occur in the form of one-time setup fees, increased recurring monthly fees, additional annual fees, and vendor support contract requirements. These costs generally aren’t substantial, and we usually don’t see them add up to an amount that hinders an SSO project; however, you’ll still need to budget for them.
Planning an SSO Project
Are you considering an SSO project? Do you need help planning and running SSO enablement for your applications? Get in touch today to learn how we’ve used Entra ID to enable SSO on countless applications for hundreds of thousands of end users.
