Question
Barclays
IN
Last activity: 14 Sep 2020 4:52 EDT
Tracing unauthenticated requestor accessing through PRServletContainerAuth
We are trying to implement SSO using container based authentication (PRServletContainerAuth) in our application on Pega v8.3 hosted on Websphere server.
we have specialized the EstablishOperator activity and this activity is perfectly exceuted at the moment.
By adding log messages in the activity we have verified that it is called from SSO URL
However, we're not able to trace this activity and all processes being called from it. We want to debug it in order to add our authorization logic.
I could not get much relevant content around this.
Steps that I have ensured are as further,
- EstabishOperator and related sub activities are specialized in a separate unauthenticated ruleset.
- There is a separate unauthenticated access group created and an unauthenticated application version which has this unauthenticated ruleset in its stack.
- The "<systemname>.BROWSER" requestor type instance points to this specific unauthenticated access group.
- Using the <url>/prweb/PRServletContainerAuth in a separate browser session and trying to trace the requestor.
- Verified that the "unauthenticated ruleset" is listed in the tracer rulesets list.
I have not done any specific configuration in prconfig.xml.
Is there something I have missed to configure in order for the tracer to trace this events ?
Pegasystems Inc.
AU
The challenge you have found with the Tracer is that the Requestor needs to exist in order to attach the Tracer to it, but in authentication scenarios the (unauthenticated) Requestor is created in the same breath as the authentication activities that run.
Consider whether there is a way to emulate running the authentication activity from an existing requestor, but this may be infeasible if your implementation is in any way dependent on HTTP headers.
Other approaches you can try:
The challenge you have found with the Tracer is that the Requestor needs to exist in order to attach the Tracer to it, but in authentication scenarios the (unauthenticated) Requestor is created in the same breath as the authentication activities that run.
Consider whether there is a way to emulate running the authentication activity from an existing requestor, but this may be infeasible if your implementation is in any way dependent on HTTP headers.
Other approaches you can try:
- You mentioned needing to trace the "processes being called by it". If those are rules your team has introduced, design them in such a way that a specific combination of inputs (or clipboard state) can yield a predictable set of expected results. Then, build some PegaUnit test cases to run those rules - as standalone rules (not as part of your authentication sequence) using those inputs and assert that the expected results are actually attained. If the rules called by your authentication activity can be shown to behave as you expect for all known sets of inputs, then your authentication activity is more likely to work as a whole. Then you can re-run these tests over and over again.
- Set the Logging Level on the authentication activity to DEBUG from Dev (or Admin?) Studio. If you can't trace, emulate execution or PegaUnit parts of your sequence, DEBUG logs for an Activity will at least log which steps in the Activity are performed. From this you can deduce what conditions must be true/false during execution to cause the Activity to jump do, say Step 22 immediately after Step 7.
Please post back your findings on what worked for you.