deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Tue, 31 Jan 2012 14:21:53 GMT
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.

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
>
>
>
> ----- Original Message -----
> > From: Gerhard Petracek <gerhard.petracek@gmail.com>
> > To: 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>
> >
> >>  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]
> >>  Gesendet: Dienstag, 31. Januar 2012 13:14
> >>  An: 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
> >>  > > [2]
> >>  > >
> >>  >
> https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Rank
> >>  > ing
> >>  > >
> >>  >
> >>
> >
>

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