users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Top Down vs. Bottom Up

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 14 Apr 2015 09:25:14 +0200

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.

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?


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
>
>
>