Question
Wipro
IN
Last activity: 3 Dec 2025 1:53 EST
REST Service with Authentication with external Identity provider Azure AD
Hi Team,
In our project we are developing a couple of REST services. For all these services we are planning to authenticate the callers by using Azure AD. Azure AD is used as enterprise-wide identity provider.
To achieve this, in service package of Rest service we set Auth type as "Custom". We created a token-based Authentication service. In this Auth service, we configure Identity mapping rule and in Identity mapping rule I have referred a token profile rule. I have verified with my Security team that all details in these rules are correct. When I say details, I mean Issuer, Audience, Key store etc.
After doing all these, when we call our REST web service from PostMan we see 401 (Unauthenticated) response and in Log file we get below error.
Custom authentication service invalid, an Authentication Activity is required in the Data-Admin-AuthService instance 'APRIntAuthService'
I am not sure where should I provide Authentication activity, in my Auth service I see only Pre Auth and Post Auth activity placeholder.
I already referred these post - Service REST OAuth2 - External OAuth2 Provider | Support Center
Securing Service-Rest with external oAuth provider like Okta | Support Center
Accepted Solution
Updated: 3 Dec 2025 1:53 EST
Pegasystems Inc.
NL
@RajeshKumarY6297 I have reviewed the documentation and log file you sent. Based on what I see I believe the error "No failure response set by custom authentication activity" occurs when the custom authentication activity completes without properly establishing the operator context. The log shows a critical clue: "After activity processing, primary page is no longer valid." This tells us that even though the JWT validation succeeded, the activity didn't set up the operator session correctly.
When using Custom authentication, Pega expects one of two outcomes from the authentication activity. Either the authentication succeeds and you provide a valid operator page via the pyOperPage parameter, or it fails and you provide an error message via the pyFailMessage parameter. When neither is provided, Pega throws this exception because it's an invalid state. The current implementation is validating the JWT token (which works fine) but then stops without actually logging the user in. The error message is Pega's way of complaining that the authentication activity didn't complete its job properly: it neither logged someone in successfully nor explicitly reported a failure.
The solution is to add a step in the custom authentication activity that properly sets the operator context. After the JWT validation succeeds, you need to add a Java step with this code:
@RajeshKumarY6297 I have reviewed the documentation and log file you sent. Based on what I see I believe the error "No failure response set by custom authentication activity" occurs when the custom authentication activity completes without properly establishing the operator context. The log shows a critical clue: "After activity processing, primary page is no longer valid." This tells us that even though the JWT validation succeeded, the activity didn't set up the operator session correctly.
When using Custom authentication, Pega expects one of two outcomes from the authentication activity. Either the authentication succeeds and you provide a valid operator page via the pyOperPage parameter, or it fails and you provide an error message via the pyFailMessage parameter. When neither is provided, Pega throws this exception because it's an invalid state. The current implementation is validating the JWT token (which works fine) but then stops without actually logging the user in. The error message is Pega's way of complaining that the authentication activity didn't complete its job properly: it neither logged someone in successfully nor explicitly reported a failure.
The solution is to add a step in the custom authentication activity that properly sets the operator context. After the JWT validation succeeds, you need to add a Java step with this code:
tools.getParameterPage().putObject("pyOperPage", myStepPage);
myStepPage is a reference to an opened operator page. Looking at the JWT payload in the log file, I can see there's an "api_user" claim with the value "APIERIMATCH". This should be used to identify which operator to open.
Here's the recommended flow for the authentication activity:
- Call pxProcessJWT to validate the JWT token (they're already doing this successfully)
- Extract the operator identifier from the JWT claims (the "api_user" field shows "APIERIMATCH" currently)
- Use Obj-Open to open that operator
- Set the parameter:
tools.getParameterPage().putObject("pyOperPage", myStepPage)where myStepPage is the opened operator - Set
pyIsAuthenticated = true - Make sure this step happens BEFORE any error handling logic
The key issue is that the current activity is successfully validating the token but then not establishing the operator session, which leaves the authentication in an incomplete state. By adding the pyOperPage parameter setting, you are properly completing the authentication handshake.
Wipro
IN
@DavidElvar I see a post where you gave reply on the similar query. May I ask your advice on above query as well. Thanks, in advice David.
Rajesh
Wipro
IN
@DionLammers can you please help on this issue, Thanks in advance.
Pegasystems Inc.
NL
@RajeshKumarY6297In Pega, when you set the Service Package Auth type to Custom, the linked Authentication Service must also be a Custom Authentication Service, not just a token-based one. Token-based authentication is typically used for OAuth 2.0 or JWT validation, but if you choose “Custom” in the service package, Pega expects an Authentication Activity to be defined in the Authentication Service rule. If you want to use Azure AD with JWT/OAuth 2.0, try to use OAuth 2.0 Authentication Profile and configure the service package to use OAuth 2.0 instead of “Custom”.
If you want to stick with Custom Authentication, then:
- Create an Authentication Activity in
Code-Securityclass. - This activity should:
- Validate the JWT token (e.g., using
pxProcessJWT). - Set
pyIsAuthenticated = trueand operator context. - Fail gracefully if validation fails.
- Validate the JWT token (e.g., using
- Reference this activity in the Custom Authentication Activity field of your Authentication Service
Wipro
IN
@DionLammers As you suggested we setup rules as below.
Service Package set to Auth Type - Custom.
Created Custom Authentication Service.
Configured Timeout and Authentication activity.
In Authentication activity we call pxProcessJWT (OOTB) to validate the JWT. This activity is validating the token without any issue.
After we invoke service from Postman, we see error in log file - .PRRuntimeException: No failure response set by custom authentication activity
To work around this, we are setting - Param.pyFailMessage and Param.pyStatus parameters.
Both of these parameters are defined as OUT parameter of the Authentication activity
But still Pega shows error in log - No failure response set by custom authentication activity .
Please suggest some work around for this. Thanks in advance- Rajesh
Pega Version - 8.6.1
Accepted Solution
Updated: 3 Dec 2025 1:53 EST
Pegasystems Inc.
NL
@RajeshKumarY6297 I have reviewed the documentation and log file you sent. Based on what I see I believe the error "No failure response set by custom authentication activity" occurs when the custom authentication activity completes without properly establishing the operator context. The log shows a critical clue: "After activity processing, primary page is no longer valid." This tells us that even though the JWT validation succeeded, the activity didn't set up the operator session correctly.
When using Custom authentication, Pega expects one of two outcomes from the authentication activity. Either the authentication succeeds and you provide a valid operator page via the pyOperPage parameter, or it fails and you provide an error message via the pyFailMessage parameter. When neither is provided, Pega throws this exception because it's an invalid state. The current implementation is validating the JWT token (which works fine) but then stops without actually logging the user in. The error message is Pega's way of complaining that the authentication activity didn't complete its job properly: it neither logged someone in successfully nor explicitly reported a failure.
The solution is to add a step in the custom authentication activity that properly sets the operator context. After the JWT validation succeeds, you need to add a Java step with this code:
@RajeshKumarY6297 I have reviewed the documentation and log file you sent. Based on what I see I believe the error "No failure response set by custom authentication activity" occurs when the custom authentication activity completes without properly establishing the operator context. The log shows a critical clue: "After activity processing, primary page is no longer valid." This tells us that even though the JWT validation succeeded, the activity didn't set up the operator session correctly.
When using Custom authentication, Pega expects one of two outcomes from the authentication activity. Either the authentication succeeds and you provide a valid operator page via the pyOperPage parameter, or it fails and you provide an error message via the pyFailMessage parameter. When neither is provided, Pega throws this exception because it's an invalid state. The current implementation is validating the JWT token (which works fine) but then stops without actually logging the user in. The error message is Pega's way of complaining that the authentication activity didn't complete its job properly: it neither logged someone in successfully nor explicitly reported a failure.
The solution is to add a step in the custom authentication activity that properly sets the operator context. After the JWT validation succeeds, you need to add a Java step with this code:
tools.getParameterPage().putObject("pyOperPage", myStepPage);
myStepPage is a reference to an opened operator page. Looking at the JWT payload in the log file, I can see there's an "api_user" claim with the value "APIERIMATCH". This should be used to identify which operator to open.
Here's the recommended flow for the authentication activity:
- Call pxProcessJWT to validate the JWT token (they're already doing this successfully)
- Extract the operator identifier from the JWT claims (the "api_user" field shows "APIERIMATCH" currently)
- Use Obj-Open to open that operator
- Set the parameter:
tools.getParameterPage().putObject("pyOperPage", myStepPage)where myStepPage is the opened operator - Set
pyIsAuthenticated = true - Make sure this step happens BEFORE any error handling logic
The key issue is that the current activity is successfully validating the token but then not establishing the operator session, which leaves the authentication in an incomplete state. By adding the pyOperPage parameter setting, you are properly completing the authentication handshake.
Wipro
IN
@DionLammers thanks a ton sir! I set operator context like you mentioned and it worked. Marking your reply as "Accepted Solution."