-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code submission by Josh Roys [PATCH] Add LDAP cert publisher using LDAP auth DN #781
Comments
Comment from vakwetu (@vakwetu) at 2012-06-26 18:49:49 attachment |
Comment from awnuk (@awnuk) at 2012-11-13 21:46:28 Thank you for submitting the patch. Could you elaborate on the purpose and usage cases for your new mapper? |
Comment from roysjosh at 2012-11-13 21:55:12 Hello Andrew, You're welcome. The main reason this mapper was implemented was due to the unfortunate legacy requirements our environment had at the time we switched to Dogtag. The user certificate DN is created with values from LDAP (based off of the authenticating user) and is something like CN=$UID,OU=Foo,...,C=US. After attempting to use the existing mappers, I found no good way to lookup the original LDAP DN from the certificate DN. When I went poking around the internal DB I immediately noticed that the authenticating DN was saved providing a trivial map back to the entry to insert the userCertificate into. I didn't feel that this functionality belonged in an existing mapper, but I am also no Dogtag expert and would defer to your judgment. I do feel the usefulness of this mapper (trivial LDAP publishing if using LDAP authentication) extends beyond our somewhat convoluted needs even though in simpler environments other mappers would also meet customer needs. Thanks, Josh |
Comment from awnuk (@awnuk) at 2012-11-14 03:01:57 Hi Josh, |
Comment from awnuk (@awnuk) at 2012-11-14 03:15:52 Unfortunately not all of the mappers are documented but most of them are described here: |
Comment from roysjosh at 2012-11-14 16:28:22 Hello Andrew, DNCompsMap doesn't work for us due to the CN=$UID ugliness we do, SubjAttrMap would have added to account creation overhead, and SimpleMap IIRC required key=value which meant I couldn't specify the authenticated LDAP DN as the dnPattern (e.g. dnPattern:$req.authenticatedName or similar has no "key" before replacement). I seem to remember trying a few more complex patterns with SimpleMap and having issues possibly related to our OU hierarchy. In any event, the most likely existing mapper to work for us would be the SubjAttrMap. We simply chose a solution that required no extra overhead on our part. Thanks, Josh |
Comment from awnuk (@awnuk) at 2012-11-15 03:27:23 Hi Josh, I just noticed that some mapping options are referring to an older type of CA requests and I wonder if that played a role in inability to use existing mappers. Thank you, Andrew. |
Comment from vakwetu (@vakwetu) at 2017-02-27 13:57:55 Metadata Update from @vakwetu:
|
This issue was migrated from Pagure Issue #210. Originally filed by vakwetu (@vakwetu) on 2012-06-26 18:49:08:
#No Description Provided
The text was updated successfully, but these errors were encountered: