> On 20.04.2015, at 15:13, Darran Lofthouse <darran.lofthouse_at_redhat.com> wrote:
>
> 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.
True. But we should start with the most popular thing and improve from that.
>
> #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.
You are right, SSO is requested a lot.
>
> 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.
Chaining and concurrency is also not a problem—IMO the “main” API should be as simple as only possible. What do you suggest to be implemented next?
>
> 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.
>>
>