You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (Jira)" <ji...@apache.org> on 2020/04/29 09:19:00 UTC
[jira] [Comment Edited] (DISPATCH-1634) Expose client X509
certificate identity (TLS client auth) to the auth service delegate
[ https://issues.apache.org/jira/browse/DISPATCH-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095275#comment-17095275 ]
Keith Wall edited comment on DISPATCH-1634 at 4/29/20, 9:18 AM:
----------------------------------------------------------------
In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert..
The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively.
[1] https://tools.ietf.org/html/rfc4422#page-29
was (Author: k-wall):
In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert..
The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively.
[1] https://tools.ietf.org/html/rfc4422#page-29
If the authenticated identity that the client supplies is identical to the one we would form from the client cert, then there is no need to reject... but otherwise (absent any other form of verification/validation) it's a way of trying to impersonate and potentially a security hole
> Expose client X509 certificate identity (TLS client auth) to the auth service delegate
> --------------------------------------------------------------------------------------
>
> Key: DISPATCH-1634
> URL: https://issues.apache.org/jira/browse/DISPATCH-1634
> Project: Qpid Dispatch
> Issue Type: Improvement
> Reporter: Keith Wall
> Priority: Major
>
> For the use-case where Dispatch Router is configured to require the client use TLS client auth (authenticatePeer: yes) and the authServicePlugin is in use, there needs to be a mechanism to expose the X509 certificate identity of the client to the auth service so it can be used to control the`address-authz response.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org