On 15/04/15 08:31, Adam Bien wrote:
> Hi *,
>
> I created a simplistic, but realistic Java EE 7 app: https://github.com/AdamBien/secspike based on with, JAX-RS, EJB and JPA.
>
> The ToDo item comes with changedBy, createdBy attributes derived from the Principal.
>
> It is ToDo application with corresponding JAX RS 2.0 system test / client, so it should be easy to test different auth scenarios.
>
> We can move it from my repo to wherever you like.
>
> My goal is to keep the authorization / authentication part as convenient, elegant and usable as only possible,
>
> Should we start with user name / password login implementation and in-memory IdentityStore? We could copy this app for each scenario and reuse the already existing sec examples.
When looking into how authentication mechanisms can work within a
proposed API / SPI I think there are a few things that are critical in
order that the API can be validated.
#1 Complex authentication mechanisms must be used, whilst it has fallen
out of favour due to the weak message digest HTTP Digest and it's
various options do push APIs quite hard.
Where I see a focus on Basic authentication in the past this tends to
not push APIs and their design far enough.
#2 There is a lot of demand for multiple authentication mechanisms to be
supported concurrently, a common combination being SPNEGO, some form of
username / password (Form, Basic, Digest etc...), Client Cert and then
maybe even combine this some form of SSO.
When using a native protocol with something like SASL a lot of this can
be achieved by listing all the supported authentication mechanisms to
the client and allowing the client to use the one it wants to use.
Within HTTP this is not the case and you can actually end up with
multiple mechanisms needing to run concurrently.
Generally this is how the current AuthenticationMechanism API within
Undertow was reached to support multiple mechanisms concurrently.
> Should we use GF 4.X as reference server?
>
>
> cheers,
>
> adam
>
> I broke my underarm, so my coding speed suffers a bit, but next week should be back to normal.
>