CLSA Community Meetup: Secure your DX API & 8.6 Security update

Find all details including the replay, useful links, download slides, and review the Q&A that came in during both sessions on this support center post.

On July 20 and 21 we hosted our CLSA Community Meetup that featured a deep dive into how to secure DX API flows and an update on the latest security updates that were added in 8.6.

In the first recording you will hear Dion Lammers (Partner Success Technical Lead) talk about the latest changes and additions around security in 8.6, like being able to associate an authentication service to individual applications and the new servlet management landing page.

In the second recording you will hear James Sleightholm (Cloud Architect) talk about securing DX API flows. He starts with a recap on some OAuth prerequisite knowledge and then looks at two specific use cases:

• DX API Authentication in the context of the new 8.6 Cosmos React architecture
• DX API Authentication in the context of a custom Single Page App where for example Angular could be used as client technology.

At the end of each recording there is live Q&A with the questions that were asked along the presentation by the participants. After below's recording there is the Q&A in text. 

What are the best ways to debug Authentication services when we run into issues?

In general, you should build the Auth Service up step by step. First step is to use a preexisting operator that matches the subject set in the assertion. This at least ensures that the correct reply address has been shared with IDP and Pega is validating the signature. When this is working, you can move on to dynamic operator provisioning and mapping claims to the metadate provided by the IDP. If you are still having problems, then you will need to inspect the response assertion. With SAML this can be easy if the SAML assertion is not encrypted. This can be picked up from the SAML response posted to /assertionconsumerservice. This can be base64 decoded and inspected. For OpenID Connect, you will need to increase the logging to debug on com.pega.pegarules.integration.engine.internal.client.oauth2.OAuth2ClientImpl  and look at the token response. Remember we are a private client, so we call /token server side with the authorization code posted to /PRAuth

If the OpenId Provider session gets logged out in another application, how pega get to know that the OpenId Provider session is not valid anmore? I'm aware of the check_session_iframe approach from OpenId spec. But we miss in Pega the session_state parameter so we are not able to implement this approach until now. Do you have any recomenation on that?

If the session_state is set in the JWT, then it could be set on the requestor/operator

Does pega use the kid for key rotation during JWT authentication? 

Pega uses the kid to identify the public key

Are kid and x5t(X.509 Certifiate SHA-1 Thumbprint) the same?

Both kid and x5t can be used to identify a key. The 'kid' is mere an alias and can be a simple name. The x5t provides a more reliable way to identify

Can we able to set the locale to operator based on the region/place user logged into application using SSO auth?

Yes, you could map the locale to the operator instance based on input from the SAML assertion or JWT.

Suppose we need to set an application access based on a combination of claims being returned by the IDP for an OIDC auth service. Would it be possible to do that on the autentication service ruleform itself?

It is possible to use @if({claim} functions on the left side of the mapping tab. However, the recommendation is to create a single page DP of type Data-Admin-Operator-ID and referencing D_pyUserInfoClaims in pages and classes. Use a DT to set .pyAccessGroup and .pyAccessGroupAdditional by processing D_pyUserInfoClaims. This DP can then be referenced on the left side of the mapping tab. See https://community.pega.com/knowledgebase/articles/security/85/mapping-operator-information-openid-connect-sso-authentication-service

Does pega still use the com.nimbusds.jose classes for parsing JWT?               

See https://community.pega.com/support/support-articles/unable-integrate-sso-platform-using-jwt 
Pega considered various JWT libraries during design time. Java JSON Web Token (JJWT) and Nimbus are two popular (based on Maven Artifact usage) JWT libraries. However, JJWT does not support JSON Web Encryption (JWE). Therefore, Pega uses Nimbus for both JWS and JWE.

I am failing to understand how Pega can differentiate between privalte and public client? As in either way the request is coming from browser only.

When a token is requested from Pega’s /token with a clientid, Pega will look up the client registration rule and know if the registration is public or private. If public (angular app), Pega will only issue an access token. If private (cosmos react), Pega will issue access token and refresh token.

Does this kind of creating authentictaion service from app studio adds servlets in web.xml automaticaly?

A new Servlet Management API is available in newer versions of Tomcat that Pega Cloud uses. Pega uses this API to read the servlets from web.xml when Pega first starts, and then stores the results in Pega's database and all subsequent startups are driven from what's in the database

With new servlet mapping, can we remap the urls for existing servlets...like prweb/sso to prweb/PRAuth for sso servlet?

Everything you can do in web.xml you can do in the new landing page.

If we have multiple nodes then updating this would affect all the nodes?

Yes as the Servlet Management records are stored in the database shared by all nodes of the cluster

When one of the applications is defaulted to use OIDC, will user be asked to login every time that application is switched to or is this maintained in session?

That depends; if the user switches to or from applications that use the same authentication service then no re-logins are required. the session cookie is maintained. only when you switch to an application that uses a different auth service

Is it possible to have condition-based authentication option based on some condition like access group?

No, there is not possible OOTB. if you want to distinct based on access group its best to provide specific URLs with the application alias and the required auth serv to the specific users of an access group

Does ABAC policy work for all data bases (Oracle, DB2, Postgres etc)?

Yes, ABAC policies are actually being translated in the sql. So ABAC policies work on all databases that Pega supports.

Does the DB need indexing based on the ABAC policy conditions since every query effectively will have more conditions in the where clause?

ABAC can have impact on the performance of the queries. In policies you have to be smart about what conditions you add; dont add n to n relations for example.

Here you can find an overview of all the past CLSA Community webinars.