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

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[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;
    <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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : +94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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:
----------------------------------------------------------------------------------------------------------------------------------------

  <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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : +94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : +94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Prasanna Dangalla
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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Chamalee De Silva
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Kishanthan Thangarajah-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Kishanthan Thangarajah-2
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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : +94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Viduranga Gunarathne
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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : +94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Saneth Dharmakeerthi
 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: +94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]> 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: <a href="tel:+94%2077%20232%205511" value="+94772325511" target="_blank">+94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Nuwan Dias
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 <[hidden email]> 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 <[hidden email]> 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: <a href="tel:+94%2077%20232%205511" value="+94772325511" target="_blank">+94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [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:

  <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.APIAuthenticationHandler">

        <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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: <a href="tel:+94%2077%20232%205511" value="+94772325511" target="_blank">+94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Uvindra Dias Jayasinha
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 <[hidden email]> 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.APIAuthenticationHandler">

        <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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: <a href="tel:+94%2077%20232%205511" value="+94772325511" target="_blank">+94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Uvindra

Mobile: 777733962

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

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

Viduranga Gunarathne
Hi,

Please find the documentation for the feature mentioned below.

Thanks,
Viduranga.

On Wed, Sep 19, 2018 at 11:39 AM Uvindra Dias Jayasinha <[hidden email]> 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 <[hidden email]> 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.APIAuthenticationHandler">

        <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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks and Best Regards,

Saneth Dharmakeerthi
Associate Technical Lead
WSO2, Inc.
Mobile: <a href="tel:+94%2077%20232%205511" value="+94772325511" target="_blank">+94772325511



On Mon, Dec 11, 2017 at 1:40 PM, Viduranga Gunarathne <[hidden email]> 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
Inline image 1
===========================================================================
Image 2:
api-manager.xml
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 <[hidden email]> 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 <[hidden email]> 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 - 

Thanks,

On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <[hidden email]> 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.


On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Viduranga,

Small clarification, does this have any impact for caching?

Thanks.

On Mon, Nov 27, 2017 at 1:34 PM, Viduranga Gunarathne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Dinusha Dissanayake
Software Engineer
WSO2 Inc 
Mobile: <a href="tel:+94%2071%20293%209439" value="+94712939439" target="_blank">+94712939439




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : <a href="tel:071%20609%207455" value="+94716097455" target="_blank">0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Kishanthan Thangarajah
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - <a href="tel:+94%2077%20342%206635" value="+94773426635" target="_blank">+94773426635

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature



--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Viduranga Gunarathne
Software Engineer Intern
WSO2

Email : [hidden email]
Mobile : <a href="tel:+94%2071%20243%207484" value="+94712437484" target="_blank">+94712437484
Web : http://wso2.com
https://wso2.com/signature

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,
Uvindra

Mobile: 777733962
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Regards,
Viduranga Gunarathne
Software Engineer
WSO2 (Pvt) Ltd.

Mobile : +94712437484
Email   : [hidden email]
Web     : http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
12