incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Wed, 01 Feb 2012 14:07:38 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message