He's not an EG member as of now?;-)
Werner
On Wed, Mar 25, 2015 at 2:58 PM, Jean-Louis Monteiro <
jlmonteiro_at_tomitribe.com> wrote:
> Forwarding to the list, cause Mark's email got rejected.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> ---------- Forwarded message ----------
> From: Mark Struberg <struberg_at_yahoo.de>
> Date: Wed, Mar 25, 2015 at 2:54 PM
> Subject: Re: [javaee-security-proposals] add a proposal for a
> SecurityBindingType (#6)
> To: javaee-security-spec/javaee-security-proposals <
> reply+000135ce1364376c5efe16bf4e6ed308196648a8fd2927ce92cf00000001112a6d4492a16.github.com
> >
> Cc: David Blevins <dblevins_at_tomitribe.com>, arjan tijms <
> arjan.tijms_at_gmail.com>, Jean-Louis Monteiro <jlmonteiro_at_tomitribe.com>
>
>
> Hi Arjan!
>
> 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.
>
>
> 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.
> >
>
>
>