Hi,
On Tue, Apr 14, 2015 at 11:08 AM, Jean-Louis Monteiro
<jlmonteiro_at_tomitribe.com> wrote:
> Well the examples were meant to give anyone to push ideas and brainstorm
> without restrictions. If we add terminology and reorganise everything we may
> somehow prevent users from proposing good stuff cause they are not familiar
> with the structure nor the terminology.
Yeah, of course, but such brainstorm ideas can still be put into an
uncategorized section, or in a folder using a different term, which we
can then possibly refactor later if it becomes clear the example is
about something for which we have established a term.
At the very least I would hope that people know whether they are
demoing "authentication" or "authorization", but if even that is not
clear we can have an uncategorized folder at the top level too.
> I'd rather when we agree on the terminology and on the way to go, move from
> example to something else?
> Probably examples was not a good name (labs or sthg else would be more
> appropriated and give us the examples for the target).
Maybe it wasn't so bad to begin with ;) But now that a large number of
examples have been pushed it might be the right time to look into
common patterns, while still allowing uncategorized new examples to be
pushed?
Kind regards,
Arjan Tijms
>
> Whatever as you mentioned a small readme would be great.
>
> Le 14 avr. 2015 10:58, "arjan tijms" <arjan.tijms_at_gmail.com> a écrit :
>>
>> 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
>>>> >
>>>> >
>>>> >
>>>
>>>
>