Summary

Users are not challenged to re-authenticate after the time interval of interaction with PRPC specified for the Access Group has timed out. This problem was reported for PRPC deployments that are configured as follows:

• A custom authentication type, for example, PRCustom or PRExternal, is used.
• For the users' Access Group, the Access Control field AuthenticationTimeout is set to a value greater than 0.
• The corresponding DATA-ADMIN-AUTHSERVICE defined for the custom authentication type has, on the Custom tab, both of the following timeout options specified:
  • Use PegaRULES Timeout
  • One of the following options:
    • Use Basic Authentication for Timeout
    • Timeout Challenge Stream is defined

Explanation

The root cause of the problem is that user credentials are not available when the activity AuthenticationTimeOut is processed. For the cases reported, the custom activity serves both as the authentication activity and the timeout activity. During initial authentication, the user ID and password are available. However, during timeout, there is a two-phase processing of the activity.

On the first pass, the default challenge is set to prompt for the user's credentials. At that time, the property param.pyWasTimedOut is set to false. This indicates that the activity:

• Does not have the credentials at this time
• Should do whatever else it can without the credentials (by default, nothing else) and exit

On the second pass, after the user's credentials are provided to the challenge response, the activity AuthenticationTimeOut is processed again. This time, the property para.pyWasTimedout is set to true, and the credentials provided by the user are now available to continue the custom authentication process as performed in the initial authentication.

Credentials

Note that the credentials from basic authentication come in through the HTTP request header. The authentication that happens initially is typically form-based, and the details are in the post data.

In either case, PRPC will normalize the input so that, after the property para.pyWasTimedout is set to true, the details are available to the activity in a consistent manner. Therefore, always test the activity AuthenticationTimeOut to ensure that on its second run, the property para.pyWasTimedout = true, as only then will user credentials be available.

Suggested Approach

To prevent this problem, follow these steps to specify the activity DATA-ADMIN-AUTHSERVICE AuthenticationTimeOut, ensuring that the property para.pyWasTimedOut is set correctly for both the first and second phases of the activity:

1. On its first pass, specify the activity AuthenticationTimeOut to be called with property para.pyWasTimedOut = false.

This setting controls the first request from a user after the access group timeout interval has been exceeded. The activity AuthenticationTimeOut stops processing and returns a value for .pyChallenge set to @java("PRAuthentication.DEFAULT_CHALLENGE").

The DEFAULT_CHALLENGE option will directly issue a challenge using either a stream (form-based challenge) or HTTP BasicAuthentication based on settings in the DATA-ADMIN-AUTHSERVICE record’s Custom tab.

1. On its second pass, specify the activity AuthenticationTimeOut to be called with property para.pyWasTimedOut = true.

This setting controls the second request from a user responding to the challenge with credentials using basic authentication or stream-based authentication.

This time, the activity AuthenticationTimeOut continues with the custom authentication process, which will be consistent with how the user authenticated during initial sign-on.

Additional Information

About Requestor Timeouts

Timeouts - definition

Authentication Service form, Completing the Service tab