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.
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.
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.
Does this help?