As we did this for a JSR that is about to be finalized in the next few
weeks (354) examples could use Maven to structure them similar to
https://github.com/JavaMoney/javamoney-examples
Instead of environments ("console" vs. "web" or "rich clients") you could
use areas like "authentication" or "authorization".
WDYT?
Werner
On Tue, Apr 14, 2015 at 10:47 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Tuesday, April 14, 2015, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> 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 ?
>>
>
> Yes, it's now in my own prototype repo. But I was looking into organising
> the javaee-security-* repo a little first.
>
> I'd like to have at least an "authentication" and "authorization" folder.
> And from that maybe follow the structure from Alex' excellent scope
> document?
>
> IMHO it would be best if for every example a little thought went into what
> it exactly demonstrates, and how it exactly relates to the scope proposed
> by Alex and perhaps the diagrams created by Rudy and me.
>
> Consistent terminology is the key here.
>
> I'd like to propose that everyone who effectively demonstrated an
> "Identity Store" renamed their examples if it didn't use that term (if
> that's doable). I'll go ahead and update my blog later today.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>> 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
>>> >
>>> >
>>> >
>>>
>>
>>