Links may not function; however, this content may be relevant to outdated versions of the product.
Basic requirements for deploying public-facing applications
To ensure the security and branding of your public-facing applications, review and follow the minimum requirements for deployment through Pega Platform.
The Security Checklist: Best practices for securely deploying your application
Security is critical in all applications, especially in applications that are used by external operators, such as customers and prospective customers, who are not your employees. Inadequate security might cause the deployment of your application to fail.
To secure your application, complete the Security Checklist to:
- Follow best practices for securely deploying applications.
- Ensure the confidentiality, integrity, and availability of your application in production.
- Identify when each task should be performed: at or near the beginning of development, on an ongoing basis, or just before deployment.
- Avoid expensive rework late in your development process.
Unless otherwise noted, these recommendations apply to all deployment environments, including Pega Cloud Services.
The most important security requirement for all applications is to maintain guardrail-compliance because Pega Platform security features cannot always be successfully enforced in custom code. You can secure applications by configuring only the built-in features in Pega Platform, without relying on custom code that is built by developers who are not security experts.
For more information, see Security Checklist.
Pega Platform shows the overall completion of the Security Checklist on the Dev Studio home page, and provides tools to track the status of each task.
For more information, see Preparing your application for secure deployment.
Public users authentication
Unauthorized individuals should not have access to view or modify the application or its data. Always verify the identity of application users, and apply one of the following types of Authentication Services, based on the user type:
- Anonymous user
- A user is initially anonymous (identity unknown). The users may register
themselves or have their identity verified partway through a
For example, in online shopping, unauthenticated users can browse and add items to a shopping cart, and then either create an account or enter their credentials to check out.
To configure authentication for applications that require anonymous users, you define the following parameters:
- An Authentication Service rule of the Anonymous type
- An access group for all anonymous users
- A limit for the access group to provide access to only data and applications functions that are not in any way confidential (such as the product catalog and shopping cart)
After a user becomes a known user, either by registering or entering credentials, you can use the Re-Authentication gadget to dynamically change their roles and privileges, so that the user can continue their session without logging in again.
For more information, see Configuring an application to use an anonymous authentication service.
- Authenticated user
- User credentials must be verified during login through an external data
store or database, such as a customer master file.
User credentials are verified at the start of a session, but those credentials are stored outside of Pega Platform.
To configure authentication for applications with authenticated users, you define the following parameters:
- An Authentication Service rule of the Basic Credentials type
- The Verify credentials using an external identity store option
- A data page for accessing an external data store
- Single sign-on
- Single sign-on (SSO) is a property of identity and authentication that enables users to securely authenticate with a set of login credentials, such as a name and password. Authentication is used and the user is authenticated through their credentials on a social media site, such as Google.
For more information, see:
Restrict access to data in Data-Admin-OperatorID class
In public-facing applications where end users do not need access to information about other operators, we recommend that you restrict all access to data in the Data-Admin-OperatorID class to only the end user’s data through an access control policy. You can do this by enabling the out-of-the-box rules pyDefault and pyRestrictToSelf in the Data-Admin-OperatorID class.
If this rule does not exist in your Pega Platform release, you can create it in any release from 7.3 forward. For more information, see Restricting access to operator information in public-facing applications.
For more information, see:
Sensitive client data protection
Never deploy any application that creates or stores personally identifiable information (PII), such as social security numbers, account numbers, health data, date of birth, addresses, phone numbers, or any other sensitive data that could be used to identify an individual, without protecting that data from unauthorized access.
To encrypt sensitive property values, apply these guidelines:
- Set up a master key in an external Key Management System.
- Define a Keystore rule instance that references the master key.
- In Dev Studio, on the Data Encryption landing page, reference the Keystore rule that accesses the master key.
- Define PropertyEncrypt access control policies, and then list the properties to encrypt.
- Define PropertyRead access control policies to conditionally mask or obfuscate these property values for operators who should not be able to view them.
For more information, see:
Branding and exposed information during user logins
Set up a descriptive and memorable (vanity) URL or custom domain name that does not unnecessarily expose server information to users.
For more information about configuring the domain name on Pega Cloud, see Requesting a custom domain name.
If you are running a Pega Platform release prior to 8.4, you should consider customizing the default login screens to remove references to Pega and the version number.
- Restricting access to operator information in public-facing applications
You can restrict all access to data in the Data-Admin-OperatorID class to only the end user’s data through an access control policy.
Previous topic Compliance score logic Next topic Restricting access to operator information in public-facing applications