Imagine you have a service that is secured with Basic Auth or better yet OAuth2 and you would like to leverage the complete capabilities of an API Platform so you choose to create an API and deploy it to a gateway running in front of your service.
When you call your service directly from within your internal network, everything works, providing you include the appropriate Authorization header that your service expects. However, when you call the API endpoint on your gateway, the endpoint you will make available to your consumers, it does not work. You are passing everything as your original call, you've just modified the end-point to point to your gateway load balancer address and API end-point. What happened?
Well, most of the headers you pass to the gateway will simply pass through by default, with the exception of Authorization. Here is an example of a real simple API I created.
This API receives a request to the "echo" end-point and simply passes it to httpbin.org so we can see the result. So, as we can see, I am not really including any security policies in my API. I am choosing to leave that to the back-end service in this case. What happens if I call this API passing with an Authorization header. As you can see below, it is not included in the headers.
This is because the gateway is an authorization and policy enforcement engine and in most cases, when we validate the user at the gateway, we do not want to pass that header to the back-end systems. But what if we do want to pass that header? It turns out this is quite simple. We add the header to our Service Request policy. Read the complete article here.
For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.