On pe, 07 loka 2016, Fraser Tweedale wrote:
On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:

Question, do we need search-and-replace at all (or at this
stage)? Most of the interesting values from the SAN should be
directly map-able to LDAP attributes. And processing the string
representation of <SUBJECT> might be tricky as discussed below.
Nevertheless the following might be possible:

* <SUBJECT:ldapAttributeName>/regexp/replacement/
* <SAN:O.I.D.:ldapAttributeName>/regexp/replacement/

where "/regexp/replacement/" stands for optional sed-like
substitution rules. E.g. a rule like

   <SUBJECT:samAccountName>/^CN=\([^,]*\).*$/\1/

would take the subject string
'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and
generate a LDAP search filter component
'(samAccountName=Certuser)' which can be included in a LDAP search
filter which includes additional components like e.g. an
objectClass.

A counter-proposal w.r.t. DN mapping:

   <SUBJECT:OID:ldapAttributeName>

Where OID is either an actual OID or the corresponding string i.e.
"CN", "O", etc.  This would extract the "most specific" (leftmost in
the LDAP sense, rightmost in the X.500 sense) attribute value of the
specified type from the Subject DN.

IMO this would cover most DN mapping use cases whilst avoiding regex
or confusion about RDN order.  Therefore your original example of:

   <SUBJECT:samAccountName>/^CN=\([^,]*\).*$/\1/

can be accomplished with:

   <SUBJECT:CN:samAccountName>

In the spirit of "make the simple things simple, and the hard things
possible" it is probably necessary to retain the regex variant to
handle more complex DN mapping use cases, e.g. where there are
multiple occurrences of a single attribute type, a particular fixed
RDN must be matched, etc.

w.r.t. SAN mapping, I concur that search/replace is probably not
needed.
How all these syntax extensions are going to handle multi-valued RDN?

--
/ Alexander Bokovoy
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to