Pragmatic Approach, Practical Designs, Secure Implementations

In this blog I would like to discuss options on how to extend the reach of your existing or new enterprise security services to client server and any non-web applications.

Hopefully you already have a centralized web authentication and maybe even authorization engine built around products like Oracle Access Manager, Siteminder or other similar products and you would like to extend your reach into client server and legacy application world.

The reason for doing this is attractive from security operations and application delivery perspective. If new or existing application can rely on external security service, they can delegate all identity management tasks to it. If application relies on external authentication service, users do not need to worry about password reset, forgotten passwords and to some extent about application identity provisioning because they can leverage existing supported processes.

You also would want to provide users with seamless application access so they are never challenged for their password again. In order to achieve this functionality, solution needs to rely on some type of session which was created when user originally logged into the network environment.

In vast majority of cases in the enterprise environment initial login will be processed by Microsoft Active Directory, but even if it is not, principles around our solution will remain the same. Successful login will generate some type of security session stored at user workstation either in the form of Kerberos ticket, cookie or similar secure object. This session is available for use as we see fit for other purposes, it just needs to be adopted to format which can be processed and understood by other applications.

In order to take advantage of this approach, legacy applications will need to be modified to bypass their normal authentication functionality and call platform specific plugin for that purpose. Bypassing local authentication is typically not a difficult change for application support team, but it will provide many operational and security benefits.

On the diagram above you can see high level approach to integration of legacy applications with Windows Integrated Authentication (IWA). Now let's walk through the steps to demonstrated the concept:

  1. User launches client server or legacy application on her desktop
  2. Application is configured to bypass internal authentication mechanisms and will just call platform specific function GetUserCredentials(). Optionally this call may include arguments which can tell what type of authentication user is requesting to make it more universal to cover cases where user is not logged into Microsoft domain and needs to be presented with interactive dialog.
  3. GetUserCredentials() plugin performs simple browser redirect call to IIS server which is capable of processing domain Kerberos ticket located in user workstation memory.
  4. IIS server receives Kerberos ticket and validates it with AD domain controller.
  5. Once ticket is validated, necessary user information (user ID, roles, groups) is retrieved from the directory and sent back to user application as a response
  6. Client server platform plugin returns user ID and optional user parameters to an application which now can proceed with it further processing.

Communication between application plugin and backend security services can be done using any message format, but if SAML infrastructure is already available, it makes a lot od sense to rely it. SAML natively support transmission of authentication parameters and custom attributes which can be secured by encryption and digital signatures. Also XML processing is greatly simplified with the use of libraries available on all major application platforms.

Application plugin can be configured to deliver entire XML message to an application or to extract all necessary parameters after validating custom or SAML token. Even in the solutions where custom tokens will be used, they will need to be protected from common replay and man-in-the-middle attacks to protect applications from accepting authentication and authorization messages from unauthorized sources.