Cairngorm 2 Security

It’s great to finally see Cairgorm 2 on Adobe Labs. To mark the occassion I thought I would post some code I developed a while back to allow Cairngorm to use secured server-side destinations.

On the server you can configure security contraints in services-config.xml as per the following example , alternatively you can configure security constraints in-line with your destinations.


You can then reference your security contraint in your destinations (data-management-config.xml, messaging-config.xml, proxy-config.xml and remoting-config.xml) as per the following example:


The ZIP contains the following files:

  • DestinationLocator – subclasses Cairngorm ServiceLocator to support Messaging, Data Management Services and Web Services.
  • SecureDestinationLocator – sublcasses DestinationLocator to support user authentication.

The SecureDestinationLocator class provides two public methods, setCredentials() and logout(). When you call setCredentials() the supplied username and password are set on all configured destinations. When you call logout() the user is logged out from all configured destinations. At present SecureDestinationLocator doesn’t support remote credentials or setting credentials on individual destinations.

When you set the user’s credentials on a service they are applied to the underlying channel not the individual services i.e. the set of services belonging to the channel share the samecredentials.

The SecureDestinationLocator will allow you to create a custom login form in your application and use the underlying J2EE security model. The benefits to your application are that you can apply authentication to your server-side destinations and also use role-based authorization. If you are developing a more complex enterprise application, which may have mid-tier business logic that is held in EJBs the user principal, which is created on authentication will be propagated. This allows you to identify the user and to secure you EJBs. The motivation to secure your server-side services often comes from the need to protect your system from malicious hackers, which forces many enterprise applications to undergo penetration testing before they can enter production.

On a wider enterprise scale many of today’s J2EE-application servers support Single Sign On (SSO) and integration with Identity Management Solutions.