Hi,
On Friday, March 27, 2015, Mark Struberg <struberg_at_yahoo.de> wrote:
> In my opinion @RolesAllowed is often not enough. The strict String[] role
> based mode is one of the reason EE-security is not used that often.
I see it a bit different. My own opinion and that what I've heard from
(many) others is that @RolesAllowed en web.xml constraints are easy to use
and have been sufficient.
In other words, defining the authorization constraint is not the *major*
issue.
IMHO, the major issue is the configuration of authentication stores (which
is mostly vendor specific) and the definition + configuration of
authentication mechanisms (which people think is vendor specific since we
perhaps didn't do the best job in the world to tell developers JASPIC
exists).
Then there are various gaps, like the non-standardised role mapper and
non-standardised caller- and group principals.
Of course it's great to have some modern or higher level features like
remember me, OAuth, events, CDI support etc, but I don't think the absence
of that is the core "flaw" in Java EE security.
That said, I do absolutely agree we should provide the "more" that you
mentioned to keep Java EE security relevant in the future.
Kind regards,
Arjan Tijms
> In practice I almost always needed more. It is kind of a meta-framework
> and you can of course build @RolesAllowed as a @SecurityBindingType as well
> ;)
>
> It _can_ be implemented via CDI - but also via Spring, etc.
>
> > And how would we explain to users the benefit of this annotation vs a
> „regular“ Interceptor annotation
> That’s indeed a good question.
> In DeltaSpike it technically IS kind of an interceptor of course. The
> difference is that you cannot use it as manual interceptor but it’s always
> explicitly used by and for security checks.
>
> LieGrue,
> strub
>
>
>
> > Am 25.03.2015 um 15:36 schrieb arjan tijms <arjan.tijms_at_gmail.com
> <javascript:;>>:
> >
> > Hi,
> >
> > On Wed, Mar 25, 2015 at 2:54 PM, Mark Struberg <struberg_at_yahoo.de
> <javascript:;>> wrote:
> > The SecurityBindingType is neither Role nor Permission based actually.
> It allows for a flexible integration on whatever level your company needs.
> In fact I basically almost always had a mixture of roles and permissions to
> check for. Often they are also tenant specific! And sometimes there are
> multiple AND vs OR requirements as well.
> > So it basically boils down to being a VERY company and business related
> topic. And this is what is really the strength of this approach. It allows
> to add any payload you like to your security annotation. Much like with
> Interceptor annotations can get any payload you like.
> >
> > I sounds good ;)
> >
> > How do you propose to position such annotation relative to (CDI based)
> @RolesAllowed and (EL based) @EvaluateSecured?
> >
> > And how would we explain to users the benefit of this annotation vs a
> "regular" Interceptor annotation, where as you mentioned users can already
> provide any payload they like (which therefor can be security related as
> well in a way that's totally application specific)?
> >
> > Note, this is no criticism, just wondering how to fit this into the
> larger picture.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> > LieGrue,
> > strub
> >
> > PS: if my mail doesn’t make it through to the spec list then plz forward
> it for me - txs!
> >
> >
> > > Am 25.03.2015 um 13:34 schrieb Arjan Tijms <notifications_at_github.com
> <javascript:;>>:
> > >
> > > Just wondering how to categorize this example.
> > >
> > > It's an authorization example it seems, but is this an example of a
> CDI based "@RolesAllowed" (as proposed in
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer
> to the "@EvaluateSecured" (as proposed in
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also
> https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization
> )?
> > >
> > > @dblevins Should be perhaps already start thinking about organization
> of this repo? A first level "authentication" and "authorization" perhaps?
> Then authentication organized in "mechanism" and "store" (even though we
> don't have a final term for that last one yet).
> > >
> > > At least make people a bit aware of what they are exactly demoing, and
> how it fits into the grand scheme of things? Maybe Rudy's mindmap and my
> diagram can be of help here too.
> > >
> > > —
> > > Reply to this email directly or view it on GitHub.
> > >
> >
> >
>
>