skip to main content

TAMUFederation

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 3.x and minor releases
    • Service Provider: Shibboleth System 2.6.0 or later releases

For more information on the Shibboleth system, specification, patches, and upgrades, visit http://shibboleth.net/ or join the announcement list.

For more information on SAML 2.0, see http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

TAMUFederation Software Deployment Guides

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

Shibboleth software guides are also available:

Testing

Test your Identity Provider configuration by visiting the TAMUFederation Show Attributes Web page (a Shib 2.0 SP).

Registering Your Systems in TAMUFederation: Metadata

To activate a resource (SP) or identity management system (IdP) in the federation, please contact tamufederation@tamu.edu.

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 tamufederation@tamu.edu.

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: tamufederation@tamu.edu


To ensure TAMUFederation members can also participate in InCommon, TAMUFederation recommendations mirror those adopted by InCommon as much as possible.

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. This is analogous to the identifiers issued to Identity Providers and is in the form of a URI.

TAMUFederation accepts unique provider IDs from participant Service Providers. https://wiki.shibboleth.net/confluence/display/CONCEPT/EntityNaming contains information that should be considered when selecting a provider ID.

Example SP Config XML

The following are example SP configuration files:

Certificate

You may use a certificate from any Certificate Authority (CA). If you wish to obtain a certificate from the TAMUFederation CA, please send the following information to tamufederation@tamu.edu:

  • a Certificate Signing Request (CSR) with o = Texas A and M University
  • Technical Contact name and email address

CSRs will be processed and e-mailed to the Technical Contact. The certificate will be in PEM format.

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 https://wiki.shibboleth.net/confluence/display/CONCEPT/MetadataForSP.

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:


<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>

For additional information or questions about the technical requirements for TAMUFederation please send mail to: tamufederation@tamu.edu.

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:1.3.6.1.4.1.5923.1.1.1.1 String Enumeration Yes
eduPersonScopedAffiliation urn:oid:1.3.6.1.4.1.5923.1.1.1.9 Domain-Qualified String Enumeration Yes
eduPersonPrincipalName urn:oid:1.3.6.1.4.1.5923.1.1.1.6 Domain-Qualified String No
eduPersonTargetedID urn:oid:1.3.6.1.4.1.5923.1.1.1.10 String, max. 256 characters No
sn urn:oid:2.5.4.4 String Yes (treated as Single-valued by TAMU IdP)
givenName urn:oid:2.5.4.42 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:1.3.6.1.4.1.4391.0.12 String No

Attribute Descriptions

eduPersonAffiliation

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

Multiple values where value is one of:

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

Note that these values are NOT case-sensitive, and capital or mixed-case values are permitted (e.g., MEMBER, Member, MeMbEr), though all lower-case is recommended.

Usage Notes

Affiliation is a high-level expression of the relationship of the user to the university or organization. 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 an indication that the user is somebody with relatively official standing with a university at the present time, and does not apply to guests, other temporary accounts, terminated employees, unpaid/unregistered students, and other exceptional cases.

eduPersonScopedAffiliation       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

Multiple values of the form value@domain, where domain is (typically) a DNS-like subdomain representing the organization or sub-organization of the affiliation (e.g., "tamu.edu") and value is one of:

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

Note that these values are NOT case-sensitive, and capital or mixed-case values are permitted (e.g., MEMBER, Member, MeMbEr), though all lower-case is recommended.

Usage Notes

Affiliation is a high-level expression of the relationship of the user to the university or organization specified in the domain. 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 an indication that the user is somebody with relatively official standing with a university at the present time, and does not apply to guests, other temporary accounts, terminated employees, unpaid/unregistered students, and other exceptional cases.

eduPersonPrincipalName       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

A single value of the form user@domain, where domain is (typically) a DNS-like subdomain representing the security domain of the user (e.g., "tamu.edu") and user is generally a username, NetID, UserID, etc. of the sort typically assigned for authentication to network services within the security domain.

Usage Notes

EPPN is the eduPerson equivalent of a username. It typically has most of the properties usually associated with usernames (such as uniqueness and a naming convention of some sort), with the added property of global uniqueness through the use of a scope. An application that tracks information based on it can therefore interact with users via any number of identity providers without fear of duplicates, although the possibility for recycling/reassignment does still exist within the domain of a given identity provider. Note that at some Identity Providers a user can freely change their local account name (in the case of a name change due to marriage, for example), and the corresponding EPPN will typically change as well. This can cause a loss of service until name changes propagate throughout every application storing the value. For a less dynamic identifier, see also the eduPersonTargetedID attribute.

eduPersonTargetedID       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

A single string value of no more than 256 characters that uniquely identifies a user in an opaque, privacy-preserving fashion. In most cases, the value will be different for a given user for each service provider to which a value is sent, to prevent correlation of activity between service providers.

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 offers a significant degree of privacy and control for users. It also 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.
Note that the values are not guaranteed to be unique except within a given identity provider's set of values.

sn       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

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

givenName       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

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

mail       (per InCommon)

Formal Definition

http://middleware.internet2.edu/eduperson/

Description

Preferred address for the "To:" field of email to be sent to this person. Usually of the form localid@univ.edu. Likely only one value.

Usage Notes

The address in this attribute cannot be assumed to represent an organizationally-assigned contact address for a user established as part of a strong identity-proofing process. This may be true of some organizations that assert this attribute, but some organizations may permit users to provide their own preferred address, e.g. an email account at an Internet mail service.

tamuEduPersonUIN

Formal Definition

http://infrastructure.tamu.edu/directory/attribute/attribute_tamuEduPersonUIN.html

Description

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

Useful Links

Metadata

TAMUFederation metadata is located here: https://idp.tamu.edu/tamufed-metadata-signed.xml

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: https://idp.tamu.edu/federation.tamu.edu.crt

The TAMUFederation CA root certificate: https://idp.tamu.edu/opensystems-ca.crt

The TAMUFederation WAYF

The TAMUFederation WAYF ("Where are You From?") server should be accessed by connecting to its DNS name – https://idp.tamu.edu/DS.

Email any questions to: tamufederation@tamu.edu.