Security attribute propagation


 

+

Search Tips   |   Advanced Search

 

WAS can transport...

...from one server to another.

WAS might obtain these security attributes from either...

Dynamic security attributes might include...

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 runtime 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. Serialization and deserialization of these custom tokens are carried out by the implementation and handled by a custom login module.

With WAS V6.0 and later, a custom JACC provider can be configured to enforce access control for Java EE applications. A custom JACC provider can explore the custom security attributes in the caller JAAS subject in making access control decisions.

When a request is being authenticated, a determination is made by the login modules whether this request is an...

An initial login is the process of authenticating the user information, typically a user ID and password, and then calling the 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 a LTPA token, and then deserializing a series of tokens that constitute both custom objects and token framework objects known to WAS.

The following marker tokens are introduced in the framework:

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 Java EE authorization decisions. Service providers can use custom propagation 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.

See...

Single sign-on (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 with the getVersion method defines the cookie name. WAS defines a default SingleSignonToken token with the LtpaToken name and V 2. The cookie name added is LtpaToken2. Do not add sensitive information, confidential information, or unencrypted data to the response cookie.

It is also recommended that any time that you use cookies, use the SSL protocol to protect the request. Using an SSO token, Web users can authenticate once when accessing Web resources across multiple WASs. A custom SSO token extends this functionality by adding custom processing to the single sign-on scenario.

See:

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 run by the target server. The attributes that are stored on the thread are propagated regardless of the Java EE RunAs user switches.

The default propagation token monitors and logs all user switches and host switches. We can add additional information to the default propagation token using the WSSecurityHelper APIs. To retrieve and set custom implementations of a propagation token, we can use the WSSecurityPropagationHelper class.

See...

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, we 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 does not use it for authentication purposes because a default authentication token exists used for WAS authentication. This token type is available for the service provider to identify how the custom data uses the token to perform custom authentication decisions.

See...

Kerberos authentication token

The Kerberos authentication token contains Kerberos credentials such as the Kerberos principal name, GSSCredential and Kerberos delegation credential.

This token is propagated to the downstream server. Although this token type is typically reserved for internal WAS purposes, if it contains the GSSCredential we can use the getGSSCredential method to extract the GSSCredential.

We can then place it in the subject and it can be used for the application.

This token is created when you authenticate to WAS with either SPNEGO Web or Kerberos authentication.

 

Horizontal propagation versus downstream propagation

In WAS, both horizontal propagation, which uses single sign-on for Web requests, and downstream propagation, which uses RMI/IIOP to access enterprise beans, are available.

 

Horizontal propagation

In horizontal propagation, security attributes are propagated among front-end servers. The serialized security attributes, which are the Subject contents and the propagation tokens, can contain both static and dynamic attributes. The 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.

To enable horizontal propagation, configure the single sign-on token and the Web inbound security attribute propagation features.

Configure both of these features using the admin console.

When front-end servers are configured and in the same data replication service 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 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

 

Performance implications for horizontal propagation

The performance implications of either the DRS or JMX remote call depends upon the 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. IBM recommends that you test the 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 the 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 might 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 RMI outbound and inbound propagation are enabled.

 

Benefits of propagating security attributes

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






Subtopics


Default authentication token

 

Related tasks


Propagating security attributes among appservers
Select an authentication mechanism
Use the default propagation token
Use the default authorization token
Use the default single sign-on token with default or custom token factory
Implement a custom propagation token for security attribute propagation
Implement a custom authorization token for security attribute propagation
Implement a custom single sign-on token for security attribute propagation
Implement a custom authentication token for security attribute propagation
Implementing single sign-on to minimize Web user authentications
Authenticate users