Identity Security

Identity Security technologies and business processes provide a digital identity environment to enable online collaboration and stakeholder engagement, while maintaining the security and integrity of the university’s digital assets.

Identity Security helps Technology Services provide a variety of services for campus:

• Identity Lifecycle Management
• Group & Role Management
• Authentication Services (federated authentication, MFA)
• Authorization Services (Microsoft Entra ID)
• Certificate Services (CSR's, ACME Endpoints)
• Directory Services
• Emerging Identity Technologies

New and enhanced services are being developed as part of the Identity Security Roadmap.

Personal NetID Account Help

To manage your personal NetID account, please go to Aggie Account Gateway. For assistance with password resets or Duo MFA, please contact Help Desk Central.

Contact Information

If you have questions regarding the content of this website (such as a request to update specific information), please reach out to identity@tamu.edu.

NetID Requests

All students, staff, and faculty automatically receive NetID accounts at Texas A&M. We offer several types of NetID accounts which can be requested on behalf of contractors, visting scholars, and other types of affiliates.

Other Account Types

• Secondary NetIDs can be created for the purposes of least privileged access.
• Shared NetIDs can be used for automated processes to authenticate.

Account Creation Requests

The various types of NetIDs are available from the service listings on it.tamu.edu.

Data Feeds & One-Time Data Reports

To request exported identity data, you must have an application or service-specific need for information about students, faculty, or staff, and use the data only for official Texas A&M University administrative or academic purposes.

If the service provider is a third party, the service provider must have a campus sponsor fill out the form. Contacts for the request must be Texas A&M University System employees.

NetID Account Lifecycle

The lifecycle of a NetID account differs based on the type of affiliation the account holder has with the university. The available documents here provide details of processes for the various university populations.

NetID Password Management

Management of a NetID password encompasses a number of practices. The table and comments below describe the default password management practices for Texas A&M NetID account holder populations.

Notes

• Each attempt to change a password is checked to ensure that the new password conforms to the character requirements.
  • A password must contain at least one (1) lowercase letter.
  • A password must contain at least one (1) uppercase letter.
  • A password must contain at least one (1) non-alphabetic symbol.
  • A password must contain only the following characters: a-z, A-Z, 0-9, ~!@#$%^&*()-_=+\[{\]}|:;'<.>?/
  • A password may not contain words found in a dictionary.
  • A password may not contain the user's NetID.
• Passwords expire after a specific number of days as shown in the table.
• When the current date is close to the date of password expiration, messages will be sent weekly to the user's university business email address indicating that the password is about to expire and giving instructions for resetting the password. One week prior to the expiration date, any attempts to authenticate via CAS will redirect the account holder to the password change application.
• Failed attempts before lockout counts the number of attempts a user may have to enter a correct NetID Credential before the account is frozen and may not be accessed.
• Once an account is frozen, a specific amount of time must pass before the account is automatically unlocked, the failed attempts count is set to zero and the user may again attempt to enter a correct NetID Credential.
• Self-Service Password Reset is the ability to change a password to something known, even if the user does not currently know their password.
• Users may be able to reset their password using an alternative authentication mechanism by calling HelpDesk Central and having them flag the account.
• Users may be able to reset their password by appearing in person with a photo ID.
• If your password is 16 characters or longer it will never expire. However in the event of your account being compromised you will still be required to change your password.

NetID Lock Policy

Locking NetID accounts is restricted to authorized personnel. Units requesting access to this ability will need to contact the Identity Security team and provide authorization from their supervisor, and if there is an approved business justification (criteria not published here), access will be granted.

Requesting A Lock

To request an account be locked immediately, it should be under one of the following scenarios:

1. There is an active security incident and the NetID is being used for malicious activity
2. A bug has caused the NetID to remain active without a valid university affiliation
3. The NetID belongs to a person whose employment was terminated and the department wishes to restrict access immediately

Criteria

• Under scenario 1, Security Operations or Incident & Operations Center personnel should take this action.
• In scenario 2, Identity Security team members should address the issue.
• In scenario 3, Identity Security team members will lock the account only with authorization from the immediate supervisor or department head.

Integration

Understand Concepts

When considering development or acquisition of a new application, it's important to understand some core identity concepts.

Prior to submitting a request, please review the following:

• Identity Concepts
• Identity Considerations
• The Beer Drinker’s Guide to SAML

Review Requirements

Prior to purchasing a vendor solution, please review our Vendor Requirements to ensure that your solution will work with our Identity Provider (IdP).

Submit Request

Please note that the typical time to onboard a new integration is a minimum of 1 week if we will be working with an external vendor.

Submit an Integration Request

Related Approvals

If you plan to use cloud computing services, the services may need to be compliant with the Texas Risk and Authorization Management Program (TX-RAMP).

Configure, Test, and Verify

We will assign your request to one of our team members who will work with you to configure, test, and verify your integration.

Identity Concepts

When considering the development or acquisition of a new software product, it’s important to understand some core identity management concepts to help ensure that the selected product will integrate well with the university identity environment.

Basic Terminology

Identifiers

• UIN - Unique numerical identifier for all university affiliations. Format: XXX00XXXX
• NetID – The official username. Format: 2-20 characters, alphanumeric as well as hyphen (-), and period (.)
• eduPersonPrincipalName (ePPN) – Part of the eduPerson schema. Format: <NetID>@tamu.edu

Technologies

• Security Assertion Markup Language (SAML) v2.0 – An XML-based open standard for exchanging authentication and authorization information between identity providers and service providers.

Components

• Identity Provider (IdP) – A part that offers user authentication as a service. In this context, the Identity Security team will provide the IdP for you to integrate with.
• Service Provider (SP) – The server/system which hosts the resource. In this context, you (or your vendor) are configuring the SP that provides a service to your customers. Your SP will integrate with our IdP.

Other Terms

• Attribute – Anything that the Identity Provider (IdP) knows about the end user that may be helpful to the Service Provider (SP).
• Metadata – In this context, a document which describes various technical aspects of an Identity Provider (IdP) or Service Provider (SP). Essentially, instructions which tell the IdP and the SP how to communicate with each other.

Identity Management Concepts

Authentication vs. Authorization

• Authentication – Authentication determines whether the user is who they claim to be.
• Authorization – Authorization determines whether an authenticated user is allowed to access a specific resource or take a specific action.

Accounts, Identifiers, and Identities

• Account – An account is the representation of a user within a particular system.
• Identifier – An identifier is how a user is labeled. In a system that uses NetID single sign-on, the user account will usually be accessed using the NetID as an identifier.
• Identity – An identity is the collection of accounts and identifiers associated with a particular person (or sometimes a non-person entity). An identity can be associated with multiple accounts and identifiers. For example, you may have multiple email accounts but all of those accounts belong to one identity (you).

Provisioning and De-provisioning

The process of how user accounts are created when they are needed and how they are deleted, archived, or made inactive when no longer needed.

Identity Life Cycle

Like the real-world entities they represent, identities have a life cycle. Their connection to the University will change over time and the accounts and authorizations they have will also change accordingly. The identity itself does not go away.

Systems must take into account the current status of a user in their authorization schemes and change account authorizations when that status changes. For example, if a student or employee leaves the university, the wireless network will note the change in affiliation and remove authorization for wireless access.

Identity Considerations

When considering the development or acquisition of a new software product, it’s important to answer some core identity management questions to help ensure that the selected product will integrate well with the university identity environment.

Account Management

How are user accounts conceptualized in your application?

Recall that there is a difference between an account, an identifier, and an identity. In short: User accounts are like keys, and the identity is the key ring which unifies them.

As an example, if you are running a UNIX service you may not be able to use NetID as the username due to namespace collisions. If you have multiple UNIX services, how would you link the accounts belonging to the same person across these different services? How would those user accounts then be linked back to an identity?

Not all accounts refer to people.

While an account is most frequently understood as referencing a person, non-person entities may have need for an account. For example, the NetID system supports service accounts that represent applications. You may need to consider if non-person accounts are appropriate for your application and, if so, how your application will handle these accounts (e.g. who has the right to make a request on behalf of a non-person account?).

Authentication

How will users authenticate?

You will need to start by knowing which authentication solutions are supported by your vendor/developer (e.g. SAML, OAuth, OIDC, etc.). If NetID-based authentication is not possible or not appropriate, you will need to consider how user accounts will be provisioned and managed over time, how they will be associated with the identity responsible for the actions taken with the account, and how authentication to the accounts will be managed.

How will you handle multi-factor authentication?

The university requires your use of multi-factor authentication. The solutions provided by the Identity Security team allow you to enforce multi-factor authentication on your applications.

Provisioning

How are user accounts going to be provisioned?

Especially with vendor-provided applications, you will need to consider how accounts are created in your application. For example, will these accounts be automatically created for a user upon their initial login attempt? Or will an administrator need to set up the account prior to the user’s initial login attempt?

How are authorizations provisioned?

Likewise, you need to consider that not all accounts in your application will be administrators. You will need to consider what the different authorizations in your application will be and how those authorizations will be granted. For example, will these authorizations be granted based on some attribute (e.g. a particular affiliation)? Or will an administrator need to manually authorize accounts?

Remember that authentication is not the same thing as authorization.

Authentication is the process of verifying that a user is who they claim to be. This is typically done by having the user provide a token (e.g. password) that only they know. Authorization is the process of checking to see that the user is allowed to access a requested resource or take a specific action. For example, after authentication your application may learn that the user is a student. Based on that knowledge, your application may then make an authorization decision that the user is or isn’t allowed to access a specific part of the application.

How does authorization work in your system?

You should understand how your application handle authorizations. Can authorization decisions be made based on attributes obtained during the authentication process? Or are all authorizations created and stored internally in the application?

Authorizations need to be reviewed over time (for example, once a year). Who is the right person to review those authorizations and audit them?

As you know, the University environment changes frequently. Students enroll and eventually graduate. Employees are hired, transferred, and terminated. Vendors are engaged and contracts end. As such, authorizations in your system will need to be reviewed on a regular basis. Depending on the sort of access your system provides, these reviews may need to occur as infrequently as once a year, or as often as once a week. You will also need to decide who in your area will be responsible for auditing those authorizations.

Deprovisioning

The University environment changes frequently. You will need to consider how accounts in your application are deprovisioned. There are two common events which might trigger deprovisioning.

Birthright changes occur when a University affiliation attribute of the user changes. For example, student graduation and employee termination are birthright changes that may need to trigger deprovisioning in your application.

Role changes occur when the identity’s affiliation itself doesn’t change but the nature of their work changes. For example, this will happen when an employee continues to be an employee, but their role within their department changes, or they transfer to a different department. Role changes are another common trigger for deprovisioning actions.

Authorization Reporting

You should be able to report on authorizations.

In order to ensure that users have the correct authorizations (and do not have authorizations which are inappropriate), your application should be able to provide a view into what authorizations an user has. To perform an audit (i.e., to perform an annual review) your application should provide the ability to report on authorizations.

Ideally, your application should be able to export authorization data into an external system.

An external system would allow authorization data to be collected into a single location to allow for holistic reporting, auditing, and management for authorizations.

Microsoft Entra ID

Integrate An Application

Microsoft Entra ID supports two protocols, OIDC (OpenID Connect) and SAML (Security Assertion Markup Language).

You can follow Microsoft documentation for OIDC integrations, also called "App Registrations" in Entra ID. These do not require special permissions for basic directory information release (name, email).

SAML integrations, also called "Enterprise Applications", require the following information:

• Entity ID
• ACS/Reply URL
• SAML claims required by the app (such as "eduPersonUniqueId" or "mail")

Creating An Integration

You can use apps.identity.tamu.edu to create App Registrations & Enterprise Applications and view apps you own. The interface is self-service, adds automatic departmental tagging, and manages the lifecycle of the integration for you.

Understanding OIDC/SAML Protocols

1. OIDC: To better understand OIDC and OAuth2, we recommend this Okta-published guide.
2. SAML: For an explanation of the SAML protocol, see this guide from Duo.

Entra ID at Texas A&M

Texas A&M University has one primary Microsoft Entra ID tenant. The primary domain in this tenant is configured to syncronize objects in the Active Directory domain auth.tamu.edu to Entra ID.

For more in-depth technical information, Microsoft provides comprehensive documentation geared toward developers around Entra ID.

Central Authentication Service (CAS)

What is CAS?

Yale University developed the Central Authentication Service (CAS) to provide a centralized Single Sign On system for campus applications. Applications did not have to manage user accounts or maintain credentials, and could focus on maintenance and development while users had fewer credentials to manage. CAS has been adopted by a number of universities and is now an Apereo Foundation project.

Requesting a CAS Integration

CAS Technical Guides

• CAS Architecture
• Texas A&M CAS Implementation
• Setting Up a CAS Client

CAS Architecture

A CAS server provides the following service URIs:

Basic Authentication Scenario

The illustration below outlines the basic steps in a successful CAS authentication event. For a comprehensive description of CAS features, please review the Central Authentication Service protocol documentation.

Preliminary Step: Service Provider CAS-Enables Site

• Register the site with the CAS service.
• Add a CAS client to the core service code.
• Configure the CAS client, specifying the portion of the site to be CAS-protected, and any parameter values to be included in the redirect to the CAS service.

Step 1: Subject Browses To CAS-protected Service Provider

When a Subject navigates to a CAS-protected Service Provider site, the Service Provider's CAS client redirects the Subject's browser to the CAS service /cas/login URI. The identifier for the Service Provider is included as a parameter so that CAS knows which Service Provider is requesting authentication.

https://cas_server/cas/login?service=https://your_server/yourApplication

Step 2: Subject Authenticates To CAS

The first time a Subject is redirected to /cas/login, CAS will respond by displaying a login screen, requesting the Subject's Credentials. When the Subject enters his Credential, the login form submits the Credential to /cas/login using the HTTP POST method.

Step 3: CAS Validates Credential

CAS submits the Credential to the Credential Store for verification. If the Credential is valid, CAS retrieves a set of attributes about the Subject to be included in the response to the Service Provider site. CAS uses the attributes to create a Ticket Granting Ticket which it stores in a cookie on the Subject's browser.

Step 4: CAS Verifies Service Provider

After the Subject successfully authenticates, CAS compares the value of the service parameter to the list of Service Provider sites in the CAS service registry. If the value matches an entry in the registry, CAS proceeds to the next step. Otherwise, CAS displays an error informing the Subject that the Service Provider site is not eligible to use CAS for authentication.

Step 5: CAS Generates Service Ticket & Redirects Browser

For a legitimate service, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.

https://your_server/yourApplication?ticket=ST-9781-123cvUwGGkp980

Step 6: Service Provider Validates Service Ticket

The Service Provider's CAS client starts a new connection to /cas/serviceValidate or /cas/p3/serviceValidate including the Service Ticket in the connection string. CAS verifies that the Service Ticket is valid (the Service Ticket value exists in CAS database, the Service Ticket is less than 2 minutes old, and the Service Provider site validating the ticket is the site that was sent the ticket). If the Service Ticket is valid, CAS responds with the Subject's username and any additional Subject attributes the Service Provider is authorized to receive.

After Initial Authentication Event

If the Subject attempts to access a different CAS-protected Service Provider site, the second site will once again redirect the Subject's browser to /cas/login URL as described in Step 1 above.

When the browser attempts to access the /cas/login site, the Ticket Granting Ticket previously stored in a cookie on the Subject's browser by the CAS service is included in the request. CAS checks the validity of the Ticket Granting Ticket by verifying the ticket value is present in its database and that the Ticket Granting Ticket has been used in the last 6 hours.

If the Ticket Granting Ticket is valid, CAS considers the Subject to be authenticated and skips Steps 2 and 3 as outlined above. If the Ticket Granting Ticket is invalid, CAS completes all the steps listed above.

Service Provider Modifications

The Service Provider's CAS client may include one or more of the following parameters:

• service - The Service Provider identifier, usually the URL of the Service Provider site. CAS will redirect the Subject back to the URL upon completion of a successful authentication event. Example: https://server/cas/login?service=https%3A%2F%2FmySite.edu If this parameter is not included, CAS displays a message notifying the Subject that they have successfully logged in.

• renew - Boolean value indicating whether or not the Service Provider wants to bypass Single Sign-On. This value is defaulted to False, so the renew parameter is required only when it should be set to True. When set to False, CAS checks for an existing Single SignOn session (managed using the cookie storing the Ticket Granting Ticket) for the Subject. Only when the Subject does not have an active Single SignOn session does CAS require a Credential to be presented.

  When set to True, CAS requests a Credential to be presented regardless of whether or not an active Single Sign-On session exists. Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&renew=true

• gateway - Boolean value indicating whether or not the Service Provider wants CAS to only check for a Single-Sign On session. This value is defaulted to False, so the gateway parameter is required only when it should be set to True.

When set to False, CAS checks for an existing single sign-on session for the Subject. If the Subject does not have an active Single Sign-On session, CAS will prompt the Subject for a Credential. When set to True, CAS checks for an existing Single Sign-On session for the Subject.

• If a Single Sign-On session exists, CAS creates a Service Ticket and redirects the Subject's browser back to the service URL, including the Service Ticket as a parameter in the URL.

• If a Single Sign-On session does not exist, CAS redirects the Subject's browser back to the Service Provider URL without requesting a Credential to be presented and/or including a Service Ticket.

Example: https://server/cas/login?service=http%3A%2F%2FmySite.edu&gateway=true

The gateway parameter is used for landing pages, where the Subject is not required to be authenticated to view content. This parameter allows sites to customize page content depending on whether or not a Single Sign-On session exists.

Technical Requirements and Information

Texas A&M CAS Version

The CAS 3.0 protocol is supported by Texas A&M's CAS service.

Texas A&M CAS Server

CAS Payload

CAS returns user information in either plain text or XML. To receive the payload in plain text, your application should call the .../validate server validation URL. To receive the payload in XML, your application should call the .../serviceValidate server validation URL. Although there are two different .../serviceValidate server validation URLs for CAS 2.0 and CAS 3.0, they will return the exact same payload. While CAS had possessed the <cas:attributes> element to return additional elements in the payload in CAS 2.0, it was not formally documented in the CAS protocol until the CAS 3.0 protocol was published.

Payload Content

CAS allows the payload to be customized. Texas A&M's CAS deployment takes advantage of this feature to return both the user's UIN and NetID. No other customizations have been made to the payload to ensure that 3rd party CAS-enabled applications will not require modifications to work with Texas A&M's CAS implementation. An optional attribute that can be added to the CAS payload is authenticationMethod. This attribute will return one of two values:

• Password: the user completed one-factor authentication
• 2Factor: the user completed two-factor authentication

Payload Format

XML payload (the .../serviceValidate response)

Successful Validation

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:authenticationSuccess>
		<cas:user>netid</cas:user>
		<cas:attributes>
			<cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>
			<cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>
		</cas:attributes>
	</cas:authenticationSuccess>
</cas:serviceResponse>  

Failed Validation

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:authenticationFailure code="...">
	       Optional authentication failure message     
	</cas:authenticationFailure>
</cas:serviceResponse>    

Successful Validation With Single-Factor

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:authenticationSuccess>
		<cas:user>netid</cas:user>
			<cas:attributes>
				<cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>   
				<cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>   
			<cas:authenticationMethod>Password</cas:authenticationMethod>
		</cas:attributes>
	</cas:authenticationSuccess>
</cas:serviceResponse>  

Successful Validation With Two-Factor

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
	<cas:authenticationSuccess>
		<cas:user>netid</cas:user>
		<cas:attributes>
			<cas:tamuEduPersonUIN>#########</cas:tamuEduPersonUIN>
			<cas:tamuEduPersonNetID>netid</cas:tamuEduPersonNetID>
			<cas:authenticationMethod>2Factor</cas:authenticationMethod>
		</cas:attributes>
	</cas:authenticationSuccess>
</cas:serviceResponse>  

The calling application can also specify authn_method=mfa-duo in the login URL, and then check for authnContextClass with the value mfa-duo in the extended attributes.

Session Life

Once a Subject has authenticated, the session is valid for 6 hours. A Subject can also end a session by closing all instances of the browser or requesting a logout.

Testing

Test your application with CAS by using the development URLs listed above. Separate requests must be made to register an application in the CAS development service registry and CAS production service registry. As an alternative to registering an application URL for testing with CAS, developers may use either of the following URLs:

• https://localhost
• https://localhost:8443

Registering Applications

CAS utilizes a service registry. Your application must be registered with CAS or CAS will not respond to any requests made by the application.

To register your application, send an email with the following information to identity@tamu.edu:

• Protocol: https is required.
• Application URL
• Application Type: Production or Development
• Technical contact name and email address (The technical contact must be an active staff employee of Texas A&M.)

CAS Clients

Texas A&M's CAS deployment returns the standard payload so CAS client code from the Apereo Foundation site can be used.

CAS Client Code Samples

• PHP
• Python
• .NET
• Java
• Apache

CAS Client Best Practices

Texas A&M's CAS service allows all university students and system employees log in to a single site, and use that login at any number of CAS-enabled sites on campus. This single-sign-on model presents a number of unique opportunities and challenges to developers, as it is very different from traditional forms of authentication.

When you write an application that is CAS-enabled, it joins a community of hundreds of applications from around the university. Just like any community, it helps if we all follow some basic guidelines to be respectful of our users and other applications.

1. Do not log users out of CAS. This can be counterintuitive. There are a few reasons for not logging a user out of CAS:

   • It inconveniences users. One of the most useful features of CAS is that it allows you to log in once and access multiple resources. You should not assume that a user is done with their CAS session because they have logged out of your application.

   • It implies single-sign-out. CAS is a single-sign-on service. It does not provide single-sign-out, so users are still logged into any other CAS-enabled services that they used during that session. Users should be encouraged to close their browsers completely when they are done using services.

   • In many cases, what you really want is renew=true. If you are calling the logout page to force a user to re-authenticate before accessing a resource, you are not using the service correctly. CAS provides a mechanism for forcing re-authentication. By including renew=true in the query string of the redirect to the login page, CAS will prompt the user to enter their username and password again before returning to your service.

2. Use landing pages that are not CAS-enabled. Landing pages give your users a clear view of the application they are visiting prior to logging into CAS. This allows them to make an informed decision before logging into your site. It also gives you a place to send users after logging them out of your application that can provide additional guidance.

3. Tell the user who they are. This is good practice, particularly if you think your application may be used in an environment where multiple people might access the same workstation.

Shibboleth

There are two major components to a Shibboleth system:

1. Identity Provider - the software run by a university or other organization with Subjects wishing to access a service
2. Service Provider - the software run by the provider managing the restricted service

When a Subject attempts to access a service, the Service Provider redirects the Subject to the campus Identity Provider managing the Subject's Credentials. The Subject then authenticates with his or her campus Credential. After a successful authentication, the campus Identity Provider passes back to the Service Provider a minimal set of identity information about the Subject. The Service Provider uses the identity information to determine whether or not the Subject is authorized to access the resource.

At Texas A&M, Shibboleth is used with CAS as a Single-Sign-On service. When Shibboleth must perform an authentication, CAS is called. If the customer has an existing CAS session active, they will not be prompted for their NetID credential. The strengths of the CAS service for NetID and password management are used for all Shibboleth-enabled services.

For more information on how Shibboleth works, the SWITCH Federation site offers a series of technical explanations from easy to expert.

Requesting a Shibboleth Integration

Shibboleth Setup

Configuring a Shibboleth Service Provider

Please see the Service Provider configuration page for information about configuring your service provider.

Testing Shibboleth Service Provider

Test your Service Provider using SAMLtest.

Register Service Provider in a Federation

Campus and System-wide service providers can register with the TAMUFederation.

Service Provider Configuration

To ensure TAMUFederation members can also participate in InCommon, TAMUFederation recommendations mirror those adopted by InCommon as much as possible. If you (or your vendor) are an InCommon member, you will receive the transientId attribute without submitting any additional information to the Identity Management Office.

Recommended server configurations for Service Providers (SPs):

EntityID

Each distinct Service Provider being deployed must possess a unique identifier, called an entityID. This is analogous to the identifiers issued to Identity Providers and is in the form of a URI. Examples of EntityIDs could be:

• https://software.tamu.edu/Shibboleth (Preferred Format)
• urn:mace:tamu.edu:shibboleth:sp:tamu:administrative:libr:ezproxy.library.tamu.edu

Example SP XML

The following are example SP configuration files:

Note that the configuration file name for Service Provider v3.x is still shibboleth2.xml.

• shibboleth2.xml.prod.xml
• shibboleth2.xml.test.xml
• attribute-map.xml

Certificates

You may use a certificate from any Certificate Authority (CA), including self-signed certificates.

SP Metadata

Shibboleth 2.0 and later versions of Shibboleth support metadata in the format defined by the SAML 2.0 specification. The relevant specifications can be found in:

• http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

An example document for a Service Provider might consist of the following:

<EntityDescriptor
   entityID="urn:mace:tamu.edu:shibboleth:sp:tamu:administrative:cscn:shibboleth.tamu.edu"
   validUntil="2010-03-27T16:28:32Z">  
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol>"
          <Extensions> 
                <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
                 Location="http://shibboleth.tamu.edu/Shibboleth.sso/DS"
                index="1"/>   
                <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
                 Location="https://shibboleth.tamu.edu/Shibboleth.sso/DS"
                index="2"/>
      </Extensions>
      <KeyDescriptor>
         <ds:KeyInfo>
            <ds:X509Data>
               <ds:X509Certificate>
                  [base64-encoded certificate used by SP]
               </ds:X509Certificate>
             </ds:X509Data>
          </ds:KeyInfo>
      </KeyDescriptor>
      <NameIDFormat>
         urn:oasis:names:tc:SAML:2.0:nameid-format:transient
      </NameIDFormat>
      <NameIDFormat>
         urn:mace:shibboleth:1.0:nameIdentifier
      </NameIDFormat>
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                        Location="https://shibboleth.tamu.edu/Shibboleth.sso/SAML2/POST"
                        index="1"
                        isDefault="true"/>
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
                        Location="https://shibboleth.tamu.edu/Shibboleth.sso/SAML2/POST-SimpleSign"
                        index="2"/>
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
                        Location="https://shibboleth.tamu.edu/Shibboleth.sso/SAML2/Artifact"
                        index="3"/>
   </SPSSODescriptor>
      <Organization>
          <OrganizationName xml:lang="en">Texas A and M University</OrganizationName>
          <OrganizationDisplayName xml:lang="en">TAMU SP</OrganizationDisplayName>
        <OrganizationURL xml:lang="en">http://shibboleth.tamu.edu/</OrganizationURL>
    </Organization> 
    <ContactPerson contactType="technical">
         <GivenName>Xavier</GivenName>
         <SurName>Chapa</SurName>
         <EmailAddress>xchapa@tamu.edu</EmailAddress>
         </ContactPerson>  
</EntityDescriptor>    

Certificates

Technology Services has been designated as the Registration Authority for certificate services provided by Sectigo/InCommon and is responsible for overseeing the Texas A&M University (02) certificate service.

What Are Certificates?

A certificate is a digital document that is used to prove the identity of an individual or organization. In the context of computer systems, a certificate is typically used to verify the identity of a website or server, and to ensure that data transmitted between the two is secure.

Certificates are issued by a certification authority (CA), which is a trusted third party that verifies the identity of the individual or organization requesting the certificate. Once issued, the certificate is stored on the website or server, and is used to encrypt data transmitted between the website or server and a user's device. This encryption helps to protect sensitive information, such as passwords and credit card numbers, from being intercepted by malicious actors.

There are different types of certificates, including SSL/TLS certificates, which are used to secure websites, and X.509 certificates, which are used to secure various types of network communication. In order for a certificate to be considered valid, it must be signed by a trusted CA and must not have expired.

Automated Certificate Management Environment (ACME)

It is strongly recommended that services utilize certificate automation via ACME where possible to avoid preventable service disruptions caused by expired SSL/TLS certificates.

Public-facing services available outside the campus network should use the public Let’s Encrypt service. Let’s Encrypt certificates are free to use and include robust automation via ACME as part of the service offering.

Internal applications and services can use the same protocol as Let’s Encrypt (ACME) to retrieve certificates from the existing InCommon/Sectigo service operated by Technology Services; certificate renewals using ACME are automated and don’t require requests. A list of compatible ACME clients for various platforms are available in Let's Encrypt's Documentation.

Request an ACME Account

We will need the following information to process an ACME Account Request:

• Technical Contact(s)
• Technology Services Vertical (Security & Risk, Architecture & Engineering, etc)
• Which team within the vertical the account is for (if applicable)
• Domain(s) the account will be used for

Upon processing your request, we will provide you with the endpoint URL, KeyID, and HMAC key for use in your ACME client.

It is crucial to keep these values private, as they enable access to issue certificates on your behalf. Treat them with the same care as application secrets and passwords - store them securely, restrict access, and do not share them outside those who require them on your team.

Submit an ACME Account Request

Manually Requesting A Certificate

To manually request a certificate, first you'll need to generate a "Certificate Signing Request". We recommend using the cross-platform Step CLI to generate it; it works on Windows, macOS, and any flavor of Linux.

Once you have a CSR, log in to cert.tamu.edu and click on Request SSL Certificate. Upload or paste in your CSR, and complete the other form fields.

S/MIME & Client Certificates

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of email contents and attachments that allows for users to digitally sign and/or encrypt email messages and attachments. It may also be used for digitally signing and encrypting documents as well as authenticating against services. S/MIME and client certificates are used for cryptographically binding identities to users.

If you find that you have a business need for an S/MIME certificate, please reach out to certificates@tamu.edu outlining your use case so that we may advise on whether to proceed with issuing an S/MIME certificate or propose alternative solutions. Due to the stricter verification requirements, we will only be able to provide support for installation of the certificates on University managed endpoints.

API Documentation

Identity Security provides two primary API services used at Texas A&M University:

1. NetID API
2. Duo Alias API

NetID Directory API

The NetID API provides a way for client applications across campus to access directory information.

Self-Service Client Registration

Anyone that can log in to CAS can register an API client with immediate, though limited, access (public, unsuppressed directory information).

Supported Formats

We offer options in either xml or json response formats.

General Information

• Client Setup
• Authentication

Available Services

• Directory Search
• Password Status

Client Setup

Adding a Client

From the Clients page click the link to “Register a new web services client”. You will be asked for a name and optionally a description and URL for your client application. You will also be asked to provide contact information. This should be the person responsible for maintaining the application. You may update your client to change this information at any time.

Click the “Add” button to create your client identifier and shared secret. The client will have immediate access to search the directory for public, unsuppressed information.

Adding a Manager

If more than one person needs access to view and update a client’s details, you can add managers to the client account. Be careful when adding managers, as they will have the same privileges as you. These include:

• Viewing the account identifier and shared secret.
• Updating the account name, description, URL and contact information.
• Adding and removing other managers.

To add a manager, click on the link for the client you want to edit. At the bottom of the client details page, there is a list of managers. Click the "Add Manager" button, enter the NetID of the user you want to make a manager, and then click "Add".

Removing a Manager

If you want to remove a manager, simply go to the details page for your client account and click the "Remove" button next to the manager’s name. Note that you cannot remove yourself as a manager, to prevent accidentally disabling your access to the service.

Authentication

All requests must be signed by the client.

Authentication Scheme

Sample Request:

GET /rest/directory/uin/000000000/json/ HTTP/1.1
Date: Tue, 04 May 2010 20:46:36 GMT
Authorization: TAM faa36ed8ef1a:4iRRBxwPuKD71JYYn7192Zuopkr3mPQ/HcQAfbSM2mQ=

Required Headers

Each request made by your client must provide, at a minimum, the Date and Authorization headers.

Date Header

The Date header should be provided in GMT, using a valid HTTP date format. The date in your request will be used to verify that the request is current. If you cannot set the date header for your request, you should instead set the x-tam-date header using the same format:

GET /rest/directory/uin/000000000/json/ HTTP/1.1
x-tam-date: Tue, 04 May 2010 20:46:36 GMT
Authorization: TAM faa36ed8ef1a:4iRRBxwPuKD71JYYn7192Zuopkr3mPQ/HcQAfbSM2mQ=

Authorization Header

The Authorization header will have the following form:

Authorization: TAM identifier:signature

The identifier is specific to your client. The signature is a HMAC-SHA256 of an authentication string made up of the request URI, the date, and your client’s identifier.

The following pseudo-code illustrates how to build the signature:

Authorization = "TAM" + " " + identifier + ":" + signature;
signature = Base64( HMAC-SHA256( UTF-8-Encoding-Of( shared_secret, authentication_string ) ) );

authentication_string = request_uri + "\n" +
    date + "\n" +
    identifier;

The date should be exactly what is provided in the Date header. The request URI is the path of the endpoint.

Sample Code (Python)

import base64
import hmac
import hashlib
import requests

from datetime import datetime, tzinfo, timedelta

class GMT(tzinfo):
    def dst(self, dt):
        d = datetime(dt.year, 4, 1)
        self.dston = d - timedelta(days=d.weekday() + 1)
        d = datetime(dt.year, 11, 1)
        self.dstoff = d - timedelta(days=d.weekday() + 1)
        if self.dston <= dt.replace(tzinfo=None) < self.dstoff:
            return timedelta(hours=1)
        else:
            return timedelta(0)
    def utcoffset(self, dt):
        return timedelta(hours=0)
    def tzname(self, dt):
        return "GMT"
        
def get_date():
    gmt = GMT()
    return datetime.now(tz=gmt).strftime('%a, %d %b %Y %H:%M:%S GMT')

def get_headers(auth_string):
    dig = hmac.new(bytes('SECRET_KEY', 'latin-1'),
                   msg=bytes(auth_string, 'latin-1'),
                   digestmod=hashlib.sha256).digest()
    signature = base64.b64encode(dig).decode('utf-8')
    headers = {'Date': str(get_date()),
               'Authorization': 'TAM ' + 'CLIENT_ID' + ':' + signature}
    return headers

# https://mqs.tamu.edu/rest/docs/

def data_from_netid(uin):
    url = 'https://mqs.tamu.edu/rest/directory/uin/%s/json/' % (uin,)
    auth_string = '/rest/directory/uin/%s/json/\n%s\n%s' % \
                                            (uin,
                                             str(get_date()),
                                             'CLIENT_ID',)
    try:
        response = requests.get(url, headers=get_headers(auth_string))
        data = response.json()
        return data
    except:
        print('Error getting uin from API: %s' % (uin))
        return response


print(data_from_netid("UIN"))

Directory Search

The new Directory Search API offers synchronous service calls that can be made by any registered client. By default, only public, unsuppressed directory information will be provided. For access to additional attributes or suppressed information, you must submit a data access request.

The default result format for all calls is JSON, though you can explicitly specify either a JSON or XML format. Note the trailing slashes on all urls.

All requests must be signed and dated.

Search by UIN

Searching by UIN is only available if you have an approved data access request on file that includes access to the UIN.

The following paths can be used to search for an entry by UIN:

https://mqs.tamu.edu/rest/directory/uin/<UIN>/
https://mqs.tamu.edu/rest/directory/uin/<UIN>/json/
https://mqs.tamu.edu/rest/directory/uin/<UIN>/xml/

where <UIN> would be replaced by the person’s UIN.

Search by NetID

The following paths can be used to search for an entry by NetID:

https://mqs.tamu.edu/rest/directory/netid/<NetID>/
https://mqs.tamu.edu/rest/directory/netid/<NetID>/json/
https://mqs.tamu.edu/rest/directory/netid/<NetID>/xml/

where <NetID> would be replaced by the person’s NetID.

Search by searchMailbox

The following paths can be used to search for an entry by searchMailbox:

https://mqs.tamu.edu/rest/directory/smb/<searchMailbox>/
https://mqs.tamu.edu/rest/directory/smb/<searchMailbox>/json/
https://mqs.tamu.edu/rest/directory/smb/<searchMailbox>/xml/

where <searchMailbox> would be replaced by the person’s searchMailbox.

Search by UID

The following paths can be used to search for an entry by UID:

https://mqs.tamu.edu/rest/directory/uid/<UID>/
https://mqs.tamu.edu/rest/directory/uid/<UID>/json/
https://mqs.tamu.edu/rest/directory/uid/<UID>/xml/

where <UID> would be replaced by the person’s UID.

Password Status

The password status API endpoint can determine the status of a user’s password.

Password Expires On

The following endpoints can be used to retrieve the date a person’s password will expire:

https://mqs.tamu.edu/rest/password/<UIN>/expires-on/
https://mqs.tamu.edu/rest/password/<UIN>/expires-on/json/
https://mqs.tamu.edu/rest/password/<UIN>/expires-on/xml/

Replace <UIN> with the person’s UIN.

Password Expired

The following paths can be used to determine if a person’s password is expired:

https://mqs.tamu.edu/rest/password/<UIN>/is-expired/
https://mqs.tamu.edu/rest/password/<UIN>/is-expired/json/
https://mqs.tamu.edu/rest/password/<UIN>/is-expired/xml/

Replace <UIN> with the person’s UIN.

Duo Alias API

The Duo Alias API allows for addition and removal of aliases within the Duo Console. For information on how aliases work in Duo, see the Duo documentation.

Add Alias

Endpoint: https://duo-alias.identity.tamu.edu/api/add

HTTP Method: POST

Authentication Required: Yes

Authentication: Include the x-api-key header provided by Identity Security.

Request Body Format:

{
    "netid":"[string]",
    "alias":"[string]"
}

Example:

{
    "netid":"john.smith",
    "alias":"jsmith"
}

Successful Response

Condition: New alias was successfully added to the account.

Code: 200

Content: Alias {alias} added for user {user}.

Error Responses

Remove Alias

Endpoint: https://duo-alias.identity.tamu.edu/api/remove

HTTP Method: POST

Authentication Required: Yes

Authentication: Include the x-api-key provided by Identity Security.

Request Body Format:

{
    "netid":"[string]",
    "alias":"[string]"
}

Example:

{
    "netid":"john.smith",
    "alias":"jsmith"
}

Successful Response

Condition: New alias was successfully added to the account.

Code: 200

Content: Alias {alias} removed for user {user}.

Error Responses

Attributes & Namespaces

White Pages People Branch

The White Pages People branch supports queries for public information about people who have an active affiliation with Texas A&M University.

Attribute Summary

1. General
   • Identifiers, access-related attributes, general information
     • Unique Identifier (uid)
     • ORCID Identifier (eduPersonOrcid)
     • Privacy Flags (tamuEduSuppress)
   • Names
     • Common Name (cn)
     • Last Name (sn)
     • First Name (givenName)
     • Display Name (displayName)
     • Official Name (tamuEduPersonOfficialName)
   • Email
     • Primary/Published Email Address (mail)
   • Postal Mail
     • Employee Work Address (postalAddress)
   • Telecommunication
     • Student Local Phone (tamuEduPersonLocalPhone)
     • Employee/Affiliate Public Office Telephone Number (telephoneNumber)
   • General
     • Home Page URL (personalURI)
2. Students
   • Major Codes (tamuEduPersonMajor)
   • Primary Major (tamuEduPersonPrimaryMajorName)
   • Classification Code (tamuEduPersonClassification)
   • Classification (tamuEduPersonClassificationName)
3. Employees
   • System Member
     • Employee/Affiliate System Member Codes (tamuEduPersonMember)
     • Employee/Affiliate Primary System Member (tamuEduPersonPrimaryMemberName)
   • Department
     • Employee/Affiliate Department (tamuEduPersonDepartmentName)
   • Position
     • Employee/Affiliate Official Title (title)
     • Employee/Affiliate Honorific Title (tamuEduPersonHonorific)
4. Entry Management
   • Object Classes Assigned to Entry (objectClass)
   • Universal Identification Number (tamuEduPersonUIN)
   • Consolidated List of Identifiers (searchMailbox)

White Pages Roles Branch

The White Pages Roles branch supports queries for public information about service accounts and organizations associated with the university.

Attribute Summary

1. General
   • Identifiers
     • Unique Identifier (uid)
   • Names
     • Common Name (cn)
     • Official Name (tamuOfficialName)
   • Email
     • Primary/Published Email Address (mail)
   • General
     • Home Page URL (personalURI)
2. Entry Management
   • Object Classes Assigned to Entry (objectClass)
   • Consolidated List of Identifiers (searchMailbox)

Enterprise Directory People Branch

The Enterprise People branch is used to manage NetID accounts for all employees, students and other personnel with an active association with the university. People in this branch have a customized username.

Attribute Summary

Below is a list of all attributes populated in the People branch with a link to particulars for each attribute.

1. General person attributes
   • General person attributes: Identifiers, access-related attributes, general information
     • Unique Identifier (uid)
     • Universally Unique Identifier (tamuEduPersonUUID)
     • Universal Identification Number (tamuEduPersonUIN)
     • Higher Ed Unique Identifier (eduPersonUniqueId)
     • TAMU BannerID (tamuEduPersonBannerId)
     • TAMU CompassID (tamuEduPersonCompassID)
     • NetID (tamuEduPersonNetID)
     • Higher Ed NetID (eduPersonPrincipalName)
     • ORCID Identifier (eduPersonOrcid)
     • Privacy Flags (tamuEduSuppress)
     • User Password (userPassword)
   • Role-based Affiliations:
     • TAMU Role-Based Affiliations (tamuEduPersonAffiliation)
     • Higher Ed Affiliations (eduPersonAffiliation)
     • Higher Ed Primary Affiliation (eduPersonPrimaryAffiliation)
   • Role@Location Affiliations:
     • TAMU Scoped Affiliations (tamuEduPersonScopedAffiliation)
     • Higher Ed Scoped Affiliations (eduPersonScopedAffiliation)
   • Course-based Affiliations:
     • Course Affiliation URNs (eduCourseOffering)Role@Course Affiliations:
     • Scoped Course Affiliations (eduCourseMember)
   • General person attributes: Resource Authorization
     • Resource Entitlement URNs (eduPersonEntitlement)
   • General person attributes: Names
     • Common Name (cn)
     • Last Name (sn)
     • First Name (givenName)
     • Display Name (displayName)
     • Official Name (tamuEduPersonOfficialName)
   • General person attributes: Electronic Mail
     • Primary/Published Email Address (mail)
     • Primary and Alternate Email Aliases (mailLocalAddress)
     • Email Destination (mailRoutingAddress)
     • All Texas A&M Email Aliases (tamuEduLocalMailAddresses)
     • @email.tamu.edu Email Alias (tamuEduNeoLocalAddress)
     • Texas A&M GoogleApps Account UID (tamuEduGoogleAppsId)
   • General person attributes: Physical Mail
     • Employee Work Address (postalAddress)
     • Employee/Affiliate Campus Mail Stop (mailStop)
     • Employee Work City (localityName)
     • Employee Work State (stateOrProvinceName)
     • Employee Work Zip Code (postalCode)
     • Employee Work County (countyName)
   • General person attributes: Telecommunication
     • Student Local Phone (tamuEduPersonLocalPhone)
     • Employee Home Phone (homePhone)
     • Employee/Affiliate Public Office Telephone Number (telephoneNumber)
   • General person attributes: General
     • Home Page URL (personalURI)
2. Student-related attributes
   • Major Codes (tamuEduPersonMajor)
   • Primary Major Code (tamuEduPersonPrimaryMajor)
   • Primary Major (tamuEduPersonPrimaryMajorName)
   • Classification Code (tamuEduPersonClassification)
   • Classification (tamuEduPersonClassificationName)
   • Texas A&M Degrees Awarded (tamuDegreeAwarded)
3. Employment-related attributes
   • System Member
     • Employee/Affiliate System Member Codes (tamuEduPersonMember)
     • Employee/Affiliate Primary System Member Code (tamuEduPersonPrimaryMember)
     • Employee/Affiliate Primary System Member (tamuEduPersonPrimaryMemberName)
   • Department
     • Employee/Affiliate Primary Department (tamuEduPersonDepartmentName)
     • Employee AdLoc Code (tamuEduPersonAdLoc)
     • Employee EmpLoc Code (tamuEduPersonEmpLoc)
   • Position
     • Employee/Affiliate Official Title (title)
     • Employee Title Code (tamuEduPersonTitleCode)
     • Employee Supervisor UIN (tamuEduPersonSupervisorUIN)
     • Employee/Affiliate Honorific Title (tamuEduPersonHonorific)
4. Entry management attributes (attributes for identity, reconciliation, selection, and directory build)
   • Object Classes Assigned to Entry (objectClass)
   • Date of Birth (birthDate)
   • Data Source (tamuEduDataFeed)
   • Account Status (tamuStatus)
   • Account Password Policy (tamuEduPersonPasswordPolicy)
   • Account Identity Assurance Compliance Details (tamuEduPersonAssurance)
   • Account Proxy (tamuProxyRDN)
   • List of Account Proxy Holders (tamuProxyHolder)
   • List of Account Proxy Targets (tamuProxyTarget)
   • Account Activation Date (tamuSignTimestamp)
   • Consolidated List of Identifiers (searchMailbox)
   • Administrative Account Identifiers (tamuEduPersonAdminID)
   • System of Record Affiliation End Date (tamuLastSeenTimestamp)
   • Account Contact Email Address (tamuEduContactMail)
   • Manual Addition Expiration (tamuManualAddExpire)
   • Manual Addition Sponsor (tamuManualAddRDN)
   • Manual Addition Sponsoring Department (tamuEduSponsorDepartmentName)

Enterprise Directory Roles Branch

The Enterprise Roles branch is used to manage email aliases and directory entries for Texas A&M University roles and organizations.

Attribute Summary

1. General role/organization attributes
   • General attributes: Identifiers, access-related attributes, general information
     • Unique Identifier (uid)
   • General attributes: Names
     • Common Name (cn)
     • Official Name (tamuOfficialName)
   • General attributes: Electronic Mail
     • Primary/Published Email Address (mail)
     • Primary and Alternate Email Aliases (mailLocalAddress)
     • Email Destination (mailRoutingAddress)
   • General attributes: General
     • Home Page URL (personalURI)
2. Entry management attributes (attributes for identity, reconciliation, selection, and directory build)
   • Object Classes Assigned to Entry (objectClass)
   • Consolidated List of Identifiers (searchMailbox)
   • Account Proxy (tamuProxyRDN)
   • Sponsoring Department (tamuEduSponsorDepartmentName)

Enterprise Directory Affiliates Branch

The Enterprise Affiliates branch is used to manage NetID accounts for former students who have not attended Texas A&M in the past two years and are no longer eligible for the majority of campus resources.

Attribute Summary

1. General person attributes
   • General person attributes: Identifiers, access-related attributes, general information
     • Unique Identifier (uid)
     • Universally Unique Identifier (tamuEduPersonUUID)
     • Universal Identification Number (tamuEduPersonUIN)
     • TAMU BannerID (tamuEduPersonBannerId)
     • NetID (tamuEduPersonNetID)
     • User Password (userPassword)
   • Role-based Affiliations:
     • TAMU Role-Based Affiliations (tamuEduPersonAffiliation)
   • Role@Location Affiliations:
     • TAMU Scoped Affiliations (tamuEduPersonScopedAffiliation)
   • General person attributes: Names
     • Common Name (cn)
     • Last Name (sn)
     • First Name (givenName)
     • Official Name (tamuEduPersonOfficialName)
   • General person attributes: Electronic Mail
     • Current Email Address (mail)
   • General person attributes: Physical Mail
     • Current Home Address (homePostalAddress)
   • General person attributes: Telecommunication
     • Current Phone (homePhone)
2. Student-related attributes
   • Former Primary Major Code (tamuEduPersonPrimaryMajor)
   • Texas A&M Degrees Awarded (tamuDegreeAwarded)
3. Entry management attributes (attributes for identity, reconciliation, selection, and directory build)
   • Object Classes Assigned to Entry (objectClass)
   • Date of Birth (birthDate)
   • Account Status (tamuStatus)
   • Account Activation Date (tamuSignTimestamp)
   • Student Last Enrolled Date (tamuLastEnrolledTimeStamp)

Enterprise Directory Sponsored Affiliates Branch

The Enterprise Sponsored Affiliates branch is used to manage NetID accounts for parents of Texas A&M University students. People in this branch have a customized username.

Attribute Summary

1. General person attributes
   • General person attributes: Identifiers, access-related attributes, general information
     • Unique Identifier (uid)
     • Universal Identification Number (tamuEduPersonUIN)
     • NetID (tamuEduPersonNetID)
     • User Password (userPassword)
   • Role-based Affiliations:
     • TAMU Role-Based Affiliations (tamuEduPersonAffiliation)
   • Role@Location Affiliations:
     • TAMU Scoped Affiliations (tamuEduPersonScopedAffiliation)
   • General person attributes: Resource Authorization
     • Resource Entitlement URNs (eduPersonEntitlement)
   • General person attributes: Names
     • Common Name (cn)
     • Last Name (sn)
     • First Name (givenName)
     • Official Name (tamuEduPersonOfficialName)
   • General person attributes: Electronic Mail
     • Current Email Address (mail)
   • General person attributes: Physical Mail
     • Current Home Address (homePostalAddress)
   • General person attributes: Telecommunication
     • Current Phone (homePhone)
2. Entry management attributes (attributes for identity, reconciliation, selection, and directory build)
   • Object Classes Assigned to Entry (objectClass)
   • Date of Birth (birthDate)
   • Account Status (tamuStatus)
   • Account Activation Date (tamuSignTimestamp)
   • Consolidated List of Identifiers (searchMailbox)
   • Proxy Holder's Preferred Account UIN (tamuProxyHolderUIN)
   • Proxy Target's UIN (tamuProxyTargetUIN)
   • List of Account Proxy Targets (tamuProxyTarget)
   • Account Sponsor (tamuEduGuestSponsorRDN)
   • Business Need for Account (tamuEduGuestReason)
   • Account Management Policy (tamuEduGuestAccountPolicy)
   • Account Request URN (tamuEduGuestClientID)
   • Requested Guest Account NetID (tamuEduGuestRequestedNetID)
   • Date of Account Request (tamuEduGuestTimestamp)
   • Account Activation Period Start Date (tamuEduGuestStart)
   • Account Activation Period End Date (tamuEduGuestTokenExpire)
   • Account Expiration Date (tamuEduGuestExpire)

Texas A&M OID Namespace

1.3.6.1.4.1.4391.0

1.3.6.1.4.1.4391.1

1.3.6.1.4.1.4391.10

1.3.6.1.4.1.4391.20

1.3.6.1.4.1.4391.40

Object Classes

tamuAdministrativeSearchMailbox

Object Class details

tamuEduAuthN

Object Class details

tamuEduDirectoryPerson

Object Class details

tamuEduGuest

Object Class details

tamuEduPerson

Object Class details

LDAP tamuEduPerson object class properties

tamuEduServicesUser

Object Class details

LDAP tamuEduServicesUser object class properties

tamuPerson

Object Class details

LDAP tamuPerson object class properties

tamuRoleOrOrg

Object Class details

LDAP tamuRoleOrOrg object class properties

urn:mace:tamu.edu Namespace

Registrations In urn:mace:tamu.edu:crs Namespace

urn:mace:tamu.edu:crs contains registrations for Texas A&M University course offerings.

Registrations In urn:mace:tamu.edu:dept Namespace

urn:mace:tamu.edu:dept contains registrations for Texas A&M University departments. All entitlement flags used to populate eduPersonEntitlement are registered under the department that manages the resource.

Registrations In urn:mace:tamu.edu:shibboleth Namespace

urn:mace:tamu.edu:shibboleth contains registrations for Texas A&M University's Shibboleth implementation.

Registrations In urn:mace:tamu.edu:iap Namespace

urn:mace:tamu.edu:iap contains registrations for identity assurance profiles.

Attributes

NetID (cn)

Account login identifier for campus electronic resources. NetIDs are human-friendly identifiers selected by the account holder. NetIDs are revokable (account holders are allowed to switch to a different NetID) and reassignable (6 months after the NetID is released by an account holder, it may be claimed by a different account holder). This attribute serves as the Relative Distinguished Name (RDN) for entries in Active Directory.

Directory-specific details

Display Name (displayName)

Account holder's preferred name.

Directory-specific details

Unique Identifier (uid)

Unique identifier assigned to every entry in the directory. The uid is used as the relative distinguished name (RDN) for entries in the Enterprise Directory people branch. This identifier is also stored in AUTH and Azure for cross-referencing but it does not serve as the RDN in these two directories.

Directory-specific details

Date of Birth (birthDate)

Account holder's date of birth.

Directory-specific details

Common Name (cn)

Typically the account holder's formal full name, and variations of the name. Common name is the only attribute universally used by LDAP applications for name lookup.

Directory-specific details

Employee Work County (countyName)

Office (work) mailing address county.

Directory-specific details

Employee/Affiliate Primary Department (department)

Name of department with which the employee/affiliate is associated. If the employee or affiliate has multiple appointments, the primary position appointment department name is stored.

Directory-specific details

Display Name (displayName)

Account holder's preferred name.

Directory-specific details

Scoped Course Affiliations (eduCourseMember)

Role of account holder in a specific current semester course offering. Scoped course affiliations are provided only for enrolled students, instructors, and teaching assistants affiliated with courses taught at Texas A&M's College Station, Galveston or Qatar campuses, or admitted and enrolled students eligible to take a Math Placement Exam. The 'current semester' used to set and clear information in the Texas A&M Enterprise Directory includes all semesters with active sections, where an active section is defined as one where the current date is on or after the section start date and on or before the section end date.

Directory-specific details

Course Affiliation URNs (eduCourseOffering)

URNs denoting the current semester's course offerings with which the account holder is affiliated. If the account holder is eligible to take a Math Placement Exam, the URN for the Math Placement Exam will also be present. URNs are provided only for enrolled students, instructors, and teaching assistants affiliated with courses taught at Texas A&M's College Station, Galveston or Qatar campuses, or admitted and enrolled students eligible to take a Math Placement Exam. The 'current semester' used to set and clear information in the Texas A&M Enterprise Directory includes all semesters with active sections, where an active section is defined as one where the current date is on or after the section start date and on or before the section end date.

Directory-specific details

Higher Ed Affiliations (eduPersonAffiliation)

Broad category(ies) describing the account holder's affiliation with the university. A person can have more than one role (e.g., a student and an employee).

Conditionals governing eduPersonAffiliation flag assignment:

Conditionals governing eduPersonAffiliation affiliate flag assignment:

Directory-specific details

Resource Entitlement URNs (eduPersonEntitlement)

URNs denoting resources the account holder is authorized to use.

Directory-specific details

ORCID Identifier (eduPersonOrcid)

Account holder's ORCID identifier. The ORCID is a persistent digital identifier that distinguishes the account holder from every other researcher. Through integration in key research workflows such as manuscript and grant submission, the ORCID identifier supports automated linkages between the account holder and his/her professional activities ensuring that the account holder's work is recognized. See http://orcid.org for more information.

Directory-specific details

Higher Ed Primary Affiliation (eduPersonPrimaryAffiliation)

Broad category describing the account holder's primary affiliation.

Directory-specific details

Higher Ed NetID (eduPersonPrincipalName)

The "NetID" (account login identifier) for inter-institutional authentication. This can be thought of as the account login scoped to the Identity Provider. For everyone in the directory, it is 'tamuEduPersonNetID@tamu.edu'. This value is also the Kerberos principal for the account holder. This is a human-friendly identifier selected by the account holder. NetIDs are revokable (account holders are allowed to switch to a different NetID) and reassignable (6 months after the NetID is released by an account holder, it may be claimed by a different account holder). Due to these characteristics, a Service Provider wishing to link a Texas A&M NetID account holder to an internal account should use a persistent identifier such as eduPersonUniqueId instead of eduPersonPrincipalName.

Directory-specific details

Higher Ed Scoped Affiliations (eduPersonScopedAffiliation)

The account holder's affiliation (role) within the Texas A&M Identity Provider's domain.

Conditionals governing eduPersonScopedAffiliation flag assignment

Directory-specific details

eduPersonUniqueId

A persistent unique identifier for inter-institutional use as a principal identifier or unique external key by applications. This identifier represents a specific Subject in the Texas A&M NetID Identity Management System.

Directory-specific details

Universal Identification Number (employeeID)

Account holder's Universal Identification Number (UIN). This is The Texas A&M University System unique identifier. The UIN is also used as the Texas A&M NetID Identity Management System primary identifier.

Directory-specific details

First Name (givenName)

The first name of the account holder.

Directory-specific details

Home Phone (homePhone)

Home phone number.

Directory-specific details

Current Home Address (homePostalAddress)

Current home address.

Directory-specific details

Employee Work City (localityName)

Office (work) mailing address city.

Directory-specific details

Email Address (mail)

Preferred address for the 'To' field of email sent to the account holder. This is not the final delivery address.

Directory-specific details

Primary and Alternate Email Aliases (mailLocalAddress)

Primary and alternate aliases for the account holder's institutional email account.

Directory-specific details

Email Destination (mailRoutingAddress)

Destination for email sent to the account holder's institutional email addresses.

Directory-specific details

Employee/Affiliate Campus Mail Stop (mailStop)

Campus Mail Stop. The term "mail stop" is used to identify a location on campus. It is the last four digits of the postal service ZIP CODE + 4. Each department has been assigned a four-digit mail stop code.

Directory-specific details

Employee Supervisor (manager)

Link to directory entry of employee's immediate supervisor.

Directory-specific details

NetID (name)

Account login identifier for campus electronic resources. NetIDs are human-friendly identifiers selected by the account holder. NetIDs are revokable (account holders are allowed to switch to a different NetID) and reassignable (6 months after the NetID is released by an account holder, it may be claimed by a different account holder).

Directory-specific details

Object Classes Assigned to Entry (objectClass)

List of object classes assigned to entry.

Directory-specific details

Home Page URL (personalURI)

Personal home page URL.

Directory-specific details

Employee Work Address (postalAddress)

Employee's office (work) mailing address. This information is provided only for faculty, staff, and graduate assistant employees of the Texas A&M System.

Directory-specific details

Employee Work Zip Code (postalCode)

Office (work) mailing address zip code.

Directory-specific details

NetID (sAMAccountName)

Account login identifier for campus electronic resources. NetIDs are human-friendly identifiers selected by the account holder. NetIDs are revokable (account holders are allowed to switch to a different NetID) and reassignable (6 months after the NetID is released by an account holder, it may be claimed by a different account holder).

Directory-specific details

Consolidated List of Identifiers (searchMailbox)

All identifiers reserved for use by account holder. This attribute is used in management of the NetID/email alias namespace.

Directory-specific details

Last Name (sn)

The last name of the account holder (i.e. surname).

Directory-specific details

Employee Work State (stateOrProvinceName)

Office (work) mailing address state.

Directory-specific details

Employee Work Address (streetAddress)

Employee's office (work) mailing address. This information is provided only for faculty, staff, and graduate assistant employees of the Texas A&M System.

Directory-specific details

Texas A&M Degrees Awarded (tamuDegreeAwarded)

Texas A&M degrees awarded to the account holder.

Directory-specific details

Account Contact Email Address (tamuEduContactMail)

Account holder's contact email address for account-related notifications.

Directory-specific details

Data Source (tamuEduDataFeed)

Data source(s). All systems of record submitting information for the account holder.

Directory-specific details

Texas A&M GoogleApps Account UID (tamuEduGoogleAppsId)

Unique identifier for the account holder's Texas A&M GoogleApps account.

Directory-specific details

Account Management Policy (tamuEduGuestAccountPolicy)

Policy for aging and deleting guest account after expiration.

Directory-specific details

Account Request URN (tamuEduGuestClientID)

URN of the client application or service that sent the guest account request.

Directory-specific details

Account Expiration Date (tamuEduGuestExpire)

Date guest account expires.

Directory-specific details

Business Need for Account (tamuEduGuestReason)

Business need for guest access.

Directory-specific details

Requested Guest Account NetID (tamuEduGuestRequestedNetID)

Guest account login identifier requested by sponsor.

Directory-specific details

Account Sponsor (tamuEduGuestSponsorRDN)

UID for account sponsor's directory entry. An account can be sponsored by a person or organization.

Directory-specific details

Account Activation Period Start Date (tamuEduGuestStart)

Date the guest account can first be activated.

Directory-specific details

Date of Account Request (tamuEduGuestTimestamp)

Date account was requested/record for guest account created in the Identity Management System.

Directory-specific details

Account Activation Period End Date (tamuEduGuestTokenExpire)

Date Identity Management System record for guest account will be removed if account has not been activated.

Directory-specific details

All Texas A&M Email Aliases (tamuEduLocalMailAddresses)

All email aliases managed by Texas A&M's central email service. This includes the account holder's institutional (@tamu.edu) email and, if provisioned, the account holder's Exchange mailbox (@exchange.tamu.edu) and GoogleApps mailbox (@email.tamu.edu) addresses. Email aliases for any hosted domains associated with the above services are also stored.

Directory-specific details

@email.tamu.edu Email Alias (tamuEduNeoLocalAddress)

Account holder's TAMU Email (@email.tamu.edu) alias (email address).

Directory-specific details

Employee AdLoc Code (tamuEduPersonAdLoc)

Employee's administrative location (AdLoc) code. The department that supervises the employee.

Directory-specific details

Administrative Account Identifiers (tamuEduPersonAdminID)

List of identifiers for Shared NetID Credentials used by the account holder to carry out administrative duties.

Directory-specific details

TAMU Role-Based Affiliations (tamuEduPersonAffiliation)

Account holder's roles. A person can have more than one role. This attribute stores all role-based affiliation flags for the account holder.

Conditionals governing tamuEduPersonAffiliation student flag assignment

Enterprise Directory People Branch Faculty flags:

Conditionals governing tamuEduPersonAffiliation faculty flag assignment

Enterprise Directory People Branch Staff flags:

Conditionals governing tamuEduPersonAffiliation faculty flag assignment

Enterprise Directory People Branch Employee flags:

Conditionals governing tamuEduPersonAffiliation employee flag assignment

Enterprise Directory People Branch Member flags:

Conditionals governing tamuEduPersonAffiliation member flag assignment

Enterprise Directory People Branch Affiliate flags:

Conditionals governing tamuEduPersonAffiliation student flag assignment

Enterprise Directory Affiliates Branch:

Conditionals governing tamuEduPersonAffiliation affiliate flag assignment

Enterprise Directory Sponsored Affiliates Branch:

Conditionals governing tamuEduPersonAffiliation affiliate flag assignment

Directory-specific details

Account Identity Assurance Compliance Details (tamuEduPersonAssurance)

Set of URIs that document identity assurance compliance details.

Directory-specific details