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:57:09 GMT
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-TypesafeViewConfig>
>>>
>>>
>>>
>>> ----- 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+Rank>
>>>
>>>>  >  ing
>>>>>  >  >
>>>>>  >
>>>>>
>>>>>
>

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