[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)