Access Group Usage and Configurations
In the series of blog articles, we will explore difference authorization rules in Pega.
This article was created using Pega '24 version.
We already talked about Operator record which can act as an basic authentication record. There are other rules in Pega which serves only on authorization side.
First let’s clear the air on Authentication Vs Authorization.
A simple example is to compare it with Passport and Visa Stamp.
Let’s say you are visiting a country in Europe
Authentication – Passport is more like authenticating and providing an Identity for you. Immigration checks your passport to know if it is you.
Authorization – Visa is more like to decide what you can do in the country. You may have Work visa which can authorize you to work, where as tourist visa normally don’t authorize you to work.
Let’s take another generic example of Application access.
On a very high level, for any Business Process Management (BPM) application we can have three types of people, let’s call it like that
- Case Manager
- Case Worker
- App Administrator
In the previous article, we talked about Operators and different configurations. When these three different types of people login with their Operator Ids, they see totally different portals with different functionalities.
For example, the Case worker who gets the User portal can only create Mortgage request cases and cannot manage all the system administration tasks or development tasks. So clearly there is separation within the user group right?
If you remember in the Operator article, we talked about two groups – Access groups and Workgroups. We can take an Operator with one or more access groups and work groups.
Why there are two types of groups for the users or the operators?!
Work group refers to team, where as Access groups refer to group of users based on access or authorization.
Just think practically. Take any team in an Organization. The team may have a mixture of resources like the manager, case workers, team leads etc. All these types of users form a team.
These managers, case works may have different access requirements. For example – Only managers can view and generate reports.
That is the reason Pega used a different user group called – Access group that is dedicatedly for access or authorization.
What is an Access group?
– It is an authorization rule which determines, which application an Operator can access.
– You can also specify which portal an Operator can access and
– You can also group access roles using Access group. We will talk more about Access role in a separate blog article.
The below picture can help and lay the path on how the authorization works with all these different types of rules.
How does Pega Authorization work?
OperatorID specifies Access group.
Access group specifies one or more access roles.
Each Access role can specify one or more access role to Objects.
Access role to objects – Objects here refer to class instances. It means controlling access to particular class instances.
You can specify certain Privileges to Access role to Objects.
Let’s focus only on Access group in this lecture.
What are the different ways to create an Access group?
Access group belongs to security category.
Just like the Operator provisioning, Access groups in Pega can be created in two simple usual way 😉
- Manual creation
- Automatic creation.
Automatic Access group creation
When you create a new application using the Application creation wizard, the wizard automatically creates different access groups.
For example – For the Onboarding application we created few days back, you can check the list of auto-created access groups.
Go to Records -> Security -> Access Groups
Important note: Make a note on the naming convention of the Access Group name. The access group name always start with <AppName>:<UserGroupName>.
We got two Access groups created automatically – Onboarding:Users and Onboarding:Authors.
Note: On lower pega versions, you may get more than 2 access groups automatically created when you create a new application.
Manual creation
We can always create a new access group manually.
Let’s create an administrator access group for Onboarding application.
Records -> Security -> Access group Right-Click and Create a new
Tip: It is always best to Save-as an existing access group for the Onboarding access groups and then update the rule configuration.
Anyways let’s create here a fresh access group
What are the configuration points in an access group rule?
Access group form contains 3 main tabs.
- Definition
- Advanced
- Operators
Definition tab
You can specify the application name, portal & access roles.
Application
Name – Specify the application name. We will specify the Onboarding application
Version – Specify the application version. We will use the right application version for Onboarding application
Available portals
You can list one or more portals here but only one portal can be active at a time.
It means as soon as you login, the default portal is the one the user sees first.
Portal is a User Interface rule which we will see in a separate article.
The five interesting portals are
a) Developer – This gives access to dev studio
b) pxAdminStudio – This give access to admin studio
c) pxExpress – this gives access to App studio
d) pxPredictionStudio – this gives access to the Prediction studio
e) UserPortal – This is not a studio, but the template user portal.
Because I am creating an administrator access group, I will keep the below portal access and enable developer as default portal
Available roles
You can list one or more Access role names here. Access roles provide a more granular level of control over different objects. Just think of a simple role for now.
I added the below three roles that are auto-created during the application creation wizard.
For an administrator access group, these three roles are highly sufficient for proper functioning!
Advanced tab
Work Pools
You can specify the work pools here.
The class group can be called a work group. The class group is the main application work layer.
For our Onboarding application ,we can directly specify the default work pool as shown below
Every application will have at least one work pool, so it is easy to specify the same here! You don’t need to manually create a new one here!
Access Control
Authentication timeout – Specify the seconds, after which the system challenges the idle browser sessions to re-enter the password. Security purpose.
HTTP/HTTPS home directory –/ webwb. Keep it as default.
This is the directory which contains scripts, style sheets and images.
Rule security mode –
This setting is mainly used to have control over rule security. A rule can be secured by providing privilege to that rule. So only users who have those privileges can access those rules.
There are three types of rule security modes:
Considering there is privilege, you can consider for now as a security token added to an Object via Access of Role to Object (ARO Instance)
The same privilege can also be added to the rule form to have more security.
When the privilege is specified in the rule form, always the privilege check is done to verify if the user can execute the rule. But if the rule form doesn’t have any privilege specified then what happens is decided by the below configuration
1. Allow – This is the default mode.
The rule always gets executed even if the privilege is not specified in the rule form.
2. Warn – When privilege is not specified in the rule, Pega keeps adding Warn messages.
For Ex: A privilege is added in ARO (Access of role to Object) for Object ‘Rule-Obj-Activity’ and this ARO is associated with the user. It means privilege is added in the User role, but not in the rule form.
On selecting this, pega logs a warn error message in pega logs, but executes the rule.
3. Deny –
Privilege is mandatory in the rule form and the check is always made and the execution can be denied if proper privilege is not available
Run time configuration and Design time configuration
First, let’s understand the difference between run-time configuration and design time configuration.
Run-time is when the rule gets executed and the design time is when the rule is developed by developers.
In both places, you can specify the rulesets.
Run-time Production rulesets – You can specify the rulesets which can apply only to the users belonging to the access group.
Note: Adding rulesets here will not be part of the application. You cannot see this ruleset in the application rule form. At run time, these rulesets appear at top of the application rulesets.
If you want to manage some business logic which can be updated by developers in production, then you can have the production rulesets.
As per my recommendation, production rulesets are not needed 😊 if you have a short release cycle.
Design Time Configuration
There may be some business functionality, where a manager or BA can create new rules from the user portal. For example, ‘reports’. Managers can create new reports – This means at back end they create report definition rules etc.,.
They may end up with an error if we don’t specify any rulesets under the design time configuration.
Default destination ruleset – Ruleset name.
Version – Versioning number.
So when a user tries to create a new rule, Pega suggests this ruleset. You can create rules in this ruleset at design time.
Note: Remember to have these ruleset versions unlocked.
Operators tab
It just lists all the operators that belong to this access group.
Note: This tab lists the operator whose default access group is specified.
How do you check the access group of a particular operator?
1. Via dev studio
When you login dev studio, you can easily access or navigate to your access group directly by using the Operator link
2. Via Clipboard pages
Pega OOTB also creates system page – AccessGroup that loads all the access group details, which can be accessed throughout the browser session of the user.
We are at the end of this article. In the next blog article, we will talk about Access roles and ARO.
