We have this below requirement for one of our project and we want to implement a security for all our exposed soap service. Our preferred option is to implement the same using two way SSL but we are ready to accept other possible options as well. Please suggest.
Requirement Details: We want to create a two way SSL authentication for all our existing/new PEGA exposed services.
Available Information: Certificates are available for both server and client sides
Bottlenecks: Below are the lack of information those actually lingering us to implement this architecture:
Where we have to keep our key store and trust store for PEGA server end and also for client/consumers
What configuration change (inside PEGA) , we need to do in service package and service soap rule to achieve this
In service package , we have an option to select TLS/SSL (For Rest Only). Is there any way we can use this for soap services as well?
Thanks for your post. As I understand it, you currently have this two-way SSL (mutual) authentication configured properly when Pega is a client.
Also, you currently have a gateway in front of the Pega server that current handles this two-way SSL (mutual) authentication. This gateway interacts securely with the client using two-way SSL and forwards the message along to Pega.
While this configuration works, the concern seems to be when someone references the Pega node name (URL) in a way that routes the two-way SSL request around the Gateway. Thus the questions about how to secure Pega with 2-way SSL.
Finally, the setting you see that mentions SSL/TLS just means "reject requests for REST services if it didn't come in through a secure channel." Pega currently does not have anything like that for SOAP.
Please let me know if this helps answer your question.
It is not possible to configure/resolve SSL issues for Services within the Pega product itself. The Application Server in which Pega runs handles all of the traffic. Pega is just processing the request data that the Application Server allowed to get to it and then returning response data intended for the client, through the Application Server. Therefore, by the time the requests get to Pega it is too late. The Application Server is handling the socket/transport layer, so SSL/TLS support is being provided completely by the Application Server.
This is different from mechanisms like HTTP authentication, where the credentials are provided as data in something like a header value, which will get passed through for Pega to decide if/how to handle it.