Correction, found the docs https://docs.wso2.com/display/AM250/Securing+APIs. Thanks for pointing it out Viduranga
On 19 September 2018 at 11:36, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > I cant find any documentation for this feature, has this been documented? > > > Without documentation the visibility of this feature is lost > > On 14 December 2017 at 13:49, Viduranga Gunarathne <vidura...@wso2.com> > wrote: > >> Hi, >> >> As of now this feature is being improved to support custom authorization >> headers in a "per API" basis. >> >> The proposed design for this is as follows. >> >> >> - A new attribute will be added to the API named "customOAuth2Header" >> [String]. This value will be saved to registry under the specific API when >> creating the API. >> - When the API is published, a custom authorization header will be >> checked in the following resources in the specified order. >> 1. Registry where the API is saved. >> 2. tenant-conf.json of the current tenant >> 3. api-manager.xml >> - If a custom header is *NOT* *AVAILABLE* in any of the above >> resources, then the default "Authorization" authorization header would >> work. >> - If a custom header is* AVAILABLE*, then that value will be added to >> the synapse config of the specific API and will be published in the >> Gateway. >> >> *Note:* >> >> 1. If a user has configured a custom authorization header, when >> creating an API (per API header) or in the tenant-conf.json (per tenant >> header) then he/she will have to re publish the APIs in order for the >> changes to make effect. >> >> The issue faced with this implementation is that the so defined custom >> authorization header is not allowed to be passed since it is not among the >> list of allowed headers. Hence the proposed solution to this is to add a >> "customOAuth2Header" property to the CORSRequestHandler so that it can be >> appended to the list of allowed headers when this handler is executed. >> >> The implementation will be as follows: >> >> Sample synapse config of an API: >> >> <handlers> >> >> ... >> >> <handler class="org.wso2.carbon.apimgt. >> gateway.handlers.security.CORSRequestHandler"> <property name= >> "customOAuth2Header" value="ENG_Auth"/> >> >> <property name="apiImplementationType" value="ENDPOINT"/> >> >> </handler> >> >> <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.APIA >> uthenticationHandler"> >> >> <property name="customOAuth2Header" value="ENG_Auth"/> >> >> <property name="RemoveOAuthHeadersFromOutMessage" value="true"/> >> >> </handler> >> >> ... >> >> </handlers> >> >> >> This implementation will overcome the requirement to enable API based >> CORS configuration and adding the custom header to the list of allowed >> headers. >> >> Ideas and suggestions are highly appreciated! >> >> Thanks, >> Viduranga. >> >> On Thu, Dec 14, 2017 at 11:57 AM, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> Hi all, >>> >>> We are not mandating the change of the 'Authorization' header. That will >>> be the header we support by default. >>> >>> The problem here is, when users adopt API Management to proxy >>> APIs/Services that are already secured using the Authorization header, they >>> hit a roadblock because the API Gateway also now requires an Authorization >>> header. There have also been cases where client apps already use different >>> (non-standard) headers for the same purpose (not everybody adheres to >>> specs). As an API Management vendor its impractical for us to ask users to >>> fix and redistribute their client Apps if they are to use our Gateway. They >>> would simply pick a competitor product that can do that easily. These are >>> some of the reasons we need to support this as a feature, but of course >>> default to standard. >>> >>> Thanks, >>> NuwanD. >>> >>> On Thu, Dec 14, 2017 at 6:48 AM, Viduranga Gunarathne < >>> vidura...@wso2.com> wrote: >>> >>>> Hi Saneth, >>>> >>>> Thanks for your views. One important reason to implement this is that >>>> this feature has been requested, so that the above mentioned requirements >>>> can be met. >>>> >>>> Thanks, >>>> Viduranga. >>>> >>>> On Tue, Dec 12, 2017 at 11:10 AM, Saneth Dharmakeerthi < >>>> sane...@wso2.com> wrote: >>>> >>>>> Hi Viduranga, >>>>> >>>>> Sorry for late reply, please find my view bellow >>>>> >>>>> 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. >>>>> >>>>> In this type of a scenario, both the API-M and the back end requires >>>>> authorization tokens and the header field would be "Authorization" for >>>>> both. This would make a confusion and also since API-M provides a >>>>> configuration to stop the authorization header from being sent to the back >>>>> end (RemoveOAuthheadersFromOutMessage) then if that config is set to >>>>> true, then the value that comes under the header field "Authorization" >>>>> would not get transferred to the back end. >>>>> >>>>> >>>>> Here I also agreed with Kishanthan, IMO changing the header name is >>>>> seems to be out of spec, So main issue here is both parties client -> >>>>> APIM and APIM-> Backend need to communicate with header " >>>>> Authorization", >>>>> So cant we keep the header option "Authorization" >>>>> in-between client->APIM as it is and we can pass some other header like >>>>> "Back-End-Authorization" in addition to "Authorization" header. So >>>>> in APIM, it will do the authorization using "Authorization" header >>>>> and then switch the "Back-End-Authorization" to "Authorization" >>>>> and send it backend. So both client -> APIM and APIM-> Backend will >>>>> do their authorization using "Authorization" header. Even if back-end >>>>> required the token in some other format we can sitch it to the required >>>>> type, but IMO we need to keep the "Authorization" header >>>>> between Client->APIM as it is. >>>>> >>>>> 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 authorization 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. >>>>> >>>>> I do not agree with here. Client app and Backend may communicate with >>>>> some other token but, After introducing APIM they cant use the same token >>>>> to communicate with APIM. If they can use the same token I don't see any >>>>> point introducing APIM between them. Even you keep the header as it is >>>>> like "TOKEN", "KEY", the token generation part need to implement in >>>>> the client side according to APIM or even hard cored the client >>>>> credential >>>>> token in the clinet side. SO anyhow client modification is there. >>>>> iii) In the APIM cloud, each tenant will be able to define their own >>>>> authorization header field. >>>>> >>>>> Also, this implementation, by default already supports the prevailing >>>>> "Authorization" header field. So, if a client doesn't do any >>>>> configurations, he/she can use the system without any issue as before. If >>>>> a >>>>> client wants to configure custom header field ti support any scenario, he >>>>> will have to make the necessary configurations. >>>>> >>>>> This may be a valid requirement but I have doubt there is an available >>>>> option to change the header name other than "*Authorization*" >>>>> according to spec [1][2] >>>>> >>>>> [1] https://tools.ietf.org/html/rfc6749#section-4.1.1 >>>>> [2] https://tools.ietf.org/html/rfc6750#section-2.1 >>>>> >>>>> >>>>> Thanks and Best Regards, >>>>> >>>>> Saneth Dharmakeerthi >>>>> *Associate Technical Lead* >>>>> WSO2, Inc. >>>>> Mobile: +94772325511 <+94%2077%20232%205511> >>>>> >>>>> <http://wso2.com/signature> >>>>> >>>>> On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne < >>>>> vidura...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is a quick update to the current implementation of this feature. >>>>>> >>>>>> Image 1 & 2 shows how the "CustomOAuth2header" and the >>>>>> "RemoveHeadersFromOutMessage" configs are setup in the tenant-conf.xml >>>>>> and >>>>>> the api-manager.xml. The custom header config in the api-manager.xml is a >>>>>> global configuration and it will only be applied if there is no config >>>>>> available in the tenant-conf.json (per tenant config). And if both >>>>>> configs >>>>>> in tenant-conf.json and the api-manager.xml are not available, then the >>>>>> "Authorization" header would work. >>>>>> >>>>>> Image 3 shows how the "API Console" in the APIM Store looks like once >>>>>> the custom header fields are configured. This header will change based on >>>>>> the tenant of the API. >>>>>> >>>>>> *Note:* However a complication occurred with this implementation. >>>>>> The web browser will not allow the custom header to be passed along with >>>>>> the request. Hence the custom header has to be added to the list of >>>>>> allowed >>>>>> headers. >>>>>> >>>>>> In addition to that, it was discussed to improve this feature to have >>>>>> custom OAuth header at the API level. Hence an API creator has the >>>>>> capability to create custom OAuth2 headers specific to each API. >>>>>> >>>>>> The current design for this improvement is to add another field to >>>>>> the "api.rxt" there by adding another field to the API model, so that the >>>>>> API creator can set a custom OAuth2 header while creating an API in the >>>>>> API-M Publisher. >>>>>> >>>>>> Once the API is published, this custom OAuth2 header will be saved to >>>>>> the registry under the API and will be deployed to the Gateway through >>>>>> the >>>>>> synapse-config. >>>>>> ============================================================ >>>>>> =============== >>>>>> Image 1: >>>>>> tenant-conf.json >>>>>> [image: Inline image 1] >>>>>> ============================================================ >>>>>> =============== >>>>>> Image 2: >>>>>> api-manager.xml >>>>>> [image: Inline image 3] >>>>>> ============================================================ >>>>>> =============== >>>>>> Image 3: >>>>>> API-M Store >>>>>> >>>>>> >>>>>> ============================================================ >>>>>> =============== >>>>>> >>>>>> Any ideas and suggestions are highly appreciated! >>>>>> >>>>>> Thanks, >>>>>> Viduranga. >>>>>> >>>>>> On Thu, Dec 7, 2017 at 8:59 AM, Viduranga Gunarathne < >>>>>> vidura...@wso2.com> wrote: >>>>>> >>>>>>> Hi Kishanthan. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> In this type of a scenario, both the API-M and the back end requires >>>>>>> authorization tokens and the header field would be "Authorization" for >>>>>>> both. This would make a confusion and also since API-M provides a >>>>>>> configuration to stop the authorization header from being sent to the >>>>>>> back >>>>>>> end (RemoveOAuthheadersFromOutMessage) then if that config is set >>>>>>> to true, then the value that comes under the header field >>>>>>> "Authorization" >>>>>>> would not get transferred to the back end. >>>>>>> >>>>>>> >>>>>>> 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 authorization 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. >>>>>>> >>>>>>> Also this implementation, by default already supports the prevailing >>>>>>> "Authorization" header field. So, if a client doesn't do any >>>>>>> configurations, he/she can use the system without any issue as before. >>>>>>> If a >>>>>>> client wants to configure custom header field ti support any scenario, >>>>>>> he >>>>>>> will have to make the necessary configurations. >>>>>>> >>>>>>> Thanks, >>>>>>> Viduranga. >>>>>>> >>>>>>> On Tue, Dec 5, 2017 at 3:48 PM, Kishanthan Thangarajah < >>>>>>> kishant...@wso2.com> wrote: >>>>>>> >>>>>>>> The header name "Authorization" is what commonly used by all the >>>>>>>> clients/proxies. So we defining our own way for the "header name" is >>>>>>>> what >>>>>>>> my concern is. If we define such customized name, will the external >>>>>>>> clients >>>>>>>> adhere to that? >>>>>>>> >>>>>>>> The spec says that the common format used is Authorization = >>>>>>>> <credentials> [1] >>>>>>>> >>>>>>>> So shouldn't we use a customized way or scheme for the >>>>>>>> <credentials> part only, to identify tenant specific tokens (which is >>>>>>>> the >>>>>>>> requirement for $subject), but not change the header name itself? >>>>>>>> >>>>>>>> Some discussions related to this in SO - >>>>>>>> https://stackoverflow.com/questions/42574022/custom-authoriz >>>>>>>> ation-header >>>>>>>> https://stackoverflow.com/questions/8463809/customize-the-au >>>>>>>> thorization-http-header >>>>>>>> >>>>>>>> Thanks, >>>>>>>> [1] https://tools.ietf.org/html/rfc7235#section-4.2 >>>>>>>> >>>>>>>> On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <dula...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> "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 < >>>>>>>>> kishant...@wso2.com> 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 < >>>>>>>>>> vidura...@wso2.com> 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 < >>>>>>>>>>> chama...@wso2.com> 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 < >>>>>>>>>>>> prasa...@wso2.com> 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 <cham...@wso2.com >>>>>>>>>>>>> > 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 < >>>>>>>>>>>>>> vidura...@wso2.com> 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 < >>>>>>>>>>>>>>> dinus...@wso2.com> 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 < >>>>>>>>>>>>>>>> vidura...@wso2.com> 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 < >>>>>>>>>>>>>>>>> nuw...@wso2.com> 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 < >>>>>>>>>>>>>>>>>> vidura...@wso2.com> 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/disp >>>>>>>>>>>>>>>>>>> lay/AM210/Working+with+Access+Tokens >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Software Engineer Intern* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *WSO2* >>>>>>>>>>>>>>>>>>> Email : vidura...@wso2.com >>>>>>>>>>>>>>>>>>> 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 : nuw...@wso2.com >>>>>>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Viduranga Gunarathne* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Software Engineer Intern* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *WSO2* >>>>>>>>>>>>>>>>> Email : vidura...@wso2.com >>>>>>>>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>>>>>> 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 : vidura...@wso2.com >>>>>>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Chamin Dias >>>>>>>>>>>>>> Mobile : 0716097455 <071%20609%207455> >>>>>>>>>>>>>> Email : cham...@wso2.com >>>>>>>>>>>>>> LinkedIn : https://www.linkedin.com/in/chamindias >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>> 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 : vidura...@wso2.com >>>>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>>>> Web : http://wso2.com >>>>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>> 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 >>>>>>>>>> Architecture@wso2.org >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks & Regards, >>>>>>>>> Dulanja Liyanage >>>>>>>>> Lead, Platform Security Team >>>>>>>>> WSO2 Inc. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> Architecture@wso2.org >>>>>>>>> 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 >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> *Viduranga Gunarathne* >>>>>>> >>>>>>> *Software Engineer Intern* >>>>>>> >>>>>>> >>>>>>> *WSO2* >>>>>>> Email : vidura...@wso2.com >>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>> Web : http://wso2.com >>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> *Viduranga Gunarathne* >>>>>> >>>>>> *Software Engineer Intern* >>>>>> >>>>>> >>>>>> *WSO2* >>>>>> Email : vidura...@wso2.com >>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>> Web : http://wso2.com >>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> *Viduranga Gunarathne* >>>> >>>> *Software Engineer Intern* >>>> >>>> >>>> *WSO2* >>>> Email : vidura...@wso2.com >>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>> Web : http://wso2.com >>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> >> *Viduranga Gunarathne* >> >> *Software Engineer Intern* >> >> >> *WSO2* >> Email : vidura...@wso2.com >> Mobile : +94712437484 <+94%2071%20243%207484> >> Web : http://wso2.com >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 777733962 > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
