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
