3 Replies Latest reply on Jan 20, 2005 4:25 PM by Adrian Brock

    Factoring out the security logic

    Scott Stark Master

      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:


      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?

        • 1. Re: Factoring out the security logic
          Adrian Brock Master

          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

          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

          • 2. Re: Factoring out the security logic
            Adrian Brock Master

            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)
            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
            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.

            • 3. Re: Factoring out the security logic
              Adrian Brock Master

              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.