Hi Viduranga,
Just to make it clarify, do we have to enter CustomOAuth2Header field
manually after creating a tenant or will it be automatically added when we
create a tenant?
Thanks,
DinushaD.
On Mon, Nov 27, 2017 at 11:41 AM, Viduranga Gunarathne <vidura...@wso2.com>
wrote:
> Hi,
>
> Attached below is a sample tenant-conf.json and synapse config featuring
> the proposed implementation.
>
> Config in tenant-conf.json
> ------------------------------------------------------------
> ------------------------------------------------------------
> ----------------
>
> {
> ...
> "CustomOAuth2Header" : "ENG_Auth",
>
> "RemoveOAuthHeadersFromOutMessage" : true
> ...
> }
>
>
> Config injected into synapse config file:
> ------------------------------------------------------------
> ------------------------------------------------------------
> ----------------
>
> <handlers>
>
> ...
>
> <handler class="org.wso2.carbon.apimgt.gateway.handlers.security.APIA
> uthenticationHandler">
>
> <property name="customOAuthHeader" value="ENG_Auth"/>
>
> <property name="RemoveOAuthHeadersFromOutMessage" value="true"/>
>
> </handler>
>
> ...
>
> </handlers>
>
> Thanks,
> Viduranga.
>
> On Mon, Nov 27, 2017 at 10:58 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>
>> This design looks good. Please send a sample of the synapse config (only
>> the portion that gets modified) so that users get a good picture of how
>> this is supposed to be injected to the Gateway handler.
>>
>> On Mon, Nov 27, 2017 at 10:43 AM, Viduranga Gunarathne <
>> vidura...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> APIs in APIM 2.1.0 are secured with OAuth2 access tokens. In order to
>>> access an API, the consumers should generate an access token and the
>>> particular request should contain the generated token as an HTTP header.
>>>
>>> *Eg: "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a"*
>>>
>>>
>>> *Problems:*
>>>
>>> i) As per the current implementation of API-M 2.1.0 the structure of the
>>> access token is as above and the header field is hard coded to be
>>> *"Authorization"*. When the Gateway receives a request to access a
>>> resource, it looks for the access token by referring to the
>>> header field "Authorization". The proposed implementation is to give each
>>> and every tenant in the system, the capability to have a, "per tenant"
>>> based customized authorization header field.
>>>
>>>
>>> Eg:
>>>
>>> Tenant 1 : hr.lk --> "HR_Auth : Bearer
>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a"
>>>
>>> Tenant 2 : eng.lk --> "ENG_Auth : Bearer
>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a"
>>>
>>>
>>> NB: This feature also supports the current implementation of
>>> "Authorization" as the header field, so that it doesn't affect the existing
>>> API-Ms in production.
>>>
>>>
>>> ii) In API-M 2.1.0 there is a feature to restrict the access token, that
>>> is being sent in the request, to be passed through to the production
>>> endpoint from the Gateway. The configuration relevant to this is in the
>>> "api-manager.xml" and it is as follows;
>>>
>>> *
>>> <RemoveOAuthHeadersFromOutMessage>true</RemoveOAuthHeadersFromOutMessage>*
>>>
>>> If the value is set to *true *then the Gateway will not pass the
>>> access token to the back end and if it's *false*, then it will. Since
>>> this configuration resides in the *"api-manager.xml"*, it applies in a
>>> "per server" basis. The proposal is to migrate it to the *"tenant-conf.json"
>>> *so that this configuration can be applied in a "per tenant"
>>> basis.
>>>
>>>
>>>
>>> *Solutions:*
>>> The design of the proposed solutions for the two problems are as follows:
>>>
>>> i) Proposed workflow for custom header field:
>>>
>>> a) Read a configuration from the "tenant-conf.json" for a customized
>>> OAuth2 header field.
>>> b) Insert the config into the synapse config file that is generated once
>>> an API is published, so that it gets deployed in the Gateway.
>>> c) Use the custom header when checking the access token from
>>> "APIAuthenticationHandler" for authentication.
>>>
>>> d) If no configuration exists in the "tenant-conf.json", then check for
>>> a config in "api-manager.xml" and follow step (b) and (c). This config will
>>> act as global config for the server.
>>>
>>> e) If no configuraton exists in the api-manager.xml then the existing
>>> workflow will execute using the "Authorization" header field.
>>>
>>>
>>> ii) Proposed workflow for restricting the access token from being passed
>>> to the backend.
>>>
>>> a) Read the "RemoveOAuthHeadersFromOutMessage" config from the
>>> "tenant-conf.json"
>>>
>>> b) If no config exists in tenant-conf.json, then read it from the
>>> "api-manager.xml"
>>>
>>>
>>> Any ideas and suggestions are highly appreciated!
>>>
>>> Thanks,
>>> Viduranga.
>>>
>>> [1] https://docs.wso2.com/display/AM210/Working+with+Access+Tokens
>>> --
>>> Regards,
>>>
>>> *Viduranga Gunarathne*
>>>
>>> *Software Engineer Intern*
>>>
>>>
>>> *WSO2*
>>> Email : vidura...@wso2.com
>>> Mobile : +94712437484 <+94%2071%20243%207484>
>>> Web : http://wso2.com
>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
>
> --
> Regards,
>
> *Viduranga Gunarathne*
>
> *Software Engineer Intern*
>
>
> *WSO2*
> Email : vidura...@wso2.com
> Mobile : +94712437484 <+94%2071%20243%207484>
> Web : http://wso2.com
> [image: https://wso2.com/signature] <https://wso2.com/signature>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dinusha Dissanayake
Software Engineer
WSO2 Inc
Mobile: +94712939439 <+94%2071%20293%209439>
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
