We exposed a REST Service for our upstream systems. We need to know how to configure mutual SSL authentication in our Service REST rule.
we tried with the enabling the Authentication Type as "Basic" and enabled the "Use TLS/SSL (REST only)" but it seems to be not working. Please advise on this and let us know how mutual SSLworks with Service Rest.
I have seen folks confusing 1-Way for 2-Way SSL(mutual auth), can you confirm if the server hosting REST service has "Client Authentication" set to required?
Two-way authentication requires a truststore and a keystore on both the client and the server. In this example (below image), CA certificate "A" exists in the truststore and a CA certificate "B" in the keystore of the client. CA certificate "B" exists in the truststore and a CA certificate "A" in the keystore of the server.
The client sends a request to the SSL server(REST Endpoint). The SSL server(REST Endpoint) sends Certificate A from the keystore to the client. The client validates Certificate A against the certificates that are contained in the truststore.
If the certificate is found in the truststore, the client accepts communication from the SSL server(REST Endpoint). The server sends an authentication request to the client(Pega). The client(Pega) then sends Certificate B from the keystore to the SSL server(REST Endpoint). The server validates Certificate B against the certificates that are contained in the truststore. If the certificate is found in the truststore, the server accepts communication from the client.
Also you may want to check the SSL protocol your REST endpoint is running on:
Aah make it clear, as per Kevin's note please add DEBUG to "com.pega.pegarules.integration.engine.internal.client.rest" package and share the logs. Also provide screen capture of authentication profile. You may also want to open a SR for this?
Can you please tell how to add DEBUG to "com.pega.pegarules.integration.engine.internal.client.rest" package ?. we are not using any authentication profile we were just trying with random options and would have got that exception.
If an SR is raised, please make sure to note its ID in this discussion so we can track it (though I'd be fascinated to see if an issue of this complexity can be resolved in the PSC).
One thing of note, for any log files/screenshots attached, make sure to remove/blur out any references to things like ip addresses and customer information. For the most part, attaching this information with sensitive details scrubbed out is completely legitimate as that info often doesn't pertain to the issue being discussed.
I'm Sathish (Silp's colleague). We have created a SR-A8816, here is the reply I got from the support engineer,
You have asked how to prevent the calling application to access a REST service without the private key/certificate
I have reviewed the information you provided in SR-A8816. This request falls outside the scope of work supported by GCS. Questions about how to design, develop, or debug custom applications and similar types of questions are best addressed by posing a question to the (*NEW*) Product Support Community.
The Product Support Community is a place where Pegasystems architects, developers, and administrators may pose questions and interact with one another in a dynamic community. It is a great place to seek solutions to problems, and to share ideas. To access the Product Support Community please use this link: https://mesh.pega.com/community/pegaproductsupport
If you would rather have direct consulting assistance with your question I can reach out to the Pega Consulting practice on your behalf. Please let me know if you would prefer this option.
I will proceed with closing this SR based on the information I have provided.
We have both Connect-REST and Service-REST for this implementation.
In Connect-REST we have an option to configure the Key store in the "Security settings" where we are passing the private key & certificate to the target application. The similar way target application is calling us, but the problem is our REST service is hosted in the public Pega cloud and anybody can hit this service now.
In the Service-REST/Service package there is no OOTB option to stop anybody coming in to our application without the specific private key & certificate. There is a provision in the Service-SOAP, its not available for REST.
In your Service Package rule that belongs to your Service-REST, you must select TLS/SSL option and select "Requires Authentication" check box. When selected, all invocations of REST services belonging to this service package must use TLS/SSL, that is, using the https protocol.
We did that, but the problem is when the target system calling the Pega REST service, its being challenged by "basic" authentication instead of Certificate. The expectation is it should validate the client certificate provided by the calling application and verify the authentication using the SSL setup in place.
There is NO option to just select the "Use TLS/SSL (REST) only", it comes by default with "Basic" auth.
There has to be a way where we need to refer a "Key store/Trust store" contains the calling application's public key/certificate to validate the REST call by the calling application. I see that is the configuration is missing, which technically bridges the calling application and Pega application server to validate mutual SSL call. But I do not know where to provide that configuration.
Thanks for sharing the details of this. While we are getting a good handle on the process of referring people to use the community from an SR, we are still working on improving the process of SRs raised after having been discussed in the community first.
I've suspected this could happen, but until now, did not have any documented evidence.
With your feedback, we'll continue to iterate and improve on this particular aspect of the community experience.
Adi - Thanks for ensure the SR continued on the right path.
Posting the resolution of the SR here for reference.
The following suggestion was made after having been tested in-house by GCS.
Note there are at least two known side-effects to implementing this procedure:
1. The Rest Service will not longer be available over HTTP.
2. Some aspects of PRSYSMGMT (SMA) will stop working (download of logs from PRPC for instance): this can be corrected by loading the CLIENT CERTIFICATE into the BROWSER's keystore.
The following procedure assumes that the TRUST STORE of the JVM where PRPC is running already has the CERTIFICATE loaded (if using a SELF-SIGNED CERTIFICATE) or that the CERTIFICATE is signed by a well-known 'Certificate Authority' which is already trusted by the JVM.
<!-- START: Changesto allow Tomcat Client-Certificate-Authentication--> <!-- We need to disable 'login-config' - only allowed one occurence of 'login-config' is allowed in the configuration --> <!-- <login-config> <auth-method>BASIC</auth-method> <realm-name>PegaRULES</realm-name> </login-config> --> <!-- END: Changesto allow Tomcat Client-Certificate-Authentication-->
Log into PRPC DEVELOPER CONSOLE
Locate your SERVICE RULE.
Ensure the ‘Requires authentication’ checkbox is NOT checked.
For debugging the authentication process: the following file can be edited: