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
8 years, 1 month
Bind Vert.x Gateway to IP
by Jorge Riquelme
Hi,
I couldn't find how to bind Vert.x Gateway to a specific IP (using the
conf-es.json file, or some parameter like -b=x.x.x.x).
Any help would be appreciated :)
Best regards,
Jorge Riquelme
8 years, 1 month
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.
8 years, 1 month
Custom reports from ES
by Ashish Patel
Hi,
We are using APIMan (1.2.7) in production and can see default API Metrics from APIMan Manager instance. It gives last 30 days/7 days usage. However, we would like to fetch custom reports like
1. Max/Avg no of requests per day per API
2. Max/Avg. response time per API
3. Total no. of APIs being used in last X days (across different organization).
..... etc.
Can we plug Kibana on top of ES and fetch such reports ?
In case if we want to shoot direct ES command , any help in ES queries to retrieve reports such as above ?
Any other help to achieve above will be highly appreciated.
Thanks & Regards,
Ashish
8 years, 2 months
How to solve the conflict about CORS and the X-API-Key in header?
by Celso Agra
Hi all,
I got some errors with CORS plugin when I try to use my API with a contract.
So, I consume my API passing info through header, such as: Authorization,
Content-Type, and X-API-Key.
I'm talking about a javascript application. So, CORS is a problem for that
language.
When I configure my contract to allow Cross-Origin, the error still there,
but if I put my X-API-Key, as a query parameter, the CORS works fine.
Does anyone could help me to understand that?
I'm concerned to pass my contract as a query parameter. It should be on
Header of my Http Request.
Please, help me to understand if it is a behaviour of the application and
how can I solve this without use query param.
Best Regards,
--
---
*Celso Agra*
8 years, 2 months
