"The OAuth 2.0 Authorization Framework: Bearer Token Usage" spec [1] mentions 3 ways the token could be sent to the Resource Server - APIM Gateway in this case:
- Authorization Request Header Field - Form-Encoded Body Parameter - URI Query Parameter It doesn't seem to mandate that other header names couldn't be used. Since we anyway use the recommended "Authorization" header by default, I don't see a problem in this. [1] https://tools.ietf.org/html/rfc6750#page-4 On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[email protected] > wrote: > Is this approach (custom authorization header field) allowed at OAuth2 > spec level? I mean, is this something we can customize/define and use it > for our own, and also in accordance with the spec? > > Thanks, > > On Thu, Nov 30, 2017 at 10:57 AM, Viduranga Gunarathne <[email protected] > > wrote: > >> Hi, >> >> @Prasanna, >> No we do not need to restart the server. Since this configuration is >> shipped with the tenant-conf.json, it will be automatically added to each >> of the created tenant configs in the registry, whenever a new tenant is >> created. Even for an existing tenant it can be added manually to the >> respective tenant config from the registry. A tenant only has to change the >> config in the registry to change the header name and save it back to >> registry. So when a new API is published, the custom header name will be >> read from the specific tenant config in the registry and added to the >> synapse config so that it will be deployed in the Gateway. >> >> @Chamalee, >> Yes, it will allow us to pass a custom header field instead of >> "Authorization" to the back end for authorization. And since this config is >> deployed in the gateway through the synapse config, once a request is >> received it can check for the specific header field for the authorization >> token. >> >> The use cases for this are as follows: >> >> i) In a scenario where both the back end and the API-M requests >> authorization tokens. >> If the back end already expects an authorization token by the name >> "Authorization", then there will be a complication when sending two tokens >> by the same name; one for the back end and he other for APIM. So the >> authorization header name of APIM should be changed. >> >> ii) Existing client apps that communicate with a back end with >> authorization tokens such as "TOKEN", "KEY". >> When APIM is introduced to an existing system where client apps used to >> communicate with the back end with their own authorizations tokens such as >> "TOKEN", "KEY" etc. , the client apps will have to be modified to send >> "Authorization" instead. This can be avoided with customizing the >> authorization header. >> >> iii) In the APIM cloud, each tenant will be able to define their own >> authorization header field. >> >> Thanks, >> Viduranga. >> >> On Mon, Nov 27, 2017 at 10:21 PM, Chamalee De Silva <[email protected]> >> wrote: >> >>> Hi Viduranga, >>> >>> As per this design, >>> Assuming that for all tenants the tenant-config is having the >>> CustomAuthHeader value and RemoveOAuthHeadersFromOutMessage is >>> configured as false, >>> it allows us to pass a custom header field instead of Authorization >>> header to the backend for the authorization. >>> >>> Can you elaborate more on what is expected by sending a custom Header >>> field and how can we guarantee that the HTTP proxies will understand these >>> Custom Headers ? >>> >>> And also, what is the real use case of differentiating this custom >>> Header by tenant domain ? >>> >>> >>> >>> Thanks, >>> Chamalee >>> >>> On Mon, Nov 27, 2017 at 5:47 PM, Prasanna Dangalla <[email protected]> >>> wrote: >>> >>>> HI Viduranga, >>>> >>>> Do we need to do a restart after we add this configuration? Hope not >>>> since we will need to restart for each every tenant and it will be an issue >>>> in a multi-tenant environment. >>>> >>>> Thanks >>>> Prasanna >>>> >>>> On Mon, Nov 27, 2017 at 2:36 PM, Chamin Dias <[email protected]> wrote: >>>> >>>>> Hi Viduranga, >>>>> >>>>> Small clarification, does this have any impact for caching >>>>> <https://docs.wso2.com/display/AM210/Configuring+Caching>? >>>>> >>>> >>>>> Thanks. >>>>> >>>>> On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Dinusha, >>>>>> >>>>>> No we do not have to add it manually. "CustomOAuth2Header" >>>>>> configuration is added to the "tenant-conf.json" that is shipped with the >>>>>> product. Therefore once a tenant is created, this config will be >>>>>> automatically added to the registry of the specific tenant. If a tenant >>>>>> wants to change the header, then that tenant can change it in the >>>>>> respective tenant configuration and save it to the registry. >>>>>> >>>>>> Thanks, >>>>>> Viduranga. >>>>>> >>>>>> On Mon, Nov 27, 2017 at 12:08 PM, Dinusha Dissanayake < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Viduranga, >>>>>>> >>>>>>> Just to make it clarify, do we have to enter CustomOAuth2Header >>>>>>> field manually after creating a tenant or will it be automatically added >>>>>>> when we create a tenant? >>>>>>> >>>>>>> Thanks, >>>>>>> DinushaD. >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 11:41 AM, Viduranga Gunarathne < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Attached below is a sample tenant-conf.json and synapse config >>>>>>>> featuring the proposed implementation. >>>>>>>> >>>>>>>> Config in tenant-conf.json >>>>>>>> ------------------------------------------------------------ >>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------------- >>>>>>>> >>>>>>>> { >>>>>>>> ... >>>>>>>> "CustomOAuth2Header" : "ENG_Auth", >>>>>>>> >>>>>>>> "RemoveOAuthHeadersFromOutMessage" : true >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Config injected into synapse config file: >>>>>>>> ------------------------------------------------------------ >>>>>>>> ------------------------------------------------------------ >>>>>>>> ---------------- >>>>>>>> >>>>>>>> <handlers> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> <handler class="org.wso2.carbon.apimgt. >>>>>>>> gateway.handlers.security.APIAuthenticationHandler"> >>>>>>>> >>>>>>>> <property name="customOAuthHeader" value="ENG_Auth"/> >>>>>>>> >>>>>>>> <property name="RemoveOAuthHeadersFromOutMessage" value="true"/> >>>>>>>> >>>>>>>> </handler> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> </handlers> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Viduranga. >>>>>>>> >>>>>>>> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This design looks good. Please send a sample of the synapse config >>>>>>>>> (only the portion that gets modified) so that users get a good >>>>>>>>> picture of >>>>>>>>> how this is supposed to be injected to the Gateway handler. >>>>>>>>> >>>>>>>>> On Mon, Nov 27, 2017 at 10:43 AM, Viduranga Gunarathne < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> APIs in APIM 2.1.0 are secured with OAuth2 access tokens. In >>>>>>>>>> order to access an API, the consumers should generate an access >>>>>>>>>> token and >>>>>>>>>> the particular request should contain the generated token as an HTTP >>>>>>>>>> header. >>>>>>>>>> >>>>>>>>>> *Eg: "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a"* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Problems:* >>>>>>>>>> >>>>>>>>>> i) As per the current implementation of API-M 2.1.0 the structure >>>>>>>>>> of the access token is as above and the header field is hard coded >>>>>>>>>> to be >>>>>>>>>> *"Authorization"*. When the Gateway receives a request to access >>>>>>>>>> a resource, it looks for the access token by referring to the >>>>>>>>>> header field "Authorization". The proposed implementation is to >>>>>>>>>> give each >>>>>>>>>> and every tenant in the system, the capability to have a, "per >>>>>>>>>> tenant" >>>>>>>>>> based customized authorization header field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Eg: >>>>>>>>>> >>>>>>>>>> Tenant 1 : hr.lk --> "HR_Auth : Bearer >>>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>>> >>>>>>>>>> Tenant 2 : eng.lk --> "ENG_Auth : Bearer >>>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NB: This feature also supports the current implementation of >>>>>>>>>> "Authorization" as the header field, so that it doesn't affect the >>>>>>>>>> existing >>>>>>>>>> API-Ms in production. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ii) In API-M 2.1.0 there is a feature to restrict the access >>>>>>>>>> token, that is being sent in the request, to be passed through to the >>>>>>>>>> production endpoint from the Gateway. The configuration relevant to >>>>>>>>>> this is >>>>>>>>>> in the "api-manager.xml" and it is as follows; >>>>>>>>>> >>>>>>>>>> * >>>>>>>>>> <RemoveOAuthHeadersFromOutMessage>true</RemoveOAuthHeadersFromOutMessage>* >>>>>>>>>> >>>>>>>>>> If the value is set to *true *then the Gateway will not pass >>>>>>>>>> the access token to the back end and if it's *false*, then it >>>>>>>>>> will. Since this configuration resides in the *"api-manager.xml"*, >>>>>>>>>> it applies in a "per server" basis. The proposal is to migrate it to >>>>>>>>>> the *"tenant-conf.json" >>>>>>>>>> *so that this configuration can be applied in a "per >>>>>>>>>> tenant" basis. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Solutions:* >>>>>>>>>> The design of the proposed solutions for the two problems are as >>>>>>>>>> follows: >>>>>>>>>> >>>>>>>>>> i) Proposed workflow for custom header field: >>>>>>>>>> >>>>>>>>>> a) Read a configuration from the "tenant-conf.json" for a >>>>>>>>>> customized OAuth2 header field. >>>>>>>>>> b) Insert the config into the synapse config file that is >>>>>>>>>> generated once an API is published, so that it gets deployed in the >>>>>>>>>> Gateway. >>>>>>>>>> c) Use the custom header when checking the access token from >>>>>>>>>> "APIAuthenticationHandler" for authentication. >>>>>>>>>> >>>>>>>>>> d) If no configuration exists in the "tenant-conf.json", then >>>>>>>>>> check for a config in "api-manager.xml" and follow step (b) and (c). >>>>>>>>>> This >>>>>>>>>> config will act as global config for the server. >>>>>>>>>> >>>>>>>>>> e) If no configuraton exists in the api-manager.xml then the >>>>>>>>>> existing workflow will execute using the "Authorization" header >>>>>>>>>> field. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ii) Proposed workflow for restricting the access token from being >>>>>>>>>> passed to the backend. >>>>>>>>>> >>>>>>>>>> a) Read the "RemoveOAuthHeadersFromOutMessage" config from the >>>>>>>>>> "tenant-conf.json" >>>>>>>>>> >>>>>>>>>> b) If no config exists in tenant-conf.json, then read it from the >>>>>>>>>> "api-manager.xml" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any ideas and suggestions are highly appreciated! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Viduranga. >>>>>>>>>> >>>>>>>>>> [1] https://docs.wso2.com/display/AM210/Working+with+Access+ >>>>>>>>>> Tokens >>>>>>>>>> -- >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>> >>>>>>>>>> *Software Engineer Intern* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *WSO2* >>>>>>>>>> Email : [email protected] >>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>> Web : http://wso2.com >>>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : [email protected] >>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> *Viduranga Gunarathne* >>>>>>>> >>>>>>>> *Software Engineer Intern* >>>>>>>> >>>>>>>> >>>>>>>> *WSO2* >>>>>>>> Email : [email protected] >>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>> Web : http://wso2.com >>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dinusha Dissanayake >>>>>>> Software Engineer >>>>>>> WSO2 Inc >>>>>>> Mobile: +94712939439 <+94%2071%20293%209439> >>>>>>> <https://wso2.com/signature> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> *Viduranga Gunarathne* >>>>>> >>>>>> *Software Engineer Intern* >>>>>> >>>>>> >>>>>> *WSO2* >>>>>> Email : [email protected] >>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>> Web : http://wso2.com >>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Chamin Dias >>>>> Mobile : 0716097455 <071%20609%207455> >>>>> Email : [email protected] >>>>> LinkedIn : https://www.linkedin.com/in/chamindias >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Chamalee De Silva* >>> Software Engineer >>> *WS**O2* Inc. :http://wso2.com/ >>> >>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>> >>> >> >> >> -- >> Regards, >> >> *Viduranga Gunarathne* >> >> *Software Engineer Intern* >> >> >> *WSO2* >> Email : [email protected] >> Mobile : +94712437484 <+94%2071%20243%207484> >> Web : http://wso2.com >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Kishanthan Thangarajah* > Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 <+94%2077%20342%206635> > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Dulanja Liyanage Lead, Platform Security Team WSO2 Inc.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
