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 Tue, 31 Jan 2012 13:51:42 GMT
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