Custom Authentication for the Constellation DX API

We are using multiple Constellation applications and would like to expose the Constellation DX API for external consumers to perform CRUD operations on work objects. For example, an external app might need to retrieve the case status, update a field, or run an action. We do not intend to run Pega headless or use external portals. We may want to use Web Embeds at some point.

Our requirement is to use a custom authentication mechanism for external DX API requests only. We don’t want to change the authentication behavior of the Constellation app itself. End users should continue to have access and use Constellation UI and portals as they do today.

Is it supported to configure a separate authentication mechanism for external requests only without affecting the way Constellation UI works? Changing authentication on the application service package level probably isn’t a good idea. We could create a new service package, but then we’d have to copy all associated REST service rules, which again - is bad design.

In theory, we could build what we need using an Authentication Service, but I have no idea how to use this service specifically just for external DX API requests.

Has anyone implemented this architecture and has some guidance for us? Thanks!

We’ve created a new OAuth 2.0 rule for external DX API requests. We have provided the client id and secret with a new acccess group with limited access. This will enable us to use something different Authentication without impacting the portal users.

Thank you Ramesh - I assume you are referring to an OAuth 2.0 Client Registration rule, correct? If yes, this rule already uses OAuth 2.0 as the default authentication type and only allows you to indicate one or more grant types (e.g. JWT, Client Credentials). It won’t allow you to customize or validate the token itself - let’s say you want to run a custom activity to validate a JWT against our corporate IDP.