How (and why) to leverage Microsoft 365 Business to manage third-party applications

One capability of Azure Active Directory which is included in your Microsoft 365 Business subscription (but which hardly anyone is taking advantage of in the SMB space) is the ability to bring third-party SaaS applications under management, and assign them to end-users–publishing them centrally via an application portal (myapps.microsoft.com), and even (in some cases) enabling them for Single Sign-On.

From Azure Active Directory, find Enterprise Applications > All applications. Click New application. There a few thousand applications now available in the app gallery. You can search or browse by many different categories. If an application is not found here in the portal, then you can add custom (non-gallery) applications only with an Azure AD Premium P1 or P2 subscription.

By way of example only, I will search for and add an application from the Azure gallery—in this case Evernote.

Next, I can assign the application to individual users, or to a security group which I have created for this purpose. Go to Users and groups to make your assignments. I use a Security group to manage this access, named Apps-EvernoteAccess.

As soon as you have configured your apps and made your assignments, users will be able to see the application tile show up within their individual Azure AD access panel located at: https://myapps.microsoft.com

At this point, if a user were to click on this tile, it would just link them over to Evernote’s sign-in page, where they would then need to provide their credentials to login.

Configure Single Sign-On (SSO) to third-party applications

Just going through the exercise to identify who in the organization should be assigned which software packages is valuable in itself (more on that later), but the value to the end user comes afterward. Now that you have mapped out apps to users, you can also tie their authentication (via SAML) to those apps (assuming you have subscriptions at those providers which support it).

Find the Single Sign-On blade within the application. Not all applications will support “true” single sign-on using SAML, but almost any app will allow the user to store their credentials within the Azure AD portal (similar to LastPass, if you are familiar with that concept). The various SSO methods are depicted in the following screenshot.

• Disabled – Just like it says, essentially this will just make the application tile available in the app portal, but there is no SSO experience. The end-user would need to provide their unique logon ID and password for that app in order to login, every time they click the tile.
• SAML – If the app supports SAML (Security Assertion Markup Language), this is what you want. SAML provides “true” SSO, where Azure AD becomes the app’s Identity Provider, and all authentication requests are logged against Azure AD—whether they come in via the app portal, or not. This is the most secure option and recommended wherever possible.
• Password-based – Otherwise, if the app does not support SAML but still uses some form of username/password, then you can choose “password-based” SSO. This option simply stores credentials in Azure AD, and replays them into the third-party app on demand, to give the user an “SSO-like” experience (without being true single sign-on). The user can input and update their own password, or it can be managed by an administrator, and the user doesn’t have to know the password at all.
• Linked – You would use this option if you already had an application linked via another Identity Provider. You may choose this option if you are slowly migrating from another identity service such as Okta or AD FS, for instance, and wanted to publish links via the new portal before you switched them over to SAML.

Note: if you are able to implement SAML, that will also open up other options within the Provisioning and Self-service blades, where users may be allowed to request access and provision their own accounts, for example.

I will not go into the full details of setting up a SAML-based SSO experience. But I do want to give you some guidance to get started—the security benefits are just too great to ignore—since you can reduce the number of identities you manage, and centralize the security logs. Therefore, if you take the time to fold your apps in, then you can monitor, grant and terminate access to all your apps from one place: Azure AD. Plus, you can apply things like MFA, or Conditional access to the logon requests (requires an Azure AD Premium subscription).

Every app is a little bit different in terms of its deployment, although they all have similarities. Here are some basic guidelines I can give you. Microsoft links to a configuration guide for many common gallery applications.

In almost all cases where SAML is available, you will need to provide Azure AD and the third-party application portal with some URLs, certificates and/or XML files, so that each side can understand and talk with the other. Sometimes certain entries are optional. Microsoft and/or third-party vendors will likely have support documentation available, as pictured here in the case of Evernote.

Conclusion

It is difficult to express just how important this Enterprise Application feature could be for your organization or practice. Even if you cannot configure true SSO with SAML to every one of your applications, just the fact that you can track application assignments to users alone is huge.

Most small organizations have no software inventory to speak of. Which is too bad, because it is often necessary to have an inventory for various compliance bodies out there. Not to mention every major security framework requires it.

Poor inventory means blind spots. Blind spots mean weak protections. Weak protections is one of the primary reasons why SME’s are still the most vulnerable targets out there. From the point of view of an attacker, the average security posture for small businesses out in the wild looks a lot like swiss cheese—and it has gotten worse with the addition of so many SaaS products in the last few years.

Bottom line (I’ve said it before and I’ll say it again): You cannot protect what you don’t even know you have. Once you know what you have, then you can start taking steps to better protect it—SAML, MFA, Conditional access, limiting privilege, etc., etc. But it starts with knowing.

Microsoft 365 can help you wrap your arms around this whole cloudy mess: identities, applications, devices and data. And this corporate access panel, with the option for SSO in many cases, solves a big piece of the puzzle right here. So make it a point to start bringing your applications into the fold!