skip to main content

Identity Services

Filling Out the Access Request Form


The following elaborates on some of the fields/questions included in the access request form.

Request Type

  • If you are setting up access for an application and are unsure which access method best meets your needs, you may find the decision matrix on the Developer Resources page helpful. You can also contact Identity Services personnel for advice by emailing idm-support@tamu.edu.

  • The Shibboleth entityID is found in the metadata for your application. To see an example, search the TAMUFederation metadata file for entityID.

  • The web services client identifier is identifier of the client you registered at https://mqs.tamu.edu/rest/docs/.

Requested Data Elements

  • For Shibboleth data requests, please itemize the data elements using schema attribute names. (See the Enterprise Directory People Branch Schema.)

  • For other types of data access requests, be as explicit as possible. For example, 'student primary major code' or 'student primary major name' instead of 'major'.

  • Data owner approval is required before access is granted to any data considered to be non-directory (non-public).

Directory/Non-Directory Data

  • Student directory data consists of a student's name, phone, email address, program of study, classification, semester enrolled if the student has not requested suppression of this information. To receive data regardless of FERPA suppression status, or to receive other data about a student, such as course enrollment, gender, date of birth, etc., the request must be approved by the Registrar.

  • Employee directory data consists of any data related to the employee's job, such as their name, title, office phone, email address, department. Release of personal information, such as employee home phone or date of birth must be approved by B/P/P.

Target Population

Provide a description of the audience using the application or service that includes the user roles (student, staff, etc.) and campus affiliations.

Data Usage

A brief explanation of how the application utilizes each data element is needed. An explanation is particularly important for requested non-directory data elements. The following example illustrates the type of information expected:

tamuEduPersonUIN - primary key; will also use for authorization, look ups of directory
      information, and look ups within the application
eduPersonAffiliation - used to determine whether a customer is faculty, staff, or student
      and under which affiliation, if multi-valued, the service is being accessed
eduCourseOffering - used to determine whether TAMU students are eligible for service based
      on current course enrollment
sn - used for greeting, mailing labels, pending order lists, and look ups within the application
givenName - used for greeting, mailing labels, pending order list, and look ups within the application
mail - when available, used to communicate with customer
tamuEduPersonMember - used to determine campus affiliation(s) and determine eligibility for service

Application or Service

The description of the application or service should include a summary of the business purpose or benefit to Texas A&M University provided by the application/service.

ISAAC assessment

An ISAAC assessment is not required in order to access Identity Services data. The answer to this question assists the Chief Information Security Officer in correlating data releases with ISAAC reviews.

Contacts

  • The Administrative Contact should be the application owner. For non-application requests, such as data to produce mailing labels, this should be the person in charge of the project for which the data is being requested.
  • The Technical Contact is the primary contact for the data access request. Identity Services contacts this person with any questions about the data access request and works with this person to set up the access or transfer the data.

Data Accessibility

The people that operate the application and database or have administrative privileges typically will be able to access all data. If the application displays any data or subsets of data, the user or user groups able to view the data need to be described. In particular, accessibility of any requested non-directory data should be described.

Contacts

  • The Security Contact is the person responsible for data security. This contact is needed only if access to non-directory data is requested.

Data Storage

If you will be storing any of the data released via this access request, it is very important to itemize

  • what data elements will be stored
  • how they will be stored
  • how long they will be retained
  • why storage of these data elements is necessary