Hi,
On Mon, Apr 20, 2015 at 3:17 PM, Darran Lofthouse
<darran.lofthouse_at_redhat.com> wrote:
>> as an application developer I'm particularly interested in the overall
>> experience for the most common use cases:
>>
>> 1. login with user name and password
>
>
> IMO an application developer should be interested in knowing that their
> application can be secured but not necessarily the how.
Well, the part of a (simple) application where the application
developer also develops the identity store does care about this, and
therefor the application developer cares.
Naturally, we (at least most of us here I think) discourage user
name/password, and even discourage storing them locally.
But IMHO, trying to educate people here using the current approach
just seems to scare them away, no matter how well meant it is. In the
beginning, application developers really do want to think in terms of
a simple store that they implement themselves. Configuring something
certificate based outside the application in a server specific way
where different XML files have to refer to "things" is *really*
intimidating.
My hope is that with a simple standardized identity store, application
developers can start using this, and then localize knowledge about
username/password to that store and optionally to a custom
authentication module (2 classes, at most). The rest of their app
shouldn't care.
Then, when the application has grown and/or the application developer
has become more accustomed to Java EE and the specific server that's
being used, security can completely transparently be moved from being
embedded in the application to being configured at the server level.
Just my 2 cents ;)
Kind regards,
Arjan Tijms
>
>
>> 2. token authentication with JAX-RS
>> 3. annotation based and runtime authorization (interceptors, permissions
>> etc.)
>> 4. enhancement of Principal with application specific payload
>> 5. logout
>> 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
>>
>