And the JAX-RS juggernaut continues ….
This blog briefly talks about how to override the default security related information associated with a JAX-RS request i.e. how to mess with the SecurityContext
Wait.. Security Context ?
- Think of it as a JAX-RS abstraction over HTTPServletRequest for security related information only
- Can be used for
- figuring out how the caller was authenticated
- extracting authenticated Principal info
- role membership confirmation (programmatic authorization)
- and whether or not the request was initiated securely (over HTTPS)
Ok, but why would I need a custom implementation ?
It helps when you have a custom authentication mechanism not implemented using standard Java EE security realm
- your web container will not be aware of the authentication details
- as a result, the SecurityContext instance will not contain the subject, role and other details (mentioned above)
- a typical example is token based authentication based on custom (app specific) HTTP headers
Your RESTful application would definitely want to make use of the authenticated caller
- the JAX-RS request pipeline needs to be aware of the associated ‘security context’
- make use of it within its business logic
SecurityContext is an interface after all..
- just implement it
- inject it (using @Context) and use it in your resource methods