Skip to main content

Entra ID SSO For Those Other Apps


Having all your enterprise apps plugged into Entra ID SSO is certainly a goal for most organisations but it's not easily achieved. Many applications charge extra for SSO functionality or restrict it to the most expensive plans. Some applications may not even offer SSO as an option, older applications in particular. 

Enter Password-based SSO, old technology that we might have forgotten about. It's a password vaulting solution where Entra stores your password for you. "But passwords are insecure." I hear you say and you might be right.  This pragmatic approach tries to use tech we are already paying for, to better secure your app. If you don't have the access to other forms of SSO then this might be something to consider. 

What does it get you?

Long random passwords are the best option, but end users don't like them because we ask them to manage the password themselves. This means users end up reusing passwords or use short and easily remembered passwords. Sometimes end users will uses a password manager. Sometimes it will be an organisation provided password manager, if this is you well done. Often it's the password manager built into the browser. An Entra ID vaulted password moves the location of the password off the endpoint and takes this burden away from the end user. As attacks against the end point increase this can only be a good thing. Vaulted passwords can be long and random. Everything a good password should be. There is no reason you can't use passwords that are as long as the applications supports. 64 character plus passwords become possible. 

Phishing attacks are another common problem that end users face. Vaulted passwords use a unique URL that Entra then uses to provide access to the application. This means that the vaulted password isn't accessible without first using this URL, protecting the user from phishing attacks for the application.

The last thing you get is having the application plugged into Entra ID. That means some logging but mostly conditional access. If you want to require access to the application only from a managed device then this is now possible. As are many of the other controls conditional access provides you with. 

There are 3 possible deployment scenarios I'll cover here. I'm sure you will find uses for them somewhere across your organisation.

Setting up Password-based SSO

There are three components to the solution: a browser extension, an Entra ID Enterprise Application and the My Apps portal.

Browser Extension

The My Apps Secure Sign-in Extension will need to be deployed to your organisations browser. It is a good idea to make this extension visible in the browser UI as users will be required to sign in to use the extension. The extension will respond to the app URL from Entra ID and fill the username and password in on the users behalf.

Entra ID Enterprise App

Let's create an Enterprise App with Password-based SSO:

  1. Sign-in to Entra ID and navigate to Enterprise Applications.
  2. Click the "New application" button at the top of the page then the "Create your own application" button.
  3. Give the application a name. This will be seen by the end user so make it something appropriate. Choose the option to "Integrate any other application you don't find in the gallery (Non-gallery)" and click "Create" at the bottom of the page.
  4. Once the app is created navigate to the "Single sign-on" tab and choose the "Password-based" option.
  5. Enter the the URL for the sign-in page of the application and click save. Entra ID will attempt to auto detect the username and password fields on the page. If this doesn't happen automatically there is a manual method that uses the My Apps extension to learn the fields that you use for sign in. I have had success by filling in something that looks like the right credentials for applications that I don't have a sign-in for. Entra just needs to learn the fields used to sign-in.
  6. Once single sign-in has been configured head over to the Users and groups tab. What you do here can result in one of 3 different configuration options. 

Single Sign-in Types

  • Shared User Account
    This scenario is best for sharing a single user account among multiple users. There are dozens of uses for this type of sign-in, social media is a common one but they crop up all the time. These accounts either have a username and password that is shared widely or only one person looks after the account. When that person leaves the organisation no one can get in or a password reset needs to be performed. 
    Change the user for this app to a generic user. According to your need create either: an email address alias, distribution list or make use of an existing or new shared mailbox. This way any communications from the account are attended to by the right people. 
    In Entra ID add a group to the app. Select the group and click on the "Update credentials" button. Enter the shared username and password for the app. Be sure to reset the password to something long and random. This set of credentials will be used by everyone in the group. Ensure that the same users are in this group and the email option you configured above.
    What about MFA? If the account supports TOTP it's best to configure it. When setting it up look for options for manual setup so this you can capture the seed token. There is a notes section in the application properties where this could be saved. If you save it in another location documenting it here is a good idea. You can now share the seed token with the users of the app to set up MFA. Alternatively you could share the QR code with your end users as this is easier for them to setup.
    The password remains unknown to the users in this case and only the MFA code is shared. 
  • Managed Individual Accounts
    This scenario works well for internally managed applications where the application administrator can set a perminiant password when the user is created. 
    In Entra ID add users individually rather than adding a group. Select the user and click on the "Update credentials" button. Enter the users username and password for the app. Be sure to set the password to something long and random. This set of credentials will be available to this user only. Granting the application administrator access to the Enterprise App in Entra ID allows setup to be complete without the end user needing to know the password. MFA can be setup by the end user themselves. 
  • Unmanaged Individual Accounts
    This scenario allows Entra ID to act like a password manager for the end user. Quite useful if you don't have an enterprise password manager deployed. 
    Setup just requires users or groups to be added to the app. That's it. End users can now visit the My Apps portal (https://myapps.microsoft.com) locate the app, click on the ellipsis and choose "Manage your application". A new screen will open. Clicking on "Add credentials" on the right side of the screen will allow the end user to enter their username and password for the application. End users can be encouraged to create long random passwords by providing them with online password generators like this one from Bitwarden: https://bitwarden.com/password-generator/ This scenario might need to be supported by internal policy as well to encourage end users to do the right thing.
One kind of application that isn't particularly well suited to this tool are applications that require regular password changes. Normally the password update workflow requires the user to enter the current password before they enter a new password. In Entra ID the plain text of the password isn't available again once the credentials have been saved making password updates impossible. 

Is this a perfect solution? No. Will it work for all password-based applications? Probably not, but it's a significant improvement in application protection and governance than would otherwise exist. 

My Apps Portal

This is the central location that grants uses access to the SSO app you have built. (https://myapps.microsoft.com) As mentioned above it's where Unmanaged Individual Accounts can enter their credentials. It's also were the Entra ID link to the application can be found for users wanting to place links to these applications in browser bookmarks.
Curation of this portal is done from Entra ID > Enterprise applications > App launchers. We humans are visual creatures so don't forget to give your a nice ican. 

Summary

Adding password-based SSO to your range of application sign-in options has the follow benefits:
  • increased password strength
  • improved phishing resistance
  • moves credentials off the endpoint
  • conditional access protections for the application
  • basic access logging
  • better application oversight and governance 
SSO is one of many security controls. Another control you might consider is disabling the browsers password manager. If you have all your main applications covered by SSO and you have a solution for casual password management then the next step might be disabling the browser's built in password manager. Browser password managers are certainly a popular target for info stealing malware. 

Password-based SSO is an incremental improvement over leaving application access up to the end user. Should we have more apps using SAML and Open ID Connect based SSO? Yes, but the reality is this isn't always possible. Having more of your apps covered by SSO will ultimately put your organisation is a more secure position. 

References