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
INC-188162 · Issue 673507
RSA-PSS signature support added for for SAML SSO
Resolved in Pega Version 8.7
The XML security jars have been updated to incorporate RSA-PSS signature algorithm support.
INC-160485 · Issue 655296
Trailing "/" added to public links for SSO use
Resolved in Pega Version 8.5.5
Links generated using pyWorkLinkWithLabel were not working with SSO due to not having a trailing "/" on the URL. This has been corrected by adding code to append the "/" if the public link url doesn't end with it.
INC-160485 · Issue 655297
Trailing "/" added to public links for SSO use
Resolved in Pega Version 8.7
Links generated using pyWorkLinkWithLabel were not working with SSO due to not having a trailing "/" on the URL. This has been corrected by adding code to append the "/" if the public link url doesn't end with it.
INC-178148 · Issue 660926
Handling added for SSO servlet name
Resolved in Pega Version 8.5.5
After update, logging into an external site was not working correctly due to the SSO URL being appended with "/app/default". This has been resolved by updating the code to handle the servlet name properly.
INC-178148 · Issue 660924
Handling added for SSO servlet name
Resolved in Pega Version 8.7
After update, logging into an external site was not working correctly due to the SSO URL being appended with "/app/default". This has been resolved by updating the code to handle the servlet name properly.
INC-188405 · Issue 673063
Handling added for SSO servlet name
Resolved in Pega Version 8.7
After update, logging into an external site was not working correctly due to the SSO URL being appended with "/app/default". This has been resolved by updating the code to handle the servlet name properly.
SR-D29127 · Issue 506863
SAML data pages restored after passivation
Resolved in Pega Version 8.2.4
If login used SAML SSO, resuming the session after passivation resulted in missing or empty data pages when using an SAP integration with Pega Cloud. This was traced to a security change that modified the D_SAMLAssertionDataPage and D_SamlSsoLoginInfo data pages as readonly, causing them to not be passivated under these conditions. To resolve this, the data pages have been made editable so they will be restored as expected. This change also resolves any difficulty with SAML logoff activities in conjunction with SAP and Pega Cloud.
INC-160767 · Issue 628374
Email headers correctly mapped when using MSGraph
Resolved in Pega Version 8.5.3
The value of "Send Date" was not correctly populated when using MSGraph instead of IMAP, causing the Email Listener to fail. Microsoft populates the "sendDateTime" field in the JSON with the value of the RFC 822 email header "Date:", but this value was not being passed to Java object of type "Message" as part of the query. To resolve this, ReceivedDateTime and SentDatetime have been added in the select filter of getMessagebymessageID.
INC-174267 · Issue 657129
Wait action persists when using Urgency Adjustment
Resolved in Pega Version 8.5.5
When using the Urgency Adjustment (pyAdjustAssignmentsla standard local action), once a case reached the wait action and the goal and deadline were updated the previous pyWaitAction was not being stored. This has been resolved by ensuring the previous pyWaitAction will be stored and passed to the AddAssign activity.