How to Keep Single Sign-on Secure

Single Sign-on or SSO is an IT buzzword that you probably have seen or heard over the past few years, especially when dealing with Cloud providers like Microsoft. SSO is a service that works in conjunction with your identity provider, to streamline your login to multiple apps and services utilizing the same username and password combination. This gives your end users the familiarity of seeing the same login screens across all different services they utilize and allows them to only remember a single username and password combo to gain access to the systems. This is beneficial for several reasons, and I will just get into a few of them below.

Single Sign-on Benefits

One reason this is beneficial, is that this effort helps lower administrative effort for both the IT teams and the end users. The IT team does not need to change your organization’s Line of Business Application user passwords when they forget them or try to figure out how to lock out a compromised user from the environment until it can re-secured. For the end user, they just need to remember a single email address and password combo, and they can perform all their tasks, including logging into email, logging into their machine, logging into all other applications they need to perform their job, and keeping them out of restricted or secured locations in the infrastructure.

You can also setup a portal page with many of these identity providers that includes all the applications you have configured to work with SSO in your organization, to create a central repository for all business applications. This helps both teams be more effective and efficient and can direct additional effort toward their job goals, instead of password resets and access or security issues.

Using MFA with SSO

If you combine Multifactor Authentication with your SSO deployment, you are effectively securing each login with this same technology, across all your SSO applications. An example of this is using Microsoft 365 (Service) with Azure Active Directory or AAD (Identity Provider). AAD can be configured as Cloud only, or in a hybrid deployment that will sync your Local Active Directory up to AAD. This is recommended if you already have this internal Active Directory infrastructure configured. If hybrid is configured, you can also use AAD to protect local on-premise applications, servers, VPN devices, any many others too with the AAD Application Proxy.

While you probably already knew about AAD and Microsoft 365 and how they work together, Microsoft has made some serious investments in security technology for AAD recently that you should also consider. Since SSO for on-premise servers and devices requires Azure AD Premium Plan 1 licensing, these security features become unlocked in your AAD Tenant and can be configured during an SSO deployment. These include conditional access policies, password protection policies including banned password lists, self service password reset with writeback to local Active Directory, Dynamic group memberships and others as well.

Are you ready to start your journey to securing cloud apps and on-premise apps using Microsoft AAD as your identity management platform? Reach out to the Sikich Team today!

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author