Securing Applications

Overview

Application security is an important concept you need to know to give users the appropriate permissions within an application. This page covers the fundamental concepts about application and object security as it relates users of the application. More information about object-specific security settings can be found on its particular design object page.

Application Security

New applications created in Appian Designer add the creating user to the role map with administrator permissions. Having permissions to an application does not give the designer permissions to the objects associated with an application. Users in Tempo must be at least application viewers to see the actions or feeds of a published application.

See the App Security Table for the roles and permissions that can be applied.

Concepts

Appian's security paradigm is extremely powerful, yet flexible. Because of this flexibility, it can initially be difficult to grasp the details of how to properly secure your applications. The following concepts will help clarify your understanding of the Appian security model.

Groups and Role Maps

Groups and role maps combine to define object security. The following question is a useful way to understand and remember the relationship of groups, role maps, and objects:

What should people (groups) be able to do (rolemap) with this object?

When Appian invokes an object's security model, members of a group are allowed to take certain actions on that object based on the permission level in the role map.

Let's look at an example process model security dialog to see these concepts in action.

example_security_role_map.png

In the above example, CMF Designers have administrative privileges to this model while CMF Users only have Viewer access to the process model. Notice each group has a different permission level on the process model, resulting in a flexible role map.

It is a best practice to only use groups when setting object security. This allows you to control object access by changing a user's group membership, rather than editing the object role map each time.

Permission Types in a Role Map

Most object types have different permission levels in their role map, which is tailor-fit for that object. For instance, a Process Model may need to allow users to start a process, but restrict them from process data moving forward. For this reason, models have an initiator permission level as part of its role map.

With up to five permission levels per object type, and a wide range of different objects, you can set security to match even complex configurations. However, in most cases, you will find that objects typically require only two permission levels:

Administrators - The group or groups whose members have administrative privileges for this object in this environment. This includes full edit and delete privileges for an object.

Viewers - The group or groups whose members can interact with a particular object from an end user state (Tempo, Sites, or Embedded). For example, have viewer rights to an interface will grant group members the permission to view and interact with that interface.

Applications and Record Types have a global option for viewers. If desires, designers may grant anyone in Appian Viewer access to one of these objects.

The viewer permission level provides interactive access for all objects excepts for document management-based objects. For Knowledge Centers and Folders, Viewer access only provides read capability.

For users that are members of multiple groups within a role map, Appian will automatically grant object access at the highest level.

The Deny Permission Type

Many objects also contain a Deny permission level. This permission level is special insofar as it is functionally equivalent to a user not being in the role map. However, Designers may find it useful for situations when a user might be in a group that normally has permissions to the object. In these cases, the Deny level will trump all others.

Security Inheritance

Folders allow for security inheritance of object, and other folders within them. This allows Designers to set top-level security at a Rule Folder or Knowledge Center, and any objects within it will automatically get set without any further action.

Because the security role maps of Process Models and Process Model Folders differ, Process Models will not inherit any permissions from it's folder.

For example, our top level Rules and Constants Folder has security set.

top-level-security.png

But child object will automatically inherit security from this top level folder.

top-level-security-child.png

Objects without security

Neither Documents nor Custom Data Types have security role maps.

Because these objects are never seen outside the context of another object, they rely on the other object's permissions. Additionally, while Documents do not have their own security, their folders do. If a group has access to that folder, they will have access to the contents of that folder. Security can be configured in such a way as to limit which documents are seem strictly through the folders that they are in.

Layered Object Security

Object security is layered like an onion. In order for a user to gain access to an application's feature, they must have the appropriate permissions for every object associated with that feature.

For example, if a case worker was assigned a task to review a customer service request.

example-layered-security.png

In order to see and submit the task, our case worker must have (at least):

  • viewer permission to the process model that generated the task
  • viewer permission to the form associated with the task
  • viewer permission to any additionally reusable interface that makes up the form

This approach provides the opportunity for very granular user access.

Security vs. Visibility

There is an important distinction between security and visibility. Where security is specific to the object, visibility is typically dependent on certain data parameters. For instance, a user could have viewer access to a record, but not have access to a related action within that records.

The visibility field when configuring the related action dictates this, and is dependent on evaluating an expression.

Similarly, a task assignment could be seen as visibility, giving access to a particular task only to as user or set of users.

In both cases, data is the underlying component of visibility as opposed to security, which is solely related to the permissions level granted in an object's role map.

FEEDBACK