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 15:57:48 GMT
+1 for implementing both to see how it works out
+1 for building @Secured on top of @SecurityBindingType

Christian


2012/2/1 Jason Porter <lightguard.jp@gmail.com>:
> I'm going to put my vote in with Arne.
>
> +1 for @Secured implemented on top of @SecurityBindingType.
>
> On Wed, Feb 1, 2012 at 06:52, Arne Limburg <arne.limburg@openknowledge.de>wrote:
>
>> 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
>> >> >
>> >>
>> >
>> >
>>
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu



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

Mime
View raw message