Single Sign-on and AB Suite

By Gary Taylor, Senior Architect

Even as proprietary and commercial single sign-on (SSO) solutions flood the market, nearly all are built around a common theme: trust.

In the simplest sense, this trust takes the form of a token that’s exchanged between users and the applications, services, etc. they wish to access. It’s validation, confirmed by the SSO solution, that these users are who they say they are and can access – and move freely between – any resources that accept that token.
So, if we want to establish SSO in the Agile Business Suite (AB Suite®) environment, we must first create something that can be trusted, such as a security certificate. Sharing that certificate between each end of the user-resource communication establishes the basis for our SSO solution. Then, we’ll need to write code that creates a token from the security certificate – and uses the same certificate to decrypt that token.

How it Works

The first step was to create an external library that allowed us to encrypt and decrypt messages using the certificate’s public-private keys. These would then be called from the AB Suite application and ASP.Net code running on the web server. Because the Microsoft® Windows® and ClearPath® MCP environments can programmatically access certificates and encryption capabilities, we were able to develop two libraries, one written in .Net for use in Windows and another written in Algol for the MCP environment.

Several factors proved key to making this approach work: we could use standard Client Tools capabilities, the message was passed via a standard field, and nothing special was required other than the external libraries. Also, the solution did not place any additional constraints on the client or host. Finally, it provided a framework to easily add a different type of trust, should one be required,
by simply changing the external library.

The SSO solution utilizes the following logic flow:

1. At the AB Suite level, we created a new Ispec that’s called by the ASP.Net client.
2. The Ispec’s “Construct” logic calls the external library to create a basic token from the certificate’s public key. This message is wrapped as a BASE64 string, which allows it to be sent via – and placed in – a standard on-screen field. The message includes a randomly generated AES256 encryption key, as well.
3. At the ASP.Net level, the code reads the value off the screen, calls the external library to use the private key to decrypt the message, and retrieves the AES256 encryption key.
4. The AES256 encryption key then encrypts a reply token, including a timestamp and user ID, places it in the same on-screen field, and sends the data back to the host.
5. At the host, the reply is decrypted, which validates the user ID and grants access to the application. Also, to prevent spoofing of messages, the time stamp is examined and the message rejected if it falls outside definable parameters, such as more than “n” minutes old.

Further, to eliminate the need to provide host-level credentials, a RATL VIEW with a predefined user was created for the ASP.Net sessions. This meant that at the application level, we’re unable to use GLB.USER. Rather, the LDL+ code populates a field that’s part of GLB.WORK, with the user ID in the message returned from the ASP.Net host. All existing references to GLB.USER were then updated to use this GLB.WORK field.

If you’d like to learn more about SSO, or explore implementing an SSO solution in your organization,
please contact your Unisys sales representative.