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