deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Wed, 01 Feb 2012 11:34:58 GMT
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 <sbryzak@redhat.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: Christian Kaltepoth <christian@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<arne.limburg@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
>>>>  <gerhard.petracek@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<sbryzak@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<struberg@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<john.d.ament@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
>>>>>>>>>>     >     >
>>>>>>>>>>     >
>>>>>>>>>> 
>>>>>>>>>> 
>>>> 
>> 
>> 
> 

Mime
View raw message