On 27/03/15 12:08, arjan tijms wrote:
> Hi,
>
> On Friday, March 27, 2015, Mark Struberg <struberg_at_yahoo.de
> <mailto: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.
I think the roles allowed being applied to methods is too coarse for
many to make use of 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.
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.
> 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.
> > >
> >
> >