On January 11 and 12 we hosted the cLSA Security Excellence webinar as part of the CLSA Continuous Excellence Enablement (C2E) program that is focussed on targeted content on platform topics and from a Pega 8 perspective. This webinar was focussed on security and discussed authentication, authorization and security features in Pega. A number of questions was asked during the webinar that couldn't all be answered during the session. This discussion posts the questions with answers about Authentication. 

The full webinar recording can be found: https://collaborate.pega.com/discussion/clsa-security-excellence-webinar-recording-handout-january-2021

OIDC versus SAML - what is recommended? And as LSA what should we advise?

If this isn’t yet decided by the client, the preference is to use OIDC because it is simpler and becoming widely adopted. But both of them are equally secure.

How could we prevent Session Management Replay and prompt the active user if additional users is attempting to login with the same user id?

We can limit concurrent operator sessions. See https://community.pega.com/knowledgebase/release-note/improve-cluster-security-limiting-concurrent-operator-sessions

As Pega 8 is supporting to have multiple applications within PRAuth , how can we have different login pages for different application as we have only one "unauthenticated access group"

The following pattern https://<servername>:<port>/prweb/PRAuth/app/<appalias>/<authserviceAlias> in combination with one unauthenticated access group & ruleset should works fine to deliver the requirement. Typically one system has one set of rules for authenticating that can support multiple applications. As of Pega 8.6 you will have the option to map authentication services to individual applications.

Is there any dynamic switch provided between different types of authentications like SAML, OIDC, BASIC or LDAP if they are preconfigured in the system?

There is no dynamic switch. However, the URL pattern https://<servername>:<port>/prweb/PRAuth/app/<appalias>/<authserviceAlias>  specifies which app and auth services to run.

What are the options for automated provisioning when dealing with users that have access to multiple applications? How to map the list of access groups and can we dynamically assign the default access group based on a specific application (for example using the URL)?

A Data Page is the correct approach to mapping multiple Access Groups based on the SAML or JWT response. In the latest releases of Pega, the URL looks like this https://<servername>:<port>/prweb/PRAuth/app/<appalias>/<authserviceAlias>

You could then extraxt the app from the URL using an approach as documented here https://collaborate.pega.com/question/how-get-query-parameter-url-authentication-activity to determine the default access group based on the requested app alias.

When you switch from guest to authenticated, do you get a new session? Or does the operator associated with your current session change?

Same Requestor and thereby same cookie would be maintained during reauthentication.

When running the pyReAuthGadget flow action, the user will reuse the same requestor and will not get a new requestor. Thereby the same pegarules cookie will be maintained during reauthentication.

ANONYMOUS

The anonymous user session remains alive for a very long time. How can we terminate the anonymous user session? Is there a way configure the timeout for this anonymous session?

The anonymous auth service is also associated with an access group. For non-anonymous sessions that context is switched to the application access group after authentication. You can configure timeout for both in the respective access groups.

When switching Authentication from Anonymous, is a new operator created on the fly? If yes, does the authentication information then come from a different IDP?

Yes, if the pyReAuthGadget triggers a signed response from an IDP with a principal that does not exist, the operator will be created. See https://community.pega.com/knowledgebase/articles/security/85/configuring-application-use-anonymous-authentication-service

AUTH PROFILE

When moving an authentication profile from one environment to another environment, we need to re-enter the secret again. It appears the secret value is not carried over. Is this expected behaviour?

Yes, this is expected behavior. They are encrypted with platform cipher with a key that is unique to thatenvironment. It's advised to add them to bypass override section on the deployment tab in your product rule, so they are deployed, but never updated and you can safely change the secret.

MASHUP

For mashups, is it possible to do an auto-log-off when the hosting application logs off from the browser or when the user closes the browser?

No, Pega would not capture the event. To ensure that the session is terminated you do need to set the timeout on the Access Group.

When using silent authentication in web mashup, how does Pega gets the user details from the browser session?

There will be a session cookie already present in the browser issued by the IDP. When Pega instructs the browser to redirect to the IDP, the cookie will be posted as well, this provides the identitiy.

OIDC

Does Pega support the OIDC silent token refresh?

It depends on the situation. When Pega is the client, Pega's OIDC Authentication Service does not support silent token refresh. However, you can set prompt=none on the authorization endpoint, when you already have a valid session cookie. This will result in a similar behavior to a refresh token.

When Pega is the server, Pega's Confidential Client Registration rule does support a silent refresh. Therefore, if you have an angular/react/mobile app authenticating with a client registration you will get a silent refresh. Look at: https://community.pega.com/knowledgebase/articles/security/85/creating-and-configuring-oauth-20-client-registration

TIMEOUT

What is the best practice for setting authentication timeouts?

Always be conservative and rely on Access Group timeouts in combination with @baseclass.pxSessionTimerreferenced from your portal rule. Only after you have been able to test out and validated the expiry in the JWT/SAML is being propogated into the Pega session then you can disable the access group timeout. See https://community.pega.com/knowledgebase/articles/security/85/authentication-time-out

What is the best way to timeout a user logged in to a mashup using an Anoymous auth service?

An Anonymous Auth Services also has to have an operator context and therefore there is a access group attached. In there you can use the Access Group timeout.

Does global session timeout work across multiple pega apps (opened in separete browser tabs)? Will the access group timeout message  popup for each tab/browser?

If all tabs are linked to same pega-rules cookie within the same browser session, then ALL will be timed out.

Isn’t timeout controlled by IDP for SAML based authentication? If we add timeout in SAML auth servcie, would it prompt user to login again after expiry on Pega application?

Yes SAML attributes can be set for timeout. Validate that the configuration correctly sets the session length on the pega-rules cookie. In that case you can consider using it; however, you are not in control. The conservative approach is to set the session timeout in the access groups to assure your application has a maximum session length.

TOKENS

In case of using Token based authentication externally, how do you validate tokens in Pega? Using OAuth as auth scheme doesnt work. Does it need custom authentication logic to be built?

Pega Token Credenitals Authentication Schema can process a token produced from Pega's token withoutconfiguration. You would select the option "Token issued by Pega Platform". However, if you want to process a third party token, then you will need to select "Token issued by External Identity Provider" In this case you will need to create an Identity Mapping and Token Profile.

Does Pega support SAML 2.0 On-Behalf-Of flows to use inbound access tokens to call down-stream outbound connector calls. Inline with end-to-end authentication where we can pass SAML bearer token for outbound REST calls i.e support end-to-end authentication, to re-use of tokens for outbound connectors. The sequence would be IdP->Pega->Downstream and the main goal is to use the same SSO 'session' for the user.

If you are talking about WS-Security / Soap, then no. You will need to set the requestor SAML assertion yourself when accessing the API. However, since 8.4 you can reference the ACCESS_TOKEN issued via OIDC Auth Service. See https://community.pega.com/knowledgebase/articles/whats-new-pega-platform/configure-authentication-profile-json-web-token-bearer-grant-type-84