2. CUD Interfaces

The following are brief descriptions of available CUD interfaces intended to assist with selection is the most appropriate for a given requirement. Details of now to request access are also provided, and additional details of how to use the interface will be provided once that request has been fulfilled. A summary of available interfaces, their purpose and what can be obtained from them is:

Interface Personal access Server/ service use AuthN method preferred Attributes available
CUD UI Y N Webauth CAS plus special release
REST N Y Kerberos CAS plus special release
SOAP query N Y Kerberos CAS plus special release
SOAP push N Y Various CAS plus special release
SQL Push N Y As required for JDBC connection CAS plus special release
LDAP query N Y Kerberos CAS
LDAP push N Y LDAP simple bind over SSL/TLS CAS plus special release
  • CAS is the Cud Attribute Set as defined below

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

Up: Contents Previous: 1. Introduction Next: 3. Requesting use of a CUD interface