Besides cleaning the current mismatch between parent and detail POMs.
One says "javaee-security-examples" the others still refer to "bootstrap";-)
Werner
On Tue, Apr 14, 2015 at 11:13 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>