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
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:
{
"keys":[ ]
}
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:
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"kid": "CsVfry3eToUyZdOA",
"n": "zIKQ...oAow"
}
]
}
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:
{
"keys": [
{
"kty": "RSA",
"e": "AQAB",
"kid": "1",
"n": "zIKQ...oAow"
}
]
}
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.
Capgemini
IN
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
Ford Motor Company
US
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>
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>
Pegasystems Inc.
PL
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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
Hi Jarek,
We are getting the below error when we try to login,
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
Pegasystems Inc.
PL
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
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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
Thanks Jarek for the debug. After enable i see the below logs and error.
Thanks Jarek for the debug. After enable i see the below logs and error.
Ford Motor Company
US
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)
Pegasystems Inc.
PL
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:
- Configure ADFS such that it accepts client secret (I don't know if it's possible)
or - 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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
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.
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.
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
Pegasystems Inc.
PL
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?
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Ford Motor Company
US
Yes, We have opened a service request with Pega to investigate the issue. Thanks for your help!
Balaji
Pegasystems Inc.
PL
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.
Ford Motor Company
US
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
Pegasystems Inc.
PL
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.
Daimler Truck Holding AG
BR
Were you able to solve this problem with {upn}?
I'm having the same problem here.
Pegasystems Inc.
IN
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
Updated: 12 Sep 2019 5:33 EDT
Pegasystems Inc.
PL
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***
Atomazing - BLOCKED! DO NOT Activate
KZ
Hi,
We are trying to configure pega authentication via oidc auth service, but we getting the following error:com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Received invalid status code 401
I think it might occur because of 16:56:35.766 [http-nio-8080-exec-7] WARN org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication scheme Bearer not supported
logs here:
Hi,
We are trying to configure pega authentication via oidc auth service, but we getting the following error:com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Received invalid status code 401
I think it might occur because of 16:56:35.766 [http-nio-8080-exec-7] WARN org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication scheme Bearer not supported
logs here:
2019-12-26 16:56:35,678 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (mt.authentication.SchemePRAuth) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Auth service alias set : sso1
2019-12-26 16:56:35,678 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (mt.authentication.SchemePRAuth) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Auth service type set : sso1
2019-12-26 16:56:35,679 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (mt.authentication.SchemePRAuth) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Unable to fetch authservice instance to login.
2019-12-26 16:56:35,681 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Processing authorization code recieved from OIDC provider
2019-12-26 16:56:35,681 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - StateParam Validation is successful
2019-12-26 16:56:35,689 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Fetching access token using authCode received
2019-12-26 16:56:35,689 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (client.oauth2.OAuth2ClientImpl) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Invoking access token endpoint:
URL = https://ad-dev.ad-dev.orange-ftgroup.ru/adfs/oauth2/token/
Request data = client_id=SOMEID&client_secret=SomeSecrect&grant_type=authorization_code&code=SOMECODE&redirect_uri=http%3A%2F%2Fvm-pega-at.orange-ftgroup.ru%3A8080%2Fprweb%2FPRAuth
2019-12-26 16:56:35,739 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (client.oauth2.OAuth2ClientImpl) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Token endpoint invocation results:
Status code = 200
Status text = OK
Content type = application/json;charset=UTF-8
Content size = 5542
2019-12-26 16:56:35,741 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (client.oauth2.OAuth2ClientImpl) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Response details:
access_token = *********
refresh_token_expires_in = 28799
refresh_token = *********
resource = SOMEID
scope = openid
id_token = HERE GOES TOKEN
token_type = bearer
expires_in = 3600
2019-12-26 16:56:35,741 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (client.oauth2.OAuth2ClientImpl) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Creating access token page for Client ID = 70c9c8b5-7910-417e-92c4-b32ea8222fd5
2019-12-26 16:56:35,742 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Successfully fetched accesss token and ID token using authCode
2019-12-26 16:56:35,743 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Validating ID token received from access token end point HERE GOES TOKEN
2019-12-26 16:56:35,745 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Succesfully validated ID token with standard claims
2019-12-26 16:56:35,745 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] ( auth.oidc.OIDCClientHandler) DEBUG vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Retrieving userInfo claims from user info Endpoint
16:56:35.766 [http-nio-8080-exec-7] WARN org.apache.http.impl.client.TargetAuthenticationStrategy - Authentication scheme Bearer not supported
2019-12-26 16:56:35,768 [http-nio-8080-exec-7] [ STANDARD] [ ] [ Tda:03.01] (ngineinterface.service.HttpAPI) ERROR vm-pega-at.orange-ftgroup.ru| Proprietary information hidden - Proprietary information hidden: com.pega.pegarules.pub.PRRuntimeException
com.pega.pegarules.pub.PRRuntimeException: Unable to execute OIDC flow : Received invalid status code 401
Any ideas how to fix this?
Thanks in advance.