jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] Re: Top Down vs. Bottom Up

From: Adam Bien <abien_at_adam-bien.com>
Date: Wed, 15 Apr 2015 09:45:09 +0200

> On 14.04.2015, at 09:25, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> Hi,
>
> On Tue, Apr 14, 2015 at 8:17 AM, Adam Bien <abien_at_adam-bien.com> wrote:
>> 1. login with user name and password
>> 2. token authentication with JAX-RS
>
> I recently prototyped this one:
>
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>
> It's 3 classes; the authentication mechanism, the identity store
> (still called authenticator there, I might rename it), and a
> ServletContextListener with a one liner that registers the module.
>
> IMHO the nice thing of this example is that it fully integrates with
> the existing Java EE security system, so that web.xml constraints and
> the existing @RolesAllowed etc all still work.
>
>
>> 3. annotation based and runtime authorization (interceptors, permissions etc.)
>> 4. enhancement of Principal with application specific payload
>
> I'm not 100% sure if this is really a good idea. The point is that a
> Principal is supposed to be just an *attribute* of the user. There's a
> widespread confusion (IMHO) that a Principal IS the user (caller).
> Much closer to representing the user/caller itself is the Subject.
But if the extensibility is requested a lot, why not just add a method Map<String,Object> getContext() (and setter) to the Principal? or expose the public part of the Subject?

We could also make the Subject injectable with @Inject (built-in CDI bean)

>
> I do know that injecting a more complete (application specific) user
> after authentication is a *very* common request by app developers.
> Personally I often use a pattern where I inject the caller/user
> Principal in a producer, and then based on that produce an application
> specific user.
>
> Authentication events (such as supported by WildFly, see
> http://jdevelopment.nl/bridging-undertows-authentication-events-cdi)
> can make this easier.
>
>> 5. logout
>
> Could you elaborate what would be needed here beyond what Java EE
> already supports? HtppServletRequest#logout is already there, or do
> you just mean the use case should be demonstrated?

Java EE supports logout only through servlets: http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html
 
In JAX-RS we can just reference the HttpServletRequest, with @Context but it is ugly. I think there is room for simplification.

>
>
> Kind regards,
> Arjan Tijms
>
>
>> 6. user management
>>
>> I would like to create a simplistic Java EE application(s) (max 5 classes) and try to implement the use cases above with minimal required code.
>> If necessary with proprietary APIs, which hopefully are going to be replaced by standard spec as we progress.
>> We could use this application for further discussion and further simplification and usability enhancement,
>>
>> what do you think?
>>
>> cheers,
>>
>> adam
>>
>>
>>