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 Wed, 01 Feb 2012 13:52:19 GMT
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 <gerhard.petracek@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 <arne.limburg@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 <christian@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 <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-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<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+Featu
>> > >>> re+
>> > >>> Ran
>> > >>> k>
>> > >>>>>>>   >   ing
>> > >>>>>>>>   >   >
>> > >>>>>>>>   >
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> > --
>> > Christian Kaltepoth
>> > Blog: http://chkal.blogspot.com/
>> > Twitter: http://twitter.com/chkal
>> >
>>
>
>

Mime
View raw message