The Core User Directory (CUD) contains details of every person who has a current relationship with the University. Currently this includes those who are students, researchers, tutors, staff and alumni. It is possible that as more information becomes available, CUD will also hold information about prospective students and those who registered to receive information about services.
CUDID, is a globally unique identifier across all the CUD data providers. This allows all data providers to have a common reference for every person record they hold. It also allows data managers to check whether a new record in their systems already exists elsewhere in other systems: if it doesn't, a new CUDID is assigned to that user for other sources to match against. The benefits of this process are that, for example, if a person returns to the University after they have been deleted from one data source, if there is a match against a historical record in another source, they can retain their old identity in that source, rather than create a duplicate record for that person.
Data Matching matches and consolidates records between sources; an outcome of this process is that source data is cleaner with no duplicate records. Should there be duplicate records CUD can provide information about multiple matches that enable records to be merged, and if required un-merged. CUD provides a set of consolidated data about a person that could not be obtained from any one other source, making it easier to query and get the desired results.
Foreign key service- this is an attribute which each data source provides to CUD for every record which it submits to CUD. It provides a reference for CUD data consumers to use to refer back to the original source, indeed to the specific record for more information. For example an ITSS officer may have been asked to provide a report on all student results over the last five years. Using CUD he can extract the FK provided by OSS and request details from OSS data manager for the information he requires. In the case of OSS of course the FK may be available from another source as it is the OSS _ID. Additionally, because the ITSS office also has the CUDID he can provide other consolidated data in the same end report for each student from other databases. Not all data providers make their foreign key available elsewhere.
Attribute release policies allow data owners to stipulate who can access attributes that are not in the CUD attribute set. Thus CUD can provide a single place for data owners to configure policies to make data available to requesters for specific data. This could be another data provider for example careers may require sensitive data from HR. This data can be controlled and made available via CUD rather than having a manually configured query.
A full service description is available on the CUD project page There are two types of CUD service users; those systems which contribute data to CUD, ie Primary Data Systems (PDS) and those system which query data stored in CUD, ie CUD data consumers.
PDS provide primary data to CUD; many sources store both primary data (ie. data for which they are the originator) and secondary data (ie. data obtained from another source). Secondary data may only be used for data matching; it is not included in the CUD attribute set (ie. any released attribute values).
As the diagram below shows, matching data is stored separately from the other data. The data which is made available to registered data consumers is the CUD attribute set. The metadata stored for each of attributes in the CUD attribute set will identify the origin, and value stored.
Other attributes may be made available to specific data consumers using attribute release policies. These are determined by the data owners and are subject to the approval of the Governance Committee for Identity and Access Management (IAM) services. The current CUD core attributes, justification and the criteria used to determine inclusion are defined separately in the discussion document Core Attribute Set This document also specifies how to request changes to the set of Core Attributes, and details the criteria required to qualify as a PDS .
CUD data consumers are able to query CUD data and obtain a result, or set of results, about the user records they are interested in. The data owners of CUD data consumer systems are not required to enter into an SLA, they are required to agree to the Terms of Usage and this SLD.
Data flows into and out of CUD by a number of mechanisms and protocols; these are defined here. Data Owners and Data Managers may control access to the data they store in CUD by means of an Attribute Release Policy, which they may configure via the appropriate user interface, subject to change control process (which includes the approval of the Governance Committee). Data owners and managers may request changes, subject to the change control procedures.
Registered ITSS and nominated Data Owners are entitled to request access to the Core User Directory to become a CUD data consumer and or a Primary Data System. Following registration, data access will be granted and the data feed configured to meet the client's specification. Follow the link to the description of the registration process.
- 9am - 5pm on weekdays: the service operates with full technical support.
- All other times: the service operates without technical support. Automated service monitoring will take place, and informal arrangements exist for staff to be notified of exceptions, however no funding is provided for contractual cover or guaranteed response.
- Exclusions: service maintenance carried out during the CUD maintenance period (2pm - 4pm every Tuesday).
2.5 Recovery will initially be from stored data in the distributed database such that data will remain available to CUD data consumers during outages. In this situation data may be aged to the when the service was fully functional and last able to receive data from PDS. Updates to data may be applied from data queued waiting to be applied, or recovered from the Primary Data Systems directly. In the worst case data will be restored from back up: recovery will be undertaken by the means which offers the greatest functionality and best recovery time for clients.
2.8 Service requests and fault reports relating to the service should be sent to the OUCS Help Desk.
2.9 Requests to register a service for access to CUD should be sent by email to firstname.lastname@example.org and will normally be fulfilled within one working day.
2.11 Requests for change to the service should be sent by email to email@example.com.
- Regulations Relating to the use of Information Technology Facilities
- JANET(UK) Statement of JANET acceptable use policy
- CHEST Code of Conduct for Site Licensed Software and Datasets
- University Policy on Data Protection
- Any local policy defined by the unit from which you use this service
3.7 Managers of services which depend on CUD are responsible for the suitability, correct configuration, and maintenance of any client software used to interact with this service. In particular this includes ensuring that LDAP clients have a suitable fail-over configuration where required.