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 <sat...@wso2.com> 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. > > [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 > [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 <prab...@wso2.com> > 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 >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Blog: http://blog.facilelogin.com >> Vlog: http://vlog.facilelogin.com >> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sathya Bandara > Software Engineer > WSO2 Inc. http://wso2.com > Mobile: (+94) 715 360 421 <+94%2071%20411%205032> > > <+94%2071%20411%205032> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Blog: http://blog.facilelogin.com Vlog: http://vlog.facilelogin.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
