Propagate security attributes among appservers
Use the security attribute propagation feature to send security attribute information regarding the original login to other servers using a token.
To fully enable security attribute propagation, in the console, configure the panels for...
We can enable just the portions of security attribute propagation. For example, we can enable Web propagation, which is propagation amongst front-end appservers, using either...
- push technique (DynaCache)
- pull technique (remote method to originating server)
We also can choose whether to enable RMI outbound and inbound propagation (downstream propagation). Typically both types of propagation are enabled for any given cell. In some cases, we might want to choose a different option for a specific appserver using that appserver's server security panel.
To prevent propagating the same security attributes among appservers multiple times, WAS verifies that a LTPA token does not exist.
- Absence of the LTPA token tells the appserver that propagation can proceed.
- Presence of the LTPA token indicates that propagation has occurred if the LTPA token has been generated within the cluster.
If the LTPA token is present, but has been generated by a server outside the cluster, such as by TAM, Lotus Domino or a different WAS cluster, security attributes are not propagated.
To access the server security panel in the admin console, click...
- Servers | Application Servers | myserver | Security | Server security
Configure WAS for security attribute propagation
- Access the WAS admin console...
-
http://myserver:port_number/ibm/console
...and go to...
- Security | Global security | Web security | Single sign-on (SSO)
- 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 Propagation token, but ignore the security attribute information that they do not understand.
- 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 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. These attributes include any custom attributes that might be set in the PropagationToken token using the com.ibm.websphere.security.WSSecurityHelper APIs. You must determine whether enabling this option improves or degrades the performance of the 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 the user registry is the bottleneck of the topology. IBM recommends that you measure the performance of the environment both using and not using this option. When you test the performance, it is recommended that you test in the operating environment of the typical production environment with the typical number of unique users accessing the system simultaneously.
- Click...
- Security | Global security
- Click...
- Security | Global security
SWAM is deprecated in WAS V7.0 and will be removed in a future release.
- Click the name of the login configuration to modify.
- Under Additional Properties, click 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.
- Click...
- Select the Security attribute propagation option on the CSIv2 inbound authentication panel. When you select Security Attribute Propagation, the server advertises to other appservers that it can receive propagated security attributes from another server in the same realm over the Common Secure Interoperability version 2 (CSIv2) protocol.
- Click...
- Security | Global security
- Verify that the Security Attribute Propagation option is selected to enable outbound Subject and security context token propagation for the RMI protocol. When you select this option, 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.
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.
- Select the Custom Outbound Mapping option if we clear the Security Attribute Propagation option and you 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. to plug in a credential mapping login module, select the Custom Outbound Mapping option.
- Specify trusted target realm names in the Trusted Target Realms field. By specifying these realm names, information can be sent to servers residing 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 so that we can 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.
- Enable propagation for a pure client.
For a pure client to propagate attributes added to the invocation Subject, add the following property to sas.client.props:
com.ibm.CSI.rmiOutboundPropagationEnabled=true
The sas.client.props file is located at <WAS-HOME>/profiles/<ProfileName>/properties>.
Disable security attribute propagation
You can disable propagation on either the server level or the cell level. Changes to the server-level settings override the cell settings.To disable on the server level...
- Click...
Server | Application Servers | myserver | Security | WAS security
- Select the RMI/IIOP security for this server overrides cell settings option.
- Disable security attribute propagation for inbound requests by clicking CSI inbound authentication under Additional Properties and clearing the Security attribute propagation option.
- Disable security attribute propagation for outbound requests by clicking CSI outbound authentication under Additional Properties and clearing the Security attribute propagation option.
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.
Use the default authorization token
Use the default propagation token
Use the default single sign-on token with default or custom token factory
Related concepts
Security attribute propagation
Related tasks
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
Propagating a custom Java serializable object for security attribute propagation
Authenticate users
Related
Default authentication token