On 20/04/15 14:22, Werner Keil wrote:
> 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)
I think the best way to describe it is our first step in moving HTTP
authentication towards an identity store approach rather than the
traditional username / credential validation approach. Obviously
internally PicketLink was our main project providing those kinds of
capabilities.
In addition to the two points I highlighted another one of our
objectives that also fed into the combined design was eliminating the
protocol from leaking through to the identity store layer -
traditionally where we had Digest or SPNEGO authentication backed by
JAAS various aspects from HTTP were leaking into the login modules
making them unsuitable for other scenarios.
> 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 <mailto: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.
>
>
>