Fwd: Certificate based Authentication for Micro-gateway

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Certificate based Authentication for Micro-gateway

Chamindu Udakara



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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


sslVerifyClient="optional"

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Rajith Roshan


On Mon, Oct 22, 2018 at 3:07 PM Bhashinee Nirmali <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
+1 
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?
Yes, If we set it as optional , we would like to skip the oauth authentication if mutual ssl has passed without any issue. But ATM we don't have a way to identify whether the mutual ssl authentication has been done successfully, when parameter is set as optional . is there a wat we can achieve this?
 

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Chamindu Udakara
In reply to this post by Bhashinee Nirmali-2
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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2
Hi Chamindu,

Can you please initiate a mail thread in [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Chamindu Udakara
Sure, will do that akka. Thanks

On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali <[hidden email]> wrote:
Hi Chamindu,

Can you please initiate a mail thread in [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2
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 <[hidden email]> wrote:
Sure, will do that akka. Thanks

On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali <[hidden email]> wrote:
Hi Chamindu,

Can you please initiate a mail thread in [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2


On Mon, Jan 7, 2019 at 8:59 AM Chamindu Udakara <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Sure, will do that akka. Thanks

On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali <[hidden email]> wrote:
Hi Chamindu,

Can you please initiate a mail thread in [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Certificate based Authentication for Micro-gateway

Bhashinee Nirmali-2
Hi All,

Setting mutual SSL to 'optional' is supported by Ballerina 0.990.3. And to identify whether the mutual SSL authentication has been done successfully, there is a record in the request as 'mutualSslHandshake'. You can get the status of the handshake as 'passed' or 'failed' as given below.
request.mutualSslHandshake["status"]
Thanks,
Bhashinee

On Tue, Jan 8, 2019 at 9:01 AM Bhashinee Nirmali <[hidden email]> wrote:


On Mon, Jan 7, 2019 at 8:59 AM Chamindu Udakara <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Sure, will do that akka. Thanks

On Sun, Oct 28, 2018 at 3:39 PM Bhashinee Nirmali <[hidden email]> wrote:
Hi Chamindu,

Can you please initiate a mail thread in [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Chamindu,

On Mon, Oct 22, 2018 at 10:22 AM Chamindu Udakara <[hidden email]> 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",
  "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
  "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_RSA_WITH_AES_128_CBC_SHA256","TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
  "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"," TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"," TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
  "TLS_DHE_DSS_WITH_AES_128_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  ,"TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
  "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"," TLS_DHE_RSA_WITH_AES_128_GCM_SHA256","TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
  ,"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA","TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA","SSL_RSA_WITH_3DES_EDE_CBC_SHA",
  "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"," TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA","SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
  "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"," TLS_EMPTY_RENEGOTIATION_INFO_SCSV"]


 I hope the above configurations(protocolName, protocolVersions, ciphers) are not mandatory fields to enable mutual SSL. Because these are not specific to mutual SSL. They can be configured in 1 way SSL as well. So how about changing the name [mtslConfig] to [SslConfig]?
 

sslVerifyClient="optional"

What do you mean by setting sslVerifyClient="optional"? Does that mean that you first check if the mutual SSL has succeeded and if it has succeeded you skip OAuth or JWT tokens authentication and if mutual SSL fails, you continue with OAuth or JWT tokens authentication as well?

 

Thank You

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003

--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Chamindu Udakara 
Software engineering Intern
WSO2  (University of Moratuwa)
mobile : +94 755285531  |   email :  [hidden email]


--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003



--
Bhashinee Nirmali
Software Engineer
WSO2 Lanka (Private) Limited: http://wso2.com
lean.enterprise.middle-ware

phone: (+94) 71 21 50003


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture