Overview#
Groups are a
container with for
LDAP Entries (or really pointers to
LDAP Entries)
If LDAPWiki think of how applications work with LDAP. Typically an application will do one the following:
If an
application is using
Groups to manage users, the
application must:
- Search for a user LDAP Entry - You can not authenticate a user without knowing the user Fully Distinguished Name (FDN).
- Bind the User - The application would then need to authenticate the user.
- Search for the Group - The application must then find the Group of interest and retrieve the values contained in the Multi-Valued "Group Member Attribute" Attribute. The group to user relationship is often called a Forward Reference
- Once the group entry is identified, a LDAP compare may be done against the "Member Attribute" attribute to see if the FDN of the user is present.
This could imply:
- If there are 5,000 users that are members of the group, this will take some time.
- If there are 50,000 it may take a very long time. If there are 500,000 often the LDAP server will fail.
- If there are 50,000,000 the LDAP server will fail.
So, to make it easy for the user, the application asks for some type of short name. The application would then:
- Perform a LDAP search operation - to find the users FDN. Search operations can also return attribute values. So when searching for a users FDN, you could also ask for all the attribute values you are interested in retrieving. Like the user's role values.
- Determine Role Validation - Since we have the Role values, if the RoleValue did not match what was required, we could refuse the user access at this point.
- Bind the User - If the role validation passed, the application would then need to authenticate the user.
Using groups requires the LDAP application to deal with two objects. Using an attribute value, deals only with he user entry.
Why do we use Groups?#
There are two reasons:
- Legacy Thing - Groups have been a common entity within LDAP, NetWare and Microsoft Active Directory form the beginning.
- Simple - On the surface groups seem to be simple.
What Do Groups provide?#
When we look at a user, if it is eDirectory and all things are correct, we can see what
GroupMemberships the user is a member of.
When we look at a group, we can see who is a member of the group.
Cyclic Inheritance is an issue with
LDAP Groups and other
Access Control Models
Some Alternative Approaches#
Application Attribute#
Perhaps a better approach maybe to assign an attribute to every application that needs to control access to their application that can not be performed by existing attribute values.
Advantages of the Application Attribute#
The attribute would be created in the schema and then added to an appropriate auxillaryClass that is, or could be associated with the user entries.
The application owner or ID Administration team would then be able to populate that attribute with appropriate values on the user entry.
The attribute, if not single-valued, would allow multiple entries to be made to correspond to the applications needs. As an example, a user entry maybe populated with values of "user" and "admin". This could indicate the user entry is able to perform user roles and admin roles for the application.
- No backlinks required. Since the application attribute is of syntax of string, there are no backlinks.
- Need only populate on attribute to control access to an application.
- Security of whom can modify or read the attribute values can be tightly controlled. The rights to the application attribute could be assigned to the application owners so that only they could modify the values of the attribute and the ability to read the value could also be controlled.
What Can Application Base Attributes Provide#
When we look at a user we can see what values the ApplicationAttribute are provided.
If we want a list of users which possess an ApplicationAttribute value, we could do a search with (ApplicationAttribute=value). The results are all entries with the desired value.
On LDAP Compares, asking if a ApplicationAttribute=value when doing a LDAP compare returns true, if the value is present, or false if the value is NOT present.
Even simpler, if an Application attribute is protected by application interfaces, then a single attribute for all applications maybe used. as an Example:
app1:admin
app2:user
app3:manager
One attribute that provides roles for more than one application. If a custom front end is used to protect who can change the one application attribute, this may be all that is needed.
References from other on issues with Groups#
There might be more information for this subject on one of the following: