4.5. Value Additions for Simple Remoting

In this section, you will learn to extend the remoting facility in BlazeDS to include a couple of additional features that add value on top of what is already available. This is not a section that illustrates every possible extension scenario. It simply can't, as there are too many possible cases. Many of the subsequent chapters in this book pick up some of these customization and extension topics individually.

The topics covered in this section pertain only to the following:

• Custom security implementation

• Extension of the JavaAdapter to include an interception point

4.5.1. Custom Security Implementation

You already know many things about the BlazeDS security from the section on configuration in this chapter and from the last chapter. Here, you will learn how to extend the standard model and implement a custom security model.

BlazeDS has built-in security implementations for most mainstream application servers, including the following:

• Tomcat

• JBoss

• Weblogic

• Websphere

• Oracle AS

• JRun

However, if you happen to use any of the other alternatives, including:

• Glassfish

• Geronimo

• ATG Dynamo

Or, if you like to delegate security to an underlying framework such as Spring or an independent identity manager, then you have a little work to do before things are ready for use.

BlazeDS security implements ways to authenticate and authorize users. Authentication identifies a user, and authorization makes sure the user engages only in permitted actions.

BlazeDS deploys within a Servlet container and a Java EE application server and so delegates its authentication and authorization as far as possible to the underlying server infrastructure. Therefore, the interface that defines the LoginCommand has an abstract implementation in AppServerLoginCommand, and this abstract implementation forms the basis for the application-server-specific implementations. Figure 4-9 depicts this.

Figure 4.9. Figure 4-9

So, the first extension point could possibly be the AppServerLoginCommand itself. The abstract class implements authorization by means of a set of overloaded methods. The first of these takes principal and a list of roles as parameters, and the second one takes an HttpServletRequest as an additional parameter. The authorization command relies on the isUserInRole method of the HttpServletRequest object to check if the user's group or role has the correct permissions for the action. The isUserInRole method returns a Boolean value and acts as a guard for authorization verification.

So an implementation for Glassfish or Geronimo could be implemented by extending the AppServerLoginCommand. With Geronimo, you will also be able to use the TomcatLoginCommand out of the box, and using the TomcatLoginCommand with Glassfish would only require a few small changes. The Glassfish web server is quite similar to Tomcat and uses the concept of "Value" and the associated pipeline like Tomcat. There are a few differences between the two though.

Tomcat's Value interface, org.apache.catalina.Value, defines an invoke method that takes a request and a response object as its parameters. The invocation in Tomcat follows a three-step process: pre-processing, invocation of the next value, and post-processing. This gets repeated for each value in the pipeline.

Glassfish improves on this single invocation model and provides two points of invocation, one called invoke and another postInvoke. The calls to invoke and postInvoke can go on to the next value in the chain or return the call to the container and stop the chain of execution.

BlazeDS security implementation implements a TomcatLogin interface to support the concept of Value.

Spring security can also be implemented by extending the AppServerLoginCommand, in the same way that it is extended to support additional application server security models. You will learn more about Spring security in the next chapter.

BlazeDS provides all security concerns within a FlexContext. FlexContext exposes the current execution context. You know that BlazeDS can be made to authenticate on a per-client or per-session basis. In the case of per-client authentication, FlexClient, which represents a client on the server, comes, handy. On the other hand, FlexSession, which represents a Flex session on the server, comes, handy when authentication is set on a per-session basis. In both cases, the authentication and authorization involve the J2EE session concept. Therefore, stateless architectures in BlazeDS, which require authentication for every request, will need a lot more work. By default, an authenticated session will be allowed to go ahead, and this may disrupt an "authenticate every time" model.

When implementing a security scheme that does not use J2EE security at all, remember to plug all the pieces in around passing of credentials and handling of exceptions. When delegating the security scheme to the underlying JEE application server, the propagation of credentials from the client to the server and the mapping to the application server roles is implicit and does not require additional work on the part of the developer. Use the ChannelSet for such interactions with the server-side security provider.

Although you need to wait a little more before you see a full implementation of a custom security scheme, this section should have given you a sense of how to go about implementing security.

Next, we explore how to create a generic interception point for the JavaAdapter.

4.5.2. An Interceptor for the JavaAdapter

A Java adapter is a BlazeDS class that sits between the remoting service destination and the actual POJO on the server. Acting as the last interception layer before the Java object, it is responsible for the invocation of a Java method. The adapter itself is stateless and is instantiated every time on a request. Adapter instances can be bound to a session if explicitly configured to do so.

The JavaAdapter class extends flex.messaging.services.ServiceAdapter. Every message passing through the adapter is intercepted and handled by the invoke method of the adapter. The invoke method has the following signature:

public Object invoke(Message message)

So, adding a generic interceptor in this adapter could imply including it within the invoke method. Thus, every passing message would give the interceptor a chance to add the additional value if it needs to.

Let's walk through the invoke method code and understand its flow. That will help you find the right place to introduce the interceptor. The invoke method goes through the following flow:

• First get a reference to the destination to which the adapter is configured.

• Then cast the message as a RemotingMessage.

• Get the operations and its parameters with the help of the remoting message.

• Run the operations through the include and exclude list to ensure that the right credentials exist for method invocation.

• Invoke the method.

• Cache the invoked method to the session if the adapter is stateful.

An interception point could be introduced anywhere in this flow, but at pre-invocation seems like a good time to introduce it.

This approach assumes, though, that you would like to intercept the call close enough to the Java object itself. Alternatively, you could set up interception layers closer to the point where the data moves between Flex and BlazeDS or close to the destination invocation.

In the next chapter, you will also learn to use Aspect-Oriented Programming (AOP) in conjunction with Spring and BlazeDS, which would provide yet another way to manage a generic interception framework.