This presentation is part of the Authentication Overview Self-Study Course.

Transcript

The first issue is that of a single or multiple security databases.  You may ask yourself:  Do I need a separate Operator ID database in PRPC if we have a centralized identity management system?  The answer is:  Yes, you always need to have an Operator ID associated with a requestor to identify worklists, route work objects, etc.  How can we keep the PRPC Operator ID current when using external security?  Let’s take a closer look.

One way is to create the PRPC Operator ID on the fly.  The User ID and the role name are passed along from the Identity Management or Web Access Management system or from the container (i.e., the application server).  This information is typically passed in an URL parameters or HTTP headers.  The Pega authentication activity uses the username and role passed in to create an Operator ID instance from a template.  Additional user information such as the email address, phone number, department code, etc. is pulled in directly from the corporate LDAP directory using JNDI.  Even if the operator ID already exists (because the user has logged in before), it is “refreshed” with the role from the input parameters and the user information from LDAP to make sure that the information is current.

In 80% of the cases, creating operator IDs on the fly works just fine.  However, the downside is that work cannot be routed to users who have not logged in at least once before.  Work groups are empty and work baskets are shared by no one user initially or only a small group of "known" users.  In the remaining cases, the application requirements may call for users to exist from the beginning.  In these cases the PegaRULES database and the corporate LDAP database must be kept in sync with some sort of batch replication mechanism.