INC-155813 · Issue 629506
SAML SSO redirects to correct URL when application and authentication aliases match
Resolved in Pega Version 8.5.3
Whenever there was a match in the authentication service alias and the application alias, the application alias was replaced with empty after logoff instead of making the authentication service alias empty. For example, given an authentication service with the alias XYZ ("login with XYZ" alias option) and an application name XYZMyOps, the application alias was being changed from XYZMyOps to appMyOps after logoff. As a result, a blue screen error resulted when clicking on button "login with XYZ" again because it redirected to appMyOps, which didn't exist. This has been resolved by removing authservicealias and modifying AuthServiceAliasHelper.adjustPathIfAuthServiceAliasPresent() to change the method for calculating the pathinfo to string tokenizing
SR-D64566 · Issue 547513
Option added for redirect to SAML IDP on logout
Resolved in Pega Version 8.3.3
An enhancement has been added which provides a check box to choose to redirect to SAML IDP on logout from Pega.
SR-D90452 · Issue 551808
SSOPreAuthenticationActivity runs until success
Resolved in Pega Version 8.3.3
When a user visited a public-facing application via a Single Sign-On (SSO) URL that redirected to SAML IDP for authentication, the first time the URL was hit the system correctly executed pySSOPreAuthenticationActivity as part of pre-authentication to determine if authentication is possible/allowed. If the pySSOPreAuthenticationActivity set the pyAuthenticationPolicyResult to 'false', authentication was not allowed: the user was not redirected to the IDP and an error message was shown. However, if the same URL is hit again after that rejection without any changes, the user was redirected to the IDP for authentication because the preauthentication activity was not run again. This has been resolved by updating the system to continue to call the pre-authentication activity for the SSO URL until a success status is returned by the activity.
SR-D79181 · Issue 551123
OKTA receives parameters on logout
Resolved in Pega Version 8.3.3
When using an OIDC logout endpoint with a parameter set as a data page value, the data page retrieved the ID Token from the database, but when logout was clicked the datapage name was being displayed in the browser instead of the IDToken. To resolve this, code has been added to support sending ID token parameters for logoff endpoint for OKTA logoff using OpeniD connect.
SR-D92837 · Issue 551004
SameSite cookie setting updated for pre-authentication
Resolved in Pega Version 8.3.3
In work done in previous versions to modify the SameSite cookie handling to support Mashups in Google Chrome v80+, SameSite was set to None only in case of an authenticated Pega-RULES cookie and not for a Pre-authenticated cookie. That caused the Samesite value to not be set when using a pre-authenticated cookie, and the blank value was treated as 'Lax', causing a login challenge. To resolve this, Samesite will be set to 'None' when using pre-authenticated cookie, which will match the way it is being set in authenticated cookie.
INC-155276 · Issue 626619
Null check added for step page
Resolved in Pega Version 8.5.3
After creating and adding new Access Roles and application 'Access When' to the privileges instead of Production level, during run time the error "runtime.IndeterminateConditionalException: Trying to evaluate Rule-Access-When conditions L:IsProdAccess when there is no page to evaluate them against" appeared for the specific privileges. This was traced to a missed use case where the system falls back to the step page if the page for evaluating the 'when' condition is null, which did not account for scenarios where the step page can be null. To resolve this, a null check has been added which will fetch the primary page if the step page for the access 'when' condition is null.
INC-154311 · Issue 615684
Decryption updated for External assignment routed with DWA
Resolved in Pega Version 8.5.3
When an external assignment was routed to a user using DWA, the user was able to access the assignment but received the error "There has been an issue; please consult your system administrator" when submitting. Investigation showed this was caused by the system attempting to decrypt the External assignment with the requestor level key, causing the decryption to fail with a NumberFormatException. To resolve this, the system will check if the obfuscated string starts with Global encryption key prefix and then decrypt with the global encryption key by trimming out the prefix.
SR-D75498 · Issue 545068
Resolved null-pointer exception for Token based Authenticated Rest
Resolved in Pega Version 8.3.3
When logging in with auth0 OIDC auth service and then trying to use connect-Rest with an authentication profile using an auth0 provider, a null pointer error was generated indicating connect-Rest could not find the Access token. Even thought the Authentication service (OIDC) and authentication profile (authorization grant) both had the same scopes (“openid profile email”), OIDC flow and authentication profile save the Access Token with different scopes. Specifically, OIDC saves the token with an extra trailing space. Handling has been added to correct this.
INC-154627 · Issue 619571
Re-enabled users are able to log in
Resolved in Pega Version 8.5.3
When disabled operators were re-enabled through operator management, the forced password change on next login was manually unchecked but the operators were unable to login because the change password screen was displayed without any password entry fields. This was a missed use case for handling the change password flag on a requestor , and has been resolved by having the system skip setting the change password on next login flag for disabled users.
INC-153957 · Issue 615290
Cache key handling updated for OAuth2 Connect-REST
Resolved in Pega Version 8.5.3
After upgrade, a Connect-REST using OAuth2 credentials was failing with HTTP response code 403 when the Connect-REST was invoked by the agent, but the Connect-REST was successfully invoked from web node with the same Auth profile. OAuth2 tokens are stored in the cache and database. In this specific environment the key formation was happening differently on the utility node for batch processes, causing different keys to be formed for the same token. This has been resolved by adding a provider filter and updating the cache key.