Delivering Single Sign-on: The Three Patterns

By Author: Appsian
Total Articles: 115
Comment this article

Delivering Single Sign-On: The Three Patterns

You understand the integration choices when you are trying to deliver SSO for an application, looking at the various design trends. Basically, there are only three distinct trends.

Pattern 1: Open standards-based integration

This is the first and most commonly used trend, especially for modern apps or cloud-based services. It is based on the fact that open standards for SSO should be accepted by your Identity and Access Management (IAM) platform and your new application also follows one of those same standards, i.e., SAML 2.0, OpenID Connect 1.0, and OAuth 2.0.

With this method, you configure a trusted digital relationship between your IAM platform and your application (by exchanging digital certificates and metadata) and use that trusted relationship to share identity details. In this relationship, your identity and access portal serve as the authoritative source of identity information, and that identity information is consumed by your application.

There are distinct flows and slightly different terms in each open standard, but if both your IAM ...
... platform and your framework support a similar standard, then you will most likely find an acceptable profile to use. After that, you determine the characteristics you will share between the two sides.

One of the advantages of this pattern of integration is that it is generally very simple and easy to set up. Many individuals are familiar with standards such as SAML and are comfortable with the appropriate flows and configuration measures.

Pattern 2: Header-based integration

This is the next most popular technique which can be used when you have an application that recognizes the SSO concept but does not support any of the above open standards. Usually, these apps recognize that the user will be authenticated by an external network and that they need a process to accept an identity from that trusted platform.

Protecting access to the application through the IAM platform, using the IAM platform to authenticate and authorize the user, and then propagating the identity of the user to the application is the common approach to achieving this. Since this cannot be achieved using an open standard identity token such as a SAML assertion, the IAM platform typically populates one or more header variables on the user's inbound request as it flows through the IAM platform.

In between the user and the program, the IAM platform lies. Typically, this is some agent deployed on the webserver of the application. The agent intercepts the requests from the user before allowing them through to the application and populating the header variables on the way, ensuring the user is authenticated and approved. It is also necessary to secure access to the application in this model to ensure that the only path to the application from a user is through the agent and that the application accepts only requests from the server with the deployed agent. It is configured on the application side to expect and trust a header variable from the IAM platform to be sent, and it will use the header variable containing the identity of the user to establish a session for that particular user.

Given the fact as to how long web access management technologies have been available, many applications commonly embrace this header-based integration approach.

Pattern 3: Form fill

When it comes to SSO, this is always the last-ditch attempt. If you need SSO and your application doesn't support patterns 1 or 2, then this integration pattern is the one to examine. It is applicable when a username and password are often prompted by your application and do not support standards or headers.

For each app, your IAM platform will store the user's username and password. It shows the IAM framework what the device login screen looks like. For that application, the IAM platform will retrieve the user's credentials when you initiate that application, populate the values into the login form, and apply the form on behalf of the user. How this is achieved by the IAM platform depends on which kind of applications you are using.

Single Sign-On, in summary, is a well-trodden route, and you can only provide SSO to your applications in a small number of ways. In your organization, you can determine which pattern each app can fit into and document how you execute each of these patterns. That way, it's only going to be a case of plugging every application into the right pattern.

Appsian One of the leading ERP data security,compliance,implementation solutions provider that gives organizations to complete control and visibility over their ERP data.