Modernizing Access with Single Sign-On

As more and more organizations choose Trakstar, we see an increasing variety in how organizations provide their users access to important applications. Recently, we’ve made major improvements in how users can sign in to Trakstar, and allowed admins more flexibility in implementing alternatives to the standard username and password login, such as single sign-on (“SSO”). We’ve learned a lot about the pros and cons of such solutions, as well as the wide variety of them available.

First off, SSO can save your organization a lot of time, once set up. Your users can log in once, and get access to most or all of the applications they need. Users aren’t prompted for their username or password if they visit another application that’s also connected – they’re just logged right in.

Administrators spend less time helping users that forgot their passwords when users only have to remember single one. Some solutions, like OneLogin, offer a “portal” that includes all of the applications a user is able to access, providing a one-click sign-in. Combining this with the ability for administrators to quickly assign and remove services from users, both individually and in groups, you can see the time savings add up quickly! There are even solutions that provide instant access to applications after signing in to your workstation.

Growing companies can benefit the most from the time saved, as a single login and automatic provisioning of accounts can greatly reduce the effort required to set up work environments for new users. This also makes revoking access to applications effortless, rather than impossible (depending on how the accounts were created in the first place).

Enhancing security can be a major benefit of implementing SSO. Passwords often do not provide as much security as you’d think. Most people use the same password for all of their accounts, meaning that a password exposed for one account is very likely to compromise all of them. While many software vendors allow specifying requirements for passwords, it varies from vendor to vendor, and is difficult to enforce across them all.

Using SSO allows an organization to effectively enforce requirements across each of its vendors. It allows administrators to add additional security features, like multi-factor authentication, to applications that otherwise wouldn’t have them, raising the bar for your organization’s security.

Support for SSO is getting more and more common. Many vendors, especially web-based ones, support open standards like SAML (we do!). This is great, as it allows organizations to choose the right tool for the job, rather than choosing an inferior product because users already have access to it.

Your organization might already have a centralized identity mechanism in place and not even know it. If your organization uses G Suite (formerly Google Apps for Work), you can choose apps from its marketplace, or connect to any application that supports SAML. Microsoft technologies like Azure Active Directory, ADFS, and Office 365 (in some cases) can be used as a central login, and allow even non-Microsoft applications to connect using the SAML standard. A variety of independent solutions with their own major benefits also exist (OneLogin, Okta, and Ping Identity to name a few), many of which can connect what you’re already using, like Active Directory, Workday, and Google.

With all of these positives, is SSO a no-brainer to implement for your organization? Often times, the answer is not so straightforward. Setting up SSO requires upfront work by technical teams that are often already juggling many projects. There are many options, which makes choosing the one that best meets your organization’s needs more difficult. Inconsistencies among user accounts in your current systems can cause headaches, and centralizing your organization’s identities into a single system can be quite difficult if it hasn’t been done before (although OneLogin offers a good solution for this).

The initial implementation is only the beginning as applications are added, and the effort required to add an application varies greatly, depending on the application and how many of your users are already using it. Keep in mind the main benefits and goals for your organization, and balance them with the effort required to make the required changes.