Search Google Appliance

Home >> Accounts >> Core User Directory >> CUD Access

CUD Access

Requesting use of a CUD interfaces

A request must be made separately for access to CUD via each of the interfaces. 


CUD User Interface (CUD UI)

The prerequisite for all access is  to request personal access to the CUD User Interface (a.k.a. the CUD UI)

The initial request for access must be supported by a signed terms and conditions of CUD access form returned to: Identity and Access Management Team, Systems Development and Support, University of Oxford IT Services, 13 Banbury Road, Oxford. You may also scan the form in and send it as an attachment to the service request.

To request access to the CUD UI, please use the HEAT service request for this, this is linked to from the IAM service requests page.


Other CUD Service Interfaces, e.g. REST interface queries.

Once you have access to the CUD UI you can request access to additional service interfaces.

Refer to the Introduction there for details of the various service interfaces to determine which best suits your needs.  

You're welcome to contact IAM if you're not sure, or need advice as to which may be best recommendation.

For requests to register for REST interface access please use the HEAT service request for this, this is linked to from the IAM service requests page.

For requests to register for non-REST interface access, please use the following general email template to request access via a new service interface.


Subject: Request for access to CUD interface - <interface requested>
Please supply service access to CUD as follows:
Name: <your name>
Reason for access (required if not ITSS):
ITSS Managers:
Machine FQDN:
Interface requested:
  • ITSS should be answered Y/N depending on whether you appear in the ITSS register
  • If you are not on the ITSS register you must provide a Reason for access - why you are requesting access, including the purpose CUD data will be put to
  • ITSS Managers is a list of members of ITSS with /itss principals (e.g. unit0001/itss) who should be given access to download kerberos principals or other credentials generated as a result of this request. At least one must be provided
  • Machine FQDN is the fully qualified network name of the server or service which will be using the interface, e.g.
  • Interface requested should be one or more of:
    • REST  
    • SOAP query
    • SOAP push
    • SQL Push
    • LDAP push
  • If your request is for a REST or SOAP interface, and GSSAPI+Kerberos authentication is not supported by the software which will be used to access CUD, please include this information in Interface requested


Requesting access to additional attributes

Please use the following email template to request access to additional attributes replacing elements in <> with your details:
Subject: Request for additional CUD attributes
Please supply access to additional CUD attributes as follows:
Name: <your name>
SSO username/service principal name: <username or principal>
Additional attributes requested:
Reason for access:
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 which has already been granted access to CUD (usually via SQL Push or REST interface), and its name is normally in the form cud/<host fqdn>@OX.AC.UK
Additional attributes requested is the list of names of the additional attributes requested, taken from the complete list of attributes.
ITSS should be answered Y/N depending on whether you appear in the ITSS register
Note that a Reason For Access is required whether or not you are ITSS.  
NOTE: For requests to release additional SITS attributes (those within the "cud:uas_sits:" namespace) we will need to seek approval from the local Information Custodian (IC).


Written by IT Services. Latest revision 10 October 2018