Hi,
I have not looked into Undertow in such detail, but I take it's an
evolution to PicketLink somewhat similar to e.g. Agorava evolved from
original Seam Social (taking many of its ideas and adding other new ones,
e.g. what was discussed for a possible Social JSR that didn't get approval
here)
Shane and Boleslaw represent(ed) Red Hat in JSR 351. The focus there is
more along the lines of SSO. These days JSR 351 is preparing for a Renewal
Ballot as I mentioned a bit earlier, the jcp.next deadlines often are more
strict than release plans and road maps of Umbrella JSRs like EE 8.
Though having a vote in the EC, I can't predict the outcome, but if the
Spec Leads can outline how a possible synergy between this JSR and 351
might work, I guess it could pass. Otherwise relevant aspects would
probably be left for this JSR entirely.
Regards,
Werner
On Mon, Apr 20, 2015 at 3:13 PM, 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.
>
> #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.
>>
>>
>