deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject AW: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Tue, 31 Jan 2012 21:56:17 GMT
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