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