13.6. STS Client Pooling

The PicketLink provides a pool of STS clients on the server. This removes STS Client creation as a bottleneck.
Client pooling can be utilized from login modules that need an STS client to obtain SAML tickets.
Login Modules that can utilize STS client pooling:
  • org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
  • org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
  • org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule
The default number of clients in the pool for each login module is configured via the initialNumberOfClients login module option.
The STSClientPoolFactory class org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory provides client pool functionality to applications.

Using STSClientPoolFactory

STS clients are inserted into sub pools using their configuration as a key. Obtain STSClientPool instance and then initialize a sub pool based on configuration, optionally with initial number of STS clients or rely on default number. 
final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);
When you are done with a client, you can return it to the pool like so: 
pool.returnClient();
To check if a subpool already exists for a given configuration: 
if (! pool.configExists(stsClientConfig) {  
    pool.createPool(stsClientConfig);  
}
When the PicketLink Federation subsystem is enabled, all client pools created for a deployment are destroyed automatically during the undeploy process. To manually destroy a pool: 
pool.destroyPool(stsClientConfig);
Report a bug