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. 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>:
>
> Hi,
>
> On Wed, Mar 25, 2015 at 2:54 PM, Mark Struberg <struberg_at_yahoo.de> 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>:
> >
> > 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.
> >
>
>