Pega pxSessiontimer not working in 8.7
Hi Team,
I have been using pxSessionTimer OOTB. I have implemented the same in the portal. I am getting a log off pop up window. But after the timeout, I am not being redirected to the login window.
I am getting an error in the console window.
So If I refresh I am redirected to the log in the window but I am not redirected automatically.
Also have checked logs nothing is appearing over there.
I am using Pega platform 8.7.0.
Please refer to the attachment.
***Edited by Moderator Marije to add Capability tags***
Pegasystems Inc.
GB
@lakhank7 can you clarify - is this LDAP or SSO?
Did you use Authentication Service SAML2.0 "Use access group timeout" checkbox?
If there is no logout url populated on auth service rule, normally idp logout url will be auto populated from idp metadata in auth service rule. If there is no logout location mentioned then the page will be reauthenticated & refreshed after timeout and Default logoff activity will be triggered as there is no logout url on auth service rule.
If IDP is configured with a logout url then you have to reimport the IDP metadata which will provides by IDP with latest that will populate the logout url on auth service rule. in this case , timeout & logout will work in the same way and redirected to same page which will be redirected based on logout url. If you want to work with with current configuration then save the pxSessionTimer section to application rule set and include this section in portal header , provide the timeout value on this section properties and you have to uncheck the "Use access group timeout" check box on auth service rule.
Are you able to run a network trace to see if Pega is redirecting correctly to the logoff url?
Can you show all the steps, including the 8th step of code-security logoff activity. Make it as this: Param.IsSAMLLogoutSuccessful=="true". Test it and share the result with us.
@lakhank7 can you clarify - is this LDAP or SSO?
Did you use Authentication Service SAML2.0 "Use access group timeout" checkbox?
If there is no logout url populated on auth service rule, normally idp logout url will be auto populated from idp metadata in auth service rule. If there is no logout location mentioned then the page will be reauthenticated & refreshed after timeout and Default logoff activity will be triggered as there is no logout url on auth service rule.
If IDP is configured with a logout url then you have to reimport the IDP metadata which will provides by IDP with latest that will populate the logout url on auth service rule. in this case , timeout & logout will work in the same way and redirected to same page which will be redirected based on logout url. If you want to work with with current configuration then save the pxSessionTimer section to application rule set and include this section in portal header , provide the timeout value on this section properties and you have to uncheck the "Use access group timeout" check box on auth service rule.
Are you able to run a network trace to see if Pega is redirecting correctly to the logoff url?
Can you show all the steps, including the 8th step of code-security logoff activity. Make it as this: Param.IsSAMLLogoutSuccessful=="true". Test it and share the result with us.
If the IDP confirms that they have set a logoff URL in the rule, and the metadata has been re-imported, please log a support incident and provide details if SSO is being used and the full network trace.
If you log a support ticket for this could you provide the INC id here so that we can help track it?
Updated: 25 Apr 2022 9:58 EDT
Nagarro
IN
@MarijeSchillern Hi I am not using LDAP or SSO for the timebeing. I have just configured PEga Platform Authentication in my applicaiton.The same code is working in Pega 8.6 .
Pegasystems Inc.
GB
@lakhank7 I was only able to find the following change 'Timeout check added to authorization to preserve portal context' according to the 8.7 Resolved Issues documentation.
Fixes have usually involved specifying the Redirect URL in Auth service rule. Also see the suggestions in this post.
If no-one else has anything to add then I would suggest that you log a support incident for this.
If you chose to go down this route, could I ask that you provide the INC id here so that we can help track this with you?