On Tue, Nov 25, 2014 at 11:15 AM, Amila De Silva <[email protected]> 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. For initial implementation we may start with api-manager.xml. Thanks, sanjeewa. > > 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 > > -- *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
