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
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
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
CORS issue
by Scott Elliott
Why, when the CORS policy plugin is used, do I get multiple
Access-Control-Allow-Origin headers in the response. From curl:
Origin: http://blah.com
Access-Control-Allow-Origin: http://blah.com
Access-Control-Allow-Origin: Jetty(9.2.19.v20160908)
Chrome does not like the multiple headers, so the API request fails.
8 years, 2 months
Re: [Apiman-user] Health Check URL for API Gateway
by Marc Savy
Julien,
The standard status endpoint or the *gateway* is:
http://apimanager:apiman123!@localhost:8080/apiman-gateway-api/system/status
Notice the embedded default username and password (remember to
substitute for whatever security mechanism you set it up)
I just checked out the 1.3.0.Final image and it seems to work okay for me.
You can also do the same for the apiman manager endpoint, but instead it is:
http://localhost:8080/apiman/system/status
Let me know if it works for you.
Regards,
Marc
On 4 September 2017 at 08:48, Julien Gerboud <julien.gerboud(a)euranova.eu> wrote:
> Hi Marc,
>
> Thanks for your quick reaction.
>
> I am using the Servlet version. To be more precise, I am using the Wildfly10
> docker image with tag 1.3.0.Final (I kept only the gateway part, the
> manager, elasticsearch, keycloak and database are on different containers).
>
> Regards,
>
> On Sun, 3 Sep 2017 at 19:30 Marc Savy <marc.savy(a)redhat.com> wrote:
>>
>> Hi,
>>
>> Which version of the gateway are you using? Vert.x or Servlet?
>>
>> Regards,
>> Marc
>>
>>
>> On Sunday, September 3, 2017, Julien Gerboud <julien.gerboud(a)euranova.eu>
>> wrote:
>>>
>>> Hello to you all,
>>>
>>> I am setting up a load balancer (HA Proxy) in front of 2 (or more) APIMan
>>> API Gateways. In order to know which instance is up, the load balancer needs
>>> an health check.
>>>
>>> I tried to use the /system/status/ endpoint of the gateway but I get a
>>> 500 error with a "X-Gateway-Error: Invalid endpoint provided:
>>> /system/status/" header.
>>>
>>> Is there another health check endpoint or a REST Doc for the API Gateway?
>>>
>>> I am using APIMan version 1.3.0.Final.
>>>
>>> Thanks for your help!
>>>
>>> Regards,
>>> Julien GERBOUD
>>> --
>>>
>>> ______________________________
>>>
>>> Julien GERBOUD
>>>
>>> Developer
>>> (M) +32 475 78 05 31
>>>
>>> EURA NOVA
>>>
>>> Rue Emile Francqui, 4
>>>
>>> 1435 Mont-Saint-Guibert
>>>
>>> (T) +32 10 75 02 00
>>>
>>> euranova.eu
>>>
>>> research.euranova.eu
>>>
>>>
>>> ♻ Be green, keep it on the screen
>>
>>
>>
>> --
>> Sent from mobile phone, apologies for brevity.
>
> --
>
> ______________________________
>
> Julien GERBOUD
>
> Developer
> (M) +32 475 78 05 31
>
> EURA NOVA
>
> Rue Emile Francqui, 4
>
> 1435 Mont-Saint-Guibert
>
> (T) +32 10 75 02 00
>
> euranova.eu
>
> research.euranova.eu
>
>
> ♻ Be green, keep it on the screen
8 years, 3 months
Health Check URL for API Gateway
by Julien Gerboud
Hello to you all,
I am setting up a load balancer (HA Proxy) in front of 2 (or more) APIMan
API Gateways. In order to know which instance is up, the load balancer
needs an health check.
I tried to use the /system/status/ endpoint of the gateway but I get a 500
error with a "X-Gateway-Error: Invalid endpoint provided: /system/status/"
header.
Is there another health check endpoint or a REST Doc for the API Gateway?
I am using APIMan version 1.3.0.Final.
Thanks for your help!
Regards,
Julien GERBOUD
--
______________________________
*Julien GERBOUD*
Developer
(M) +32 475 78 05 31 <+32%20475%2078%2005%2031>
*EURA NOVA*
Rue Emile Francqui, 4
1435 Mont-Saint-Guibert
(T) +32 10 75 02 00 <+32%2010%2075%2002%2000>
*euranova.eu <http://euranova.eu/>*
*research.euranova.eu* <http://research.euranova.eu/>
--
♻ Be green, keep it on the screen
8 years, 3 months
