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.
Cheers,
Fraser
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
