When we discuss security in this article, we are referring to access, not authentication. This means we are referring to what someone has access to within the system, not the method of determining whether their password is valid and allowing them into the system.
Security for platform components is handled by Security Policies. Security policies are something defined by a system admin and can be as simple or complex as necessary. These policies can incorporate a variety of information, including the user's indentity, teams, roles, and more.
Security policies can be used, in some cases, to determine access to the platform consoles themselves.
Security Policies are created in the same manner, regardless of the level they are created for. You may have different information depending on the level, but creating the policy is the same.
Rules are built (written) using KSL, a scripting language created for such things. See the related KSL article for more information on KSL and for sample security policies.
Each Policy Rule console has the same fields:
Security policies are defined in different places, depending on where they are applied. If no policy is defined, then the policy is used from the next highest level.
In level order:
In general, you need to be a Space Admin to have access to the consoles.
If you allow a user access to Form Modification, they have 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 and kapp modification. While kapp visibility is just to see the forms for the kapp, kapp modification allows a user to have access to the kapp consoles.
You can also see the default values for form security permissions that are set here.
There are four options for Security Policies for Forms. They control form modification and visibility, and submision access and modification. Another option is to set the form to anonymous. This option is featured in another article because it's not specifically a security option.
Each of the four options has the same list of choices.
Access to workflow, task trees, is controlled by Policy Rules. The format is similar to what is described above except that ruby is used and there is no type field.
One feature that is particular to workflow security rules is that the element they are attached to is also shown at the bottom of the rule.
API (task tree normally) access is restricted per Source, so at the bottom of each Rule, you can select a source to apply the rule to.
Policy rules are available for Categories, and Consoles also.
The workflow engine allows a very granular access to the different consoles.