Elephant Security System is used to isolate contents based on user granted permissions. The content is generated at server side based on this security system.

Basic security points

• User passwords.
• User social group syndication.
• User roles, mainly granted through social groups.
• User permissions, defined by roles.
• User fuzzy roles, discovered by user activity.
• Conceptual permissions, related to entity's components and module specific.

Passwords

Elephant uses a symmetric cipher with a unique key pair, to produce the ciphertext to be stored.

Before stored, the application measures the password strength and shows the result as a percentage. The rules for measuring the strength are:

• for length: [...4] = 3, [5...7] = 6, [8...15] = 12, [16...] = 18
• has lowercase: = 2
• has uppercase: = 2
• lowercase > 2 and uppercase > 2: = 2
• for numbers: = min{number, 3} * 2
• lowercase > 2 and uppercase > 2 and numbers > 0: = 2
• for special characters: = min{specials, 3} * 2
• lowercase > 2 and uppercase > 2 and numbers > 0 and specials > 0: = 2

isInRole method

Elephant provides isInRole convenience method to check user assigned points. The method takes as string parameter with a permission checking syntax.

The scripts also provide a facade map named rolemap. The checking syntax will be rolemap['root:permission'].

See [ Social groups, Permissions, Scripting, Actors, Concept permissions, Superuser ]

Social groups propagate into static, application-wide permissions. Users syndicated to socials groups will also be granted with the related permissions.

Elephant comes with a ready-to-use set of social groups, associated to roles with fine-grained permissions. The following table is auto-generated with the current version. The identifier is the internal form of the social group. Syndicate shows nested social groups. Roles are the set of permissions granted with the social group. Each role has a popup showing the fine-grained permissions, where no-popup would mean no-permissions. Tags is no longer used, since contacts module already provides a tag-kind-of navigating among social groups.

Inheritance

Socials groups marked with are subject to inheritance. Inheritance ensures that staff from a company or center will inherit the social group and its permissions. Inheritance is dynamic and takes into account current companies or centers.

Permissions' definition is explained in Social groups . Simplifying, definition is set of permissions related to a root, for example dossier:list,new,edit,delete, whereas checking a permission would take the form dossier:new. In the definition we say the permissions related to dossier, when checking we ask whether it has one of those permissions.

Permissions can be ORed using |, for example dossier:list|@customer:on.

Permission root types

• Entities, as defined in Elephant modules. dossier, contact, document are examples of those entities.
• Social groups, using the social group identifier prefixed with a @, and followed with :on.
• Roles, using the role name prefixed with a #, and followed with :on.
• Fuzzy roles, using the fuzzy role name prefixed with a @, and followed with :is.
• Actors, using a fixed root @actor:, and followed with the actor name.

Fuzzy roles

Fuzzy roles are those discovered by the application and highly dependent on interactions. Represented as @fuzzy_role:is.

Commodity roles

Elephant includes some commodity roles, not directly related to user's role:

Some examples

Suppose a sample user assigned to Privileged Customers social group. This social group grants the DossierParticipant role, which carries dossier=list,show permissions. Therefore, dossier:show will be granted.

Scriptable permissions

This feature is in its early stages and provides a more flexible way to use the permissions starting with a @. Adds the possibility of creating complex formulas, with preferences, negations and logical operators.

Scripting is used by Actors , in Concept permissions and in Visual elements . The main goal is to provide an advanced way to check permissions, roles, social groups and entity related attributes.

User functions

Methods related to currently authenticated user. The scripting context initializes the variable user.

Helping functions

Per module functions

Per module attributes address those features unique to the entities in this module. Per module attributes sum to the generic attributes.

Issue, Dossier and Category

Dossier context initializes the variables dpl and issue, dossier or category. Notice that when applying constraints that uniquely refer to a project, the dossier must be of type project.

Helping functions

Script files

It is possible to use scripting files with the directive file:file_name. Scripting files are located in /WEB-INF/elephant/scripts.

Debugging

Scripts generate no logs with errors. Starting the script with debug: indicates the Scripting API to write any error in the log file.

Actors API is a superset specification based in Security 's Scripting . The goal of this API is allowing the creation of easy-customizable application actors.

The basics

An actor is a given user complying with a group of constraints attached to the actor's name. An example would be:

PartnerNetwork=pfunc.anyOfSyndications(user, "partner,patron,contacts_admin")

The line configures the PartnerNetwork actor. In order to check if the visiting user is a PartnerNetwork, in Visuals we'll do:

user.isActor("PartnerNetwork")

Surpassing the individual

Actors API is fully compliant with the collaboration modules. We can create specific actors for a large variety of entities. An example of an actor related to dossiers or categories:

ComissionMember=dpl.isParticipant(user)

Now we could check if the visitor is a ComissionMember with:

user.isActor(dossier, "ComissionMember")

Checking a user

The BaaS service provides a view where we can check users against all defined actors. It's also possible to perform the check using an entity.

Concept permissions is a convenience set of security settings, differentiated by their name (concept). Concept permissions factory should primarily be an Elephant Entity, by means of its method getConceptPermission(name). Using an Elephant Entity as a factory ensures the correct initialization of the Scripting methods.

Permission fields

The concept of a Superuser adds extra security to management users. There are two kinds of superusers, the superusers themselves, and the CloudAdmin user, addressed to cloud administrators.

Superuser functionality

A Superuser, su from now on, has access to the whole configuration set, including special management of Social Groups for contacts. Important for a su to remember:

• A su has full power over the application and web site.
• A su can assign or remove the su attribute from any contact.
• There is no limit to the number of su's. Anyway, the reason to have them is to keep the number low, for instance, one plus a backup.
• Non-su admins will not be able to impersonate a su. The attempt will be registered as /log/failsu, and an email will be sent to all su's.
• The fuzzy role @su:is is available for context roles and the whole security script system.

Superuser special access

The following table shows the elements restricted to su-only-eyes.