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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
