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.
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.
“Our requirement is to use a custom authentication mechanism for external DX API requests only.”
If the goal is to integrate to an external Identity provider (your corporate IDP), best approach is to utilize OIDC or SAML for such integration. Is it possible to utilize one of these preferred Authentication Service types, and then use that to execute an authorization code grant flow specifying the authorization_service query arg with the auth service alias. This grant flow could be used to authenticate the user using the external IDP and then obtaining an Infinity issued access_token to use with DX API calls (or with Web Embed).
In addition to these preferred types, there is also the “Custom” authentication service type where you use the WebLDAP1, WebLDAP2 or WebLDAP3 id/alias and the matching PRWebLDAP1, PRWebLDAP2 or PRWebLDAP3 url pattern and pass that alias once again as the authetication_service value.
Web Embed also has a authService attribute where you can specify such an authentication_service and use this with the default grantType value of “authCode”.
Other options to consider is custom bearer grant type which would allow you to have your own custom authentication-like activity be utilized as part of issuing the Infinity access_token as part of issuing this specific pega-specific token endpoint invocation. However, it does not offer direct integration to your external IDP.
Using OIDC would further allow you to use server based Authentication Profiles which can leverage the IDP identity token obtained during authorization code grant flow to make IDP specific additional validation.
