Hi Prashant,
If the application you're trying to integrate is an off-the-shelf application, the options available for Single Sign-On depend a lot on what the application supports. For applications running on a platform, the options depend on the options for the platform and whether the application is integrated with the platform services. For custom applications - or applications that can be modified - there are many choices... something standard is usually a good idea.
Single Sign-On has progressed in recent times. Ten years ago, it was rare to find applications that supported protocols such as SAML (or OpenID Connect). This is much more common now and a simple way to achieve single sign-on. These protocols can be used both when the application is independent from the IAM plaform (like an external SaaS or partner service) or for applications that are more tightly integrated. Where these protocols are supported, these are your go-to methods for SSO.
Most of the other SSO methods supported by ISAM (now IBM Verify Access) are designed to work when the Reverse Proxy is in-line with the application. The user authenticates to the Reverse Proxy and it asserts identity to the backend server.
The most up-to-date method of this type is passing a signed JSON Web Token in an agreed HTTP header. Many modern platforms support this method of identity assertion. IBM WebSphere Liberty is a good example. Using a standards based token in this way leads to looser coupling and removes reliance on proprietary or less-adopted technologies.
For older applications, or other applications that don't support JWT tokens or SAML or OIDC, you need something else. IBM supports the native SSO methods of a number of platforms - either with built-in technology or via integration plugins.
You mention LTPA in your question. LTPA is a proprietary SSO method from IBM. It was developed for WebSphere Application Server but is also supported by some other IBM systems (like Lotus Domino for example). The main limitation for LTPA is that the full DN of the user is passed in the token - so it can be hard to use if the systems do not share a common directory.
For WebSphere Application Server there is an alternative to LTPA which is "TAI" (Trust Association Interceptor). This passes just the username and so works well even when different registries are used. In fact, it can even work even when users are not defined in the WAS directory. In most cases you would be better off looking to JWT though.
For Microsoft platforms, Kerberos is commonly used for SSO. We support accepting Kerberos tokens (for Desktop SSO) and passing delegated Kerberos tokens downstream for SSO. This is a common and easy way to integrate with IIS and other applications that are hosted on it (like Sharepoint). It's worth noting that once you get into the modern MS offerings, like O365, you're back to SAML again (which is good news). IBM Verify Access (or indeed our IBM Verify IDaaS offering) can support environments where users authenticate against local Active Directory and access O365 via SAML. This requires transmission of an Immutable ID that is shared between these systems.
Whether or not another web/application server supports Kerberos as an authentication method depends on that server. There's no reason why they couldn't do so - it's just whether or not the vendor has prioritized this capability. These days it is more likely they would support JWT or SAML/OIDC.
For custom applications that are built on a application server platform that supports a standard SSO method, you can use that platform SSO if the application is integrated into the platform authentication services. However, this is not always the case.
If you have an application that performs its own user validation (with users stored in a database for example), it is hard to see how you can integrate that without making code changes or by using a method such as form-filling. If possible, code changes are better than form-filling because form-filling usually means you also have to worry about account and password synchronization - and storage of passwords in a reversible way. That is not good security in most cases.
OK, I think that's enough to get a conversation started. If you have further questions for the community, feel free to continue this thread.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Mon June 29, 2020 10:31 AM
From: Prashant Narkhede
Subject: ISAM - SSO mechanism and expectations from back-end application
Hi All,
I am exploring different SSO mechanism available with ISAM. For the configurations, I am referring to info center.
However, before that, I am looking for on what basis the SSO mechanism should be selected and what architecture or criteria back-end application must fulfill to get it implemented.
This might be a very basic thing for you guys that I am looking for but I don't find any information about it on info center. It talks more about the overview of mechanisms and steps to configure it.
I have below queries about the same.
1. A simple JSP-Servlet application deployed on Web Server having a login page and its users and groups are maintained in the database. Is it possible to implement real SSO(not the sso using gso) for this? how?
If any customer has such an application then what to do? Does it lead to modification of the back-end app?
2. are there any restrictions or constraints or expectations from the back-end application in order to implement the SSO using LTPA? Or it can be done for any application deployed on WebSphere?
3. I observed that Windows Desktop single-sign-on and Kerberos delegated authentication is being used with active directory, applications that are deployed on IIS, and applications using Windows Authentication.
Can it be used with application deployed on any other Web Server(not IIS) using active directory as authentication and having its own login page? If yes then how? If no then which is one to use?
Is there any matrix or guidelines to decide which SSO mechanism should be used and when? and the expectations from the back-end application to work with it?
------------------------------
Thanks and Regards,
Prashant
------------------------------