skip to content

IT Help and Support

University Information Services

Test CRSids are the CRSids issued to fulfil short-term or long term developmental and supporting testing purposes.

An introduction to the Common Registration Scheme identifier

The Common Registration Scheme identifier (CRSid) is a person’s unique username that is widely used (and re-used) for a user’s lifecycle management throughout his/her affiliation with the University. The unique CRSid issued to University staff, students and affiliates for business as usual non-testing purposes is termed as Service CRSid in this document. All CRSids are created by Jackdaw. The subscription to web-based services is authenticated through Raven. Jackdaw is a database hosting User Admin, IP register and CERT4 databases and web applications. According to historically accepted conventions, the CRSid is supposed to consist of at least the first initial and the first letter of the surname, with matches to existing strings differentiated by the assigned number, incrementing by one from the last assigned number for a given string. The user’s initials, used to generate the CRSid are usually those disclosed to the University Information Services (UIS) at the point of a user’s first registration. Jackdaw creates a CRSid using the initial(s) and surname only which is supposed to be personal and unique. It should be noted that Jackdaw’s User Admin is not the only or even a primary source for names. Names are provided by CamSIS, CHRIS, Staff Pre-registration and web-form. There is no clear priority route for this data into the system.

A CRSid is deactivated when the user leaves the University and, wherever possible, reactivated when the user returns, hence, CRSids are issued only once, to one person, whether they remain at the University or leave and never return.

Test CRSid approval process and risk acceptance

Test CRSids are the CRSids issued to fulfil short-term or long-term developmental and supporting testing purposes.

Example: This document uses a hypothetical Service CRSid “xy123” as an example. When the user with Service CRSid xy123 request a Test CRSid, he/she will need to get approval through an online form along with the Acceptable Usage Policy acknowledgment from his/her department head.

Risk Owner for the Test CRSid is the Head of Department of the user. The risks and responsibilities associated with a Test CRSid are to be accepted and owned by the user’s head of department. The user is responsible to treat the issued CRSid as a highly confidential need based privilege and should ensure the responsible usage as well as revocation of the CRSid and its complete cleansing and disassociation from any applications, services, systems, embedding and non-embedding software etc., once the user is no longer associated with the role and/or the entitlement of owning the Test CRSid. If the member of staff (issued with the Test CRSid) leaves and is replaced with another user with the same duties, it is the responsibility of the Risk Owner to ensure that the leaving personnel’s Test CRSid is revoked and a new one associated to the person replacing him is issued. The burden of responsibility and ownership eventually rests with the user’s Head of Department to ensure that the rules and restrictions of usage are duly complied with.

User association and accountability tracking

It is essential that one specific Test CRSid is clearly associated with a unique user identifiable with a Service CRSid. Hence, it is mandatory to add an additional parameter (Notes field can be used to specify the Service CRSid of the user issued with the Test CRSid) in the Jackdaw database. It is strongly recommended to log this association in an independent association database or a securely maintained electronic record showing the ownership of a Test CRSid with a unique Service CRSid holder. It is also advised to add the description along with the Surname and Display name fields in Jackdaw database to illustrate the Test purpose.

Test CRSid naming scheme

Test CRSids are the CRSids issued to fulfil short-term or long term developmental and supporting testing purposes. The Architecture Team does not require a fixed expiry date of Test CRSids, however the Service Operations and User Administration team have currently decided to implement an across the board expiry of three months, and a review of the current policy/guideline in six months’ time. Hence, the Test CRSids shall have an expiry date of three months from issuance, and must be revoked based on the risk ownership discussed further in this document.

After discussions with the User Administration team, considering the known limitations of CRSid semantics, the existing standard and exceptional use case naming schemes and the optimum security, accountability and management balance, the UIS Architecture Team has devised a naming scheme for Test CRSids in this document. This document uses a hypothetical Service CRSid xy123 for a user (Xan as first name, Yan as surname) as an example. Once the user with CRSid xy123 goes through the approval process (described in Section 1.2B of this document) for a Test CRSid acquisition, the following naming scheme shall be used to issue him/her with Test CRSid.

Test CRSids should be issued as: t000001, t000002, t000003 and so on in ascending order.

All the six characters after the first character t can be varied from 0-9 in ascending order.

For example, a user with Service CRSid xy123 would be issued a Test CRSid as t000001. The notes field should specify the user’s service CRSid i.e. xy123 in this example. Also the first name and surname (Xan as first name, Yan as surname in the example used in this document), college/departmental/institutional affiliation e.g., Computer laboratory etc., MUST be specified in the Jackdaw fields.

The existing Test CRSids in use must also be linked with specific Service CRSids as described above. Also the User Administration team should initiate a process to phase out the existing Test CRSid naming scheme with the new standard scheme.

Test CRSid terms of usage

The user is responsible to treat the issued Test CRSid as a high risk privilege and should ensure responsible usage as well as revocation of the Test CRSid and its complete cleansing and disassociation from any applications, services, systems, embedding and non-embedding software etc., once he/she is no longer associated with the role and/or the entitlement or requirement of owning the Test CRSid.

Risk Owner for the Test CRSid is the Head of Department/Head of IT for the user. The risks and responsibilities associated with a Test CRSid are to be accepted and owned by the user’s Head of Department/ Head of IT. The Risk Owner is ultimately responsible for the appropriate and responsible usage and ownership of risk associated with the usage of Test CRSid.

The Test CRSids MUST NOT be used for: I. Any personal purpose. A personal purpose is any non-official (non-University) reason which is not directly serving the user’s official mandate for testing. II. Any official non-testing requirement. The user must discern clearly and carefully between usage of a Service CRSid and a Test CRSid. III. Hacking into any University and non-University system and/or software without written approval and signed agreement between the UIS CISO (Chief Information Security Officer) and the user’s Head of Department. It must be noted that Penetration Testing is a separate subject for which there are specified prerequisites, rules and terms of use, that are beyond the scope of this document. IV. Sharing via code or software in a closed group e.g. Pastebin & Github etc or on public forums. It is the user’s responsibility to delete the CRSid from any code or application between sharing it with anyone else. V. Interfacing with or accessing any system or software in an application specific and/or application agnostic way without the formal approval of the system and/or service owner. VI. Embedding the Test CRSid into any application, system or network interface in a way that it becomes difficult for the UIS service owner to remove the Test CRSid from that application, system or network. VII. Sharing access with other users. The only individual entitled to use a Test CRSid is the user whom that specific Test CRSid is issued to and whose Service CRSid is clearly tied to that Test CRSid. VIII. Covert access or removing activity and/or access logs/traces into any interface, system or software. IX. Longer periods of time than absolutely essential for the testing requirements. The responsibility of revocation as well as removal of record and association of the Test CRSid from any service/application/interface lies with the Test CRSid user and the Risk Owner.

Misuse and disciplinary action

Failure to comply with any of the above-stated rules and restrictions may result in revocation of the Test CRSid as well as disciplinary action depending on the nature and extent of misuse. The disciplinary actions resulting from the misuse of Test CRSid could involve legal actions (if the user issued with the Test CRSid misuses it to perform any illegal action) as a Test CRSid is a high risk privilege. Hence it is strongly encouraged that the burden of risk and ownership must be accepted by the Risk Owner as well as the user with due caution and only on genuine testing need basis.

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

Latest news

Your University GoogleDrive: 20GB quota limit from December 2022

19 January 2022

Google is replacing its G Suite for Education model licensing model in October 2022. As a result, there will be a new limit of 20GB on personal GoogleDrive spaces provided with G Suite@Cambridge accounts. If your GoogleDrive usage exceeds 20GB after 1 December 2022, your University account GoogleDrive will become read-only until your usage is brought below 20GB.

Moodle offline for upgrade during 06:00–12:00 on Tuesday 11 January

10 January 2022

Moodle will be unavailable from 06:00 to 12:00 on Tuesday 11 January while we upgrade it to version 3.9. During the upgrade, you won’t be able to view or upload sessions on Panopto because access is managed via your Moodle login. Assessment Moodle, ICE Moodle and Clinical School Moodle users will be unaffected. An outline...

HEAT authentication method changing to Azure on 13 January

7 January 2022

We're changing the authentication method for the IT service management system, HEAT, to Microsoft Azure on Thursday 13 January 2022. What is changing? You should continue to use the same URL for accessing HEAT: However, the 'Sign in' screen you'll be directed to will look slightly different,...