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

Mon Oct 2 20:44:29 EDT 2017

Great! Global CORS could be awesome and useful!

In general I'm using API Key to use some security policies. My policies
involves IP address white list, oauth integration with keycloak, and roles
verification. Also, I used a validation about the number of requests
filtered by IP Address to avoid DDoS or web crawlers.
So, there is some difficulties...

When I'm using javascript and mobile apps, I don't know if would be
possible to use the white list. I've never tried to test that. but, using
integration with keycloak gives me a security level, so that's ok to me!

Thanks for your answer!

Best Regards,

Celso Agra

2017-10-02 17:40 GMT-03:00 Marc Savy <marc.savy at redhat.com>:

> 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
>

-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171002/e8e06535/attachment-0001.html 