Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Uvindra Dias Jayasinha]

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 
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 
> 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:
>>
>>   
>>
>>   ...
>>
>>   > "customOAuth2Header" value="ENG_Auth"/>
>>
>> 
>>
>> 
>>
>> 
>>
>> 
>>
>> 
>>
>>  
>>
>>   ...
>>
>>   
>>
>>
>> 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  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 ->
> 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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:

  

  ...

  











 

  ...

  


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  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 
> 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 
>> 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 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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 
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>
>
> 
>
> On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne 
> 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, 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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 
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 =
>  [1]
>
> So shouldn't we use a customized way or scheme for the  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-authorization-header
> https://stackoverflow.com/questions/8463809/customize-
> the-authorization-http-header
>
> Thanks,
> [1] https://tools.ietf.org/html/rfc7235#section-4.2
>
> On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage  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 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Kishanthan Thangarajah]

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 = 
[1]

So shouldn't we use a customized way or scheme for the  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-authorization-header
https://stackoverflow.com/questions/8463809/customize-the-authorization-http-header

Thanks,
[1] https://tools.ietf.org/html/rfc7235#section-4.2

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage  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 
>>> 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 
 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  wrote:
>
>> Hi Viduranga,
>>

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Dulanja Liyanage]

"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  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  > 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 
>> 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 
>>> 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  wrote:

> Hi Viduranga,
>
> Small clarification, does this have any impact for 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 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Kishanthan Thangarajah]

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 
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 
> 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 
>> 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  wrote:
>>>
 Hi Viduranga,

 Small clarification, does this have any impact for 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
>>> 
>>> 
>>> 
>>>
>>> {
>>>  ...
>>>  

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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 
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 
> 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  wrote:
>>
>>> Hi Viduranga,
>>>
>>> Small clarification, does this have any impact for 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:
>> 
>> 
>> 
>>
>>   
>>
>>   ...
>>
>>  
>>
>> 
>>
>> 
>>
>>  
>>
>> 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Chamin Dias]

Hi Viduranga,

Small clarification, does this have any impact for caching
?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne 
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 
> 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:
>>> 
>>> 
>>> 
>>>
>>>   
>>>
>>>   ...
>>>
>>>  
>>>
>>> 
>>>
>>> 
>>>
>>>  
>>>
>>>   ...
>>>
>>>   
>>>
>>> Thanks,
>>> Viduranga.
>>>
>>> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias  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;
>
> *
> true*
>
> 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 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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 
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  > 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:
>> 
>> 
>> 
>>
>>   
>>
>>   ...
>>
>>  
>>
>> 
>>
>> 
>>
>>  
>>
>>   ...
>>
>>   
>>
>> Thanks,
>> Viduranga.
>>
>> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias  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;

 *
 true*

 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 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Dinusha Dissanayake]

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 
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:
> 
> 
> 
>
>   
>
>   ...
>
>  
>
> 
>
> 
>
>  
>
>   ...
>
>   
>
> Thanks,
> Viduranga.
>
> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias  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;
>>>
>>> *
>>> true*
>>>
>>> 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 : vidura...@wso2.com
>>> Mobile : +94712437484 <+94%2071%20243%207484>
>>> Web : http://wso2.com
>>> [image: https://wso2.com/signature] 
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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:


  

  ...

 





 

  ...

  

Thanks,
Viduranga.

On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias  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  > 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;
>>
>> *
>> true*
>>
>> 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 : vidura...@wso2.com
>> Mobile : +94712437484 <+94%2071%20243%207484>
>> Web : http://wso2.com
>> [image: 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
Web : http://wso2.com
[image: https://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Nuwan Dias]

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 
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;
>
> *
> true*
>
> 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 : vidura...@wso2.com
> Mobile : +94712437484 <+94%2071%20243%207484>
> Web : http://wso2.com
> [image: https://wso2.com/signature] 
>



-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

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;

*
true*

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 : vidura...@wso2.com
Mobile : +94712437484
Web : http://wso2.com
[image: https://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture