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

Reply via email to