users@javaee-security-spec.java.net

[javaee-security-spec users] Re: [jsr375-experts] Re: Drop SecurityContext from the spec?

From: reza_rahman <reza_rahman_at_lycos.com>
Date: Mon, 20 Mar 2017 11:45:50 -0400

If we have to limit scope, that's not too bad.
-------- Original message --------From: Will Hopkins <will.hopkins_at_oracle.com> Date: 3/19/17 10:17 PM (GMT-05:00) To: jsr375-experts_at_javaee-security-spec.java.net Subject: [javaee-security-spec users] [jsr375-experts] Re: Drop SecurityContext from the spec?

    Let's discuss when we meet.

    

    Until then, a question: what are people's thoughts on limiting the
    implementation to Servlet and EJB containers for now. I'm wondering
    whether it makes sense to wait on defining an SPI until we've had a
    chance to specify roles and authorization in Security 1.x.

    

    On 03/19/2017 08:08 PM, arjan tijms
      wrote:

    
    
      

        

          On Sun, Mar 19, 2017 at 11:17 PM,
            arjan tijms <arjan.tijms_at_gmail.com>
            wrote:

            
              
                
                  
                    So with a small SPI interface (like e.g. the
                      CDI RI (Weld) and the JSF RI (Mojarra) also have)
                      this should be possible.

                    
                    

                    
                    I'll do a quick implementation of such an SPI
                      in Soteria as a draft proposal, so we can base
                      further discussion on that.
                  
                
              
            
            

            
            I just committed this SPI and an example implementation
              of it here: https://github.com/javaee-security-spec/soteria/commit/51f8430e2310e5ed724b4684e0bef6f890ea2c81
            

            
            

            
            Specifically this small SPI interface (to be
              implemented by integrators):
            

            
            
              package org.glassfish.soteria.authorization.spi;
              

              
              import java.security.Principal;
              

              
              public interface CallerDetailsResolver {
                  
                  Principal getCallerPrincipal();
                  boolean isCallerInRole(String role);
              

              
              }
            
            

            
            And a following example implementation:
            

            
            
              public class ReflectionAndJaccCallerDetailsResolver
                implements CallerDetailsResolver {
              

              
                  @Override
                  public Principal getCallerPrincipal() {
                      Subject subject = JACC.getSubject();
                      
                      if (subject == null) {
                          return null;
                      }
                      
                      SubjectParser roleMapper = new
                SubjectParser(getContextID(), emptyList());
                      
                      return
                roleMapper.getCallerPrincipalFromPrincipals(subject.getPrincipals());
                  }
            
            

            
               // isCallerInRole left to be done
            }
            

            
            In this example, the Subject is obtained from JACC, and
              then a helper class that has knowledge about several
              servers and how they store Principals in the Subject tries
              to find the caller principal in this subject.
            

            
            Again, this is a generic example and every
              vendor/integrator can implement this in whatever way,
              using or not using JACC.
            

            
            Kind regards,
            Arjan Tijms
            

            
             
          
        
      
    
    

    --
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803