When we discuss security here, 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:
- Name. Descriptive name for the rule
- Type. Drop-down list of options for the rule depending on where you are in the Request console (Space or Kapp).
- Message. Message presented if the rule resolves to False
- Rule. KSL that resolves to True or False
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.
kapp security settings are in the Settings console for the kapp, under the Security tab.
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.
- Form Display.
- Form Modification.
- Subbmission Access.
- Submission Modification.
Note that the default (kapp) security applied is noted beneath the field if nothing is selected. Also, if you have selected a rule that no longer exists (this will generally cause an error in rendering), that is also noted.
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.
Here is an example of API Policy Rules:
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.
This option is available in Reverse on the dialog for the Source.
Policy rules are available for Categories and Consoles also.
Updated 11 months ago