A resource adapter can re-authenticate a physical connection (that is, one that already exists in the connection pool under a different security context) to the underlying EIS. A resource adapter performs reauthentication when an application server calls the getConnection method with a security context, passed as a Subject instance, different from the context previously associated with the physical connection.
- Reauthentication support: The resource adapter provider must specify whether a resource adapter supports reauthentication of an existing physical connection.
- The matchManagedConnections method in ManagedConnectionFactory may return a matched ManagedConnection instance with the assumption that the ManagedConnection.getConnection method will later switch the security context through reauthentication.
- If reauthentication is successful, the resource adapter has changed the security context of the underlying ManagedConnection instance to that associated with the passed Subject instance.
Detailed description of the reauthentication process is described in section 9.1.9.
There are a couple of design choices
- An implementation that keeps all connections within the same managed connection pool
- An implementation that separates connections based on their credentials and does a reauthentication if needed
There are pros and cons for each design solution - basically inverted of each other
- Ease to implement
- Proven already
- Number of reauthentications occurring
In the case of 2) we will need a good LRU mechanism across all managed connection pools.
The implementation is currently based on design solution 1.
The classes are
have been updated to use the PoolStrategy.REAUTH strategy for all resource adapters which have specified that they support reauthentication.
- Lookup connection factory / connection
- Invoke connection with credential #1
- Invoke connection with credential #2
should lead to success
- Reauthentication enabled
- Expose simple connection interface
- Configuration: Initially <min-pool-size> and <max-pool-size> should be set to 1
- Maybe do two resource adapters
- #1 using Subject
- #2 using CRI
- Allow a configured number of connections (java.net.Socket)
- Binary protocol
- Support Subject based security through raw data
- Support CRI based security through raw data
- Support reauthentication on existing connection
- Be able to run in-VM
- All communication has to go over the Sockets for clean separation between RA and EIS
The EIS is located under
And test cases under
Each command is identified with a byte followed by the payload for the command.
|CONNECT||<nothing>||Boolean (True if granted access) (OBJECT)|
|ECHO||Serializable (OBJECT)||Serializable (Echo service) (OBJECT)|
|String (User name) (OBJECT)|
|UNAUTH||<nothing>||Boolean (True if successful) (OBJECT)|
|GETAUTH||<nothing>||String (User name) (OBJECT)|
Option #C and #A described in section 9.1.9 should be tested in that order.
Ideally the entire test suite setup can be included as an example in the user guide.
Some databases support reauthentication, so we need to provide a way to enable support in our JDBC resource adapter.
A new SPI interface for this functionality
We can also provide plugins for the Open Source databases that supports this, f.ex
Reauthentication is automatically enabled when a <reauth-plugin> element is defined in the datasource deployment.