Define Authorization Model

From PegaWiki
Controlling who has access to an application and its data /
Revision as of 20:20, 17 July 2020 by Mantk (talk | contribs) (Created page with "{{Design pattern |Title= Define Authorization Model |Body= == Use the Security Checklist == [https://community.pega.com/knowledgebase/articles/security/84/security-checklist...")

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Define Authorization Model

Description
Version as of
Application
Capability/Industry Area

Use the Security Checklist

Use the Security Checklist

Control Authorization

The goal of authorization is to securely limit access to sensitive data and application’s 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 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 by clicking Designer Studio > System > General > Systems, Nodes, Requestors. 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 acess, 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, screen, 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 it 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 they are applied correctly to individual cases.

[[Category:]]