Default Propagation Token
The default propagation token does the following:
It monitors and logs all user switches and host switches. The token data should be available from within the container of any resource where the PropagationToken lands. Remember that enable the propagation feature at each server where a request is sent in order for propagation to work.
There is a WSSecurityHelper class that has application programming interfaces (APIs) for accessing the PropagationToken attributes and for adding custom attributes to the propagation token in your application code.
After you add attributes to the PropagationToken, we cannot change these attributes. This enables the WebSphere Application Server security runtime to add auditable information and have that information remain there for the life of the invocation. Any time that you add an attribute to a specific key, an ArrayList is stored to hold that attribute. The order of the attributes added is preserved. The first element in the String Array returned is the first attribute added for that specific key.
In the default PropagationToken, any data changes to the token is recorded using a change flag. These changes are tracked to enable WebSphere Application Server to know when to re-send the authentication information downstream so that the downstream server has those changes. A Common Secure Interoperability version 2 (CSIV2) session is maintained between servers for an authenticated client. Whenever the PropagationToken changes, a new CSIV2 session is generated and a new authentication occurs. Therefore is there are frequent changes to the PropagationToken during a method, it will cause frequent downstream calls which may impact performance.
Whenever the PropagationToken is propagated either horizontally or downstream, the name of the receiving application server is logged into the PropagationToken. The format for each server in the list is "Cell:Node:Server", which provides you access to the cell name, node name, and server name of each application server that receives the invocation.
We can also get the caller list from the PropagationToken. Anytime a authenticated Subject is generated, it is logged in the token. Basically, whenever an authenticated user is set on the thread, the user is logged in the default PropagationToken. At times, the same user might be logged in multiple times if the RunAs user is different from the caller.