One of my favorite new features of Alfresco 3.2 is the concept of subsystems. Alfresco defines a subsystem as:

A configurable module responsible for a sub-part of Alfresco functionality. Typically, a subsystem wraps an optional functional area such as IMAP binding, or one with several alternative implementations, such as authentication.

In essence it’s like having mini child servers, each with its own Spring application context which makes configurability a lot more intuitive.

My first encounter with Alfresco’s subsystems was due to an AWPr jira issue that someone raised saying that STAr doesn’t work with Alfresco 3.2 because they “changed” the way authentication components are chained. To be honest my first reaction was “Oh no! More re-factoring!”. But then when I looked into how the Authentication Subsystem works it was clear that this new direction is better and allows for easier extensibility.

Remember how painful it was to chaining multiple LDAPs? Now it’s as simple as adding the following to your global properties file:

authentication.chain=ldap1:ldap,ldap2:ldap

then you create the following file/folder structure:

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/ldap/ldap1/ldap-authentication.properties

and

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/ldap/ldap2/ldap-authentication.properties

So what about custom authentication components like STAr? Piece of cake. All that needs to be done is create the following file/folder structure:

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/star/star-authentication-context.xml

star-authentication-context.xml would basically contain the definition of the authentication component and authentication service with very minor differences from what it looked like in Alfresco 3.1. I documented the exact syntax on STAr’s wiki page.

The final step would be to modify alfresco-global.properties to add STAr to the authentication chain like so:

authentication.chain=alfrescoNtlm1:alfrescoNtlm,star1:star

It seems though that Alfresco 3.2r2 has a bug where it doesn’t pick up authentication subsystem entries from the extension folder on the shared classpath. So I had to release a new version of STAr (1.2.0) where the -context.xml file is in the STAr AMP and ultimately ends up inside alfresco.war. When Alfresco fixes this bug then STAr 1.1.0 will be sufficient.

To learn more about Alfresco’s subsystems and how to configure authentication components visit the following links:

http://wiki.alfresco.com/wiki/Alfresco_Subsystems
http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems

At Rivet Logic Corporation I’ve been tasked many times to expose Alfresco features through a JSR-168/286 portlet hosted in JBoss Portal or Liferay Portal. Easy right? Not really, and here’s why:

Today Alfresco provides us with a couple of ways to do this:

1. Write a portlet and use Alfresco’s Web services API to expose the Enterprise Content Management (ECMS) features
2. Use Alfresco’s out-of-the-box Web script portlet to expose an Alfresco Web script

The first approach works but in many cases requires that you develop custom Alfresco actions since the Web services API does not cover the full feature set of AFS (Alfresco Foundation Services).

The second approach provides us with more AFS coverage but has one restriction that is not easy to work with. It requires that all of Alfresco be deployed inside the portal as a portlet application. So if you needed to deploy JBoss Portal running an Alfresco Web script portlet that exposes the MySpaces Web script, the deployment would look like this:

The problem with this approach is that it introduces scalability constraints. Namely, if you need to scale the portal you are forced to scale Alfresco with it and vice versa.

For the Web services approach we have an alternative thanks to our Remote Alfresco API rivet (RAAr). With RAAr we are able to make use of Web frameworks like JBoss Seam backed by rich UI component libraries like RichFaces to develop JSR 168/286 portlets that expose most if not all of the AFS features using a Java-based API that uses RESTful communication to provide a secure and scalable interface to Alfresco. One example of a document library portlet that we created using this approach is shown below:

On the other hand, if you need to go with the Web script approach you’re pretty much out of luck unless you’re willing to go with the deployment architecture shown above. The fact that there was no single solution for this problem was all the motivation I needed to create AWPr (Alfresco Web Script Portlet rivet). With this portlet we will be able to have a better deployment architecture that could be represented by the following diagram:

Here the portal and the ECMS are in two separate tiers and can be managed or maintained as such. This not only allows for better flexibility when scaling becomes necessary, it also allows the portal to expose Web scripts that are hosted in different geographic locations.

To make this possible I leveraged a custom authentication component that we wrote called STAr (Secure Token Authentication rivet) that could be plugged into an Alfresco authentication chain. With this in place the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.

We recently released the first public version of AWPr under the GNU Affero General Public License.

The release includes two example Web scripts that, when installed and configured correctly in your portal (e.g. Liferay Portal), will look like this:

If you would like to know more about AWPr you can visit its wiki pages at the following location: http://wiki.rivetlogic.org/display/AWPr/Home