I remember going through the Acegi documentation the first time. It was
daunting.
In hindsight, it boils down to this:
The central object in Acegi is the SecurityContext. You need to store and
retrieve it from your HttpSession and that is done either through a filter
configured in web.xml (for a Spring-configured scenario), or as a part of a
Tapestry filter chain (for tapestry5-acegi).
You need to configure at least one AuthenticationProvider using a
UserDetailsService, and pass it to the AuthenticationManager. I like the
InMemoryDaoImpl as the UserDetailsService for initial development, and a way
of embedding special administrative accounts. Don't waste time reading
about all of the options for this service. Know that later you can add
additional AuthenticationProviders to have multiple authentication methods.
The AuthenticationProvider can be invoked manually (by injecting it into
your page, and calling methods like authenticate()), or via a specific jsp
page.
For example, and this can be handy for testing, you can do this:
@Inject
private AuthenticationManager _authenticationManager;
...
UsernamePasswordAuthenticationToken authRequest =
new
UsernamePasswordAuthenticationToken(_username,_password);
Authentication authResult;
try {
System.out.println("username:" + _username + "
password: " + _password);
authResult =
_authenticationManager.authenticate(authRequest);
logger.info("successful login for: " + _username);
} catch (BadCredentialsException failed) {
_form.recordError(_passwordField, "Invalid username
or password");
logger.info("bad password for: " + _username);
return null;
} catch (AuthenticationException failed) {
_form.recordError(_passwordField, "Invalid username
or password");
logger.info("failed login for: " + _username);
return null;
}
SecurityContextHolder.getContext().setAuthentication(authResult);
Then you need to enforce security (authorize). This can be directly, by
getting the SecurityContext and asking for the Authentication object, and
then getting a list of GrantedAuthorities and working with that. (Read the
code for the tapestry5-acegi IfRole component if you want to see what I
mean). Or, it can be done using Spring configured filters for URL patterns,
or tapestry5-acegi filters for pages or patterns.
It's only daunting if you look at it all at once.
Jonathan
> -----Original Message-----
> From: wesley [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 05, 2008 12:37
> To: users@tapestry.apache.org
> Subject: RE: spring T5 integration on acegi security considerations
>
>
> hi,
>
> thanks for the feedback, as long as the pages are secure and can prevent
> unauthorized users from logging in i'm open for any options. previously
> what
> i did was quite traditional, implementing a one way password encryption,
> setting keystore and config within tomcat container. to me acegi is like a
> huge topic and mass complexion to implement. so when come to the decision
> on
> implementing it is really a challenge to me. the tutorials are great but
> mostly aim at T5 alone (which is normal). but within my implementation
> where
> it is an integrated environment, i really have no idea which one should i
> choose.
>
>
> Jonathan Barker wrote:
> >
> >
> > It depends on your needs. The tapestry5-acegi or tapestry-spring-
> security
> > (http://www.localhost.nu/java/tapestry-spring-security/index.html) are
> > probably easier to drop in. The Spring-configured route might be better
> > if
> > your application includes other servlets or filters.
> >
> > Either way you will be able to get access to things like the
> > AuthenticationManager if you need to from your page classes.
> >
> > With an older T4 app, I used Spring / Hibernate / Acegi with Acegi
> > configured via Spring. I also rolled a few components: Authorize and
> > AclAuthorize.
> >
> > With the T5 apps I now do, I use a slightly modified tapestry5-acegi
> > although I still use Spring for DAO's and some services. Parts of my
> old
> > Authorize component are now included in the tapestry5-acegi IfRole
> > component.
> >
> > Actually, I think tapestry5-acegi and its successor would benefit from
> > being
> > split in two: one piece for the annotations, components and supporting
> > pieces that are specific to Tapestry, and the second piece to allow for
> a
> > choice of configuration via Spring, or configuration via tapestry-ioc.
> >
> > Whichever way you choose, it's better than re-inventing the wheel and
> > rolling your own security.
> >
> > Jonathan
> >
> >
> >> -----Original Message-----
> >> From: wesley [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, October 03, 2008 10:59
> >> To: users@tapestry.apache.org
> >> Subject: spring T5 integration on acegi security considerations
> >>
> >>
> >> hi all,
> >>
> >> i've been implementing a project by using T5 mostly as front end,
> spring
> >> framework for back(eg Dao and db operations). after few search on it
> >> regarding the acegi implementation, i'm a little bit confused as
> whether
> >> or
> >> not to implement this security framework on T5 or spring. any
> >> recommendations or advise on this topic? should i just apply this
> >> security
> >> layer on T5 alone? or Spring 2 for securing the backend or both??
> >>
> >> please advise, thanks
> >>
> >> wesley
> >> --
> >> View this message in context: http://n2.nabble.com/spring-T5-
> integration-
> >> on-acegi-security-considerations-tp1142158p1142158.html
> >> Sent from the Tapestry Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context: http://n2.nabble.com/spring-T5-integration-
> on-acegi-security-considerations-tp1142158p1299013.html
> Sent from the Tapestry Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
