Question
Pegasystems Inc.
JP
Last activity: 21 Jul 2017 9:56 EDT
How does PRPC prevent spoofing attack ?
With the PegaAcademy online course: Lead System Architect (7.1) > Security > Authenticating using SSO >
There are two lessons describing how to write an SSO authentication activity, however these lessons don't explain how PRPC prevent spoofing attack.
It sounds like anyone, who knows the "URL" returned by external access control system, could login to PRPC application.
Below is the excerpt from the online course.
How to Write a Single Sign-On Authentication Activity
In addition to establishing an operator, authentication activities can also do the following:
- Verify a token passed through from an access control system used for single sign-on. Specifically, with respect to SSO, the credential information must be passed from the external system to PRPC. This is done either through the query string portion of the URL or with custom HTTP headers..
How to Setup Single Sign-On Token Security
Let’s explain token generation and verification, and then revisit our token security authentication activity.
The token is generated in the external access control system, and then verified in PRPC.
The external system takes a password, one that is also known to PRPC, and combines it with a query string and the timestamp, to make a single string.
With the PegaAcademy online course: Lead System Architect (7.1) > Security > Authenticating using SSO >
There are two lessons describing how to write an SSO authentication activity, however these lessons don't explain how PRPC prevent spoofing attack.
It sounds like anyone, who knows the "URL" returned by external access control system, could login to PRPC application.
Below is the excerpt from the online course.
How to Write a Single Sign-On Authentication Activity
In addition to establishing an operator, authentication activities can also do the following:
- Verify a token passed through from an access control system used for single sign-on. Specifically, with respect to SSO, the credential information must be passed from the external system to PRPC. This is done either through the query string portion of the URL or with custom HTTP headers..
How to Setup Single Sign-On Token Security
Let’s explain token generation and verification, and then revisit our token security authentication activity.
The token is generated in the external access control system, and then verified in PRPC.
The external system takes a password, one that is also known to PRPC, and combines it with a query string and the timestamp, to make a single string.
A hash is generated from this string; this hash represents the token.
The external system passes the token, the query string, and sender time to PRPC using either the URL or custom headers, as discussed earlier.
PRPC then checks the Sender Time and ensures that the request is recent. If not, the verification fails. If it is considered recent, PRPC then continues and generates its own copy of the token, forming it.
The same way as the external application.
The Query String, the sender time, and its own copy of the password are combined, to create a single string.
A hash is generated from this, thus creating the token.
If the tokens match, the verification passes.
A PRPC “Application ID” instance plays a critical role in this process.
For clarity, Application ID instances are not the same as “Application” rules, which control the ruleset stack and other settings for the PRPC application you are developing.
“Application ID” data instances are specifically used for token verification. They store the password that is used, as well as the lag time, in seconds, that is considered acceptable for evaluating whether a request is considered recent.
Let’s look at an example URL that is generated by the external website to show how these values are passed to PRPC.
The “From” parameter indicates the Application ID instance, “SenderTime” is the time that the token was created, and “pw” represents the token. Do not be confused by the fact that this parameter is called “pw”. It is not the password; it is the token, which, as discussed earlier, includes the password.
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
Chunzi,
While Authentication methods used with Pega 7 are customizable, I will stick with what is generally done out of the box. There are tokens that help to prevent spoofing. However, they are not embedded in the URL, they are in a cookie that comes with the request. This cookie needs to present in the request with the URL, otherwise you will be redirected to the login screen.
The tokens in the cookie would look something like the following:
Cookie: IAC-NonGateway=%2078386187d17b829b72a35d3c634d4ec6; JSESSIONID=6EBA8B846280C09A63E0488796BAF7BB; Pega-RULES=HA921947D7D734C7442066AF08DEDFF72
In many situations you want to replace this authentication mechanism with one that is a better fit with the customer's environment. This is often an authentication mechanism that is already in place like Siteminder.
Pegasystems Inc.
US
The URL returned by the external system is not fixed and is short lived. It also requires knowledge of the password in order to be spoofed.