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