Groups, Roles and Application Contexts
This topics explains the concepts behind roles, groups and application contexts in Packflow.
You may refer to the Administration pages for practical information on how to manage groups in Packflow.
This topic contains the following sections:
Packflow uses different concepts listed below to manage users membership and permissions.
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.
The group object allows to array principals at runtime. It may contain PFUser or other PFGroup instances.
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 *.
|* '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 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.
Packflow engines instanciates application groups per application Context/Modeled Role combination. These application groups are used to define permissions on applications.
|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
|Site||Creation by members of SiteAdmins system group.||May be included in any group. Can include any site group, if not cycling.||Yes|
Administrators create site groups and include users or other site groups.
This allows representing the users' organisation.
|Application||Creation by the engine during application deployment.||Cannot be included in any group. Can include site groups.||No||Administrators include site groups and users under Application groups, to define permissions on applications.|
Groups in Packflow API
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.
Every new PFItem needs to have an application context selected. Once selected, the engine uses the model to compute runtime permissions on the object.
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.
Application Contexts are created under each applications. Nevertheless, it is common that a functionnal data boundary makes sense for several applications.
A relevant example is using contexts for geographical areas. All geographical areas might use any of the applications in the site.
Packflow allows to link related application contexts under different applications, using a Site Group as reference. This reference group is used by the engine to find a context matching the currently selected context for other applications.
In the example below, you can see two applications instances with two applications contexts under each.
The site group 'Europe' is used as reference Group to match the two 'EU' contexts under the applications. The end user sees a single entry named 'EU' when selecting contexts, which applies to both applications.
You can see an illustration in the example below. There are two applications and relative contexts, one coloured yellow, the other coloured green. Blue boxes represent Site-related objects.
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.