The following elaborates on some of the fields/questions included in the access request form.
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 email@example.com.
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
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
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 Enterprise Data Warehouse personnel.
Provide a description of the audience using the application or service that includes the
user roles (student, staff, etc.) and campus affiliations.
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.
IT Risk Assessment
An IT risk 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 risk assessment reviews.
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
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.
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.
The Security Contact is the person responsible for data security. This contact is needed only if
access to non-directory data is requested.
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