LDAP and Role based permissions in LiveTime
LDAP servers are commonly used to centralize and manage staff access to corporate information such as IT infrastructure and resources. The problem with LDAP however is how best to structure and manage an organization’s authentication-based information. Whilst some servers allow for the easy modification of the LDAP schema, other servers are not so ‘customization friendly’.
The lack of a ‘best practice’ approach lead to an environment of fragmentation where-by many LDAP vendors have implemented variations of either a Schema Modification or Permissions Group approach. The following is an analysis of the two predominant approaches to structuring and managing LDAP access information as suggested by some of the leading LDAP vendors including Sun, IBM Oracle and Microsoft.
Schema Modification
Adding attributes to an LDAP schema is one approach to managing user access information. Microsoft’s ADS allows for schema modification, although In order to change the Active Directory Schema, a key needs to be acquired from Microsoft. At last check there was an associated fee for generating this key.
The biggest problem with this approach is the sheer volume of attributes that could potentially be assigned to a user. As such, this method is not recommended for storing access information. It should be noted also that this approach would require the directory administrator to update the role-based information for all applications.
Permissions Groups
Defining Groups for application roles is the alternative approach, and this seems to be the most common approach taken by the major industry players including Sun, IBM, Novell and Oracle. This approach sees groups defined for an application, or roles of an application.
The reason this approach is favored is due to the flexibility. Some recommendations extend to creating groups to control access down to specific pages of web applications. Groups can contain users, other Groups or even be defined as a query against the server to dynamically populate the group on request. Groups can even be referenced from alternate servers in some instances. This provides for an enterprise wide means of managing access information.
The net effect of this approach is one or more groups will be defined on the server for each application, and as such, the users of any application can be easily identified, as can their level of access.
SunONE – Access Control By Roles
Sun specify two approaches to managing access to resources – ‘Principal mapping’ & ‘Group mapping’.
Principal mapping is where by each user is added to the application, however according to Sun, this approach doesn’t scale well. This is similar to the first approach – schema modification.
Group mapping is where users are grouped together, and this group represents their level of access. This is an abbreviated description of the approach taken by LiveTime – Permissions Groups.
Details on securing J2EE application access using Sun ONE can be found here at:
http://java.sun.com/features/2002/10/appser_7.html
WebSphere Enterprise Applications
The approach taken by IBM for WebSphere applications (in this case Tivoli), is again very similar to the approach described by Sun, and consistent with the approach taken by LiveTime.
A detailed development example can be found here:
http://www-128.ibm.com/developerworks/tivoli/library/t-ldap04/index.html?ca=dgr-lnxw06LDAP-P4
Table 1 from above shows (in this one instance), three groups defined managing access permissions, firstly to the level of billing information available to each user, and then in Table 2, controlling access to servlets.
In this particular example, the ‘Group’ is referred to as a ‘Security Role’, but ultimately it is just an instance of an LDAP Group given the details are stored against the ‘memberOf’ attribute for each account on the LDAP Server. This is actually stated further into the article.
There is also further information specifically for websphere referring to the use of groups for controlling access to applications, and application roles here:
Oracle BPEL Developer Guide
One of the more recent products out of Oracle is their BPEL (Business Process Expression Language) integration suite of tools, to allow users to customize their business processes as supported by Oracle.
There is a sample for how to configure access to the process configuration here:
http://docs.huihoo.com/oracle/docs/B14099_19/integrate.1012/b14448/appx_users.htm#CIHBGBBD
Section F.1.1 breaks the problem down into Users, Application Roles and Enterprise Groups. Table F-2 details the application roles, and Table F-3 shows how these map to LDAP Group definitions.
Convergence of disparate approaches
The Oracle BPEL experience is significant as this is a more recent example, and indicates a clear industry trend to define role based permissions as a one-to-one mapping with groups defined on an LDAP server. This approach is the most suitable for enterprise development as it is also compatible with Active Directory.
Novell eDirectory also follows the Permissions Group approach, and there are documents available online to support the statement that a clear trend has emerged in how best to control application access.
The LiveTime Approach – Permissions Groups
LiveTime R&D considered the LDAP organization issues in 2005, and implemented a Role based approach. At the time it seemed the most consistent way to control application access across all server platforms. This consistency across implementations can be attributed as a major reason for the industry moving in this direction.
It should be noted that both approaches represent an overhead for the directory server administrator as either way the roles need to be managed. Ultimately though, the LDAP server is the repository for access and authorization information, and where an LDAP server is used in this fashion, best practice would dictate that this should be centralized – not spread out over multiple administration consoles.
The most common argument against the Permissions Groups approach is most likely to be associated with the need for a paper trail. In real terms though, the typical case for changing access to LiveTime will have a paper trail. It is reasonable to expect Human Resources activities, such as Hiring, Firing, Promotion and Demotion to be the predominant reasons for needing changes to the helpdesk &/or support site access permissions. There is obviously a paper trail for these functions.
In a similar thread – the initial setup overhead of adding all the users to groups could be a slight burden. This can be quite easily overcome on all servers except Active Directory by using Dynamic Groups for the definition of the Customers Group. In Active Directory environments, the accounts will need to be added, but a carefully constructed ldap query string would reduce this burden also.
The only use case for the Schema Modification approach is when an organization requires the frequent swapping LDAP access privileges This use case arises when organizations are frequently re-assigning application licenses. As this behavior is often seen as a breach of the license terms, it should not be a consideration.