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 <
> rajinisiva...@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.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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>
