Authorization question
by Stephen Henrie
My goal is minimize the amount of Apiman configuration that I need to do by
sharing a single, common authentication Plan using the Keycloak plugin
across all APIs while using an API specific authorization policy for each
individual API.
As such, I am trying to configure a single, global plan within Apiman that
can be used for ensuring authentication policy using the Keycloak plugin
which forwards all of my realm roles. This single plan would be assigned to
all of my APIs in the Org, which would allow me to only have to configure
the Keycloak realm information in one place. Then for each individual API,
I was hoping to add a single Authorization policy plugin configured with
endpoints and paths specific for each API.
Something like
Api1 ---> Keycloak Plan Abc
+---->Authorization Policy (123)
Api2 ---> Keycloak Plan Abc
+---->Authorization Policy (456)
When I do this and call one of the API endpoints, I am getting the
following error:
curl -k -H "Authorization: Bearer $T"
https://localhost:9443/apiman-gateway/chassi/chassi-tenant-bff/1.0/mytenants
{"type":"Other","failureCode":10010,"responseCode":0,"message":"No roles
have been extracted during authentication. Make sure the authorization
policy comes *after* a compatible authentication policy in your
configuration.","headers":[]}
It would seem that the Keycloak plugin that is configured in the Plan
assigned to the API is not forwarding the realm roles to the Authentication
policy which is also assigned to the same API.
Is this by design? Do the authentication and authorization policies have to
be within the same entity (ie. Plan, Api, etc) and not passed out of a plan
to be used by downstream policies? If so, is there another way to
configure plans and policies that will allow me to accomplish my goal?
Thanks in advance!
Stephen
6 years, 7 months
Enhancing apiman-cli to make headless gateway configs easier to use.
by Marc Savy
We've had some people using the Apiman Gateway headless for a while
now, either with the new immutable registry that loads from JSON[1],
or simply using any existing registry via the gateway API instead of
using a manager.
The main issue people encounter is that policy configuration contains
two fields that are difficult to work out and clumsy to encode
properly[1]:
- `policyImpl` requires the plugin's URI, including the path to its
main class. You can work these out by looking at the plugin's source
code, but that's rather circuitous and it would be nicer to just
provide the plugin's GAV (like in the manager) and for it to be
resolved.
- `policyJsonConfig`[3] needs to be escaped properly (and must valid
according to its schema).
Neither of these aspects are especially user-friendly. My proposal is
to extend apiman-cli's functionality to allow the Apiman Gateway to be
configured directly via a YAML/JSON file (i.e. declaratively).
We can therefore provide a more user-friendly interface that automates
the resolution of plugins; validations and escapes the policy config;
etc.
A final step would be to bundle the apiman-cli tool with our distros
to make it easier to access.
Any thoughts?
Regards,
Marc
[1] https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/v...
[2] Of course, this interface was never truly designed to be used by
humans, so that's understandable
[3] Unfortunately named as it can be any arbitrary string, the policy
just needs to be able to decode it. For example, it could be XML.
6 years, 7 months
Proxy headers missing for processing policies
by Stephen Henrie
I have Apiman running in an openshift environment, which is essentially a
similar configuration to running in kubernetes. Each container/pod is
always receiving http/s requests through an HA Proxy server, so that the
x-forwarded-* set of headers get added to each request by the proxy server.
Unfortunately, it appears that the headers which are provided in the
ApiRequet bean when the policy chain processor doApply() method is called
does not include these proxy related headers. This means that the standard
policies for the IP white and black listing policies do not work when the
apiman gateway is behind a proxy server. The request.getRemoteAddr()
method returns the ip address to the proxy server, so there is no way to
get the ip address of the originator since the x-forwarded-for header ( and
related headers ) are not found.
Has anyone else experienced this? If so, is this by design?
Thanks!
Stephen
6 years, 9 months
policy error/failure writer cannot find logger
by Balu S
Hello,
I have a custom error and failure writers that
implements IPolicyErrorWriter and IPolicyFailureWriter respectively. But
these implementation methods does not provide IPolicyContext object to
access loggers. However this is possible from IDataPolicy.
So I have tried to inject the ApimanLogger like below, but it always yields
null. I have include the neccesary jar as "provided" scope in pom.xml.
*example:*
public class MyPolicyErrorWriter implements IPolicyErrorWriter{
@Inject @ApimanLogger(MyPolicyErrorWriter.class)
IApimanLogger logger;
@Override
public void write(ApiRequest request, Throwable error,
IApiClientResponse response) {
// here logger is always null?
logger.info("
}
......
Could you please suggest how can I add IApimanLogger to my custom error or
failure writers ?
Best regards
Balu
6 years, 9 months
Any expiry settings for Clients ?
by Ashish Patel
Hi,
We recently faced a strange issue on our APIman setup (QA/UAT environment so far). Suddenly one by one (not all APIs yet) API Clients are complaining that they are getting below exception. Here, none of the Client details (register / unregister) changed under APIManUI and even though below exception. The fix we applied selectively is, break any one API from client and add the same again through "New Contract" -> it will enable the "Re-Register" button -> click it and issue is resolved. This leads me to think, is there any Client API expiry settings - after which we have to re-register the client ? OR am I missing something here ?
Any help is greatly appreciated.
App Server: Wildfly 10.0.0-Final
APIMan: 1.2.7.Final
OS: Ubuntu
Exception:
[apiResponse] => Array
(
[responseCode] => 500
[message] => No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
[trace] => io.apiman.gateway.engine.beans.exceptions.InvalidContractException: No client found for API Key 9c561c16-e866-44fe-b5d6-c11c5629f0d6
at io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)
at io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)
at io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)
at io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)
at io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
Thanks & Regards,
Ashish Patel
6 years, 10 months
JIRA problems (unable to log in)
by Marc Savy
Hi All,
Community members have reported that they are unable to log into the
Apiman JIRA.
Unfortunately we had no idea up until now as our own accounts were
unaffected. We've contacted the relevant support folk and hopefully
the glitch will be resolved shortly.
Apologies for the inconvenience and just to reassure folk that work is
still very much progressing!
Regards,
Marc
6 years, 10 months
