search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

Rewriter for member -> uniqueMember #4390

Open marknl opened 3 years ago

marknl commented 3 years ago

Is your feature request related to a problem? Please describe. I'd like to integrate vCenter and FreeIPA for authentication. vCenter needs groups to have "uniqueMember" attributes. FreeIPA doesn't support this. FreeIPA runs 389ds, hence the feature request here.

Describe the solution you'd like I would like to see a "uniqueMember" attribute in the groups that I search for. If possible besides the "member" attribute, so applications that do support "member" can remain using that and vCenter can use "uniqueMember". If that's not possible, it's also accepted to only return "uniqueMember".

Describe alternatives you've considered Talked to Red Hat support. They don't support this feature. I was referred by @tbordaz to either grab the example rewriter and make a custom rewriter or request a rewriter here. Since my knowledge of C++ is very limited, I'm making a feature request.

Thanks in advance.

tbordaz commented 3 years ago

Thanks @marknl for opening this issue. I fully support your demand that out of the box, 389-ds provides a rewriter 'member' -> 'uniqueMember'.

Firstyear commented 3 years ago

The main issue I see is that uniqueMember is an attribute in schema, so an entry that has both uniqueMember and member, the rewriter could conflict or be unclear. We also need to choose if this would be a virtual rewrite, and how the rewrite occures (does the attribute need to be requested, or is it supplied with * or +?). Or do we extract member in the write path and duplicate the values since uniqueMember and member have different syntaxes IIRC

attributeTypes: ( 2.5.4.31 NAME 'member'
  SUP distinguishedName
  X-ORIGIN 'RFC 4519' )

attributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
  EQUALITY uniqueMemberMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.34
  X-ORIGIN 'RFC 4519' )

https://ldapwiki.com/wiki/1.3.6.1.4.1.1466.115.121.1.34

I think there are some subtle and non-obvious traps we could land in here. Really, in a way what we want is not a rewriter, but an aliasing mechanism in this case to allow one attribute to map onto another when requested.

So I think some extra thought about the design and mechanics is needed, but expanding our application's we support is always a positive.