View source for Controlling who has access to an application and its data

{{Design pattern
|Title= Define Authorization Model

|Body=

|Description= Defining the authorization model.
|Version= 8.4
|Applications= Platform
|Capability Area= Security
|Owner=Solomon, marty}}

== Use the Security Checklist ==
Whenever you create an application and define an authorization model, you should start with and use the [https://community.pega.com/knowledgebase/articles/security/84/security-checklist Security Checklist].

== Control Authorization ==

The goal of authorization is to securely limit access to sensitive data and application functionality (especially the ability to change application data, and the application itself). To do so, follow these best practices:

=== Guardrail compliance ===
The most important security requirement for all Pega Platform applications is to maintain guardrail compliance. Pega Platform security features cannot always be successfully enforced in custom code. Use the built-in authorization features in Pega Platform to protect your application, and do not rely on custom code built by developers who are not security experts.

=== Principle of ''least privilege access'' ===
Restrict access to those who need it to perform their jobs, and prevent others from gaining unnecessary access. Each application end-user should have access to the least data and the fewest functions needed. Rather than granting users access to all data and functions, start by denying them access to all data and functions, and then grant them access to specific data and functions as needed.

=== Set the system production level to 5 when deploying to production ===
To implement the most restrictive security scheme, set the production level for the application to level 5. Production levels can be changed as described in the community article titled ''[https://community.pega.com/knowledgebase/articles/system-administration/85/specifying-production-level Specifying the production level]''. The change takes effect the next time the system is started. The production level value primarily affects privilege-based authorization through Access of Role Object and Access Deny rules, and testing mirrors the authorization controls that are set for production. If this setting interferes with development environment access, add more focused Access of Role to Object rules that grant access, instead of lowering the production level.

=== Define appropriate roles and privileges to restrict access ===
Define roles for the users in access groups. For each class, section, flow, flow action, or tool that only certain users need, define an appropriate privilege to enable its access. Use the Access Manager to manage the granting of these privileges to roles. Grant access only to users with a real business need for a business function or business data. Review all access groups, especially access groups for unauthenticated users, to make sure that an access group has the minimum required access to rules, case types, and data.

=== Define appropriate access control policies to restrict access ===
Use access control policies to enforce restrictions on access to application data at the row and column level; in other words, to restrict access to specific instances or properties in a class for different operators. These policies dynamically compare user privileges, credentials, or other information on the clipboard to properties in each instance of the restricted class. Use the Policy Verification landing page to test the defined policies and make sure policies are applied correctly to individual cases.