Embedding Apache Directory Server

Apache directory server is an embeddable LDAP server written in Java. It is now embedded in Jetspeed-2 which fully supports LDAP for authentication and partially for authorization. The Jetspeed-2 security SPI has been implemented to support LDAP. Embedding Apache directory server has been overall quite a pleasant experience.
The first step consisted in integrating Apache DS with Jetspeed-2 Maven Plugin:

<goal name="j2:_start.ldap">
  ...
  <java classname="org.apache.ldap.server.ServerMain" fork="yes">
    <classpath>
    <pathelement
      path="${maven.repo.local}/${plugin.groupId}/
            jars/jetspeed-security-schema-${jetspeed.version}.jar"/>
    <pathelement
      path="${plugin.getDependencyPath('directory:apacheds-main')}"/>
    </classpath>
    <arg value="${org.apache.jetspeed.plugin.ldap.conf}"/>
  </java>
</goal>

The above code invokes Apache DS ServerMain startup class with the server.xml configuration file parametrized through ${org.apache.jetspeed.plugin.ldap.conf}. As illustrated above, Apache DS is also started with the Jetspeed schema extensions. The pathelement element references jetspeed-security-schema which holds the Jetspeed specific schema extensions. The schema extensions java code is generated using the Apache DS Maven Plugin directory:schema goal. The classes are then compiled and archived as a referencable artifact for the LDAP server. Once the server is started, it is now time to bind to the LDAP server. Jetspeed-2 uses the Sun JDK LdapCtxFactory for its default binding configuration.

Idiosyncrasies of java.security.AccessController

As part of cleaning up Jetspeed 2 JAAS RdbmsPolicy, i ran into some not so obvious idiosyncrasies of java.security.AccessController and the differences between doAs(), doAsPrivileged() and whether to pass the AccessControlContext or not.
On the differences between doAs() and doAsPrivileged(), I found a good post of Sun Java Forums:

doAsPrivileged effectively means you are granting
the calling stack your [code's] privileges when executing the code in question. Whereas doAs only associates the subject with the current access control context, all the calling code still requires the permission to be assigned to it (under the subject in question).

Where it gets interesting, is that when implementing a custom policy, and assessing whether the caller is authorized to access the callee, in implies(ProtectionDomain protectionDomain, Permission permission) the protectionDomain does not contain the principals when performing a doAs check. As mentioned in this post on the Java Forum, when the permission check is concerned about the principals in the subject (call to protectionDomain.getPrincipals()) for the security check, the security check should be performed as:

doAsPrivileged(theSubject, anAction, null)

By passing in a null access control context, the caller is essentially saying: "I don't care who called me, the only important thing is whether I have permission when associated with the given subject".

Subtle differences...

Making Sense of Identity Management

With the rise of service oriented architecture, maintaining a consistent user identity across multiple enterprise systems is becoming increasingly difficult. In an attempt to address the pain that many large IT organizations go through, the software industry has given birth to an onslaught of standards with the purpose of maintaining a common identity across the enterprise. Jason Rouault from HP has written a great paper that sheds some light on that space: Making sense of the federation protocol landscape. As an introductory reading, I strongly recommend An introduction to identity management as well. I like the following definition for identity management:

The set of processes, tools and social contracts surrounding the creation, maintenance, utilization and termination of a digital identity for people or, more generally, for systems and services to enable secure access to an expanding set of systems and applications.

The following pictures sums it up well from a conceptual standpoint:

In my views, a right identity management strategy can provide a strong competitive advantage to an organization as distributed application or services can leverage a much better known user and therefore increasingly build value added to address their employees, customers, partners, and suppliers needs. As organizations consider service oriented architectures, it is critical to craft an identity management strategy in line with such distributed services.

Some thoughts on JSR 196

There are a few open source security framework out there that follow an SPI model for their security implementation. Acegi is one, Jetspeed security is another one. Both spring based frameworks follow an SPI concept, but the specifics are quite different from JSR 196. In the JSR 196 world, the javax.security.auth.container.AuthContextFactory is used to obtain context objects that encapsulate authentication modules and delegate to the ClientAuthModule or ServerAuthModule given the authentication context (ClientAuthContext or ServerAuthContext). Each authentication context is initialized according to a MessagePolicy that specifies what authentication guarantees the module is to enforce when securing or validating request and response messages within that context. A ServerAuthModule may delegate some of its security processing responsibilities to a LoginModule for JAAS authentication.

Regarding, the management of the authentication modules interaction, I found that comment in ServerAuthContext interesting:

Implementations also have custom logic to determine what modules to invoke, and in what order.

I could be nice to have policies or rules to manage that interaction...

Jetspeed Security - JAAS all the way...

I finally got some time to update Jetspeed security documentation. I still have a little bit of work to do, but I think this is a good beginning and it was badly lacking. Jetspeed 2 fully leverages JAAS for authentication (through the implementation of javax.security.auth.spi.LoginModule) and authorization (through the implementation of a custom java.security.Policy) and provides a flexible security framework with a set of coarse grained services for user management, role management, group management and permission management.


Jetspeed security SPI provides a pluggable authentication and authorization architecture. I found interesting some of the similarities with Acegi as pointed out by Keith Gary Boyce on Jetspeed user list.
For future releases, I am planning to investigate integration with JACC and with JSR 196. Additionally, Jetspeed provides some nice portlets that provide management features for the security framework.