users@javaee-security-spec.java.net

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

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 14 Apr 2015 09:29:28 +0200

Sounds good, do you think you may consolidate this under
https://github.com/javaee-security-spec/javaee-security-examples and/or
(where API is affected)
https://github.com/javaee-security-spec/javaee-security-proposals ?

Kind Regards,
Werner

On Tue, Apr 14, 2015 at 9:25 AM, 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.
>
> 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
> >
> >
> >
>