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
