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.re...@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" <manikumar.re...@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=t...@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=
> > t...@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.there...@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.re...@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.re...@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
> > > > >
> > > >
> > >
> >
> >
> >
>
