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 08:42:32 GMT
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-TypesafeVi
> >>> 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+Feature+
> >>> Ran
> >>> k>
> >>>>>>>   >   ing
> >>>>>>>>   >   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>>>
> >>
> >>
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>

Mime
View raw message