On January 11 and 12 we hosted the cLSA Security Excellence webinar as part of the CLSA Continuous Excellence Enablement (C2E) program that is focussed on targeted content on platform topics and from a Pega 8 perspective. This webinar was focussed on security and discussed authentication, authorization and security features in Pega. A number of questions was asked during the webinar that couldn't all be answered during the session. This discussion posts the questions with answers about ABAC.
Can you please provide some clarity on ABAC Read vs ABAC Discover; there is a confusion around exact purpose and implementation of Discover?
With a read action in the ABAC policy the user can open a case that meets the policy conditions or view data for the case in lists, reports, searches, and so on. With a discover action the user can see limited information (defined by a developer) about a case that does not meet Read policy conditions but does satisfy the discover policy conditions.
A typical use case to use discover is: when someone is investigating a case and doesn’t have security clearance to see all the data but would benefit from knowing there is other data in the system that might help them, then the discovery policy would provide that. Given the info provided by the discovery policy, the user could then request higher clearance from someone up the org chart to see that data.
What is the advantage of using ABAC policies over RBAC Access When rules?
While an Access When rule defines a test that the system performs to allow, or disallow, a user from performing an operation or accessing information (instances of a specific class) based on security requirements, it is important to understand is that Access When’s in RAROs -to accomplish row-level security- are limited in its functionally in reports and in searches. ABAC is uniformly enforced throughout the product including reports and searches. And as the defined policy conditions are automatically included in the SQL it can provide the best performance.
Next to this ABAC works well very dynamic and fine-grained access requirements. It is a good choice to use with diverse workgroups separated by geography or time, you can define access by employee type, location, and business hours and you could only allow access during business hours for the specific time zone of a branch.
How can we apply ABAC for properties which are defined in classes other than Work, Data and Assign? For example properties defined in Link- or Int- classes?
You can indeed not use ABAC on any other class that Work, Data and Assign. However support for Link- and Int- classes is on the roadmap. Due to expected performance implications of ABAC policies on Rule classes during rule resolution, ABAC is not supported on Rule-.
When we use the ABAC PropertyRead to mask the property then it shows the masked value in the UI. How does that work for reporting and the clipboard? When I run a report will it show the data unmasked or masked? And does the clipboard show it as unmasked?
Encrypted properties will not appear at all on the clipboard. Reports honour the ABAC policy and therefore will show the masked value.
If PropertyEncrypted used, would they appear decrypted in BIX extracts?
By default, it will show the property in the encrypted value in a BIX extract. There is a Dynamic System Setting that determines whether to decrypt or not: prconfig/bix/getClearTextWhileExtraction/default.
By setting that DSS to true, it will show the decrypted value.
Using ABAC; can an encrypted property be exposed on the worktable and can it be used in report definition operations as a filter with equals or Contains operation.
The PropertyEncrypt action in the ABAC policy is used to encrypt the value of the property in the database, clipboard, logs, and search indexes. Although it can be used in unexposed properties of your work class, the typical use case is to use it for exposed columns.
In report definitions, the property can be displayed in report results and can also be referenced on the left side of filter conditions that use the Is equal and Is not equal operators. It cannot otherwise be referenced in report definitions (for example, to sort, rank, or group results in SQL functions, and so forth).
***Edited by Moderator Marissa to add the Developer Knowledge Share tag***
Hi Atanu, as responded to the post mentioned. I think this needs an SR raised so the support team can work on this further. They can involve the product team if there is a potential issue to get that resolved.