On Tue, Nov 25, 2014 at 11:15 AM, Amila De Silva wrote:
> Hi,
> Shouldn't we think of providing the configuration in each API rather than
> in api-manager.xml. So some APIs will get the token only from the Header,
> while some other APIs can get if from request URL.
>
+1 that would be very useful
Hi,
Shouldn't we think of providing the configuration in each API rather than
in api-manager.xml. So some APIs will get the token only from the Header,
while some other APIs can get if from request URL.
On Tue, Nov 25, 2014 at 10:18 AM, Sanjeewa Malalgoda
wrote:
> As of now we have implemented
>
As of now we have implemented
method extractCustomerKeyFromAuthHeader(headers) to extract authentication
headers(token) from incoming transport headers list. So we might need to
add generic method in a way we can retrieve token from message context.
What i suggest is having configuration to decide
Hi Sanjeewa,
Currently the key validation is done inside OAuthAuthenticator. what i’m
planning to do is to get the key from query parameter if key is not
available in the Authentication Header.
regards
On Mon, Nov 24, 2014 at 2:12 PM, Sanjeewa Malalgoda
wrote:
> IMO we should add configuratio
IMO we should add configuration to key validation entry point (in gateway
authentication handler). With this configuration we should be able to
decide token accept as query param, transport header or both. If query
param authentication header enabled only we will retrieve token from query
params. O
In general, it is understood that it is bad practice. But its mentioned in
the OAuth 2.0 spec, so IMO as a product we should support it but mention
implications on the docs clearly.
In scenarios where the communication between the client and server are
guaranteed to be safe, its ok to pass the inf
>
>
> On Sat, Nov 22, 2014 at 12:50 PM, Harsha Kumara wrote:
>
>> Hi,
>>
>> As Johann mentioned, if the specification defined sending token as the
>> query param, we needs to support it and implement as specification
>> specified. But again the user who going to use it needs to know aware of
>> th
Hi all,
Thanks a lot for your replies. Since the spec says to implement using query
string, i will implement according to the spec specified by Johann and i
will mention the security considerations in the documentation.
Regards
On Sat, Nov 22, 2014 at 12:50 PM, Harsha Kumara wrote:
> Hi,
>
> A
Hi,
As Johann mentioned, if the specification defined sending token as the
query param, we needs to support it and implement as specification
specified. But again the user who going to use it needs to know aware of
the security issues cause by using token as query param. Also the
specification spe
Hi,
Given you use HTTP, If the request is intercepted, keys are exposed even
you send as URL or as headers.
If you use https, headers and URL are both encrypted I guess. However
sending in URL has some drawbacks,
1) browsers caches the URL
2) will be printed in logs ad Johans mentioned
So bette
First of all this is highly discouraged way of sending the access token,
mainly because you will find it in the http access logs.
Still if you want to go ahead an implement it, it must follow the
specification at [1].
However we should discourage using this approach.
[1] https://tools.ietf.org/htm
Hi all
I’m developing $Subject for APIM
Currently the access token is passed in the Authorization header and now
i’m planning to Implement this feature by sending access token in the
query string using the parameter name "authkey" as shown below,
Eg :-
http://10.100.5.192:8280/twitter/1.0.0?q=w
12 matches
Mail list logo
