Authentication in Pega Platform™ ensures that only users and systems whose identity has been verified can access your applications.
Authentication consists of two steps: identification (ID) and verification (V).
- Identification means to tell a system who you are, typically by entering a user name.
- Verification means to provide proof that you are who you say you are, typically through some secret passphrase that is shared between you and the system that you want to access.
Authentication in Pega Platform includes:
- User logins
- External service requests to the platform
- Platform requests to external services
All authentication services use the PRAuth servlet.
However, for backward compatibility with earlier versions of Pega Platform, it is possible to authenticate by using PRServlet instead of PRAuth (in other words, the login URL includes /prweb/PRServlet). For more information about authentication types, see Application URL patterns for various authentication service types.
The user logs into the application using the browser, either by entering credentials or by using single sign-on (SSO).
Authentication Service can be used to authenticate the users with external identity providers/systems.
The Authentication Service feature enables you to override or extend the default authentication process. By creating an authentication service, you implement more specialized authentication requirements than the default, for example, 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.
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.
However, for backward compatibility with earlier versions of Pega Platform, it is possible to authenticate by using PRServlet instead of PRAuth (in other words, the login URL includes /prweb/PRServlet). When PRServlet is used, security policies are enabled by using various controls on the Security Policies landing page. For more information about authentication types, see Application URL patterns for various authentication service types
The following table lists the protocols for user logins that Pega Platform supports.
|An external identity provider that supports the SAML 2.0 protocol, such as Microsoft Active Directory
|An external identity provider that supports the OpenID Connect (OIDC) protocol
|A user ID and password are stored in the Pega Platform database or another internal or external data source. Note: Do not recommend Basic Credentials authentication type for a production environment.
|A token that is validated by an external identity provider or by the OAuth 2.0 authorization layer in Pega Platform (often used in offline mobile applications)
|No verification until partway through a session. For example, an unauthenticated user can add items to a shopping cart and enter credentials when they check out.
|You can configure a custom authentication service to use information that is stored within the identity provider to determine the user roles and privileges in Pega Platform. You can use authentication services (including SAML 2.0, OpenID Connect, or token credentials) to implement single sign-on (SSO) solutions. Make your applications more secure by using simple selections in the authentication service rule form to implement policies such as multi-factor authentication.
|Kerberos is a network authentication protocol that secures client-server node communication by using secret-key cryptography. You can use a user's Kerberos credentials to connect to external systems and authenticate with them.
For example, when a user/employee authenticates to a certain application, the roles defined in the Organization's Microsoft Active Directory are allocated to the user/employee. We don't need to manually change the operator id record in the Pega application with the developer/user access group; this can be done with the SAML2.0/Custom type Authentication Service.
External service requests to the Pega platform through Service rules
An external system or application can invoke a REST service that is defined in Pega Platform or within a Pega Platform application to get case information. This type of authentication uses a service type and service package instances. Supported forms of authentication include:
- Basic credentials
- OAuth 2.0
- Custom authentication
Pega Platform requests to external services through Connector rules
Pega Platform application must authenticate to external system or application to get information, by invoking external REST service call. This type of authentication uses an authentication profile and OAuth provider data instances. The supported forms of authentication include:
- Basic credentials
- NT LAN Manager credentials (NTLM)
- OAuth 1.0 and OAuth 2.0
When Pega communicates with other applications, data and messages must move securely. Authentication profiles are used to manage the security of communication with other applications.
Authentication profiles in Pega are referred to on connector and service rules to secure the communication. However, few authentication profiles are created for a specific purpose (for example, a Microsoft Azure authentication profile).
You can specify authentication profile data instances on the Service tab of Connect CMIS, Connect dotNet, Connect HTTP, Connect JMS, Connect REST, Connect SAP, and Connect SOAP rules and on the Environment tab of FTP Server rules.
Type of authentication profiles:
|Authentication Profile Types
|When to use
|Basic HTTP authentication credentials
|NT LAN Manager credentials
|OAuth 1.0 authentication
|OAuth 2.0 authentication
|Amazon Web Services (AWS)
|Amazon S3 BLOB storage repositories
|Azure BLOB storage repositories
The Data-Admin-Security-AuthenticationProfile class contains authentication profile data instances.
Configure Authentication Services in your application to ensure that only users and systems with a verified identity can access your applications, web pages, APIs, and data.
This is used to authenticate your integration request to an external system via an integration connector in a secure manner.
|For example, when a user logs into a credit card application to check their balance or transactions, the application will utilize Authentication Service to verify their identity/login credentials.
|For example, if a credit card application connects to an external application to get card transactions, the external system/application will authenticate your request using the Authentication profile.