Factoring out the security logic

[starksm64]

In accord with the 'TODO: Interceptors' post, security needs to be factored out to deal with run-as access. I created a bug report in jira about the JCA layer not honoring the run-as identity from the web or ejb tiers:

http://jira.jboss.com/jira/browse/JBAS-1309

As mentioned there this could be hacked with another custom login module, but even the existing CallerIdentityLoginModule is stretching the JAAS api too far. Caller identity propagation including run-as can be handled much cleaner via an interceptor.

The question is, is there a minimal refactoring we can do in the BaseConnectionManager2 to support this in 4.0.x?

[adrian.brock]

There is currently quite a convoluted dance here, but essentially
want gets bound into jndi is a ConnectionFactory (like a DataSource)
that holds a reference to our ConnectionManagerProxy (necessary because
we need to have it serializable, i.e. it can disconnect/reconnect from the jmx object).

dataSource -> ConnectionManager.allocateConnection(ManagedConnectionFactory, ConnectRequestInfo);

Once we are inside that proxy we can do what we like. At the moment we
just delegate to the real ConnectionMananger implementation, a BaseConnectionManager2
implementation.

The first thing this does (after some sanity checks) is get the subject then invokes
getManagedConnection(Subject, ConnectionRequestInfo)
which just delegates to the pool after some ConnectionManager specifc processing.

Finally, after it gets the managed connection it asks it for a connection handle
and does the necessary book keeping to keep track of references and handle
errors.

[adrian.brock]

My suggestion is to have the ConnectionManagerProxy
invoke down an interceptor chain the result of which will be a connection handle
that can be returned from allocateConnection.

The interceptors would be something like:

CMProxy (as now)
Security
CachedConnectionManager (CCM) processing (on the return stroke)
Handle reference tracking (on the return stroke)
NoTx/Tx behaviour (for track-connection-by-tx and tx enlistment/synchronization)
SubPool selection
Pooling
ManagedConnectionFactory delegation to create or match an MC (ManagedConnection)

That is a rough mapping of what happens now.

There should also be an interceptor stack for the MC which would replace the
ConnectionListener (handling events like close/error/etc.)
and would be a better place to implement the CCM/handle reference
processing I show above.
I haven't analysed this part in much detail.

[adrian.brock]

So to answer your question.

The easiest way to do it now (without reimplemting the rest of the stack)
would be to make the CMProxy invoke getManagedConnection(subject, cri)
rather than allocateConnection, with an interceptor stack in front of that method.

Besides the security interceptor there would need to be a ConnectionManager
interceptor that does the rest of what is done in allocateConnection at the moment.