Authentication

Authentication in Pega Platform™ helps to ensure that only verified users and systems can access your applications. 

Authentication consists of two steps: identification (ID) and verification (V).   

•  Identification involves providing your username to the system to establish your identity. 
• Verification involves providing proof of your identity, typically through a secret passphrase shared between you and the system you want to access. 

Authentication in Pega Platform includes:

• User credentials
• Requests from external services to Pega Platform. 
• Requests from Pega Platform to external services. 

User credentials

Users log into applications using their web browser by entering their credentials by using single sign-on (SSO) or using external identity providers. The Authentication services verify these user credentials. 

The Authentication Service feature enables you to override or extend the default authentication process. By creating an authentication service, you can implement more specialized authentication requirements than the default service provides. This is useful, for example, when you want to use pre-authentication and post-authentication activities. 

Authentication Services are instances of the Data-Admin-AuthService class. All authentication services use the PRAuth servlet.  By default, the system includes a basic authentication service named Platform Authentication, which you can save with a new name and edit. You can create any type of authentication service, including the basic type. 

The default servlet, PRAuth, provides a unified authentication gateway so that you do not need to edit prweb.xml or restart the server for new authentication services.  

All authentication services use the PRAuth servlet. However, for backward compatibility with earlier versions of Pega Platform, you can authenticate by explicitly specifying PRServlet in the application URL instead of PRAuth or by removing the servlet name. For more information about authentication types, see Application URL patterns for various authentication service types.   

The following table lists the protocols supported by Pega Platform for user logins: 

When a user authenticates a particular application, the roles defined in the user's company, Microsoft Active Directory, are automatically allocated to that user. Manually changing the user ID record in the Pega application with the developer or user access group is not necessary. Such changes can be made with the SAML 2.0/Custom type Authentication Service. 

The Custom Bearer authentication service in Pega is a feature that enhances the security of data on display. It is part of the OAuth 2.0 client registration and is used to eliminate the need for reauthentication, providing a seamless user experience without requiring pop-ups and browser redirects. This is particularly useful in scenarios where Pega web embeds are used to load user interfaces that use DX APIs. By defining a custom bearer grant type when configuring an OAuth 2.0 client registration, the need for reauthentication is eliminated, which enhances the user experience and secures the data on display. 

Another way of authenticating users is by using CAPTCHAs and Multi-factor authentication:

• CAPTCHA 
  CAPTCHA creates a challenge that is easy enough for a human user to meet, but which is likely to defeat standard automated software.
• Multi-factor authentication 
  Multi-factor authentication enhances security by adding an authentication requirement beyond a username and password. Pega Platform supports multi-factor authentication by sending a one-time password (OTP) to a user through email and SMS 

Web-based SSO 

With SAML and OAuth protocols, Pega supports web-based SSO, a feature that allows users to access Pega applications and other applications within their organization's ecosystem with a single set of login credentials. These protocols enable Pega applications to integrate with identity providers (IdPs) and authentication servers, which are responsible for verifying user credentials and generating authentication tokens. 

External service requests to Pega Platform by using Service Rules  

External systems or applications can retrieve case information by invoking a REST service defined in Pega Platform or within a Pega Platform application. Authentication for this type of service is done through service type and service package instances. The following forms of authentication are supported: 

• Basic credentials  

• OAuth 2.0  

• Custom authentication  

Pega Platform requests to external services by using Connector Rules  

To retrieve information by invoking an external REST service call, Pega Platform applications must authenticate with external systems or applications. This type of authentication is done through the authentication profile and OAuth provider data instances. The following forms of authentication are supported: 

• Basic credentials  
• NT LAN Manager credentials (NTLM)   
• OAuth 1.0a 
• OAuth 2.0  
• Amazon Web Services (AWS) 
• Microsoft Azure 

Authentication profiles are used to secure the transfer of data and messages when the Pega applications communicate with other external applications. 

Connector and service rules in Pega applications refer to authentication profiles to help ensure secure communication. However, only a limited number of authentication profiles are created for specific purposes, such as a Microsoft Azure authentication profile. 

Authentication profile data instances can be specified on the Service tab of Connect CMIS, Connect dotNet, Connect HTTP, Connect JMS, Connect REST, Connect SAP, and Connect SOAP rules, as well as on the Environment tab of FTP Server rules. 

Type of authentication profiles:

Authentication profile data instances are stored in the Data-Admin-Security-AuthenticationProfile class. 

The following table shows when and where to use authentication services and authentication profiles: 

Check your knowledge with the following interaction: