[Apiman-user] How to solve the conflict about CORS and the X-API-Key in header?

Mon Oct 2 16:40:28 EDT 2017

This is a good area of discussion.

There are some caveats to the query parameters approach. Query params
are sometimes stored in logs and other areas where you wouldn't want
highly sensitive data being kept.

I think in the Apiman API Key case it should be okay, but it depends
on your use case:

- The API Key is only to provide correlation between an inbound
request and an Apiman Client; it doesn't really provide security. For
example, you would generally still need to do OAuth2, JWT, BASIC or
some other security mechanism over the top if you want "real" auth and
authz.

- The Apiman Gateway strips out the apikey query parameter (i.e. it
doesn't get passed to the backend). However, if you terminate SSL
before the Apiman Gateway then it might have a chance to be stored in
some logs elsewhere.

For example, using my echo service (just responds back with what it receives):

}[msavy at mmbp apiman](list-prototype)$ curl -k
'https://localhost:8443/test/froofroo/9003?apikey=7ab94cd5-6d31-4ed0-ba8a-607b2cbe0bc9&another=thing'
{
  "method" : "GET",
  "resource" : "/a/b/c/?another=thing", (1)
  "uri" : "/a/b/c/",
  "headers" : {
    "Transfer-Encoding" : "chunked",
    "Accept" : "*/*",
    "User-Agent" : "curl/7.54.0",
    "Host" : "localhost:9999"
  },
  "bodyLength" : null,
  "bodySha1" : null,
  "counter" : 6

(1) Notice that the apikey query parameter has not appeared in the
echoed response

As a fairly rough solution, perhaps we could allow people to
additionally set a global CORS config on the Apiman Gateway (e.g. in
your case where you control the entire gateway this could be a useful
'base case').

On 2 October 2017 at 19:52, Celso Agra <celso.agra at gmail.com> wrote:
> I understand!
>
> I got this conflict because part of my application is made in angular4.
> I'm using apikey as a query param, but this was a question to me "is this
> right put apikey as query param?"
>
> I believe there is no problem leave this as query param, since url is also
> encrypted.
>
> Thanks for your attention Eric and Marc!
>
>
> 2017-10-02 15:22 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>>
>> Correction:
>>
>> I think that we can provide full functionality in all
>> circumstances.
>>
>> I think that we *cannot* provide full functionality in all
>> circumstances.
>>
>> On 2 October 2017 at 19:21, Marc Savy <marc.savy at redhat.com> wrote:
>> > I seem to recall another annoying knot: as you can't set any custom
>> > headers on a preflight request itself in most browsers (any?),
>> > reaching the correct CORS policy is impossible when putting the
>> > X-API-Key in the header. This probably explains why people like Google
>> > require it to be a query parameter.
>> >
>> > Therefore, unless we encoded that information in the URL itself (seems
>> > a bad idea) I think that we can provide full functionality in all
>> > circumstances.
>> >
>> > Unless someone else thinks I'm wrong? Happy to hear alternative
>> > theories.
>> >
>> > On 2 October 2017 at 19:07, Celso Agra <celso.agra at gmail.com> wrote:
>> >> I attached an image. Also I added different kinds of headers, just to
>> >> pass
>> >> in case of "Camel Case" validation
>> >> Unfortunately the CORS validation still occurs when I use the plugin...
>> >>
>> >> 2017-10-02 15:00 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>> >>>
>> >>> This is from memory, but no, I don't think so: the API key is needed
>> >>> before the correct policy chain (including CORS policy) can be
>> >>> resolved.
>> >>>
>> >>> The CORS protocol, when using a custom header, requires a preflight
>> >>> request, however the preflight does not allow any custom headers to be
>> >>> set, so we can't currently resolve the correct policy chain.
>> >>>
>> >>> We could think about specifically making X-API-Key available for
>> >>> preflight as I think that should always be okay, but I'll have to
>> >>> investigate whether there are any downsides.
>> >>>
>> >>> Of course, we could continue saying to use a query param in that
>> >>> scenario!
>> >>>
>> >>> On 2 October 2017 at 18:37, Eric Wittmann <eric.wittmann at redhat.com>
>> >>> wrote:
>> >>> > Just to be clear - if X-API-Key is added as an allowed CORS header
>> >>> > in
>> >>> > the
>> >>> > CORS plugin configuration, does that solve the issue?
>> >>> >
>> >>> > -Eric
>> >>> >
>> >>> >
>> >>> > On Mon, Oct 2, 2017 at 1:17 PM, Celso Agra <celso.agra at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> So, there is no prob to pass as query param!
>> >>> >>
>> >>> >> Thanks Marc
>> >>> >>
>> >>> >> Best Regards,
>> >>> >>
>> >>> >> Celso Agra
>> >>> >>
>> >>> >> 2017-10-02 13:49 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>> >>> >>>
>> >>> >>> Hi Celso,
>> >>> >>>
>> >>> >>> The query string is encrypted with SSL/TLS.
>> >>> >>>
>> >>> >>> Regards,
>> >>> >>> Marc
>> >>> >>>
>> >>> >>> On 2 October 2017 at 17:40, Celso Agra <celso.agra at gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> Yeah! It is! My concern is because I'm passing the apiKey as a
>> >>> >>>> query
>> >>> >>>> param.
>> >>> >>>>
>> >>> >>>> I don't know if requests works like this in ssl requests, but I
>> >>> >>>> believe
>> >>> >>>> that query params can be viewed if you have a sniffer, unlike
>> >>> >>>> header
>> >>> >>>> params.
>> >>> >>>>
>> >>> >>>> So, I'm probably have to allow X-API-Key header in Apiman
>> >>> >>>> requests.
>> >>> >>>> Would be possible to add this feature in a plugin or maybe in the
>> >>> >>>> Apiman?
>> >>> >>>> I'll take a look in some classes to know how to do that.
>> >>> >>>>
>> >>> >>>> I'd like to know if it is a feature that will contribute with the
>> >>> >>>> project.
>> >>> >>>>
>> >>> >>>> Thanks for your answer Marc.
>> >>> >>>>
>> >>> >>>> Best Regards,
>> >>> >>>>
>> >>> >>>> Celso Agra
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> 2017-10-02 9:18 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>> >>> >>>>>
>> >>> >>>>> If I understand your questions correctly: by default CORS does
>> >>> >>>>> not
>> >>> >>>>> allow any custom headers to be sent in the request. This means
>> >>> >>>>> that
>> >>> >>>>> Apiman
>> >>> >>>>> does not receive the X-API-Key header and necessarily can't
>> >>> >>>>> figure
>> >>> >>>>> out how
>> >>> >>>>> to route the request. The same CORS restriction does not exist
>> >>> >>>>> with
>> >>> >>>>> query
>> >>> >>>>> parameters so if you provide it with the query param you'll be
>> >>> >>>>> okay.
>> >>> >>>>>
>> >>> >>>>> Perhaps a (partial) solution to some of these kinds of CORS
>> >>> >>>>> issues
>> >>> >>>>> is
>> >>> >>>>> for Apiman to always indicate that the X-API-Key header is
>> >>> >>>>> allowed.
>> >>> >>>>>
>> >>> >>>>> Regards,
>> >>> >>>>> Marc
>> >>> >>>>>
>> >>> >>>>> On 27 September 2017 at 05:35, Celso Agra <celso.agra at gmail.com>
>> >>> >>>>> wrote:
>> >>> >>>>>>
>> >>> >>>>>> 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
>> >>> >>>>>>
>> >>> >>>>>> _______________________________________________
>> >>> >>>>>> Apiman-user mailing list
>> >>> >>>>>> Apiman-user at lists.jboss.org
>> >>> >>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>> >>>>>>
>> >>> >>>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> --
>> >>> >>>> ---
>> >>> >>>> Celso Agra
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> ---
>> >>> >> Celso Agra
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> Apiman-user mailing list
>> >>> >> Apiman-user at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>> >>
>> >>> >
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ---
>> >> Celso Agra
>
>
>
>
> --
> ---
> Celso Agra