Darran Lofthouse wrote:
The more I have experienced issues in this area the more convinced I am that PicketBox or any related security subsystem should not be responsible for managing the actual association of the current security context with the current request.
What I mean by this is that the security subsystem / PicketBox is not aware of the underlying threading model of the subsystem currently handling the request - in the past we had one thread per request so have been able to make assumptions about this but that is not the case anymore.
I am not sure what it would look like yet but I have been thinking we need something along the lines of an API that allows for items to be attached to the current request the different subsystems / containers would then provide implementations of that API and the container will then make the decision regarding how to actually perform the association.
As then raised above there needs to be a mechanism to propagate between different containers - that may be a point where a ThreadLocal may be required and leave the container receiving the request responsible for taking care of it before it switches the request to a new thread.
PicketBox cannot be the all encompassing security project as many demand. :)
As you said, Darran, there are cases where the integrating application/subsystem has to manage aspects of security itself while using the constructs in PBox.