It might make more sense if we have a generic ldap_dn field that can be applied to entities that want to be correlated with objects in LDAP. Currently each module supplies its own ldap_dn entity field (see ldap_user's ldap_user_current_dn field for an example).

There are any number of ldap objects that users might want to create in drupal and track based on ldap management (think: groups, conference rooms, etc). It would make a lot more sense if the ldap module provided an entity field for ldap dn, so that admins can go to the respective entity ui screens and apply this field to their desired bundles.

here are the use cases:

  1. admin goes to configuration -> account settings -> manage fields and adds the ldap_dn field to the user type (this could be automated via ldap_user module). This is especially relevant when the profile2 modules is in place. admins may only want certain types of users to be tracked via ldap.
  2. admin goes to structure -> content types -> 'group' and adds the ldap_dn field to the group so that ldap_og integration can reference the proper content type during authorization

lemme know what you think.
-Chris

Comments

johnbarclay’s picture

johnbarclay commented

The ldap_user_current_dn field in ldap_user is meant to play this role for ldap_user. ldap_user is required for any ldap modules that establish a relationship between a drupal user and ldap user (authentication, authorization, provisioning, etc.)

Are you suggesting creating an ldap_dn field type also that supports entity relationships? This makes sense. I believe the convention would be an ldap_dn module that provides the field. Are you wanting for these fields to have auto increment or uuids to be indexed to aid in querying also; or just text fields as ldap_user_current_dn is now?

Currently ldap_user_current_dn is not editable or visible and its simply a text field.

netw3rker’s picture

netw3rker commented

Are you suggesting creating an ldap_dn field type also that supports entity relationships?

That might be going a little too far. Really i'm just saying that the ldap api should provide a field / field type that entities/bundles can apply to help denote what ldap object that thing is tracking. this way we dont wind up with 20 different ldap dn tracking fields. I don't see a need for uuid/auto increment indexing since this field would just be a property of whatever object was created.

my initial proposed change would be to rename the ldap_user_current_dn field to simply ldap_dn, and move it to the ldap.module. then allow the ldap_user module to apply the ldap_dn field to the user entity (in the same way it does now).

make sense?

netw3rker’s picture

netw3rker commented

I believe the convention would be an ldap_dn module that provides the field.

I would agree with this to some extent. I was thinking there was a common api module that all of these modules relied on (EG: 'ldap' or 'ldap core'), but it appears that every module essentially occupies a distinct space, and really the only common one is 'ldap servers'. Given that there isn't a common core api module, we should probably just create an ldap_field module and set it as required by ldap_user & ldap_group (and any other entity groups)

should we consider having a common ldap api module? (this would become a separate issue in the issue queue)

johnbarclay’s picture

johnbarclay commented

ldap_servers is the api/core module. Its just named funny because I was working around a couple other developers initially, so I couldn't use ldap or ldap_api as those were taken. Its a good place for a field definition for now.

netw3rker’s picture

netw3rker commented

cool, I'll add it in there then. I think I see what you were talking about with the 'entity reference' idea. I'm going through the ldap_user's entity_fields definition & there are a bunch more fields than i expected. I sort of thought that i'd only see a user_dn field and thats it (this goes back to my days using the ldap_integration module). the fields I see now are:

  • ldap_user_puid
  • ldap_user_puid_id
  • ldap_user_puid_property
  • ldap_user_current_dn
  • ldap_user_prov_entries
  • ldap_user_last_checked

I'm going to guess that technically speaking, any item that needs to be linked to an ldap object would need the same number of fields and they would be similar to these. It would make sense in that case for these to be abstracted to an "ldap entity" that has all of these field values attached to it. That entity can then be referenced as a single field in any other entity/bundle that is attempting to relate to an ldap entry.

is that what you were thinking?

johnbarclay’s picture

johnbarclay commented

These fields all make sense for the drupal user - ldap user relationship which may be broken when CNs, uid, etc change. For groups, computers, printers, etc, I'm not sure if users are going to want to configure these things. Generally there is a sid or some other attribute that is common across all objects. So while the puid value may be useful, keeping track of puid_property per object type is not needed. Nor current_dn. Really the admin is probably best presented with the option of using dn or another attribute as the standard, "permanent" identifier for all objects. That narrows it down to storing one id per object.

johnbarclay’s picture

johnbarclay commented
Title: Generic ldap dn field » LDAP Server: Provide Generic ldap dn field

This could be a compound field with these sub fields:

dn
object_type
puid_id
puid_property
puid_property_is_binary

They would work for most use cases.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Issue summary: View changes
Status: Active » Closed (won't fix)

no update for > 12 months, no patches - closing