1 2 3 Previous Next 30 Replies Latest reply on Mar 15, 2010 6:15 AM by dimonv Go to original post
      • 15. Re: SecurityContext
        starksm64

        This has to be driven by the security aspects and the usecases I outlined. The SecurityAssociation is at best an implementation detail of some aspects. We should be looking to propagate security context info via the invocation payload rather than thread locals.

        • 16. Re: SecurityContext
          starksm64

           

          "anil.saldhana@jboss.com" wrote:

          I'm not seeing how the run-as identity and roles fits into the SecurityContext. How does it?

          RunAsIdentity is not applicable to every JEMS project. It is more of an JEE aspect. Both RAI and Roles will be keyed in the context map inside SC implementation.


          Forget about the specific RunAsIdentity notion. This should be a subset of a general trust configuration where there is an assertion that the caller is X with proof of identity Y. The javaee run-as notion has X=some-role with Y=the-ability-to-deploy-a-component-with-a-run-as-tag.



          • 17. Re: SecurityContext
            anil.saldhana

             

            "scott.stark@jboss.org" wrote:
            This has to be driven by the security aspects and the usecases I outlined. The SecurityAssociation is at best an implementation detail of some aspects. We should be looking to propagate security context info via the invocation payload rather than thread locals.

            Yes, that I understood with your previous feedback. That is where the complexity arises with run-as propagation. Apart from RAI, what other trust associaters need to be sent via the payload.

            • 18. Re: SecurityContext
              anil.saldhana

               

              - How would we configure a scenario where the caller of an ejb was mapped to another identity/credentials for accessing resources like jca connections? For example, a caller derived username/password, principal/credential for a database or jms connection.


              How is this currently being handled in JBoss4?

              • 19. Re: SecurityContext
                starksm64

                Its not handled. We have no security domain mapping notions currently.

                • 20. Re: SecurityContext
                  anil.saldhana

                  I have been thinking about the run-as scenarios. It will not be difficult to define the various semantics of this - in-vm or an explicit trust association (via transport, saml assertion or custom).

                  One implementation issue I have is how will the client proxy pick up the caller security context that includes any deployment level trust settings without using some kind of a threadlocal stack (one level will be sufficient), just like the current SecurityAssociation stacks. This is really important for inter-vm calls. Some kind of an injection semantics will suffice, but I am not aware of any such setup within JBoss. Any possible ideas here?

                  • 21. Re: SecurityContext
                    starksm64

                    This has to be part of the client proxy interceptor stack. Today there is only the SecurityInterceptor that accesses the SecurityAssociation. The interceptor stack associated with a proxy needs to include whatever security aspects are needed based on the security metadata. One way would be to include several different security interceptors in the proper order so that the aggregate security context of the call is correct. Some interceptors may do nothing if there already is a security context associated with the call while others may augment it.

                    • 22. Re: SecurityContext
                      anil.saldhana

                      Now where will the client side interceptors pick up the caller Security Context from? I need something like the old SecurityAssociation threadlocal.

                      This is just a minute issue but this is where I cannot throw away the threadlocal concept. In my current prototype, I have a SecurityContextAssociation with a single threadlocal to hold the securitycontext object. The Security Interceptor in the proxy looks at the threadlocal object to obtain the call-path security context. If it exists and it holds the invocation principal(means there is no explicit jaas login), I just send the security context over the invocation. If the invocation principal does not match with the SC on the threadlocal, it means there is an explicit jaas login - create a new SC (plug the call-path sc as its parent) and set this new SC on the threadlocal as well as sending it on the invocation. Takes care of end-to-end security. On the return, there is pop action with the current security context discared with the caller sc becoming primary and so on.

                      The security context can hold the caller's security context and be passed via invocation. So we get the stack like behavior for the caller's context.

                      • 23. Re: SecurityContext
                        starksm64

                        Setting the security context has to be reconcilled with the security aspect behavior. If you do an explicit jaas login, all that really results is an authenticated subject. Instead of having a ClientLoginModule push this to a thread local, it could associate this info with the mc metadata repository at a request scope. The aspect checking the security context would use the metadata repository to pickup scope starting from the request and moving up to higher levels like deployment, security domain default, etc.

                        Alternatively we could look at Subject.doAs*()/Subject.getSubject(AccessControlContext acc) with validation of the authentication as data in the subject private credentials to better leverage the jaas apis.

                        • 24. Re: SecurityContext
                          anil.saldhana

                          The metadata repository at the request level is certainly a good alternative to the threadlocal setup.

                          • 25. Re: SecurityContext
                            anil.saldhana

                            Two questions:
                            a) On the server side, can I know if the call originated within the same vm or not unless I put something on the invocation via the InvokerInterceptor?

                            b) Is there anything equivalent to ServletRequest.isSecure() for jboss ejb invocations? I do not think so looking at the Invocation interface. What is the right way to inject transport semantics(like ssl) into the invocation? Should it be remoting? Mainly for the trusted run-as call, I am interested in seeing if the call arrived on a secure transport.

                            • 26. Re: SecurityContext
                              anil.saldhana

                              The security context work is going on. I am validating all the use cases (there are a lot of them). I think once the 5.0beta2 is released, I should be able to check things in.

                              • 27. Re: SecurityContext
                                anil.saldhana

                                Topic: Situation between <use-caller-identity> and <run-as>

                                Task: Security Context replacement of SecurityAssociation; SC over the invocation.
                                
                                I have the following situation with reference to the <security-identity> tag:
                                
                                [A] -> [B]->[C]
                                
                                EJB A defines a run-as (P/InternalRole), B defines no run-as but has <use-caller-identity>
                                
                                Both B and C are accessible only by role "InternalRole".
                                
                                The situation for me is the call to C. It does not have the "InternalRole" in the security context because it is not part of Subject nor is the callerRunAsIdentity.
                                
                                I am treating this as a special case as follows:
                                At the security checks happening for B, I do:
                                =======================
                                RunAsIdentity callerRunAsIdentity = getCallerRunAsIdentity(mi);
                                 /**
                                 * Special case: if <use-caller-identity> configured and
                                 * the caller is arriving with a run-as, we need to push that run-as
                                 */
                                 if(callerRunAsIdentity != null && this.isUseCallerIdentity)
                                 this.runAsIdentity = callerRunAsIdentity;
                                 ...
                                 pushRunAsIdentity(runAsIdentity);
                                ======================================
                                
                                


                                Effectively, this has replaced the run-as for B-C call to be the caller's RAI from A to B.

                                Reference: EJBSpecTest -> testDeepRunAs

                                • 28. Re: SecurityContext
                                  starksm64

                                  That's correct and what the test is validating. We have gone around on this in the past, but settled on the run-as identity being what should be seen as propagated. use-caller-identity really is a noop default behavior that does not change the previously established authenticated identity vs run-as which is changing it for the call.

                                  • 29. Re: SecurityContext
                                    anil.saldhana

                                    Moving on to the concept of JBossSubject an end result of authentication, we have many variations of Subjects to consider:
                                    a) JAAS Subject.
                                    b) SAML Subject
                                    c) WS-Trust Security Token (that contains claims about a trusted identity like name etc).
                                    d) XACML Subject
                                    e) Custom subject.

                                    Of these the structure of JAAS, SAML and XACML are well defined. WS-T security token is open-ended with scope for custom tokens.

                                    I am thinking that JBossSubject should be a composition of these subjects , rather than an union of constituents of these individual subjects.

                                    My Choice:

                                     public class JBossSubject
                                     {
                                     List<Object> theSubjects;
                                    
                                     public <T> void addSubject(T subject);
                                     }
                                    


                                    A particular case I have in mind is when an authenticated subject has multiple identities (a jaas subject, saml subject, a security token etc) and the authorization layer can make a decision based on some configuration, in the presence of multiple subject types for a particular identity.

                                    For the record, a ws-trust security token can be saml, x509, username/pwd or custom.