machine501

Update: The “start”-method-not-getting-called bug is now a filed in the adobe bug tracker: http://bugs.adobe.com/jira/browse/BLZ-190

This post is another baby step in getting acegi/spring security and blazeds to work together. The whole purpose of these exercises is to for acegi to handle authentication/authorization and destination security. Even bypassing container security.

In the last part I talked about how I was stumped by the LoginCommand and how the “start” method is never called. The reason I want the start method to be called is so that I am passed a ServletConfig and from there I can get access to the ServletContext, and thereby access to the Spring WebApplicationContext but unfortunately this method never seems to get called. I traced the BlazeDS source in SVN, not very thoroughly I should admit, and never found a spot where the start method gets called.

That’s not such a big deal because I can get access to the ServletContext by using the FlexContext singleton. I’m not generally a fan of singletons but what the hell; if it gets it to work =p

Anyway, here’s a brief outline of my AcegiLoginCommand, which extends AppServerLoginCommand:

.. class AcegiLoginCommand extends AppServerLoginCommand …

public AcegiLoginCommand() {
    initAuthenticationManager();
}

private void initAuthenticationManager()
{
    ServletContext servletContext = FlexContext.getServletContext();
    String beanId = servletContext.getInitParameter("loginCommandBean");

    if (beanId == null) {
        beanId = "authenticationManager";
    }

    WebApplicationContext context =
        WebApplicationContextUtils.getWebApplicationContext(servletContext);

    authenticationManager = (AuthenticationManager)context.getBean(beanId);

    if (authenticationManager == null) {
      throw new RuntimeException("AuthenticationManager could not be found.  Tried beanId='"+ beanId+"'");
    }
}

The LoginCommand needs access t othe authenticationManager so that it can pass it call the manager’s “authenticate” method. To make it more configurable, I added a little bit of code that will get the bean name from a web.xml init-parameter.

Finally, my “doAuthentication” method looks like this:

public Principal doAuthentication(String username, Object password) {
  Authentication authentication =
        new UsernamePasswordAuthenticationToken(username, password);
  authentication = authenticationManager.authenticate(authentication);
  SecurityContextHolder.getContext().setAuthentication(authentication);

  return (Principal)authentication;
}

I don’t need to override doAuthorization because when I’m doing MethodSecurityInterceptor, that class takes care of looking at the Authentication token’s “GrantedAuthority”es to see if they can execute the method.

That’s pretty much it. I need to figure out the extent of the security integration. I know that at the moment the authentication will not work on RTMP channels.

A good explanation and example for Spring and BlazeDS is important for driving adoption of BlazeDS into environments that run on Java. I know a potential client of mine is looking into using BlazeDS as a transport layer for a product they have running on a Tomcat container. They want to try following established practices in Java and want to use off-the-shelf, tried-and-true technologies like Spring and Hibernate, and having information on using these with BlazeDS would make them more confident when adopting BlazeDS.

Hope this helps. Also, I just found out someone else had documented a similar approach at this blog post:

http://blog.f4k3.net/fake/entry/acegi_logincommand_for_fds

This entry was posted on Sunday, June 1st, 2008 at 3:50 pm and is filed under blazeds, flex, java, technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.