An application user identity exists essentially to specify a single user identity that is shared between client and AppServer sessions of a multi-tier application. The application user identity typically originates from the client and is used to set the OpenEdge session identity in each AppServer session. It might also be used for synchronizing database connection identity in each AppServer session.

In multi-tier applications, managing application user identity requires resolving these key issues:

  • How to securely authenticate and transport the application user identity between AppServer sessions and a given client session
  • How to share a single login for an application user identity across multiple requests to an AppServer running in stateless or state-free operating mode

Therefore, when running in stateless or state-free operating mode, an AppServer must:

  • Authenticate the user's identity once per client connection (stateless) or once per user login (state-free)
  • Share copies of a single client-principal object using a common client context storage to assert the user's identity on each agent involved in a given client's requests
  • Logout and destroy all copies of the client-principal object when the client disconnects (stateless) or logs out (state-free)

In OpenEdge, the basic mechanism for managing user identities is the client-principal object. Typically, in a multi-tier application, ABL code on an AppServer (authentication server) creates and maintains the client-principal object on behalf of the client and exchanges identity information, based on the operating mode, as described in the following table.

Table 1. Identity management for multi-tier applications
In this operating mode... The AppServer...
State-aware or state-reset Maintains a single client connection to a given agent. So, the agent only needs to assert and maintain the user's identity using a single client-principal object during the entire connection. The agent can then remove the client-principal object from session context when the client disconnects.
Stateless Maintains multiple client connections to the broker, which distributes client requests to any available agent. Because the broker maintains client connections, a shared client-principal object can be identified using the SERVER-CONNECTION-ID on the SESSION system handle. However, this value is only unique within an AppServer session. For auditing across multiple AppServer sessions, you might use a universal unique identifier (UUID) generated by the ABL GENERATE-UUID function to uniquely identify any recorded user login sessions, and use the SERVER-CONNECTION-ID on the SESSION system handle to key access to the client-principal object in client context storage.

Alternatively, you can use the ClientContextId property on the Progress.Lang.OERequestInfo object as described for state-free operating mode for both auditing and to key access to client context storage.
State-free Maintains no client connections. The broker distributes client requests as they arrive to any available agent. Because the broker maintains no client connections, the shared client-principal object must be identified based on a unique identifier, which you can generate using the ABL GENERATE-UUID function or which you can obtain and set as the value of the ClientContextId property on an Progress.Lang.OERequestInfo object using the following handle attributes, which return object references to instances appropriate for either sending the property value to the AppServer in a client request or returning the property value to the client in a server response:
  • AppServer client — The REQUEST-INFO and RESPONSE-INFO attributes on the server object handle for a given AppServer
  • AppServer agent — The CURRENT-REQUEST-INFO and CURRENT-RESPONSE-INFO attributes on the SESSION system handle of the agent that is servicing a given client request
This built-in support for different client and server instances of a Progress.Lang.OERequestInfo object conveniently allows the passing of a single ClientContextId property value on behalf of a single user identity to any level of a multi-tier application, where AppServers send client requests, in turn, to other AppServers.

Progress.Lang.OERequestInfo also includes the GetClientPrincipal( )and SetClientPrincipal( ), for accessing the client-principal object.

For example, in an application that uses server authentication, the authenticating AppServer can provide this value to both initialize and store each client-principal object that it authenticates, seals, and exports back to the client in response to its initial login request. The client can then return the same unique value with each request to an application AppServer in the same login session. The responding AppServer agent can then use the value as a key to import the shared client-principal object from client context storage to set its application identity before servicing the client request, and so on.