Discussion

Authenticating to Pega with miniOrange using OIDC protocol

This article describes how to configure Pega to authenticate users against miniOrange using OpenID Connect protocol. From the protocol perspective, in this setup Pega Platform acts as the OpenID Client and miniOrange acts as OpenID Identity Provider.

The solution has been tested with Pega Platform 8.1.1 and miniOrange in Cloud trial version.

Step One: Create Authentication Service in Pega

In the Dev Studio of your Pega instance click Configure > Org & Security > Authentication > Create Authentication Service. Choose “OpenID Connect” as the type, fill in other fields and click “Create and open”.

On the next screen, type-in the service alias (1) and note the value of the "Redirect URI" field (2). You will need this URI in the next step.

Step Two: Create miniOrange application

Login to miniOrange console and create a new application of "OpenID Connect" type.

Specify the Client name (Pega) and the Redirect URI. This must match the "Redirect URI" field from Pega authentication service (the one you noted in the previous step)

Finally associate an authentication policy with your application. For the purpose of this article we created a new policy named "Simple Password Policy" and associated it with the DEFAULT user group and the Pega application.

Step Three: Reconcile configuration of miniOrange and Pega

In this step you need to copy configuration of miniOrange application to the Pega authentication service. At the moment miniOrange does not provide discovery endpoints for applications, so you cannot use "Import Metadata" feature to automatically configure the authentication service. Instead you need to manually copy the following values:

  • Authorization Endpoint (3)
  • Token Endpoint (4)
  • User Info Endpoint (5)
  • Client Id and Client Secret (6)

The values need to be entered into the corresponding fields of the authentication service:

Additionally you need to specify the name of OAuth claim that will be used to map users authenticated in miniOrange to Pega operators. The claim name must be specified in curly braces. Typically email is used for that purpose.

Step Four: Import public key for validating tokens

OpenID Connect specification requires the Client (Pega in our case) to verify the signature of each ID token received from Identity Provider. In order to do so, Pega must know this provider's public key, therefore the keystore with this key must be included in the authentication service configuration.

miniOrange provides application-specific public key in the PAM format. You can download it from the link marked "Certificate" on the list of applications in your miniOrange console.

After downloading the key, you need to add it to a keystore in a format supported by Pega. For the purpose of this article we will use JSON Web Key Set (JWKS) format for the keystore. There are two options to create a JWKS keystore from a PEM key. You can do it using either a command-line tool, or an online tool and text-editor.

Option 1: Command line tool

The simplest way is to use node-jose-tools toolkit. It is a front-end to node-jose library, which is an implementation of JSON Object Signing and Encryption (JOSE) specification. After installing the toolkit, run the following command:

jose addkey --create --beauty RSA256_OpenID_public_key.pem > moas-openid.jwk

where RSA256_OpenID_public_key.pem is the "Certificate" you downloaded from miniOrange.

Option 2: Online tool

You can use JWK to PEM Convertor online to convert the key from PAM to JWK format. To do so choose "PEM-to-JWK" option, paste the key in PAM format and click submit. You will get a JWK key, which you now need to add to a JWKS keystore.

To do so, simply create a text file with the following contents:

  1. {
  2. "keys":[ ]
  3. }

Then paste they JWK key between [ and ] characters and save the file as moas-openid.jwk.

Regardless of which option you chose, you should now have a JWKS keystore in moas-openid.jwk file, which should look like this:

  1. {
  2. "keys": [
  3. {
  4. "kty": "RSA",
  5. "e": "AQAB",
  6. "kid": "CsVfry3eToUyZdOA",
  7. "n": "zIKQ...oAow"
  8. }
  9. ]
  10. }

As you can see there is one element in the keys array, which corresponds to the public key from miniOrange. This key is described by four properties. Three of them came from the PEM file. These are the key type ("kty"), exponent ("e") and modulus ("n"). The fourth one, that is the unique identifier of the key ("kid"), was not originally present in the PEM file and was randomly generated during conversion from PEM to JWK format.

However, each ID token specifies the unique identifier of the key that should be used to verify its signature. In case of ID token issued by miniOrange, this identifier is always equal to "1". Therefore you need to modify, with a text editor, the kid of miniOrange key in your keystore to be equal "1", to match the kid which comes with minOrange tokens. So the final keystore in moas-openid.jwk file should look like this:

  1. {
  2. "keys": [
  3. {
  4. "kty": "RSA",
  5. "e": "AQAB",
  6. "kid": "1",
  7. "n": "zIKQ...oAow"
  8. }
  9. ]
  10. }

Now you need to import they keystore to Pega. In the DevStudio click Create > Security > Keystore, fill in the fields, and click "Create and open".

On the next screen choose "Upload file" as the keystore location, JWK as the keystore type, upload your moas-openid.jwk file and save the keystore.

Go back to the authentication service configuration and fill-in the "ID token processing" section. Specify https://auth.miniorange.com as the "Issuer" and your newly created keystore as the "Signature truststore".

Save the authentication service.

Step Five: Test the authentication experience

Now you need to create a test user in miniOrange and a corresponding operator in Pega. If you chose email as the basis of mapping users to operators, then the email of miniOrange user must match the name of operator in Pega. Additionally make sure that the operator in Pega has "Use external authentication" option checked.

Start a new incognito window of your web browser (to make sure you are not logged in) and go to the URL specified in the authentication service as "Login URL". You will get redirected to miniOrange for authentication. Enter username and password of the test user. Upon successful authentication, you will be redirected to Pega logged in as the operator corresponding to the test user.

Comments

Keep up to date on this post and subscribe to comments

February 5, 2019 - 8:04am

Thanks for the article.

Having some issue when trying this, Changed the keystore file extension from jwks to jwk and the issue got resolved.

 

Thanks

Saikat

Pega
February 5, 2019 - 8:30am
Response to Saikatc8

Hi Saikat,

Thank you for pointing this out. I will update the article to use "jwk" extension.

Jarek

February 8, 2019 - 12:38pm

HI Jarek,

Its good article.Can you please also mention do we check anything on the web.xml entry?

Regards,

Anandh

Pega
February 8, 2019 - 1:14pm
Response to Anandh Palanisamy

Hi Anandh,

I'm not sure if I understood your question correctly - what do you mean by "the web.xml entry"?

February 8, 2019 - 1:34pm
Response to Jarek.Cora

Hi Jarek,

Do we need to change anything on the <servlet-name> tag, we have the below entry on the web.xml. Do we need to change/update anything.

<servlet>

<servlet-name>PRAuth</servlet-name>

<display-name>PRAuth</display-name>

<description>PRAuth</description>

<servlet-class>com.pega.pegarules.internal.web.servlet.WebStandardBoot</servlet-class>

<init-param>

<param-name>PegaEtierClass</param-name>

<!-- COMPONENTS: This was previously com.pega.pegarules.services.HttpAPI -->

<param-value>com.pega.pegarules.session.internal.engineinterface.service.HttpAPI</param-value>

</init-param>

<init-param>

<param-name>AuthenticationType</param-name>

<param-value>PegaAuthentication</param-value>

</init-param>

<init-param>

<param-name>StatusPage</param-name>

<param-value>/diagnostic/status.jsp</param-value>

</init-param>

<init-param>

<param-name>RuntimeServletName</param-name>

<param-value>PRAuth</param-value>

</init-param>

<init-param>

<param-name>SecureServletName</param-name>

<param-value>PRAuth</param-value>

</init-param>

</servlet>

 

Regards,

Anandh

 

Pega
February 8, 2019 - 2:13pm
Response to Anandh Palanisamy

Hi Anandh,

No, you don't need to change anything in web.xml of your Pega server. The only thing that is required is that your server is accessible via HTTPS, not just HTTP. Also keep in mind that I tested this functionality with Pega 8.x (aka Pega Infinity). Earlier versions, such as Pega 7.x,  may require additional, manual configuration.

February 8, 2019 - 3:03pm
Response to Jarek.Cora

Thanks Jarek, we are trying in 7.4 and its not redirecting into the "Authorization endpoint" which i mention on the rule.

Windows authentication its not happening, can i enable any logger to troubleshoot?

Regards,

Anandh

Pega
February 12, 2019 - 5:05am
Response to Anandh Palanisamy

Hi Anandh,

In Pega 7.4.1, I set logging level to ALL for "com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler " and I can see the following entry in the log file:

(sso.oidc.OIDCClientHandler) DEBUG  - Constructed authorization URL for OIDC provider : https://....

It contains the URL to the external Identity Provider configured for my authentication service.  Please enable the above logger to see if the URL is the one you expect.  Also please make sure you start the whole login by going to the Login URL specified by your Authentication Service, not to any other servlet or login page provided by Pega.

February 12, 2019 - 10:52pm
Response to Jarek.Cora

Hi Jarek,

We have 7.4 system, will this work on this version also we have RS256 algorithm on the metedata. Will Pega support those algorithm? 

Regards,

Anandh

Pega
February 13, 2019 - 4:57am
Response to Anandh Palanisamy

Hi Anandh,

I haven't tried it on 7.4 personally,  but I believe it will work because full support for OpenID Connect was introduced in 7.4. Yes, Pega supports JWT tokens signed with RS256 algorithm.

Jarek

February 10, 2019 - 9:06am

Hi @Jarek

Would this work with Pega 7.4? Specifically, with Pega 7.4 on Openshift? Is there a way to troubleshoot this configuration when the Login URL does not redirect to the IDP for authentication?

Balaji

Pega
February 12, 2019 - 4:05am
Response to BalajiR1491

Hi Balaji,

I tried OIDC configuration with Pega 7.4.1 (Build: PRPC-7.4.1-281). It worked correctly, in particular redirection to the Identity Provider login page happened as expected. I guess it's obvious, but make sure that you start the whole login process by going to the Login URL specified in your Authentication Service, which has the form:  https://YOUR_HOST/prweb/PRAuth/SERVICE_ALIAS  This should redirect the browser to the external Identity Provider login page. If this doesn't happen I would suggest trying to make this request with a tool which allows to trace HTTP requests and responses, such as Postman or wget. 

February 21, 2019 - 11:00am

Hi Jarek,

We are getting the below error when we try to login,

2019-02-21 15:53:37,117 [http-apr-8080-exec-3] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Initiating OIDC flow  
2019-02-21 15:53:37,117 [http-apr-8080-exec-3] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructing authorization URL for OIDC provider  
2019-02-21 15:53:37,122 [http-apr-8080-exec-3] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructed authorization URL for OIDC provider : https://corpqa.sts.ford.com/adfs/oauth2/authorize/?redirect_uri=https%3A%2F%2Fgesbdocker-gesb-pega-dev.app.caas.ford.com%3A443%2Fprweb%2FPRAuth&client_id=urn:gesbpega:oc:native:dev&scope=openid &state=62555e3133046ef5b685d3ca5c1d2446cd099362fb60ac8fdf43a69caef8e3f1&nonce=afe4a3c102dfc7b0d0a254ee03966c3be57f92fa0afd20c55d6b5b75d13295ba&response_type=code 
2019-02-21 15:58:55,381 [http-apr-8080-exec-4] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Initiating OIDC flow  
2019-02-21 15:58:55,381 [http-apr-8080-exec-4] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructing authorization URL for OIDC provider  
2019-02-21 15:58:55,387 [http-apr-8080-exec-4] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructed authorization URL for OIDC provider : https://corpqa.sts.ford.com/adfs/oauth2/authorize/?redirect_uri=https%3A%2F%2Fgesbdocker-gesb-pega-dev.app.caas.ford.com%3A443%2Fprweb%2FPRAuth&client_id=urn:gesbpega:oc:native:dev&scope=openid &state=58f5ecf9cbc1585df917b2e97852bc8c9bc0018044c87501c4b0cc556249f754&nonce=ac3125acb7b8e36a1e7fdb8efc1f33e6a608307a263ba827c00a09c899454c17&response_type=code 
2019-02-21 15:58:59,179 [http-apr-8080-exec-1] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Processing authcode recieved from OIDC provider  
2019-02-21 15:58:59,181 [http-apr-8080-exec-1] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Fetching access token using authCode received  
2019-02-21 15:58:59,325 [http-apr-8080-exec-1] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (ngineinterface.service.HttpAPI) ERROR gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - phy010047.caas.ford.com: com.pega.pegarules.pub.PRRuntimeException 
com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Access token endpoint invocation failed : Response status : 400  Bad Request 
	at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:736) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.mgmt.authentication.Authentication.doAuthentication(Authentication.java:535) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.service.HTTPAuthenticationHandler.performAuthentication(HTTPAuthenticationHandler.java:250) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.service.HTTPAuthenticationHandler.doHttpReqAuthentication(HTTPAuthenticationHandler.java:94) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.handleAuthentication(HttpAPI.java:2327) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:576) ~[prenginext.jar:?] 
	at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:415) ~[prenginext.jar:?] 
	at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source) ~[?:?] 
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162] 
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162] 
	at com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1368) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1105) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:959) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:354) ~[prenginext.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:855) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:331) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:274) ~[prprivate.jar:?] 
	at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:251) ~[prprivate.jar:?] 
	at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278) ~[prpublic.jar:?] 
	at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223) ~[prpublic.jar:?] 
	at com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:691) ~[prwebj2ee.jar:?] 
	at com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:397) ~[prwebj2ee.jar:?] 
	at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) ~[?:?] 
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_162] 
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162] 
	at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:370) ~[prbootstrap-7.3.1-218.jar:7.3.1-218] 
	at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:411) ~[prbootstrap-7.3.1-218.jar:7.3.1-218] 
	at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:224) ~[prbootstrap-api-7.3.1-218.jar:7.3.1-218] 
	at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:273) ~[prbootstrap-api-7.3.1-218.jar:7.3.1-218] 
	at com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:129) ~[prbootstrap-api-7.3.1-218.jar:7.3.1-218] 
	at com.pega.pegarules.internal.web.servlet.WebStandardBoot.doGet(WebStandardBoot.java:100) ~[prbootstrap-api-7.3.1-218.jar:7.3.1-218] 
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) ~[servlet-api.jar:?] 
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) ~[servlet-api.jar:?] 
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) ~[catalina.jar:7.0.86] 
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) ~[tomcat7-websocket.jar:7.0.86] 
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:1025) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) ~[catalina.jar:7.0.86] 
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) ~[catalina.jar:7.0.86] 
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115) ~[tomcat-coyote.jar:7.0.86] 
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) ~[tomcat-coyote.jar:7.0.86] 
	at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2555) ~[tomcat-coyote.jar:7.0.86] 
	at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2544) ~[tomcat-coyote.jar:7.0.86] 
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162] 
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162] 
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-coyote.jar:7.0.86] 
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162] 
Caused by: com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Access token endpoint invocation failed : Response status : 400  Bad Request 
	at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.processAuthcodeRes(OIDCClientHandler.java:150) ~[printegrint.jar:?] 
	at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.authenticate(OIDCClientHandler.java:74) ~[printegrint.jar:?] 
	at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:719) ~[prprivate.jar:?] 
	... 53 more 
Caused by: com.pega.pegarules.pub.PRRuntimeException: Access token endpoint invocation failed : Response status : 400  Bad Request 
	at com.pega.pegarules.integration.engine.internal.client.oauth2.OAuth2ClientImpl.getTokensFromEndpoint(OAuth2ClientImpl.java:650) ~[printegrint.jar:?] 
	at com.pega.pegarules.integration.engine.internal.client.oauth2.OAuth2ClientImpl.getTokensFromEndpoint(OAuth2ClientImpl.java:553) ~[printegrint.jar:?] 
	at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.processAuthcodeRes(OIDCClientHandler.java:132) ~[printegrint.jar:?] 
	at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.authenticate(OIDCClientHandler.java:74) ~[printegrint.jar:?] 
	at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:719) ~[prprivate.jar:?] 
	... 53 more 

 

Regards,

Anandh

Pega
February 22, 2019 - 6:06am
Response to Anandh Palanisamy

Hi Anandh,

First of all let me say that you did a great job configuring loggers and finding relevant information in the logs files. The information you provided exactly pinpoints the failure. The log file shows that the redirection to login page happened successfully, login to Identity Provider (ADFS) was also successful, and Pega received authorization code confirming that the user signed in. That's indicated by the following entry in the log

"Processing authcode recieved from OIDC provider"

Now Pega needs to exchange the authcode for access token. This happens by a direct communication between Pega server and Identity provider (ADFS) server, w/o out any involvement from the end-user so it's not visible for the user. Pega server makes a request to ADFS, as indicates by this entry:

"Fetching access token using authCode received"

In the next step, the failure occurs. The Identity Provider (ADFS), instead of responding with access token, fails to understand the request and returns "HTTP 400  bad request". This is in the log file here:

"Access token endpoint invocation failed : Response status : 400  Bad Request"

To troubleshoot further, the first think to check would be the value of  "Token endpoint" field in you Pega authentication service configuration. My guess it should be :

https://corpqa.sts.ford.com/adfs/oauth2/token

If this end point seems right, I would look in your ADFS logs. It responds with "HTTP 400 bad request" so there is a chance it logged what was the problem with the request. 

 

February 22, 2019 - 3:13pm
Response to Jarek.Cora

Hi Jarek,

Thanks, we have tested with Postman on the ADFS token its getting generate. When i check the JWT keystore, its showing as "d_token_signing_alg_values_supported":["HS256"]".

Do you think its support by Pega?

Regards,

Anandh

Pega
February 25, 2019 - 5:28am
Response to Anandh Palanisamy

Hi Anandh,

I couldn't find information regarding Pega support for validation of JWT tokens signed with HS256. This method requires a secret shared between Pega and IdentityProvider so it would be a bit more complicated to configure than RS256.

However, I believe the lack of support for HS256 is not what is causing the exception in your logs, because this exception happens before the token is even received Pega. If you look at the logs from a successful OIDC flow here,  you can see that failure you experience corresponds to step 5, that is "Fetching access token using authCode received".  If it was a problem with verifying signature, this would occur later, in step 7, that is "Validating ID token...". 

Going back to the exception in your logs, the fact that you were able to receive token via Postman but not from Pega suggests, that there is something different about the request made by Pega.

My advise would be to configure logger for "OAuth2ClientImpl" in Pega. This should print out "Invoking access token endpoint" followed by the exact request from Pega to ADFS. Compare it to the request printed out in the Postman console. If there is a difference, this may be the culprit.

February 25, 2019 - 1:26pm

Thanks Jarek for the debug. After enable i see the below logs and error.

 

2019-02-25 18:15:14,616 [http-apr-8080-exec-9] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Initiating OIDC flow  

2019-02-25 18:15:14,616 [http-apr-8080-exec-9] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructing authorization URL for OIDC provider  

2019-02-25 18:15:14,623 [http-apr-8080-exec-9] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Constructed authorization URL for OIDC provider : https://corpqa.sts.ford.com/adfs/oauth2/authorize?redirect_uri=https%3A%2F%2Fgesbdocker-gesb-pega-dev.app.caas.ford.com%3A443%2Fprweb%2FPRAuth&client_id=urn:gesbpega:oc:native:dev&scope=openid &state=65e6d66e731ecda81661c574cc2701f869e20406845bdb2ed9c934e834a4345e&nonce=b182f9b0cf36eaaf7ce6c47d76b0f91a87726c7e7f030fea2de9e4a1e79a47a1&response_type=code 

2019-02-25 18:15:24,875 [http-apr-8080-exec-7] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Processing authcode recieved from OIDC provider  

2019-02-25 18:15:24,877 [http-apr-8080-exec-7] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Fetching access token using authCode received  

2019-02-25 18:15:24,877 [http-apr-8080-exec-7] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Invoking access token endpoint: 

 URL = https://corpqa.sts.ford.com/adfs/oauth2/token 

 Request data = "some data"

2019-02-25 18:15:25,015 [http-apr-8080-exec-7] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  - Token endpoint invocation results: 

Status code = 400 

Status text = Bad Request 

Content type = application/json;charset=UTF-8 

Content size = 182 

 

2019-02-25 18:15:25,015 [http-apr-8080-exec-7] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG gesbdocker-gesb-pega-dev.app.caas.ford.com|phy010047.caas.ford.com  -  

 Response received : {"error":"invalid_client","error_description":"MSIS9623: Received invalid Client credentials. The OAuth client is not configured to authenticate using passed in client credentials."} 

February 25, 2019 - 1:35pm
Response to Anandh Palanisamy

@Jarek.Cora

Is it possible to make the client_secret field not mandatory when creating the authentication service? With ADFS 4.0, there is an option to configure a client to authenticate without a client_secret. 

See this link (https://stackoverflow.com/questions/44797903/adfs-4-0-received-invalid-client-credentials)

 

Pega
February 26, 2019 - 9:28am
Response to BalajiR1491

At the moment OIDC Authentication Service in Pega always sends client secret and there is no way to disable it.  At the moment you have two options:

  1. Configure ADFS such that it accepts client secret (I don't know if it's possible)
    or
  2. File a Support Request with Pega asking for an enhancement to Authentication Service, namely to support so called 'public client' mode in which client (Pega in this case) uses PKCE (Proof Key for Code Exchange) instead of sending client secret to Identity Provider

I strongly discourage you from using the idea mentioned in the StackOverflow post you linked, that is intercepting a request and removing client secret, because this would introduce a potential security vulnerability. Client secret is an important security feature and cannot be just removed, it must be replaced with other mechanism, such as PKCE (Proof Key for Code Exchange) I mentioned above.

 

February 26, 2019 - 10:07am
Response to Jarek.Cora

@Jarek.Cora

Thanks for the reply. I referenced the stackoverflow link just to show that there are ADFS v4 implementations that only expect the clients to send in the client_id alone. I did not mean to alter the request to be sent to ADFS token service. Will file a feature request to Pega.

Thanks!

Balaji

Pega
February 26, 2019 - 2:54pm
Response to BalajiR1491

Hello Balaji,

I understand you were not even considering using the workaround mentioned on stackoverflow, I just wanted to make it clear for others reading this discussion in future that what was suggested on stackoverflow was not the best idea. 

Also I need to say you guys did excellent job troubleshooting the problem and you found the exact root cause of the failure.  Thank you.

March 21, 2019 - 3:46pm
Response to Jarek.Cora

@Jarek.Cora

I installed Pega 8.1.0 and configured the authentication service to authenticate against the IDP. I configured the entry in IDP to authenticate with the client_id and client_secret. When I invoke postman client, it is able to successfully generate an access token and I can validate it with jwt.io. However, when I try to hit the login URL configured in the authentication service, I get the following error in the logs.

2019-03-21 19:21:06,042 [ttp-apr-8080-exec-10] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Initiating OIDC flow 

2019-03-21 19:21:06,042 [ttp-apr-8080-exec-10] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Constructing authorization URL for OIDC provider 

2019-03-21 19:21:06,047 [ttp-apr-8080-exec-10] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Constructed authorization URL for OIDC provider : https://xxxx.xxxx.com/adfs/oauth2/authorize/?redirect_uri=https%3A%2F%2Fxxxx.xxxx.com%2Fprweb%2FPRAuth&client_id=yyyy&scope=openid &state=zzzz&nonce=wwww&response_type=code

2019-03-21 19:21:09,899 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Processing authorization code recieved from OIDC provider 

2019-03-21 19:21:09,901 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Fetching access token using authCode received 

2019-03-21 19:21:09,902 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Invoking access token endpoint:

 URL = https://xxxx.xxxx.com/adfs/oauth2/token/

 Request data = client_id=yyyy&client_secret=uuuu&grant_type=authorization_code&code=vvvv&redirect_uri=https%3A%2F%2Fxxxx.xxxx.com%2Fprweb%2FPRAuth&resource=tttt&response_mode=form_post

2019-03-21 19:21:09,923 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Token endpoint invocation results:

Status code = 200

Status text = OK

Content type = application/json;charset=UTF-8

Content size = 4735

 

2019-03-21 19:21:09,924 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Response details: 

access_token = *********

refresh_token_expires_in = 28799

refresh_token = *********

resource = urn:microsoft:userinfo

scope = openid

id_token = aaaa

token_type = bearer

expires_in = 3600

 

2019-03-21 19:21:09,924 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (client.oauth2.OAuth2ClientImpl) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Creating access token page for Client ID = yyyy

2019-03-21 19:21:09,924 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Successfully fetched accesss token and ID token using authCode 

2019-03-21 19:21:09,925 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Validating ID token received from access token end point aaaa

2019-03-21 19:21:09,925 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Succesfully validated ID token with standard claims 

2019-03-21 19:21:09,925 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Retrieving userInfo claims from user info Endpoint 

2019-03-21 19:21:09,933 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (    sso.oidc.OIDCClientHandler) DEBUG xxxx.xxxx.com|phy010048.dddd.com  - Fetch operator from claim {upn} from received ID token claims

2019-03-21 19:21:09,933 [http-apr-8080-exec-5] [  STANDARD] [                    ] [ESBSecurity:01.01.01] (ngineinterface.service.HttpAPI) ERROR xxxx.xxxx.com|phy010048.dddd.com  - phy010048.dddd.com: com.pega.pegarules.pub.PRRuntimeException

com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Unable to derive claim "upn" from id token for operator establishment

at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:739) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.mgmt.authentication.Authentication.doAuthentication(Authentication.java:491) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.service.HTTPAuthenticationHandler.performAuthentication(HTTPAuthenticationHandler.java:251) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.service.HTTPAuthenticationHandler.doHttpReqAuthentication(HTTPAuthenticationHandler.java:94) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.handleAuthentication(HttpAPI.java:2551) ~[prprivate.jar:?]

at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:594) ~[prenginext.jar:?]

at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:433) ~[prenginext.jar:?]

at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source) ~[?:?]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]

at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]

at com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1377) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1109) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:963) ~[prprivate.jar:?]

at com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:361) ~[prenginext.jar:?]

at com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:882) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:331) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:274) ~[prprivate.jar:?]

at com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:251) ~[prprivate.jar:?]

at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:275) ~[prpublic.jar:?]

at com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:220) ~[prpublic.jar:?]

at com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:712) ~[prwebj2ee.jar:?]

at com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:398) ~[prwebj2ee.jar:?]

at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source) ~[?:?]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_171]

at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_171]

at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:370) ~[prbootstrap-8.1.0-175.jar:8.1.0-175]

at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:411) ~[prbootstrap-8.1.0-175.jar:8.1.0-175]

at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:224) ~[prbootstrap-api-8.1.0-175.jar:8.1.0-175]

at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:273) ~[prbootstrap-api-8.1.0-175.jar:8.1.0-175]

at com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:129) ~[prbootstrap-api-8.1.0-175.jar:8.1.0-175]

at com.pega.pegarules.internal.web.servlet.WebStandardBoot.doGet(WebStandardBoot.java:100) ~[prbootstrap-api-8.1.0-175.jar:8.1.0-175]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) ~[servlet-api.jar:?]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) ~[servlet-api.jar:?]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) ~[catalina.jar:7.0.88]

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) ~[tomcat7-websocket.jar:7.0.88]

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110) ~[catalina.jar:7.0.88]

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) ~[catalina.jar:7.0.88]

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) ~[catalina.jar:7.0.88]

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:1025) ~[catalina.jar:7.0.88]

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) ~[catalina.jar:7.0.88]

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) ~[catalina.jar:7.0.88]

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1139) ~[tomcat-coyote.jar:7.0.88]

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) ~[tomcat-coyote.jar:7.0.88]

at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2555) ~[tomcat-coyote.jar:7.0.88]

at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2544) ~[tomcat-coyote.jar:7.0.88]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_171]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_171]

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-coyote.jar:7.0.88]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]

Caused by: com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Unable to derive claim "upn" from id token for operator establishment

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.processAuthcodeRes(OIDCClientHandler.java:131) ~[printegrint.jar:?]

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.authenticate(OIDCClientHandler.java:73) ~[printegrint.jar:?]

at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:722) ~[prprivate.jar:?]

... 53 more

Caused by: com.pega.pegarules.pub.PRRuntimeException: Unable to derive claim "upn" from id token for operator establishment

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.resolveSourceValue(OIDCClientHandler.java:231) ~[printegrint.jar:?]

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.establishOperatorFromIDToken(OIDCClientHandler.java:171) ~[printegrint.jar:?]

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.processAuthcodeRes(OIDCClientHandler.java:119) ~[printegrint.jar:?]

at com.pega.pegarules.integration.engine.internal.sso.oidc.OIDCClientHandler.authenticate(OIDCClientHandler.java:73) ~[printegrint.jar:?]

at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRAuth.authenticateOperator(SchemePRAuth.java:722) ~[prprivate.jar:?]

... 53 more

 

However, the access token verified on the jwt.io page shows the upn attribute in the claim with my correct email id. Can you help me troubleshoot the issue?

Thanks for your help!

Balaji

Pega
March 22, 2019 - 7:11am
Response to BalajiR1491

Hello Balaji,

I see in the log files that Pega is requesting only one scope, that is "openid".  It's possible, that the "upn" claim is not included in "openid" scope. Could you please compare the value of Scope field from you Potsman request with the value of the Scope field in the Authentication Service (it's in the "Client Information" section). Are they the same?

March 22, 2019 - 11:27am
Response to Jarek.Cora

@Jarek.Cora

Thanks for the reply. Postman request has the scope defined as openid. The same scope is defined in the Pega Authentication service as well. Any idea why the postman request is working while pega is failing?

Balaji

Pega
March 26, 2019 - 3:45am
Response to BalajiR1491

Hi Balaji

I know you already mentioned you checked the token with jwt.io, but I don't know if you tried the one from Postman or the one from Pega.  In the log you posted, there is a line "Validating ID token received from access token end point"  followed by the actual token. Paste this token from the log file into jwt.io to check if the "upn" claim is there.

March 26, 2019 - 8:15am
Response to Jarek.Cora

@Jarek.Cora

I tried pasting the token received in Pega and Postman to jwt.io page and they both contain the "upn" claim. The tokens have been signed using RS-256 algorithm. Thanks!

Balaji

Pega
March 26, 2019 - 8:27am
Response to BalajiR1491

In this case I'm really why Pega cannot resolve the UPN claim. I looked into the actual code, and the only place where "Unable to derive claim "xxx" from id token for operator establishment" is when the claim is null or is not a string. I believe the fastest option for you will be to report an Support Request with Pega, so someone investigates your particular case.

March 26, 2019 - 8:41am
Response to Jarek.Cora

@Jarek.Cora

Yes, We have opened a service request with Pega to investigate the issue. Thanks for your help!

Balaji

Pega
March 27, 2019 - 5:44am
Response to BalajiR1491

No problem, I'm sorry I wasn't able to actually help you resolve the problem.  

One more thing you may want to double check is that the claim in the authentication service configuration is entered w/o any quotation marks, just with curly braces:  {upn}  However, I presume that's exactly how you entered it.

March 25, 2019 - 7:48pm
Response to Jarek.Cora

@Jarek.Cora

Is it possible to enable pega to list the claims it is able to see in the token received from the IDP? That way, we can triage the issue better. Are there any other additional log levels that can be set to enable this?

Thanks!

Balaji

Pega
March 29, 2019 - 6:29am
Response to BalajiR1491

I haven't found a way to list the claims that Pega can 'see' in the token. There is only possibility of logging the whole token.  

 

July 9, 2019 - 9:08am

@Jarek.Cora

do you have any article on Authenticating to Pega  with Gmail using Open ID Connect 

I have configured it my local machine, Personal Edition by obtaining Client ID and Secret Key from google Credentials page , it is working fine but only for one gmail ID , how to make to work for any gmail ID. 

 

Thanks in advance

Pega
July 15, 2019 - 2:39am
Response to ShivaRamBhupathi

Hi, 

Check the following instruction: (attached) (Authentication Service part: slides 7-11).

Do you have operator mapping set properly (slide 11). You need to set mapping in Authentication service and create model operator.

Hope it helps

***Moderator Edit-Vidyaranjan: Removed Box url and updated content***

 

July 17, 2019 - 8:22am
Response to kawea

Thanks it is working fine now, followed your document :)