skip to main content
Infrastructure Division of Information Technology


Technical Requirements and Information

Supported Software

Organizations participating in TAMUFederation must install and operate software systems that can interoperate with other participants. TAMUFederation supports the following protocols, software systems, and versions.

  • Protocol
    • SAML 2.0
  • Software
    • Identity Provider: Shibboleth System 4.x or 3.x (support for 3.x ends December 31, 2020)
    • Service Provider: Shibboleth System 3.1.0 (currently the only supported version)

For more information on the Shibboleth system, specification, patches, and upgrades, visit or join the announcement list.

For more information on SAML 2.0, see

TAMUFederation Software Deployment Guides

TAMUFederation-specific guides for installing and configuring the Shibboleth software:

Shibboleth software guides are also available:


Test your Identity Provider configuration by visiting the TAMUFederation Show Attributes Web page.

Registering Your Systems in TAMUFederation: Metadata

To activate a resource (SP) or identity management system (IdP) in the federation, please contact

Information required by the federation to process a request:

  • a copy of the metadata generated on the Identity or Service Provider
  • Service Providers should also send:
    • a list of the attributes you will be requesting
      (Remember that attribute access must be approved. See Identity Attributes section below.)
    • the service you would like to use: test or production

If an Identity or Service Provider ever needs to update their metadata or certificate, please send a copy of the new metadata to

For detailed information on TAMUFederation metadata and the TAMUFederation WAYF ("Where Are You From?") service, please see the Metadata page.

Identity Attributes

To receive identity attributes from the TAMU Enterprise Directory, access to the attributes must be approved. The Access Request page provides details on this process.

For information regarding the attributes TAMUFederation recommends, please visit the Attributes page.

TAMUFederation Operations Reference

TAMUFederation operates a number of technology platforms, including a Web server, a WAYF server, and an x.509 v3 certificate authority (CA). While TAMUFederation does operate a WAYF server and CA, participants can operate their own own WAYFs and utilize certificates from other CAs.

Email any questions to:

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. To receive additional data attributes, a Data Release Form will need to be submitted for each unique service.

Recommended server configurations for Service Providers (SPs):

provider ID (entityID)

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

  • (preferred format)

TAMUFederation accepts unique provider IDs from participant Service Providers. contains information that should be considered when selecting a provider ID.

Example SP Config XML

The following are example SP configuration files:

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


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

SP metadata

After installing a new Service Provider, use the URL http://localhost/Shibboleth.sso/Metadata on your Service Provider to automatically generate your metadata. For details on generating metadata, please visit The generated metadata or metadate URL should be submitted with the Data Release Form.

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:

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

   <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol>"
          <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
          <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
                   [base64-encoded certificate used by SP]
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
      <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      <OrganizationName xml:lang="en">Texas A and M University</OrganizationName>
      <OrganizationDisplayName xml:lang="en">TAMU SP</OrganizationDisplayName>
      <OrganizationURL xml:lang="en"></OrganizationURL>
   <ContactPerson contactType="technical">

For additional information or questions about the technical requirements for TAMUFederation please send mail to:

Federation and Identity Attributes

In a federation scenario, when a Subject attempts to access a protected Service Provider site an Identity Provider is asked to provide information, in the form of "identity attributes", about the Subject to the Service Provider. The Service Provider uses this information to evaluate whether the Subject is authorized to access the protected resource and for other purposes. These attributes might include information unique to that Subject, like an identifier email address, or more general information such as organizational affiliation or group membership.

The Identity Provider sets policies about which attributes and values are sent to which Service Providers. Without the Service Provider specifically requesting additional data, the only information returned is the Subject's targeted ID. If a Service Provider requires more information about an individual, they must contact the Identity Provider and request the additional attributes.

TAMUFederation Attribute Summary

Many of the attributes recommended for use in the TAMUFederation are used among InCommon participants. To ensure TAMUFederation participants are also able to participate in InCommon, the TAMUFederation will follow the guidelines recommended by InCommon for attributes the two Federations have in common. For the convenience of TAMUFederation participants, the InCommon recommendations are provided below.

The following is a non-exhaustive list of the attributes commonly encountered in the use of TAMUFederation-enabled services.

Attribute Summary Table
Friendly Name Formal Name Datatype Multi-valued?
eduPersonAffiliation urn:oid: String Enumeration Yes
eduPersonScopedAffiliation urn:oid: Domain-Qualified String Enumeration Yes
eduPersonPrincipalName urn:oid: Domain-Qualified String No
eduPersonUniqueId urn:oid: String, max. 256 characters No
sn urn:oid: String Yes (treated as Single-valued by TAMU IdP)
givenName urn:oid: String Yes (treated as Single-valued by TAMU IdP)
mail urn:oid:0.9.2342.19200300.100.1.3 String Yes (treated as Single-valued by TAMU IdP)
tamuEduPersonUIN urn:oid: String No

Attribute Descriptions


Formal Definition


Multiple values where value is one of:

  • member
  • student
  • employee
  • faculty
  • staff
  • alum
  • affiliate
  • library-walk-in

Usage Notes

The primary intended purpose of eduPersonAffiliation is to convey broad-category affiliation assertions between members of an identity federation. Given this inter-institutional context, only values of eduPersonAffiliation with broad consensus in definition and practice will have any practical value.

A user can possess many affiliations, though some values are mutually exclusive. This attribute is often made available to any Shibboleth service provider, and is a good way to filter or block users of a given general type.

In particular, "member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

The "member" affiliation MUST be asserted for people carrying one or more of the following affiliations: faculty or staff or student or employee.

Note: Holders of the affiliation "alum" are not typically "members" since they are not eligiblea for the full set of basic institutional privileges enjoyed by faculty, staff and students.

Cautionary note: There are significant differences in practice between identity providers in the way they define faculty, staff and employee and the logical relationships between the three. In particular there are conflicting definitions of "staff" and "employee" from country to country that make those values particularly unreliable in any international context.

The "affiliate" value for eduPersonAffiliation indicates that the holder has some definable affiliation to the university NOT captured by any of faculty, staff, student, employee, alum and/or member. Typical examples might include event volunteers, parents of students, guests and external auditors. There are likely to be widely varying definitions of "affiliate" across institutions. Given that, "affiliate" is of dubious value in federated, inter-institutional use cases.

For the sake of completeness, if for some reason the institution carries digital identity information for people with whom it has no affiliation according to the above definitions, the recommendation is simply not to assert eduPersonAffiliation values for those individuals.

"Library-walk-in:" This term was created to cover the case where physical presence in a library facility grants someone access to electronic resources typically licensed for faculty, staff and students. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary. For a more direct way of using eduPerson attributes to express library privilege information, see the eduPersonEntitlement value "urn:mace:dir:entitlement:common-lib-terms" as defined in the MACE-Dir Registry of eduPersonEntitlement values

The presence of other affiliation values neither implies nor precludes the affiliation "library-walk-in."

It is not feasible to attempt to reach broad-scale, precise and binding inter-institutional definitions of affiliations such as faculty and students. Organizations have a variety of business practices and institutional specific uses of common terms. Therefore each institution will decide the criteria for membership in each affiliation classification. What is desirable is that a reasonable person should find an institution's definition of the affiliation plausible.


Formal Definition


Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. Multiple values are expected. The values consist of a left and right component separated by an "@" sign. The left component is one of the values from the eduPersonAffiliation controlled vocabulary.

The right-hand side syntax of eduPersonScopedAffiliation intentionally matches that used for the right-hand side values for eduPersonPrincipalName (e.g., "") The "scope" portion MUST be the administrative domain to which the affiliation applies.

Usage Notes

Consumers of eduPersonScopedAffiliation will have to decide whether or not they trust values of this attribute. In the general case, the directory carrying the eduPersonScopedAffiliation is not the ultimate authoritative speaker for the truth of the assertion. Trust must be established out of band with respect to exchanges of this attribute value.


Formal Definition


A single value of the form user@domain, where user is a name-based identifier for the person and where the domain portion MUST be the administrative domain of the identity system where the identifier was created and assigned. Each value of domain defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName.

Usage Notes

Values of eduPersonPrincipalName are often, but not required to be, human-friendly, and may change as a result of various business processes. Possibilities of changes and reassignments make this identifier unsuitable for many purposes. As a result, eduPersonPrincipalName is NOT RECOMMENDED for use by applications that provide separation between low-level identification and more presentation-oriented data such as name and email address. Common identity protocols provide for a standardized and more stable identifier for such applications, and these protocol-specific identifiers should be used whenever possible; where using a protocol-specific identifier is not possible, the eduPersonUniqueId attribute may be an appropriate "neutral" form. Syntactically, ePPN looks like an email address but is not intended to be a person’s published email address, or to be used as an email address. Consumers must not assume this is a valid email address for the individual.


Formal Definition


A long-lived, non re-assignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications.

This identifier represents a specific principal in a specific identity system. Values of this attribute MUST be assigned in such a manner that no two values created by distinct identity systems could collide. This identifier is permanent, to the extent that the principal is represented in the issuing identity system. Once assigned, it MUST NOT be reassigned to another principal. This identifier is meant to be freely sharable, is public, opaque, and SHOULD remain stable over time regardless of the nature of association, interruptions in association, or complexity of association by the principal with the issuing identity system. When possible, the issuing identity system SHOULD associate any number of principals associated with a single person with a single value of this attribute.

This identifier is scoped and of the form uniqueID@scope. The uniqueID portion MUST be unique within the context of the issuing identity system and MUST contain only alphanumeric characters (a-z, A-Z, 0-9). The length of the uniqueID portion MUST be less than or equal to 64 characters. The scope portion MUST be the administrative domain of the identity system where the identifier was created and assigned. The scope portion MAY contain any Unicode character. The length of the scope portion MUST be less than or equal to 256 characters. Note that the use of characters outside the seven-bit ASCII set or extremely long values in the scope portion may cause issues with interoperability.

Usage Notes

This attribute offers a powerful alternative to the use of eduPersonPrincipalName as a user identifier within applications and databases. Its power lies in the fact that it tends to be more stable than EPPN because it doesn't change merely in response to superficial name changes. It still may change, but generally in a more controlled fashion. It also requires a policy of non-reassignment. That is, while a given user may be associated with more than one value over time, a single value once assigned will never be assigned to any other user. When appropriate, the value can remain consistent across multiple service providers, if those systems have a demonstrated relationship and need to share information about the user's activities. Such sharing must be tightly controlled.

Relying parties SHOULD NOT treat this identifier as an email address for the principal as it is unlikely (though not precluded) for it to be valid for that purpose. Most organizations will find that existing email address values will not serve well as values for this identifier.


Formal Definition


Multiple string values containing components of the users's "family" name or surname.


Formal Definition


Multiple string values containing the part of the user's name that is not their surname or middle name.


Formal Definition


Preferred address for the "To:" field of email to be sent to this person. Usually of the form Though multi-valued, there is often only one value.

Usage Notes

Some mail clients will not display entries unless the mail attribute is populated. See the LDAP Recipe for further guidance on email addresses, routing, etc. (


Formal Definition


Universal Identification Number (UIN) assigned to the person by the Texas A&M University System.

Useful Links


TAMUFederation metadata is located here:

Metadata for Identity Provider systems (IdP) includes:

  • Top Domain Name
  • URL of Single Sign On Service
  • URL of Artifact Resolution Service
  • URL of Attribute Authority Service
  • URL of Error Page
  • KeyName (CN of your selected Digital Certificate)
  • Technical contact name and email address
  • Administrative and/or Support contacts

Metadata for Service Provider systems (SP) includes:

  • Provider Id URI
  • Assertion Consumer Service: Type (post, artificat) and URL
  • KeyName (CN of your selected Digital Certificate)
  • Technical contact name and email address
  • Administrative and/or Support contacts

TAMUFederation Certificate Authority (CA)

The metadata signing certificate:

The TAMUFederation CA root certificate:

The TAMUFederation WAYF

The TAMUFederation WAYF ("Where are You From?") server should be accessed by connecting to its DNS name –

Email any questions to: