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