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.
> >
>
>