Soap 2 way TLS between client app and backend target

Hi,

I have a System(say A) that exposes a SOAP service s1 and access is restricted to clients with valid client certificate(generated by A).

I want to create a rest to soap API that the client apps can use to access SOAP service s1.

Each client app would have its own client certificate.

Question

1) How do I achieve this?

Lets say , I can create a developer app for client (lets say google) with grant type as client_credential.

google would use the access token to call the rest to soap api along with passing the client certificate(generated by A).

In this case, client cert would get terminated at apigee and wouldn't pass through to the actual system A.

Is there any alternate solution to the underlined problem.

I am sure this is one of the basic questions and I am doing something wrong here.

0 1 1,013
1 REPLY 1

Yes, ok let's break it down.

I will make some assumptions. First the certificate is a x.509 certificate. There are a couple options here.

  1. The cert is used for transport-level security. In that case the transport layer (TLS) uses the cert and the application or messaging layer does not. The server that receives the direct connection from the client, in your case it would be Apigee Edge, would need to be configured to trust the client cert, or the CA that signed the cert. This is normal 2-way TLS on HTTP. In this case, there is no way for Apigee Edge to use that same cert to secure the transport layer between Apigee Edge and the existing SOAP service. It is not possible. Also it would violate the intent of TLS in the first place, which is that a cert uniquely identifies the calling party. If Apigee Edge could impersonate any client that connected to it, that would be bad news, security wise.
  2. The cert is used for application-level security. Perhaps it is used to sign an XML payload; this is a common thing done with WS-Security. In this case, again the client could "sign" the "REST" payload sent to Apigee Edge. But Apigee Edge could not then "sign" the transformed SOAP payload sent to the backend, because Apigee edge does not possess (and should not possess) the client's certificate with the private key, which is necessary for signing.

So what is to be done?

Let's understand the idea of "mediation". When I talk to a waiter at a restaurant, the waiter acts as a mediator. He mediates my request to the kitchen staff, to prepare a meal for me. I don't talk directly to the kitchen staff. I talk to the waiter, and the waiter talks to the kitchen staff. The waiter is responsible for verifying that I am a bonafide customer, that I am willing to pay for service, and that I am not making nuisance requests. In other words, the waiter verts and verifies my identity and my request, before relaying it to the kitchen staff.

When the waiter talks to the kitchen staff, the kitchen staff understand it is the waiter. They don't trust some random person off the street to ask them to prepare a meal. There are only a few trusted waiters, and the kitchen staff authenticate the waiter when she makes a request so that the kitchen staff does not perform work requested by unknown or unauthorized people. The waiter mediates my request If it's a Greek restaurant, It's possible the kitchen staff speaks only Greek; in which case the waiter can translate from my English-language request, into a Greek language request that can be understood by the kitchen staff. And if the kitchen staff has any message for the customer, the waiter can do the reverse Greek-to-English translation. The waiter, being bi-lingual, can do this translation.

Apigee Edge can similarly act as a mediator. Apigee Edge will authenticate clients, and then vet their requests. Apigee Edge can transform the requests (English->Greek, JSON->XML) before relaying them to the backend. Apigee Edge can translate XML from the backend into JSON that can be sent to the client. Implicit in this model is that the backend trusts Apigee Edge. The backend system does not trust the originating client. Apigee Edge acts as the mediator. Therefore if the backend system requires certificate-level security (either transport or application-level) then Apigee Edge is configured with the cert. The security between Apigee Edge and the backend is protected by the cert; Apigee Edge acts as the client to the backend.

Apigee Edge can multiplex many external clients to its one certificate. This requires that Apigee Edge also dispenses credentials to the clients. And this makes sense. Moving from SOAP, with it's angle brackets and cert-based security, into REST, with JSON (usually) and token-based security, makes end developers much happier. Apigee edge can help you make that happen, but you will need to change the security model for the external clients, to allow Apigee Edge to act as mediator.

5940-screenshot-20170324-140810.png

Does this help?