incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Kaltepoth <christ...@kaltepoth.de>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Wed, 01 Feb 2012 06:13:01 GMT
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
>>>>>>>>   >   >
>>>>>>>>   >
>>>>>>>>
>>>>>>>>
>>
>>
>



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

Mime
View raw message