Groups, Roles and Application Contexts

Packflow uses different concepts listed below to manage users membership and permissions.

• Modeling Role

  Roles are a permission modeling object used at application design time. They allow to template permissions within the modeled applications.

  When deploying an application, the modeled roles are translated into Group instances.

• Group

  The group object allows to array principals at runtime. It may contain PFUser or other PFGroup instances.

• Application Context

  Application contexts are runtime data partionning objects, allowing keeping data private for different entities using the same application.

Groups are runtime containers for other Packflow groups or users.

When computing permissions, Packflow RLS considers included groups have the same permissions as their parent *.

Note
* 'Parent' is used as a shortcut to say 'The group including the mentioned group'. There is no strict Parent notion in Packflow. Groups can be included in several other groups, having multiple parents.

Each group has one of the following scopes:

• Site

  Site groups are created runtime by the site administrators. They might be included in any other group, if not cycling. These groups can synchronize their membership on an Active Directory group.

  Application

  Packflow engines instanciates application groups per application Context/Modeled Role combination. These application groups are used to define permissions on applications.

  Important
  Application-scoped groups are called 'Roles' in the administrative GUI of Packflow. This was decided to avoid confusion during runtime administration. In this document, we always use the word 'Role' to reference a modeling role, not a runtime group instance.

Comparation between group scopes

Groups in Packflow API

Packflow groups are represented by the PFGroup class. Site groups are found in a relation under the current Site. Application groups are found in a relation under their parent PFApplication instance.

Application groups keep metadata about their source role and application context.

Application Contexts are data partitioning objects created by administrators at runtime. As an example, an application context could represent a physical location, a plant, a country, or any other entity, depending on your application needs. Using application contexts, these entities could use the same applications while keeping their functional data private.

Application Contexts and Item Creation

Every new PFItem needs to have an application context selected. Once selected, the engine uses the model to compute runtime permissions on the object.

Note
Most of the time, the context selection is automatically made by the engine, based on current user's membership or an eventual parent item. The user is prompted to manually select the context in rare cases only.

If permissions were modeled using roles, the RLS system finds application groups matching the target modeled role in the current context to set permissions.

As an example, imagine that members of 'Admins' Role are enabled to delete an item, at modeling stage.

At runtime, an item is created with an application context named EU. The engine will then find the application group matching this role and app context to set the delete permissions on the item.

You may see this section for more details on how Roles, Groups and Contexts fit together.

Reference Groups

Let's take a simple example: An application is modeled with one content-type and three roles:

When deploying the application, the three roles are instanciated as application groups per application context. Creating a new application context automatically creates a new set of application groups.

In the object diagram below, you can see the objects created when deploying 'MyApplication'. The color convention is the same as above.

There are some notable points in the object diagram above.

• The roles offspring app groups that are repeated for each application context present.
• Site groups may be included in other site groups, as in application groups
• Including users or groups into application groups from multiple app contexts allows multi-context operation.

  The group 'World Directors' is a good exemple, it is included in the Directors application group for both application contexts.

• Site groups can be included in application groups from multiple applications.

Reference

Other Resources