incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Bryzak <sbry...@redhat.com>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Wed, 01 Feb 2012 09:43:18 GMT
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<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