Configuring single sign-on
Single sign-on authentication done right improves user experience and makes it easier to manage enterprise security. Finsemble supports the popular providers, so it is likely that you already have one configured in your organization. Setting up SSO with Finsemble will simplify the use and administration of your smart desktops.
What is single sign-on
Single sign-on (SSO) is a session and user authentication system that allows a user to sign in to multiple independent systems by using a single set of credentials. The user doesn’t even need to be aware that various systems and apps require credentials. In other words, from the user’s perspective, it all just works. Behind the scenes, the SSO takes care of authenticating the user to all these different entities. All systems must be tied to the same authentication system in order for SSO to work properly.
SSO requires an authentication management provider, or identity provider (IdP). There are many such providers available. Finsemble supports Security Assertion Markup Language (SAML), and all SAML-based providers should work with Finsemble out of the box. Finsemble has been tested with Keycloak, Microsoft ADFS, and Google SSO (SAML based), but you can use any authentication provider that is browser-enabled (including SAML, OAuth, Integrated Windows Auth, and so on) or a Finsemble-integrated native app. We don’t recommend one provider over another.
In addition to SAML, we also support OAuth and any other authentication system that is browser-enabled, such as Integrated Windows Auth. For more detail, see Authenticating apps. To implement SSO, you typically add the SAML layer on top of an existing authentication system (for example, on top of the Windows Active directory) as the authentication system does not typically provide SAML out of the box. Microsoft ADFS is a good example of this, it provides SAML based SSO on top of Windows Active Directory.
Don’t confuse SSO with Microsoft Windows pass-through authentication. This form of authentication isn’t SAML based and therefore Finsemble doesn’t support it as a part of SSO. You can still have apps that use pass-through authentication on your smart desktop, but users might have to sign on to them separately. (See the Configuration gotchas section later in this topic.)
Advantages and disadvantages
There are several advantages to SSO. The first, and an obvious advantage is that SSO allows the user to remember one password instead of being forced to remember a separate password for each system. People are forgetful and remembering passwords is hard. And password recovery is time-consuming and annoying to the user. In addition, a finger slip while typing a password will cause a login to fail, causing even more aggravation. Single sign-on reduces the human error aspects associated with logins simply because there is less to remember and less to type.
Second, SSO reduces the number of steps that a user has to do before they can get started and continue working. No more stopping the flow for typing, and possibly retyping, passwords. SSO provides a seamless experience for users when logging into various systems through the use of one interconnected system. It’s faster and transparent.
The third main advantage is that your system administrators have more control over authentication, which helps make the overall system more secure. They can enforce and maintain password complexity rules, multi-factor authentication, and password rotation in one system.
So with all the good things that SSO provides, why would you not implement it? There are some disadvantages. None of them should stop you from using SSO, but you need to be aware of them.
The first is the relatively high one time cost of setting up an SSO system in terms of both money and time. You will need to research, buy, implement and test the new system. Also, if there is no existing system in place, your IT staff might require additional training, or you might need to hire new IT staff to augment the skills in your organization. You might need to implement and approve additional security protocols around the SSO system. It’s possible you might need to get additional software for the SSO IdP, application configuration, and possibly implementation of SAML protocols in custom software. But once done, all you need to do is maintain it.
There is also a different kind of price you pay for the convenience SSO brings. That price is an increased need to focus on additional security concerns around tying all the systems together. A hacker that gains access to your system can now also access all the systems and apps for which you have enabled SSO. Carefully crafted security policies will help mitigate this risk. Security concerns are high on everyone’s list of priorities, so this shouldn’t be surprising.
The next issue to consider is reliability. You need to plan for what happens if your user is ready to work but your provider is not available. For most companies, a login failure due to such an occurrence isn’t acceptable. For this reason, you should add planned redundancy of your systems in order to provide a reliable user experience.
In our case, a Finsemble desktop configured to hit an SSO endpoint that is down won't be able to get past the login prompt on startup. Moreover, no applications will be able to authenticate. In other words, if the SSO endpoint is down, even if Finsemble starts, no applications will be logged in and all will fail to start anyway.
Configuration gotchas
Setting up SSO is straightforward. Any issues will be caught at the setup time as long as you follow the established industry standard. Still, here are a few considerations to keep in mind.
SSO is the most effective when all applications are configured to use the same IdP. If you don't configure an app for the appropriate IdP, the app might use a different authentication method and the user will be prompted for additional logins. For this reason, we recommend that you collect information about every app on your users’ smart desktops before you begin implementing SSO. You can of course fix any issues as they arise, but it’s a lot easier to get it right the first time.
We recommend that you configure Finsemble with a startup login profile. This way, you can control access to the desktop and the apps that hit the same IdP will automatically log in. Users will have to login separately to the apps that don’t hit the same IdP and to native apps.
Keep in mind that Windows pass-through authentication and a SAML provider might not communicate. As a result, a native app with Windows pass-through will end up prompting the user for a login again.
Finally your organization might use multiple authentication systems for different applications or purposes. For example, some orgs are huge and have different login systems for APIs, user interface apps, or groups of technologies (such legacy .NET or web apps and new ones), or they might have separate stacks and technology teams in different departments. If this is the case in your org, you might be able to build a hybrid auth component to use in Finsemble on startup. This way, you can establish sessions or retrieve access tokens from each system to distribute to your applications as needed. Alternatively, Finsemble also supports multiple authentication profiles. Finally, we also support authentication on-demand allowing you to start an auth session only when needed. See Authentication for more details.