Basic authentication in Pega

Welcome to the series of posts on authentication topic. I hope many will be happy to see this topic in my blog (many people have requested the same). In this first article of the series, we will get started with the introduction and detailed explanation of basic authentication in Pega.

What is authentication?

It refers to the identification of an individual or a process.

Let’s start with the Facebook example. Think of how the authentication works in Facebook.

Facebook login page allows you to either login with the credentials or you can register a new account. If you are using facebook for the very first time, then you always signup first.

Signing up refers to registering your personal details with userid and password. On registering, facebook saves your credentials, assume just the normal database save. Now next time when you enter your credentials and click on login button, you will be verified with the saved data and identified as the registered individual.

The below picture is the basic authentication in Pega.

Here in the basic authentication, Pega and its database serves as the virtual identity provider.

What is an identity provider?

It is also known as IdP or IDP is a trusted system that authenticates users on behalf of other applications.

It provides user authentication as a service.

Why do you need authentication as a service?

In the very basic authentication, we saw that the authentication step is within Pega application. Pega validates the credentials against its own database, that corresponds to the Pega application.

Now think of any big organization, say AIG an insurance company. Around 20000 employees work in AIG! Usually every organization maintains their employee details in some identity management like directories. AIG also maintains some identity management for the employees.

Now, the AIG customer servicing employees need access to different AIG applications to service the customers. Do you think every application needs to have their own authentication step within the application. Why cannot they use AIG central identity management to authenticate employees in different applications?!

Below is just my own version of simple authentication architecture.

Here the web applications use Authentication as a service!

What are the most common protocols used in authentication?

1. LDAP – Lightweight Directory Access Protocol.
2. Oauth2
3. SAML – Security Assertion Markup language
4. OpenID connect

I will not go much detail into these protocols and IdPs in this post. I will create separate posts for those!

Let’s get back to the basic authentication in Pega.

I am using personal edition and so basic authentication is default enabled.

Just open the designer studio launch page – http://localhost:8080/prweb/PRServlet

So, what really happened at the backend?!

First, let’s look back at the URL resource path again – http://localhost:8080/prweb/PRServlet  /prweb/PRServlet

PRServlet – refers to the servlet name.

What is servlet?

Servlet is a java program that extends the capabilities of a server. It means it can respond to any incoming request and construct responses.

Servlet definitions of the web applications are configured in the web.xml file.

Now, what is web.xml file?

Technically it can be defined as the Web Application Deployment Descriptor of the application.

It is an XML document that describes the servlets and other components like listeners, filters etc.

Usually, you will find the web.xml file under /WEB-INF/web.xml

Let’s look at the file from our personal edition.

Step 1: Click on the location or folder where you have installed your personal edition.

Step 2: Switch along the path tomcat->webapps->prweb->WEB-INF

You will find the web.xml file.

Step 3: Open the web.xml file, preferably using the Notepad++

Under web-app tag, you see different tags – servlet, servlet-mapping, mime-mapping, security tags, listeners etc.

Let’s look at servlet and servlet-mapping tags.

You see the servlet-name – WebStandard

Note the AuthenticationType parameter is PRBasic.

Note: It is commented, because  PRBasic is the default authentication type when the parameter is not specified.

Now let’s see the corresponding servlet mapping for the WebStandard servlet name.

You see the URL pattern for the WebStandard servlet is /PRServlet and /PRServlet/* with a wild character *

Thus the incoming to this servlet URL is properly responded back when you hit the URL

http://localhost:8080/prweb/PRServlet 

There is one another interesting servlet mapping for the WebStandard servlet.

WebStandard servlet just maps to /* wild card.

It means, you can access pega application with http:// localhost:8080/prweb

Feel free to explore the web.xml file. I will be referring the same file in the upcoming posts as well 😊

Now let’s see some pega rules involved in launching the login page.

You won’t get all the technical rule details directly!! It is all properly buried under Pega rule engine java code.

The first thing is a new browser requestor session is launched.

Step 1: Open the browser requestor type – pega

Records -> SysAdmin -> Requestor types

Note: If you have used different system name, try opening corresponding browser requestor type.

Switch to Activities tab and you will see in the starting activity, Web-Start is called!

So as soon as the browser requestor session is launched, Web-Start activity gets called.

Step 2: Open the activity – Web-Start

You see, it calls the function – PresentAuthentication(), the pega engine code. You can view the details of this function by navigating to the Engine API

Click on the class – PRAuthentication to check the function details (not much details 😊)

The HTML  Web-Login rule is responsible to render the default pega login page.

If you need to customize the login page, then you may need to override the Web-Login rule form in your application ruleset. (I will make a short post on customizing the login page later!)  

Now, let’s get back to the login page.

As I said, a new browser requestor is initiated. You know you can always tracer any browser requestor session from your machine.

Open the tracer and click on remote tracer. Look out for the browser requestor (starts with H) without any operator associated, because still we are in login page – Unauthenticated.

Remember to select the DB query option in the tracer settings.

I purposefully entered the wrong password and clicked Log in.

In the above tracer you see, the DB queries on the PR_OPERATORS table for the operator ID – Prem.

Next time, open the tracer and provide the right credentials.

You will see the operator gets validated successfully and 3 activities are called sequentially.

1. InitialProfileSetup
2. ApplicationSetup
3. ShowDesktop

ShowDesktop activity is responsible to launch the harness specified in the corresponding portal.

ShowDesktop activity is referred in the operator rule form.

End of the basic introduction about authentication. Let’s dive in deep in the next articles!