You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ganesh Murthy (Jira)" <ji...@apache.org> on 2020/06/02 14:52: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=17123845#comment-17123845 ]
Ganesh Murthy edited comment on DISPATCH-1634 at 6/2/20, 2:51 PM:
------------------------------------------------------------------
The Dispatch Router provides fields in the sslProfile entity, namely, uidFormat and uidNameMappingFile.
The uidFormat allows you to specify a format which will be used to generate an identity from the TLS client certificate.
Allowed values in uidFormat can be any combination of
{noformat}
'c'( ISO3166 two character country code),
's'(state or province),
'l'(Locality; generally - city),
'o'(Organization - Company Name),
'u'(Organization Unit - typically certificate type or brand),
'n'(CommonName - typically a user name for client certificates) and
'1'(sha1 certificate fingerprint, as displayed in the fingerprints section when looking at a certificate with say a web browser is the hash of the entire certificate)
'2'(sha256 certificate fingerprint)
'5' (sha512 certificate fingerprint).
The user identifier (uid) that is generated based on the uidFormat is a string which has a semi-colon as a separator between the components{noformat}
For example the uidFormat can be
{noformat}
('sslProfile', {'name': 'sslProfile',
'caCertFile': 'ca-certificate.pem',
'certFile': 'server-certificate.pem',
'privateKeyFile': 'server-private-key.pem',
'uidFormat': 'nsuco',
'uidNameMappingFile': /path/to/ssl_profile.json,
'password': 'server-password'}) {noformat}
{noformat}
'nsuco' for uidFormat indicates that the unique certificate identity be constructed using CommonName, State, Organization Unit, Country Code and Company Name{noformat}
The uidNameMappingFile is the absolute path to the file containing the unique id to display name mapping.
For example, the contents of ssl_profile.json file could be
{noformat}
{
"Danny DeVito;MA;Dev;US;Acme Inc": "ddevito",
"Jane Doe;MA;Dev;US;Acme Inc": "janedoe",
"John Doe;MA;Dev;US;Acme Inc": "johndoe",
}
{noformat}
The file is simply a JSON which maps the identity string generated by the uidFormat to a user name.
The user name can be empty in which case the router will just return the identity string
Now that we have explained how the uidFormat and uidNameMappingFile work, there are two parts to this Jira
# If the certificate identity (string generated using uidFormat) does not exist in the uidNameMappingFile, the router does not currently close the connection which it will have to do.
# 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. To do this we need a way from proton-c to
## for a server to get the authzid for a sasl external request
## for a client to specify the authzid to send with an external request
was (Author: ganeshmurthy):
The Dispatch Router provides a fields in the sslProfile entity, namely, uidFormat and uidNameMappingFile.
The uidFormat allows you to specify a format which will be used to generate an identity from the TLS client certificate.
Allowed values in uidFormat can be any combination of
{noformat}
'c'( ISO3166 two character country code),
's'(state or province),
'l'(Locality; generally - city),
'o'(Organization - Company Name),
'u'(Organization Unit - typically certificate type or brand),
'n'(CommonName - typically a user name for client certificates) and
'1'(sha1 certificate fingerprint, as displayed in the fingerprints section when looking at a certificate with say a web browser is the hash of the entire certificate)
'2'(sha256 certificate fingerprint)
'5' (sha512 certificate fingerprint).
The user identifier (uid) that is generated based on the uidFormat is a string which has a semi-colon as a separator between the components{noformat}
For example the uidFormat can be
{noformat}
('sslProfile', {'name': 'sslProfile',
'caCertFile': 'ca-certificate.pem',
'certFile': 'server-certificate.pem',
'privateKeyFile': 'server-private-key.pem',
'uidFormat': 'nsuco',
'uidNameMappingFile': /path/to/ssl_profile.json,
'password': 'server-password'}) {noformat}
{noformat}
'nsuco' for uidFormat indicates that the unique certificate identity be constructed using CommonName, State, Organization Unit, Country Code and Company Name{noformat}
The uidNameMappingFile is the absolute path to the file containing the unique id to display name mapping.
For example, the contents of ssl_profile.json file could be
{noformat}
{
"Danny DeVito;MA;Dev;US;Acme Inc": "ddevito",
"Jane Doe;MA;Dev;US;Acme Inc": "janedoe",
"John Doe;MA;Dev;US;Acme Inc": "johndoe",
}
{noformat}
The file is simply a JSON which maps the identity string generated by the uidFormat to a user name.
The user name can be empty in which case the router will just return the identity string
Now that we have explained how the uidFormat and uidNameMappingFile work, there are two parts to this Jira
# If the certificate identity (string generated using uidFormat) does not exist in the uidNameMappingFile, the router does not currently close the connection which it will have to do.
# 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. To do this we need a way from proton-c to
## for a server to get the authzid for a sasl external request
## for a client to specify the authzid to send with an external request
> 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