2.1. CUD UI

Typical use cases: ad-hoc lookups of data in CUD; preparation and testing of query to be used by server/service

The CUD UI is a web application which enables registered users to perform the following:

• Searching using a query builder
• Matching
• Manage affiliations

All users are encouraged to use the CUD UI to familiarise themselves with the documented features

2.2. REST

Typical use-case: retrieve data for a college or department, saving to file for local processing

Representational State Transfer (REST) is the preferred method of querying CUD from a server or service. It allows data to be requested using a simple GET query communicated over HTTPS. The client is then able to save the data received from CUD to a local file for processing, or store it in memory. Client requirements are:

• Can make GET requests over HTTPS and process the data returned
• Can use HTTP-Negotiate + Kerberos for authentication using credentials stored in a keytab

On many Linux/Unix servers Curl can be used for this purpose. For other cases the Cud Client is available which:

• Is full self-contained, and requires no additional Kerberos libraries on a system
• Uses Java, with a requirement for Java 7
• Can be invoked unattended in a script

2.3. SOAP

Typical use-case: send data to/accept data from packaged application which supports SOAP for this purpose.

SOAP is currently supported as a means of pushing data to remote webservices. Requirements are specific to each service.

2.4. LDAP

Typical use case: Web application which requires a lookup of single records in CUD

CUD behave as an LDAP v3 directory, queryable by any LDAP client. Client requirements are:

• LDAP v3 support
• Support authentication using GSSAPI+Kerberos using a service principal stored in a keytab (preferred)
• Support simple bind over SSL/TLS using securely stored credentials

Typical use case: provision accounts to local Active Directory, with account lifecycle managed by CUD

CUD can push data to an external LDAP directory, such as Microsoft Active Directory. Requirements of the directory are:

• Supports SSL/TLS
• Enables CUD to authenticate with a simple bind
• Is accessible for connections initiated from CUD server

2.5. SQL

Typical use case: maintain data on a set of people in a table in a database for use locally

CUD can push data into a SQL database. Normally this involves storing data in a table or tables in the remote database which is dedicated to this task. This data is then processed by local procedures to update other data tables, or referenced as appropriate in queries. CUD can update the log table either incrementally, or by dropping existing data and repopulating the table(s). Requirements for the SQL database are:

• Addressable remotely on a network port (note: Microsoft Access and OpenOffice Base are not networked databases and so are not supported) with connections initiated from the CUD servers
• Has a supported Java Database Connection (JDBC) driver
• Username and password for use by CUD

4.1. CUD attribute set

The CUD attribute set (CAS) comprises a list of attributes which are available by default to all registered users of CUD for all person records in CUD. Some attributes in the CAS are consolidated values from multiple sources, others are single values taken from a single source

4.2. Complete list of attributes

Additional attributes, not included in the CAS are available on application. You must have a good reason for using additional attributes, access to which will be considered in consultation with the data owner.

The following table shows additional consolidated attributes:

The following table shows all attributes, their source and whether they are included in the CAS.

4.3. Requesting access to additional attributes

Please use the following email template to request access to additional attributes replacing elements in <> with your details:

• SSO username/service principal name is the name of the login which requires access to the additional attributes. In the CUD UI this will be an SSO username. For other interfaces this will be the kerberos service principal name granted which has already been granted access to CUD, normally in the form cud/<host fqdn>@OX.AC.UK
• Additional attributes requested is the list of name of the additional requested, taken from the complete list of attributes
• ITSS should be answered Y/N depending on whether you appear in the ITSS register
• Reason for access is required whether or not you are ITSS

4.4. Affiliations

In addition to attributes, CUD stores affiliations, which reflect the relationship of a person with the University.

CUD models an unlimited number of as affiliations with the following components:

• Status (coarse grained)
• Unit
• Source
• Start date
• End date
• Date last updated

Primary data systems have different status codes and different codes/acronyms for units

Status codes are stored “as-is” and not decoded, is there is no status it is stored as “unknown”

Unit codes are stored as received from the primary data system, but an attempt is also made to map them to a common acronym and name, so a single affiliation (from University Card) is stored in different forms:

• MC@EN
• MC@OUCS
• MC@Computing Services

CUD exposes affiliations in the form current_affiliations for convenience. It lists units with which a person has a current affiliation from any source

• Status is not listed
• Start, end and last updated dates not exposed
• Easy to search
• Easy to consume

CUD also exposes affiliations in the form scoped_affiliation where additional data is required. This includes all data held for an affiliation

• For “flat” format (e.g. a CSV) the elements are concatenated with ; delimiters
• Where there are multiple affiliations this can become difficult to process!
• For “structured” formats elements are in a defined structure and so easier to process
• Scoped_affiliation includes past, current, and (potentially) future affiliations

Affiliations can be considered part of the CAS, since all registered CUD users are able to view them. In many cases start and end dates not specifically included in the CAS are available as a component of an affiliation.