The access mode of a port supports the good ol’ deny or allow by default, with a list of folders and services in the exception list. Looking for the same function at the API level. Am I missing something obvious or is it just not there? Don’t want APIs exposed to the outside world simply because they’ve been deployed to the internal API GW (auth can be applied to prevent access but want to support “internal only” APIs that may not have/need authenticated access.)
Hi,
I think you can simply specify the namespace of your API with
/rad/…
Otherwise you can select ACL’s, that is if you have assigned specific ACL’s to the services associated with your API.
regards
John
Product Manager
Integration & Microservice Runtime
Not sure what you’re addressing on the namespace aspect. Not a factor really.
Regarding ACLs, as I mentioned we could potentially use groups/teams and policy to limit calls from outside. But would prefer a single “sentry” point rather than various groups/teams/policies. Also, I mentioned that some APIs that may be exposed will not have any auth needed at all. So ACL/group/team won’t work there. Can’t use ACLs on the IS service level for APIs that do not use IS-hosted services as the so-called “native” service.
Worded another way: want internal apps/users to be able to call particular APIs via the internal GW (authenticated and not authenticated, identified and not identified) but never via the external GW even if they are otherwise authorized to call. I was thinking that implementing the same approach used by IS and external (non-API) gateway function would make the most sense. Instead of indicating which folders and/or services allowed, specified which APIs are allowed via the external path.
@John_Carter4 – Thanks again for the response. I fear I may not have made my original query very clear.
My query is a about API access. What the API calls as the “native” service is immaterial. Our infrastructure is more or less like the diagram on page 14 of the API GW configuration guide:
As things stand right now with GW, if there is an API defined on the “Green Zone” (GZ) GW, then it is accessible via the DMZ GW. For select APIs, I want to prevent any calls by anyone via the DMZ GW. Want to allow calls for some APIs only in the GZ GW (if they have permission). Internal API clients connects to the GZ GW, not the DMZ GW. I want “Deny+” configurable on the GZ GW to allow access only to APIs that are in the explicit allow list.
The idea is similar to what is available with the Enterprise Gateway Server (EGS, formerly “reverse invoke server”) for Integration Server. Screen shot from an IS instance (not a GW host).
Obviously the equivalent exists on the IS instance hosting the GZ GW but that is at the service level. I would like a similar capability at the API level. Let me block/allow an API or any of the resources within a given API being called via the DMZ GW.
Regarding the namespace stuff, we’re clear on that. No issues/queries related to that. EDIT: I finally realized that when you say “namespace” that is referring to the folder/URL path. Sorry for not recognizing that. But that does not help here. DMZ GW API → GZ GW API → “native” service. I want to stop the call at the GZ GW API when it comes from the DMZ GW. The native service is not a factor at that point.
Hi Rob,
Sorry for the delay, took me a while to figure it out. The feature that you are asking for is possible by setting the green zone API Gateway’s internal port to deny by default and then adding any API’s you want to the allowed list.
Unfortunately this is a new behaviour introduced with 10.7 and even with this version you have to explicitly set an extending setting to adopt the new behaviour.
e.g.
Thanks John. I see the “Bind access of APIs with ports” added item in the 10.7 readme file, the description of the extended setting and the port config in the GW user’s guide. That looks like it will do exactly what I was looking for.
