OAuth clients based on a trusted CA

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

OAuth clients based on a trusted CA

Prabath Siriwardena
I guess following scenario will be useful in a microservices deployment, when we need to secure service to service communication.

Please find below the steps..

1. We create a service provider provider, and associate a CA's certificate with it.
2. Now we have multiple microservices, each with a signed certificate from the previous trusted CA.
3. Each of those microservice will be able to talk to the /token endpoint of IS (or STS), authenticate with mTLS and get a token. The token request also carries an audience value (or implied in scope).
4. IS treats, the thumbprint of the cert (preferably SVID, in a SPIFFE/Istio environment) as the client id, and the access token is issued against it (which can be a JWT as well).
5. This new access token/JWT can be used for service to service authentication, within the same domain or cross domain.

This helps to onboard all the microservices, carrying a key pair (as their workload identity) to an OAuth environment.

WDYT..?

Thanks & Regards,
Prabath




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

Re: OAuth clients based on a trusted CA

Sathya Bandara
Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client Authentication' specification [1]. There it defines two distinct methods for certificate based client authentication.
 
1. PKI Mutual TLS OAuth Client Authentication
Uses a subject distinguished name (DN) and validated certificate chain to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication

Support client authentication using self-signed certificates.  Client registers needs to associate a self-signed X.509 certificate at the time of registering. The client is successfully authenticated, if the subject public key info of the certificate matches the subject public key info of one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based authentication [2].

In the first method, client needs to associate the CA certificate and need to provide the DN of the signed certificate at the time of client registration. During mutual TLS handshake, we only need to validate client's CA certificate. The client is successfully authenticated if the subject information in the certificate matches with the expected DN configured or registered for that particular client.

[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena <[hidden email]> wrote:
I guess following scenario will be useful in a microservices deployment, when we need to secure service to service communication.

Please find below the steps..

1. We create a service provider provider, and associate a CA's certificate with it.
2. Now we have multiple microservices, each with a signed certificate from the previous trusted CA.
3. Each of those microservice will be able to talk to the /token endpoint of IS (or STS), authenticate with mTLS and get a token. The token request also carries an audience value (or implied in scope).
4. IS treats, the thumbprint of the cert (preferably SVID, in a SPIFFE/Istio environment) as the client id, and the access token is issued against it (which can be a JWT as well).
5. This new access token/JWT can be used for service to service authentication, within the same domain or cross domain.

This helps to onboard all the microservices, carrying a key pair (as their workload identity) to an OAuth environment.

WDYT..?

Thanks & Regards,
Prabath




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




--
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: <a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">(+94) 715 360 421

<a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">

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

Re: OAuth clients based on a trusted CA

Prabath Siriwardena
Hi Sathya,

Yes... it is an extension to [1]...

In this approach, we are going to avoid registration of individual microservices (as OAuth clients).... even no thumbprints registered... we identify each one as a valid client, if the CA is valid, and dynamically create clients for them on the fly, when they request tokens...

Thanks & regards,
-Prabath

On Tue, Aug 7, 2018 at 2:52 AM, Sathya Bandara <[hidden email]> wrote:
Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client Authentication' specification [1]. There it defines two distinct methods for certificate based client authentication.
 
1. PKI Mutual TLS OAuth Client Authentication
Uses a subject distinguished name (DN) and validated certificate chain to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication

Support client authentication using self-signed certificates.  Client registers needs to associate a self-signed X.509 certificate at the time of registering. The client is successfully authenticated, if the subject public key info of the certificate matches the subject public key info of one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based authentication [2].

In the first method, client needs to associate the CA certificate and need to provide the DN of the signed certificate at the time of client registration. During mutual TLS handshake, we only need to validate client's CA certificate. The client is successfully authenticated if the subject information in the certificate matches with the expected DN configured or registered for that particular client.

[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena <[hidden email]> wrote:
I guess following scenario will be useful in a microservices deployment, when we need to secure service to service communication.

Please find below the steps..

1. We create a service provider provider, and associate a CA's certificate with it.
2. Now we have multiple microservices, each with a signed certificate from the previous trusted CA.
3. Each of those microservice will be able to talk to the /token endpoint of IS (or STS), authenticate with mTLS and get a token. The token request also carries an audience value (or implied in scope).
4. IS treats, the thumbprint of the cert (preferably SVID, in a SPIFFE/Istio environment) as the client id, and the access token is issued against it (which can be a JWT as well).
5. This new access token/JWT can be used for service to service authentication, within the same domain or cross domain.

This helps to onboard all the microservices, carrying a key pair (as their workload identity) to an OAuth environment.

WDYT..?

Thanks & Regards,
Prabath




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




--
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: <a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">(+94) 715 360 421

<a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">

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




--
Thanks & Regards,
Prabath




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

Re: OAuth clients based on a trusted CA

Farasath Ahamed


On Tue, Aug 7, 2018 at 4:53 PM, Prabath Siriwardena <[hidden email]> wrote:
Hi Sathya,

Yes... it is an extension to [1]...

In this approach, we are going to avoid registration of individual microservices (as OAuth clients).... even no thumbprints registered... we identify each one as a valid client, if the CA is valid, and dynamically create clients for them on the fly, when they request tokens...

So when we dynamically creates we are going map mulitiple client ids against the same SP? 

Thanks & regards,
-Prabath


On Tue, Aug 7, 2018 at 2:52 AM, Sathya Bandara <[hidden email]> wrote:
Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client Authentication' specification [1]. There it defines two distinct methods for certificate based client authentication.
 
1. PKI Mutual TLS OAuth Client Authentication
Uses a subject distinguished name (DN) and validated certificate chain to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication

Support client authentication using self-signed certificates.  Client registers needs to associate a self-signed X.509 certificate at the time of registering. The client is successfully authenticated, if the subject public key info of the certificate matches the subject public key info of one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based authentication [2].

In the first method, client needs to associate the CA certificate and need to provide the DN of the signed certificate at the time of client registration. During mutual TLS handshake, we only need to validate client's CA certificate. The client is successfully authenticated if the subject information in the certificate matches with the expected DN configured or registered for that particular client.

[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena <[hidden email]> wrote:
I guess following scenario will be useful in a microservices deployment, when we need to secure service to service communication.

Please find below the steps..

1. We create a service provider provider, and associate a CA's certificate with it.
2. Now we have multiple microservices, each with a signed certificate from the previous trusted CA.
3. Each of those microservice will be able to talk to the /token endpoint of IS (or STS), authenticate with mTLS and get a token. The token request also carries an audience value (or implied in scope).
4. IS treats, the thumbprint of the cert (preferably SVID, in a SPIFFE/Istio environment) as the client id, and the access token is issued against it (which can be a JWT as well).
5. This new access token/JWT can be used for service to service authentication, within the same domain or cross domain.

This helps to onboard all the microservices, carrying a key pair (as their workload identity) to an OAuth environment.

WDYT..?

Thanks & Regards,
Prabath




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




--
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: <a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">(+94) 715 360 421

<a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">

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




--
Thanks & Regards,
Prabath




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




--
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: <a href="tel:%2B94777603866" value="+94713149860" style="font-size:12.8px;color:rgb(17,85,204)" target="_blank">+94777603866
Twitter: @farazath619





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

Re: OAuth clients based on a trusted CA

Prabath Siriwardena


On Tue, Aug 7, 2018 at 4:42 AM, Farasath Ahamed <[hidden email]> wrote:


On Tue, Aug 7, 2018 at 4:53 PM, Prabath Siriwardena <[hidden email]> wrote:
Hi Sathya,

Yes... it is an extension to [1]...

In this approach, we are going to avoid registration of individual microservices (as OAuth clients).... even no thumbprints registered... we identify each one as a valid client, if the CA is valid, and dynamically create clients for them on the fly, when they request tokens...

So when we dynamically creates we are going map mulitiple client ids against the same SP? 

Yes... 

Thanks & regards,
-Prabath
 

Thanks & regards,
-Prabath


On Tue, Aug 7, 2018 at 2:52 AM, Sathya Bandara <[hidden email]> wrote:
Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client Authentication' specification [1]. There it defines two distinct methods for certificate based client authentication.
 
1. PKI Mutual TLS OAuth Client Authentication
Uses a subject distinguished name (DN) and validated certificate chain to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication

Support client authentication using self-signed certificates.  Client registers needs to associate a self-signed X.509 certificate at the time of registering. The client is successfully authenticated, if the subject public key info of the certificate matches the subject public key info of one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based authentication [2].

In the first method, client needs to associate the CA certificate and need to provide the DN of the signed certificate at the time of client registration. During mutual TLS handshake, we only need to validate client's CA certificate. The client is successfully authenticated if the subject information in the certificate matches with the expected DN configured or registered for that particular client.

[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena <[hidden email]> wrote:
I guess following scenario will be useful in a microservices deployment, when we need to secure service to service communication.

Please find below the steps..

1. We create a service provider provider, and associate a CA's certificate with it.
2. Now we have multiple microservices, each with a signed certificate from the previous trusted CA.
3. Each of those microservice will be able to talk to the /token endpoint of IS (or STS), authenticate with mTLS and get a token. The token request also carries an audience value (or implied in scope).
4. IS treats, the thumbprint of the cert (preferably SVID, in a SPIFFE/Istio environment) as the client id, and the access token is issued against it (which can be a JWT as well).
5. This new access token/JWT can be used for service to service authentication, within the same domain or cross domain.

This helps to onboard all the microservices, carrying a key pair (as their workload identity) to an OAuth environment.

WDYT..?

Thanks & Regards,
Prabath




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




--
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: <a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">(+94) 715 360 421

<a href="tel:+94%2071%20411%205032" value="+94714115032" target="_blank">

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




--
Thanks & Regards,
Prabath




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




--
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: <a href="tel:%2B94777603866" value="+94713149860" style="font-size:12.8px;color:rgb(17,85,204)" target="_blank">+94777603866
Twitter: @farazath619





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




--
Thanks & Regards,
Prabath




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