Interceptors will perform operations on behalf of the user/context making calls against the proxy. Interceptors will often need to access or alter the DIT. Interceptors have several options for DIT access/alteration.
The danger here is an infinite recursion. Let's suppose the first intercepted operation, Invocation *A*, performs operations *A'* (that's A prime) and *B* against the nexus. Invocation *A'* by the way is the same operation as the intercepted operation but with different parameters. The same operation does not mean the same Invocation. In this case *A'* may incur another set of Invocation *A"* and *B'* all invoked within the same Interceptor. This chain reaction could continue unabated to blow out the stack without regulation.
A good example of an Interceptor prone to an infinite recursion is the AuthorizationService. It needs to lookup and search for other other entries to determine access rights to perform operations. Those lookup and search operations in turn trigger the AuthorizationService again to issue another set of lookup and search operations and so on. An infinate recursion is the result.
If the AuthorizationService could call lookup and search on the nexus proxy while bypassing itself then the recursion can be avoided. This raises the question of whether or not sub-operations excecuted by Interceptors are really considered to be performed by the user of the intercepted call.
Calls against the nexus proxy are not presently possible. They can however be enabled. The foreseeable mechanism would be to just call the proxy object of the current intercepted operation. This could be done by peeking at the InvocationStack to get a handle on the Invocation object for the current operation. From there the calling Context can be accessed. An accessor in the Context implementation can expose access to the nexus proxy object.
Calling this nexus proxy will push a new Invocation object on top of the current operation's Invocation object. This is good even though the Context is used to issue yet another Invocation. The key advantage though is that we can diffentiate between the two Invocations even if the caller Context, operation and the parameters are the same.
Because the same Context object is used, the identity performing the operation is the same. This may be good and bad.
It's good because we are associating the sub-operations with the user performing the primary operation. Although if we peek onto the stack the bottom most Invocation tells us who the original Invocation was issued by. Even if sub-operations are performed as another user like the super-user we can tell who the original user was that this sub-operation was issued on behalf of.
There will be situations when we want a setUid like mechanism to access protected information on behalf of the current user. Even if the current user does not have access to protected resources, the Interceptor should be able to access these resources to satisfy the current intercepted operation. Meaning the Interceptor will need to perform operations as if it were the admin user to satisfy an operation on behalf of the current user. Doing this is no simple matter: authentication must be bypassed to enable an operation as the admin user. Otherwise we would need access to the admin's credentials. Plus re-authentication as the admin is unnecesary since the Interceptor is trusted with admin rights. If we trust the Interceptor and give it the ability to access the DIT as the admin, we must be sure this is done without compromising security.
Another alternative to access protected resources would be to disable access controls for select sub-operations performed by an Interceptor. Perhaps even if an operation's associated identity is unchanged, another parameter can be used to provide access as another user. This would be a special cue to the Authorization subsystem.
These limitations just show us that we're missing something in the design of the Interceptor Mechanism. Whether we need to handle sub-operations with special authorization measures, selectively bypass or require specific Interceptors something is required.