Enable security attribute propagation

 

+

Search Tips   |   Advanced Search

 

Overview

The security attribute propagation feature of WAS enables you to send security attribute information regarding the original login to other servers using a token. To fully enable security attribute propagation, configure the single signon (SSO), CSIv2 inbound, and CSIv2 outbound panels in the WAS Administrative Console.

We can enable just the portions of security attribute propagation relevant to your configuration. For example, one can enable Web propagation, which is propagation amongst front-end application servers, using either the push technique (DynaCache) or the pull technique (remote method to originating server). You also can choose whether to enable RMI outbound and inbound propagation, which is commonly called downstream propagation. Typically both types of propagation are enabled for any given cell. In some cases, you might want to choose a different option for a specific application server using the server security panel within the specific application server settings.

To access the server security panel in the administrative console, click...

Servers | Application Servers | servername | Server security | Server-level security

Complete the following steps to configure WAS for security attribute propagation:

 

Procedure

  1. From the console....

    Security | Global security | Authentication mechanisms | LTPA | Single Signon (SSO)

  2. Optional. Select the Interoperability Mode option to interoperate with servers that do not support security attribute propagation. Servers that do not support security attribute propagation receive the LTPA token and the PropagationToken, but ignore the security attribute information that it does not understand.

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

    Typically, you enable the Web inbound security attribute propagation option to gather dynamic security attributes set at the original login server that cannot be regenerated at the new front-end server. This attributes include any custom attributes that might be set in the PropagationToken using...

    com.ibm.websphere.security.WSSecurityHelper

    You must determine whether enabling this option improves or degrades the performance of your 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 your topology. Measure the performance of your environment with, and without, the option. Test in the operating environment of the typical production environment with the typical number of unique users accessing the system simultaneously.

  4. Click...

    Security | Global security | Authentication protocol | CSIv2 inbound authentication

  5. Select the Security attribute propagation option allows the server to advertise that it can receive propagated security attributes from servers in the same realm.

  6. 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 | JAAS Configuration | 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 the name of the login configuration that you want to modify.

    3. Under Additional Properties, click JAAS Login Modules. The JAAS Login Modules panel is displayed, which lists all of the login modules processed in the login configuration. Do not delete the required JAAS login modules. Instead, one can add custom login modules before or after the required login modules. If you add custom login modules, do not begin their names with com.ibm.ws.security.server because this prefix is reserved for WAS internal use.

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

  7. Click...

    Security | Authentication protocol | CSIv2 Outbound authentication

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

  8. Select Security Attribute Propagation to enable outbound Subject and security context token propagation for the RMI protocol.

    This will serialize the Subject contents and the PropagationToken contents. After the contents are serialized, the server uses the CSIv2 protocol to send the Subject and PropagationToken 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.

    Note that 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. Select the Custom Outbound Mapping option if you deselect the Security Attribute Propagation option and you want to use the RMI_OUTBOUND login configuration.

    If 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. Specify trusted target realm names in the Trusted Target Realms field. Optional

    By specifying these realm names, information can be sent to servers that reside outside the realm of the sending server to allow for inbound mapping to occur at these downstream servers. To perform outbound mapping to a realm different from the current realm, specify the realm in this field so that one can get to this point without the request being rejected due to 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. To enable propagation for a pure client add the following property to the sas.client.props file:

    com.ibm.CSI.rmiOutboundPropagationEnabled=true

 

Result

After completing these steps, you have configured WAS to propagate security attributes to other servers. After you have configured WAS for security attribute propagation and need to disable this functionality, one can disable propagation for either the server level or the cell level. To disable security attribute propagation on the server level, click...

Server | Application Servers | servername | Server security

We can disable security attribute propagation for inbound requests by clicking CSI inbound authentication under Additional Properties and deselecting Security attribute propagation. We can disable security attribute propagation for outbound requests by clicking CSI outbound authentication under Additional Properties and deselecting Security attribute propagation. To disable security attribute propagation on the cell level, undo each of the steps that you completed to enable security attribute propagation in this task.

 

See Also


Security attribute propagation