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

>
>
> On Tue, Aug 7, 2018 at 4:53 PM, Prabath Siriwardena <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 <https://twitter.com/farazath619>
> <http://wso2.com/signature>
>
>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> 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
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to