8 Replies Latest reply on Aug 24, 2012 9:26 AM by Anil Saldanha

    Security Context Propagation

    Anil Saldanha Master

      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

        • 1. Re: Security Context Propagation
          Pedro Igor Master

          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.

          • 2. Re: Security Context Propagation
            Anil Saldanha Master

            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.

            • 3. Re: Security Context Propagation
              Pedro Igor Master

              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 ?

              • 4. Re: Security Context Propagation
                Anil Saldanha Master

                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.

                • 5. Re: Security Context Propagation
                  Pedro Igor Master

                  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 ?

                  • 6. Re: Security Context Propagation
                    Bill Burke Master

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

                    • 7. Re: Security Context Propagation
                      Darran Lofthouse Master

                      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.

                      • 8. Re: Security Context Propagation
                        Anil Saldanha Master

                        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.