This component provides a highly flexible security framework It is based on code from the Turbine framework, but has been expanded and can be used in any container compatible with the Avalon framework.

  • Allow pluggability via Avalon components of various entities.
  • Explicit Model interface allows generic entities to be glued together in a custom model very quickly.
  • Provide adapters to various other security systems
  • Solve most common problems in dealing with security
  • Not enforce assumptions about how a security framework should be setup.


Basic Model Dynamic Model Turbine Model
User Group User Group Role Permission Delegates User Group Role Permission UserGroupRole
Memory X X X X X X X X X X X X
Hibernate X X X X X X X X X X X X
Torque X X X X X X X X X X X X

Common Security Implementations

The two most common models for security are embodied in the "Basic" and "Dynamic" models. A third model, "Turbine", demonstrates customizing the "Dynamic" model by adding a concept of a global group.


For lack of a better name, this one is called Dynamic because you can configure all the relationships. In it, you have a set of permissions that are related in a many to many relation ship with a set or roles. Those roles are related in a many to many relationship with a set of groups. A user is in a many to many relationship with a set of groups.

The memory, hibernate and torque packages currently implement this security model.


This model is based on what the Turbine application server uses, and leverages the Dynamic model. It merely adds the concept of a "global group" which is a toplevel group to the Dynamic model. However, what makes this different is that instead of roles being related just to groups, there instead is a many to many relationship between users and groups and roles. So you pick a user, pick their role, and their group, and that is their permissions.

The memory, hibernate and torque packages currently implement this security model.


This model is very simple and was originally inspired by OSUser's security model. In it, you have users, and groups, and security is based on a user belonging to a group. Users can belong to multiple groups. So groups become the equivalent of roles/permissions.

The memory, nt torque and hibernate packages currently implement this security model.



Usage of InMemory components

The InMemory components implement the Basic model. All data is strictly in memory, and is not persisted. Therefore when your application stops, all values are lost. However, this is very useful in unit testing and prototyping using the Security component. Notice how role, user, group, and permission managers are all Avalon components as well? This allows you to swap one component out for another. Say you wanted to provide your own group manager that checked that a group existed in NT. You could swap out the MemoryGroupManager implementation for a NTGroupManager, assuming you kept the API the same.


This uses the integrated role and component config XML. Check the /src/test directory for the most uptodate examples of the configuration files used in unit testing!








In org.apache.fulcrum.security.adapter.turbine is an implementation of the Turbine Security Service. This is designed to allow you to run the Fulcrum Security Service, but have Turbine 2.3's be able to query, through the adapter the Fulcrum Security service.


In org.apache.fulcrum.security.adapter.osuser is an implementation of the various *Provider classes required by OSUser. In order to have OSUser load up these classes, you must add this to your ouser.xml configuration file.

    <!-- Fulcrum providers -->
    <provider class="org.apache.fulcrum.security.adapter.osuser.FulcrumAccessProvider"/>
    <provider class="org.apache.fulcrum.security.adapter.osuser.FulcrumCredentialsProvider"/>
  <!-- don't have a propertyset provider, so just return a memory one. -->
    <provider class="com.opensymphony.user.provider.memory.MemoryProfileProvider" />

When using the FulcrumAccessProvider and FulcrumCredentialsProvider, you must first pass into them the Fulcrum SecurityService class. They both inherit from BaseFulcrumProvider, so you can just do BaseFulcrumProvider.setSecurityService(securityService) before OSUser calls them for the first time.

Implementation Details


With the Hibernate SPI, you can just subclass the BasicUserImpl/DynamicUserImpl class, or implement the User interface, provide your own mapping .hbm file and then any additional user properties will be persisted! Very easy customization for your environment!


The Torque SPI provides three different schema mappings for the different security models (in the schema directory). You can easily adjust these to your needs. If adjustments are needed, set up the project.properties file according to your database environment (see the Torque Maven Plugin Documentation for reference) and use Maven to generate the Torque-OM-classes and to re-built the JAR.

The component configuration must refer to the correct Torque-OM-classes as in the following example for the Dynamic model:



As a default, the Torque Security Service uses fulcrum as the name of the connection pool for the tables used. This should be considered in the Torque configuration when the service is deployed.


If you use the BasicModel with the NT implementation, you have a wholly NT based authentication scheme! The groups map onto NT groups, while the users are authenticated against NT as well. This does require you to ask your users for their NT username and password however, we don't have NTLM working as yet.