[
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 contain something like this:
{noformat}
X509v3 Subject Alternative Name: critical
DNS:zookeeper-server-001.example.com, DNS:APPLICATION_NAME,
DNS: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) {
// not shown: filtering on type 2 here
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 (given the example SAN list shown
above):
{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 (any suggestions for alternative approaches)?
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 contain something like this:
{noformat}
X509v3 Subject Alternative Name: critical
DNS:zookeeper-server-001.example.com, DNS:APPLICATION_NAME,
DNS: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) {
// filter on type 2 here
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 (given the example SAN list shown
above):
{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 (any suggestions for alternative approaches)?
If so, how do you feel about the config option named
sslAclIncludeSANAuthZEnabled?
> 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 contain something like this:
> {noformat}
> X509v3 Subject Alternative Name: critical
> DNS:zookeeper-server-001.example.com, DNS:APPLICATION_NAME,
> DNS: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) {
> // not shown: filtering on type 2 here
> 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 (given the example SAN list
> shown above):
> {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 (any suggestions for alternative
> approaches)? If so, how do you feel about the config option named
> sslAclIncludeSANAuthZEnabled?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
