Configure LDAP Authentication Service in Pega

In this blog article, we will see how we can authenticate the application user credentials against the attributes stored in the apache directory server.

It is mandatory to visit my another blog article of LDAP set up before proceeding in this article.

How to configure the LDAP authentication in Pega?

Let’s start by choosing the right servlet. In the authentication introduction post, we already saw the usage of web.xml file

You will find the file in the right directory

Tomcat->webapps->prweb->WEB-INF

You see Pega already provides 3 servlets for LDAP authentication. These servlets are reserved for the configuration wizard – WebLDAP1, WebLDAP2, WebLDAP3

So, no need to add or update servlets, we can reuse the existing servlets.

Now its time to start with the Pega wizard.

Step 1: Designer studio -> Configure -> Org & security -> Authentication -> Create authentication service

Step 2: select the authentication type as Custom and Name as WebLDAP1. We will use the first servlet.

Click create.

Step 3: You will see the custom authentication service rule created with empty field values.

What are the configuration points in the authentication service rule?

There are 3 main tabs

  1. Service
  2. Mapping
  3. Custom
Service tab

You have three blocks here to configure

Custom authentication activity

There are two authentication activities you can configure. Pega already provides you with the default activities for LDAP.

Timeout Activity

Once the timeout exceeds, then we can challenge the user to enter the credentials again. Specify the activity – AuthenticationLDAPTimeout.

The activity performs the following actions

  • Presents the challenge stream
  • Validates the credentials against the LDAP server.

You can explore the activity on your own.

So, where do you configure this timeout settings?

Switch to the custom tab and scroll down

Timeout options

Use PegaRULES Timeout – It uses the authentication timeout specified in the users access group. You can also use timeout managed by external services.

Now challenging stream, you can specify 2 options

1. Use basic authentication for timeout – It throws the default browser pop-up window to gather the credentials

2. Timeout challenge stream – you can specify a HTML form to validate the crendetials

Redirect URL – You can also specify a redirect URL when the session timesout!

Let’s get back to the activity.

Authentication Activity

Specify the default pega activity – AuthenticationLDAPWebVerifyCredentials

The activity performs the following actions

– Do a lookup on the LDAP server and validates the credentials

– Once successfully verified, it checks if the operator already exists

If yes – do some normal updates with the LDAP attributes.

If No – Uses the model operator and creates a new operator on the fly.

– If the credential verification fails, then failure stream can be presented.

Please explore the activity on your own.

JNDI binding parameters

This block is responsible to define the binding parameters to connect to the LDAP server.

Initial context factory – specify the java class name for JNDI connect factory. The default value is com.sun.jndi.ldap.LdapCtxFactory

Directory – You can either specify the URL directly or via JNDI entry.

Remember we use the LDAP protocol and so ldap instead of http.

Use the port – 10389 and the resource name for the partition o=myknowpega.

ldap://localhost:10389/o=myknowpega

Just a glimpse of our partition from apache directory studio.

Trust store  – If you use secured LDAP connection, then use the trust store that contains the server certificates.

Bind distinguished name and password

Remember when we create a new connection to the LDAP server from the studio, we specified the binding parameters. Specify the same in the fields.

Password is still ‘secret’ 😊

Once done, save and do the test connectivity.

Heel Goed !!

Let’s give the final touches.

Search Parameters

You can specify the search parameters in this block

Directory context – If you want to search the credentials under a certain branch in the apache directory, then you can give the directory context.  In my scenario, I saved the employee names in the top directory context under o=myknowpega (already specified in the URL)

So, leave it empty

Search filter

(<searchname>=%V)   – (uid=%V)

%V – dynamically gets substituted by the user name you enter in the login screen. So here, the user name is searched against the uid attribute value in the LDAP entries.

Mapping tab

You can specify the attribute to property name mapping.

First let’s specify some additional attributes in the apache directory server.

Remember to always provide the credentials in the attribute – userPassword.

Note: Org, div and unit are key mapping to identify the model operator

Save the entry once you add the attributes.

Get back to Pega and add the mapping.

Once credentials are successfully verified , the attributes will be mapped to the operator record.

Custom tab

This screen is basically about providing the challenge screens at the initial stage or failure stage.

Please explore it on your own 😀 Nothing big. You can leave empty to accept the default behavior 😉

Let’s test the LDAP authentication

Scenario 1: Operator already exists in pega database

Step 1: Save the authentication service rule form with the configuration as shown above.

Step 2: make sure your LDAP server is up and running

Step 3: now launch your LDAP URL

http://localhost:8080/prweb/PRWebLDAP1

Provide the username and password you saved in LDAP directory

We have successfully logged in pega validating against LDAP server.

Step 4: Open the operator rule form. You will see the operator record is updated with LDAP attribute mapping.

Scenario 2: Operator does not exist in pega database

Step 1: Add a new entry in the LDAP server for the new employee.

Please follow my previous article to know the steps to add new entry in the LDAP server.

I added an entry for luffy.

Step 2: In this scenario, Pega needs a model operator to save as and create a new operator.

It uses the model operator specified in the Unit instance to create a new operator. Make sure a model operator is available in the organization unit instance.

You can again look into the activity – AuthenticationLDAPWebVerifyCredentials activity where we open the Unit instance and use the model operator.

Step 3: Now launch the LDAP URL again and provide the credentials specified in the apache directory server.

Username – luffy

Step 4: Open the operator record and verify the operator is created today and the attributes are rightly mapped.

Done 😊

 

A technical team dedicated to empowering the Pega ecosystem with in-depth knowledge, guided by Premkumar Ganesan's vision.