zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Bringhurst (Jira)" <j...@apache.org>
Subject [jira] [Updated] (ZOOKEEPER-3514) Use client certificate SAN list for X.509 ACL AuthZ
Date Thu, 22 Aug 2019 19:31:00 GMT

     [ 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)

Mime
View raw message