Security attribute propagation: WAS ND

Security attribute propagation

Security attribute propagation enables WebSphere Application Server to transport security attributes (authenticated Subject contents and security context information) from one server to another in your configuration. WAS might obtain these security attributes from either an enterprise user registry, which queries static attributes, or a custom login module, which can query static or dynamic attributes. Dynamic security attributes, which are custom in nature, might include the authentication strength used for the connection, the identity of the original caller, the location of the original caller, the IP address of the original caller, and so on.

Security attribute propagation provides propagation services using Java serialization for any objects that are contained in the Subject. However, Java code must be able to serialize and deserialize these objects. The Java programming language specifies the rules for how Java code can serialize an object. Because problems can occur when dealing with different platforms and versions of software, WAS also offers a token framework that enables custom serialization functionality. The token framework has other benefits that include the ability to identify the uniqueness of the token. This uniqueness determines how the Subject gets cached and the purpose of the token. The token framework defines four marker token interfaces that enable the WAS run time to determine how to propagate the token.

Any custom tokens that are used in this framework are not used by WAS for authorization or authentication. The framework serves as a way to notify WAS that you want these tokens propagated in a particular way. WAS handles the propagation details, but does not handle serialization or deserialization of custom tokens. The serialization of custom tokens is handled by the token framework calling the getBytes() method on all forwardable tokens in the invocation Subject. The implementation of the getBytes() method determines whether the byte array is encoded or encrypted. The deserialization of custom tokens is handled by a custom login module plugged into inbound system login configurations. The token byte array is found by iterating through the information provided in the WSTokenHolderCallback passed into the inbound login configuration.

When a request is being authenticated, a determination is made by the login modules whether this is an initial login or a propagation login. An initial login is the process of authenticating the user information, typically a user ID and password, and then calling the application programming interfaces (APIs) for the remote user registry to look up secure attributes that represent the user access rights. A propagation login is the process of validating the user information, typically an Lightweight Third Party Authentication (LTPA) token, and then deserializing a series of tokens that constitute both custom objects and token framework objects known to the WAS.

The following marker tokens are introduced in the framework:

Authorization token

The authorization token contains most of the authorization-related security attributes that are propagated. The default authorization token is used by the WAS authorization engine to make J2EE authorization decisions. Service providers can use custom authorization token implementations to isolate their data in a different token; perform custom serialization and de-serialization; and make custom authorization decisions using the information in their token at the appropriate time. For information on how to use and implement this token type, see Default AuthorizationToken and Implementing a custom AuthorizationToken.

Single signon (SSO) token

A custom SingleSignonToken token that is added to the Subject is automatically added to the response as an HTTP cookie and contains the attributes sent back to Web browsers. The token interface getName() method together with the getVmethod defines the cookie name. WAS defines a default SingleSignonToken with the LtpaToken name and version 2. The cookie name added is LtpaToken2. Do not add sensitive information, confidential information, or unencrypted data to the response cookie.
Any time that you use cookies, use the Secure Sockets Layer (SSL) protocol to protect the request. Using an SSO token, Web users can authenticate once when accessing Web resources across multiple WAS. A custom SSO token extends this functionality by adding custom processing to the single signon scenario. For more information on SSO tokens, see Configuring single signon. For information on how to use and implement this token type, see Default SingleSignonToken and Implementing a custom SingleSignonToken.

Propagation token

The propagation token is not associated with the authenticated user so it is not stored in the Subject. Instead, the propagation token is stored on the thread and follows the invocation wherever it goes. When a request is sent outbound to another server, the propagation tokens on that thread are sent with the request and the tokens are executed by the target server. The attributes stored on the thread are propagated regardless of the J2EE RunAs user switches.
The default propagation token monitors and logs all user switches and host switches. You can add additional information to the default propagation token using the WSSecurityHelper application programming interfaces (APIs). To retrieve and set custom implementations of a propagation token, you can use the WSSecurityPropagationHelper class.
For information on how to use and implement this token type, see Default PropagationToken and Implementing a custom PropagationToken.

Authentication token

The authentication token flows to downstream servers and contains the identity of the user. This token type serves the same function as the LTPA token in previous versions. Although this token type is typically reserved for internal WAS purposes, you can add this token to the Subject and the token is propagated using the getBytes method of the token interface.
A custom authentication token is used solely for the purpose of the service provider that adds it to the Subject. WAS do not use it for authentication purposes, because a default authentication token exists that is used for WAS authentication. This token type is available for the service provider to identify the purpose of the custom data to use the token to perform custom authentication decisions.
For information on how to use and implement this token type, see Default AuthenticationToken and Implementing a custom AuthenticationToken.

Horizontal propagation versus downstream propagation

In WAS, both horizontal propagation, which is uses single signon for Web requests, and downstream propagation, which uses Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) to access enterprise beans, are available.

Horizontal propagation

In horizontal propagation, security attributes are propagated amongst front-end servers. The serialized security attributes, which are the Subject contents and the propagation tokens, can contain both static and dynamic attributes. The single signon (SSO) token stores additional system-specific information that is needed for horizontal propagation. The information contained in the SSO token tells the receiving server where the originating server is located and how to communicate with that server. Additionally, the SSO token also contains the key to look up the serialized attributes. In order to enable horizontal propagation, configure the single signon token and the Web inbound security attribute propagation features. You can configure both of these features using the administrative console by clicking...
Security > Authentication Mechanisms > LTPA | Additional Properties | Single signon (SSO)

When front-end servers are configured and in the same distributed replication service (DRS) replication domain, the appserver automatically propagates the serialized information to all of the servers within the same domain. In figure 1, application 1 is deployed on server 1 and server 2, and both servers are members of the same DRS replication domain. If a request originates from application 1 on server 1 and then gets redirected to application 1 on server 2, the original login attributes are found on server 2 without additional remote requests. However, if the request originates from application 1 on either server 1 or server 2, but the request is redirected to application 2 on either server 1 or server 2, the serialized information is not found in the DRS cache because the servers are not configured in the same replication domain. As a result, a remote Java Management Extensions (JMX) request is sent back to the originating server that hosts application 1 to obtain the serialized information so that original login information is available to the application. By getting the serialized information using a single JMX remote call back to the originating server, the following benefits are realized:

You gain the function of retrieving login information from the original server.

You do not need to perform any remote user registry calls because the appserver can regenerate the Subject from the serialized information. Without this ability, the application server might make 5 to 6 separate remote calls.

Figure 1

Performance implications for horizontal propagation

The performance implications of either the DRS or JMX remote call depends upon your environment. The DRS or JMX remote call is used for obtaining the original login attributes. Horizontal propagation reduces many of the remote user registry calls in cases where these calls cause the most performance problems for an application. However, the de-serialization of these objects also might cause performance degradation, but this degradation might be less than the remote user registry calls. It is recommended that you test your environment with horizontal propagation enabled and disabled. In cases where use horizontal propagation for preserving original login attributes, test whether DRS or JMX provides better performance in your environment. Typically, it is recommended that you configure DRS both for failover and performance reasons. However, because DRS propagates the information to all of the servers in the same replication domain (whether the servers are accessed or not), there may be a performance degradation if too many servers are in the same replication domain. In this case, either reduce the number of servers in the replication domain or do not configure the servers in a DRS replication domain. The later suggestion causes a JMX remote call to retrieve the attributes, when needed, which might be quicker overall.

Downstream propagation

In downstream propagation, a Subject is generated at the Web front-end server, either by a propagation login or a user registry login. WAS propagates the security information downstream for enterprise bean invocations when both Remote Method Invocation (RMI) outbound and inbound propagation are enabled.

Benefits of propagating security attributes

The security attribute propagation feature of WAS has the following benefits:

Enables WAS to use the security attribute information for authentication and authorization purposes. The propagation of security attributes can eliminate the need for user registry calls at each remote hop along an invocation. Previous versions of WAS propagated only the user name of the authenticated user, but ignored other security attribute information that needed to be regenerated downstream using remote user registry calls. To accentuate the benefits of this new functionality, consider the following example:
In previous releases, you might use a reverse proxy server, such as WebSEAL, to authenticate the user, gather group information, and gather other security attributes. Prior to WAS V5.1.1, the appserver used to accept only the identity of the authenticated user, but disregarded the additional security attribute information. To create a Java Authentication and Authorization Service (JAAS) Subject containing the needed WSCredential and WSPrincipal objects, WAS made 5 to 6 calls to the user registry. The WSCredential object contains various security information required to authorize a J2EE resource. The WSPrincipal object contains the realm name and the user that represents the principal for the Subject.

In the current release of the Application Server, information that is obtained from the RPS can be used by WAS and propagated downstream to other server resources without additional calls to the user registry. The retaining of the security attribute information enables you to protect server resources properly by making appropriate authorization and trust-based decisions. User switches that occur because of J2EE RunAs configurations do not cause the appserver to lose the original caller information. This information is stored in the propagation token that is located on the running thread.

Enables third-party providers to plug in custom tokens. The token interface contains a getBytes() method that enables the token implementation to define custom serialization, encryption methods, or both.

Provides the ability to have multiple tokens of the same type within a Subject created by different providers. WAS can handle multiple tokens for the same purpose. For example, you might have multiple authorization tokens in the Subject and each token might have distinct authorization attributes that are generated by different providers.

Provides the ability to have a unique ID for each token type that is used to formulate a more unique subject identifier than just the user name in cases where dynamic attributes might change the context of a user login. The token type has a getUniqueId method that is used for returning a unique string for caching purposes. For example, you might need to propagate a location ID, which indicates the location from which the user logs into the system. This location ID can be generated during the original login using either an RPS or the WEB_INBOUND login configuration and added to the Subject prior to serialization. Other attributes might be added to the Subject as well and use a unique ID. All of the unique IDs must be considered for the uniqueness of the entire Subject. WAS has the ability to specify what is unique about the information in the Subject, which might affect how the user accesses the Subject later.

Managing security
Enabling security attribute propagation
Implementing a custom PropagationToken
Implementing a custom AuthorizationToken
Implementing a custom SingleSignonToken
Implementing a custom AuthenticationToken
Configuring single signon

Default PropagationToken
Default AuthorizationToken
Default SingleSignonToken
Default AuthenticationToken