You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@deltaspike.apache.org by Christian Kaltepoth <ch...@kaltepoth.de> on 2012/02/01 07:13:01 UTC

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

What about something like this:

  public @interface AnyOf {
      Class<? extends Annotation>[] value();
  }

Usage:

  @AnyOf({User.class, Admin.class})
  public void doSomething() {
       // something
  }

It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java syntax. :)

Christian


2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> Yes, that would work, but that annotation is not that nice. I would have expected something like
> @AnyOf({@User, @Admin})
> which unfortunately is no valid Java syntax.
> Instead of that someone could write something like
> @AnyOf(role1 = @User, role2 = @Admin)
> which could be used like Shane suggests. Sadly enough there is no easy way to provide a default @AnyOf annotation. So the users have to write their own versions any time they need one.
>
> Any better ideas?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> Gesendet: Dienstag, 31. Januar 2012 22:48
> An: deltaspike-dev@incubator.apache.org
> Cc: Jason Porter
> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>
> I would approach the "or" use case by simply providing another annotation:
>
> @SecurityBindingType
> @Retention(RetentionPolicy.**RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface AdminOrUser {
>
> }
>
>
> public boolean @Secures @AdminOrUser isAdminOrUser() {
>   return isAdmin() || isUser();
> }
>
>
>
>
> On 01/02/12 07:44, Jason Porter wrote:
>> Looks like I responded to the wrong thread as well.
>>
>> I personally like the binding approach a little better. It seems to be
>> more similar to the CDI way of doing interceptors (which, at the end
>> of the day is essentially what we're doing). However, we have seen a
>> need of doing @Admin || @User or @Admin&&  @User. The and is fairly
>> easy, but the or is currently not covered and we need to be able to do that.
>>
>> I'm pretty much at a +0 for both as well. As long as we have a way of
>> doing the feature I described above, I don't really care which way we go.
>>
>> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>> <ge...@gmail.com>wrote:
>>
>>> hi shane,
>>>
>>> that's one of the reasons why i won't block it right now.
>>> if the majority prefers custom annotations, we should just introduce
>>> it
>>>> after<  v0.1 and prototype the missing parts (and test it with the
>>> supported servers).
>>>
>>> my vote is +0 right now (for both).
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
>>>
>>>> On 01/02/12 00:21, Gerhard Petracek wrote:
>>>>
>>>>> hi mark,
>>>>>
>>>>> thx for the heads-up. i just talked with shane about all those details.
>>>>>
>>>>> i don't see an issue with view-configs. codi just extracts the
>>>>> @Secured annotation during the bootstrapping process in case of view-configs.
>>> that
>>>>> would be the "same" for such custom annotations meta-annotated with
>>>>> @SecurityBindingType.
>>>>>
>>>>> what we need in case of intercepted beans:
>>>>> 1) access to InvocationContext
>>>>> 2) easy access to the information if a security check is on-going
>>>>> 3) possibility to configure a default error-view (needed later on)
>>>>> 4) possibility to provide a custom message + an integration with
>>>>> the upcoming i18n module
>>>>>
>>>>> shane said that it should be possible to add all needed features.
>>>>> (for
>>> me
>>>>> that means we need a prototype if the majority prefers custom
>>>>> annotations.)
>>>>>
>>>>> in the end both approaches are similar. both are generic enough to
>>>>> integrate 3rd party security frameworks.
>>>>>
>>>>> @SecurityBindingType is just more generic and users need an
>>>>> additional step to find secured beans (/views) in a project.
>>>>> furthermore, meta-data inheritance with the mentioned view-configs
>>>>> is a bit harder for users.
>>>>> imo it's just a matter of taste. custom annotations as additional
>>>>> indirection vs. a specific annotation with inline information.
>>>>>
>>>>> with the approach provided by codi, users can't introduce a custom
>>>>> annotation. however, i know a lot of users who prefer one given
>>> annotation
>>>>> instead of implementing x custom annotations. and i guess shane
>>>>> knows a lot of users who prefer custom annotations. the goal of
>>>>> codi was to make it easy, intuitive and flexible enough to
>>>>> integrate 3rd party security-frameworks (instead of creating a new
>>>>> security-framework). i wouldn't block the custom annotation
>>>>> approach if 1)-4) are possible -
>>> it's
>>>>> a bit more flexible but also a bit more complex for users.
>>>>>
>>>> The beauty with the custom annotations is, if you like you can just
>>> define
>>>> a single annotation if you want and use that throughout your application.
>>>>   I.e. you could similate the behavior of CODI:
>>>>
>>>>
>>>> @SecurityBindingType
>>>> @Retention(RetentionPolicy.**RUNTIME)
>>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>>>> Secured {
>>>>   @Nonbinding Class[] voters() default {};
>>>>
>>>> }
>>>>
>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
>>>>>
>>>>>   Gerhard, for explaining this you will probably need to also
>>>>> explain the
>>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
>>>>>> annotations, you would loose lots of functionality in this area.
>>>>>>
>>>>>> I know that this is not the current topic, but discussing security
>>>>>> mechanisms without discussing the stuff which needs to get secured
>>>>>> is only half of the truth ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>>>>>> JSFUsage-TypesafeViewConfig<
>>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC
>>> onfig
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>
>>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
>>> gerhard.petracek@gmail.com>
>>>>>>> To: deltaspike-dev@incubator.**apache.org<
>>> deltaspike-dev@incubator.apache.org>
>>>>>>> Cc:
>>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
>>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>>>>>>
>>>>>>> in case of myfaces codi it's also used for secured view and it is
>>>>>>> integrated with the default-error-view concept (as mentioned in
>>>>>>> the
>>>>>>>
>>>>>> ticket
>>>>>>
>>>>>>> we will postpone this part).
>>>>>>> furthermore it's used by codi-scopes to avoid a different
>>>>>>> expiration behaviour of beans cause by a security check (see the
>>>>>>> mentioned AccessDecisionVoterContext).
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
>>> arne.limburg@openknowledge.de>
>>>>>>>    Hi,
>>>>>>>>   My first objection when I saw the CODI feature the first time,
>>>>>>>> was
>>>>>>>>
>>>>>>> that it
>>>>>>>   maybe is too basic: When I have to implement the Voter anyway
>>>>>>> (or my
>>>>>>>>   security-framework of choice delivers it), why should I use
>>>>>>>> @Secured at
>>>>>>>>   all? I mean, what is the REAL benefit of using @Secured over a
>>> custom
>>>>>>>>   annotation implemented by myself or delivered by my
>>> security-framework
>>>>>>> of
>>>>>>>   choice.
>>>>>>>>   The only benefit I see is when using different security
>>>>>>>> sources, but
>>>>>>>>
>>>>>>> this
>>>>>>>   is a rare use case imho.
>>>>>>>>   Cheers,
>>>>>>>>   Arne
>>>>>>>>
>>>>>>>>   -----Ursprüngliche Nachricht-----
>>>>>>>>   Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
>>> gerhard.petracek@gmail.com>
>>>>>>>> ]
>>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
>>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
>>> deltaspike-dev@incubator.apache.org>
>>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>>>>>>>
>>>>>>>>   that's one option. a 2nd option is to use a
>>> deltaspike-security-impl.
>>>>>>>>   module which can provide e.g. an adapter for 3rd party
>>>>>>>>
>>>>>>> security-framework.
>>>>>>>   or users just add a possible deltaspike-add-on provided by an
>>> external
>>>>>>>>   community e.g. by a security-framework itself.
>>>>>>>>
>>>>>>>>   regards,
>>>>>>>>   gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
>>>>>>>>
>>>>>>>>   >   Is it up to the developer to define the bean that implements an
>>>>>>>>   interface?
>>>>>>>>   >
>>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
>>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
>>>>>>>>   >
>>>>>>>>   >   >   hi @ all,
>>>>>>>>   >   >
>>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice starting point
>>>>>>>>
>>>>>>> for
>>>>>>>
>>>>>>>>   >   >   the security-api discussion, because the basic idea behind it
>>> is
>>>>>>> a
>>>>>>>
>>>>>>>>   >   >   very thin integration layer (which can be used by other
>>>>>>>> modules).
>>>>>>>>   >   >
>>>>>>>>   >   >   the basic concept:
>>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure the target
>>>>>>>>   method/s.
>>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a specific
>>>>>>>>
>>>>>>> interface
>>>>>>>
>>>>>>>>   >   >   and therefore has access to the InvocationContext.
>>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<   be
>>>>>>>>
>>>>>>> used to
>>>>>>>
>>>>>>>>   >   integrate
>>>>>>>>   >   >   3rd party security-frameworks.
>>>>>>>>   >   >   [1] provides a bit more details of the basic concept as well
>>> as
>>>>>>> the
>>>>>>>
>>>>>>>>   >   >   basic usage of @Secured.
>>>>>>>>   >   >
>>>>>>>>   >   >   please send
>>>>>>>>   >   >   +1, +0 or -1 because...
>>>>>>>>   >   >   for the>basic concept<.
>>>>>>>>   >   >
>>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can discuss
>>>>>>>>
>>>>>>> details e.g.
>>>>>>>
>>>>>>>>   >   >   further objections about the concrete implementation (e.g.
>>>>>>>>
>>>>>>> internal
>>>>>>>
>>>>>>>>   >   >   classes,...) as soon as we agreed on including this concept.)
>>>>>>>>   >   >
>>>>>>>>   >   >   regards,
>>>>>>>>   >   >   gerhard
>>>>>>>>   >   >
>>>>>>>>   >   >   [1] https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
>>>>>>>>   >   >   [2]
>>>>>>>>   >   >
>>>>>>>>   >
>>>>>>>>
>>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>>>>>> SE+Feature+Rank<
>>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran
>>> k>
>>>>>>>   >   ing
>>>>>>>>   >   >
>>>>>>>>   >
>>>>>>>>
>>>>>>>>
>>
>>
>



-- 
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Shane Bryzak <sb...@redhat.com>.

This looks very interesting, we should definitely plan to provide an 
IdentityStore implementation that interfaces with this.

On 01/02/12 21:34, Mark Struberg wrote:
> Slightly OT FYI: there is also currently a new incubation project being discussed which handles 'Identity Management' [1]
>
>
>
>
> LieGrue,
> strub
>
>
> [1] http://wiki.apache.org/incubator/SyncopeProposal
>
>
> ----- Original Message -----
>> From: Shane Bryzak<sb...@redhat.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc: Christian Kaltepoth<ch...@kaltepoth.de>
>> Sent: Wednesday, February 1, 2012 10:43 AM
>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>
>> T he problem with this solution is it doesn't allow you to specify any
>> member values for the annotations.  I.e.
>>
>> @InGroup("manager")
>> public boolean promoteStaff(Staff staff) {
>>    ...
>> }
>>
>> I would probably rather defer any complex authorization logic to the
>> developer.  We're already giving them a lot of power with the typesafe
>> annotations, it would be really easy for them to define authorization
>> methods for any non-trivial privilege checks themselves.  Here's a
>> (contrived) example:
>>
>> @MemberOfRole(mode = MemberOf.ANY, roles = {"admin",
>> "manager",
>> "superuser"})
>> public void doSomethingPrivileged() {
>>     ...
>> }
>>
>> Everything here would be provided by the developer - the @MemberOfRole
>> annotation, the MemberOf enum and the authorizer method to process the
>> authorization logic.
>>
>> On 01/02/12 16:13, Christian Kaltepoth wrote:
>>>   What about something like this:
>>>
>>>      public @interface AnyOf {
>>>          Class<? extends Annotation>[] value();
>>>      }
>>>
>>>   Usage:
>>>
>>>      @AnyOf({User.class, Admin.class})
>>>      public void doSomething() {
>>>           // something
>>>      }
>>>
>>>   It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
>> syntax. :)
>>>   Christian
>>>
>>>
>>>   2012/1/31 Arne Limburg<ar...@openknowledge.de>:
>>>>   Yes, that would work, but that annotation is not that nice. I would
>> have expected something like
>>>>   @AnyOf({@User, @Admin})
>>>>   which unfortunately is no valid Java syntax.
>>>>   Instead of that someone could write something like
>>>>   @AnyOf(role1 = @User, role2 = @Admin)
>>>>   which could be used like Shane suggests. Sadly enough there is no easy
>> way to provide a default @AnyOf annotation. So the users have to write their own
>> versions any time they need one.
>>>>   Any better ideas?
>>>>
>>>>   Cheers,
>>>>   Arne
>>>>
>>>>   -----Ursprüngliche Nachricht-----
>>>>   Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>>>>   Gesendet: Dienstag, 31. Januar 2012 22:48
>>>>   An: deltaspike-dev@incubator.apache.org
>>>>   Cc: Jason Porter
>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>>>
>>>>   I would approach the "or" use case by simply providing
>> another annotation:
>>>>   @SecurityBindingType
>>>>   @Retention(RetentionPolicy.**RUNTIME)
>>>>   @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>> AdminOrUser {
>>>>   }
>>>>
>>>>
>>>>   public boolean @Secures @AdminOrUser isAdminOrUser() {
>>>>      return isAdmin() || isUser();
>>>>   }
>>>>
>>>>
>>>>
>>>>
>>>>   On 01/02/12 07:44, Jason Porter wrote:
>>>>>   Looks like I responded to the wrong thread as well.
>>>>>
>>>>>   I personally like the binding approach a little better. It seems to
>> be
>>>>>   more similar to the CDI way of doing interceptors (which, at the
>> end
>>>>>   of the day is essentially what we're doing). However, we have
>> seen a
>>>>>   need of doing @Admin || @User or @Admin&&     @User. The and
>> is fairly
>>>>>   easy, but the or is currently not covered and we need to be able to
>> do that.
>>>>>   I'm pretty much at a +0 for both as well. As long as we have a
>> way of
>>>>>   doing the feature I described above, I don't really care which
>> way we go.
>>>>>   On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>>>>>   <ge...@gmail.com>wrote:
>>>>>
>>>>>>   hi shane,
>>>>>>
>>>>>>   that's one of the reasons why i won't block it right
>> now.
>>>>>>   if the majority prefers custom annotations, we should just
>> introduce
>>>>>>   it
>>>>>>>   after<     v0.1 and prototype the missing parts (and test
>> it with the
>>>>>>   supported servers).
>>>>>>
>>>>>>   my vote is +0 right now (for both).
>>>>>>
>>>>>>   regards,
>>>>>>   gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>>   2012/1/31 Shane Bryzak<sb...@redhat.com>
>>>>>>
>>>>>>>   On 01/02/12 00:21, Gerhard Petracek wrote:
>>>>>>>
>>>>>>>>   hi mark,
>>>>>>>>
>>>>>>>>   thx for the heads-up. i just talked with shane about
>> all those details.
>>>>>>>>   i don't see an issue with view-configs. codi just
>> extracts the
>>>>>>>>   @Secured annotation during the bootstrapping process in
>> case of view-configs.
>>>>>>   that
>>>>>>>>   would be the "same" for such custom
>> annotations meta-annotated with
>>>>>>>>   @SecurityBindingType.
>>>>>>>>
>>>>>>>>   what we need in case of intercepted beans:
>>>>>>>>   1) access to InvocationContext
>>>>>>>>   2) easy access to the information if a security check
>> is on-going
>>>>>>>>   3) possibility to configure a default error-view
>> (needed later on)
>>>>>>>>   4) possibility to provide a custom message + an
>> integration with
>>>>>>>>   the upcoming i18n module
>>>>>>>>
>>>>>>>>   shane said that it should be possible to add all needed
>> features.
>>>>>>>>   (for
>>>>>>   me
>>>>>>>>   that means we need a prototype if the majority prefers
>> custom
>>>>>>>>   annotations.)
>>>>>>>>
>>>>>>>>   in the end both approaches are similar. both are
>> generic enough to
>>>>>>>>   integrate 3rd party security frameworks.
>>>>>>>>
>>>>>>>>   @SecurityBindingType is just more generic and users
>> need an
>>>>>>>>   additional step to find secured beans (/views) in a
>> project.
>>>>>>>>   furthermore, meta-data inheritance with the mentioned
>> view-configs
>>>>>>>>   is a bit harder for users.
>>>>>>>>   imo it's just a matter of taste. custom annotations
>> as additional
>>>>>>>>   indirection vs. a specific annotation with inline
>> information.
>>>>>>>>   with the approach provided by codi, users can't
>> introduce a custom
>>>>>>>>   annotation. however, i know a lot of users who prefer
>> one given
>>>>>>   annotation
>>>>>>>>   instead of implementing x custom annotations. and i
>> guess shane
>>>>>>>>   knows a lot of users who prefer custom annotations. the
>> goal of
>>>>>>>>   codi was to make it easy, intuitive and flexible enough
>> to
>>>>>>>>   integrate 3rd party security-frameworks (instead of
>> creating a new
>>>>>>>>   security-framework). i wouldn't block the custom
>> annotation
>>>>>>>>   approach if 1)-4) are possible -
>>>>>>   it's
>>>>>>>>   a bit more flexible but also a bit more complex for
>> users.
>>>>>>>   The beauty with the custom annotations is, if you like you
>> can just
>>>>>>   define
>>>>>>>   a single annotation if you want and use that throughout
>> your application.
>>>>>>>      I.e. you could similate the behavior of CODI:
>>>>>>>
>>>>>>>
>>>>>>>   @SecurityBindingType
>>>>>>>   @Retention(RetentionPolicy.**RUNTIME)
>>>>>>>   @Target({ElementType.TYPE, ElementType.METHOD}) public
>> @interface
>>>>>>>   Secured {
>>>>>>>      @Nonbinding Class[] voters() default {};
>>>>>>>
>>>>>>>   }
>>>>>>>
>>>>>>>
>>>>>>>>   regards,
>>>>>>>>   gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   2012/1/31 Mark Struberg<st...@yahoo.de>
>>>>>>>>
>>>>>>>>      Gerhard, for explaining this you will probably need
>> to also
>>>>>>>>   explain the
>>>>>>>>>   TypeSafe Navigation as we have it in CODI [1].By
>> using custom
>>>>>>>>>   annotations, you would loose lots of functionality
>> in this area.
>>>>>>>>>   I know that this is not the current topic, but
>> discussing security
>>>>>>>>>   mechanisms without discussing the stuff which needs
>> to get secured
>>>>>>>>>   is only half of the truth ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   LieGrue,
>>>>>>>>>   strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   [1]
>>>>>>>>>   https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>>>>>>>>>   JSFUsage-TypesafeViewConfig<
>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC
>>>>>>   onfig
>>>>>>>>>   ----- Original Message -----
>>>>>>>>>
>>>>>>>>>>   From: Gerhard
>> Petracek<gerhard.petracek@**gmail.com<
>>>>>>   gerhard.petracek@gmail.com>
>>>>>>>>>>   To: deltaspike-dev@incubator.**apache.org<
>>>>>>   deltaspike-dev@incubator.apache.org>
>>>>>>>>>>   Cc:
>>>>>>>>>>   Sent: Tuesday, January 31, 2012 1:31 PM
>>>>>>>>>>   Subject: Re: [DISCUSS][SECURITY-API]
>> [DELTASPIKE-64] @Secured
>>>>>>>>>>   in case of myfaces codi it's also used for
>> secured view and it is
>>>>>>>>>>   integrated with the default-error-view concept
>> (as mentioned in
>>>>>>>>>>   the
>>>>>>>>>>
>>>>>>>>>   ticket
>>>>>>>>>
>>>>>>>>>>   we will postpone this part).
>>>>>>>>>>   furthermore it's used by codi-scopes to
>> avoid a different
>>>>>>>>>>   expiration behaviour of beans cause by a
>> security check (see the
>>>>>>>>>>   mentioned AccessDecisionVoterContext).
>>>>>>>>>>
>>>>>>>>>>   regards,
>>>>>>>>>>   gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   2012/1/31 Arne
>> Limburg<arne.limburg@**openknowledge.de<
>>>>>>   arne.limburg@openknowledge.de>
>>>>>>>>>>       Hi,
>>>>>>>>>>>      My first objection when I saw the CODI
>> feature the first time,
>>>>>>>>>>>   was
>>>>>>>>>>>
>>>>>>>>>>   that it
>>>>>>>>>>      maybe is too basic: When I have to implement
>> the Voter anyway
>>>>>>>>>>   (or my
>>>>>>>>>>>      security-framework of choice delivers
>> it), why should I use
>>>>>>>>>>>   @Secured at
>>>>>>>>>>>      all? I mean, what is the REAL benefit of
>> using @Secured over a
>>>>>>   custom
>>>>>>>>>>>      annotation implemented by myself or
>> delivered by my
>>>>>>   security-framework
>>>>>>>>>>   of
>>>>>>>>>>      choice.
>>>>>>>>>>>      The only benefit I see is when using
>> different security
>>>>>>>>>>>   sources, but
>>>>>>>>>>>
>>>>>>>>>>   this
>>>>>>>>>>      is a rare use case imho.
>>>>>>>>>>>      Cheers,
>>>>>>>>>>>      Arne
>>>>>>>>>>>
>>>>>>>>>>>      -----Ursprüngliche Nachricht-----
>>>>>>>>>>>      Von: Gerhard Petracek
>> [mailto:gerhard.petracek@**gmail.com<
>>>>>>   gerhard.petracek@gmail.com>
>>>>>>>>>>>   ]
>>>>>>>>>>>      Gesendet: Dienstag, 31. Januar 2012
>> 13:14
>>>>>>>>>>>      An:
>> deltaspike-dev@incubator.**apache.org<
>>>>>>   deltaspike-dev@incubator.apache.org>
>>>>>>>>>>>      Betreff: Re: [DISCUSS][SECURITY-API]
>> [DELTASPIKE-64] @Secured
>>>>>>>>>>>      that's one option. a 2nd option is
>> to use a
>>>>>>   deltaspike-security-impl.
>>>>>>>>>>>      module which can provide e.g. an adapter
>> for 3rd party
>>>>>>>>>>   security-framework.
>>>>>>>>>>      or users just add a possible
>> deltaspike-add-on provided by an
>>>>>>   external
>>>>>>>>>>>      community e.g. by a security-framework
>> itself.
>>>>>>>>>>>      regards,
>>>>>>>>>>>      gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      2012/1/31 John D.
>> Ament<jo...@gmail.com>
>>>>>>>>>>>      >      Is it up to the developer to
>> define the bean that implements an
>>>>>>>>>>>      interface?
>>>>>>>>>>>      >
>>>>>>>>>>>      >      On Tue, Jan 31, 2012 at 6:59
>> AM, Gerhard Petracek<
>>>>>>>>>>>      >     gerhard.petracek@gmail.com>
>>     wrote:
>>>>>>>>>>>      >
>>>>>>>>>>>      >      >      hi @ all,
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      imo this feature of
>> myfaces codi-core is a nice starting point
>>>>>>>>>>   for
>>>>>>>>>>
>>>>>>>>>>>      >      >      the security-api
>> discussion, because the basic idea behind it
>>>>>>   is
>>>>>>>>>>   a
>>>>>>>>>>
>>>>>>>>>>>      >      >      very thin integration
>> layer (which can be used by other
>>>>>>>>>>>   modules).
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      the basic concept:
>>>>>>>>>>>      >      >      a cdi interceptor
>> invokes (inline) voters to secure the target
>>>>>>>>>>>      method/s.
>>>>>>>>>>>      >      >      a voter is a (custom)
>> cdi bean which implements a specific
>>>>>>>>>>   interface
>>>>>>>>>>
>>>>>>>>>>>      >      >      and therefore has
>> access to the InvocationContext.
>>>>>>>>>>>      >      >      furthermore, a voter
>> detects 0-n violations and>can<      be
>>>>>>>>>>   used to
>>>>>>>>>>
>>>>>>>>>>>      >      integrate
>>>>>>>>>>>      >      >      3rd party
>> security-frameworks.
>>>>>>>>>>>      >      >      [1] provides a bit
>> more details of the basic concept as well
>>>>>>   as
>>>>>>>>>>   the
>>>>>>>>>>
>>>>>>>>>>>      >      >      basic usage of
>> @Secured.
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      please send
>>>>>>>>>>>      >      >      +1, +0 or -1
>> because...
>>>>>>>>>>>      >      >      for the>basic
>> concept<.
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      (please
>> add>basic<      objections also to [2]. we can discuss
>>>>>>>>>>   details e.g.
>>>>>>>>>>
>>>>>>>>>>>      >      >      further objections
>> about the concrete implementation (e.g.
>>>>>>>>>>   internal
>>>>>>>>>>
>>>>>>>>>>>      >      >      classes,...) as soon
>> as we agreed on including this concept.)
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      regards,
>>>>>>>>>>>      >      >      gerhard
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >      >      [1]
>> https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>>>>>>   https://issues.apache.org/jira/browse/DELTASPIKE-64>
>>>>>>>>>>>      >      >      [2]
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >
>>>>>>>>>>>
>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>>>>>>>>>   SE+Feature+Rank<
>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran
>>>>>>   k>
>>>>>>>>>>      >      ing
>>>>>>>>>>>      >      >
>>>>>>>>>>>      >
>>>>>>>>>>>
>>>>>>>>>>>
>>>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Mark Struberg <st...@yahoo.de>.

Slightly OT FYI: there is also currently a new incubation project being discussed which handles 'Identity Management' [1]




LieGrue,
strub


[1] http://wiki.apache.org/incubator/SyncopeProposal


----- Original Message -----
> From: Shane Bryzak <sb...@redhat.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: Christian Kaltepoth <ch...@kaltepoth.de>
> Sent: Wednesday, February 1, 2012 10:43 AM
> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> 
>T he problem with this solution is it doesn't allow you to specify any 
> member values for the annotations.  I.e.
> 
> @InGroup("manager")
> public boolean promoteStaff(Staff staff) {
>   ...
> }
> 
> I would probably rather defer any complex authorization logic to the 
> developer.  We're already giving them a lot of power with the typesafe 
> annotations, it would be really easy for them to define authorization 
> methods for any non-trivial privilege checks themselves.  Here's a 
> (contrived) example:
> 
> @MemberOfRole(mode = MemberOf.ANY, roles = {"admin", 
> "manager", 
> "superuser"})
> public void doSomethingPrivileged() {
>    ...
> }
> 
> Everything here would be provided by the developer - the @MemberOfRole 
> annotation, the MemberOf enum and the authorizer method to process the 
> authorization logic.
> 
> On 01/02/12 16:13, Christian Kaltepoth wrote:
>>  What about something like this:
>> 
>>     public @interface AnyOf {
>>         Class<? extends Annotation>[] value();
>>     }
>> 
>>  Usage:
>> 
>>     @AnyOf({User.class, Admin.class})
>>     public void doSomething() {
>>          // something
>>     }
>> 
>>  It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java 
> syntax. :)
>> 
>>  Christian
>> 
>> 
>>  2012/1/31 Arne Limburg<ar...@openknowledge.de>:
>>>  Yes, that would work, but that annotation is not that nice. I would 
> have expected something like
>>>  @AnyOf({@User, @Admin})
>>>  which unfortunately is no valid Java syntax.
>>>  Instead of that someone could write something like
>>>  @AnyOf(role1 = @User, role2 = @Admin)
>>>  which could be used like Shane suggests. Sadly enough there is no easy 
> way to provide a default @AnyOf annotation. So the users have to write their own 
> versions any time they need one.
>>> 
>>>  Any better ideas?
>>> 
>>>  Cheers,
>>>  Arne
>>> 
>>>  -----Ursprüngliche Nachricht-----
>>>  Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>>>  Gesendet: Dienstag, 31. Januar 2012 22:48
>>>  An: deltaspike-dev@incubator.apache.org
>>>  Cc: Jason Porter
>>>  Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>> 
>>>  I would approach the "or" use case by simply providing 
> another annotation:
>>> 
>>>  @SecurityBindingType
>>>  @Retention(RetentionPolicy.**RUNTIME)
>>>  @Target({ElementType.TYPE, ElementType.METHOD}) public @interface 
> AdminOrUser {
>>> 
>>>  }
>>> 
>>> 
>>>  public boolean @Secures @AdminOrUser isAdminOrUser() {
>>>     return isAdmin() || isUser();
>>>  }
>>> 
>>> 
>>> 
>>> 
>>>  On 01/02/12 07:44, Jason Porter wrote:
>>>>  Looks like I responded to the wrong thread as well.
>>>> 
>>>>  I personally like the binding approach a little better. It seems to 
> be
>>>>  more similar to the CDI way of doing interceptors (which, at the 
> end
>>>>  of the day is essentially what we're doing). However, we have 
> seen a
>>>>  need of doing @Admin || @User or @Admin&&    @User. The and 
> is fairly
>>>>  easy, but the or is currently not covered and we need to be able to 
> do that.
>>>> 
>>>>  I'm pretty much at a +0 for both as well. As long as we have a 
> way of
>>>>  doing the feature I described above, I don't really care which 
> way we go.
>>>> 
>>>>  On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>>>>  <ge...@gmail.com>wrote:
>>>> 
>>>>>  hi shane,
>>>>> 
>>>>>  that's one of the reasons why i won't block it right 
> now.
>>>>>  if the majority prefers custom annotations, we should just 
> introduce
>>>>>  it
>>>>>>  after<    v0.1 and prototype the missing parts (and test 
> it with the
>>>>>  supported servers).
>>>>> 
>>>>>  my vote is +0 right now (for both).
>>>>> 
>>>>>  regards,
>>>>>  gerhard
>>>>> 
>>>>> 
>>>>> 
>>>>>  2012/1/31 Shane Bryzak<sb...@redhat.com>
>>>>> 
>>>>>>  On 01/02/12 00:21, Gerhard Petracek wrote:
>>>>>> 
>>>>>>>  hi mark,
>>>>>>> 
>>>>>>>  thx for the heads-up. i just talked with shane about 
> all those details.
>>>>>>> 
>>>>>>>  i don't see an issue with view-configs. codi just 
> extracts the
>>>>>>>  @Secured annotation during the bootstrapping process in 
> case of view-configs.
>>>>>  that
>>>>>>>  would be the "same" for such custom 
> annotations meta-annotated with
>>>>>>>  @SecurityBindingType.
>>>>>>> 
>>>>>>>  what we need in case of intercepted beans:
>>>>>>>  1) access to InvocationContext
>>>>>>>  2) easy access to the information if a security check 
> is on-going
>>>>>>>  3) possibility to configure a default error-view 
> (needed later on)
>>>>>>>  4) possibility to provide a custom message + an 
> integration with
>>>>>>>  the upcoming i18n module
>>>>>>> 
>>>>>>>  shane said that it should be possible to add all needed 
> features.
>>>>>>>  (for
>>>>>  me
>>>>>>>  that means we need a prototype if the majority prefers 
> custom
>>>>>>>  annotations.)
>>>>>>> 
>>>>>>>  in the end both approaches are similar. both are 
> generic enough to
>>>>>>>  integrate 3rd party security frameworks.
>>>>>>> 
>>>>>>>  @SecurityBindingType is just more generic and users 
> need an
>>>>>>>  additional step to find secured beans (/views) in a 
> project.
>>>>>>>  furthermore, meta-data inheritance with the mentioned 
> view-configs
>>>>>>>  is a bit harder for users.
>>>>>>>  imo it's just a matter of taste. custom annotations 
> as additional
>>>>>>>  indirection vs. a specific annotation with inline 
> information.
>>>>>>> 
>>>>>>>  with the approach provided by codi, users can't 
> introduce a custom
>>>>>>>  annotation. however, i know a lot of users who prefer 
> one given
>>>>>  annotation
>>>>>>>  instead of implementing x custom annotations. and i 
> guess shane
>>>>>>>  knows a lot of users who prefer custom annotations. the 
> goal of
>>>>>>>  codi was to make it easy, intuitive and flexible enough 
> to
>>>>>>>  integrate 3rd party security-frameworks (instead of 
> creating a new
>>>>>>>  security-framework). i wouldn't block the custom 
> annotation
>>>>>>>  approach if 1)-4) are possible -
>>>>>  it's
>>>>>>>  a bit more flexible but also a bit more complex for 
> users.
>>>>>>> 
>>>>>>  The beauty with the custom annotations is, if you like you 
> can just
>>>>>  define
>>>>>>  a single annotation if you want and use that throughout 
> your application.
>>>>>>     I.e. you could similate the behavior of CODI:
>>>>>> 
>>>>>> 
>>>>>>  @SecurityBindingType
>>>>>>  @Retention(RetentionPolicy.**RUNTIME)
>>>>>>  @Target({ElementType.TYPE, ElementType.METHOD}) public 
> @interface
>>>>>>  Secured {
>>>>>>     @Nonbinding Class[] voters() default {};
>>>>>> 
>>>>>>  }
>>>>>> 
>>>>>> 
>>>>>>>  regards,
>>>>>>>  gerhard
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  2012/1/31 Mark Struberg<st...@yahoo.de>
>>>>>>> 
>>>>>>>     Gerhard, for explaining this you will probably need 
> to also
>>>>>>>  explain the
>>>>>>>>  TypeSafe Navigation as we have it in CODI [1].By 
> using custom
>>>>>>>>  annotations, you would loose lots of functionality 
> in this area.
>>>>>>>> 
>>>>>>>>  I know that this is not the current topic, but 
> discussing security
>>>>>>>>  mechanisms without discussing the stuff which needs 
> to get secured
>>>>>>>>  is only half of the truth ;)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  LieGrue,
>>>>>>>>  strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  [1]
>>>>>>>>  https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>>>>>>>>  JSFUsage-TypesafeViewConfig<
>>>>> 
> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC
>>>>>  onfig
>>>>>>>> 
>>>>>>>>  ----- Original Message -----
>>>>>>>> 
>>>>>>>>>  From: Gerhard 
> Petracek<gerhard.petracek@**gmail.com<
>>>>>  gerhard.petracek@gmail.com>
>>>>>>>>>  To: deltaspike-dev@incubator.**apache.org<
>>>>>  deltaspike-dev@incubator.apache.org>
>>>>>>>>>  Cc:
>>>>>>>>>  Sent: Tuesday, January 31, 2012 1:31 PM
>>>>>>>>>  Subject: Re: [DISCUSS][SECURITY-API] 
> [DELTASPIKE-64] @Secured
>>>>>>>>> 
>>>>>>>>>  in case of myfaces codi it's also used for 
> secured view and it is
>>>>>>>>>  integrated with the default-error-view concept 
> (as mentioned in
>>>>>>>>>  the
>>>>>>>>> 
>>>>>>>>  ticket
>>>>>>>> 
>>>>>>>>>  we will postpone this part).
>>>>>>>>>  furthermore it's used by codi-scopes to 
> avoid a different
>>>>>>>>>  expiration behaviour of beans cause by a 
> security check (see the
>>>>>>>>>  mentioned AccessDecisionVoterContext).
>>>>>>>>> 
>>>>>>>>>  regards,
>>>>>>>>>  gerhard
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  2012/1/31 Arne 
> Limburg<arne.limburg@**openknowledge.de<
>>>>>  arne.limburg@openknowledge.de>
>>>>>>>>>      Hi,
>>>>>>>>>>     My first objection when I saw the CODI 
> feature the first time,
>>>>>>>>>>  was
>>>>>>>>>> 
>>>>>>>>>  that it
>>>>>>>>>     maybe is too basic: When I have to implement 
> the Voter anyway
>>>>>>>>>  (or my
>>>>>>>>>>     security-framework of choice delivers 
> it), why should I use
>>>>>>>>>>  @Secured at
>>>>>>>>>>     all? I mean, what is the REAL benefit of 
> using @Secured over a
>>>>>  custom
>>>>>>>>>>     annotation implemented by myself or 
> delivered by my
>>>>>  security-framework
>>>>>>>>>  of
>>>>>>>>>     choice.
>>>>>>>>>>     The only benefit I see is when using 
> different security
>>>>>>>>>>  sources, but
>>>>>>>>>> 
>>>>>>>>>  this
>>>>>>>>>     is a rare use case imho.
>>>>>>>>>>     Cheers,
>>>>>>>>>>     Arne
>>>>>>>>>> 
>>>>>>>>>>     -----Ursprüngliche Nachricht-----
>>>>>>>>>>     Von: Gerhard Petracek 
> [mailto:gerhard.petracek@**gmail.com<
>>>>>  gerhard.petracek@gmail.com>
>>>>>>>>>>  ]
>>>>>>>>>>     Gesendet: Dienstag, 31. Januar 2012 
> 13:14
>>>>>>>>>>     An: 
> deltaspike-dev@incubator.**apache.org<
>>>>>  deltaspike-dev@incubator.apache.org>
>>>>>>>>>>     Betreff: Re: [DISCUSS][SECURITY-API] 
> [DELTASPIKE-64] @Secured
>>>>>>>>>> 
>>>>>>>>>>     that's one option. a 2nd option is 
> to use a
>>>>>  deltaspike-security-impl.
>>>>>>>>>>     module which can provide e.g. an adapter 
> for 3rd party
>>>>>>>>>> 
>>>>>>>>>  security-framework.
>>>>>>>>>     or users just add a possible 
> deltaspike-add-on provided by an
>>>>>  external
>>>>>>>>>>     community e.g. by a security-framework 
> itself.
>>>>>>>>>> 
>>>>>>>>>>     regards,
>>>>>>>>>>     gerhard
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>     2012/1/31 John D. 
> Ament<jo...@gmail.com>
>>>>>>>>>> 
>>>>>>>>>>     >     Is it up to the developer to 
> define the bean that implements an
>>>>>>>>>>     interface?
>>>>>>>>>>     >
>>>>>>>>>>     >     On Tue, Jan 31, 2012 at 6:59 
> AM, Gerhard Petracek<
>>>>>>>>>>     >    gerhard.petracek@gmail.com>  
>    wrote:
>>>>>>>>>>     >
>>>>>>>>>>     >     >     hi @ all,
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     imo this feature of 
> myfaces codi-core is a nice starting point
>>>>>>>>>> 
>>>>>>>>>  for
>>>>>>>>> 
>>>>>>>>>>     >     >     the security-api 
> discussion, because the basic idea behind it
>>>>>  is
>>>>>>>>>  a
>>>>>>>>> 
>>>>>>>>>>     >     >     very thin integration 
> layer (which can be used by other
>>>>>>>>>>  modules).
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     the basic concept:
>>>>>>>>>>     >     >     a cdi interceptor 
> invokes (inline) voters to secure the target
>>>>>>>>>>     method/s.
>>>>>>>>>>     >     >     a voter is a (custom) 
> cdi bean which implements a specific
>>>>>>>>>> 
>>>>>>>>>  interface
>>>>>>>>> 
>>>>>>>>>>     >     >     and therefore has 
> access to the InvocationContext.
>>>>>>>>>>     >     >     furthermore, a voter 
> detects 0-n violations and>can<     be
>>>>>>>>>> 
>>>>>>>>>  used to
>>>>>>>>> 
>>>>>>>>>>     >     integrate
>>>>>>>>>>     >     >     3rd party 
> security-frameworks.
>>>>>>>>>>     >     >     [1] provides a bit 
> more details of the basic concept as well
>>>>>  as
>>>>>>>>>  the
>>>>>>>>> 
>>>>>>>>>>     >     >     basic usage of 
> @Secured.
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     please send
>>>>>>>>>>     >     >     +1, +0 or -1 
> because...
>>>>>>>>>>     >     >     for the>basic 
> concept<.
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     (please 
> add>basic<     objections also to [2]. we can discuss
>>>>>>>>>> 
>>>>>>>>>  details e.g.
>>>>>>>>> 
>>>>>>>>>>     >     >     further objections 
> about the concrete implementation (e.g.
>>>>>>>>>> 
>>>>>>>>>  internal
>>>>>>>>> 
>>>>>>>>>>     >     >     classes,...) as soon 
> as we agreed on including this concept.)
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     regards,
>>>>>>>>>>     >     >     gerhard
>>>>>>>>>>     >     >
>>>>>>>>>>     >     >     [1] 
> https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>>>>>  https://issues.apache.org/jira/browse/DELTASPIKE-64>
>>>>>>>>>>     >     >     [2]
>>>>>>>>>>     >     >
>>>>>>>>>>     >
>>>>>>>>>> 
>>>>>>>>> 
> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>>>>>>>>  SE+Feature+Rank<
>>>>> 
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran
>>>>>  k>
>>>>>>>>>     >     ing
>>>>>>>>>>     >     >
>>>>>>>>>>     >
>>>>>>>>>> 
>>>>>>>>>> 
>>>> 
>> 
>> 
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Shane Bryzak <sb...@redhat.com>.

The problem with this solution is it doesn't allow you to specify any 
member values for the annotations.  I.e.

@InGroup("manager")
public boolean promoteStaff(Staff staff) {
  ...
}

I would probably rather defer any complex authorization logic to the 
developer.  We're already giving them a lot of power with the typesafe 
annotations, it would be really easy for them to define authorization 
methods for any non-trivial privilege checks themselves.  Here's a 
(contrived) example:

@MemberOfRole(mode = MemberOf.ANY, roles = {"admin", "manager", 
"superuser"})
public void doSomethingPrivileged() {
   ...
}

Everything here would be provided by the developer - the @MemberOfRole 
annotation, the MemberOf enum and the authorizer method to process the 
authorization logic.

On 01/02/12 16:13, Christian Kaltepoth wrote:
> What about something like this:
>
>    public @interface AnyOf {
>        Class<? extends Annotation>[] value();
>    }
>
> Usage:
>
>    @AnyOf({User.class, Admin.class})
>    public void doSomething() {
>         // something
>    }
>
> It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java syntax. :)
>
> Christian
>
>
> 2012/1/31 Arne Limburg<ar...@openknowledge.de>:
>> Yes, that would work, but that annotation is not that nice. I would have expected something like
>> @AnyOf({@User, @Admin})
>> which unfortunately is no valid Java syntax.
>> Instead of that someone could write something like
>> @AnyOf(role1 = @User, role2 = @Admin)
>> which could be used like Shane suggests. Sadly enough there is no easy way to provide a default @AnyOf annotation. So the users have to write their own versions any time they need one.
>>
>> Any better ideas?
>>
>> Cheers,
>> Arne
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>> Gesendet: Dienstag, 31. Januar 2012 22:48
>> An: deltaspike-dev@incubator.apache.org
>> Cc: Jason Porter
>> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>
>> I would approach the "or" use case by simply providing another annotation:
>>
>> @SecurityBindingType
>> @Retention(RetentionPolicy.**RUNTIME)
>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface AdminOrUser {
>>
>> }
>>
>>
>> public boolean @Secures @AdminOrUser isAdminOrUser() {
>>    return isAdmin() || isUser();
>> }
>>
>>
>>
>>
>> On 01/02/12 07:44, Jason Porter wrote:
>>> Looks like I responded to the wrong thread as well.
>>>
>>> I personally like the binding approach a little better. It seems to be
>>> more similar to the CDI way of doing interceptors (which, at the end
>>> of the day is essentially what we're doing). However, we have seen a
>>> need of doing @Admin || @User or @Admin&&    @User. The and is fairly
>>> easy, but the or is currently not covered and we need to be able to do that.
>>>
>>> I'm pretty much at a +0 for both as well. As long as we have a way of
>>> doing the feature I described above, I don't really care which way we go.
>>>
>>> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>>> <ge...@gmail.com>wrote:
>>>
>>>> hi shane,
>>>>
>>>> that's one of the reasons why i won't block it right now.
>>>> if the majority prefers custom annotations, we should just introduce
>>>> it
>>>>> after<    v0.1 and prototype the missing parts (and test it with the
>>>> supported servers).
>>>>
>>>> my vote is +0 right now (for both).
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
>>>>
>>>>> On 01/02/12 00:21, Gerhard Petracek wrote:
>>>>>
>>>>>> hi mark,
>>>>>>
>>>>>> thx for the heads-up. i just talked with shane about all those details.
>>>>>>
>>>>>> i don't see an issue with view-configs. codi just extracts the
>>>>>> @Secured annotation during the bootstrapping process in case of view-configs.
>>>> that
>>>>>> would be the "same" for such custom annotations meta-annotated with
>>>>>> @SecurityBindingType.
>>>>>>
>>>>>> what we need in case of intercepted beans:
>>>>>> 1) access to InvocationContext
>>>>>> 2) easy access to the information if a security check is on-going
>>>>>> 3) possibility to configure a default error-view (needed later on)
>>>>>> 4) possibility to provide a custom message + an integration with
>>>>>> the upcoming i18n module
>>>>>>
>>>>>> shane said that it should be possible to add all needed features.
>>>>>> (for
>>>> me
>>>>>> that means we need a prototype if the majority prefers custom
>>>>>> annotations.)
>>>>>>
>>>>>> in the end both approaches are similar. both are generic enough to
>>>>>> integrate 3rd party security frameworks.
>>>>>>
>>>>>> @SecurityBindingType is just more generic and users need an
>>>>>> additional step to find secured beans (/views) in a project.
>>>>>> furthermore, meta-data inheritance with the mentioned view-configs
>>>>>> is a bit harder for users.
>>>>>> imo it's just a matter of taste. custom annotations as additional
>>>>>> indirection vs. a specific annotation with inline information.
>>>>>>
>>>>>> with the approach provided by codi, users can't introduce a custom
>>>>>> annotation. however, i know a lot of users who prefer one given
>>>> annotation
>>>>>> instead of implementing x custom annotations. and i guess shane
>>>>>> knows a lot of users who prefer custom annotations. the goal of
>>>>>> codi was to make it easy, intuitive and flexible enough to
>>>>>> integrate 3rd party security-frameworks (instead of creating a new
>>>>>> security-framework). i wouldn't block the custom annotation
>>>>>> approach if 1)-4) are possible -
>>>> it's
>>>>>> a bit more flexible but also a bit more complex for users.
>>>>>>
>>>>> The beauty with the custom annotations is, if you like you can just
>>>> define
>>>>> a single annotation if you want and use that throughout your application.
>>>>>    I.e. you could similate the behavior of CODI:
>>>>>
>>>>>
>>>>> @SecurityBindingType
>>>>> @Retention(RetentionPolicy.**RUNTIME)
>>>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>>>>> Secured {
>>>>>    @Nonbinding Class[] voters() default {};
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
>>>>>>
>>>>>>    Gerhard, for explaining this you will probably need to also
>>>>>> explain the
>>>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
>>>>>>> annotations, you would loose lots of functionality in this area.
>>>>>>>
>>>>>>> I know that this is not the current topic, but discussing security
>>>>>>> mechanisms without discussing the stuff which needs to get secured
>>>>>>> is only half of the truth ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>>>>>>> JSFUsage-TypesafeViewConfig<
>>>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC
>>>> onfig
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
>>>> gerhard.petracek@gmail.com>
>>>>>>>> To: deltaspike-dev@incubator.**apache.org<
>>>> deltaspike-dev@incubator.apache.org>
>>>>>>>> Cc:
>>>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
>>>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>>>>>>>
>>>>>>>> in case of myfaces codi it's also used for secured view and it is
>>>>>>>> integrated with the default-error-view concept (as mentioned in
>>>>>>>> the
>>>>>>>>
>>>>>>> ticket
>>>>>>>
>>>>>>>> we will postpone this part).
>>>>>>>> furthermore it's used by codi-scopes to avoid a different
>>>>>>>> expiration behaviour of beans cause by a security check (see the
>>>>>>>> mentioned AccessDecisionVoterContext).
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
>>>> arne.limburg@openknowledge.de>
>>>>>>>>     Hi,
>>>>>>>>>    My first objection when I saw the CODI feature the first time,
>>>>>>>>> was
>>>>>>>>>
>>>>>>>> that it
>>>>>>>>    maybe is too basic: When I have to implement the Voter anyway
>>>>>>>> (or my
>>>>>>>>>    security-framework of choice delivers it), why should I use
>>>>>>>>> @Secured at
>>>>>>>>>    all? I mean, what is the REAL benefit of using @Secured over a
>>>> custom
>>>>>>>>>    annotation implemented by myself or delivered by my
>>>> security-framework
>>>>>>>> of
>>>>>>>>    choice.
>>>>>>>>>    The only benefit I see is when using different security
>>>>>>>>> sources, but
>>>>>>>>>
>>>>>>>> this
>>>>>>>>    is a rare use case imho.
>>>>>>>>>    Cheers,
>>>>>>>>>    Arne
>>>>>>>>>
>>>>>>>>>    -----Ursprüngliche Nachricht-----
>>>>>>>>>    Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
>>>> gerhard.petracek@gmail.com>
>>>>>>>>> ]
>>>>>>>>>    Gesendet: Dienstag, 31. Januar 2012 13:14
>>>>>>>>>    An: deltaspike-dev@incubator.**apache.org<
>>>> deltaspike-dev@incubator.apache.org>
>>>>>>>>>    Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>>>>>>>>
>>>>>>>>>    that's one option. a 2nd option is to use a
>>>> deltaspike-security-impl.
>>>>>>>>>    module which can provide e.g. an adapter for 3rd party
>>>>>>>>>
>>>>>>>> security-framework.
>>>>>>>>    or users just add a possible deltaspike-add-on provided by an
>>>> external
>>>>>>>>>    community e.g. by a security-framework itself.
>>>>>>>>>
>>>>>>>>>    regards,
>>>>>>>>>    gerhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    2012/1/31 John D. Ament<jo...@gmail.com>
>>>>>>>>>
>>>>>>>>>    >     Is it up to the developer to define the bean that implements an
>>>>>>>>>    interface?
>>>>>>>>>    >
>>>>>>>>>    >     On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
>>>>>>>>>    >     gerhard.petracek@gmail.com>     wrote:
>>>>>>>>>    >
>>>>>>>>>    >     >     hi @ all,
>>>>>>>>>    >     >
>>>>>>>>>    >     >     imo this feature of myfaces codi-core is a nice starting point
>>>>>>>>>
>>>>>>>> for
>>>>>>>>
>>>>>>>>>    >     >     the security-api discussion, because the basic idea behind it
>>>> is
>>>>>>>> a
>>>>>>>>
>>>>>>>>>    >     >     very thin integration layer (which can be used by other
>>>>>>>>> modules).
>>>>>>>>>    >     >
>>>>>>>>>    >     >     the basic concept:
>>>>>>>>>    >     >     a cdi interceptor invokes (inline) voters to secure the target
>>>>>>>>>    method/s.
>>>>>>>>>    >     >     a voter is a (custom) cdi bean which implements a specific
>>>>>>>>>
>>>>>>>> interface
>>>>>>>>
>>>>>>>>>    >     >     and therefore has access to the InvocationContext.
>>>>>>>>>    >     >     furthermore, a voter detects 0-n violations and>can<     be
>>>>>>>>>
>>>>>>>> used to
>>>>>>>>
>>>>>>>>>    >     integrate
>>>>>>>>>    >     >     3rd party security-frameworks.
>>>>>>>>>    >     >     [1] provides a bit more details of the basic concept as well
>>>> as
>>>>>>>> the
>>>>>>>>
>>>>>>>>>    >     >     basic usage of @Secured.
>>>>>>>>>    >     >
>>>>>>>>>    >     >     please send
>>>>>>>>>    >     >     +1, +0 or -1 because...
>>>>>>>>>    >     >     for the>basic concept<.
>>>>>>>>>    >     >
>>>>>>>>>    >     >     (please add>basic<     objections also to [2]. we can discuss
>>>>>>>>>
>>>>>>>> details e.g.
>>>>>>>>
>>>>>>>>>    >     >     further objections about the concrete implementation (e.g.
>>>>>>>>>
>>>>>>>> internal
>>>>>>>>
>>>>>>>>>    >     >     classes,...) as soon as we agreed on including this concept.)
>>>>>>>>>    >     >
>>>>>>>>>    >     >     regards,
>>>>>>>>>    >     >     gerhard
>>>>>>>>>    >     >
>>>>>>>>>    >     >     [1] https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>>>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
>>>>>>>>>    >     >     [2]
>>>>>>>>>    >     >
>>>>>>>>>    >
>>>>>>>>>
>>>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>>>>>>> SE+Feature+Rank<
>>>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran
>>>> k>
>>>>>>>>    >     ing
>>>>>>>>>    >     >
>>>>>>>>>    >
>>>>>>>>>
>>>>>>>>>
>>>
>
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Gerhard Petracek <ge...@gmail.com>.

hi @ all,

since the extended version of @Secured is also nice for codi, i'll improve
the corresponding parts of codi before importing the feature.
as soon as we have the additional features for @SecurityBindingType, i'll
start with the refactoring to build it on top of @SecurityBindingType.

mark started with the release-process for v0.1. since it's the first
release, we should wait with adding new parts until we know that the
approach with a release-branch works for us.

regards,
gerhard



2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>

> +1 for implementing both to see how it works out
> +1 for building @Secured on top of @SecurityBindingType
>
> Christian
>
>
> 2012/2/1 Jason Porter <li...@gmail.com>:
> > I'm going to put my vote in with Arne.
> >
> > +1 for @Secured implemented on top of @SecurityBindingType.
> >
> > On Wed, Feb 1, 2012 at 06:52, Arne Limburg <
> arne.limburg@openknowledge.de>wrote:
> >
> >> If we implement @Secured on top of @SecurityBindingType this could even
> be
> >> a permanent solution.
> >> So my +1 for that.
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >> Gesendet: Mittwoch, 1. Februar 2012 12:33
> >> An: deltaspike-dev@incubator.apache.org
> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>
> >> hi @ all,
> >>
> >> i talked with shane about further details of the current implementation.
> >>
> >> -> if we don't see an agreement this week:
> >> +1 for adding both (at least for now).
> >>
> >> we have to add features to >both< @Secured as well as
> @SecurityBindingType.
> >> maybe we will see that one of both is better as soon as we have the
> final
> >> implementation (and therefore all the details) and we can remove the
> other
> >> approach.
> >> if we see that both make sense, we just keep them.
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/2/1 Gerhard Petracek <ge...@gmail.com>
> >>
> >> > yes - that's possible as well.
> >> >
> >> > short addition - 3b allows:
> >> >
> >> > @TwoOf //introduced by the >user<
> >> > @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
> >> > AccessDecisionVoter3.class})
> >> >
> >> > (i wouldn't do it that way, because i wouldn't use a custom annotation
> >> > for such use-cases. however, users can decide it on their own.)
> >> >
> >> > regards,
> >> > gerhard
> >> >
> >> >
> >> >
> >> > 2012/2/1 Arne Limburg <ar...@openknowledge.de>
> >> >
> >> >> Basically we are discussing, if the access control logic goes into a
> >> >> class that implements an interface (which is AccessDecisionVoter) or
> >> >> into a method that is annotated with @Secures.
> >> >>
> >> >> Note that both approaches can be built with the other.
> >> >>
> >> >> I prefer the second way since it looks more like the CDI way.
> >> >>
> >> >> Another option is to provide both APIs. Then we only would have to
> >> >> decide which one is "core" and which one is based on the other.
> >> >>
> >> >> Cheers,
> >> >> Arne
> >> >>
> >> >> -----Ursprüngliche Nachricht-----
> >> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >> >> Gesendet: Mittwoch, 1. Februar 2012 08:54
> >> >> An: deltaspike-dev@incubator.apache.org
> >> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >> >>
> >> >> @christian: that's correct. but the advantage of using custom
> >> >> annotation arguments can't be used any more.
> >> >>
> >> >> and that's also one of my concerns - simple cases work (but also
> >> >> simple cases are more complex than the usage of @Secured) and such
> >> "advanced"
> >> >> use-cases are restricted.
> >> >>
> >> >> >in some cases it's worth to add more complexity, because it makes
> >> >> >sense
> >> >> for supporting advanced use-cases!<
> >> >> but right now i don't see it here.
> >> >>
> >> >> it would be possible to extend the approach of @Secured.
> >> >>
> >> >> examples:
> >> >>
> >> >> #1
> >> >>
> >> >> //...
> >> >> @Secured(MyAccessDecisionVoter.class)
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> users who prefer custom annotations can use stereotypes:
> >> >>
> >> >> #2
> >> >> //...
> >> >> @Admin
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(AdminAccessDecisionVoter.class)
> >> >> public @interface Admin
> >> >> {
> >> >> }
> >> >>
> >> >> #3
> >> >> //...
> >> >> //...
> >> >> @AdminOrUser
> >> >> public class SecuredBean
> >> >> {
> >> >>    //...
> >> >> }
> >> >>
> >> >> a)
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(oneOf = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class})
> >> >> // @Secured(allOf = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class})
> >> >> // ...
> >> >> public @interface AdminOrUser
> >> >> {
> >> >> }
> >> >>
> >> >> or
> >> >>
> >> >> b)
> >> >> //...
> >> >> @Stereotype
> >> >> //users could even provide a custom interceptor strategy and
> >> >> introduce custom versions of @OneOf or other annotations @OneOf
> >> >> @Secured({AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
> >> >>
> >> >> or
> >> >>
> >> >> c)
> >> >> //...
> >> >> @Stereotype
> >> >> @Secured(value = {AdminAccessDecisionVoter.class,
> >> >> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
> >> >> AdminOrUser { }
> >> >>
> >> >> regards,
> >> >> gerhard
> >> >>
> >> >>
> >> >>
> >> >> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
> >> >>
> >> >> > What about something like this:
> >> >> >
> >> >> >  public @interface AnyOf {
> >> >> >      Class<? extends Annotation>[] value();  }
> >> >> >
> >> >> > Usage:
> >> >> >
> >> >> >  @AnyOf({User.class, Admin.class})
> >> >> >  public void doSomething() {
> >> >> >       // something
> >> >> >  }
> >> >> >
> >> >> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
> >> >> > syntax. :)
> >> >> >
> >> >> > Christian
> >> >> >
> >> >> >
> >> >> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> >> >> > > Yes, that would work, but that annotation is not that nice. I
> >> >> > > would have
> >> >> > expected something like
> >> >> > > @AnyOf({@User, @Admin})
> >> >> > > which unfortunately is no valid Java syntax.
> >> >> > > Instead of that someone could write something like
> >> >> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like
> >> >> > > Shane suggests. Sadly enough there is no easy
> >> >> > way to provide a default @AnyOf annotation. So the users have to
> >> >> > write their own versions any time they need one.
> >> >> > >
> >> >> > > Any better ideas?
> >> >> > >
> >> >> > > Cheers,
> >> >> > > Arne
> >> >> > >
> >> >> > > -----Ursprüngliche Nachricht-----
> >> >> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> >> >> > > Gesendet: Dienstag, 31. Januar 2012 22:48
> >> >> > > An: deltaspike-dev@incubator.apache.org
> >> >> > > Cc: Jason Porter
> >> >> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >> >> > >
> >> >> > > I would approach the "or" use case by simply providing another
> >> >> > annotation:
> >> >> > >
> >> >> > > @SecurityBindingType
> >> >> > > @Retention(RetentionPolicy.**RUNTIME)
> >> >> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> >> >> > AdminOrUser {
> >> >> > >
> >> >> > > }
> >> >> > >
> >> >> > >
> >> >> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
> >> >> > >   return isAdmin() || isUser();
> >> >> > > }
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On 01/02/12 07:44, Jason Porter wrote:
> >> >> > >> Looks like I responded to the wrong thread as well.
> >> >> > >>
> >> >> > >> I personally like the binding approach a little better. It seems
> >> >> > >> to be more similar to the CDI way of doing interceptors (which,
> >> >> > >> at the end of the day is essentially what we're doing). However,
> >> >> > >> we have seen a need of doing @Admin || @User or @Admin&&  @User.
> >> >> > >> The and is fairly easy, but the or is currently not covered and
> >> >> > >> we need to be able to do
> >> >> > that.
> >> >> > >>
> >> >> > >> I'm pretty much at a +0 for both as well. As long as we have a
> >> >> > >> way of doing the feature I described above, I don't really care
> >> >> > >> which way we
> >> >> > go.
> >> >> > >>
> >> >> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> >> >> > >> <ge...@gmail.com>wrote:
> >> >> > >>
> >> >> > >>> hi shane,
> >> >> > >>>
> >> >> > >>> that's one of the reasons why i won't block it right now.
> >> >> > >>> if the majority prefers custom annotations, we should just
> >> >> > >>> introduce it
> >> >> > >>>> after<  v0.1 and prototype the missing parts (and test it with
> >> >> > >>>> the
> >> >> > >>> supported servers).
> >> >> > >>>
> >> >> > >>> my vote is +0 right now (for both).
> >> >> > >>>
> >> >> > >>> regards,
> >> >> > >>> gerhard
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
> >> >> > >>>
> >> >> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> >> >> > >>>>
> >> >> > >>>>> hi mark,
> >> >> > >>>>>
> >> >> > >>>>> thx for the heads-up. i just talked with shane about all
> >> >> > >>>>> those
> >> >> > details.
> >> >> > >>>>>
> >> >> > >>>>> i don't see an issue with view-configs. codi just extracts
> >> >> > >>>>> the @Secured annotation during the bootstrapping process in
> >> >> > >>>>> case of
> >> >> > view-configs.
> >> >> > >>> that
> >> >> > >>>>> would be the "same" for such custom annotations
> >> >> > >>>>> meta-annotated with @SecurityBindingType.
> >> >> > >>>>>
> >> >> > >>>>> what we need in case of intercepted beans:
> >> >> > >>>>> 1) access to InvocationContext
> >> >> > >>>>> 2) easy access to the information if a security check is
> >> >> > >>>>> on-going
> >> >> > >>>>> 3) possibility to configure a default error-view (needed
> >> >> > >>>>> later
> >> >> > >>>>> on)
> >> >> > >>>>> 4) possibility to provide a custom message + an integration
> >> >> > >>>>> with the upcoming i18n module
> >> >> > >>>>>
> >> >> > >>>>> shane said that it should be possible to add all needed
> >> features.
> >> >> > >>>>> (for
> >> >> > >>> me
> >> >> > >>>>> that means we need a prototype if the majority prefers custom
> >> >> > >>>>> annotations.)
> >> >> > >>>>>
> >> >> > >>>>> in the end both approaches are similar. both are generic
> >> >> > >>>>> enough to integrate 3rd party security frameworks.
> >> >> > >>>>>
> >> >> > >>>>> @SecurityBindingType is just more generic and users need an
> >> >> > >>>>> additional step to find secured beans (/views) in a project.
> >> >> > >>>>> furthermore, meta-data inheritance with the mentioned
> >> >> > >>>>> view-configs is a bit harder for users.
> >> >> > >>>>> imo it's just a matter of taste. custom annotations as
> >> >> > >>>>> additional indirection vs. a specific annotation with inline
> >> >> information.
> >> >> > >>>>>
> >> >> > >>>>> with the approach provided by codi, users can't introduce a
> >> >> > >>>>> custom annotation. however, i know a lot of users who prefer
> >> >> > >>>>> one given
> >> >> > >>> annotation
> >> >> > >>>>> instead of implementing x custom annotations. and i guess
> >> >> > >>>>> shane knows a lot of users who prefer custom annotations. the
> >> >> > >>>>> goal of codi was to make it easy, intuitive and flexible
> >> >> > >>>>> enough to integrate 3rd party security-frameworks (instead of
> >> >> > >>>>> creating a new security-framework). i wouldn't block the
> >> >> > >>>>> custom annotation approach if 1)-4) are possible -
> >> >> > >>> it's
> >> >> > >>>>> a bit more flexible but also a bit more complex for users.
> >> >> > >>>>>
> >> >> > >>>> The beauty with the custom annotations is, if you like you can
> >> >> > >>>> just
> >> >> > >>> define
> >> >> > >>>> a single annotation if you want and use that throughout your
> >> >> > application.
> >> >> > >>>>   I.e. you could similate the behavior of CODI:
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> @SecurityBindingType
> >> >> > >>>> @Retention(RetentionPolicy.**RUNTIME)
> >> >> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public
> >> >> > >>>> @interface Secured {
> >> >> > >>>>   @Nonbinding Class[] voters() default {};
> >> >> > >>>>
> >> >> > >>>> }
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>>> regards,
> >> >> > >>>>> gerhard
> >> >> > >>>>>
> >> >> > >>>>>
> >> >> > >>>>>
> >> >> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
> >> >> > >>>>>
> >> >> > >>>>>   Gerhard, for explaining this you will probably need to also
> >> >> > >>>>> explain the
> >> >> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using
> >> >> > >>>>>> custom annotations, you would loose lots of functionality in
> >> this area.
> >> >> > >>>>>>
> >> >> > >>>>>> I know that this is not the current topic, but discussing
> >> >> > >>>>>> security mechanisms without discussing the stuff which needs
> >> >> > >>>>>> to get secured is only half of the truth ;)
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> LieGrue,
> >> >> > >>>>>> strub
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> [1]
> >> >> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> >> >> > >>>>>> JSFUsage-TypesafeViewConfig<
> >> >> > >>>
> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-Typesaf
> >> >> > >>> eVi
> >> >> > >>> ewC
> >> >> > >>> onfig
> >> >> > >>>>>>
> >> >> > >>>>>>
> >> >> > >>>>>> ----- Original Message -----
> >> >> > >>>>>>
> >> >> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> >> >> > >>> gerhard.petracek@gmail.com>
> >> >> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> >> >> > >>> deltaspike-dev@incubator.apache.org>
> >> >> > >>>>>>> Cc:
> >> >> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
> >> >> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> >> >> > >>>>>>> @Secured
> >> >> > >>>>>>>
> >> >> > >>>>>>> in case of myfaces codi it's also used for secured view and
> >> >> > >>>>>>> it is integrated with the default-error-view concept (as
> >> >> > >>>>>>> mentioned in the
> >> >> > >>>>>>>
> >> >> > >>>>>> ticket
> >> >> > >>>>>>
> >> >> > >>>>>>> we will postpone this part).
> >> >> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
> >> >> > >>>>>>> expiration behaviour of beans cause by a security check
> >> >> > >>>>>>> (see the mentioned AccessDecisionVoterContext).
> >> >> > >>>>>>>
> >> >> > >>>>>>> regards,
> >> >> > >>>>>>> gerhard
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>>
> >> >> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> >> >> > >>> arne.limburg@openknowledge.de>
> >> >> > >>>>>>>    Hi,
> >> >> > >>>>>>>>   My first objection when I saw the CODI feature the first
> >> >> > >>>>>>>> time, was
> >> >> > >>>>>>>>
> >> >> > >>>>>>> that it
> >> >> > >>>>>>>   maybe is too basic: When I have to implement the Voter
> >> >> > >>>>>>> anyway (or my
> >> >> > >>>>>>>>   security-framework of choice delivers it), why should I
> >> >> > >>>>>>>> use @Secured at
> >> >> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
> >> >> > >>>>>>>> over a
> >> >> > >>> custom
> >> >> > >>>>>>>>   annotation implemented by myself or delivered by my
> >> >> > >>> security-framework
> >> >> > >>>>>>> of
> >> >> > >>>>>>>   choice.
> >> >> > >>>>>>>>   The only benefit I see is when using different security
> >> >> > >>>>>>>> sources, but
> >> >> > >>>>>>>>
> >> >> > >>>>>>> this
> >> >> > >>>>>>>   is a rare use case imho.
> >> >> > >>>>>>>>   Cheers,
> >> >> > >>>>>>>>   Arne
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   -----Ursprüngliche Nachricht-----
> >> >> > >>>>>>>>   Von: Gerhard Petracek
> >> >> > >>>>>>>> [mailto:gerhard.petracek@**gmail.com<
> >> >> > >>> gerhard.petracek@gmail.com>
> >> >> > >>>>>>>> ]
> >> >> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
> >> >> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> >> >> > >>> deltaspike-dev@incubator.apache.org>
> >> >> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> >> >> > >>>>>>>> @Secured
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   that's one option. a 2nd option is to use a
> >> >> > >>> deltaspike-security-impl.
> >> >> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
> >> >> > >>>>>>>>
> >> >> > >>>>>>> security-framework.
> >> >> > >>>>>>>   or users just add a possible deltaspike-add-on provided
> >> >> > >>>>>>> by an
> >> >> > >>> external
> >> >> > >>>>>>>>   community e.g. by a security-framework itself.
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   regards,
> >> >> > >>>>>>>>   gerhard
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>   >   Is it up to the developer to define the bean that
> >> >> > implements an
> >> >> > >>>>>>>>   interface?
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
> >> >> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>   >   >   hi @ all,
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
> >> >> > starting point
> >> >> > >>>>>>>>
> >> >> > >>>>>>> for
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   the security-api discussion, because the basic
> idea
> >> >> > behind it
> >> >> > >>> is
> >> >> > >>>>>>> a
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   very thin integration layer (which can be used
> by
> >> >> other
> >> >> > >>>>>>>> modules).
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   the basic concept:
> >> >> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to
> secure
> >> >> the
> >> >> > target
> >> >> > >>>>>>>>   method/s.
> >> >> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements
> a
> >> >> > specific
> >> >> > >>>>>>>>
> >> >> > >>>>>>> interface
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   and therefore has access to the
> InvocationContext.
> >> >> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations
> >> and>can<
> >> >> > be
> >> >> > >>>>>>>>
> >> >> > >>>>>>> used to
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   integrate
> >> >> > >>>>>>>>   >   >   3rd party security-frameworks.
> >> >> > >>>>>>>>   >   >   [1] provides a bit more details of the basic
> >> concept
> >> >> as
> >> >> > well
> >> >> > >>> as
> >> >> > >>>>>>> the
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   basic usage of @Secured.
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   please send
> >> >> > >>>>>>>>   >   >   +1, +0 or -1 because...
> >> >> > >>>>>>>>   >   >   for the>basic concept<.
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we
> can
> >> >> > discuss
> >> >> > >>>>>>>>
> >> >> > >>>>>>> details e.g.
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   further objections about the concrete
> >> implementation
> >> >> > (e.g.
> >> >> > >>>>>>>>
> >> >> > >>>>>>> internal
> >> >> > >>>>>>>
> >> >> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including
> this
> >> >> > concept.)
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   regards,
> >> >> > >>>>>>>>   >   >   gerhard
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >   >   [1]
> >> >> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> >> >> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> >> >> > >>>>>>>>   >   >   [2]
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>
> >> >> > >>>>>>>
> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >> >> > >>>>>> SE+Feature+Rank<
> >> >> > >>>
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Featu
> >> >> > >>> re+
> >> >> > >>> Ran
> >> >> > >>> k>
> >> >> > >>>>>>>   >   ing
> >> >> > >>>>>>>>   >   >
> >> >> > >>>>>>>>   >
> >> >> > >>>>>>>>
> >> >> > >>>>>>>>
> >> >> > >>
> >> >> > >>
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Christian Kaltepoth
> >> >> > Blog: http://chkal.blogspot.com/
> >> >> > Twitter: http://twitter.com/chkal
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Jason Porter
> > http://lightguard-jp.blogspot.com
> > http://twitter.com/lightguardjp
> >
> > Software Engineer
> > Open Source Advocate
> > Author of Seam Catch - Next Generation Java Exception Handling
> >
> > PGP key id: 926CCFF5
> > PGP key available at: keyserver.net, pgp.mit.edu
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Christian Kaltepoth <ch...@kaltepoth.de>.

+1 for implementing both to see how it works out
+1 for building @Secured on top of @SecurityBindingType

Christian


2012/2/1 Jason Porter <li...@gmail.com>:
> I'm going to put my vote in with Arne.
>
> +1 for @Secured implemented on top of @SecurityBindingType.
>
> On Wed, Feb 1, 2012 at 06:52, Arne Limburg <ar...@openknowledge.de>wrote:
>
>> If we implement @Secured on top of @SecurityBindingType this could even be
>> a permanent solution.
>> So my +1 for that.
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> Gesendet: Mittwoch, 1. Februar 2012 12:33
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>
>> hi @ all,
>>
>> i talked with shane about further details of the current implementation.
>>
>> -> if we don't see an agreement this week:
>> +1 for adding both (at least for now).
>>
>> we have to add features to >both< @Secured as well as @SecurityBindingType.
>> maybe we will see that one of both is better as soon as we have the final
>> implementation (and therefore all the details) and we can remove the other
>> approach.
>> if we see that both make sense, we just keep them.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/2/1 Gerhard Petracek <ge...@gmail.com>
>>
>> > yes - that's possible as well.
>> >
>> > short addition - 3b allows:
>> >
>> > @TwoOf //introduced by the >user<
>> > @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
>> > AccessDecisionVoter3.class})
>> >
>> > (i wouldn't do it that way, because i wouldn't use a custom annotation
>> > for such use-cases. however, users can decide it on their own.)
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2012/2/1 Arne Limburg <ar...@openknowledge.de>
>> >
>> >> Basically we are discussing, if the access control logic goes into a
>> >> class that implements an interface (which is AccessDecisionVoter) or
>> >> into a method that is annotated with @Secures.
>> >>
>> >> Note that both approaches can be built with the other.
>> >>
>> >> I prefer the second way since it looks more like the CDI way.
>> >>
>> >> Another option is to provide both APIs. Then we only would have to
>> >> decide which one is "core" and which one is based on the other.
>> >>
>> >> Cheers,
>> >> Arne
>> >>
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> >> Gesendet: Mittwoch, 1. Februar 2012 08:54
>> >> An: deltaspike-dev@incubator.apache.org
>> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>> >>
>> >> @christian: that's correct. but the advantage of using custom
>> >> annotation arguments can't be used any more.
>> >>
>> >> and that's also one of my concerns - simple cases work (but also
>> >> simple cases are more complex than the usage of @Secured) and such
>> "advanced"
>> >> use-cases are restricted.
>> >>
>> >> >in some cases it's worth to add more complexity, because it makes
>> >> >sense
>> >> for supporting advanced use-cases!<
>> >> but right now i don't see it here.
>> >>
>> >> it would be possible to extend the approach of @Secured.
>> >>
>> >> examples:
>> >>
>> >> #1
>> >>
>> >> //...
>> >> @Secured(MyAccessDecisionVoter.class)
>> >> public class SecuredBean
>> >> {
>> >>    //...
>> >> }
>> >>
>> >> users who prefer custom annotations can use stereotypes:
>> >>
>> >> #2
>> >> //...
>> >> @Admin
>> >> public class SecuredBean
>> >> {
>> >>    //...
>> >> }
>> >>
>> >> //...
>> >> @Stereotype
>> >> @Secured(AdminAccessDecisionVoter.class)
>> >> public @interface Admin
>> >> {
>> >> }
>> >>
>> >> #3
>> >> //...
>> >> //...
>> >> @AdminOrUser
>> >> public class SecuredBean
>> >> {
>> >>    //...
>> >> }
>> >>
>> >> a)
>> >> //...
>> >> @Stereotype
>> >> @Secured(oneOf = {AdminAccessDecisionVoter.class,
>> >> UserAccessDecisionVoter.class})
>> >> // @Secured(allOf = {AdminAccessDecisionVoter.class,
>> >> UserAccessDecisionVoter.class})
>> >> // ...
>> >> public @interface AdminOrUser
>> >> {
>> >> }
>> >>
>> >> or
>> >>
>> >> b)
>> >> //...
>> >> @Stereotype
>> >> //users could even provide a custom interceptor strategy and
>> >> introduce custom versions of @OneOf or other annotations @OneOf
>> >> @Secured({AdminAccessDecisionVoter.class,
>> >> UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
>> >>
>> >> or
>> >>
>> >> c)
>> >> //...
>> >> @Stereotype
>> >> @Secured(value = {AdminAccessDecisionVoter.class,
>> >> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
>> >> AdminOrUser { }
>> >>
>> >> regards,
>> >> gerhard
>> >>
>> >>
>> >>
>> >> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
>> >>
>> >> > What about something like this:
>> >> >
>> >> >  public @interface AnyOf {
>> >> >      Class<? extends Annotation>[] value();  }
>> >> >
>> >> > Usage:
>> >> >
>> >> >  @AnyOf({User.class, Admin.class})
>> >> >  public void doSomething() {
>> >> >       // something
>> >> >  }
>> >> >
>> >> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
>> >> > syntax. :)
>> >> >
>> >> > Christian
>> >> >
>> >> >
>> >> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
>> >> > > Yes, that would work, but that annotation is not that nice. I
>> >> > > would have
>> >> > expected something like
>> >> > > @AnyOf({@User, @Admin})
>> >> > > which unfortunately is no valid Java syntax.
>> >> > > Instead of that someone could write something like
>> >> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like
>> >> > > Shane suggests. Sadly enough there is no easy
>> >> > way to provide a default @AnyOf annotation. So the users have to
>> >> > write their own versions any time they need one.
>> >> > >
>> >> > > Any better ideas?
>> >> > >
>> >> > > Cheers,
>> >> > > Arne
>> >> > >
>> >> > > -----Ursprüngliche Nachricht-----
>> >> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>> >> > > Gesendet: Dienstag, 31. Januar 2012 22:48
>> >> > > An: deltaspike-dev@incubator.apache.org
>> >> > > Cc: Jason Porter
>> >> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>> >> > >
>> >> > > I would approach the "or" use case by simply providing another
>> >> > annotation:
>> >> > >
>> >> > > @SecurityBindingType
>> >> > > @Retention(RetentionPolicy.**RUNTIME)
>> >> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>> >> > AdminOrUser {
>> >> > >
>> >> > > }
>> >> > >
>> >> > >
>> >> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
>> >> > >   return isAdmin() || isUser();
>> >> > > }
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > On 01/02/12 07:44, Jason Porter wrote:
>> >> > >> Looks like I responded to the wrong thread as well.
>> >> > >>
>> >> > >> I personally like the binding approach a little better. It seems
>> >> > >> to be more similar to the CDI way of doing interceptors (which,
>> >> > >> at the end of the day is essentially what we're doing). However,
>> >> > >> we have seen a need of doing @Admin || @User or @Admin&&  @User.
>> >> > >> The and is fairly easy, but the or is currently not covered and
>> >> > >> we need to be able to do
>> >> > that.
>> >> > >>
>> >> > >> I'm pretty much at a +0 for both as well. As long as we have a
>> >> > >> way of doing the feature I described above, I don't really care
>> >> > >> which way we
>> >> > go.
>> >> > >>
>> >> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>> >> > >> <ge...@gmail.com>wrote:
>> >> > >>
>> >> > >>> hi shane,
>> >> > >>>
>> >> > >>> that's one of the reasons why i won't block it right now.
>> >> > >>> if the majority prefers custom annotations, we should just
>> >> > >>> introduce it
>> >> > >>>> after<  v0.1 and prototype the missing parts (and test it with
>> >> > >>>> the
>> >> > >>> supported servers).
>> >> > >>>
>> >> > >>> my vote is +0 right now (for both).
>> >> > >>>
>> >> > >>> regards,
>> >> > >>> gerhard
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
>> >> > >>>
>> >> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
>> >> > >>>>
>> >> > >>>>> hi mark,
>> >> > >>>>>
>> >> > >>>>> thx for the heads-up. i just talked with shane about all
>> >> > >>>>> those
>> >> > details.
>> >> > >>>>>
>> >> > >>>>> i don't see an issue with view-configs. codi just extracts
>> >> > >>>>> the @Secured annotation during the bootstrapping process in
>> >> > >>>>> case of
>> >> > view-configs.
>> >> > >>> that
>> >> > >>>>> would be the "same" for such custom annotations
>> >> > >>>>> meta-annotated with @SecurityBindingType.
>> >> > >>>>>
>> >> > >>>>> what we need in case of intercepted beans:
>> >> > >>>>> 1) access to InvocationContext
>> >> > >>>>> 2) easy access to the information if a security check is
>> >> > >>>>> on-going
>> >> > >>>>> 3) possibility to configure a default error-view (needed
>> >> > >>>>> later
>> >> > >>>>> on)
>> >> > >>>>> 4) possibility to provide a custom message + an integration
>> >> > >>>>> with the upcoming i18n module
>> >> > >>>>>
>> >> > >>>>> shane said that it should be possible to add all needed
>> features.
>> >> > >>>>> (for
>> >> > >>> me
>> >> > >>>>> that means we need a prototype if the majority prefers custom
>> >> > >>>>> annotations.)
>> >> > >>>>>
>> >> > >>>>> in the end both approaches are similar. both are generic
>> >> > >>>>> enough to integrate 3rd party security frameworks.
>> >> > >>>>>
>> >> > >>>>> @SecurityBindingType is just more generic and users need an
>> >> > >>>>> additional step to find secured beans (/views) in a project.
>> >> > >>>>> furthermore, meta-data inheritance with the mentioned
>> >> > >>>>> view-configs is a bit harder for users.
>> >> > >>>>> imo it's just a matter of taste. custom annotations as
>> >> > >>>>> additional indirection vs. a specific annotation with inline
>> >> information.
>> >> > >>>>>
>> >> > >>>>> with the approach provided by codi, users can't introduce a
>> >> > >>>>> custom annotation. however, i know a lot of users who prefer
>> >> > >>>>> one given
>> >> > >>> annotation
>> >> > >>>>> instead of implementing x custom annotations. and i guess
>> >> > >>>>> shane knows a lot of users who prefer custom annotations. the
>> >> > >>>>> goal of codi was to make it easy, intuitive and flexible
>> >> > >>>>> enough to integrate 3rd party security-frameworks (instead of
>> >> > >>>>> creating a new security-framework). i wouldn't block the
>> >> > >>>>> custom annotation approach if 1)-4) are possible -
>> >> > >>> it's
>> >> > >>>>> a bit more flexible but also a bit more complex for users.
>> >> > >>>>>
>> >> > >>>> The beauty with the custom annotations is, if you like you can
>> >> > >>>> just
>> >> > >>> define
>> >> > >>>> a single annotation if you want and use that throughout your
>> >> > application.
>> >> > >>>>   I.e. you could similate the behavior of CODI:
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> @SecurityBindingType
>> >> > >>>> @Retention(RetentionPolicy.**RUNTIME)
>> >> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public
>> >> > >>>> @interface Secured {
>> >> > >>>>   @Nonbinding Class[] voters() default {};
>> >> > >>>>
>> >> > >>>> }
>> >> > >>>>
>> >> > >>>>
>> >> > >>>>> regards,
>> >> > >>>>> gerhard
>> >> > >>>>>
>> >> > >>>>>
>> >> > >>>>>
>> >> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
>> >> > >>>>>
>> >> > >>>>>   Gerhard, for explaining this you will probably need to also
>> >> > >>>>> explain the
>> >> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using
>> >> > >>>>>> custom annotations, you would loose lots of functionality in
>> this area.
>> >> > >>>>>>
>> >> > >>>>>> I know that this is not the current topic, but discussing
>> >> > >>>>>> security mechanisms without discussing the stuff which needs
>> >> > >>>>>> to get secured is only half of the truth ;)
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> LieGrue,
>> >> > >>>>>> strub
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> [1]
>> >> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>> >> > >>>>>> JSFUsage-TypesafeViewConfig<
>> >> > >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-Typesaf
>> >> > >>> eVi
>> >> > >>> ewC
>> >> > >>> onfig
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> ----- Original Message -----
>> >> > >>>>>>
>> >> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
>> >> > >>> gerhard.petracek@gmail.com>
>> >> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
>> >> > >>> deltaspike-dev@incubator.apache.org>
>> >> > >>>>>>> Cc:
>> >> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
>> >> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
>> >> > >>>>>>> @Secured
>> >> > >>>>>>>
>> >> > >>>>>>> in case of myfaces codi it's also used for secured view and
>> >> > >>>>>>> it is integrated with the default-error-view concept (as
>> >> > >>>>>>> mentioned in the
>> >> > >>>>>>>
>> >> > >>>>>> ticket
>> >> > >>>>>>
>> >> > >>>>>>> we will postpone this part).
>> >> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
>> >> > >>>>>>> expiration behaviour of beans cause by a security check
>> >> > >>>>>>> (see the mentioned AccessDecisionVoterContext).
>> >> > >>>>>>>
>> >> > >>>>>>> regards,
>> >> > >>>>>>> gerhard
>> >> > >>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
>> >> > >>> arne.limburg@openknowledge.de>
>> >> > >>>>>>>    Hi,
>> >> > >>>>>>>>   My first objection when I saw the CODI feature the first
>> >> > >>>>>>>> time, was
>> >> > >>>>>>>>
>> >> > >>>>>>> that it
>> >> > >>>>>>>   maybe is too basic: When I have to implement the Voter
>> >> > >>>>>>> anyway (or my
>> >> > >>>>>>>>   security-framework of choice delivers it), why should I
>> >> > >>>>>>>> use @Secured at
>> >> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
>> >> > >>>>>>>> over a
>> >> > >>> custom
>> >> > >>>>>>>>   annotation implemented by myself or delivered by my
>> >> > >>> security-framework
>> >> > >>>>>>> of
>> >> > >>>>>>>   choice.
>> >> > >>>>>>>>   The only benefit I see is when using different security
>> >> > >>>>>>>> sources, but
>> >> > >>>>>>>>
>> >> > >>>>>>> this
>> >> > >>>>>>>   is a rare use case imho.
>> >> > >>>>>>>>   Cheers,
>> >> > >>>>>>>>   Arne
>> >> > >>>>>>>>
>> >> > >>>>>>>>   -----Ursprüngliche Nachricht-----
>> >> > >>>>>>>>   Von: Gerhard Petracek
>> >> > >>>>>>>> [mailto:gerhard.petracek@**gmail.com<
>> >> > >>> gerhard.petracek@gmail.com>
>> >> > >>>>>>>> ]
>> >> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
>> >> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
>> >> > >>> deltaspike-dev@incubator.apache.org>
>> >> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
>> >> > >>>>>>>> @Secured
>> >> > >>>>>>>>
>> >> > >>>>>>>>   that's one option. a 2nd option is to use a
>> >> > >>> deltaspike-security-impl.
>> >> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
>> >> > >>>>>>>>
>> >> > >>>>>>> security-framework.
>> >> > >>>>>>>   or users just add a possible deltaspike-add-on provided
>> >> > >>>>>>> by an
>> >> > >>> external
>> >> > >>>>>>>>   community e.g. by a security-framework itself.
>> >> > >>>>>>>>
>> >> > >>>>>>>>   regards,
>> >> > >>>>>>>>   gerhard
>> >> > >>>>>>>>
>> >> > >>>>>>>>
>> >> > >>>>>>>>
>> >> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
>> >> > >>>>>>>>
>> >> > >>>>>>>>   >   Is it up to the developer to define the bean that
>> >> > implements an
>> >> > >>>>>>>>   interface?
>> >> > >>>>>>>>   >
>> >> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
>> >> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
>> >> > >>>>>>>>   >
>> >> > >>>>>>>>   >   >   hi @ all,
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
>> >> > starting point
>> >> > >>>>>>>>
>> >> > >>>>>>> for
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   the security-api discussion, because the basic idea
>> >> > behind it
>> >> > >>> is
>> >> > >>>>>>> a
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   very thin integration layer (which can be used by
>> >> other
>> >> > >>>>>>>> modules).
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   the basic concept:
>> >> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure
>> >> the
>> >> > target
>> >> > >>>>>>>>   method/s.
>> >> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
>> >> > specific
>> >> > >>>>>>>>
>> >> > >>>>>>> interface
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   and therefore has access to the InvocationContext.
>> >> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations
>> and>can<
>> >> > be
>> >> > >>>>>>>>
>> >> > >>>>>>> used to
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   integrate
>> >> > >>>>>>>>   >   >   3rd party security-frameworks.
>> >> > >>>>>>>>   >   >   [1] provides a bit more details of the basic
>> concept
>> >> as
>> >> > well
>> >> > >>> as
>> >> > >>>>>>> the
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   basic usage of @Secured.
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   please send
>> >> > >>>>>>>>   >   >   +1, +0 or -1 because...
>> >> > >>>>>>>>   >   >   for the>basic concept<.
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
>> >> > discuss
>> >> > >>>>>>>>
>> >> > >>>>>>> details e.g.
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   further objections about the concrete
>> implementation
>> >> > (e.g.
>> >> > >>>>>>>>
>> >> > >>>>>>> internal
>> >> > >>>>>>>
>> >> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
>> >> > concept.)
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   regards,
>> >> > >>>>>>>>   >   >   gerhard
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >   >   [1]
>> >> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>> >> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
>> >> > >>>>>>>>   >   >   [2]
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >
>> >> > >>>>>>>>
>> >> > >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>> >> > >>>>>> SE+Feature+Rank<
>> >> > >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Featu
>> >> > >>> re+
>> >> > >>> Ran
>> >> > >>> k>
>> >> > >>>>>>>   >   ing
>> >> > >>>>>>>>   >   >
>> >> > >>>>>>>>   >
>> >> > >>>>>>>>
>> >> > >>>>>>>>
>> >> > >>
>> >> > >>
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Christian Kaltepoth
>> >> > Blog: http://chkal.blogspot.com/
>> >> > Twitter: http://twitter.com/chkal
>> >> >
>> >>
>> >
>> >
>>
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu



-- 
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Jason Porter <li...@gmail.com>.

I'm going to put my vote in with Arne.

+1 for @Secured implemented on top of @SecurityBindingType.

On Wed, Feb 1, 2012 at 06:52, Arne Limburg <ar...@openknowledge.de>wrote:

> If we implement @Secured on top of @SecurityBindingType this could even be
> a permanent solution.
> So my +1 for that.
>
> -----Ursprüngliche Nachricht-----
> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> Gesendet: Mittwoch, 1. Februar 2012 12:33
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>
> hi @ all,
>
> i talked with shane about further details of the current implementation.
>
> -> if we don't see an agreement this week:
> +1 for adding both (at least for now).
>
> we have to add features to >both< @Secured as well as @SecurityBindingType.
> maybe we will see that one of both is better as soon as we have the final
> implementation (and therefore all the details) and we can remove the other
> approach.
> if we see that both make sense, we just keep them.
>
> regards,
> gerhard
>
>
>
> 2012/2/1 Gerhard Petracek <ge...@gmail.com>
>
> > yes - that's possible as well.
> >
> > short addition - 3b allows:
> >
> > @TwoOf //introduced by the >user<
> > @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
> > AccessDecisionVoter3.class})
> >
> > (i wouldn't do it that way, because i wouldn't use a custom annotation
> > for such use-cases. however, users can decide it on their own.)
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2012/2/1 Arne Limburg <ar...@openknowledge.de>
> >
> >> Basically we are discussing, if the access control logic goes into a
> >> class that implements an interface (which is AccessDecisionVoter) or
> >> into a method that is annotated with @Secures.
> >>
> >> Note that both approaches can be built with the other.
> >>
> >> I prefer the second way since it looks more like the CDI way.
> >>
> >> Another option is to provide both APIs. Then we only would have to
> >> decide which one is "core" and which one is based on the other.
> >>
> >> Cheers,
> >> Arne
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> >> Gesendet: Mittwoch, 1. Februar 2012 08:54
> >> An: deltaspike-dev@incubator.apache.org
> >> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>
> >> @christian: that's correct. but the advantage of using custom
> >> annotation arguments can't be used any more.
> >>
> >> and that's also one of my concerns - simple cases work (but also
> >> simple cases are more complex than the usage of @Secured) and such
> "advanced"
> >> use-cases are restricted.
> >>
> >> >in some cases it's worth to add more complexity, because it makes
> >> >sense
> >> for supporting advanced use-cases!<
> >> but right now i don't see it here.
> >>
> >> it would be possible to extend the approach of @Secured.
> >>
> >> examples:
> >>
> >> #1
> >>
> >> //...
> >> @Secured(MyAccessDecisionVoter.class)
> >> public class SecuredBean
> >> {
> >>    //...
> >> }
> >>
> >> users who prefer custom annotations can use stereotypes:
> >>
> >> #2
> >> //...
> >> @Admin
> >> public class SecuredBean
> >> {
> >>    //...
> >> }
> >>
> >> //...
> >> @Stereotype
> >> @Secured(AdminAccessDecisionVoter.class)
> >> public @interface Admin
> >> {
> >> }
> >>
> >> #3
> >> //...
> >> //...
> >> @AdminOrUser
> >> public class SecuredBean
> >> {
> >>    //...
> >> }
> >>
> >> a)
> >> //...
> >> @Stereotype
> >> @Secured(oneOf = {AdminAccessDecisionVoter.class,
> >> UserAccessDecisionVoter.class})
> >> // @Secured(allOf = {AdminAccessDecisionVoter.class,
> >> UserAccessDecisionVoter.class})
> >> // ...
> >> public @interface AdminOrUser
> >> {
> >> }
> >>
> >> or
> >>
> >> b)
> >> //...
> >> @Stereotype
> >> //users could even provide a custom interceptor strategy and
> >> introduce custom versions of @OneOf or other annotations @OneOf
> >> @Secured({AdminAccessDecisionVoter.class,
> >> UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
> >>
> >> or
> >>
> >> c)
> >> //...
> >> @Stereotype
> >> @Secured(value = {AdminAccessDecisionVoter.class,
> >> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
> >> AdminOrUser { }
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
> >>
> >> > What about something like this:
> >> >
> >> >  public @interface AnyOf {
> >> >      Class<? extends Annotation>[] value();  }
> >> >
> >> > Usage:
> >> >
> >> >  @AnyOf({User.class, Admin.class})
> >> >  public void doSomething() {
> >> >       // something
> >> >  }
> >> >
> >> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
> >> > syntax. :)
> >> >
> >> > Christian
> >> >
> >> >
> >> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> >> > > Yes, that would work, but that annotation is not that nice. I
> >> > > would have
> >> > expected something like
> >> > > @AnyOf({@User, @Admin})
> >> > > which unfortunately is no valid Java syntax.
> >> > > Instead of that someone could write something like
> >> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like
> >> > > Shane suggests. Sadly enough there is no easy
> >> > way to provide a default @AnyOf annotation. So the users have to
> >> > write their own versions any time they need one.
> >> > >
> >> > > Any better ideas?
> >> > >
> >> > > Cheers,
> >> > > Arne
> >> > >
> >> > > -----Ursprüngliche Nachricht-----
> >> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> >> > > Gesendet: Dienstag, 31. Januar 2012 22:48
> >> > > An: deltaspike-dev@incubator.apache.org
> >> > > Cc: Jason Porter
> >> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >> > >
> >> > > I would approach the "or" use case by simply providing another
> >> > annotation:
> >> > >
> >> > > @SecurityBindingType
> >> > > @Retention(RetentionPolicy.**RUNTIME)
> >> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> >> > AdminOrUser {
> >> > >
> >> > > }
> >> > >
> >> > >
> >> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
> >> > >   return isAdmin() || isUser();
> >> > > }
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On 01/02/12 07:44, Jason Porter wrote:
> >> > >> Looks like I responded to the wrong thread as well.
> >> > >>
> >> > >> I personally like the binding approach a little better. It seems
> >> > >> to be more similar to the CDI way of doing interceptors (which,
> >> > >> at the end of the day is essentially what we're doing). However,
> >> > >> we have seen a need of doing @Admin || @User or @Admin&&  @User.
> >> > >> The and is fairly easy, but the or is currently not covered and
> >> > >> we need to be able to do
> >> > that.
> >> > >>
> >> > >> I'm pretty much at a +0 for both as well. As long as we have a
> >> > >> way of doing the feature I described above, I don't really care
> >> > >> which way we
> >> > go.
> >> > >>
> >> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> >> > >> <ge...@gmail.com>wrote:
> >> > >>
> >> > >>> hi shane,
> >> > >>>
> >> > >>> that's one of the reasons why i won't block it right now.
> >> > >>> if the majority prefers custom annotations, we should just
> >> > >>> introduce it
> >> > >>>> after<  v0.1 and prototype the missing parts (and test it with
> >> > >>>> the
> >> > >>> supported servers).
> >> > >>>
> >> > >>> my vote is +0 right now (for both).
> >> > >>>
> >> > >>> regards,
> >> > >>> gerhard
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
> >> > >>>
> >> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> >> > >>>>
> >> > >>>>> hi mark,
> >> > >>>>>
> >> > >>>>> thx for the heads-up. i just talked with shane about all
> >> > >>>>> those
> >> > details.
> >> > >>>>>
> >> > >>>>> i don't see an issue with view-configs. codi just extracts
> >> > >>>>> the @Secured annotation during the bootstrapping process in
> >> > >>>>> case of
> >> > view-configs.
> >> > >>> that
> >> > >>>>> would be the "same" for such custom annotations
> >> > >>>>> meta-annotated with @SecurityBindingType.
> >> > >>>>>
> >> > >>>>> what we need in case of intercepted beans:
> >> > >>>>> 1) access to InvocationContext
> >> > >>>>> 2) easy access to the information if a security check is
> >> > >>>>> on-going
> >> > >>>>> 3) possibility to configure a default error-view (needed
> >> > >>>>> later
> >> > >>>>> on)
> >> > >>>>> 4) possibility to provide a custom message + an integration
> >> > >>>>> with the upcoming i18n module
> >> > >>>>>
> >> > >>>>> shane said that it should be possible to add all needed
> features.
> >> > >>>>> (for
> >> > >>> me
> >> > >>>>> that means we need a prototype if the majority prefers custom
> >> > >>>>> annotations.)
> >> > >>>>>
> >> > >>>>> in the end both approaches are similar. both are generic
> >> > >>>>> enough to integrate 3rd party security frameworks.
> >> > >>>>>
> >> > >>>>> @SecurityBindingType is just more generic and users need an
> >> > >>>>> additional step to find secured beans (/views) in a project.
> >> > >>>>> furthermore, meta-data inheritance with the mentioned
> >> > >>>>> view-configs is a bit harder for users.
> >> > >>>>> imo it's just a matter of taste. custom annotations as
> >> > >>>>> additional indirection vs. a specific annotation with inline
> >> information.
> >> > >>>>>
> >> > >>>>> with the approach provided by codi, users can't introduce a
> >> > >>>>> custom annotation. however, i know a lot of users who prefer
> >> > >>>>> one given
> >> > >>> annotation
> >> > >>>>> instead of implementing x custom annotations. and i guess
> >> > >>>>> shane knows a lot of users who prefer custom annotations. the
> >> > >>>>> goal of codi was to make it easy, intuitive and flexible
> >> > >>>>> enough to integrate 3rd party security-frameworks (instead of
> >> > >>>>> creating a new security-framework). i wouldn't block the
> >> > >>>>> custom annotation approach if 1)-4) are possible -
> >> > >>> it's
> >> > >>>>> a bit more flexible but also a bit more complex for users.
> >> > >>>>>
> >> > >>>> The beauty with the custom annotations is, if you like you can
> >> > >>>> just
> >> > >>> define
> >> > >>>> a single annotation if you want and use that throughout your
> >> > application.
> >> > >>>>   I.e. you could similate the behavior of CODI:
> >> > >>>>
> >> > >>>>
> >> > >>>> @SecurityBindingType
> >> > >>>> @Retention(RetentionPolicy.**RUNTIME)
> >> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public
> >> > >>>> @interface Secured {
> >> > >>>>   @Nonbinding Class[] voters() default {};
> >> > >>>>
> >> > >>>> }
> >> > >>>>
> >> > >>>>
> >> > >>>>> regards,
> >> > >>>>> gerhard
> >> > >>>>>
> >> > >>>>>
> >> > >>>>>
> >> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
> >> > >>>>>
> >> > >>>>>   Gerhard, for explaining this you will probably need to also
> >> > >>>>> explain the
> >> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using
> >> > >>>>>> custom annotations, you would loose lots of functionality in
> this area.
> >> > >>>>>>
> >> > >>>>>> I know that this is not the current topic, but discussing
> >> > >>>>>> security mechanisms without discussing the stuff which needs
> >> > >>>>>> to get secured is only half of the truth ;)
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>> LieGrue,
> >> > >>>>>> strub
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>> [1]
> >> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> >> > >>>>>> JSFUsage-TypesafeViewConfig<
> >> > >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-Typesaf
> >> > >>> eVi
> >> > >>> ewC
> >> > >>> onfig
> >> > >>>>>>
> >> > >>>>>>
> >> > >>>>>> ----- Original Message -----
> >> > >>>>>>
> >> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> >> > >>> gerhard.petracek@gmail.com>
> >> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> >> > >>> deltaspike-dev@incubator.apache.org>
> >> > >>>>>>> Cc:
> >> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
> >> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> >> > >>>>>>> @Secured
> >> > >>>>>>>
> >> > >>>>>>> in case of myfaces codi it's also used for secured view and
> >> > >>>>>>> it is integrated with the default-error-view concept (as
> >> > >>>>>>> mentioned in the
> >> > >>>>>>>
> >> > >>>>>> ticket
> >> > >>>>>>
> >> > >>>>>>> we will postpone this part).
> >> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
> >> > >>>>>>> expiration behaviour of beans cause by a security check
> >> > >>>>>>> (see the mentioned AccessDecisionVoterContext).
> >> > >>>>>>>
> >> > >>>>>>> regards,
> >> > >>>>>>> gerhard
> >> > >>>>>>>
> >> > >>>>>>>
> >> > >>>>>>>
> >> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> >> > >>> arne.limburg@openknowledge.de>
> >> > >>>>>>>    Hi,
> >> > >>>>>>>>   My first objection when I saw the CODI feature the first
> >> > >>>>>>>> time, was
> >> > >>>>>>>>
> >> > >>>>>>> that it
> >> > >>>>>>>   maybe is too basic: When I have to implement the Voter
> >> > >>>>>>> anyway (or my
> >> > >>>>>>>>   security-framework of choice delivers it), why should I
> >> > >>>>>>>> use @Secured at
> >> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
> >> > >>>>>>>> over a
> >> > >>> custom
> >> > >>>>>>>>   annotation implemented by myself or delivered by my
> >> > >>> security-framework
> >> > >>>>>>> of
> >> > >>>>>>>   choice.
> >> > >>>>>>>>   The only benefit I see is when using different security
> >> > >>>>>>>> sources, but
> >> > >>>>>>>>
> >> > >>>>>>> this
> >> > >>>>>>>   is a rare use case imho.
> >> > >>>>>>>>   Cheers,
> >> > >>>>>>>>   Arne
> >> > >>>>>>>>
> >> > >>>>>>>>   -----Ursprüngliche Nachricht-----
> >> > >>>>>>>>   Von: Gerhard Petracek
> >> > >>>>>>>> [mailto:gerhard.petracek@**gmail.com<
> >> > >>> gerhard.petracek@gmail.com>
> >> > >>>>>>>> ]
> >> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
> >> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> >> > >>> deltaspike-dev@incubator.apache.org>
> >> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> >> > >>>>>>>> @Secured
> >> > >>>>>>>>
> >> > >>>>>>>>   that's one option. a 2nd option is to use a
> >> > >>> deltaspike-security-impl.
> >> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
> >> > >>>>>>>>
> >> > >>>>>>> security-framework.
> >> > >>>>>>>   or users just add a possible deltaspike-add-on provided
> >> > >>>>>>> by an
> >> > >>> external
> >> > >>>>>>>>   community e.g. by a security-framework itself.
> >> > >>>>>>>>
> >> > >>>>>>>>   regards,
> >> > >>>>>>>>   gerhard
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
> >> > >>>>>>>>
> >> > >>>>>>>>   >   Is it up to the developer to define the bean that
> >> > implements an
> >> > >>>>>>>>   interface?
> >> > >>>>>>>>   >
> >> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
> >> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
> >> > >>>>>>>>   >
> >> > >>>>>>>>   >   >   hi @ all,
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
> >> > starting point
> >> > >>>>>>>>
> >> > >>>>>>> for
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   the security-api discussion, because the basic idea
> >> > behind it
> >> > >>> is
> >> > >>>>>>> a
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   very thin integration layer (which can be used by
> >> other
> >> > >>>>>>>> modules).
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   the basic concept:
> >> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure
> >> the
> >> > target
> >> > >>>>>>>>   method/s.
> >> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
> >> > specific
> >> > >>>>>>>>
> >> > >>>>>>> interface
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   and therefore has access to the InvocationContext.
> >> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations
> and>can<
> >> > be
> >> > >>>>>>>>
> >> > >>>>>>> used to
> >> > >>>>>>>
> >> > >>>>>>>>   >   integrate
> >> > >>>>>>>>   >   >   3rd party security-frameworks.
> >> > >>>>>>>>   >   >   [1] provides a bit more details of the basic
> concept
> >> as
> >> > well
> >> > >>> as
> >> > >>>>>>> the
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   basic usage of @Secured.
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   please send
> >> > >>>>>>>>   >   >   +1, +0 or -1 because...
> >> > >>>>>>>>   >   >   for the>basic concept<.
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
> >> > discuss
> >> > >>>>>>>>
> >> > >>>>>>> details e.g.
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   further objections about the concrete
> implementation
> >> > (e.g.
> >> > >>>>>>>>
> >> > >>>>>>> internal
> >> > >>>>>>>
> >> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
> >> > concept.)
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   regards,
> >> > >>>>>>>>   >   >   gerhard
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >   >   [1]
> >> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> >> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> >> > >>>>>>>>   >   >   [2]
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >
> >> > >>>>>>>>
> >> > >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >> > >>>>>> SE+Feature+Rank<
> >> > >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Featu
> >> > >>> re+
> >> > >>> Ran
> >> > >>> k>
> >> > >>>>>>>   >   ing
> >> > >>>>>>>>   >   >
> >> > >>>>>>>>   >
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Christian Kaltepoth
> >> > Blog: http://chkal.blogspot.com/
> >> > Twitter: http://twitter.com/chkal
> >> >
> >>
> >
> >
>



-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

AW: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Arne Limburg <ar...@openknowledge.de>.

If we implement @Secured on top of @SecurityBindingType this could even be a permanent solution.
So my +1 for that.

-----Ursprüngliche Nachricht-----
Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
Gesendet: Mittwoch, 1. Februar 2012 12:33
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

hi @ all,

i talked with shane about further details of the current implementation.

-> if we don't see an agreement this week:
+1 for adding both (at least for now).

we have to add features to >both< @Secured as well as @SecurityBindingType.
maybe we will see that one of both is better as soon as we have the final implementation (and therefore all the details) and we can remove the other approach.
if we see that both make sense, we just keep them.

regards,
gerhard



2012/2/1 Gerhard Petracek <ge...@gmail.com>

> yes - that's possible as well.
>
> short addition - 3b allows:
>
> @TwoOf //introduced by the >user<
> @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
> AccessDecisionVoter3.class})
>
> (i wouldn't do it that way, because i wouldn't use a custom annotation
> for such use-cases. however, users can decide it on their own.)
>
> regards,
> gerhard
>
>
>
> 2012/2/1 Arne Limburg <ar...@openknowledge.de>
>
>> Basically we are discussing, if the access control logic goes into a
>> class that implements an interface (which is AccessDecisionVoter) or
>> into a method that is annotated with @Secures.
>>
>> Note that both approaches can be built with the other.
>>
>> I prefer the second way since it looks more like the CDI way.
>>
>> Another option is to provide both APIs. Then we only would have to
>> decide which one is "core" and which one is based on the other.
>>
>> Cheers,
>> Arne
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> Gesendet: Mittwoch, 1. Februar 2012 08:54
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>
>> @christian: that's correct. but the advantage of using custom
>> annotation arguments can't be used any more.
>>
>> and that's also one of my concerns - simple cases work (but also
>> simple cases are more complex than the usage of @Secured) and such "advanced"
>> use-cases are restricted.
>>
>> >in some cases it's worth to add more complexity, because it makes
>> >sense
>> for supporting advanced use-cases!<
>> but right now i don't see it here.
>>
>> it would be possible to extend the approach of @Secured.
>>
>> examples:
>>
>> #1
>>
>> //...
>> @Secured(MyAccessDecisionVoter.class)
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> users who prefer custom annotations can use stereotypes:
>>
>> #2
>> //...
>> @Admin
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> //...
>> @Stereotype
>> @Secured(AdminAccessDecisionVoter.class)
>> public @interface Admin
>> {
>> }
>>
>> #3
>> //...
>> //...
>> @AdminOrUser
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> a)
>> //...
>> @Stereotype
>> @Secured(oneOf = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class})
>> // @Secured(allOf = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class})
>> // ...
>> public @interface AdminOrUser
>> {
>> }
>>
>> or
>>
>> b)
>> //...
>> @Stereotype
>> //users could even provide a custom interceptor strategy and
>> introduce custom versions of @OneOf or other annotations @OneOf
>> @Secured({AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class}) public @interface AdminOrUser { }
>>
>> or
>>
>> c)
>> //...
>> @Stereotype
>> @Secured(value = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
>> AdminOrUser { }
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
>>
>> > What about something like this:
>> >
>> >  public @interface AnyOf {
>> >      Class<? extends Annotation>[] value();  }
>> >
>> > Usage:
>> >
>> >  @AnyOf({User.class, Admin.class})
>> >  public void doSomething() {
>> >       // something
>> >  }
>> >
>> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
>> > syntax. :)
>> >
>> > Christian
>> >
>> >
>> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
>> > > Yes, that would work, but that annotation is not that nice. I
>> > > would have
>> > expected something like
>> > > @AnyOf({@User, @Admin})
>> > > which unfortunately is no valid Java syntax.
>> > > Instead of that someone could write something like
>> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like
>> > > Shane suggests. Sadly enough there is no easy
>> > way to provide a default @AnyOf annotation. So the users have to
>> > write their own versions any time they need one.
>> > >
>> > > Any better ideas?
>> > >
>> > > Cheers,
>> > > Arne
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>> > > Gesendet: Dienstag, 31. Januar 2012 22:48
>> > > An: deltaspike-dev@incubator.apache.org
>> > > Cc: Jason Porter
>> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>> > >
>> > > I would approach the "or" use case by simply providing another
>> > annotation:
>> > >
>> > > @SecurityBindingType
>> > > @Retention(RetentionPolicy.**RUNTIME)
>> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>> > AdminOrUser {
>> > >
>> > > }
>> > >
>> > >
>> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
>> > >   return isAdmin() || isUser();
>> > > }
>> > >
>> > >
>> > >
>> > >
>> > > On 01/02/12 07:44, Jason Porter wrote:
>> > >> Looks like I responded to the wrong thread as well.
>> > >>
>> > >> I personally like the binding approach a little better. It seems
>> > >> to be more similar to the CDI way of doing interceptors (which,
>> > >> at the end of the day is essentially what we're doing). However,
>> > >> we have seen a need of doing @Admin || @User or @Admin&&  @User.
>> > >> The and is fairly easy, but the or is currently not covered and
>> > >> we need to be able to do
>> > that.
>> > >>
>> > >> I'm pretty much at a +0 for both as well. As long as we have a
>> > >> way of doing the feature I described above, I don't really care
>> > >> which way we
>> > go.
>> > >>
>> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>> > >> <ge...@gmail.com>wrote:
>> > >>
>> > >>> hi shane,
>> > >>>
>> > >>> that's one of the reasons why i won't block it right now.
>> > >>> if the majority prefers custom annotations, we should just
>> > >>> introduce it
>> > >>>> after<  v0.1 and prototype the missing parts (and test it with
>> > >>>> the
>> > >>> supported servers).
>> > >>>
>> > >>> my vote is +0 right now (for both).
>> > >>>
>> > >>> regards,
>> > >>> gerhard
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
>> > >>>
>> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
>> > >>>>
>> > >>>>> hi mark,
>> > >>>>>
>> > >>>>> thx for the heads-up. i just talked with shane about all
>> > >>>>> those
>> > details.
>> > >>>>>
>> > >>>>> i don't see an issue with view-configs. codi just extracts
>> > >>>>> the @Secured annotation during the bootstrapping process in
>> > >>>>> case of
>> > view-configs.
>> > >>> that
>> > >>>>> would be the "same" for such custom annotations
>> > >>>>> meta-annotated with @SecurityBindingType.
>> > >>>>>
>> > >>>>> what we need in case of intercepted beans:
>> > >>>>> 1) access to InvocationContext
>> > >>>>> 2) easy access to the information if a security check is
>> > >>>>> on-going
>> > >>>>> 3) possibility to configure a default error-view (needed
>> > >>>>> later
>> > >>>>> on)
>> > >>>>> 4) possibility to provide a custom message + an integration
>> > >>>>> with the upcoming i18n module
>> > >>>>>
>> > >>>>> shane said that it should be possible to add all needed features.
>> > >>>>> (for
>> > >>> me
>> > >>>>> that means we need a prototype if the majority prefers custom
>> > >>>>> annotations.)
>> > >>>>>
>> > >>>>> in the end both approaches are similar. both are generic
>> > >>>>> enough to integrate 3rd party security frameworks.
>> > >>>>>
>> > >>>>> @SecurityBindingType is just more generic and users need an
>> > >>>>> additional step to find secured beans (/views) in a project.
>> > >>>>> furthermore, meta-data inheritance with the mentioned
>> > >>>>> view-configs is a bit harder for users.
>> > >>>>> imo it's just a matter of taste. custom annotations as
>> > >>>>> additional indirection vs. a specific annotation with inline
>> information.
>> > >>>>>
>> > >>>>> with the approach provided by codi, users can't introduce a
>> > >>>>> custom annotation. however, i know a lot of users who prefer
>> > >>>>> one given
>> > >>> annotation
>> > >>>>> instead of implementing x custom annotations. and i guess
>> > >>>>> shane knows a lot of users who prefer custom annotations. the
>> > >>>>> goal of codi was to make it easy, intuitive and flexible
>> > >>>>> enough to integrate 3rd party security-frameworks (instead of
>> > >>>>> creating a new security-framework). i wouldn't block the
>> > >>>>> custom annotation approach if 1)-4) are possible -
>> > >>> it's
>> > >>>>> a bit more flexible but also a bit more complex for users.
>> > >>>>>
>> > >>>> The beauty with the custom annotations is, if you like you can
>> > >>>> just
>> > >>> define
>> > >>>> a single annotation if you want and use that throughout your
>> > application.
>> > >>>>   I.e. you could similate the behavior of CODI:
>> > >>>>
>> > >>>>
>> > >>>> @SecurityBindingType
>> > >>>> @Retention(RetentionPolicy.**RUNTIME)
>> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public
>> > >>>> @interface Secured {
>> > >>>>   @Nonbinding Class[] voters() default {};
>> > >>>>
>> > >>>> }
>> > >>>>
>> > >>>>
>> > >>>>> regards,
>> > >>>>> gerhard
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
>> > >>>>>
>> > >>>>>   Gerhard, for explaining this you will probably need to also
>> > >>>>> explain the
>> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using
>> > >>>>>> custom annotations, you would loose lots of functionality in this area.
>> > >>>>>>
>> > >>>>>> I know that this is not the current topic, but discussing
>> > >>>>>> security mechanisms without discussing the stuff which needs
>> > >>>>>> to get secured is only half of the truth ;)
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> LieGrue,
>> > >>>>>> strub
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> [1]
>> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>> > >>>>>> JSFUsage-TypesafeViewConfig<
>> > >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-Typesaf
>> > >>> eVi
>> > >>> ewC
>> > >>> onfig
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> ----- Original Message -----
>> > >>>>>>
>> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
>> > >>> gerhard.petracek@gmail.com>
>> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
>> > >>> deltaspike-dev@incubator.apache.org>
>> > >>>>>>> Cc:
>> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
>> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
>> > >>>>>>> @Secured
>> > >>>>>>>
>> > >>>>>>> in case of myfaces codi it's also used for secured view and
>> > >>>>>>> it is integrated with the default-error-view concept (as
>> > >>>>>>> mentioned in the
>> > >>>>>>>
>> > >>>>>> ticket
>> > >>>>>>
>> > >>>>>>> we will postpone this part).
>> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
>> > >>>>>>> expiration behaviour of beans cause by a security check
>> > >>>>>>> (see the mentioned AccessDecisionVoterContext).
>> > >>>>>>>
>> > >>>>>>> regards,
>> > >>>>>>> gerhard
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
>> > >>> arne.limburg@openknowledge.de>
>> > >>>>>>>    Hi,
>> > >>>>>>>>   My first objection when I saw the CODI feature the first
>> > >>>>>>>> time, was
>> > >>>>>>>>
>> > >>>>>>> that it
>> > >>>>>>>   maybe is too basic: When I have to implement the Voter
>> > >>>>>>> anyway (or my
>> > >>>>>>>>   security-framework of choice delivers it), why should I
>> > >>>>>>>> use @Secured at
>> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
>> > >>>>>>>> over a
>> > >>> custom
>> > >>>>>>>>   annotation implemented by myself or delivered by my
>> > >>> security-framework
>> > >>>>>>> of
>> > >>>>>>>   choice.
>> > >>>>>>>>   The only benefit I see is when using different security
>> > >>>>>>>> sources, but
>> > >>>>>>>>
>> > >>>>>>> this
>> > >>>>>>>   is a rare use case imho.
>> > >>>>>>>>   Cheers,
>> > >>>>>>>>   Arne
>> > >>>>>>>>
>> > >>>>>>>>   -----Ursprüngliche Nachricht-----
>> > >>>>>>>>   Von: Gerhard Petracek
>> > >>>>>>>> [mailto:gerhard.petracek@**gmail.com<
>> > >>> gerhard.petracek@gmail.com>
>> > >>>>>>>> ]
>> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
>> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
>> > >>> deltaspike-dev@incubator.apache.org>
>> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
>> > >>>>>>>> @Secured
>> > >>>>>>>>
>> > >>>>>>>>   that's one option. a 2nd option is to use a
>> > >>> deltaspike-security-impl.
>> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
>> > >>>>>>>>
>> > >>>>>>> security-framework.
>> > >>>>>>>   or users just add a possible deltaspike-add-on provided
>> > >>>>>>> by an
>> > >>> external
>> > >>>>>>>>   community e.g. by a security-framework itself.
>> > >>>>>>>>
>> > >>>>>>>>   regards,
>> > >>>>>>>>   gerhard
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
>> > >>>>>>>>
>> > >>>>>>>>   >   Is it up to the developer to define the bean that
>> > implements an
>> > >>>>>>>>   interface?
>> > >>>>>>>>   >
>> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
>> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
>> > >>>>>>>>   >
>> > >>>>>>>>   >   >   hi @ all,
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
>> > starting point
>> > >>>>>>>>
>> > >>>>>>> for
>> > >>>>>>>
>> > >>>>>>>>   >   >   the security-api discussion, because the basic idea
>> > behind it
>> > >>> is
>> > >>>>>>> a
>> > >>>>>>>
>> > >>>>>>>>   >   >   very thin integration layer (which can be used by
>> other
>> > >>>>>>>> modules).
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   the basic concept:
>> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure
>> the
>> > target
>> > >>>>>>>>   method/s.
>> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
>> > specific
>> > >>>>>>>>
>> > >>>>>>> interface
>> > >>>>>>>
>> > >>>>>>>>   >   >   and therefore has access to the InvocationContext.
>> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<
>> > be
>> > >>>>>>>>
>> > >>>>>>> used to
>> > >>>>>>>
>> > >>>>>>>>   >   integrate
>> > >>>>>>>>   >   >   3rd party security-frameworks.
>> > >>>>>>>>   >   >   [1] provides a bit more details of the basic concept
>> as
>> > well
>> > >>> as
>> > >>>>>>> the
>> > >>>>>>>
>> > >>>>>>>>   >   >   basic usage of @Secured.
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   please send
>> > >>>>>>>>   >   >   +1, +0 or -1 because...
>> > >>>>>>>>   >   >   for the>basic concept<.
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
>> > discuss
>> > >>>>>>>>
>> > >>>>>>> details e.g.
>> > >>>>>>>
>> > >>>>>>>>   >   >   further objections about the concrete implementation
>> > (e.g.
>> > >>>>>>>>
>> > >>>>>>> internal
>> > >>>>>>>
>> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
>> > concept.)
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   regards,
>> > >>>>>>>>   >   >   gerhard
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   [1]
>> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
>> > >>>>>>>>   >   >   [2]
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >
>> > >>>>>>>>
>> > >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>> > >>>>>> SE+Feature+Rank<
>> > >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Featu
>> > >>> re+
>> > >>> Ran
>> > >>> k>
>> > >>>>>>>   >   ing
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> > --
>> > Christian Kaltepoth
>> > Blog: http://chkal.blogspot.com/
>> > Twitter: http://twitter.com/chkal
>> >
>>
>
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Gerhard Petracek <ge...@gmail.com>.

hi @ all,

i talked with shane about further details of the current implementation.

-> if we don't see an agreement this week:
+1 for adding both (at least for now).

we have to add features to >both< @Secured as well as @SecurityBindingType.
maybe we will see that one of both is better as soon as we have the final
implementation (and therefore all the details) and we can remove the other
approach.
if we see that both make sense, we just keep them.

regards,
gerhard



2012/2/1 Gerhard Petracek <ge...@gmail.com>

> yes - that's possible as well.
>
> short addition - 3b allows:
>
> @TwoOf //introduced by the >user<
> @Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
> AccessDecisionVoter3.class})
>
> (i wouldn't do it that way, because i wouldn't use a custom annotation for
> such use-cases. however, users can decide it on their own.)
>
> regards,
> gerhard
>
>
>
> 2012/2/1 Arne Limburg <ar...@openknowledge.de>
>
>> Basically we are discussing, if the access control logic goes into a
>> class that implements an interface (which is AccessDecisionVoter) or into a
>> method that is annotated with @Secures.
>>
>> Note that both approaches can be built with the other.
>>
>> I prefer the second way since it looks more like the CDI way.
>>
>> Another option is to provide both APIs. Then we only would have to decide
>> which one is "core" and which one is based on the other.
>>
>> Cheers,
>> Arne
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
>> Gesendet: Mittwoch, 1. Februar 2012 08:54
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>>
>> @christian: that's correct. but the advantage of using custom annotation
>> arguments can't be used any more.
>>
>> and that's also one of my concerns - simple cases work (but also simple
>> cases are more complex than the usage of @Secured) and such "advanced"
>> use-cases are restricted.
>>
>> >in some cases it's worth to add more complexity, because it makes sense
>> for supporting advanced use-cases!<
>> but right now i don't see it here.
>>
>> it would be possible to extend the approach of @Secured.
>>
>> examples:
>>
>> #1
>>
>> //...
>> @Secured(MyAccessDecisionVoter.class)
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> users who prefer custom annotations can use stereotypes:
>>
>> #2
>> //...
>> @Admin
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> //...
>> @Stereotype
>> @Secured(AdminAccessDecisionVoter.class)
>> public @interface Admin
>> {
>> }
>>
>> #3
>> //...
>> //...
>> @AdminOrUser
>> public class SecuredBean
>> {
>>    //...
>> }
>>
>> a)
>> //...
>> @Stereotype
>> @Secured(oneOf = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class})
>> // @Secured(allOf = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class})
>> // ...
>> public @interface AdminOrUser
>> {
>> }
>>
>> or
>>
>> b)
>> //...
>> @Stereotype
>> //users could even provide a custom interceptor strategy and introduce
>> custom versions of @OneOf or other annotations @OneOf
>> @Secured({AdminAccessDecisionVoter.class, UserAccessDecisionVoter.class})
>> public @interface AdminOrUser { }
>>
>> or
>>
>> c)
>> //...
>> @Stereotype
>> @Secured(value = {AdminAccessDecisionVoter.class,
>> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
>> AdminOrUser { }
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
>>
>> > What about something like this:
>> >
>> >  public @interface AnyOf {
>> >      Class<? extends Annotation>[] value();  }
>> >
>> > Usage:
>> >
>> >  @AnyOf({User.class, Admin.class})
>> >  public void doSomething() {
>> >       // something
>> >  }
>> >
>> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
>> > syntax. :)
>> >
>> > Christian
>> >
>> >
>> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
>> > > Yes, that would work, but that annotation is not that nice. I would
>> > > have
>> > expected something like
>> > > @AnyOf({@User, @Admin})
>> > > which unfortunately is no valid Java syntax.
>> > > Instead of that someone could write something like
>> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like Shane
>> > > suggests. Sadly enough there is no easy
>> > way to provide a default @AnyOf annotation. So the users have to write
>> > their own versions any time they need one.
>> > >
>> > > Any better ideas?
>> > >
>> > > Cheers,
>> > > Arne
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
>> > > Gesendet: Dienstag, 31. Januar 2012 22:48
>> > > An: deltaspike-dev@incubator.apache.org
>> > > Cc: Jason Porter
>> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>> > >
>> > > I would approach the "or" use case by simply providing another
>> > annotation:
>> > >
>> > > @SecurityBindingType
>> > > @Retention(RetentionPolicy.**RUNTIME)
>> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>> > AdminOrUser {
>> > >
>> > > }
>> > >
>> > >
>> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
>> > >   return isAdmin() || isUser();
>> > > }
>> > >
>> > >
>> > >
>> > >
>> > > On 01/02/12 07:44, Jason Porter wrote:
>> > >> Looks like I responded to the wrong thread as well.
>> > >>
>> > >> I personally like the binding approach a little better. It seems to
>> > >> be more similar to the CDI way of doing interceptors (which, at the
>> > >> end of the day is essentially what we're doing). However, we have
>> > >> seen a need of doing @Admin || @User or @Admin&&  @User. The and is
>> > >> fairly easy, but the or is currently not covered and we need to be
>> > >> able to do
>> > that.
>> > >>
>> > >> I'm pretty much at a +0 for both as well. As long as we have a way
>> > >> of doing the feature I described above, I don't really care which
>> > >> way we
>> > go.
>> > >>
>> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
>> > >> <ge...@gmail.com>wrote:
>> > >>
>> > >>> hi shane,
>> > >>>
>> > >>> that's one of the reasons why i won't block it right now.
>> > >>> if the majority prefers custom annotations, we should just
>> > >>> introduce it
>> > >>>> after<  v0.1 and prototype the missing parts (and test it with
>> > >>>> the
>> > >>> supported servers).
>> > >>>
>> > >>> my vote is +0 right now (for both).
>> > >>>
>> > >>> regards,
>> > >>> gerhard
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
>> > >>>
>> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
>> > >>>>
>> > >>>>> hi mark,
>> > >>>>>
>> > >>>>> thx for the heads-up. i just talked with shane about all those
>> > details.
>> > >>>>>
>> > >>>>> i don't see an issue with view-configs. codi just extracts the
>> > >>>>> @Secured annotation during the bootstrapping process in case of
>> > view-configs.
>> > >>> that
>> > >>>>> would be the "same" for such custom annotations meta-annotated
>> > >>>>> with @SecurityBindingType.
>> > >>>>>
>> > >>>>> what we need in case of intercepted beans:
>> > >>>>> 1) access to InvocationContext
>> > >>>>> 2) easy access to the information if a security check is
>> > >>>>> on-going
>> > >>>>> 3) possibility to configure a default error-view (needed later
>> > >>>>> on)
>> > >>>>> 4) possibility to provide a custom message + an integration with
>> > >>>>> the upcoming i18n module
>> > >>>>>
>> > >>>>> shane said that it should be possible to add all needed features.
>> > >>>>> (for
>> > >>> me
>> > >>>>> that means we need a prototype if the majority prefers custom
>> > >>>>> annotations.)
>> > >>>>>
>> > >>>>> in the end both approaches are similar. both are generic enough
>> > >>>>> to integrate 3rd party security frameworks.
>> > >>>>>
>> > >>>>> @SecurityBindingType is just more generic and users need an
>> > >>>>> additional step to find secured beans (/views) in a project.
>> > >>>>> furthermore, meta-data inheritance with the mentioned
>> > >>>>> view-configs is a bit harder for users.
>> > >>>>> imo it's just a matter of taste. custom annotations as
>> > >>>>> additional indirection vs. a specific annotation with inline
>> information.
>> > >>>>>
>> > >>>>> with the approach provided by codi, users can't introduce a
>> > >>>>> custom annotation. however, i know a lot of users who prefer one
>> > >>>>> given
>> > >>> annotation
>> > >>>>> instead of implementing x custom annotations. and i guess shane
>> > >>>>> knows a lot of users who prefer custom annotations. the goal of
>> > >>>>> codi was to make it easy, intuitive and flexible enough to
>> > >>>>> integrate 3rd party security-frameworks (instead of creating a
>> > >>>>> new security-framework). i wouldn't block the custom annotation
>> > >>>>> approach if 1)-4) are possible -
>> > >>> it's
>> > >>>>> a bit more flexible but also a bit more complex for users.
>> > >>>>>
>> > >>>> The beauty with the custom annotations is, if you like you can
>> > >>>> just
>> > >>> define
>> > >>>> a single annotation if you want and use that throughout your
>> > application.
>> > >>>>   I.e. you could similate the behavior of CODI:
>> > >>>>
>> > >>>>
>> > >>>> @SecurityBindingType
>> > >>>> @Retention(RetentionPolicy.**RUNTIME)
>> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
>> > >>>> Secured {
>> > >>>>   @Nonbinding Class[] voters() default {};
>> > >>>>
>> > >>>> }
>> > >>>>
>> > >>>>
>> > >>>>> regards,
>> > >>>>> gerhard
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
>> > >>>>>
>> > >>>>>   Gerhard, for explaining this you will probably need to also
>> > >>>>> explain the
>> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
>> > >>>>>> annotations, you would loose lots of functionality in this area.
>> > >>>>>>
>> > >>>>>> I know that this is not the current topic, but discussing
>> > >>>>>> security mechanisms without discussing the stuff which needs to
>> > >>>>>> get secured is only half of the truth ;)
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> LieGrue,
>> > >>>>>> strub
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> [1]
>> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
>> > >>>>>> JSFUsage-TypesafeViewConfig<
>> > >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeVi
>> > >>> ewC
>> > >>> onfig
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> ----- Original Message -----
>> > >>>>>>
>> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
>> > >>> gerhard.petracek@gmail.com>
>> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
>> > >>> deltaspike-dev@incubator.apache.org>
>> > >>>>>>> Cc:
>> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
>> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>> > >>>>>>>
>> > >>>>>>> in case of myfaces codi it's also used for secured view and it
>> > >>>>>>> is integrated with the default-error-view concept (as
>> > >>>>>>> mentioned in the
>> > >>>>>>>
>> > >>>>>> ticket
>> > >>>>>>
>> > >>>>>>> we will postpone this part).
>> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
>> > >>>>>>> expiration behaviour of beans cause by a security check (see
>> > >>>>>>> the mentioned AccessDecisionVoterContext).
>> > >>>>>>>
>> > >>>>>>> regards,
>> > >>>>>>> gerhard
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
>> > >>> arne.limburg@openknowledge.de>
>> > >>>>>>>    Hi,
>> > >>>>>>>>   My first objection when I saw the CODI feature the first
>> > >>>>>>>> time, was
>> > >>>>>>>>
>> > >>>>>>> that it
>> > >>>>>>>   maybe is too basic: When I have to implement the Voter
>> > >>>>>>> anyway (or my
>> > >>>>>>>>   security-framework of choice delivers it), why should I use
>> > >>>>>>>> @Secured at
>> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
>> > >>>>>>>> over a
>> > >>> custom
>> > >>>>>>>>   annotation implemented by myself or delivered by my
>> > >>> security-framework
>> > >>>>>>> of
>> > >>>>>>>   choice.
>> > >>>>>>>>   The only benefit I see is when using different security
>> > >>>>>>>> sources, but
>> > >>>>>>>>
>> > >>>>>>> this
>> > >>>>>>>   is a rare use case imho.
>> > >>>>>>>>   Cheers,
>> > >>>>>>>>   Arne
>> > >>>>>>>>
>> > >>>>>>>>   -----Ursprüngliche Nachricht-----
>> > >>>>>>>>   Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
>> > >>> gerhard.petracek@gmail.com>
>> > >>>>>>>> ]
>> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
>> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
>> > >>> deltaspike-dev@incubator.apache.org>
>> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
>> > >>>>>>>> @Secured
>> > >>>>>>>>
>> > >>>>>>>>   that's one option. a 2nd option is to use a
>> > >>> deltaspike-security-impl.
>> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
>> > >>>>>>>>
>> > >>>>>>> security-framework.
>> > >>>>>>>   or users just add a possible deltaspike-add-on provided by
>> > >>>>>>> an
>> > >>> external
>> > >>>>>>>>   community e.g. by a security-framework itself.
>> > >>>>>>>>
>> > >>>>>>>>   regards,
>> > >>>>>>>>   gerhard
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
>> > >>>>>>>>
>> > >>>>>>>>   >   Is it up to the developer to define the bean that
>> > implements an
>> > >>>>>>>>   interface?
>> > >>>>>>>>   >
>> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
>> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
>> > >>>>>>>>   >
>> > >>>>>>>>   >   >   hi @ all,
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
>> > starting point
>> > >>>>>>>>
>> > >>>>>>> for
>> > >>>>>>>
>> > >>>>>>>>   >   >   the security-api discussion, because the basic idea
>> > behind it
>> > >>> is
>> > >>>>>>> a
>> > >>>>>>>
>> > >>>>>>>>   >   >   very thin integration layer (which can be used by
>> other
>> > >>>>>>>> modules).
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   the basic concept:
>> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure
>> the
>> > target
>> > >>>>>>>>   method/s.
>> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
>> > specific
>> > >>>>>>>>
>> > >>>>>>> interface
>> > >>>>>>>
>> > >>>>>>>>   >   >   and therefore has access to the InvocationContext.
>> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<
>> > be
>> > >>>>>>>>
>> > >>>>>>> used to
>> > >>>>>>>
>> > >>>>>>>>   >   integrate
>> > >>>>>>>>   >   >   3rd party security-frameworks.
>> > >>>>>>>>   >   >   [1] provides a bit more details of the basic concept
>> as
>> > well
>> > >>> as
>> > >>>>>>> the
>> > >>>>>>>
>> > >>>>>>>>   >   >   basic usage of @Secured.
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   please send
>> > >>>>>>>>   >   >   +1, +0 or -1 because...
>> > >>>>>>>>   >   >   for the>basic concept<.
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
>> > discuss
>> > >>>>>>>>
>> > >>>>>>> details e.g.
>> > >>>>>>>
>> > >>>>>>>>   >   >   further objections about the concrete implementation
>> > (e.g.
>> > >>>>>>>>
>> > >>>>>>> internal
>> > >>>>>>>
>> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
>> > concept.)
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   regards,
>> > >>>>>>>>   >   >   gerhard
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >   >   [1]
>> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
>> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
>> > >>>>>>>>   >   >   [2]
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >
>> > >>>>>>>>
>> > >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
>> > >>>>>> SE+Feature+Rank<
>> > >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+
>> > >>> Ran
>> > >>> k>
>> > >>>>>>>   >   ing
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> > --
>> > Christian Kaltepoth
>> > Blog: http://chkal.blogspot.com/
>> > Twitter: http://twitter.com/chkal
>> >
>>
>
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Gerhard Petracek <ge...@gmail.com>.

yes - that's possible as well.

short addition - 3b allows:

@TwoOf //introduced by the >user<
@Secured({AccessDecisionVoter1.class,  AccessDecisionVoter2.class,
AccessDecisionVoter3.class})

(i wouldn't do it that way, because i wouldn't use a custom annotation for
such use-cases. however, users can decide it on their own.)

regards,
gerhard



2012/2/1 Arne Limburg <ar...@openknowledge.de>

> Basically we are discussing, if the access control logic goes into a class
> that implements an interface (which is AccessDecisionVoter) or into a
> method that is annotated with @Secures.
>
> Note that both approaches can be built with the other.
>
> I prefer the second way since it looks more like the CDI way.
>
> Another option is to provide both APIs. Then we only would have to decide
> which one is "core" and which one is based on the other.
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
> Gesendet: Mittwoch, 1. Februar 2012 08:54
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
>
> @christian: that's correct. but the advantage of using custom annotation
> arguments can't be used any more.
>
> and that's also one of my concerns - simple cases work (but also simple
> cases are more complex than the usage of @Secured) and such "advanced"
> use-cases are restricted.
>
> >in some cases it's worth to add more complexity, because it makes sense
> for supporting advanced use-cases!<
> but right now i don't see it here.
>
> it would be possible to extend the approach of @Secured.
>
> examples:
>
> #1
>
> //...
> @Secured(MyAccessDecisionVoter.class)
> public class SecuredBean
> {
>    //...
> }
>
> users who prefer custom annotations can use stereotypes:
>
> #2
> //...
> @Admin
> public class SecuredBean
> {
>    //...
> }
>
> //...
> @Stereotype
> @Secured(AdminAccessDecisionVoter.class)
> public @interface Admin
> {
> }
>
> #3
> //...
> //...
> @AdminOrUser
> public class SecuredBean
> {
>    //...
> }
>
> a)
> //...
> @Stereotype
> @Secured(oneOf = {AdminAccessDecisionVoter.class,
> UserAccessDecisionVoter.class})
> // @Secured(allOf = {AdminAccessDecisionVoter.class,
> UserAccessDecisionVoter.class})
> // ...
> public @interface AdminOrUser
> {
> }
>
> or
>
> b)
> //...
> @Stereotype
> //users could even provide a custom interceptor strategy and introduce
> custom versions of @OneOf or other annotations @OneOf
> @Secured({AdminAccessDecisionVoter.class, UserAccessDecisionVoter.class})
> public @interface AdminOrUser { }
>
> or
>
> c)
> //...
> @Stereotype
> @Secured(value = {AdminAccessDecisionVoter.class,
> UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface
> AdminOrUser { }
>
> regards,
> gerhard
>
>
>
> 2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>
>
> > What about something like this:
> >
> >  public @interface AnyOf {
> >      Class<? extends Annotation>[] value();  }
> >
> > Usage:
> >
> >  @AnyOf({User.class, Admin.class})
> >  public void doSomething() {
> >       // something
> >  }
> >
> > It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
> > syntax. :)
> >
> > Christian
> >
> >
> > 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> > > Yes, that would work, but that annotation is not that nice. I would
> > > have
> > expected something like
> > > @AnyOf({@User, @Admin})
> > > which unfortunately is no valid Java syntax.
> > > Instead of that someone could write something like
> > > @AnyOf(role1 = @User, role2 = @Admin) which could be used like Shane
> > > suggests. Sadly enough there is no easy
> > way to provide a default @AnyOf annotation. So the users have to write
> > their own versions any time they need one.
> > >
> > > Any better ideas?
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> > > Gesendet: Dienstag, 31. Januar 2012 22:48
> > > An: deltaspike-dev@incubator.apache.org
> > > Cc: Jason Porter
> > > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> > >
> > > I would approach the "or" use case by simply providing another
> > annotation:
> > >
> > > @SecurityBindingType
> > > @Retention(RetentionPolicy.**RUNTIME)
> > > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> > AdminOrUser {
> > >
> > > }
> > >
> > >
> > > public boolean @Secures @AdminOrUser isAdminOrUser() {
> > >   return isAdmin() || isUser();
> > > }
> > >
> > >
> > >
> > >
> > > On 01/02/12 07:44, Jason Porter wrote:
> > >> Looks like I responded to the wrong thread as well.
> > >>
> > >> I personally like the binding approach a little better. It seems to
> > >> be more similar to the CDI way of doing interceptors (which, at the
> > >> end of the day is essentially what we're doing). However, we have
> > >> seen a need of doing @Admin || @User or @Admin&&  @User. The and is
> > >> fairly easy, but the or is currently not covered and we need to be
> > >> able to do
> > that.
> > >>
> > >> I'm pretty much at a +0 for both as well. As long as we have a way
> > >> of doing the feature I described above, I don't really care which
> > >> way we
> > go.
> > >>
> > >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> > >> <ge...@gmail.com>wrote:
> > >>
> > >>> hi shane,
> > >>>
> > >>> that's one of the reasons why i won't block it right now.
> > >>> if the majority prefers custom annotations, we should just
> > >>> introduce it
> > >>>> after<  v0.1 and prototype the missing parts (and test it with
> > >>>> the
> > >>> supported servers).
> > >>>
> > >>> my vote is +0 right now (for both).
> > >>>
> > >>> regards,
> > >>> gerhard
> > >>>
> > >>>
> > >>>
> > >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
> > >>>
> > >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> > >>>>
> > >>>>> hi mark,
> > >>>>>
> > >>>>> thx for the heads-up. i just talked with shane about all those
> > details.
> > >>>>>
> > >>>>> i don't see an issue with view-configs. codi just extracts the
> > >>>>> @Secured annotation during the bootstrapping process in case of
> > view-configs.
> > >>> that
> > >>>>> would be the "same" for such custom annotations meta-annotated
> > >>>>> with @SecurityBindingType.
> > >>>>>
> > >>>>> what we need in case of intercepted beans:
> > >>>>> 1) access to InvocationContext
> > >>>>> 2) easy access to the information if a security check is
> > >>>>> on-going
> > >>>>> 3) possibility to configure a default error-view (needed later
> > >>>>> on)
> > >>>>> 4) possibility to provide a custom message + an integration with
> > >>>>> the upcoming i18n module
> > >>>>>
> > >>>>> shane said that it should be possible to add all needed features.
> > >>>>> (for
> > >>> me
> > >>>>> that means we need a prototype if the majority prefers custom
> > >>>>> annotations.)
> > >>>>>
> > >>>>> in the end both approaches are similar. both are generic enough
> > >>>>> to integrate 3rd party security frameworks.
> > >>>>>
> > >>>>> @SecurityBindingType is just more generic and users need an
> > >>>>> additional step to find secured beans (/views) in a project.
> > >>>>> furthermore, meta-data inheritance with the mentioned
> > >>>>> view-configs is a bit harder for users.
> > >>>>> imo it's just a matter of taste. custom annotations as
> > >>>>> additional indirection vs. a specific annotation with inline
> information.
> > >>>>>
> > >>>>> with the approach provided by codi, users can't introduce a
> > >>>>> custom annotation. however, i know a lot of users who prefer one
> > >>>>> given
> > >>> annotation
> > >>>>> instead of implementing x custom annotations. and i guess shane
> > >>>>> knows a lot of users who prefer custom annotations. the goal of
> > >>>>> codi was to make it easy, intuitive and flexible enough to
> > >>>>> integrate 3rd party security-frameworks (instead of creating a
> > >>>>> new security-framework). i wouldn't block the custom annotation
> > >>>>> approach if 1)-4) are possible -
> > >>> it's
> > >>>>> a bit more flexible but also a bit more complex for users.
> > >>>>>
> > >>>> The beauty with the custom annotations is, if you like you can
> > >>>> just
> > >>> define
> > >>>> a single annotation if you want and use that throughout your
> > application.
> > >>>>   I.e. you could similate the behavior of CODI:
> > >>>>
> > >>>>
> > >>>> @SecurityBindingType
> > >>>> @Retention(RetentionPolicy.**RUNTIME)
> > >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> > >>>> Secured {
> > >>>>   @Nonbinding Class[] voters() default {};
> > >>>>
> > >>>> }
> > >>>>
> > >>>>
> > >>>>> regards,
> > >>>>> gerhard
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
> > >>>>>
> > >>>>>   Gerhard, for explaining this you will probably need to also
> > >>>>> explain the
> > >>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
> > >>>>>> annotations, you would loose lots of functionality in this area.
> > >>>>>>
> > >>>>>> I know that this is not the current topic, but discussing
> > >>>>>> security mechanisms without discussing the stuff which needs to
> > >>>>>> get secured is only half of the truth ;)
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> LieGrue,
> > >>>>>> strub
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> [1]
> > >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> > >>>>>> JSFUsage-TypesafeViewConfig<
> > >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeVi
> > >>> ewC
> > >>> onfig
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>
> > >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> > >>> gerhard.petracek@gmail.com>
> > >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> > >>> deltaspike-dev@incubator.apache.org>
> > >>>>>>> Cc:
> > >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
> > >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> > >>>>>>>
> > >>>>>>> in case of myfaces codi it's also used for secured view and it
> > >>>>>>> is integrated with the default-error-view concept (as
> > >>>>>>> mentioned in the
> > >>>>>>>
> > >>>>>> ticket
> > >>>>>>
> > >>>>>>> we will postpone this part).
> > >>>>>>> furthermore it's used by codi-scopes to avoid a different
> > >>>>>>> expiration behaviour of beans cause by a security check (see
> > >>>>>>> the mentioned AccessDecisionVoterContext).
> > >>>>>>>
> > >>>>>>> regards,
> > >>>>>>> gerhard
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> > >>> arne.limburg@openknowledge.de>
> > >>>>>>>    Hi,
> > >>>>>>>>   My first objection when I saw the CODI feature the first
> > >>>>>>>> time, was
> > >>>>>>>>
> > >>>>>>> that it
> > >>>>>>>   maybe is too basic: When I have to implement the Voter
> > >>>>>>> anyway (or my
> > >>>>>>>>   security-framework of choice delivers it), why should I use
> > >>>>>>>> @Secured at
> > >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
> > >>>>>>>> over a
> > >>> custom
> > >>>>>>>>   annotation implemented by myself or delivered by my
> > >>> security-framework
> > >>>>>>> of
> > >>>>>>>   choice.
> > >>>>>>>>   The only benefit I see is when using different security
> > >>>>>>>> sources, but
> > >>>>>>>>
> > >>>>>>> this
> > >>>>>>>   is a rare use case imho.
> > >>>>>>>>   Cheers,
> > >>>>>>>>   Arne
> > >>>>>>>>
> > >>>>>>>>   -----Ursprüngliche Nachricht-----
> > >>>>>>>>   Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
> > >>> gerhard.petracek@gmail.com>
> > >>>>>>>> ]
> > >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
> > >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> > >>> deltaspike-dev@incubator.apache.org>
> > >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> > >>>>>>>> @Secured
> > >>>>>>>>
> > >>>>>>>>   that's one option. a 2nd option is to use a
> > >>> deltaspike-security-impl.
> > >>>>>>>>   module which can provide e.g. an adapter for 3rd party
> > >>>>>>>>
> > >>>>>>> security-framework.
> > >>>>>>>   or users just add a possible deltaspike-add-on provided by
> > >>>>>>> an
> > >>> external
> > >>>>>>>>   community e.g. by a security-framework itself.
> > >>>>>>>>
> > >>>>>>>>   regards,
> > >>>>>>>>   gerhard
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
> > >>>>>>>>
> > >>>>>>>>   >   Is it up to the developer to define the bean that
> > implements an
> > >>>>>>>>   interface?
> > >>>>>>>>   >
> > >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
> > >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
> > >>>>>>>>   >
> > >>>>>>>>   >   >   hi @ all,
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
> > starting point
> > >>>>>>>>
> > >>>>>>> for
> > >>>>>>>
> > >>>>>>>>   >   >   the security-api discussion, because the basic idea
> > behind it
> > >>> is
> > >>>>>>> a
> > >>>>>>>
> > >>>>>>>>   >   >   very thin integration layer (which can be used by
> other
> > >>>>>>>> modules).
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   the basic concept:
> > >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure
> the
> > target
> > >>>>>>>>   method/s.
> > >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
> > specific
> > >>>>>>>>
> > >>>>>>> interface
> > >>>>>>>
> > >>>>>>>>   >   >   and therefore has access to the InvocationContext.
> > >>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<
> > be
> > >>>>>>>>
> > >>>>>>> used to
> > >>>>>>>
> > >>>>>>>>   >   integrate
> > >>>>>>>>   >   >   3rd party security-frameworks.
> > >>>>>>>>   >   >   [1] provides a bit more details of the basic concept
> as
> > well
> > >>> as
> > >>>>>>> the
> > >>>>>>>
> > >>>>>>>>   >   >   basic usage of @Secured.
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   please send
> > >>>>>>>>   >   >   +1, +0 or -1 because...
> > >>>>>>>>   >   >   for the>basic concept<.
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
> > discuss
> > >>>>>>>>
> > >>>>>>> details e.g.
> > >>>>>>>
> > >>>>>>>>   >   >   further objections about the concrete implementation
> > (e.g.
> > >>>>>>>>
> > >>>>>>> internal
> > >>>>>>>
> > >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
> > concept.)
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   regards,
> > >>>>>>>>   >   >   gerhard
> > >>>>>>>>   >   >
> > >>>>>>>>   >   >   [1]
> > https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> > >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> > >>>>>>>>   >   >   [2]
> > >>>>>>>>   >   >
> > >>>>>>>>   >
> > >>>>>>>>
> > >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> > >>>>>> SE+Feature+Rank<
> > >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+
> > >>> Ran
> > >>> k>
> > >>>>>>>   >   ing
> > >>>>>>>>   >   >
> > >>>>>>>>   >
> > >>>>>>>>
> > >>>>>>>>
> > >>
> > >>
> > >
> >
> >
> >
> > --
> > Christian Kaltepoth
> > Blog: http://chkal.blogspot.com/
> > Twitter: http://twitter.com/chkal
> >
>

AW: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Arne Limburg <ar...@openknowledge.de>.

Basically we are discussing, if the access control logic goes into a class that implements an interface (which is AccessDecisionVoter) or into a method that is annotated with @Secures.

Note that both approaches can be built with the other.

I prefer the second way since it looks more like the CDI way.

Another option is to provide both APIs. Then we only would have to decide which one is "core" and which one is based on the other.

Cheers,
Arne

-----Ursprüngliche Nachricht-----
Von: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
Gesendet: Mittwoch, 1. Februar 2012 08:54
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

@christian: that's correct. but the advantage of using custom annotation arguments can't be used any more.

and that's also one of my concerns - simple cases work (but also simple cases are more complex than the usage of @Secured) and such "advanced"
use-cases are restricted.

>in some cases it's worth to add more complexity, because it makes sense
for supporting advanced use-cases!<
but right now i don't see it here.

it would be possible to extend the approach of @Secured.

examples:

#1

//...
@Secured(MyAccessDecisionVoter.class)
public class SecuredBean
{
    //...
}

users who prefer custom annotations can use stereotypes:

#2
//...
@Admin
public class SecuredBean
{
    //...
}

//...
@Stereotype
@Secured(AdminAccessDecisionVoter.class)
public @interface Admin
{
}

#3
//...
//...
@AdminOrUser
public class SecuredBean
{
    //...
}

a)
//...
@Stereotype
@Secured(oneOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// @Secured(allOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// ...
public @interface AdminOrUser
{
}

or

b)
//...
@Stereotype
//users could even provide a custom interceptor strategy and introduce custom versions of @OneOf or other annotations @OneOf @Secured({AdminAccessDecisionVoter.class, UserAccessDecisionVoter.class}) public @interface AdminOrUser { }

or

c)
//...
@Stereotype
@Secured(value = {AdminAccessDecisionVoter.class, UserAccessDecisionVoter.class}, mode = ONE_OF) public @interface AdminOrUser { }

regards,
gerhard



2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>

> What about something like this:
>
>  public @interface AnyOf {
>      Class<? extends Annotation>[] value();  }
>
> Usage:
>
>  @AnyOf({User.class, Admin.class})
>  public void doSomething() {
>       // something
>  }
>
> It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java
> syntax. :)
>
> Christian
>
>
> 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> > Yes, that would work, but that annotation is not that nice. I would
> > have
> expected something like
> > @AnyOf({@User, @Admin})
> > which unfortunately is no valid Java syntax.
> > Instead of that someone could write something like
> > @AnyOf(role1 = @User, role2 = @Admin) which could be used like Shane
> > suggests. Sadly enough there is no easy
> way to provide a default @AnyOf annotation. So the users have to write
> their own versions any time they need one.
> >
> > Any better ideas?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> > Gesendet: Dienstag, 31. Januar 2012 22:48
> > An: deltaspike-dev@incubator.apache.org
> > Cc: Jason Porter
> > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >
> > I would approach the "or" use case by simply providing another
> annotation:
> >
> > @SecurityBindingType
> > @Retention(RetentionPolicy.**RUNTIME)
> > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> AdminOrUser {
> >
> > }
> >
> >
> > public boolean @Secures @AdminOrUser isAdminOrUser() {
> >   return isAdmin() || isUser();
> > }
> >
> >
> >
> >
> > On 01/02/12 07:44, Jason Porter wrote:
> >> Looks like I responded to the wrong thread as well.
> >>
> >> I personally like the binding approach a little better. It seems to
> >> be more similar to the CDI way of doing interceptors (which, at the
> >> end of the day is essentially what we're doing). However, we have
> >> seen a need of doing @Admin || @User or @Admin&&  @User. The and is
> >> fairly easy, but the or is currently not covered and we need to be
> >> able to do
> that.
> >>
> >> I'm pretty much at a +0 for both as well. As long as we have a way
> >> of doing the feature I described above, I don't really care which
> >> way we
> go.
> >>
> >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> >> <ge...@gmail.com>wrote:
> >>
> >>> hi shane,
> >>>
> >>> that's one of the reasons why i won't block it right now.
> >>> if the majority prefers custom annotations, we should just
> >>> introduce it
> >>>> after<  v0.1 and prototype the missing parts (and test it with
> >>>> the
> >>> supported servers).
> >>>
> >>> my vote is +0 right now (for both).
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
> >>>
> >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> >>>>
> >>>>> hi mark,
> >>>>>
> >>>>> thx for the heads-up. i just talked with shane about all those
> details.
> >>>>>
> >>>>> i don't see an issue with view-configs. codi just extracts the
> >>>>> @Secured annotation during the bootstrapping process in case of
> view-configs.
> >>> that
> >>>>> would be the "same" for such custom annotations meta-annotated
> >>>>> with @SecurityBindingType.
> >>>>>
> >>>>> what we need in case of intercepted beans:
> >>>>> 1) access to InvocationContext
> >>>>> 2) easy access to the information if a security check is
> >>>>> on-going
> >>>>> 3) possibility to configure a default error-view (needed later
> >>>>> on)
> >>>>> 4) possibility to provide a custom message + an integration with
> >>>>> the upcoming i18n module
> >>>>>
> >>>>> shane said that it should be possible to add all needed features.
> >>>>> (for
> >>> me
> >>>>> that means we need a prototype if the majority prefers custom
> >>>>> annotations.)
> >>>>>
> >>>>> in the end both approaches are similar. both are generic enough
> >>>>> to integrate 3rd party security frameworks.
> >>>>>
> >>>>> @SecurityBindingType is just more generic and users need an
> >>>>> additional step to find secured beans (/views) in a project.
> >>>>> furthermore, meta-data inheritance with the mentioned
> >>>>> view-configs is a bit harder for users.
> >>>>> imo it's just a matter of taste. custom annotations as
> >>>>> additional indirection vs. a specific annotation with inline information.
> >>>>>
> >>>>> with the approach provided by codi, users can't introduce a
> >>>>> custom annotation. however, i know a lot of users who prefer one
> >>>>> given
> >>> annotation
> >>>>> instead of implementing x custom annotations. and i guess shane
> >>>>> knows a lot of users who prefer custom annotations. the goal of
> >>>>> codi was to make it easy, intuitive and flexible enough to
> >>>>> integrate 3rd party security-frameworks (instead of creating a
> >>>>> new security-framework). i wouldn't block the custom annotation
> >>>>> approach if 1)-4) are possible -
> >>> it's
> >>>>> a bit more flexible but also a bit more complex for users.
> >>>>>
> >>>> The beauty with the custom annotations is, if you like you can
> >>>> just
> >>> define
> >>>> a single annotation if you want and use that throughout your
> application.
> >>>>   I.e. you could similate the behavior of CODI:
> >>>>
> >>>>
> >>>> @SecurityBindingType
> >>>> @Retention(RetentionPolicy.**RUNTIME)
> >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> >>>> Secured {
> >>>>   @Nonbinding Class[] voters() default {};
> >>>>
> >>>> }
> >>>>
> >>>>
> >>>>> regards,
> >>>>> gerhard
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
> >>>>>
> >>>>>   Gerhard, for explaining this you will probably need to also
> >>>>> explain the
> >>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
> >>>>>> annotations, you would loose lots of functionality in this area.
> >>>>>>
> >>>>>> I know that this is not the current topic, but discussing
> >>>>>> security mechanisms without discussing the stuff which needs to
> >>>>>> get secured is only half of the truth ;)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [1]
> >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> >>>>>> JSFUsage-TypesafeViewConfig<
> >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeVi
> >>> ewC
> >>> onfig
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>
> >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> >>> gerhard.petracek@gmail.com>
> >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> >>> deltaspike-dev@incubator.apache.org>
> >>>>>>> Cc:
> >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
> >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>>>>>>
> >>>>>>> in case of myfaces codi it's also used for secured view and it
> >>>>>>> is integrated with the default-error-view concept (as
> >>>>>>> mentioned in the
> >>>>>>>
> >>>>>> ticket
> >>>>>>
> >>>>>>> we will postpone this part).
> >>>>>>> furthermore it's used by codi-scopes to avoid a different
> >>>>>>> expiration behaviour of beans cause by a security check (see
> >>>>>>> the mentioned AccessDecisionVoterContext).
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> gerhard
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> >>> arne.limburg@openknowledge.de>
> >>>>>>>    Hi,
> >>>>>>>>   My first objection when I saw the CODI feature the first
> >>>>>>>> time, was
> >>>>>>>>
> >>>>>>> that it
> >>>>>>>   maybe is too basic: When I have to implement the Voter
> >>>>>>> anyway (or my
> >>>>>>>>   security-framework of choice delivers it), why should I use
> >>>>>>>> @Secured at
> >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured
> >>>>>>>> over a
> >>> custom
> >>>>>>>>   annotation implemented by myself or delivered by my
> >>> security-framework
> >>>>>>> of
> >>>>>>>   choice.
> >>>>>>>>   The only benefit I see is when using different security
> >>>>>>>> sources, but
> >>>>>>>>
> >>>>>>> this
> >>>>>>>   is a rare use case imho.
> >>>>>>>>   Cheers,
> >>>>>>>>   Arne
> >>>>>>>>
> >>>>>>>>   -----Ursprüngliche Nachricht-----
> >>>>>>>>   Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
> >>> gerhard.petracek@gmail.com>
> >>>>>>>> ]
> >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
> >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> >>> deltaspike-dev@incubator.apache.org>
> >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64]
> >>>>>>>> @Secured
> >>>>>>>>
> >>>>>>>>   that's one option. a 2nd option is to use a
> >>> deltaspike-security-impl.
> >>>>>>>>   module which can provide e.g. an adapter for 3rd party
> >>>>>>>>
> >>>>>>> security-framework.
> >>>>>>>   or users just add a possible deltaspike-add-on provided by
> >>>>>>> an
> >>> external
> >>>>>>>>   community e.g. by a security-framework itself.
> >>>>>>>>
> >>>>>>>>   regards,
> >>>>>>>>   gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
> >>>>>>>>
> >>>>>>>>   >   Is it up to the developer to define the bean that
> implements an
> >>>>>>>>   interface?
> >>>>>>>>   >
> >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
> >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
> >>>>>>>>   >
> >>>>>>>>   >   >   hi @ all,
> >>>>>>>>   >   >
> >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
> starting point
> >>>>>>>>
> >>>>>>> for
> >>>>>>>
> >>>>>>>>   >   >   the security-api discussion, because the basic idea
> behind it
> >>> is
> >>>>>>> a
> >>>>>>>
> >>>>>>>>   >   >   very thin integration layer (which can be used by other
> >>>>>>>> modules).
> >>>>>>>>   >   >
> >>>>>>>>   >   >   the basic concept:
> >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure the
> target
> >>>>>>>>   method/s.
> >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
> specific
> >>>>>>>>
> >>>>>>> interface
> >>>>>>>
> >>>>>>>>   >   >   and therefore has access to the InvocationContext.
> >>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<
> be
> >>>>>>>>
> >>>>>>> used to
> >>>>>>>
> >>>>>>>>   >   integrate
> >>>>>>>>   >   >   3rd party security-frameworks.
> >>>>>>>>   >   >   [1] provides a bit more details of the basic concept as
> well
> >>> as
> >>>>>>> the
> >>>>>>>
> >>>>>>>>   >   >   basic usage of @Secured.
> >>>>>>>>   >   >
> >>>>>>>>   >   >   please send
> >>>>>>>>   >   >   +1, +0 or -1 because...
> >>>>>>>>   >   >   for the>basic concept<.
> >>>>>>>>   >   >
> >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
> discuss
> >>>>>>>>
> >>>>>>> details e.g.
> >>>>>>>
> >>>>>>>>   >   >   further objections about the concrete implementation
> (e.g.
> >>>>>>>>
> >>>>>>> internal
> >>>>>>>
> >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
> concept.)
> >>>>>>>>   >   >
> >>>>>>>>   >   >   regards,
> >>>>>>>>   >   >   gerhard
> >>>>>>>>   >   >
> >>>>>>>>   >   >   [1]
> https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> >>>>>>>>   >   >   [2]
> >>>>>>>>   >   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >>>>>> SE+Feature+Rank<
> >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+
> >>> Ran
> >>> k>
> >>>>>>>   >   ing
> >>>>>>>>   >   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>>>
> >>
> >>
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>

Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured

Posted by Gerhard Petracek <ge...@gmail.com>.

@christian: that's correct. but the advantage of using custom annotation
arguments can't be used any more.

and that's also one of my concerns - simple cases work (but also simple
cases are more complex than the usage of @Secured) and such "advanced"
use-cases are restricted.

>in some cases it's worth to add more complexity, because it makes sense
for supporting advanced use-cases!<
but right now i don't see it here.

it would be possible to extend the approach of @Secured.

examples:

#1

//...
@Secured(MyAccessDecisionVoter.class)
public class SecuredBean
{
    //...
}

users who prefer custom annotations can use stereotypes:

#2
//...
@Admin
public class SecuredBean
{
    //...
}

//...
@Stereotype
@Secured(AdminAccessDecisionVoter.class)
public @interface Admin
{
}

#3
//...
//...
@AdminOrUser
public class SecuredBean
{
    //...
}

a)
//...
@Stereotype
@Secured(oneOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// @Secured(allOf = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class})
// ...
public @interface AdminOrUser
{
}

or

b)
//...
@Stereotype
//users could even provide a custom interceptor strategy and introduce
custom versions of @OneOf or other annotations
@OneOf
@Secured({AdminAccessDecisionVoter.class, UserAccessDecisionVoter.class})
public @interface AdminOrUser
{
}

or

c)
//...
@Stereotype
@Secured(value = {AdminAccessDecisionVoter.class,
UserAccessDecisionVoter.class}, mode = ONE_OF)
public @interface AdminOrUser
{
}

regards,
gerhard



2012/2/1 Christian Kaltepoth <ch...@kaltepoth.de>

> What about something like this:
>
>  public @interface AnyOf {
>      Class<? extends Annotation>[] value();
>  }
>
> Usage:
>
>  @AnyOf({User.class, Admin.class})
>  public void doSomething() {
>       // something
>  }
>
> It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java syntax. :)
>
> Christian
>
>
> 2012/1/31 Arne Limburg <ar...@openknowledge.de>:
> > Yes, that would work, but that annotation is not that nice. I would have
> expected something like
> > @AnyOf({@User, @Admin})
> > which unfortunately is no valid Java syntax.
> > Instead of that someone could write something like
> > @AnyOf(role1 = @User, role2 = @Admin)
> > which could be used like Shane suggests. Sadly enough there is no easy
> way to provide a default @AnyOf annotation. So the users have to write
> their own versions any time they need one.
> >
> > Any better ideas?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Shane Bryzak [mailto:sbryzak@redhat.com]
> > Gesendet: Dienstag, 31. Januar 2012 22:48
> > An: deltaspike-dev@incubator.apache.org
> > Cc: Jason Porter
> > Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >
> > I would approach the "or" use case by simply providing another
> annotation:
> >
> > @SecurityBindingType
> > @Retention(RetentionPolicy.**RUNTIME)
> > @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> AdminOrUser {
> >
> > }
> >
> >
> > public boolean @Secures @AdminOrUser isAdminOrUser() {
> >   return isAdmin() || isUser();
> > }
> >
> >
> >
> >
> > On 01/02/12 07:44, Jason Porter wrote:
> >> Looks like I responded to the wrong thread as well.
> >>
> >> I personally like the binding approach a little better. It seems to be
> >> more similar to the CDI way of doing interceptors (which, at the end
> >> of the day is essentially what we're doing). However, we have seen a
> >> need of doing @Admin || @User or @Admin&&  @User. The and is fairly
> >> easy, but the or is currently not covered and we need to be able to do
> that.
> >>
> >> I'm pretty much at a +0 for both as well. As long as we have a way of
> >> doing the feature I described above, I don't really care which way we
> go.
> >>
> >> On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
> >> <ge...@gmail.com>wrote:
> >>
> >>> hi shane,
> >>>
> >>> that's one of the reasons why i won't block it right now.
> >>> if the majority prefers custom annotations, we should just introduce
> >>> it
> >>>> after<  v0.1 and prototype the missing parts (and test it with the
> >>> supported servers).
> >>>
> >>> my vote is +0 right now (for both).
> >>>
> >>> regards,
> >>> gerhard
> >>>
> >>>
> >>>
> >>> 2012/1/31 Shane Bryzak<sb...@redhat.com>
> >>>
> >>>> On 01/02/12 00:21, Gerhard Petracek wrote:
> >>>>
> >>>>> hi mark,
> >>>>>
> >>>>> thx for the heads-up. i just talked with shane about all those
> details.
> >>>>>
> >>>>> i don't see an issue with view-configs. codi just extracts the
> >>>>> @Secured annotation during the bootstrapping process in case of
> view-configs.
> >>> that
> >>>>> would be the "same" for such custom annotations meta-annotated with
> >>>>> @SecurityBindingType.
> >>>>>
> >>>>> what we need in case of intercepted beans:
> >>>>> 1) access to InvocationContext
> >>>>> 2) easy access to the information if a security check is on-going
> >>>>> 3) possibility to configure a default error-view (needed later on)
> >>>>> 4) possibility to provide a custom message + an integration with
> >>>>> the upcoming i18n module
> >>>>>
> >>>>> shane said that it should be possible to add all needed features.
> >>>>> (for
> >>> me
> >>>>> that means we need a prototype if the majority prefers custom
> >>>>> annotations.)
> >>>>>
> >>>>> in the end both approaches are similar. both are generic enough to
> >>>>> integrate 3rd party security frameworks.
> >>>>>
> >>>>> @SecurityBindingType is just more generic and users need an
> >>>>> additional step to find secured beans (/views) in a project.
> >>>>> furthermore, meta-data inheritance with the mentioned view-configs
> >>>>> is a bit harder for users.
> >>>>> imo it's just a matter of taste. custom annotations as additional
> >>>>> indirection vs. a specific annotation with inline information.
> >>>>>
> >>>>> with the approach provided by codi, users can't introduce a custom
> >>>>> annotation. however, i know a lot of users who prefer one given
> >>> annotation
> >>>>> instead of implementing x custom annotations. and i guess shane
> >>>>> knows a lot of users who prefer custom annotations. the goal of
> >>>>> codi was to make it easy, intuitive and flexible enough to
> >>>>> integrate 3rd party security-frameworks (instead of creating a new
> >>>>> security-framework). i wouldn't block the custom annotation
> >>>>> approach if 1)-4) are possible -
> >>> it's
> >>>>> a bit more flexible but also a bit more complex for users.
> >>>>>
> >>>> The beauty with the custom annotations is, if you like you can just
> >>> define
> >>>> a single annotation if you want and use that throughout your
> application.
> >>>>   I.e. you could similate the behavior of CODI:
> >>>>
> >>>>
> >>>> @SecurityBindingType
> >>>> @Retention(RetentionPolicy.**RUNTIME)
> >>>> @Target({ElementType.TYPE, ElementType.METHOD}) public @interface
> >>>> Secured {
> >>>>   @Nonbinding Class[] voters() default {};
> >>>>
> >>>> }
> >>>>
> >>>>
> >>>>> regards,
> >>>>> gerhard
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/1/31 Mark Struberg<st...@yahoo.de>
> >>>>>
> >>>>>   Gerhard, for explaining this you will probably need to also
> >>>>> explain the
> >>>>>> TypeSafe Navigation as we have it in CODI [1].By using custom
> >>>>>> annotations, you would loose lots of functionality in this area.
> >>>>>>
> >>>>>> I know that this is not the current topic, but discussing security
> >>>>>> mechanisms without discussing the stuff which needs to get secured
> >>>>>> is only half of the truth ;)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [1]
> >>>>>> https://cwiki.apache.org/**EXTCDI/jsf-usage.html#**
> >>>>>> JSFUsage-TypesafeViewConfig<
> >>> https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewC
> >>> onfig
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>
> >>>>>>> From: Gerhard Petracek<gerhard.petracek@**gmail.com<
> >>> gerhard.petracek@gmail.com>
> >>>>>>> To: deltaspike-dev@incubator.**apache.org<
> >>> deltaspike-dev@incubator.apache.org>
> >>>>>>> Cc:
> >>>>>>> Sent: Tuesday, January 31, 2012 1:31 PM
> >>>>>>> Subject: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>>>>>>
> >>>>>>> in case of myfaces codi it's also used for secured view and it is
> >>>>>>> integrated with the default-error-view concept (as mentioned in
> >>>>>>> the
> >>>>>>>
> >>>>>> ticket
> >>>>>>
> >>>>>>> we will postpone this part).
> >>>>>>> furthermore it's used by codi-scopes to avoid a different
> >>>>>>> expiration behaviour of beans cause by a security check (see the
> >>>>>>> mentioned AccessDecisionVoterContext).
> >>>>>>>
> >>>>>>> regards,
> >>>>>>> gerhard
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2012/1/31 Arne Limburg<arne.limburg@**openknowledge.de<
> >>> arne.limburg@openknowledge.de>
> >>>>>>>    Hi,
> >>>>>>>>   My first objection when I saw the CODI feature the first time,
> >>>>>>>> was
> >>>>>>>>
> >>>>>>> that it
> >>>>>>>   maybe is too basic: When I have to implement the Voter anyway
> >>>>>>> (or my
> >>>>>>>>   security-framework of choice delivers it), why should I use
> >>>>>>>> @Secured at
> >>>>>>>>   all? I mean, what is the REAL benefit of using @Secured over a
> >>> custom
> >>>>>>>>   annotation implemented by myself or delivered by my
> >>> security-framework
> >>>>>>> of
> >>>>>>>   choice.
> >>>>>>>>   The only benefit I see is when using different security
> >>>>>>>> sources, but
> >>>>>>>>
> >>>>>>> this
> >>>>>>>   is a rare use case imho.
> >>>>>>>>   Cheers,
> >>>>>>>>   Arne
> >>>>>>>>
> >>>>>>>>   -----Ursprüngliche Nachricht-----
> >>>>>>>>   Von: Gerhard Petracek [mailto:gerhard.petracek@**gmail.com<
> >>> gerhard.petracek@gmail.com>
> >>>>>>>> ]
> >>>>>>>>   Gesendet: Dienstag, 31. Januar 2012 13:14
> >>>>>>>>   An: deltaspike-dev@incubator.**apache.org<
> >>> deltaspike-dev@incubator.apache.org>
> >>>>>>>>   Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> >>>>>>>>
> >>>>>>>>   that's one option. a 2nd option is to use a
> >>> deltaspike-security-impl.
> >>>>>>>>   module which can provide e.g. an adapter for 3rd party
> >>>>>>>>
> >>>>>>> security-framework.
> >>>>>>>   or users just add a possible deltaspike-add-on provided by an
> >>> external
> >>>>>>>>   community e.g. by a security-framework itself.
> >>>>>>>>
> >>>>>>>>   regards,
> >>>>>>>>   gerhard
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>   2012/1/31 John D. Ament<jo...@gmail.com>
> >>>>>>>>
> >>>>>>>>   >   Is it up to the developer to define the bean that
> implements an
> >>>>>>>>   interface?
> >>>>>>>>   >
> >>>>>>>>   >   On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek<
> >>>>>>>>   >   gerhard.petracek@gmail.com>   wrote:
> >>>>>>>>   >
> >>>>>>>>   >   >   hi @ all,
> >>>>>>>>   >   >
> >>>>>>>>   >   >   imo this feature of myfaces codi-core is a nice
> starting point
> >>>>>>>>
> >>>>>>> for
> >>>>>>>
> >>>>>>>>   >   >   the security-api discussion, because the basic idea
> behind it
> >>> is
> >>>>>>> a
> >>>>>>>
> >>>>>>>>   >   >   very thin integration layer (which can be used by other
> >>>>>>>> modules).
> >>>>>>>>   >   >
> >>>>>>>>   >   >   the basic concept:
> >>>>>>>>   >   >   a cdi interceptor invokes (inline) voters to secure the
> target
> >>>>>>>>   method/s.
> >>>>>>>>   >   >   a voter is a (custom) cdi bean which implements a
> specific
> >>>>>>>>
> >>>>>>> interface
> >>>>>>>
> >>>>>>>>   >   >   and therefore has access to the InvocationContext.
> >>>>>>>>   >   >   furthermore, a voter detects 0-n violations and>can<
> be
> >>>>>>>>
> >>>>>>> used to
> >>>>>>>
> >>>>>>>>   >   integrate
> >>>>>>>>   >   >   3rd party security-frameworks.
> >>>>>>>>   >   >   [1] provides a bit more details of the basic concept as
> well
> >>> as
> >>>>>>> the
> >>>>>>>
> >>>>>>>>   >   >   basic usage of @Secured.
> >>>>>>>>   >   >
> >>>>>>>>   >   >   please send
> >>>>>>>>   >   >   +1, +0 or -1 because...
> >>>>>>>>   >   >   for the>basic concept<.
> >>>>>>>>   >   >
> >>>>>>>>   >   >   (please add>basic<   objections also to [2]. we can
> discuss
> >>>>>>>>
> >>>>>>> details e.g.
> >>>>>>>
> >>>>>>>>   >   >   further objections about the concrete implementation
> (e.g.
> >>>>>>>>
> >>>>>>> internal
> >>>>>>>
> >>>>>>>>   >   >   classes,...) as soon as we agreed on including this
> concept.)
> >>>>>>>>   >   >
> >>>>>>>>   >   >   regards,
> >>>>>>>>   >   >   gerhard
> >>>>>>>>   >   >
> >>>>>>>>   >   >   [1]
> https://issues.apache.org/**jira/browse/DELTASPIKE-64<
> >>> https://issues.apache.org/jira/browse/DELTASPIKE-64>
> >>>>>>>>   >   >   [2]
> >>>>>>>>   >   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>> https://cwiki.apache.org/**confluence/display/DeltaSpike/**
> >>>>>> SE+Feature+Rank<
> >>> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ran
> >>> k>
> >>>>>>>   >   ing
> >>>>>>>>   >   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>>>
> >>
> >>
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>