Re: [Architecture] Fwd: Certificate based Authentication for Micro-gateway

[Bhashinee Nirmali]

On Mon, Jan 7, 2019 at 8:59 AM Chamindu Udakara  wrote:

> Hi Bhashinee,
> Yeah it will help us to proceed with validation part in filters. And it
> will help to provide the optional support with mutual SSL feature,
>
Ack.

Thanks!

>
> Thanks
>
> On Sat, Jan 5, 2019 at 10:50 PM Bhashinee Nirmali 
> wrote:
>
>> Hi All,
>>
>> To identify whether the mutual SSL authentication has been done
>> successfully, will it be okay if we send a parameter in the request saying
>> it failed or not? So that we can continue with the filters depending on the
>> retrieved value of that parameter.
>>
>> Thanks,
>> Bhashinee
>>
>> On Sun, Oct 28, 2018 at 7:57 PM Chamindu Udakara 
>> wrote:
>>
>>> Sure, will do that akka. Thanks
>>>
>>> On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali 
>>> wrote:
>>>
 Hi Chamindu,

 Can you please initiate a mail thread in ballerina-...@googlegroups.com
 mentioning the improvements that you need to come from ballerina side in
 order to continue this? So that we can discuss how feasible to provide
 these improvements with the ballerina team.

 Thanks,
 Bhashinee

 On Tue, Oct 23, 2018 at 12:44 PM Bhashinee Nirmali 
 wrote:

> Hi Rajith,
>
> As of now, Ballerina doesn't support setting mutual SSL to 'optional'.
> It only supports the 'require' option. With that, it requires client
> certificate authentication. The connection will terminate if no suitable
> client certificate is presented. So currently there is no way of doing
> that. Better to create an issue to track this requirement.
>
> Hi Chamindu,
>
> If this is a valid requirement to set it to optional, we'll keep it in
> that way. As we do not support it from Ballerina now, let's keep that
> option disabled. So once the support is given from Ballerina, we can
> continue using that option as well.
>
> Thanks,
> Bhashinee
>
> On Mon, Oct 22, 2018 at 5:16 PM Chamindu Udakara 
> wrote:
>
>> Hi Bhashinee Akka,
>>
>> It was a mistake to put that parameter value as "optional" since we
>> are not providing optional support. I will change it as false or "not
>> required".
>>
>> Thank You
>>
>> On Mon, Oct 22, 2018 at 3:07 PM Bhashinee Nirmali 
>> wrote:
>>
>>> Hi Chamindu,
>>>
>>> On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara 
>>> wrote:
>>>



 Hi All,

 The project I have chosen is Certificate based authentication for
 micro gateway.

 *Problem*

-

Micro-gateway does not have certificate based authentication or
Mutual TLS establishment and micro-gateway can authenticate a 
 request using
OAuth2 token only. This is an overhead for trusted clients who are 
 using
this product because of the token generation and life cycle of 
 OAuth2
tokens.

 *Solution*

-

This project is carried out to overcome above limitation by
providing Mutual TLS (Certificate based authentication) to 
 micro-gateway.


 *Design *


 Configure mutualSSL feature at runtime level in configuration



 MutualSSL feature can be enabled for a micro-gateway after it was
 built by changing a property from “micro-gw.conf” file. There is a 
 property
 as “sslVerifyClient” in this “micro-gw.conf” file under “[mtslConfig]”
 Instance ID. By default this value is set to “false”.

 When this,

 sslVerifyClient = “false”

 property is shows as above the micro-gateway will function as
 previous by using OAuth or JWT tokens as authentication.

 To enable mutualSSL in a micro-gateway user has to change this
 “sslVerifyClient” as follows,

 sslVerifyClient = “require”

 and user has to change KeyStore path and KeyStore password in this
 “micro-gw.conf” file. These “keyStore.path” property and
 “keyStore.password” property under “[listenerConfig]” instance ID has 
 to be
 changed.

 By enabling this MutualSSL feature in micro-gateway
 authentication process is done in the transport layer and therefore 
 OAUth
 headers or JWT token will not be needed for requests from trusted 
 clients.
 If the mutualSSL is enable in the micro-gateway, 
 “Authentication_Filter”
 and “Authorization_Filter” will be skipped by newly introduces
 “Mutual_SSL_Filter”. And the details needed for throttling also append 
 by
 this “Mutual_SSL_Filter”. Then listener.bal file looks as 

Re: [Architecture] Auth0 OpenID Connector for IS

[Nirubikaa Ravikumar]

Hi all,
plese find the sample request and response.

*Authorization Code Grant Type*

request
https://testapp1996.auth0.com/authorize?audience=https://testapp1996.auth0.com/api/v2/=openid_type=code_id=kyq73nra4j5KSm6xg8hoqPltt12Q3UvQ_uri=https://www.google.lk=123

response
https://www.google.lk/?code=z2oK4XkLUAiACfeG=123

Authorization code : z2oK4XkLUAiACfeG


*get-Access token*

endpoint
https://testapp1996.auth0.com/oauth/token

payload
{
  "grant_type": "authorization_code",
  "client_id": "kyq73nra4j5KSm6xg8hoqPltt12Q3UvQ",
  "client_secret":
"PkyrWSBrqQB7TXJdpcTZ8RhqqL9EAZbG57a9Lzv9cOQuMv90cJwgOyAvtgHkhp1p",
  "code": "z2oK4XkLUAiACfeG",
  "redirect_uri": "https://www.google.lk;
}

response
{
"access_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5UZzROVFpEUlVSQlJUSTNNVEkxT1RSQ01FVTRNRFl4UkVVMlFqQXhRakkyUWtNMFJrRTRPQSJ9.eyJpc3MiOiJodHRwczovL3Rlc3RhcHAxOTk2LmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1YzBkZjA2ZmU5NzhjNTJlMTU0ZjFkMzUiLCJhdWQiOlsiaHR0cHM6Ly90ZXN0YXBwMTk5Ni5hdXRoMC5jb20vYXBpL3YyLyIsImh0dHBzOi8vdGVzdGFwcDE5OTYuYXV0aDAuY29tL3VzZXJpbmZvIl0sImlhdCI6MTU0NjgzNTk5NiwiZXhwIjoxNTQ2OTIyMzk2LCJhenAiOiJreXE3M25yYTRqNUtTbTZ4Zzhob3FQbHR0MTJRM1V2USIsInNjb3BlIjoib3BlbmlkIn0.tS_4FK-tscfvtLNR9i2CsgoNy6I8LWUbUgzSOHeb9X6NkNbN7fzuY2gOVcwz3P0sFdHB6yfe4epTUzNivWJCcuGq_vAaLCVcSz_2cTkMJOTo_3Te149iqclY82SVAcih3ydIH7pPGJnXkgXG7-PvrIIhOWSe_w-tUA92j6hr0-pjASbEpY_es8keT6xnsY979dKiW3kujmlwawjXdwj39WTBXXx05ZXdlrG8vtANqGj9fazkbhHGDhWVpGzStPX7fnouf_fzHUUhw8yixCvhit2L7xQXbY61TpS3-CfDyOjfFk77PYE5W5gd3AwIbqWBPoKajYcTp0lpPz73BV-8rQ",
"id_token":
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik5UZzROVFpEUlVSQlJUSTNNVEkxT1RSQ01FVTRNRFl4UkVVMlFqQXhRakkyUWtNMFJrRTRPQSJ9.eyJpc3MiOiJodHRwczovL3Rlc3RhcHAxOTk2LmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1YzBkZjA2ZmU5NzhjNTJlMTU0ZjFkMzUiLCJhdWQiOiJreXE3M25yYTRqNUtTbTZ4Zzhob3FQbHR0MTJRM1V2USIsImlhdCI6MTU0NjgzNTk5NiwiZXhwIjoxNTQ2ODcxOTk2LCJhY3IiOiJodHRwOi8vc2NoZW1hcy5vcGVuaWQubmV0L3BhcGUvcG9saWNpZXMvMjAwNy8wNi9tdWx0aS1mYWN0b3IiLCJhbXIiOlsibWZhIl19.gZnVMIBABNU_lYeKwEG6eGK51N21LOa6r3yyNmCp27jvMds3O9nDb1A3rvtW0LgeCb5k68xi94Lvi_Ui2wmXqyv2_-QixluK8QWWv1l-xAd5bYwRQbQV1bAIZZOxceS2e2Q10gIdPKQTLHkEGhkh7NYyzbSvnSwyTUTXhBn6-r-Wdx6fqZBbXKVo4a5SJTQnu9O_FQ7Wjy4naO2xHPi1L4xWFNwPQhv2p1nlUdpYusg4sy_w3j9V9mhw5qHo_q1GQ-hVoPpgJZ6kXYOCIVrqJ8yxM30PduN2tTOK9VD64P6UiAYlqBA5GLIdtD-7kS92mgiIuBRFIxp-3pwL7REMLA",
"expires_in": 86400,
"token_type": "Bearer"
}

Thanks

On Mon, Jan 7, 2019 at 3:16 PM Naduni Pamudika  wrote:

> Hi Nirubikaa,
>
> On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
> wrote:
>
>> Hi all,
>> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
>> diagram below:
>>
>> In the flow of OpenID Connect,
>>
>> User sends a request to service provider, then the request is redirected
>> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
>> client credentials, and Openid scope. Then the Auth0 redirects to the
>> request with Authorization code.
>>
>> For the Authorization code request, as I read we need to send only the
> client Id (not both the client id and the secret).
>
> Could you please provide sample requests and responses for the flow you
> explained here? It would help others understand OIDC using Auth0 easily.
>
> Thanks,
> Naduni
>
>> Then WSO2 IS requests Access token, to that Auth0 responses with the
>> Access token, An ID token is issued from the token endpoint in addition to
>> an Access token.
>>
>> WSO2 IS requests to get user info, And Auth0 can retrieve user
>> information from the ID token or Access token.
>>
>> Thanks.
>> --
>> R.Nirubikaa
>> Intern | WSO2
>> M: O779108852
>>
>>
>>
>
>
> --
> *Naduni Pamudika*
> Software Engineer | WSO2
>
> Mobile: +94 719 143658 <+94%2071%20914%203658>
> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
> Blog: https://medium.com/@naduni_pamudika
> [image: http://wso2.com/signature] 
>


-- 
R.Nirubikaa
Intern | WSO2
M: O779108852
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Farasath Ahamed]

Hi Nirubikaa,

Before we start implementing this connector can we try our generic OIDC
Federation connector[1] to talk to Auth0 and see if it works?
Ideally, if Auth0 is having a standard OIDC Endpoint then this should work
without any issues.

[1] https://docs.wso2.com/display/IS570/Configuring+OAuth2-OpenID+Connect

On Mon, Jan 7, 2019 at 2:53 PM Nirubikaa Ravikumar 
wrote:

> please find the image,
>
> On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
> wrote:
>
>> Hi all,
>> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
>> diagram below:
>>
>>
>>
>>
>> In the flow of OpenID Connect,
>>
>> User sends a request to service provider, then the request is redirected
>> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
>> client credentials, and Openid scope. Then the Auth0 redirects to the
>> request with Authorization code.
>>
>> Then WSO2 IS requests Access token, to that Auth0 responses with the
>> Access token, An ID token is issued from the token endpoint in addition to
>> an Access token.
>>
>> WSO2 IS requests to get user info, And Auth0 can retrieve user
>> information from the ID token or Access token.
>>
>> Thanks.
>> --
>> R.Nirubikaa
>> Intern | WSO2
>> M: O779108852
>>
>>
>>
>
>
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Naduni Pamudika]

Hi Nirubikaa,

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> For the Authorization code request, as I read we need to send only the
client Id (not both the client id and the secret).

Could you please provide sample requests and responses for the flow you
explained here? It would help others understand OIDC using Auth0 easily.

Thanks,
Naduni

> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
*Naduni Pamudika*
Software Engineer | WSO2

Mobile: +94 719 143658 <+94%2071%20914%203658>
LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
Blog: https://medium.com/@naduni_pamudika
[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Nirubikaa Ravikumar]

please find the image,

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
R.Nirubikaa
Intern | WSO2
M: O779108852
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cookie Based Authentication for Micro-gateway.

[Nuwan Dias]

The requirement to implement $subject is to enable client-side web
applications (Javascript driven SPAs) to use OAuth2 APIs easily. When an
SPA uses OAuth2 protected APIs, they are required to present a valid access
token. To do this these Applications need to execute some Javascript on the
client side (we browser) which reads an access token stored in some storage
and adds it as a header to the request initiated from the SPA (browser).

The problem here is that if a token is to be stored in a way that is
accessible by client side Javascript, the token becomes vulnerable to any
type of Javascript that runs on the domain of the particular web
application. Meaning that if the application becomes vulnerable to a cross
site scripting attack (XSS) they run the risk of the token being stolen by
an unintended party. To keep the token safe, it makes sense to store the
token in 'httpOnly' format so that they become inaccessible to Javascript.
This way, the token will be submitted to the API in a cookie and hence the
need for the Gateway to identify the token which it may now receive in the
form of a cookie and no longer as an HTTP header.

On Fri, Jan 4, 2019 at 5:04 PM Chamindu Udakara  wrote:

> Hi All,
>
> My project is to add cookie based authentication for micro-gateway. This
> is the approach that I have come up with. Please review and let me know
> what you think and please be kind enough to suggest your suggestions.
>
> Requirement
>
> Provide authentication for product micro-gateway with cookie based
> authentication which uses session HTTP cookies for authentication.
>
> Suggested Approach
>
> When an user invoke an API with a cookie, micro-gateway has to validate
> that cookie prior to the response. The list of cookies included in the HTTP
> request which use to authenticate, have to be extracted from the request.
> From all extracted cookies,their respective session ID value has to be
> extracted properly.
>
> The Authn filter will check incoming request to micro-gateway and
> determine whether it contains header as "Authorization" or header as
> "Cookie". If header is equals to "Cookie" then the cookie validation
> process will be executed and cookie will be validated. If not it will
> execute as a normal request which contains header as "Authorization". The
> session ID of the required cookie can be provided to server as a direct key
> value pair at the micro-gateway server startup.
>
>
>
>
>
>
> if (request.hasHeader(authHeaderName)) {
>
>authHeader = request.getHeader(authHeaderName);
>
>}else if (request.hasHeader(COOKIE_HEADER)){
>
>//Authentiction with HTTP cookies
>
>CookieBasedAuth cookieBasedAuth = new CookieBasedAuth ();
>
>result = cookieBasedAuth.processRequest(listener, request,
> context);
>
>}else {
>
>log:printError("No authorization header was provided");
>
>setErrorMessageToFilterContext(context,
> API_AUTH_MISSING_CREDENTIALS);
>
>sendErrorResponse(listener, request, untaint context);
>
>return false;
>
>}
>
> Above code segment will do that identification of header type of the
> coming request. Then the validation process will be done at the separate
> file named as* "cookie.bal"*. In this file the extraction of session Id
> and validation of that Id with given value at the server startup will be
> done. For that I have implemented a new function as "*ProcessRequest*"
> which returns a string or an error. If any of the cookies included in
> request is not equal to given Id then the validation process will be
> failed. If it fails, then it throws an error and authnFilter will be
> failed. If any of session Id of a cookie matches with given one then that
> id will be returned to authnFilter for further execution at authnFilter.
>
> public function processRequest(http:Listener listener, http:Request
> request, http:FilterContext context)
>
>returns string|error {
>
>boolean isAuthorized;
>
>//get required cookie as config value
>
>string requiredCookie = config:getAsString(COOKIE_HEADER, default
> = "");
>
>//extraxt cookies from the incoming request
>
>string authHead = request.getHeader(COOKIE_HEADER);
>
>string[] cookies = authHead.trim().split(";");
>
>foreach cookie in cookies{
>
>io:println(cookie);
>
>string[] sessionIds = cookie.trim().split("=");
>
>string sessionId = sessionIds[1];
>
>if (sessionId == requiredCookie){
>
>return sessionId;
>
>}
>
>}
>
>error notFound = {message:"No matched cookie found"};
>
>return notFound;
>
> }
>
>
>
> *Chamindu Udakara *
> *Software engineering Intern*
> WSO2  (University of Moratuwa)
> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) 

Re: [Architecture] Auth0 OpenID Connector for IS

[Nuwan Dias]

Hi Nirubikaa,

The image hasn't loaded it seems, could you attach it please?

I'm trying to figure out the problem we're trying to solve with this
solution. Could you briefly explain the use case (problem) as well please?

Thanks,
NuwanD.

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Nilasini Thirunavukkarasu]

Hi Nirubikaa,

We couldn't able to see the diagram. Could you please re-attach the image?

Thanks,
Nila.

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
Nilasini Thirunavukkarasu
Software Engineer - WSO2

Email : nilas...@wso2.com
Mobile : +94775241823
Web : http://wso2.com/



___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Nirubikaa Ravikumar]

please find the image,


On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
R.Nirubikaa
Intern | WSO2
M: O779108852
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Auth0 OpenID Connector for IS

[Nirubikaa Ravikumar]

please find the image,

On Mon, Jan 7, 2019 at 1:23 PM Nirubikaa Ravikumar 
wrote:

> Hi all,
> I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
> diagram below:
>
>
>
>
> In the flow of OpenID Connect,
>
> User sends a request to service provider, then the request is redirected
> to the WSO2 IS .Then the WSO2 IS requests to get authorization code with
> client credentials, and Openid scope. Then the Auth0 redirects to the
> request with Authorization code.
>
> Then WSO2 IS requests Access token, to that Auth0 responses with the
> Access token, An ID token is issued from the token endpoint in addition to
> an Access token.
>
> WSO2 IS requests to get user info, And Auth0 can retrieve user information
> from the ID token or Access token.
>
> Thanks.
> --
> R.Nirubikaa
> Intern | WSO2
> M: O779108852
>
>
>


-- 
R.Nirubikaa
Intern | WSO2
M: O779108852
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Auth0 OpenID Connector for IS

[Nirubikaa Ravikumar]

Hi all,
I am planing to work on  "Auth0 OpenID Connector ". Please find the flow
diagram below:




In the flow of OpenID Connect,

User sends a request to service provider, then the request is redirected to
the WSO2 IS .Then the WSO2 IS requests to get authorization code with
client credentials, and Openid scope. Then the Auth0 redirects to the
request with Authorization code.

Then WSO2 IS requests Access token, to that Auth0 responses with the Access
token, An ID token is issued from the token endpoint in addition to an
Access token.

WSO2 IS requests to get user info, And Auth0 can retrieve user information
from the ID token or Access token.

Thanks.
-- 
R.Nirubikaa
Intern | WSO2
M: O779108852
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Certificate based Authentication for Micro-gateway

[Bhashinee Nirmali]

Hi All,

To identify whether the mutual SSL authentication has been done
successfully, will it be okay if we send a parameter in the request saying
it failed or not? So that we can continue with the filters depending on the
retrieved value of that parameter.

Thanks,
Bhashinee

On Sun, Oct 28, 2018 at 7:57 PM Chamindu Udakara  wrote:

> Sure, will do that akka. Thanks
>
> On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali 
> wrote:
>
>> Hi Chamindu,
>>
>> Can you please initiate a mail thread in ballerina-...@googlegroups.com
>> mentioning the improvements that you need to come from ballerina side in
>> order to continue this? So that we can discuss how feasible to provide
>> these improvements with the ballerina team.
>>
>> Thanks,
>> Bhashinee
>>
>> On Tue, Oct 23, 2018 at 12:44 PM Bhashinee Nirmali 
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> As of now, Ballerina doesn't support setting mutual SSL to 'optional'.
>>> It only supports the 'require' option. With that, it requires client
>>> certificate authentication. The connection will terminate if no suitable
>>> client certificate is presented. So currently there is no way of doing
>>> that. Better to create an issue to track this requirement.
>>>
>>> Hi Chamindu,
>>>
>>> If this is a valid requirement to set it to optional, we'll keep it in
>>> that way. As we do not support it from Ballerina now, let's keep that
>>> option disabled. So once the support is given from Ballerina, we can
>>> continue using that option as well.
>>>
>>> Thanks,
>>> Bhashinee
>>>
>>> On Mon, Oct 22, 2018 at 5:16 PM Chamindu Udakara 
>>> wrote:
>>>
 Hi Bhashinee Akka,

 It was a mistake to put that parameter value as "optional" since we are
 not providing optional support. I will change it as false or "not 
 required".

 Thank You

 On Mon, Oct 22, 2018 at 3:07 PM Bhashinee Nirmali 
 wrote:

> Hi Chamindu,
>
> On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara 
> wrote:
>
>>
>>
>>
>> Hi All,
>>
>> The project I have chosen is Certificate based authentication for
>> micro gateway.
>>
>> *Problem*
>>
>>-
>>
>>Micro-gateway does not have certificate based authentication or
>>Mutual TLS establishment and micro-gateway can authenticate a request 
>> using
>>OAuth2 token only. This is an overhead for trusted clients who are 
>> using
>>this product because of the token generation and life cycle of OAuth2
>>tokens.
>>
>> *Solution*
>>
>>-
>>
>>This project is carried out to overcome above limitation by
>>providing Mutual TLS (Certificate based authentication) to 
>> micro-gateway.
>>
>>
>> *Design *
>>
>>
>> Configure mutualSSL feature at runtime level in configuration
>>
>>
>>
>> MutualSSL feature can be enabled for a micro-gateway after it was
>> built by changing a property from “micro-gw.conf” file. There is a 
>> property
>> as “sslVerifyClient” in this “micro-gw.conf” file under “[mtslConfig]”
>> Instance ID. By default this value is set to “false”.
>>
>> When this,
>>
>> sslVerifyClient = “false”
>>
>> property is shows as above the micro-gateway will function as
>> previous by using OAuth or JWT tokens as authentication.
>>
>> To enable mutualSSL in a micro-gateway user has to change this
>> “sslVerifyClient” as follows,
>>
>> sslVerifyClient = “require”
>>
>> and user has to change KeyStore path and KeyStore password in this
>> “micro-gw.conf” file. These “keyStore.path” property and
>> “keyStore.password” property under “[listenerConfig]” instance ID has to 
>> be
>> changed.
>>
>> By enabling this MutualSSL feature in micro-gateway
>> authentication process is done in the transport layer and therefore OAUth
>> headers or JWT token will not be needed for requests from trusted 
>> clients.
>> If the mutualSSL is enable in the micro-gateway, “Authentication_Filter”
>> and “Authorization_Filter” will be skipped by newly introduces
>> “Mutual_SSL_Filter”. And the details needed for throttling also append by
>> this “Mutual_SSL_Filter”. Then listener.bal file looks as follows,
>>
>>
>> endpoint gateway:APIGatewaySecureListener apiSecureListener {
>>
>> port:9095,
>>
>> filters:[  mtslFilter, authnFilter, authorizationFilter,
>> subscriptionFilter, throttleFilter, analyticsFilter, extensionFilter]
>>
>> };
>>
>>
>> micro-gw.conf will change as follows,
>>
>>
>>
>>
>>
>>
>> [mtslConfig]
>> protocolName="TLS"
>>
>> protocolVersions=["TLSv1.2", "TLSv1.1"]
>>
>>
>> ciphers=["TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
>>
>>