Clearspace 2.0 made several improvements to the internal security mechanisms within the product that serve to streamline and standardize the way authentication, authorization and auditing occur within the application. Following on Dolan's blog about Spring in Clearspace 2.0, this post will cover the Acegi-related changes for 2.0 security.
There were several motivations for using Acegi Security in Clearspace 2.0:
Reuse of standard, community reviewed code - At the time of writing, Acegi is planned to be incorporated into Spring proper in the near future. Particularly with security-related code, community review is essential to producing a more robust end result.
Removal of unnecessary, Jive-specific code - There really wasn't a need for us to manage our own authentication framework, authorization framework, X509 handling, etc. when Acegi has already made available a solid implementation. Additionally, Acegi gives us out of the box AuthenticationProvider and Filter implementations for things that previously we had to roll from scratch such as SiteMinder integration or X509 authentication. Acegi's implementations will still require some customization, largely due to the way we perform authorization, but the jive-managed code can be substantially reduced.
Community - As with Spring, Acegi has a healthy community that we can leverage, both through shared code as well as by contributing back to the project.
Flexibility - Acegi is well written and tends to give us extension points where we need them. For example, we needed to support existing LDAP configurations from Clearspace 1.x installations. This required us to inject custom LDAP search properties into the Acegi BindAuthenticator which was easily done through the setUserSearch method on the authenticator.
Leverage Existing Enterprise Competencies - Acegi and Spring are fairly well known in Java enterprise development. Existing skill sets around Acegi will translate to SSO implementations with Clearspace 2.0 as opposed to the 1.x model which required a customer's developers to learn an entirely new security model.
The Clearspace 2.0 authentication model follows standard Acegi authentication, defining a Spring-managed FilterChainProxy bean in web.xml which then delegates to URL-mapped filter chains. These chains manage various security-related concerns including Session expiration, authentication cookie management, password encoding, user profile loading and federated identity features of Clearspace. One notable change is the move to a stronger password hash using a SHA-256 hash of a salted password. Additionally, the amount of Jive-specific LDAP code has been dramatically reduced instead delegating to Acegi's LDAP lookup and bind implementation.
Clearspace 2.0 authorization has not changed substantially from 1.x with the exception that contextual information about a user is now accessed via the Acegi SecurityContext rather than explicitly passed through the application as AuthToken objects. This change focused the APIs on business concerns and moved security concerns to more of a cross-cutting realm, a change we're leveraging in 2.1 to make authorization driven by annotation rather than proxied objects. The hope for 2.1 is that this will greatly reduce the amount of authoirzation code while improving security.
Acegi fundamentally feeds into the new auditing features of Clearspace 2.0. Based on contextual authentication information accessed by Acegi's SecurityContext, the auditing functionality logs operations performed by the effective user performing an action in the system.
Customization of authentication and authorization have several extension mechanisms in Clearspace 2.0 and the required APIs have been simplified. The older AuthFactory class has been removed and implementing jive-specific interfaces is no-longer required to customize the authentication mechanism. The goal for 2.0 authentication customization has shifted focus to a more modular, composition and inversion of control-driven approach. This better aligns with the Spring-standard Acegi approach and focuses customization on Spring-managed filters and/or AuthenticationProvider implementations. The Clearspace 2.0 documentation has more information on creating new authentication customizations or migrating 1.x authentication customizations.
The hope for these changes is that they will improve, standardize and simplify security as it exists in Clearspace. Let us know your feedback!