What are the advantages of having to select auth modes for GW toolkit? Would an approach where both are supported at the same time without basicAuth-only or oAuth-only modes be easier? Is that going to add more unwanted dependencies?
The concern is, if during a deployment the auth scheme is changed, would that force rebuilding the GWs, if during the initial designing process the wrong scheme is selected? *Chamila de Alwis* | Associate Technical Lead | WSO2 Inc. (m) +94 77 220 7163 | (e) [email protected] [image: Get Integration Agile] <https://wso2.com/signature> On Mon, Nov 19, 2018 at 11:55 AM Chamindu Udakara <[email protected]> wrote: > Hi All, > > My project is to add basic authentication for micro-gateway.This is the > approach that I have been come up with. Please review and let me know what > you think. > > Requirement > > Provide authentication for product micro-gateway with basic authentication > which uses usernames and passwords for authentication. > > Approach > > > The ballerina source of the current micro-gateway is generated only for > supporting OAuth2.0. We will introduce a new system property as “security” > which can be configured at 'setup' command as “ > -Dsecurity=”values_of_securitySchemas”” to make the micro-gateway work > based on basic authentication and as well as work with OAuth 2.0. When > this command is provided, the ballerina source will be generated to support > following user stories based on what are the values user is provided. > > 1. > > BasicAuth only - User has to provide the system property value as “ > -Dsecurity=”basic”” and then the micro-gateway will only support for > the basic authentication and it won’t support OAuth2 or JWT token based > Authentication. > 2. > > BasicAuth and OAuth2 token based at same time - User has to provide > the both schemas as “-Dsecurity=”oauth2, basic””. To separate the > schemas user has to use “,” s. Then micro-gateway will support both > authentications schemas. If user sends both headers with request then the > first header with token will be given the prominence. > 3. > > OAuth2 Authentication Only (Default mode) - Either user has to provide > the schema as “-Dsecurity=”oauth2”” or not provide any schema > explicitly. In this scenario micro-gateway will only support for OAuth2 > authentication and it will not support basic authentication. > > > This authentication modes handling can be done in SetupCmd.java file by > adding following function to set security schemas for micro-gateway. > > public void setSecuritySchemas(String schemas){ > > .... > > .... > > .... > > .... > > } > > > Then at “listeners.mustache” file, it has to check whether this isOptional > and isRequired boolean values at “BasicAuth.java” class which has to be > created under “Config.java” . Based on that value the source generation > will be changed as follows at “listeners.mustache” file. > > > > {{#if config.basicAuth.isOptional}} > > {{>basicAuthOptional}} > > {{else if config.basicAuth.isRequired}} > > {{>basicAuthRequired}} > > {{else}} > > {{>oAuthRequired}} > > {{/if}} > > Then to validate and to set information which is needed for Analytics can > be done in following way. > > Create a new filter called “BasicAuthenticationFilter.bal” and do the > validation and value settings for analytics inside the filter. Include this > filter by default to the filter chain and if “AUTH_HEADER” is “basic” > then request will process through this “BasicAuthenticationFilter” and > skip the “AuthnticationFilter” which requires OAuth2 tokens for > authentication. By using this design, this feature can provide support for > basic authentication and OAuth2 based authentication at the same time and > to only support for basic authentication only. > > By using any of above designs validation and providing analytics data > can be performed. After enabling this user has to manually provide > usernames and passwords which are authorized. Those usernames and passwords > should be added into “micro-gw.conf” file which is using when > micro-gateway is running in local machines or in docker after convert those > sensitive values into hash values. > > To invoke the API user has to send the curl request with username and > password as follows. > > curl -k -X GET "https://localhost:9095/test/v1.0/"; -H "accept: > application/json" -H "Authorization: Basic $(echo -n USERNAME:PASSWORD | > base64)" > > > > -- > *Chamindu Udakara * > *Software engineering Intern* > WSO2 (University of Moratuwa) > *mobile *: *+94 755285531* | *email *: [email protected] > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
