You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Jon Bringhurst (Jira)" <ji...@apache.org> on 2019/08/22 19:31:00 UTC
[jira] [Updated] (ZOOKEEPER-3514) Use client certificate SAN list
for X.509 ACL AuthZ
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Bringhurst updated ZOOKEEPER-3514:
--------------------------------------
Description:
Hello! We have a TLS environment where services currently utilize various client certificate SAN fields for authentication. For example, a client certificate would look contain something like this:
{noformat}
X509v3 Subject Alternative Name: critical
DNS:zookeeper-server-001.example.com, URI:APPLICATION_NAME, URI:DATACENTER_NAME
{noformat}
My current approach is to simply add the SAN list to the cnxn AuthInfo list. For example (in X509AuthenticationProvider):
{noformat}
protected List<String> getAlternativeClientIds(X509Certificate clientCert) {
return clientCert.getSubjectAlternativeNames();
}
{noformat}
{noformat}
if (this.sslAclIncludeSANAuthZEnabled) {
List<String> alternativeClientIds = getAlternativeCLientIds(clientCert);
for (int i = 0; i < alternativeClientIds.size(); i++) {
Id altAuthInfo = new Id(getScheme(), alternativeClientIds.get(i));
cnxn.addAuthInfo(altAuthInfo);
LOG.info("Authenticated Alternative Id '{}' for Scheme '{}'", altAuthInfo.getId(), altAuthInfo.getScheme());
}
}
{noformat}
So, ACLs would then look something like this:
{noformat}
x509:zookeeper-server-001.example.com:perm
x509:APPLICATION_NAME:perm
x509:DATACENTER_NAME:perm
{noformat}
Before I spend time to put it together, would a patch for this functionality have any chance of being accepted? If so, how do you feel about the config option named sslAclIncludeSANAuthZEnabled?
was:
Hello! We have a TLS environment where services currently utilize various client certificate SAN fields for authentication. For example, a client certificate would look contain something like this:
{noformat}
X509v3 Subject Alternative Name: critical
DNS:zookeeper-server-001.example.com, URI:APPLICATION_NAME, URI:DATACENTER_NAME
{noformat}
My current approach is to simply add the SAN list to the cnxn AuthInfo list. For example:
{noformat}
protected List<String> getAlternativeClientIds(X509Certificate clientCert) {
return clientCert.getSubjectAlternativeNames();
}
{noformat}
{noformat}
if (this.sslAclIncludeSANAuthZEnabled) {
List<String> alternativeClientIds = getAlternativeCLientIds(clientCert);
for (int i = 0; i < alternativeClientIds.size(); i++) {
Id altAuthInfo = new Id(getScheme(), alternativeClientIds.get(i));
cnxn.addAuthInfo(altAuthInfo);
LOG.info("Authenticated Alternative Id '{}' for Scheme '{}'", altAuthInfo.getId(), altAuthInfo.getScheme());
}
}
{noformat}
So, ACLs would then look something like this:
{noformat}
x509:zookeeper-server-001.example.com:perm
x509:APPLICATION_NAME:perm
x509:DATACENTER_NAME:perm
{noformat}
Before I spend time to put it together, would a patch for this functionality have any chance of being accepted? :)
> Use client certificate SAN list for X.509 ACL AuthZ
> ---------------------------------------------------
>
> Key: ZOOKEEPER-3514
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3514
> Project: ZooKeeper
> Issue Type: Improvement
> Reporter: Jon Bringhurst
> Priority: Major
>
> Hello! We have a TLS environment where services currently utilize various client certificate SAN fields for authentication. For example, a client certificate would look contain something like this:
> {noformat}
> X509v3 Subject Alternative Name: critical
> DNS:zookeeper-server-001.example.com, URI:APPLICATION_NAME, URI:DATACENTER_NAME
> {noformat}
> My current approach is to simply add the SAN list to the cnxn AuthInfo list. For example (in X509AuthenticationProvider):
> {noformat}
> protected List<String> getAlternativeClientIds(X509Certificate clientCert) {
> return clientCert.getSubjectAlternativeNames();
> }
> {noformat}
> {noformat}
> if (this.sslAclIncludeSANAuthZEnabled) {
> List<String> alternativeClientIds = getAlternativeCLientIds(clientCert);
> for (int i = 0; i < alternativeClientIds.size(); i++) {
> Id altAuthInfo = new Id(getScheme(), alternativeClientIds.get(i));
> cnxn.addAuthInfo(altAuthInfo);
> LOG.info("Authenticated Alternative Id '{}' for Scheme '{}'", altAuthInfo.getId(), altAuthInfo.getScheme());
> }
> }
> {noformat}
> So, ACLs would then look something like this:
> {noformat}
> x509:zookeeper-server-001.example.com:perm
> x509:APPLICATION_NAME:perm
> x509:DATACENTER_NAME:perm
> {noformat}
> Before I spend time to put it together, would a patch for this functionality have any chance of being accepted? If so, how do you feel about the config option named sslAclIncludeSANAuthZEnabled?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)