How Digital Certificates Enable Secure Single Sign-On (SSO)

Users in an organization typically need access to many applications to assign and complete their tasks, access email, write code and communicate with each other. Multiple apps require multiple sets of sign-on credentials.

The problem is that when you have many sign-on credentials, it’s easy to forget passwords. To avoid remembering many passwords, people use common/weak passwords for applications due to “password fatigue,” which puts your data at risk. 81% of company data breaches occur due to stolen/weak passwords.

A Secure Single Sign On (SSO) is a solution that helps you log into many applications securely using a single set of credentials. Let’s read through the principles and protocols of SSO, the concept of Federated Identity Management, and the role of SAML in SSO. Finally, let’s find out how using digital certificates makes SSO more effective for your organization.

Types of Secure SSO

Secure SSO is a user authentication service that allows users to use a single set of credentials, like a username and a password, to access multiple applications. Organizations of any size can use SSO to manage numerous credentials easily. There are three main types of SSO:

• Web SSO enables users to access web properties with a single set of credentials or a single identity. A system can recognize your credentials from one site to the next through the same set of credentials.
• Mobile SSO helps users access different apps on mobile devices through a single sign-on.
• Federated SSO connects users to different apps held by federated partners through the same credentials. Federated SSO allows users to connect to various apps without the burden of authentication methods. It’s how you sign in to various social media apps through the same credentials. 
• Enterprise SSOs are password managers with different components for clients and servers that use the same credentials to log into target applications. 

SSO Protocols

Some different standards and protocols provide SSO for web and enterprises. Let’s take a look at the main SSO protocols that are used today.  

Lightweight Directory Access Protocol (LDAP) 

The Lightweight Directory Access Protocol (LDAP) provides access to a directory containing credentials. LDAP exchanges information by implementing LDAP Data Interchange Format (LDIF). An LDAP directory can be shared across multiple apps. You can stack all user identities on the central server when you use the LDAP with Active Directory AD.

An app can directly authenticate users by placing an authentication request to the LDAP/AD server. The LDAP is open and a cross-platform protocol that can use multiple service providers. Many popular apps support LDAP, such as OpenVPN, Jenkins, and Kubernetes.

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) is another standard SSO implementation protocol. It uses XML files to exchange data between the user, the identity provider, and the app or the service provider.

SAML can provide requests to gain access to secure resources that include authentication elements and any attributes that provide real-time data about the user. SAML can also enforce and support Access Control Lists (ACLs).

OAuth2

OAuth is a more recent protocol developed by Google and Twitter at the start of 2006. Developed to compensate for the deficiencies in SAML for mobile platforms, the OAuth2 is based on JSON instead of XML. It is lighter and faster than SAML as it uses JWT tokens widely.

The OAuth2 protocol connects with the server and issues access to third-party apps before the resource owner’s consent. These access tokens are used by third-party applications like Bitbucket and Slack to access resources provided by the resource server. However, OAuth2 only authorizes users; it can’t authenticate users.

OpenID Connect

In OpenID Connect, the authorization server uses a user’s credentials after the browser places an authentication request. After verification, the user is provided access, and the subsequent authentication allows them to use multiple applications. They can use a single set of credentials to access various applications. OIDC is open standard organizations use to authenticate users on the server.

What is Federated Identity Management (FIM)?

Federated Identity Management (FIM) is a trust-based arrangement between various organizations or domains that enables users to use a single digital identity across various networks. The partners in an FIM are also called trust domains. For an FIM to work effectively, all the partners across the domain should have mutual trust.

Even though the domains maintain individual identity management, they are all interlinked through a third-party service provider. The third-party service provider stores all the user credentials and provides the platform for the trust mechanism that facilitates the FIM to work. The third-party provider is also known as the identity provider.

How is FIM different from SSO?

FIM is an important component of SSO; however, SSO can be independent of FIM. FIM is an arrangement between various organizations, helping subscribers sign into various applications using the same identifier.

A common use case for an FIM arrangement would be adding new users to an existing system post-merger and acquisition. Here, the new user credentials are stored with an identity provider. Every time they log in to the software as a service provider, the service provider trusts the IDP to authorize and grant access.

SSO is a vital component of FIM, but it differs from FIM in the following respects:

Thus, FIM and SSO differ mainly in the range of access that they provide to the user and how they improve the user experience by helping them access various functions and applications across single and federated organizations.

How does SSO work?

SSO authentication is based upon a trust relationship between a service and an identity provider to help users sign into various applications in an organization. The login flow of an SSO looks like this:

1. The user browses the application that he needs access to, i.e. the service provider.
2. The service provider sends a token that has their identity information to the identity provider. 
3. The identity provider checks for user authentication and grants access to the service app.
4. If the user has not been authenticated, they would be prompted to provide the identity credentials, which could be a username and password, email address, or a one-time password. 
5. The identity provider validates the credentials and transmits a token to the service provider for successful authentication.
6. The service provider validates the token against the trust relationship set between the identity provider and themself during the initial configuration.
7. Once the validation is through, the user gains access to the required application.

SAML and its use in SSO

Security Assertion Markup Language (SAML) is an open standard for authentication. It allows you to access applications using a single set of credentials. It passes the authentication information in a particular format to the identity provider and the web application.

The SAML simplifies the authentication process to access web applications across numerous domains. Previously, Secure SSO was achieved through cookies, but they were feasible only through their respective domains. Cookies facilitated authentication by centralizing the process with any identity provider. The web application could use SAML vis the ID provider to grant user access.

SAML SSO enhances user experience as they need to remember only a single credential to authenticate themself. It enables faster and more seamless access to apps and sites without repetitive password prompts. The user logs into the Identity provider and gains the needed access.

How SAML makes it easier to adopt SSO for organizations?

SAML helps users to authenticate without the need to remember numerous passwords. SAML is a boon to service providers as it boosts their platform security and helps bypass the need to store weak and insecure passwords or address password resets regularly.

Disadvantages of using SSO: 

Although SSO has numerous benefits, some risks and trade-offs come with implementing SSO tools. Some cons of SSO are

• SSO is expensive and burns your budget pretty soon. Though SSO is riddled with benefits, the numerous vendors and their costs add up quickly and make it difficult to scale. 
• SSO is limited to web apps. Managing web apps with SSO is a small part of Identity and Access Management  (IAM), requiring admins to create a host of other solutions to create an effective SSO environment. 
• You can authenticate yourself with a single set of credentials as a user. Still, an effective password should be long, complicated, complex, and secure. Forgetting the password leads to many reset requests or logging out of web apps.
• SSO is connected to many resources. Though passwords protect SSO portals,  they are still vulnerable to attacks and hacking threats. 

How do Digital Certificates protect SSO better?

SSO brings many benefits to an organization and its people, along with some undeniable drawbacks. The biggest drawback of the SSO is its vulnerability to attacks due to weak passwords/ not following best practices. A strong SSO solution needs a robust form of authentication in the form of digital certificates.

A certificate-based authentication like SecureW2 integrates with your SSO solution and provides identity context to help you monitor who or what device is connected to your network. Securew2s JoinNow suite helps onboard all the users onto your network, create customized access policies, and deploy passwordless certificate-based authentication.

No matter how big or small your organization is, SecureW2 has customized security solutions that work for everyone. Our vendor-neutral access control suite offers instant, out-of-the-box implementation and can be scaled to meet your needs. Click here to try our products and immediately see the difference in your network security.