In my last article I discussed the identity management challenges you need to consider when onboarding a new application/service. I talked about single sign-on (SSO) and how, whilst it is a fairly common capability, there are still organisations yet to adopt it, or at least not widely.
I thought it would be useful to discuss SSO further, looking at the different architecture patterns, so that, when you are looking to deliver SSO for an application, whether it is deployed on-premise or in the Cloud, you understand your integration options.
Fundamentally, there are only 3 different patterns.
Pattern 1 – Open standards-based integration
This is the first, and in my experience the most widely used pattern, especially for modern applications or cloud-based services. It is based on the fact that your Identity and Access Management (IAM) platform should support open standards for SSO and your new application also supports one of those same standards, i.e. SAML 2.0, OAuth 2.0, and OpenID Connect 1.0.
With this approach you configure a digitally trusted relationship (by exchanging digital certificates and metadata) between your IAM platform and your application and use that trusted relationship to exchange identity information. In this relationship, you have your identity and access platform acting as the authoritative source of identity information and your application consuming that identity information, as shown below.
Each open standard has different flows and slightly different terminology, but if your IAM platform and your application both support a common standard, then you will most likely find a suitable profile to use. After that, you decide which attributes you will be exchanging between the two parties.
One of the benefits of this integration pattern is that it is normally very quick and easy to set-up. Many people are familiar with standards like SAML and therefore comfortable with the flows and the configuration steps necessary.
Pattern 2 – Header-based integration
This is the next most common approach and can be used when you have an application that understands the concept of SSO, but doesn’t support any of the open standards mentioned above. These apps typically understand that an external platform will do the user’s authentication and that they need a mechanism to accept an identity from that trusted platform.
The common approach to achieving this is to protect access to the application with your IAM platform, use the IAM platform to authenticate and authorise the user, and then propagate the user’s identity to the application. Since this can’t be done using an open standard identity token like a JWT token or a SAML assertion, it is usually done by the IAM platform populating one or more header variables on the inbound request from the user as it flows through the IAM platform.
As you can see, this approach is different to pattern 1. The IAM platform sits in-between the user and the application. This is normally some type of agent deployed on the application’s web server, or on a reverse proxy server deployed in front of the application. The agent is intercepting the requests from the user, ensuring the user is authenticated and authorised before letting their request through to the application and populating the header variables on the way. In this model it is also important to secure access to the application to ensure that a user’s only path to the application is through the agent and that the application only accepts requests from the server with the agent deployed. On the application’s side, it is configured to expect and trust a header variable being sent from the IAM platform, and it will use that header variable containing the user’s identity to create a session for that user.
Given how long web access management technologies have been available, this header-based integration approach is widely supported by many applications. In my experience, it will be the slightly older web-based apps that will support this approach.
Pattern 3 – Form fill
I shudder every time I think of this integration pattern. It really is the last-ditch effort when it comes to SSO. If your application doesn’t support patterns 1 or 2 and you REALLY need SSO, then this integration pattern is the one to investigate. It is applicable when your application always prompts you for a username and password and doesn’t support standards or headers.
So, how does it work? Well, your IAM platform will store the user’s username and password for each app. The IAM platform is taught what the login screen for the application looks like. For example, it will know what the HTML form fields are called, and which values each field is expecting (i.e. the username or password values). When you launch that application, the IAM platform will retrieve the user’s credentials for that application, populate the values into the login form that is presented and submit the form on behalf of the user.
How the IAM platform does this depends on which type of applications you are using. Some platforms will use a browser-based plug-in if your apps are all web-based, whereas others will use a client installed on the user’s desktop, which means they can usually support non-web-based apps, such as fat client applications etc.
Why do I dislike this approach? Well, it’s a sticking plaster, solving the user experience problem without solving the underlying identity management challenges. You still have to manage a password for the user in the targets. If that password changes, the stored password within the IAM platform also needs changing, either programmatically, or manually by the end-user (i.e. back to a poor user experience). You also have a client to maintain, patch, update etc. It may be a desktop client or it may be a browser plug-in but that comes with all of the baggage associated with platform/browser certifications etc.
I always see this pattern as the last resort and I would carefully consider whether you really need SSO to that application, or whether the application could be updated to support either pattern 1 or 2.
In summary, single sign-on isn’t a topic you should fear. It is a well-trodden path and there are only a finite number of ways that you can deliver SSO to your applications. You should evaluate which pattern each app will fit into and document how you deliver each of these patterns within your organisation. That way, it will just be a case of plugging each application into the correct pattern. Please visit our website to learn more about Oracle Identity and Access Management and SSO.