Identity Management in Quercus<>

LDAP

LDAP entries

An LDAP directory holds the records of many users. The record of an individual user is known as an entry.

Each entry is associated with a collection of attributes. An attribute has a name and one or more values.

Each LDAP directory has its own set of allowed attributes. These are defined in a schema. Typically attributes will be grouped into families such as general user details, address details, application accounts and so on.

A typical list of attributes is shown below.

Attribute

Description

cn

Name

c

Business country

department

Business department

givenname

First name

homephone

Home phone number

homepostaladdress

Home postal address

info

Notes

initials

Initials

l

Business city

mail

Email address

mobile

Home cellphone number

organizationname

Company name

otherfacsimiletelephonenumber

Home fax number

otherpager

Business pager number

physicaldeliveryofficename

Location of office at work

postaladdress

Business postal address

postalcode

Business postal code

sn

Last Name

st

Business state/province

telephonenumber

Business phone number

title

Job title

url

Business web page

LDAP groups

In addition to storing user profile information, LDAP servers often store information about user groups. These groups are simply named entities. They are known as LDAP groups.

The LDAP server does not use the groups for any purpose it simply maintains the groups. The ‘meaning’ of the groups is determined by the various systems which use the IDM and the links between users and LDAP groups are held in these systems.

Directory structure

LDAP directories have a tree structure similar to the folder structure of a computer’s operating system. So entries can be subdivided to reflect the structure organisation. Specific operations can be allowed or disallowed for particular branches of the tree.

Distinguished Names (DN)

Each LDAP directory entry has a unique identifier known as a Distinguished Name (DN). A DN specifies the position of an entry in the directory and is is similar, conceptually, to using a filepath as a unique resource identifier on a computer.

A DN is written left (most specific) to right (least specific) and looks something like this:

DN: uid=fwhite,ou=staff,dc=campusit,dc=org


However, because a DN may change when entries are moved within the tree structure, a user will also be uniquely identified (e.g. by the sAMAccountName or the userPrincipalName) in a way that provides a pointer to the user record that is independent of the DN.

Other names

Within the LDAP structure there are several other conventionally used abbreviations:

CN = Common Name

OU = Organizational Unit

DC = Domain Component

Example

So combining the various names and attributes the record of a typical user might look something like this:

dn: cn=Freddie White,dc=campusit,dc=org
cn: Freddie White
givenName: Freddie
sn: White
telephoneNumber: +353 123 456 789
mail: fwhite@campusit.org
manager: cn=Mary Black,dc=campusit,dc=org
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top


LDAP implementations supported in Quercus

Quercus supports the following LDAP implementations:

Apache Directory Server

Microsoft Active Directory

Novell eDirectory

OpenLDAP

Oracle Internet Directory

The CampusIT Embedded option

In addition, Quercus has its own IDM-equivalent option known as CampusIT Embedded. CampusIT Embedded provides you with an alternative identity management solution if you do not want Quercus to be integrated with an external IDM. CampusIT Embedded allows you to set up and maintain LDAP users and LDAP groups in the same way that an external LDAP solution would, except that its use is confined to Quercus. CampusIT Embedded allows you to run Quercus as a totally standalone system without dependency on any external LDAP server.

External LDAP system or the CampusIT Embedded option?

Given that you have a choice between using an external LDAP option or the CampusIT Embedded option, which should you use?

Benefits of an external IDM (Identity Management System)

If an institution’s users regularly need to switch between applications supplied by different vendors it may result in the need to memorise a different login and password combination for each system. This requirement may confuse users, resulting in regular loss of passwords and imposing a corresponding load on support staff.

In addition, a centralised IDM removes the need to maintain the same data in several different systems, reducing data redundancy and increasing data quality.

Drawbacks of an external IDM (Identity Management System)

Centralised IDMs may be complicated to maintain as they introduce additional requirements for secure data transport and communication between systems.

In addition, a central IDM may introduce the single-point-of-failure for all enterprise systems should the IDM become unavailable.

External versus CampusIT Embedded

Before making the decision to delegate Quercus authentication to a centralised IDM, you will need to work out where the balance lies between the advantages and disadvantages listed above.

Factors favouring an external IDM

Factors favouring the use of CampusIT Embedded

A typical user needs to access multiple enterprise systems

Users tend to be associated with specific systems

User’s level of privilege for each each individual system is based upon common criteria (for example membership of a specific division or office, role, seniority, location, etc.)

User’s level of privilege for each each individual system is specific to the operation of the system in question (e.g. power user, content creator)

Users find it difficult to manage multiple logins and passwords

Users are capable of managing multiple passwords and logins

High volume of user profile data stored. Many of the systems require access to the same nodes within this data set.

Limited need to share user profile data across systems

Reliable established messaging infrastructure allowing data transport between IDM and enterprise systems

Legacy messaging system infrastructure and IDM processes tightly coupled to local business rules

High availability of IDM can be guaranteed

High availability of IDM cannot be guaranteed

Good understanding within the enterprise of IDM functionality distributed across the technical team

Limited understanding within the enterprise of IDM functionality or understanding confined to a small number of individuals

Quick implementation without dependency on IT resources