You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Manikumar <ma...@gmail.com> on 2018/09/07 19:15:57 UTC
[DISCUSS] KIP-371: Add a configuration to build custom SSL principal name
Hi all,
I have created a KIP that proposes couple of options for building custom
SSL principal names.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
Please take a look.
Thanks,
Manikumar
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Thanks for the reviews.
Makes sense. I don't see any downsides. Updated the KIP, to go with Option
2.
I will be starting the vote thread soon.
Thanks,
On Wed, Sep 19, 2018 at 2:17 PM Rajini Sivaram <ra...@gmail.com>
wrote:
> Hi Manikumar,
>
> Unless there is a downside to option 2 (e.g will it impose character limits
> in the DN), it may be better to go with option 2 for consistency and
> flexibility.
>
> On Wed, Sep 19, 2018 at 5:11 AM, Harsha <ka...@harsha.io> wrote:
>
> > Thanks. I am also leaning towards option 2, as it will help the
> > consistency of expressing such mapping between sasl and ssl.
> > -Harsha
> >
> > On Tue, Sep 18, 2018, at 8:27 PM, Manikumar wrote:
> > > Hi Harsha,
> > >
> > > Thanks for the review. Yes, As mentioned on the motivation section,
> this
> > is
> > > to simply extracting fields from the certificates
> > > for the common use cases. Yes, we are not supporting extracting
> > > SubjectAltName using this KIP.
> > >
> > > Thanks,
> > >
> > >
> > > On Wed, Sep 19, 2018 at 8:29 AM Harsha <ka...@harsha.io> wrote:
> > >
> > > > Hi Manikumar,
> > > > I am interested to know the reason for exposing this config,
> > given
> > > > a user has access to PrincipalBuilder interface to build their
> > > > interpretation of an identity from the X509 certificates. Is this to
> > > > simplify extraction of identity? and also there are other use cases
> > where
> > > > user's will extract SubjectAltName to construct the identity I guess
> > thats
> > > > not going to supported by this method.
> > > >
> > > > Thanks,
> > > > Harsha
> > > >
> > > > On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> > > > > Hi Rajini,
> > > > >
> > > > > I don't have strong reasons for rejecting Option 2. I just felt
> > Option 1
> > > > is
> > > > > sufficient for
> > > > > the common use-cases (extracting single field, like CN etc..).
> > > > >
> > > > > We are open to go with Option 2, for more flexible mapping
> mechanism.
> > > > > Let us know, your preference.
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <
> > rajinisivaram@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Manikumar,
> > > > > >
> > > > > > It wasn't entirely clear to me why Option 2 was rejected.
> > > > > >
> > > > > > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <
> > manikumar.reddy@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > We would like to go with Option 1, which adds a new
> configuration
> > > > > > parameter
> > > > > > > pair of the form:
> > > > > > > ssl.principal.mapping.pattern, ssl.principal.mapping.value.
> This
> > will
> > > > > > > fulfill the requirement for most of the common use cases.
> > > > > > >
> > > > > > > We would like to include the KIP in the upcoming release. If
> > there no
> > > > > > > concerns, would like to start vote on this KIP.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <
> > pshah@hortonworks.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Definitely a helpful change. +1 for Option 2.
> > > > > > > >
> > > > > > > > On 9/14/18, 10:52 AM, "Manikumar" <
> manikumar.reddy@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > Hi Eno,
> > > > > > > >
> > > > > > > > Thanks for the review.
> > > > > > > >
> > > > > > > > Most often users want to extract one of the field (eg.
> > CN). CN
> > > > is
> > > > > > the
> > > > > > > > commonly used field.
> > > > > > > > For this simple change, users need to build and maintain
> > the
> > > > custom
> > > > > > > > principal builder class
> > > > > > > > and also package and deploy to the all brokers. Having
> > > > configurable
> > > > > > > > rules
> > > > > > > > will be useful.
> > > > > > > >
> > > > > > > > Proposed mapping rules works on string representation of
> > the
> > > > X.500
> > > > > > > > distinguished name(RFC2253 format) [1].
> > > > > > > > Mapping rules can use the attribute types keywords
> defined
> > in
> > > > RFC
> > > > > > > 2253
> > > > > > > > (CN,
> > > > > > > > L, ST, O, OU, C, STREET, DC, UID).
> > > > > > > >
> > > > > > > > Any additional/custom attribute types are emitted as
> OIDs.
> > To
> > > > emit
> > > > > > > > additional attribute type keys,
> > > > > > > > we need to have OID -> attribute type keyword String
> > > > mapping.[2]
> > > > > > > >
> > > > > > > > For example, String representation of
> > X500Principal("CN=Duke,
> > > > > > > > OU=JavaSoft,
> > > > > > > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > > > > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > > > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > > > > > 160d7465737440746573742e636f6d"
> > > > > > > >
> > > > > > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > > > > > "emailAddress"),
> > > > > > > > the string will be
> > > > > > > > "CN=Duke,OU=JavaSoft,O=Sun
> Microsystems,C=US,emailAddress=
> > > > > > > > test@test.com"
> > > > > > > >
> > > > > > > > Since we are not passing this mapping, we can not extarct
> > using
> > > > > > > > additional
> > > > > > > > attribute type keyword string.
> > > > > > > > If the user want to extract additional attribute keys, we
> > need
> > > > to
> > > > > > > write
> > > > > > > > custom principal builder class.
> > > > > > > >
> > > > > > > > Hope the above helps. Update the KIP.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > > X500Principal.html#getName(java.lang.String)
> > > > > > > >
> > > > > > > > [2]
> > > > > > > >
> > > > > > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > > > > > eno.thereska@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Manikumar, thanks. If I understand the KIP motivation
> > right,
> > > > this
> > > > > > > is
> > > > > > > > > currently already possible, but you want to have an
> > easier
> > > > way of
> > > > > > > > doing it,
> > > > > > > > > right? The motivation would be stronger if we had 2-3
> > common
> > > > > > cases
> > > > > > > > (from
> > > > > > > > > experience) where the suggested pattern would solve
> > them, and
> > > > > > > > perhaps 1-2
> > > > > > > > > cases where the pattern would not be adequate and we'd
> > have
> > > > to
> > > > > > fall
> > > > > > > > back to
> > > > > > > > > the existing builder class.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Eno
> > > > > > > > >
> > > > > > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > > > > > manikumar.reddy@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi All,
> > > > > > > > > >
> > > > > > > > > > We'd appreciate any thoughts / comments on the
> proposed
> > > > options
> > > > > > > for
> > > > > > > > > > customizing SSL principal names.
> > > > > > > > > > We are happy to discuss any alternative
> > > > approaches/suggestions.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > > > > > manikumar.reddy@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > I have created a KIP that proposes couple of
> options
> > for
> > > > > > > building
> > > > > > > > > custom
> > > > > > > > > > > SSL principal names.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > https://cwiki.apache.org/
> > confluence/display/KAFKA/KIP-
> > > > > > > > > >
> > > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > > > > > >
> > > > > > > > > > > Please take a look.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Manikumar
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Rajini Sivaram <ra...@gmail.com>.
Hi Manikumar,
Unless there is a downside to option 2 (e.g will it impose character limits
in the DN), it may be better to go with option 2 for consistency and
flexibility.
On Wed, Sep 19, 2018 at 5:11 AM, Harsha <ka...@harsha.io> wrote:
> Thanks. I am also leaning towards option 2, as it will help the
> consistency of expressing such mapping between sasl and ssl.
> -Harsha
>
> On Tue, Sep 18, 2018, at 8:27 PM, Manikumar wrote:
> > Hi Harsha,
> >
> > Thanks for the review. Yes, As mentioned on the motivation section, this
> is
> > to simply extracting fields from the certificates
> > for the common use cases. Yes, we are not supporting extracting
> > SubjectAltName using this KIP.
> >
> > Thanks,
> >
> >
> > On Wed, Sep 19, 2018 at 8:29 AM Harsha <ka...@harsha.io> wrote:
> >
> > > Hi Manikumar,
> > > I am interested to know the reason for exposing this config,
> given
> > > a user has access to PrincipalBuilder interface to build their
> > > interpretation of an identity from the X509 certificates. Is this to
> > > simplify extraction of identity? and also there are other use cases
> where
> > > user's will extract SubjectAltName to construct the identity I guess
> thats
> > > not going to supported by this method.
> > >
> > > Thanks,
> > > Harsha
> > >
> > > On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> > > > Hi Rajini,
> > > >
> > > > I don't have strong reasons for rejecting Option 2. I just felt
> Option 1
> > > is
> > > > sufficient for
> > > > the common use-cases (extracting single field, like CN etc..).
> > > >
> > > > We are open to go with Option 2, for more flexible mapping mechanism.
> > > > Let us know, your preference.
> > > >
> > > > Thanks,
> > > >
> > > >
> > > > On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <
> rajinisivaram@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Manikumar,
> > > > >
> > > > > It wasn't entirely clear to me why Option 2 was rejected.
> > > > >
> > > > > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <
> manikumar.reddy@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > We would like to go with Option 1, which adds a new configuration
> > > > > parameter
> > > > > > pair of the form:
> > > > > > ssl.principal.mapping.pattern, ssl.principal.mapping.value. This
> will
> > > > > > fulfill the requirement for most of the common use cases.
> > > > > >
> > > > > > We would like to include the KIP in the upcoming release. If
> there no
> > > > > > concerns, would like to start vote on this KIP.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <
> pshah@hortonworks.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Definitely a helpful change. +1 for Option 2.
> > > > > > >
> > > > > > > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > Hi Eno,
> > > > > > >
> > > > > > > Thanks for the review.
> > > > > > >
> > > > > > > Most often users want to extract one of the field (eg.
> CN). CN
> > > is
> > > > > the
> > > > > > > commonly used field.
> > > > > > > For this simple change, users need to build and maintain
> the
> > > custom
> > > > > > > principal builder class
> > > > > > > and also package and deploy to the all brokers. Having
> > > configurable
> > > > > > > rules
> > > > > > > will be useful.
> > > > > > >
> > > > > > > Proposed mapping rules works on string representation of
> the
> > > X.500
> > > > > > > distinguished name(RFC2253 format) [1].
> > > > > > > Mapping rules can use the attribute types keywords defined
> in
> > > RFC
> > > > > > 2253
> > > > > > > (CN,
> > > > > > > L, ST, O, OU, C, STREET, DC, UID).
> > > > > > >
> > > > > > > Any additional/custom attribute types are emitted as OIDs.
> To
> > > emit
> > > > > > > additional attribute type keys,
> > > > > > > we need to have OID -> attribute type keyword String
> > > mapping.[2]
> > > > > > >
> > > > > > > For example, String representation of
> X500Principal("CN=Duke,
> > > > > > > OU=JavaSoft,
> > > > > > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > > > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > > > > 160d7465737440746573742e636f6d"
> > > > > > >
> > > > > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > > > > "emailAddress"),
> > > > > > > the string will be
> > > > > > > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > > > > > > test@test.com"
> > > > > > >
> > > > > > > Since we are not passing this mapping, we can not extarct
> using
> > > > > > > additional
> > > > > > > attribute type keyword string.
> > > > > > > If the user want to extract additional attribute keys, we
> need
> > > to
> > > > > > write
> > > > > > > custom principal builder class.
> > > > > > >
> > > > > > > Hope the above helps. Update the KIP.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > X500Principal.html#getName(java.lang.String)
> > > > > > >
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > > > > eno.thereska@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Manikumar, thanks. If I understand the KIP motivation
> right,
> > > this
> > > > > > is
> > > > > > > > currently already possible, but you want to have an
> easier
> > > way of
> > > > > > > doing it,
> > > > > > > > right? The motivation would be stronger if we had 2-3
> common
> > > > > cases
> > > > > > > (from
> > > > > > > > experience) where the suggested pattern would solve
> them, and
> > > > > > > perhaps 1-2
> > > > > > > > cases where the pattern would not be adequate and we'd
> have
> > > to
> > > > > fall
> > > > > > > back to
> > > > > > > > the existing builder class.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Eno
> > > > > > > >
> > > > > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > > > > manikumar.reddy@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi All,
> > > > > > > > >
> > > > > > > > > We'd appreciate any thoughts / comments on the proposed
> > > options
> > > > > > for
> > > > > > > > > customizing SSL principal names.
> > > > > > > > > We are happy to discuss any alternative
> > > approaches/suggestions.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > > > > manikumar.reddy@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > I have created a KIP that proposes couple of options
> for
> > > > > > building
> > > > > > > > custom
> > > > > > > > > > SSL principal names.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > https://cwiki.apache.org/
> confluence/display/KAFKA/KIP-
> > > > > > > > >
> > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > > > > >
> > > > > > > > > > Please take a look.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Manikumar
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL principal
name
Posted by Harsha <ka...@harsha.io>.
Thanks. I am also leaning towards option 2, as it will help the consistency of expressing such mapping between sasl and ssl.
-Harsha
On Tue, Sep 18, 2018, at 8:27 PM, Manikumar wrote:
> Hi Harsha,
>
> Thanks for the review. Yes, As mentioned on the motivation section, this is
> to simply extracting fields from the certificates
> for the common use cases. Yes, we are not supporting extracting
> SubjectAltName using this KIP.
>
> Thanks,
>
>
> On Wed, Sep 19, 2018 at 8:29 AM Harsha <ka...@harsha.io> wrote:
>
> > Hi Manikumar,
> > I am interested to know the reason for exposing this config, given
> > a user has access to PrincipalBuilder interface to build their
> > interpretation of an identity from the X509 certificates. Is this to
> > simplify extraction of identity? and also there are other use cases where
> > user's will extract SubjectAltName to construct the identity I guess thats
> > not going to supported by this method.
> >
> > Thanks,
> > Harsha
> >
> > On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> > > Hi Rajini,
> > >
> > > I don't have strong reasons for rejecting Option 2. I just felt Option 1
> > is
> > > sufficient for
> > > the common use-cases (extracting single field, like CN etc..).
> > >
> > > We are open to go with Option 2, for more flexible mapping mechanism.
> > > Let us know, your preference.
> > >
> > > Thanks,
> > >
> > >
> > > On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <ra...@gmail.com>
> > > wrote:
> > >
> > > > Hi Manikumar,
> > > >
> > > > It wasn't entirely clear to me why Option 2 was rejected.
> > > >
> > > > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <ma...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We would like to go with Option 1, which adds a new configuration
> > > > parameter
> > > > > pair of the form:
> > > > > ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
> > > > > fulfill the requirement for most of the common use cases.
> > > > >
> > > > > We would like to include the KIP in the upcoming release. If there no
> > > > > concerns, would like to start vote on this KIP.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <pshah@hortonworks.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Definitely a helpful change. +1 for Option 2.
> > > > > >
> > > > > > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com>
> > wrote:
> > > > > >
> > > > > > Hi Eno,
> > > > > >
> > > > > > Thanks for the review.
> > > > > >
> > > > > > Most often users want to extract one of the field (eg. CN). CN
> > is
> > > > the
> > > > > > commonly used field.
> > > > > > For this simple change, users need to build and maintain the
> > custom
> > > > > > principal builder class
> > > > > > and also package and deploy to the all brokers. Having
> > configurable
> > > > > > rules
> > > > > > will be useful.
> > > > > >
> > > > > > Proposed mapping rules works on string representation of the
> > X.500
> > > > > > distinguished name(RFC2253 format) [1].
> > > > > > Mapping rules can use the attribute types keywords defined in
> > RFC
> > > > > 2253
> > > > > > (CN,
> > > > > > L, ST, O, OU, C, STREET, DC, UID).
> > > > > >
> > > > > > Any additional/custom attribute types are emitted as OIDs. To
> > emit
> > > > > > additional attribute type keys,
> > > > > > we need to have OID -> attribute type keyword String
> > mapping.[2]
> > > > > >
> > > > > > For example, String representation of X500Principal("CN=Duke,
> > > > > > OU=JavaSoft,
> > > > > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > > > 160d7465737440746573742e636f6d"
> > > > > >
> > > > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > > > "emailAddress"),
> > > > > > the string will be
> > > > > > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > > > > > test@test.com"
> > > > > >
> > > > > > Since we are not passing this mapping, we can not extarct using
> > > > > > additional
> > > > > > attribute type keyword string.
> > > > > > If the user want to extract additional attribute keys, we need
> > to
> > > > > write
> > > > > > custom principal builder class.
> > > > > >
> > > > > > Hope the above helps. Update the KIP.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > X500Principal.html#getName(java.lang.String)
> > > > > >
> > > > > > [2]
> > > > > >
> > > > > >
> > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > > > eno.thereska@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Manikumar, thanks. If I understand the KIP motivation right,
> > this
> > > > > is
> > > > > > > currently already possible, but you want to have an easier
> > way of
> > > > > > doing it,
> > > > > > > right? The motivation would be stronger if we had 2-3 common
> > > > cases
> > > > > > (from
> > > > > > > experience) where the suggested pattern would solve them, and
> > > > > > perhaps 1-2
> > > > > > > cases where the pattern would not be adequate and we'd have
> > to
> > > > fall
> > > > > > back to
> > > > > > > the existing builder class.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Eno
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > > > manikumar.reddy@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > We'd appreciate any thoughts / comments on the proposed
> > options
> > > > > for
> > > > > > > > customizing SSL principal names.
> > > > > > > > We are happy to discuss any alternative
> > approaches/suggestions.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > > > manikumar.reddy@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > I have created a KIP that proposes couple of options for
> > > > > building
> > > > > > > custom
> > > > > > > > > SSL principal names.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > > >
> > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > > > >
> > > > > > > > > Please take a look.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Manikumar
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> >
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Hi Harsha,
Thanks for the review. Yes, As mentioned on the motivation section, this is
to simply extracting fields from the certificates
for the common use cases. Yes, we are not supporting extracting
SubjectAltName using this KIP.
Thanks,
On Wed, Sep 19, 2018 at 8:29 AM Harsha <ka...@harsha.io> wrote:
> Hi Manikumar,
> I am interested to know the reason for exposing this config, given
> a user has access to PrincipalBuilder interface to build their
> interpretation of an identity from the X509 certificates. Is this to
> simplify extraction of identity? and also there are other use cases where
> user's will extract SubjectAltName to construct the identity I guess thats
> not going to supported by this method.
>
> Thanks,
> Harsha
>
> On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> > Hi Rajini,
> >
> > I don't have strong reasons for rejecting Option 2. I just felt Option 1
> is
> > sufficient for
> > the common use-cases (extracting single field, like CN etc..).
> >
> > We are open to go with Option 2, for more flexible mapping mechanism.
> > Let us know, your preference.
> >
> > Thanks,
> >
> >
> > On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <ra...@gmail.com>
> > wrote:
> >
> > > Hi Manikumar,
> > >
> > > It wasn't entirely clear to me why Option 2 was rejected.
> > >
> > > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <ma...@gmail.com>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > We would like to go with Option 1, which adds a new configuration
> > > parameter
> > > > pair of the form:
> > > > ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
> > > > fulfill the requirement for most of the common use cases.
> > > >
> > > > We would like to include the KIP in the upcoming release. If there no
> > > > concerns, would like to start vote on this KIP.
> > > >
> > > > Thanks,
> > > >
> > > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <pshah@hortonworks.com
> >
> > > > wrote:
> > > >
> > > > > Definitely a helpful change. +1 for Option 2.
> > > > >
> > > > > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com>
> wrote:
> > > > >
> > > > > Hi Eno,
> > > > >
> > > > > Thanks for the review.
> > > > >
> > > > > Most often users want to extract one of the field (eg. CN). CN
> is
> > > the
> > > > > commonly used field.
> > > > > For this simple change, users need to build and maintain the
> custom
> > > > > principal builder class
> > > > > and also package and deploy to the all brokers. Having
> configurable
> > > > > rules
> > > > > will be useful.
> > > > >
> > > > > Proposed mapping rules works on string representation of the
> X.500
> > > > > distinguished name(RFC2253 format) [1].
> > > > > Mapping rules can use the attribute types keywords defined in
> RFC
> > > > 2253
> > > > > (CN,
> > > > > L, ST, O, OU, C, STREET, DC, UID).
> > > > >
> > > > > Any additional/custom attribute types are emitted as OIDs. To
> emit
> > > > > additional attribute type keys,
> > > > > we need to have OID -> attribute type keyword String
> mapping.[2]
> > > > >
> > > > > For example, String representation of X500Principal("CN=Duke,
> > > > > OU=JavaSoft,
> > > > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > > 160d7465737440746573742e636f6d"
> > > > >
> > > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > > "emailAddress"),
> > > > > the string will be
> > > > > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > > > > test@test.com"
> > > > >
> > > > > Since we are not passing this mapping, we can not extarct using
> > > > > additional
> > > > > attribute type keyword string.
> > > > > If the user want to extract additional attribute keys, we need
> to
> > > > write
> > > > > custom principal builder class.
> > > > >
> > > > > Hope the above helps. Update the KIP.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > X500Principal.html#getName(java.lang.String)
> > > > >
> > > > > [2]
> > > > >
> > > > >
> https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > > >
> > > > > Thanks
> > > > >
> > > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > > eno.thereska@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Manikumar, thanks. If I understand the KIP motivation right,
> this
> > > > is
> > > > > > currently already possible, but you want to have an easier
> way of
> > > > > doing it,
> > > > > > right? The motivation would be stronger if we had 2-3 common
> > > cases
> > > > > (from
> > > > > > experience) where the suggested pattern would solve them, and
> > > > > perhaps 1-2
> > > > > > cases where the pattern would not be adequate and we'd have
> to
> > > fall
> > > > > back to
> > > > > > the existing builder class.
> > > > > >
> > > > > > Thanks
> > > > > > Eno
> > > > > >
> > > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > > manikumar.reddy@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > We'd appreciate any thoughts / comments on the proposed
> options
> > > > for
> > > > > > > customizing SSL principal names.
> > > > > > > We are happy to discuss any alternative
> approaches/suggestions.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > > manikumar.reddy@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I have created a KIP that proposes couple of options for
> > > > building
> > > > > > custom
> > > > > > > > SSL principal names.
> > > > > > > >
> > > > > > > >
> > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > >
> 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > > >
> > > > > > > > Please take a look.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Manikumar
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL principal
name
Posted by Harsha <ka...@harsha.io>.
Hi Manikumar,
I am interested to know the reason for exposing this config, given a user has access to PrincipalBuilder interface to build their interpretation of an identity from the X509 certificates. Is this to simplify extraction of identity? and also there are other use cases where user's will extract SubjectAltName to construct the identity I guess thats not going to supported by this method.
Thanks,
Harsha
On Tue, Sep 18, 2018, at 8:25 AM, Manikumar wrote:
> Hi Rajini,
>
> I don't have strong reasons for rejecting Option 2. I just felt Option 1 is
> sufficient for
> the common use-cases (extracting single field, like CN etc..).
>
> We are open to go with Option 2, for more flexible mapping mechanism.
> Let us know, your preference.
>
> Thanks,
>
>
> On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <ra...@gmail.com>
> wrote:
>
> > Hi Manikumar,
> >
> > It wasn't entirely clear to me why Option 2 was rejected.
> >
> > On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <ma...@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > We would like to go with Option 1, which adds a new configuration
> > parameter
> > > pair of the form:
> > > ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
> > > fulfill the requirement for most of the common use cases.
> > >
> > > We would like to include the KIP in the upcoming release. If there no
> > > concerns, would like to start vote on this KIP.
> > >
> > > Thanks,
> > >
> > > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <ps...@hortonworks.com>
> > > wrote:
> > >
> > > > Definitely a helpful change. +1 for Option 2.
> > > >
> > > > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com> wrote:
> > > >
> > > > Hi Eno,
> > > >
> > > > Thanks for the review.
> > > >
> > > > Most often users want to extract one of the field (eg. CN). CN is
> > the
> > > > commonly used field.
> > > > For this simple change, users need to build and maintain the custom
> > > > principal builder class
> > > > and also package and deploy to the all brokers. Having configurable
> > > > rules
> > > > will be useful.
> > > >
> > > > Proposed mapping rules works on string representation of the X.500
> > > > distinguished name(RFC2253 format) [1].
> > > > Mapping rules can use the attribute types keywords defined in RFC
> > > 2253
> > > > (CN,
> > > > L, ST, O, OU, C, STREET, DC, UID).
> > > >
> > > > Any additional/custom attribute types are emitted as OIDs. To emit
> > > > additional attribute type keys,
> > > > we need to have OID -> attribute type keyword String mapping.[2]
> > > >
> > > > For example, String representation of X500Principal("CN=Duke,
> > > > OU=JavaSoft,
> > > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > > 160d7465737440746573742e636f6d"
> > > >
> > > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > > "emailAddress"),
> > > > the string will be
> > > > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > > > test@test.com"
> > > >
> > > > Since we are not passing this mapping, we can not extarct using
> > > > additional
> > > > attribute type keyword string.
> > > > If the user want to extract additional attribute keys, we need to
> > > write
> > > > custom principal builder class.
> > > >
> > > > Hope the above helps. Update the KIP.
> > > >
> > > > [1]
> > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > X500Principal.html#getName(java.lang.String)
> > > >
> > > > [2]
> > > >
> > > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > > >
> > > > Thanks
> > > >
> > > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> > eno.thereska@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Manikumar, thanks. If I understand the KIP motivation right, this
> > > is
> > > > > currently already possible, but you want to have an easier way of
> > > > doing it,
> > > > > right? The motivation would be stronger if we had 2-3 common
> > cases
> > > > (from
> > > > > experience) where the suggested pattern would solve them, and
> > > > perhaps 1-2
> > > > > cases where the pattern would not be adequate and we'd have to
> > fall
> > > > back to
> > > > > the existing builder class.
> > > > >
> > > > > Thanks
> > > > > Eno
> > > > >
> > > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > > manikumar.reddy@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > We'd appreciate any thoughts / comments on the proposed options
> > > for
> > > > > > customizing SSL principal names.
> > > > > > We are happy to discuss any alternative approaches/suggestions.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > > manikumar.reddy@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have created a KIP that proposes couple of options for
> > > building
> > > > > custom
> > > > > > > SSL principal names.
> > > > > > >
> > > > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > > >
> > > > > > > Please take a look.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Manikumar
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Hi Rajini,
I don't have strong reasons for rejecting Option 2. I just felt Option 1 is
sufficient for
the common use-cases (extracting single field, like CN etc..).
We are open to go with Option 2, for more flexible mapping mechanism.
Let us know, your preference.
Thanks,
On Tue, Sep 18, 2018 at 8:05 PM Rajini Sivaram <ra...@gmail.com>
wrote:
> Hi Manikumar,
>
> It wasn't entirely clear to me why Option 2 was rejected.
>
> On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <ma...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > We would like to go with Option 1, which adds a new configuration
> parameter
> > pair of the form:
> > ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
> > fulfill the requirement for most of the common use cases.
> >
> > We would like to include the KIP in the upcoming release. If there no
> > concerns, would like to start vote on this KIP.
> >
> > Thanks,
> >
> > On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <ps...@hortonworks.com>
> > wrote:
> >
> > > Definitely a helpful change. +1 for Option 2.
> > >
> > > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com> wrote:
> > >
> > > Hi Eno,
> > >
> > > Thanks for the review.
> > >
> > > Most often users want to extract one of the field (eg. CN). CN is
> the
> > > commonly used field.
> > > For this simple change, users need to build and maintain the custom
> > > principal builder class
> > > and also package and deploy to the all brokers. Having configurable
> > > rules
> > > will be useful.
> > >
> > > Proposed mapping rules works on string representation of the X.500
> > > distinguished name(RFC2253 format) [1].
> > > Mapping rules can use the attribute types keywords defined in RFC
> > 2253
> > > (CN,
> > > L, ST, O, OU, C, STREET, DC, UID).
> > >
> > > Any additional/custom attribute types are emitted as OIDs. To emit
> > > additional attribute type keys,
> > > we need to have OID -> attribute type keyword String mapping.[2]
> > >
> > > For example, String representation of X500Principal("CN=Duke,
> > > OU=JavaSoft,
> > > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > > will be "CN=Duke,OU=JavaSoft,O=Sun
> > > Microsystems,C=US,1.2.840.113549.1.9.1=#
> > 160d7465737440746573742e636f6d"
> > >
> > > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > > "emailAddress"),
> > > the string will be
> > > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > > test@test.com"
> > >
> > > Since we are not passing this mapping, we can not extarct using
> > > additional
> > > attribute type keyword string.
> > > If the user want to extract additional attribute keys, we need to
> > write
> > > custom principal builder class.
> > >
> > > Hope the above helps. Update the KIP.
> > >
> > > [1]
> > >
> > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > X500Principal.html#getName(java.lang.String)
> > >
> > > [2]
> > >
> > > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> > X500Principal.html#getName(java.lang.String,%20java.util.Map)
> > >
> > > Thanks
> > >
> > > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <
> eno.thereska@gmail.com
> > >
> > > wrote:
> > >
> > > > Manikumar, thanks. If I understand the KIP motivation right, this
> > is
> > > > currently already possible, but you want to have an easier way of
> > > doing it,
> > > > right? The motivation would be stronger if we had 2-3 common
> cases
> > > (from
> > > > experience) where the suggested pattern would solve them, and
> > > perhaps 1-2
> > > > cases where the pattern would not be adequate and we'd have to
> fall
> > > back to
> > > > the existing builder class.
> > > >
> > > > Thanks
> > > > Eno
> > > >
> > > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > > manikumar.reddy@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We'd appreciate any thoughts / comments on the proposed options
> > for
> > > > > customizing SSL principal names.
> > > > > We are happy to discuss any alternative approaches/suggestions.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > > manikumar.reddy@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I have created a KIP that proposes couple of options for
> > building
> > > > custom
> > > > > > SSL principal names.
> > > > > >
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > > >
> > > > > > Please take a look.
> > > > > >
> > > > > > Thanks,
> > > > > > Manikumar
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Rajini Sivaram <ra...@gmail.com>.
Hi Manikumar,
It wasn't entirely clear to me why Option 2 was rejected.
On Tue, Sep 18, 2018 at 7:47 AM, Manikumar <ma...@gmail.com>
wrote:
> Hi All,
>
> We would like to go with Option 1, which adds a new configuration parameter
> pair of the form:
> ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
> fulfill the requirement for most of the common use cases.
>
> We would like to include the KIP in the upcoming release. If there no
> concerns, would like to start vote on this KIP.
>
> Thanks,
>
> On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <ps...@hortonworks.com>
> wrote:
>
> > Definitely a helpful change. +1 for Option 2.
> >
> > On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com> wrote:
> >
> > Hi Eno,
> >
> > Thanks for the review.
> >
> > Most often users want to extract one of the field (eg. CN). CN is the
> > commonly used field.
> > For this simple change, users need to build and maintain the custom
> > principal builder class
> > and also package and deploy to the all brokers. Having configurable
> > rules
> > will be useful.
> >
> > Proposed mapping rules works on string representation of the X.500
> > distinguished name(RFC2253 format) [1].
> > Mapping rules can use the attribute types keywords defined in RFC
> 2253
> > (CN,
> > L, ST, O, OU, C, STREET, DC, UID).
> >
> > Any additional/custom attribute types are emitted as OIDs. To emit
> > additional attribute type keys,
> > we need to have OID -> attribute type keyword String mapping.[2]
> >
> > For example, String representation of X500Principal("CN=Duke,
> > OU=JavaSoft,
> > O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> > will be "CN=Duke,OU=JavaSoft,O=Sun
> > Microsystems,C=US,1.2.840.113549.1.9.1=#
> 160d7465737440746573742e636f6d"
> >
> > If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> > "emailAddress"),
> > the string will be
> > "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> > test@test.com"
> >
> > Since we are not passing this mapping, we can not extarct using
> > additional
> > attribute type keyword string.
> > If the user want to extract additional attribute keys, we need to
> write
> > custom principal builder class.
> >
> > Hope the above helps. Update the KIP.
> >
> > [1]
> >
> > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> X500Principal.html#getName(java.lang.String)
> >
> > [2]
> >
> > https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/
> X500Principal.html#getName(java.lang.String,%20java.util.Map)
> >
> > Thanks
> >
> > On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <eno.thereska@gmail.com
> >
> > wrote:
> >
> > > Manikumar, thanks. If I understand the KIP motivation right, this
> is
> > > currently already possible, but you want to have an easier way of
> > doing it,
> > > right? The motivation would be stronger if we had 2-3 common cases
> > (from
> > > experience) where the suggested pattern would solve them, and
> > perhaps 1-2
> > > cases where the pattern would not be adequate and we'd have to fall
> > back to
> > > the existing builder class.
> > >
> > > Thanks
> > > Eno
> > >
> > > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> > manikumar.reddy@gmail.com>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > We'd appreciate any thoughts / comments on the proposed options
> for
> > > > customizing SSL principal names.
> > > > We are happy to discuss any alternative approaches/suggestions.
> > > >
> > > > Thanks,
> > > >
> > > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> > manikumar.reddy@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I have created a KIP that proposes couple of options for
> building
> > > custom
> > > > > SSL principal names.
> > > > >
> > > > >
> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > > >
> > > > > Please take a look.
> > > > >
> > > > > Thanks,
> > > > > Manikumar
> > > > >
> > > >
> > >
> >
> >
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Hi All,
We would like to go with Option 1, which adds a new configuration parameter
pair of the form:
ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
fulfill the requirement for most of the common use cases.
We would like to include the KIP in the upcoming release. If there no
concerns, would like to start vote on this KIP.
Thanks,
On Fri, Sep 14, 2018 at 11:32 PM Priyank Shah <ps...@hortonworks.com> wrote:
> Definitely a helpful change. +1 for Option 2.
>
> On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com> wrote:
>
> Hi Eno,
>
> Thanks for the review.
>
> Most often users want to extract one of the field (eg. CN). CN is the
> commonly used field.
> For this simple change, users need to build and maintain the custom
> principal builder class
> and also package and deploy to the all brokers. Having configurable
> rules
> will be useful.
>
> Proposed mapping rules works on string representation of the X.500
> distinguished name(RFC2253 format) [1].
> Mapping rules can use the attribute types keywords defined in RFC 2253
> (CN,
> L, ST, O, OU, C, STREET, DC, UID).
>
> Any additional/custom attribute types are emitted as OIDs. To emit
> additional attribute type keys,
> we need to have OID -> attribute type keyword String mapping.[2]
>
> For example, String representation of X500Principal("CN=Duke,
> OU=JavaSoft,
> O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
> will be "CN=Duke,OU=JavaSoft,O=Sun
> Microsystems,C=US,1.2.840.113549.1.9.1=#160d7465737440746573742e636f6d"
>
> If we have the OID - key mapping ("1.2.840.113549.1.9.1",
> "emailAddress"),
> the string will be
> "CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=
> test@test.com"
>
> Since we are not passing this mapping, we can not extarct using
> additional
> attribute type keyword string.
> If the user want to extract additional attribute keys, we need to write
> custom principal builder class.
>
> Hope the above helps. Update the KIP.
>
> [1]
>
> https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String)
>
> [2]
>
> https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String,%20java.util.Map)
>
> Thanks
>
> On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <en...@gmail.com>
> wrote:
>
> > Manikumar, thanks. If I understand the KIP motivation right, this is
> > currently already possible, but you want to have an easier way of
> doing it,
> > right? The motivation would be stronger if we had 2-3 common cases
> (from
> > experience) where the suggested pattern would solve them, and
> perhaps 1-2
> > cases where the pattern would not be adequate and we'd have to fall
> back to
> > the existing builder class.
> >
> > Thanks
> > Eno
> >
> > On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <
> manikumar.reddy@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > We'd appreciate any thoughts / comments on the proposed options for
> > > customizing SSL principal names.
> > > We are happy to discuss any alternative approaches/suggestions.
> > >
> > > Thanks,
> > >
> > > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <
> manikumar.reddy@gmail.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have created a KIP that proposes couple of options for building
> > custom
> > > > SSL principal names.
> > > >
> > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > > >
> > > > Please take a look.
> > > >
> > > > Thanks,
> > > > Manikumar
> > > >
> > >
> >
>
>
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Priyank Shah <ps...@hortonworks.com>.
Definitely a helpful change. +1 for Option 2.
On 9/14/18, 10:52 AM, "Manikumar" <ma...@gmail.com> wrote:
Hi Eno,
Thanks for the review.
Most often users want to extract one of the field (eg. CN). CN is the
commonly used field.
For this simple change, users need to build and maintain the custom
principal builder class
and also package and deploy to the all brokers. Having configurable rules
will be useful.
Proposed mapping rules works on string representation of the X.500
distinguished name(RFC2253 format) [1].
Mapping rules can use the attribute types keywords defined in RFC 2253 (CN,
L, ST, O, OU, C, STREET, DC, UID).
Any additional/custom attribute types are emitted as OIDs. To emit
additional attribute type keys,
we need to have OID -> attribute type keyword String mapping.[2]
For example, String representation of X500Principal("CN=Duke, OU=JavaSoft,
O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
will be "CN=Duke,OU=JavaSoft,O=Sun
Microsystems,C=US,1.2.840.113549.1.9.1=#160d7465737440746573742e636f6d"
If we have the OID - key mapping ("1.2.840.113549.1.9.1", "emailAddress"),
the string will be
"CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=test@test.com"
Since we are not passing this mapping, we can not extarct using additional
attribute type keyword string.
If the user want to extract additional attribute keys, we need to write
custom principal builder class.
Hope the above helps. Update the KIP.
[1]
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String)
[2]
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String,%20java.util.Map)
Thanks
On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <en...@gmail.com> wrote:
> Manikumar, thanks. If I understand the KIP motivation right, this is
> currently already possible, but you want to have an easier way of doing it,
> right? The motivation would be stronger if we had 2-3 common cases (from
> experience) where the suggested pattern would solve them, and perhaps 1-2
> cases where the pattern would not be adequate and we'd have to fall back to
> the existing builder class.
>
> Thanks
> Eno
>
> On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <ma...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > We'd appreciate any thoughts / comments on the proposed options for
> > customizing SSL principal names.
> > We are happy to discuss any alternative approaches/suggestions.
> >
> > Thanks,
> >
> > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <ma...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have created a KIP that proposes couple of options for building
> custom
> > > SSL principal names.
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > >
> > > Please take a look.
> > >
> > > Thanks,
> > > Manikumar
> > >
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Hi Eno,
Thanks for the review.
Most often users want to extract one of the field (eg. CN). CN is the
commonly used field.
For this simple change, users need to build and maintain the custom
principal builder class
and also package and deploy to the all brokers. Having configurable rules
will be useful.
Proposed mapping rules works on string representation of the X.500
distinguished name(RFC2253 format) [1].
Mapping rules can use the attribute types keywords defined in RFC 2253 (CN,
L, ST, O, OU, C, STREET, DC, UID).
Any additional/custom attribute types are emitted as OIDs. To emit
additional attribute type keys,
we need to have OID -> attribute type keyword String mapping.[2]
For example, String representation of X500Principal("CN=Duke, OU=JavaSoft,
O=Sun Microsystems, C=US, EMAILADDRESS=test@test.com")
will be "CN=Duke,OU=JavaSoft,O=Sun
Microsystems,C=US,1.2.840.113549.1.9.1=#160d7465737440746573742e636f6d"
If we have the OID - key mapping ("1.2.840.113549.1.9.1", "emailAddress"),
the string will be
"CN=Duke,OU=JavaSoft,O=Sun Microsystems,C=US,emailAddress=test@test.com"
Since we are not passing this mapping, we can not extarct using additional
attribute type keyword string.
If the user want to extract additional attribute keys, we need to write
custom principal builder class.
Hope the above helps. Update the KIP.
[1]
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String)
[2]
https://docs.oracle.com/javase/7/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String,%20java.util.Map)
Thanks
On Fri, Sep 14, 2018 at 7:44 PM Eno Thereska <en...@gmail.com> wrote:
> Manikumar, thanks. If I understand the KIP motivation right, this is
> currently already possible, but you want to have an easier way of doing it,
> right? The motivation would be stronger if we had 2-3 common cases (from
> experience) where the suggested pattern would solve them, and perhaps 1-2
> cases where the pattern would not be adequate and we'd have to fall back to
> the existing builder class.
>
> Thanks
> Eno
>
> On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <ma...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > We'd appreciate any thoughts / comments on the proposed options for
> > customizing SSL principal names.
> > We are happy to discuss any alternative approaches/suggestions.
> >
> > Thanks,
> >
> > On Sat, Sep 8, 2018 at 12:45 AM Manikumar <ma...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I have created a KIP that proposes couple of options for building
> custom
> > > SSL principal names.
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> > >
> > > Please take a look.
> > >
> > > Thanks,
> > > Manikumar
> > >
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Eno Thereska <en...@gmail.com>.
Manikumar, thanks. If I understand the KIP motivation right, this is
currently already possible, but you want to have an easier way of doing it,
right? The motivation would be stronger if we had 2-3 common cases (from
experience) where the suggested pattern would solve them, and perhaps 1-2
cases where the pattern would not be adequate and we'd have to fall back to
the existing builder class.
Thanks
Eno
On Fri, Sep 14, 2018 at 12:36 PM, Manikumar <ma...@gmail.com>
wrote:
> Hi All,
>
> We'd appreciate any thoughts / comments on the proposed options for
> customizing SSL principal names.
> We are happy to discuss any alternative approaches/suggestions.
>
> Thanks,
>
> On Sat, Sep 8, 2018 at 12:45 AM Manikumar <ma...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I have created a KIP that proposes couple of options for building custom
> > SSL principal names.
> >
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
> >
> > Please take a look.
> >
> > Thanks,
> > Manikumar
> >
>
Re: [DISCUSS] KIP-371: Add a configuration to build custom SSL
principal name
Posted by Manikumar <ma...@gmail.com>.
Hi All,
We'd appreciate any thoughts / comments on the proposed options for
customizing SSL principal names.
We are happy to discuss any alternative approaches/suggestions.
Thanks,
On Sat, Sep 8, 2018 at 12:45 AM Manikumar <ma...@gmail.com> wrote:
> Hi all,
>
> I have created a KIP that proposes couple of options for building custom
> SSL principal names.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
>
> Please take a look.
>
> Thanks,
> Manikumar
>