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 <[email protected]> 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 <[email protected]> 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 <[email protected] >> > 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 <[email protected] >>> > 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [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/disp >>>>>>>>>>>>>>>>>> lay/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 <071%20609%207455> >>>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> Dulanja Liyanage >>>>>>>> Lead, Platform Security Team >>>>>>>> WSO2 Inc. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 <+94%2077%20777%205729> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > 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 > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
