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 <[email protected]> wrote: > 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 we get bearer token from > headers, url parameter or both. I'm sure every APIM users do not want to > allow sending token as query string. Also most importantly there is a way > to configure remove auth headers and skip it by adding configuration to > api-manager.xml. And we should keep it as it is because APIM users are > heavily use it. > > Thanks, > sanjeewa. > > On Mon, Nov 24, 2014 at 4:14 PM, Sam Sivayogam <[email protected]> wrote: > >> 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 <[email protected]> >> wrote: >> >>> 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. Otherwise we will be looking at transport headers. Or we may be >>> able to look at both(transport header, query parameter) according to >>> defined order. WDYT? >>> >>> Thanks, >>> sanjeewa. >>> >>> On Mon, Nov 24, 2014 at 11:40 AM, Nuwan Dias <[email protected]> wrote: >>> >>>> 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 information in the url IMO. Ex: >>>> For systems communicating internally only. With the IoT stuff building up, >>>> I presume there could be more valid uses of this. >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> On Mon, Nov 24, 2014 at 11:33 AM, Gayan Gunawardana <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>>> >>>>>> On Sat, Nov 22, 2014 at 12:50 PM, Harsha Kumara <[email protected]> >>>>>> 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 >>>>>>> the security issues cause by using token as query param. Also the >>>>>>> specification specified that it's discourage to use this approach. IMO >>>>>>> If >>>>>>> we support it, we shouldn't use in our products unless if there is any >>>>>>> specific reason. >>>>>>> >>>>>> >>>>> What would be the particular use case to send access token in query >>>>> String. This is a bad practice according to many real world use cases [1]. >>>>> >>>>> [1] >>>>> http://www.thread-safe.com/2013/10/latest-facebook-security-vulnerability.html >>>>> -- >>>>> Gayan Gunawardana >>>>> Software Engineer; WSO2 Inc.; http://wso2.com/ >>>>> Email: [email protected] >>>>> Mobile: +94 (71) 8020933 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Associate Tech Lead - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Sam Sivayogam* >> >> Software Engineer >> Mobile : +94 772 906 439 >> Office : +94 112 145 345 >> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >> lean.enterprise.middleware. >> > > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
