This article is part of series of articles named Constellation Flexible UI. Please check table of contents: https://support.pega.com/discussion/constellation-flexible-ui

During the development phase we used oAuth2 authcode authorization with login popup showing from time to time. This is not a production ready solution that we would like to have. Instead, we would like to implement authorization process that resembles Anonymous Auth Service known from previous versions of Pega. Thanks to that our mashup will be accessible for anyone browsing Sweet Life homepage. In our use case we want to have seamless integration working in the background for anonymous users. Authcode flow is a good choice when we require user to login to external portal.

In our scenario anyone can file Incident, leaving their contact info that will be later validated by the back office workers. For that we need first do some configuration in Pega.

Enabling Custom Bearer Grant Type

Disclaimer:

Anonymous authentication is not supported by Constellation as of Pega 24.1.2. While configuration described below will work this is not a production ready solution as there are multiple security related checks that you would need to configure on your own and they are not described in this document.

In order to enable seamless authorization in Pega for anonymous users we will use new feature called Customer Bearer grant type. The Feature is enabled by a Dynamic System Setting called CustomAuthForPegaEmbed. Please set Owning Ruleset to Pega-Engine.

This DSS need to be set true in order to enable new option on OAuth 2.0 client registrations. We use Custom bearer option.

Authentication activity is the activity that will be triggered on authentication flow. It is up to this activity to decide if user is authenticated or not.

Here couple of characteristics of authentication activity:

• Must be defined on Code-Security class
• Must be located within a Rule-set which is part of application stack -
• "Require authentication to run" MUST NOT be checked
•  "oauth2" service package must have an Administrators group for give application (so that the application stack is able to access the custom bearer activity)
•  Must not use "Activity-End" or "Exit-Activity" step within activity for success or error paths
• It is possible to pass parameters to this activity from JavaScript. In example of anonymous authentication we will not use it. This is power full technique if we have users authenticated on external portal, we could pass cookies or header to custom authentication activity in Pega and validate it against external service. This way we could implement silent authentication without redirects.

• Any custom parameters passed in below way will be available on param page in activity
• Activity needs  to set pyOperPage page with details of operator that will be used for login

In a simplest form when we always the same user, activity can looks like this:

Again, this activity would be more complex in situation when we deal with user authenticated on external portal rather than with anonymous users. Please refer to security considerations at the end of this post.

In order to use customerBearer authentication flow we need to configure it in sdk-config.json config file.

Then we can use custom-bearer header and  pass in body:

• client_id
• grant_type

Having token received we can use it to authorize subsequent calls, using Bearer header.

Note on security

Solution with anonymous authentication is described in documentation with reference to web embed. It is worth to understand security constraints of this solution https://docs.pega.com/bundle/platform/page/platform/user-experience/authentication-web-embed.html

• each user accessing public page will be mapped to the same user in Pega
• we need to ask use to provide some PII data so we can differentiate them as all Pega cases will be created for the same user
• Access Group that will designated for this user shall have very limited set of access rights. This Access Group shall grant only necessary rights and privileges.

One of possible (and quite often used) patterns is to create two apps, one accessible by clients and the second one, internal for back office processing. Cases are copied over via standard Pega API between apps.

As application will be exposed to public Internet with anonymous access available, we need to make sure we secure properly our APIs as anyone is able to use it.

In Pega each Service REST rule belongs to a Service Package rule in Pega.  By default, the API service package has basic authentication enabled. It is recommended to create a new service for use with the DX APIs and create a service package per unique persona & authentication method (e.g., one for  anonymous customer and one internal actors). Avoid using Basic authentication for production.

The API service package consolidates different services, which should not be available to external users (e.g., quiesce a node, run system reports). Best practice is to create new Service Packed that will contain only the endpoints that we would like to expose. Once a new service package is created, copy the Service REST rules required for your specified implementation of the DX APIs (e.g., /cases, /assignments, /data, etc.) into this service package.

Additionally Pega platform offers two security configuration to further secure access to Data Pages

• By default, only data pages  flagged as API  run through /data endpoint (pxGetDataDX)
• Use Data Page privileges to limit access to data pages