Hi,
There was some discussion around JAX-RS and the Security API integration on another thread [1]. Before opening a thread on the JAX-RS list to consider deprecating their SecurityContext class, I'd like to gather your opinion on the broad part of this topic.
Currently, the following specs (besides Security spec and JACC) provide a way to get the user principal and/or check user roles:
Spec User Principal User in role
------------ ----------------------------------------------------------------------- -----------------------------------
Servlet HttpServletRequest#getUserPrincipal() HttpServletRequest#isUserInRole()
JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() javax.ws.rs.core.SecurityContext#isUserInRole()
JAX-WS WebServiceContext#getUserPrincipal() WebServiceContext#isUserInRole()
EJB EJBContext#getCallerPrincipal() EJBContext#isCallerInRole()
CDI @Inject Principal principal -
Servlet, JAX-WS and EJB behaviour is theoretically controlled by JACC. JAX-WS should inherit the Servlet rules when implemented on top of them (which is not mandatory).
But Security has always been difficult on Java EE and so users have relied on a lot of home-grown solutions, like overriding HttpServletRequest or javax.ws.rs.core.SecurityContext methods to control the caller identity. That approach presents the issue that the identity is not controlled by the container and thus not propagated between components.
The "is caller in role" methods can also be problematic. Imagine the following situations:
- On a Servlet based JAX-RS resource/JAX-WS service, with a HttpServletRequestWrapper that overrides the getUserPrincipal()/isUserInRole() methods might return different results than the javax.ws.rs.core.SecurityContext and WebServiceContext equivalent methods.
- On an EJB based JAX-RS resource, with a custom javax.ws.rs.core.SecurityContext overriding the getUserPrincipal()/isUserInRole() methods, EJBContext might return different results that SecurityContext.
- In any case, it's unspecified where CDI takes its injectable Principal from [2].
- Things like @RolesAllowed and Servlet security constraints won't work with the "dynamic" roles.
In addition to that problems, there's no guarantee that all the "get caller principal"
methods will return the same object. The former JSR 375 EG couldn't
agree to return the user defined Principal (via JASPIC) as the caller principal due to some shortcomings in WebLogic.
To improve this situation, my personal take on this is we should push other specs to:
- Servlet: when there's a JSR375 implementation on the classpath, login must be done via an HttpAuthenticationMechanism. In those cases, users are pointed to customize the
javax.security.enterprise.SecurityContext in order to provide custom behaviour, instead of wrapping the HttpServletRequest. Role checks are done against the SecurityContext (which in turn will delegate to JACC by default). JASPIC should always be mandated, even outside Jakarta EE containers.
- JAX-RS: deprecate javax.ws.rs.core.SecurityContext and strongly recommend users to directly use the Security API. JAX-RS doesn't even have a portable way to define security constraints (Servlet integration is optional). Users will still be able to implement home grown security if they don't want/can't use the Security API.
- EJB and JAX-WS: if there are new releases of these specs, they should mandate the security methods to delegate to javax.security.enterprise.SecurityContext. EJB Lite and standalone JAX-WS would be outside this rule. @RolesAllowed checks are done agains SecurityContext.
- CDI: deprecate Principal injection and delegate its obtention to SecurityContext#getCallerPrincipal.
We get the follwing benefits from this:
- Every "getCallerPrincipal" method returns the same instance. As of now, there's still no guarantee that the instance will be the one defined by the user. But if we are able to eventually remove the concept of "platform-specific" principal representations, all methods will automatically get the user principal. For the time being, they will at least all return the same representation.
- Users who need to do application-managed identities will only need to provide an @Alternative SecurityContext and all security related methods will return consistent results. The identity won't be propagated to the container, but container facilities like @RolesAllowed should still work.
What do you all think about this? Do you think this is worth pushing other specs to work on?
Regards,
Guillermo González de Agüero
