Question

3
Replies
736
Views
 Rupayan Paul (Rupayan Paul)
EY

EY
US
Rupayan Paul Member since 2013 1 post
EY
Posted: December 4, 2017
Last activity: December 8, 2017
Posted: 4 Dec 2017 14:15 EST
Last activity: 8 Dec 2017 17:42 EST
Closed

Best approaches to embed Security on a exposed soap service

Hi PDN Users,

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?
Data Integration Security
Moderation Team has archived post, This thread is closed to future replies. Content and links will no longer be updated. If you have the same/similar Question, please write a new Question.
Posted: 3 years ago
Posted: 8 Dec 2017 15:02 EST
Shawn Szturma (sztus)
PEGA
Director, Solutions Consulting
Pegasystems Inc.
US

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.


Right now, Pega expects this configuration to be done at the application server.  So webSphere should be configured to reject any SOAP request that isn't configured properly for two-way SSL, doesn't have the right URL format (SOAP request vs. launch portal request), or for which it doesn't have the certificates in its keystore.  This is an article on how this configuration can be done at https://developer.ibm.com/answers/questions/232166/2-way-ssl-between-websphere-app-server-and-another/.


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.​
Posted: 3 years ago
Posted: 8 Dec 2017 16:10 EST
Jeff Houle (HOULJ)
PEGA
Senior Software Engineer
Pegasystems Inc.
US

Just one note I'd like to add for the moment:


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.