6th February, 2022
TABLE OF CONTENTS
SSO can be an asset if used rightly. They make organizations secure and save employees time logging in and out of different apps. But the same can become a liability when performed without a complete understanding of SSO implementation and management. The way to flawless implementation of SSO is easy once you grasp the best practices involved with the usage and implementation.
Built on the idea of trust between an application and service provider, SSO or single sign-on is an authentication scheme.
This scheme fosters the use of the same login details across platforms. So, all you need is one password for all the applications that are SSO-enabled.
Yet, remember that SSO resounds with convenience when used correctly, but it also hints at harm when dealt with incorrectly.
For instance, if someone wants to hack into one of your platforms, they just need to hack into one platform to get hold of all the other ones.
But at the same time, the hassle of remembering multiple sets of login credentials is ruled out.
At the enterprise level, SSO is crucial. The use of SSO is a simple task, but its implementation is complex.
There are so many jargons and heavy terms involved that one can get lost in them. The documents are also extensively specific and leave no room for generalization.
What’s the solution?
To mitigate the complexity and understand the use of SSO better, we have compiled a list of best practices for you.
SSO implementation depends highly on the applications a particular company plans to access via SSO. This involves considering the ways in which the customers are managing their accounts. The understanding of “Why is SSO used?” is important here.
We need to ask this because various options are available.
You must prepare a set of questions to ask your customers. Following are some important questions:
What applications do they use? Are they using Google Apps or Gmail?
Do all company officials have an account on Github via work email address?
Do they possess an active directory server or identity provider that is internally managed?
Do they possess a vendor for single sign-on?
Using what method do they log in and manage all the user accounts via other SaaS vendors?
Once you get the answers to all these questions, you will gain more clarity about the direction in which your implementation process should proceed.
SSO is jargon-laden. When you take a look at SSO tutorials, documentation, standards, etc., you will find it difficult to make sense of it all.
At times, the same term holds a different meaning in different scenarios. Therefore, it is crucial to understand these three important concepts involved with SSO
When we say the user, principal, or client, we are referring to someone whose identity is being verified. This is done to give them access to the application in question.
The application is nothing but the service provider. It uses a third party for the verification of the user’s credentials.
The identity provider serves as the authority responsible for the verification of the user’s identity and furnishing claims.
When it comes to SSO standards, there are various shared authorization and authentication schemes. When one uses the term “standard,” it is typically used without a precise meaning.
While some may sound highly similar, they are quite different. Let us see some:
OpenID - OpenID is a somewhat obsolete standard for maintaining a digital identity via an identity provider. Its obsoletion is in terms of verifying the identity of other websites called Service Providers. OpenID has been replaced by a newer version called OpenID connect.
SAML - This language is based on XML data format and protocol for user authentication. SAML has been around for a long time, and it is far more common for bigger enterprises. Companies that are highly modern, like Google, still work with SAML-based SSO workflow.
OpenID Connect is the fairly latest standard authentication protocol and data format. It is the better version of OpenID. It follows a design similar to Facebook Connect and has been taken up by Google as well as other big providers.
Various standards and protocols were made with a special focus on the web app in a browser. In case your application does not gel with the given mold, then your implementation choices will perish.
Mobile apps typically don’t have access to the cookies stored in the mobile’s browser generating HTTP requests. Using these cookies, all the Identity Providers keep the logged-in state. In the absence of that state, the mobile app could use credentials from Identity Provider. Yet, the user must log in again for every new app.
The authentication flow of standard SSO includes a minimum of one communication step between the server of the application and the Identity Provider. Yet, try to avoid the server with a single-page app. In case you do not, you might want to give up the application state via the typical redirect-based approach.
Administration best practices help in making the workflow smooth with SSO. With these at your disposal, you can make the task of adopting SSO quite easy.
You can skip email verification when you get into SSO setup, as it enables you to verify emails at the same time. This aids in reducing the time taken into the account creation process.
In-time provisioning reduces the manual work, reduces the wait time, and attains the ultimate goal of SSO by propagating the user account of the customer’s account management into the application. This demands automation of the process that generates a new account and grants correct permissions to new users.
It is essential to decide which is more important, whether it is the manual sign-in or SSO use. For specific applications, the preference may hinge on whether to use the manual sign-in or others; SSO may be preferred. It is better to attain a clarification as to which is more preferred under which particular scenario.
When you are working with various Identity Providers, you must ask for the email address or URL of a unique account of users—this aids in determining the right Identity Provider. As per the direct approach, you can offer buttons for each provider. This will result in a cluttered UI. The very assumption that the user knows the provider the company uses is faulty.
To cut short on the manual inputs, you can use a lifetime cookie that tells which Identity Provider a particular user is associated with. As they log in the next time, they will be redirected to the authentication page right away. In case they have an active session, they will be signed in without following a single extra step.
Most enterprise organizations do not focus on sufficient procurement standards to ensure the tools have SSO, provisioning, and de-provisioning. Security is, at times, consulted far too late in the entire selection process.
This generally means most choices have already been made, and the money has already been spent; the tools used might not use SSO. The capability of single sign-on uses the fact that various tools use it.
For any authentication that is based on a password, a second-factor authentication could not assure complete security. Yet, it adds an additional level of security and minimizes the incidents of compromise by a considerable amount.
One of the weakest things about any SSO tool is the time taken by people to log into it. Various organizations still depend on short passwords that are rotated many times.
You can work on strengthening the weak links within an SSO workflow. These include policies based on password rotation and selection. The users must employ the use of a password manager and update SSO logins with good passwords.
The SSO solution might comply with the industry specifications and be secure otherwise when it resides within your organization’s IT architecture.
Various security strategies depend on automatic blacklisting of malicious IP addresses, right from the access of a system or allowing a particular specific IP subnet to connect to one.
Just as HTTPS helps in securing HTTP, FTPS, and SFTP for FTP is, far more secure protocols are there for your existing SSO setup.
It works on an extra layer of protection via TLS with certificates and security keys. Typically, secure LDAP is customized. It is not a part of the actual LDAP standard. This is why added verification is required. You must check if the LDAPS library is correctly using SSL with reference to a hostname and certificate validation.
In this post, we've discussed 7 symptoms of an unoptimized SaaS stack and solutions to optimize the same.
In this post, you'll learn about shadow IT due to SaaS apps. You'll also learn the most common types of shadow apps categories, shadow IT risks, and shadow IT benefits.
An obese SaaS stack leads to SaaS wastage. It's a disease! It not only causes financial issues but also gives you security and compliance problems. That's why you must keep tight control on your SaaS stack. And it begins with managing your SaaS vendors.
When an organization has a large number of SaaS applications in its SaaS stack, it gives rise to SaaS Sprawl.
SaaS operations consist of procuring the right set of SaaS apps, managing access to these apps by users/departments, monitoring their usage, and offboarding them properly when they are no longer needed.
The GRC tools are not one-size-fits-all kinds of stuff. A wide range of products and solutions are available in the market to meet the requirements of various kinds of businesses. Because of this, choosing a perfect GRC tool can be a little difficult for you.
The main purpose for implementing user provisioning is for security and compliance. But in the SaaS world, there are much more shadow apps than those bought by the IT and procurement teams.
Access control systems and processes limit access to sensitive information, such as customer information, employee data, intellectual property, trade secrets, operational or inventory information, and industry-specific data.