Hi,
On Mon, Apr 20, 2015 at 3:29 PM, Darran Lofthouse
<darran.lofthouse_at_redhat.com> wrote:
> 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.
Indeed, +1 on that.
The identity store should just be "credentials in - username/roles
out", and should definitely not be concerned with HTTP or any other
communication/interaction with the caller.
Kind regards,
Arjan Tijms
>
>> 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.
>>
>>
>>
>