Propagate security attributes among application servers

Use the security attribute propagation feature of WebSphere Application Server to send security attribute information regarding the original login to other servers using a token.

We can enable just the portions of security attribute propagation relevant to the configuration. For example, we can enable web propagation (propagation amongst front-end application servers), using either the push technique (DynaCache) or the pull technique (remote method to originating server). We also enable RMI outbound and inbound propagation (downstream propagation). Typically both types of propagation are enabled for any given cell.

To use a different option for a specific application server use the server security panel.

Servers > Application Servers > server > Security > Server security

To fully enable security attribute propagation, configure SSO and CSIv2.

To prevent propagating the same security attributes multiple times, WAS verifies that an LTPA token does not exist. Two cases can occur.

• Absence of the LTPA token tells the Application Server that propagation can proceed. Presence of the LTPA token indicates that propagation has occurred if the LTPA token has been generated within the cluster.

• The LTPA token is present, but has been generated by a server outside the cluster, such as by Security Access Manager, Lotus Domino, or a different Application Server cluster, security attributes are not propagated.

Configure WAS for security attribute propagation

1. Access the WAS administrative console...
   http://server:port_number/ibm/console

2. Click...
   Security > Global security > Web security > Single sign-on (SSO)

3. Optional: Select the "Interoperability Mode" option if we must interoperate with servers that do not support security attribute propagation. Servers that do not support security attribute propagation receive the LPTA token and the Propagation token, but ignore the security attribute information that they do not understand.

4. Select the "Web inbound security attribute propagation" option. The Web inbound security attribute propagation option enables horizontal propagation, which allows the receiving SSO token to retrieve the login information from the original login server. If we do not enable this option, downstream propagation can occur if we enable the Security Attribute Propagation option on both the CSIv2 inbound and outbound panels.

   Typically, we enable the web inbound security attribute propagation option if we need to gather dynamic security attributes set at the original login server that cannot be regenerated at the new front-end server. These attributes include any custom attributes that might be set in the PropagationToken token using the com.ibm.websphere.security.WSSecurityHelper APIs. We must determine whether enabling this option improves or degrades the performance of our system. While the option prevents some remote user registry calls, the deserialization and decryption of some tokens might impact performance. In some cases propagation is faster, especially if your user registry is the bottleneck of our topology. IBM recommends that you measure the performance of the environment both using and not using this option. When we test the performance, IBM recommends that you test in the operating environment of the typical production environment with the typical number of unique users accessing the system simultaneously.

   When the "Web inbound security attribute propagation" option is enabled, security attributes are propagated to front-end application servers. When this option is disabled, the SSO token is used to log in and recreate the Subject from the user registry.

5. Click...
   Security > Global security > RMI/IIOP security > CSIv2 inbound authentication

   The Login configuration field specifies RMI_INBOUND as the system login configuration used for inbound requests. To add custom JAAS login modules:

   1. Click...
      Security > Global security > Java Authentication and Authorization Service > System logins

      A list of the system login configurations is displayed. WAS provides the following pre-configured system login configurations:

      • DEFAULT
      • LTPA
      • LTPA_WEB
      • RMI_INBOUND
      • RMI_OUTBOUND
      • SWAM
      • WEB_INBOUND
      • wssecurity.IDAssertion
      • wssecurity.Signature

      Do not delete these predefined configurations.

   2. Click...
      login configuration > Additional Properties > JAAS Login Modules

      The JAAS Login Modules panel is displayed, which lists all of the login modules that are processed in the login configuration. Do not delete the required JAAS login modules. Instead, we can add custom login modules before or after the required login modules. If we add custom login modules, do not begin their names with com.ibm.ws.security.server.

      We can specify the order in which the login modules are processed by clicking "Set Order".

6. Select the "Security attribute propagation" option on the CSIv2 inbound authentication panel. The server can now advertise to other application servers that it can receive propagated security attributes from another server in the same realm over the CSIv2 protocol.

7. Click...
   Security > Global security > RMI/IIOP security > CSIv2 Outbound authentication

   The CSIv2 outbound authentication panel is displayed. The "Login configuration" field specifies RMI_OUTBOUND as the JAAS login configuration used for outbound configuration. We cannot change this login configuration. Instead, we can customize this login configuration by completing the substeps listed previously for CSIv2 Inbound authentication.

8. Optional: Verify that the "Security Attribute Propagation" option is selected to enable outbound Subject and security context token propagation for the Remote Method Invocation (RMI) protocol.

   When selected, WAS serializes the Subject contents and the PropagationToken contents. After the contents are serialized, the server uses the CSIv2 protocol to send the Subject and PropagationToken token to the target servers that support security attribute propagation. If the receiving server does not support security attribute tokens, WAS sends the LTPA token only.

   Important: WAS propagates only the objects within the Subject that it can serialize. The server propagates custom objects on a best-effort basis.

   When "Security Attribute Propagation" is enabled, WAS adds marker tokens to the Subject to enable the target server to add additional attributes during the inbound login. During the commit phase of the login, the marker tokens and the Subject are marked as read-only and cannot be modified thereafter.

9. Optional: Select the "Custom Outbound Mapping" option if you clear the "Security Attribute Propagation" option and we want to use the RMI_OUTBOUND login configuration. If neither the "Custom Outbound Mapping" option nor the "Security Attribute Propagation" option is selected, WAS does not call the RMI_OUTBOUND login configuration. If we need to plug in a credential mapping login module, select the "Custom Outbound Mapping" option.

10. Optional: Specify trusted target realm names in the "Trusted Target Realms" field.

    By specifying these realm names, information can be sent to servers that reside outside the realm of the sending server to support inbound mapping that is at these downstream servers. To perform outbound mapping to a realm different from the current realm, specify the realm in this field to get to this point without having the request rejected because of a realm mismatch. If we need WAS to propagate security attributes to another realm when a request is sent, specify the realm name in the "Trusted Target Realms" field. Otherwise, the security attributes are not propagated to the unspecified realm. We can add multiple target realms by adding a pipe ("|") delimiter between each entry.

11. Optional: Enable propagation for a pure client. For a pure client to propagate attributes added to the invocation Subject, edit...
    WAS_HOME/profiles/ProfileName/properties/sas.client.props

    ...and add the property...

    com.ibm.CSI.rmiOutboundPropagationEnabled=true

After completing these steps, we have configured WAS to propagate security attributes to other servers.

To disable security attribute propagation on the server level:

1. Click...
   Server > Application Servers > server > Security > Server security > RMI/IIOP security for this server overrides cell settings

2. Disable security attribute propagation for inbound requests by clearing option...
   Additional Properties > CSI inbound authentication > Security attribute propagation

3. Disable security attribute propagation for outbound requests by clearing option...
   Additional Properties > CSI outbound authentication > Security attribute propagation

To disable security attribute propagation on the cell level, undo each of the steps completed to enable security attribute propagation in this task.

Subtopics

Related

Use the default authorization token

Security attribute propagation

Authenticating users

Default propagation token

Default authorization token

Default single sign-on token with default or custom token factory

Implement a custom propagation token

Implement a custom authorization token

Implement a custom single sign-on token

Implement a custom authentication token

Propagating a custom Java serializable object

Default authentication token