Security Context Propagation

[anil.saldhana]

Discussion related to https://docs.jboss.org/author/display/SECURITY/Java+Application+Security

When there is a need to propagate security context, the following usecases come into my mind:

a) Thread level security context propagation.

b) Session level security context propagation.

   - Internal session maintained by PicketBox.

   - External session injected.

The API can look like the following:

SecurityContext context = //

SecurityContextPropagation.setContext(context, Level.THREAD);

SecurityContextPropagation.setContext(context, Level.SESSION);

SecurityContextPropagation.setContext(context, session, Level.SESSION);

context = SecurityContextPropagation.getContext();  //Thread level or internal session

context = SecurityContextPropagation.getContext(session);

Note: Session is an instance of PicketBoxSession.

References

https://docs.jboss.org/author/display/SECURITY/Session+Management

[pcraveiro]

PicketBox already works with sessions to use different stores: local-inmemory or in-memory distributable cache. Your proposal can work with what we already have.

The PicketBoxSubject and PicketBoxSession work very similar to the SecurityContext. But I agree that is better to have a specific class for that.

Maybe we can have something like: PicketBoxSubject.propagate(). Where this method is responsible to create a SC instance by using some factory or something (let developers code their own SC) and to know how to propagate it.

Basically, your logic would be inside the PicketBoxSubject.propagate() method.

[anil.saldhana]

We need to provide the construct for SecurityContext.  We have one in PBox4.

IMO it is better to have a static class called SecurityContextPropagation to convey the meaning.

[pcraveiro]

For me is fine to have a static class for that. The result is the same. I just tried to hide this aspect from developers.

I think we can start coding something regarding threadlocals. If I understand correctly, the SC needs to be setted for each client request/interaction, right ?

[anil.saldhana]

I think we can start coding something regarding threadlocals. If I understand correctly, the SC needs to be setted for each client request/interaction, right ?

It is upto the integrating applications to set the context for propagation.  The contract is thread,session/internal,session/external.

[pcraveiro]

Yeah, asked that because we need to change PB HTTP security filter to do that.

I think we should also consider the following scenarios:

• Propagation between layers in the same VM (In-VM propagation)
• Propagation between layers in different VMs

The first scenario is easy to get solved with threadlocals. The second one can be done if clustering the session, but is that a good way to propagate the SC ? I mean, by forcing a clustered cache config in order to get the SC propagated ?

[bill.burke]

explain session, internal and external?

Can you link SecurityContext?  I want something similar to:

https://github.com/resteasy/Resteasy/blob/master/jaxrs/jaxrs-api/src/main/java/javax/ws/rs/core/SecurityContext.java

That a plugin could implement this interface and then call SecurityContext.setContext(myContext, THREAD);

[dlofthouse]

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.

[anil.saldhana]

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.