Integrates Acegi Security System for Spring into RCP.

Overview

Acegi Security is a comprehensive open-source security system that delivers fully-featured security to Spring applications. To learn more about Acegi Security or access detailed documentation, please visit the project home page at http://acegisecurity.sourceforge.net.

It is envisaged that many RCP clients will be connecting with a remote Spring-powered server. In such deployments, security becomes of paramount importance. Whilst transport-layer security (such as HTTPS, port filtering and firewalls) are essential to almost all production applications, this package delivers comprehensive application-layer security to RCP clients by hooking into the Acegi Security project.

Background Knowledge

Whilst you should really read the Acegi Security System for Spring reference documentation to fully understand the architecture, the most important details you need to understand in order to utilize this RCP package is the summarized below.

RCP uses the following key Acegi Security classes and interfaces:

ContextHolder, which simply uses a ThreadLocal to store a SecureContext implementation.

Authentication, which stores the details of a principal, credentials and its granted authorities. RCP uses Acegi Security’s UsernamePasswordAuthenticationToken, which simply represents a username and password for the principal and credentials respectively.

AuthenticationManager, which is able to accept a “request” Authentication object (containing only the principal and credentials details), process its validity, and return a populated Authentication object (also containing the GrantedAuthorty[]s).

How Login and Logout Works

This package provides two key RCP commands: LoginCommand and LogoutCommand. To use these commands, simply add them to your commands-context.xml.

Both commands accept an optional property, displaySuccess, which default to true. This simply results in an information dialog being displayed after login or logout. You can switch this off by setting the property to false in the application context.

LoginCommand basically displays a dialog requesting the username and password. Upon these being entered, a “request” Authentication object is created (as mentioned in the “Background Knowledge” section above) and presented to the AuthenticationManager which is configured against the LoginCommand. With a little luck, a populated Authentication object is returned and this is placed onto the ContextHolder. In addition, a LoginEvent is published to the application context so other interested classes know a login has taken place.

LogoutCommand is far simpler. It simply updates the ContextHolder so its Authentication object is null. It also publishes a LogoutEvent to the application context.

Which AuthenticationManager?

As mentioned above, an AuthenticationManager is configured against the LoginCommand. This is just like any other Acegi Security use of AuthenticationManager, so you can use any of the standard Acegi Security authentication providers with the RCP package (such as DaoAuthenticationProvider).

We will now discuss the typical usage case of a remote server. In this case you need the client to ensure a username and password is valid against the remote server, and also obtain the list of GrantedAuthority[]s (so the populated Authentication object can be constructed). To achieve this, on the client you’ll need to use the RemoteAuthenticationProvider. On the server you’ll need to use the RemoteAuthenticationManagerImpl. On the client you'll use your preferred remoting proxy factory to access the server-side RemoteAuthenticationManagerImpl. You can find these classes in Acegi Security's net.sf.acegisecurity.providers.rcp package.

Remoting Integration

If your application uses Spring’s normal remoting classes to access your business objects on the server, you will probably want to register RemotingSecurityConfigurer in your application context.

RemotingSecurityConfigurer listens for login and logout events (as generated by the LoginCommand and LogoutCommand) and updates the usernames and passwords associated with any of your registered remoting proxy factories. This causes BASIC authentication to be used in the header of the remoting requests.

On the server side you will need to register Acegi Security’s BasicProcessingFilter so BASIC authentication headers can be processed. You’d need to do this if you’re using Acegi Security with any form of BASIC authentication (it is not an RCP-specific requirement).

Action Control

Coming soon... The general idea will be CommandActions listen for events and update their visibility and enable/disabled status based on delegation to a security manager. The security manager will indicate the expected state based on granted authorities held.