Security Policies

Overview

When discussing security in this guide, we refer to what users can access within the Platform (as opposed to authentication, which determines whether a user's password is valid and allows them into the system).

System admins define security policies that handle security for Platform components. These policies let you apply security that is logically easy but impossible to implement with traditional group-based security. Some examples include:

Granting a user access to a form if they are NOT on a specific team.
Granting a user access to a form if they have a matching attribute.
Granting a user access to a form if they are on BOTH Team A and Team B.
Limiting access to a form to weekends.
Limiting access to a form to people employed for more than a year.

Security Policy Hierarchy

Security policies are defined in different places, depending on where they are applied. If no policy is defined, then the next-highest level's policy is used.

In ascending order, the levels are:

Form
Kapp
Space

Form Security

Form Display: Controls who can see and submit the form. It is not possible at this level to allow someone access to see but not submit the form. That would need to be controlled with rules on the front end, such as an advance condition, or within the workflow engine after submission (not to process or delete the submission).
Form Modification: Controls who can change/update the form. This is often set to a security definition that includes form developers and platform admins.
Submission Display: Controls who can see submissions. This is often set to the submitter of the submission and platform admins. Submission Display access also becomes important when retrieving search results. Searches will error if they contain too many (>25) submissions the user cannot access. This is something to remember when determining access for various forms and constructing search queries.
Submission Modification: Controls who can modify a particular submission. This is often set to the submitter of the submission and platform admins.

You can also indicate whether the form accepts anonymous submissions. See Forms: Security for more information.

Kapp Security

Access to Kapps is limited to Space Admins and users granted display or modification permissions. If you allow users access to Form Modification, they are also granted access to the Kapp the form is part of. They can see other consoles in the Kapp but cannot make changes.

Each Kapp also has a setting for Kapp visibility (allowing users to see all forms for a Kapp) and Kapp modification (allowing users access to change Kapp functionality).

Kapp security settings are located on the Security tab of the Kapp Settings page. You can also set the default values for form-level permissions for this Kapp here.

Space Security

The Security tab lets you assign access permissions for the Space and access, create, and modify permissions for teams and users.

Workflow Security

Policy rules control access to workflow task trees. These rules use Ruby and do not contain a Type field. The element to which a workflow security rule is attached is also shown at the bottom of the rule.

API access is restricted per Source. You can select which sources to apply the rule to for each policy rule. You can also apply policy rules to sources from the Source page.