deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: AW: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
Date Tue, 31 Jan 2012 13:54:19 GMT
Yes, that might well be.

Actually I did not really think about the direct implications. I just wanted to point out
that we need to think a bit further :)

LieGrue,
strub



----- Original Message -----
> From: Arne Limburg <arne.limburg@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>;
Mark Struberg <struberg@yahoo.de>
> Cc: 
> Sent: Tuesday, January 31, 2012 2:51 PM
> Subject: AW: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> 
> Hi Mark,
> 
> I don't see, why this could not be done with the Seam Security approach. We 
> can recognize security annotations via the @SecurityBindingType
> 
> Cheers,
> Arne
> 
> -----Ursprüngliche Nachricht-----
> Von: Mark Struberg [mailto:struberg@yahoo.de] 
> Gesendet: Dienstag, 31. Januar 2012 14:28
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
> 
> 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+Ran
>>>  k
>>>   > ing
>>>   > >
>>>   >
>>> 
>> 
> 

Mime
View raw message