jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] Re: [javaee-security-proposals] add a proposal for a SecurityBindingType (#6)

From: Darran Lofthouse <darran.lofthouse_at_redhat.com>
Date: Thu, 09 Apr 2015 14:58:04 +0100

On 31/03/15 17:04, arjan tijms wrote:
> Hi,
>
> On Tue, Mar 31, 2015 at 5:40 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com> wrote:
>> I think the roles allowed being applied to methods is too coarse for many to
>> make use of
>
> I may also depend on what business case you assign to a role. Is a
> role necessarily something like "ADMIN", or is it acceptable to have
> roles like "VIEW_UNPROCESSED_TX", "REVOKE_PROCESSED_TX", etc?
>
>> but overall I think it is the shortcomings of security in the
>> specs as a whole that push people away from EE security rather than one
>> specific part.
>
> Indeed, IMHO it's mainly a collection of mostly little things which
> all together add up.
>
>> I think the Servlet spec also drove some away by forcing authentication to
>> only occur once a secured resource was accessed with the automatic redirects
>> although at least that has been covered now.
>
> True, this was a major shortcoming in practice that was covered by
> what was technically speaking not even that big and much code to
> implement.
>
> JASPIC also addressed this specific point by defining that a SAM is
> *always* called, whether a secured- or non secured resource is
> accessed and whether the authenticated identity has previously (within
> the same session) been established or not. Preemptive authentication
> is the keyword here.

I also took a similar view with authentication within Undertow, for some
authentication mechanisms once you have authenticated once you need to
still keep checking the headers from the browser otherwise you leave
yourself at risk of a replay attack that the mechanism was supposed to
protect against.

> Kind regards,
> Arjan Tijms
>