Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46F7BAD2.2060607@fdar.com>
Date: Mon, 24 Sep 2007 09:25:38 -0400
From: Ian Roughley <ian@fdar.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: JAAS struts 2 Tutorial?
References: <fc8bm8$oi6$1@sea.gmane.org>
 <331772.62486.qm@web38004.mail.mud.yahoo.com> <fcbcqn$9kd$1@sea.gmane.org>
 <953573.53692.qm@web38012.mail.mud.yahoo.com> <46EE91AC.2080100@abdere.com>
 <46EEADFB.5090707@gmail.com>
 <7fa59c400709180028q27f50c60k78e5ab462cf021ef@mail.gmail.com>
 <46EFFF47.8060004@fdar.com>
 <42db7f0a0709180958k5c1daa0ek71df6a5700cac36e@mail.gmail.com>
 <46F02DBC.7090505@fdar.com> <12858416.post@talk.nabble.com>
In-Reply-To: <12858416.post@talk.nabble.com>
Content-Type: multipart/alternative;
 boundary="------------080005030904000602000000"

--------------080005030904000602000000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

You can find the key features of acegi here - 
http://www.acegisecurity.org/. 

I see the advantages as being able to customize the authentication and 
authorization from within the scope of the web application, and not 
external configuration via an app server.  But then, this also depends 
on the app server.

/Ian

wild_oscar wrote:
> In the web app I'm currently developing (which uses JAAS authentication),
> I've done the following:
>
> 1) Create an HttpServletRequestWrapper to override the isUserInRole method
> 2) Create an AnnotationRoles class to annotate my actions if they require
> particular roles
> 3) Create an AnnotationRolesInterceptor (as described in this forum) to
> determine if the user has the role required by the annotation
>
> What are the advantages of using acegi over this custom implementation? And
> what is the license model of acegi?
>
>
> Ian Roughley wrote:
>   
>> If you are not using container managed persistence, where the 
>> HttpRequest values are being set in the environment, you probably don't 
>> want to use the Principal or PrincipalAware interface, or even to wrap 
>> the HttpServletRequest (this email was in response to using a servlet 
>> wrapper to re-implement code already present in s2).
>>
>> Options I've used are creating an interceptor to access the security 
>> context (I've not used JAAS personally), and then create an annotation 
>> to signify actions/methods that need security information assigned to 
>> them.  The same annotation, or another, could also be used to 
>> declaratively configure those actions that require a specific role from 
>> the security context in order to be invoked.
>>
>> /Ian
>>
>> Chris Pratt wrote:
>>     
>>> On 9/18/07, Ian Roughley <ian@fdar.com> wrote:
>>>   
>>>       
>>>> By implementing the PrincipalAware interface, the Principal object will
>>>> be injected into the action with those values from the request (the
>>>> user, roles, etc.).  The values can be be used in the action, or the
>>>> Principal can be exposed with a setter for the actions to use.
>>>>
>>>>     
>>>>         
>>> But if you don't use Container Managed Authentication, how do you get
>>> the Principal into the request so that PrincipalAware can inject it,
>>> without using a ServletFilter?
>>>   (*Chris*)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>   
>>>       
>>     
>
>   

--------------080005030904000602000000--