Search Google Appliance

Home >> Accounts >> Core User Directory >> CUD Interfaces Introduction

CUD Interfaces Introduction

1. Introduction

CUD provides a number of interfaces for CUD registered users to access the data. These act as gateways to retrieve data from and provide data to CUD. Besides, users can choose the format in which data retrieved must appear. For example using the Simple Matching and Query interface, users may choose to download results in a comma delimited (CSV) file or in rich meta data with values of each attributes.

Users may choose the format to suit the purpose they are using the data for. It is similarly possible to generate a query, save it and reuse it in more than one interface.

Glossary note: CAS is CUD Attribute Set; the default attributes available to all users of CUD. It is defined in the list of CUD attributes.

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 how 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:

Table 1. Available CUD Interfaces
Interface Personal access Server/ service use Authentication method preferred Attributes available
CUD User Interface 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 push N Y LDAP simple bind over SSL/TLS CAS plus special release

 

What interface should I choose for a CUD client?

  1. If you're doing ad-hoc queries, or kicking the tyres (and everyone should kick the tyres first) then you should use the CUD UI
  2. If you have a database which can be addressed remotely using a JDBC driver then you should strongly consider using the SQL push interface
  3. If don't have a database, or prefer to download data as text files before loading them into the database then you should look at the REST interface on the CUD Webservice
  4. If you are using a packaged application that is able to use a remote webservice to import data then you should look at the Webservice
  5. If you are using a packaged application that is able to query a remote LDAP directory to import data then you should look at the LDAP interface

The most commonly used are the CUD UI (User Interface) and REST.  Details of how to apply for access to those are available in the  CUD Access page. 

More details on each are below.

2.1.CUD User Interface

Typical use cases: ad-hoc lookups of people 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:

Users can search the CUD database and construct queries to filter the results to those of particular interest.  The search functionality is extremely useful to check an individual's data or to query for a cohort of people who satisfy the search parameters, e.g. people in your unit with a current University Card.

There is the capability to download your results into a csv, xml or json file.  

There is also an option to include the history and you can view previous values for attributes and the dates on which they were added and updated last. 

All users are encouraged to use the CUD UI Simple Search to familiarise themselves with the documented features in the User Guide.

Access to the CUD UI is pre-requisite to requesting access to the other interfaces.

Details of how to request access are in the CUD Access page. 

2.2.REST

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

Increasingly used by colleges and departments, 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

This is recommended: the end-user can edit their queries, run several different queries and change which data are retrieved without the need of raising a Service Request. 

The data is downoaded to a file (whose format can be specified, e.g. xml, csv, json) and the user can process that file for their own requirements.

Details of how to request access are in the CUD Access page.

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: 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

Commonly utilised by colleges and departments, 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
This is far less flexible than the REST query.  The user will need to liaise with IAM to make changes to the data provided, and to inform CUD if changes are made to the target table in the database that may affect the SQL push. 

NOTE: If CUD updates the data incrementally, expired records may build up. In htat case, it would be the user's responsibility to set up processes to identify and handle expired records.

 

Written by IT Services. Latest revision 6 December 2017