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.
CUD consolidates records from a number of data sources for those persons. The result of matching and consolidation is that CUD is able to provide the following key services and benefits:
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.
1.1. Primary Data Systems (PDS)
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 .
Each PDS will be required to enter into a Service Level Agreement (SLA) between the CUD service provider and the nominated PDS data owner. A typical such agreement is shown here.
CUD Data Consumers
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.
CUD Data Access and Flow
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.
Requests to register a service user system for access to Core User Directory should be sent by email to firstname.lastname@example.org; a response will be given within one working day.
Provisioning for CUD data consumers will normally be completed within 1-2 working days of the request. The provisioning process is defined here.
PDS provisioning for CUD will commence within 1 working day. The provisioning process for PDS is defined here.
Requests for Change
Data owners and managers may request changes to the data collected from CUD and data delivered to CUD, and the means of connection. These requests are also subject to a change control process.
2. Summary of OUCS’s responsibilities
Hours of Service
2.1 The service is offered as follows:
2.2 OUCS will commence investigation of reported faults within one hour when full technical support is available (provided that no similar fault is already being handled by the same team).
Service Level Targets
2.3 It is intended, as far as is possible, to maintain service availability at all times apart from exclusions listed under 2.1, however there are no formal targets.
2.4 The service is intended to be available at all times during the stated hours of service; however there are no formal availability targets.
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.
Administration and Support
2.6 All support (operations and 1st/2nd/3rd line support for ITSS) for the service is provided by OUCS as described above.
2.7 Notification of scheduled maintenance, outages, and other information of general interest in relation to the service will be circulated on the itss-announce and CUD mailing lists.
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 email@example.com and will normally be fulfilled within one working day.
2.10 Information for departmental and college system administrators is given at
Management of Change
2.11 Requests for change to the service should be sent by email to firstname.lastname@example.org.
Reporting and Review
2.12 Service usage information will be reported annually in the OUCS Annual Report.
2.13 The service will be reviewed annually. The review will provide input to the service level description review, normally carried out in May of each year.
3. Summary of client’s responsibilities
3.1 Users are responsible for ensuring that this service is suitable for their needs.
3.3 PDS owners are required to enter into a Service Level Agreement with the CUD service providers.
3.4 All use of the service must be in compliance with the Terms of Usage.
3.5 All service providers and users must register their services to become either a PDS or CUD consumer.
3.6 Users should report any defect, malfunction, or performance degradation of the service promptly to enable remedial action to be taken.
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.
4. Premium services