[fleXive] implements an access control list based approach to security combined with roles. Since handling access permissions on a per user basis would result in tremendous amounts of data, [fleXive] checks permissions based on access control lists on a per user group basis. User accounts can be assigned to any number of user groups and if in rare cases an explicit user based security is needed, the use of one group for each user is recommended.

User accounts are stored in the database and consist basically of the login name together with a hashed password of the assigned groups and roles. For more information about accounts see the section called “User Management”.

Authentication is currently performed against the database by calling FxContext.login(..) (or as an alternative directly using AccountEngine.login(..)). JAAS based login can be implemented very easily by uncommenting some code in LoginLogoutHandler. It is planned to make this configurable in future versions of [fleXive].

At the core and web layer (provided they run in the same virtual machine) a context is available which is stored in a ThreadLocal called FxContext which provides amongst others the following information:

  • getDivisionId(): number of the current division

  • getLanguage(): the current users preferred language

  • getTicket(): the current users UserTicket instance

The UserTicket is the central class providing information about the current user ranging from the user name, mandator, user group memberships, assigned roles to all access control lists the user belongs to indirectly. Hence it serves as the central authorization data provider for any security check performed.

[fleXive] was designed to be used by application service providers (ASP) with only one deployed enterprise application instance using multiple databases. These database instances are called Divisions and contain their own accounts, structures and content - totally separated from other users of [fleXive].

Divisions are mapped to server names using regular expressions. A web based user interface is provided by the Global Configuration Plugin.

Mandators are - contrary to divisions - not transparent to the user but a means of separating accounts and data. Data can be shared between mandators by assigning user groups from multiple mandators to access control lists. Transfer of data between mandators is a planned upcoming feature of [fleXive]. An example when mandators should be used is e.g. to model different departments of a larger company.

Access control lists - which are assigned to user groups - define a list (Read, Edit, Create, etc.) of permissions attached to an arbitrary object like content instances, types, properties (and property assignments) or select lists. See this article on Wikipedia for more information about access control lists. For the purpose of easier organization and logical grouping [fleXive] categorizes ACL's into the following groups:

  • Instance: Attached to content instances.

  • Structure: Attached to types, properties and property assignments.

  • Workflow: Attached to workflow steps.

  • Briefcase: Attached to briefcases, to allow sharing them among different users.

  • Selectlist: Attached to select lists, the only relevant permission is Create to allow users to create new items for that list.

  • Selectlist Item: Attached to selectlist items, to restrict visibility.

Each access control list allows setting the following permissions independently: Read, Edit, Create, Delete, Relate and Export.

Roles can be assigned individually to users and groups. Every user (or account) is eligible to use any role assigned to the user or any group he belongs to. It is considered best practice to assign roles to groups and only in very rare cases (e.g. flagging someone as a global supervisor) should the role assignments be done on an individual (per user) basis.

[fleXive] provides the following roles:

  • GlobalSupervisor: no restrictions at all.

  • MandatorSupervisor: may do everything for "his" mandator

  • ACLManagement: create/update/delete ACL's for "his" mandator

  • AccountManagement: create/update/delete users, groups and roles (may only add roles he is assigned himself, may not alter assigned roles that he has not assigned himself) for "his" mandator. Everybody may read user and group informations (of course no passwords which are hashed anyways), but only for his own mandators unless he is a global supervisor.

  • SelectListEditor: may see the user interface to edit selectlist items (role entitles to no CRUD rights!), actual permissions are taken from the select lists createItemACL

  • WorkflowManagement: create/update/delete steps and workflows for "his" mandator

  • StructureManagement: create/update/delete types, relations, groups, properties, assignments and selectlists and assign scripts to structures for "his" mandator

  • ScriptManagement: create/update/delete scripts

  • ScriptExecution: execute scripts that can be run "standalone" (i.e. not triggered by events)

  • BackendAccess: may login to the administration GUI (does not imply any rights)