Question
Coforge
US
Last activity: 6 Jan 2021 10:06 EST
Issue with two authentication services on same server [error defaults to one]
Here is something different happening to us in prod. We have two applications that are running on the Pega cloud and authenticated using Okta. Assume the two apps to have authentication URL using SP as https://division.organization.com/prweb/PRAuth/App1 https://division.organization.com/prweb/PRAuth/App2
We have two authentication services setups, the service activity has been written in such a way that even if the operator exists, they remove the current access group and add the required access based on the authentication service. One thing to say is App2 was released into prod after App1 and there are users who are common to both the applications. For these types of users [in order]
- When they log in to App2 (works properly).
- When they log in to App1 (works properly).
- When they try to access App2 (doesn't work as expected). Logs the user into the App1.
We must delete the operator id to allow the user to login to App2 again.
Has anyone in the Pega realm has encountered this issue.
***Edited by Moderator Kayla to update Content Type from Discussion to Question***
Accepted Solution
Coforge
US
Well, this issue was solved by making the changes to the access group to the operator and saving the operator id explicitly with obj-save write now.
Since it was post-authentication activity, not authentication activity that was the way to go.
Updated: 9 Nov 2020 1:02 EST
Coforge
US
One more additional finding on this.
- Users logs into app 2 (https://division.organization.com/prweb/PRAuth/App2)
- The user then logs into app 1 (https://division.organization.com/prweb/PRAuth/App1)
- Login to the admin studio and clear off all the requestors by using a terminate requestor.
- Then try to login to app 2 (https://division.organization.com/prweb/PRAuth/App2)
- Works perfectly this time.
So, if without killing the requestor if I try it picks up from passivation. Btw in app 1 "Use access-group timeout" is set.
Accepted Solution
Coforge
US
Well, this issue was solved by making the changes to the access group to the operator and saving the operator id explicitly with obj-save write now.
Since it was post-authentication activity, not authentication activity that was the way to go.
Pegasystems Inc.
US
Thank you for sharing your resolution and marking it as the solution @imranullah!
This will help users in the future who also have the same question! Much appreciated!