On Fri, Oct 07, 2016 at 09:35:00AM +0300, Alexander Bokovoy wrote: > 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? > In the variant I proposed, it is handled fine because it selects the "most specific" occurrence of that attribute type. An attribute type cannot appear twice in the same RDN so this is unambiguous.
For the regex variant, because `RDN ::= SET OF AVA' we would have to ensure that the stringified DN uses a deterministic order for attribute types (probably lexicographic order on corresponding LDAP attribute name) within a multi-valued RDN and clearly document this. It will be up to admins to define the correct regex based on naming of the certificates they use. Cheers, Fraser _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
