SEC-2220: Extending Principals and ServletApi()

[spring-projects-issues]

Cemo Koc (Migrated from SEC-2220) said:

servletApi() of Spring Security is really very nice. But I am struggling with a Principal problem.

Shortly:

I would like inject my custom principal which is extending Principal to my controllers.

Details:

I have configured my Spring Security M2 perfectly. Here I have not configured anything else. Only UserDetails Service is implemented.

@Override
protected void registerAuthentication(AuthenticationManagerBuilder auth) throws Exception        {
  auth
     .userDetailsService(detailsService);
}

And my usage:

public interface UserPrincipal extends Principal {
   public Integer getId();

   // and other properties...
}

@RequestMapping(value = "/")
public ResponseEntity<List<Conversation>> listAfter(UserPrincipal user){
   // implementation
}  

or


@RequestMapping(value = "/")
public ResponseEntity<List<Conversation>> listAfter(UserPrincipalImpl user){
   // implementation
}

I am expecting UserPrincipal and UserPrincipalImpl to be injected here.

But this is not possible because SecurityContextHolderAwareRequestWrapper is returning an Authentication which is delegating to internal principal.

    @Override
    public Principal getUserPrincipal() {
        Authentication auth = getAuthentication();

        if ((auth == null) || (auth.getPrincipal() == null)) {
            return null;
        }

        return auth;
    }

Problems are starting here:

1. Having problem at injecting UserPrincipal to Controllers

        else if (Principal.class.isAssignableFrom(paramType)) {
            return request.getUserPrincipal();
        }

ServletRequestMethodArgumentResolver thinks that UserPrincipal is a Principal. This is correct. SecurityContextHolderAwareRequestWrapper#getUserPrincipal method returns Authentication which is not a UserPrincipal. This is raising an exception because it can not assign Authentication to UserPrincipal.

1. Inevitable dependency to Spring Security because of Authentication

Consider two different modules which has the abstraction of Servlet Api. Proper implementation of this abstraction should provide no need to Spring Security.

Consider this:

Module A depends on Servlet Api and Custom Principal
Module B depends on Servlet Api and Spring Security and Custom Principal
Module Web A depends on Module A and Module B

Each module has their own Controllers. But in order to access custom principal at module A, I must be depend on Spring Security too :*( This is breaking brilliant abstraction of Spring Security and Servlet API.

And I have to use as this:

public ModelAndView someRequestHandler(Principal principal) {
   UserPrincipal activeUser = (UserPrincipal) ((Authentication) principal).getPrincipal();
   ...
}

Which is pretty ugly because I have to depend on Spring Security for module A.

My questions:

1. Is it possible to return real Principal at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestWrapper#getUserPrincipal?
2. If 1 is not possible, How can I configure Authentication to implement UserPrincipal methods? (This is what I really does not want)

Thanks

[spring-projects-issues]

Cemo Koc said:

We had conversations at stackoverflow at these threads 1 and 2. I ended up with such slight change.

old:

    public Principal getUserPrincipal() {
        Authentication auth = getAuthentication();

        if ((auth == null) || (auth.getPrincipal() == null)) {
            return null;
        }

        return auth;
    }

new: 

   public Principal getUserPrincipal() {
      Authentication auth = getAuthentication();

      if ((auth == null) || (auth.getPrincipal() == null)) {
         return null;
      }

      Object principal = auth.getPrincipal();
      return principal instanceof Principal ? (Principal)principal : auth;
   }

What do you think Rob?

[spring-projects-issues]

Rob Winch said:

Please see my responses to your SO questions http://stackoverflow.com/questions/17744272/spring-security-why-authentication-is-extending-principal/17751459 and http://stackoverflow.com/questions/17741787/injecting-custom-principal-to-controllers-by-spring-security?lq=1 In short, I don't think this will be integrated into Spring Security but you can certainly leverage existing infrastructure to achieve what you need with minimal issues.