Security Policy Basics
Introduction
Security policies are definable expressions that control who is authorized to access/create/modify/delete specific resources.
Parts of a Security Definition
Each Security Definition has the same four elements.
Name
The Name is descriptive text that is presented in dropdowns. It must be Unique, even if it is for a different type.
Type
Because there is a different scope between Space and kapps, there are different types available.
Avaialble Types for Space:
| Type (where they can be used) | Available Bindings |
|---|---|
| Space | identity(...), space(...) |
| Team | identity(...), space(...), team(...) |
| User | identity(...), space(...), user(...) |
| Datastore Form | identity(...), space(...), form(...) |
| Datastore Submission | identity(...), space(...), form(...), submission(...) |
Avaialble Types for Kapps:
| Type (where they can be used) | Available Bindings |
|---|---|
| Kapp | identity(...), space(...), kapp(...) |
| Form | identity(...), space(...), kapp(...), form(...) |
| Submission | identity(...), space(...), kapp(...), form(...), submission(...) |
Message
The message is what is returned to the customer if the Rule evaluates to false.
Rule
The Security Definition rule is a single JavaScript expression that has to evaluate to either true or false.
Use
Security Definitions are used throughout the application to provide limits on access to different elements like forms, kapps, and submissions.
Expressions
Security policies give us the ability to apply security that is logically easy, but impossible to implement with traditional group based security.
- Ex: “A user can access this form if they are NOT in a specific team”
- Ex: “A user can access this form if they have a matching attribute"
- Ex: “A user can access this form if they are in Team A AND in Team B”
- Ex: “This form is only available on “Weekends”
- Ex: “This process is usable by people who have been employed > 1 year"
Security Policy Precedence
The Kinetic Platform leverages a number of nested scopes. Security Policies evaluate the highest scope first, and proceed until all appropriate policies have been evaluated.
- Users with Space Admin privileges bypass all security policy evaluation
- This is why invalid security policies sometimes don’t show up until users without Space Admin permissions begin using the system
- If someone can modify a Kapp, they can access/create/modify all Forms and Submissions in that Kapp
- This is new in Platform v5, pre-v5 Submissions were independent of Kapp Modification security
- If someone can modify a Form, they can access/create/modify all Submissions of that Form
Submission Searching
Security policies needed to be coordinated with submission search patterns
- Security Policies can not be a replacement for submission searching
- If there are more than 25 submissions encountered in a search that the Submission Access policy denies, the entire query fails
- Security Policies must be evaluated after querying the database
- We limit failures to avoid "table scans" and the resulting performance degradation
| Example Search: | All submissions where the Assigned Team is “Facilities” |
| Example Good Submission Access Policy: | The current user is in the Facilities Team |
| Example Bad Submission Access Policy: | The current user has the attribute “Manager” set to true |
Updated over 3 years ago