SR-D23239 · Issue 499591
Support added for multi-operator SAML logins
Resolved in Pega Version 8.4
When a SAML user logged in by Single Sign-On (SAML), the system processed the login to portal as a different operator if there was a function on the Attribute field under Operator identification in the SAML authentication service. In this scenario, using an expression for operator provisioning did not work because all SAML login sessions resolved to same first operator due to parseAndEvaluateExpression() in ExpressionHelper.java ignoring new expression arguments if the expression page already existed. To support the use of multiple operator logins in this format, the system has been updated to clone a new expression page for every session and update it with the correct expression arguments.
SR-D31734 · Issue 515657
XSS protection added for parameter page properties
Resolved in Pega Version 8.4
An XSS vulnerability was seen with the Edge browser when run on visibility on client check was enabled with dynamic layouts and some properties were accessed from parameter page. Because run on visibility on client check is not required in this scenario, is has been removed and the values will be accessed from the server instead.
SR-D47685 · Issue 514647
Cookie logging restored
Resolved in Pega Version 8.4
As part of security updates, Cookies were restricted from being logged. However, this caused some business use cases such as a custom function call to obtain the list of cookies that are present in the application to stop working. To resolve this, the cookie logging restriction has been reverted.
SR-D23239 · Issue 499595
Support added for multi-operator SAML logins
Resolved in Pega Version 8.3.1
When a SAML user is logged in by Single Sign-On (SAML), the system processes the login to portal as a different operator if there was a function on the Attribute field under Operator identification in the SAML authentication service. In this scenario, using an expression for operator provisioning did not work because all SAML login sessions resolved to the same first operator due to parseAndEvaluateExpression() in ExpressionHelper.java ignoring new expression arguments if the expression page already existed. To support the use of multiple operator logins in this format, the system has been updated to clone a new expression page for every session and update it with the correct expression arguments.
SR-D47611 · Issue 513113
HTTPS login path issue resolved
Resolved in Pega Version 8.3.1
When using iOS, entering wrong credentials for a login with an https endpoint converted the URL to http. This was traced to a case where the resourcePath was coming as http in SSL enabled system, but the reqURI was still https. To correct this, the system has been updated so that if the reqContextURI starts with https and the requestURL starts with http, then the requestURL will be converted to https.
INC-118838 · Issue 560691
OKTA receives parameters on logout
Resolved in Pega Version 8.2.7
When using an OIDC logout endpoint with a parameter set as a data page value, the data page retrieved the ID Token from the DB, 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-D95148 · Issue 557483
Port validation updated for redirect URI
Resolved in Pega Version 8.2.7
When an offline app for windows client was generated, trying to login via SSO resulted in the error "invalid redirect_uri". This was traced to the system validating the whole loopback redirection URL, e.g. "http://127.0.0.1:1234/redirection", including the port number. To enhance flexibility, an update has been made so that the port number will not be validated, allowing the client to establish it based on availability at the moment of the request to the authorization service. NOTE: As a best practice, a loopback URL should not be configured as a redirect URI. If a loopback URL is configured, then at run time the port number will not be validated, and the client application can use any available port on the system including ports that may not be intended for use.
INC-134046 · Issue 575238
database locking improved for login performance
Resolved in Pega Version 8.5
A slowness issue seen when trying to login to my.pega.com was traced to numerous database locks occurring on the pr_data_saml_authreqcontext table during the SAML flow. Analysis showed that while running Obj-Save on AuthRequestContext with 'OnlyIfNew' as false, the check caused a select query to run on the table to determine if the context was already there and insert it if it was not. To resolve this, the onlyIfNew check will default to true to avoid running the query; if the context is already present it will be overridden. Duplicate key exception handling has also been added to avoid any issues if a resave is done with same key.
SR-D96395 · Issue 555118
CDK key loading modified for better database compatibility
Resolved in Pega Version 8.5
Users were unable to log on to the system and received the error "There has been an issue; please consult your system administrator." Investigation showed the log errors stating "(dataencryption.DataKeyProvider) ERROR localhost - Could not get CDK from systemKeyManagementCache - System CDK is null". This was an issue specific to the MS SQL Server database when there were 6 or more CDKs in the database: CDK keys are loaded from database into Cache using an SQL statement which had the ORDER clause. By default, the ORDER clause treats NULL values differently on different databases, and this caused MS SQL databases to not load a necessary CDK key. To resolve this, the SQL query has been modified so the result will be the same for all supported daatbases (Oracle, Postgres & MS SQL Server).
INC-132209 · Issue 577000
CDK key loading modified for better database compatibility
Resolved in Pega Version 8.5
Users were unable to log on to the system and received the error "There has been an issue; please consult your system administrator." Investigation showed the log errors stating "(dataencryption.DataKeyProvider) ERROR localhost - Could not get CDK from systemKeyManagementCache - System CDK is null". This was an issue specific to the MS SQL Server database when there were 6 or more CDKs in the database: CDK keys are loaded from database into Cache using an SQL statement which had the ORDER clause. By default, the ORDER clause treats NULL values differently on different databases, and this caused MS SQL databases to not load a necessary CDK key. To resolve this, the SQL query has been modified so the result will be the same for all supported daatbases (Oracle, Postgres & MS SQL Server).