+1 :)
Le 14 avr. 2015 11:27, "Werner Keil" <werner.keil_at_gmail.com> a écrit :
> 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
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>
>