The Oak LDAP service is intended to enable authorisation decisions to be taken by service providers in the University. Data on unit affiliations (departments and colleges), and the nature of people's relationships with the University (student, staff, etc) are provided. The directory information in Oak LDAP can also be used to map between people's different identifiers (SSO username, barcode, etc), and to retrieve contact data and names for people and units.
It is possible to look up people by their card's barcode number, by their email address, or by their Oak single sign-on (SSO) username. This ability to look someone up by their Oak SSO username makes the service especially useful in conjunction with the Oak Kerberos and Webauth Authentication Services.
An example of the type of policy that can be implemented with data from the Oak LDAP service is "only people affiliated with Department X can use Service Y". Another example is "only members of the University can use Service Z".
The directory contains entries about all University members, and some non-members, such as virtual access card holders. In principle, it could contain entries about anyone whose relationship with the University justifies inclusion.
- Which Kerberos principal(s) should be granted access to Oak LDAP for this service?
- If you're adding simple authorisation to an existing WebAuth-protected
mod_webauthldap, we can grant access to the existing WebAuth principal(s)
- Otherwise, we'll create a new principal
oak-ldap/<HOSTNAME>@OX.AC.UKfor this purpose
- See the ITSS Wiki authentication page for some background.
- If you're adding simple authorisation to an existing WebAuth-protected site using
- Will the principal(s) need access to the personal LDAP entries of all people, or only of people affiliated to your unit(s)?
- A confirmation that you have read the terms of usage
The Oak authorisation service provides, in the first instance, LDAP access to a directory of user and unit attributes. The service is primarily intended to be used in conjunction with the existing Kerberos/Webauth authentication service. Your use of the Oak authorisation service is subject to the following conditions:
- You are an IT Support person who is either registered to provide a service to one or more clearly defined units OR you are registered as a University-wide service provider.
- You are registered with OUCS to be an Oak data consumer (see registration process).
- You have read and understood the Regulations Relating to the use of Information Technology Facilities. In particular, your attention is drawn to clauses 9-10 of the Regulations relating to the confidentiality of information and the holding or processing of data relating to living individuals.
You have read and understand the
University Policy on Data Protection. In particular,
your attention is drawn to the following paragraphs:
All staff or other individuals who have access to, or who use, personal data, have a responsibility to exercise care in the treatment of that data and to ensure that such information is not disclosed to any unauthorised person. Examples of data include address lists and contact details as well as individual files.
Under principle 8, which restricts the transfer of material outside the European Area, personal data about an individual placed on the world wide web is likely to breach the provisions of the Act unless the individual whose data is used has given his or her express consent. It is important that all those preparing web pages, address lists and the like, are aware of these provisions, and seek advice from the Data Protection Officer if in doubt.
- Your use of the Service and any data obtained from the Service is in accordance with the Oak LDAP Schema and Attribute Release Policy.
This section gives recommendations on how to achieve particular goals using the Oak LDAP service, independently of any particular LDAP client software. To apply this advice using your OpenLDAP client software, please refer to Using LDAP Client Software With the Oak LDAP Service.
You shouldn't infer anything from the mere existence of an Oak LDAP entry for a person. In particular, just because someone is in the Oak LDAP directory doesn't mean they're a member of the University (but see How to Authorise Based on Membership of the University), nor does it imply that they're entitled to use any University resources.
You should not do an LDAP search with a base of
This is because in some cases a person may have multiple
oakPersonIDs. Only one of these will be present
in the distinguished name of the person's entry as the
If the card reader you're using reads the whole barcode including
the check digit, then perform an LDAP search with a base of
ou=people,dc=oak,dc=ox,dc=ac,dc=uk and a filter of
oakUniversityBarcodeFull=BARCODE. Otherwise, use
oakUniversityBarcode attribute instead.
Perform an LDAP compare query to compare the
attribute on the person's entry with the known distinguished name
of the unit's entry. For example, to see whether person
is a member of OUCS, one would perform an LDAP compare to ask whether
eduPersonOrgUnitDN attribute of
has a value of
Equally valid is to perform an LDAP compare query to compare the
member attribute on the unit's entry with the known
distinguished name of the person's entry. Using the same example as above,
one would perform an LDAP compare to ask whether
member attribute of
has a value of
You should use the
for this (bearing in mind how to look up a
person by ID).
None of the other unique attributes are guaranteed to
be present on every person entry.
You should not treat the
a persistent reference to a person; principal names
may be used to store persistent references to particular principals,
but this is different from treating
a persistent reference to a person.
- If a node refuses the connection, or if the initial connection fails due to a timeout or any other reason, try connecting to a different node from the pool. Don't give up until all nodes in the pool have been tried
- If the node you're connected to closes the connection, or the connection breaks or expires for other reasons, open a new connection to a node currently in the pool (taking care to expire any cached DNS responses according to their TTLs), and reissue any incomplete queries
The exact way to achieve this differs from client to client. Clients not implementing the above behaviours will still work properly a lot of the time, but will not exhibit continuous operation when individual nodes become unavailable, for example due to maintenance operations or component failures.