InCommon Federation Attribute Overview
Note that detailed recommendations regarding specific attributes can be found on the InCommon Attribute Summary page.
Federation and Identity Attributes
The InCommon Federation provides the trust foundation to enable Service Providers and Identity Providers to work together to manage access to protected resources. InCommon participant sites use federation-enabled software products, such as the Shibboleth System or other products supporting the Security Assertion Markup Language (SAML) to accomplish this.
In a federation scenario, when someone attempts to access a protected Service Provider site an Identity Provider is asked to provide information called "identity attributes" to the Service Provider. These attributes might include a unique identifier (traditionally a "user ID") or other information such as organizational affiliation, status, email address, etc. (this information is also called "claims" in some products). In many scenarios identity attributes are very useful to Service Providers for access control, personalization, and other purposes. InCommon encourages the support of identity attributes by its participants to improve academic and business processes and to help protect personal privacy.
An identity attribute, as asserted by an Identity Provider, consists of an attribute name (such as "eduPersonScopedAffiliation"), and a value (such as "email@example.com"). Values are often simple numbers or strings but can also be complex, such as XML-structured data, if desired. Many identity attributes can be sent at one time. Identity attributes can express things specific to a particular subject, such as a unique identifier, or things shared among many subjects, such as group membership or affiliation. Identity attribute values are based on information maintained in the identity management system of an Identity Provider, often using existing technology such as LDAP-based directory services. The Identity Provider sets policies about which attributes and values are sent to which Service Providers.
InCommon Attribute Discussions via MACE-Dir
MACE-Dir is the directories working group of the Middleware Architecture Committee for Education (MACE). Discussions about the use of attributes in InCommon, including suggestions for new standardized attributes, are conducted via MACE-Dir (mailing list, wiki, bi-weekly phone calls). All are welcome to participate in the conference calls and on the email list. Here is how you can participate and/or gather information:
InCommon Attribute Recommendations
To obtain the benefits of interoperable identity attributes, InCommon participants must agree on the definitions of such attributes and their use in service access scenarios. Attributes have been defined for many distinct purposes. Some are used in many applications, while others are more specific to particular scenarios.
Many InCommon Identity Provider participants have privacy policies that state that the only information about a subject that should be sent to a Service Provider is the information required to access that service. This approach helps preserve personal privacy, and also helps Service Providers because they are not obliged to handle and protect information they do not need. Support of this principle makes it even more important for Identity Providers and Service Providers to agree on the meaning and use of identity attributes.
The following general points apply to identity attributes intended for use among InCommon participants:
- The use of identity attributes for a particular purpose is based on mutual agreement between participants. That is, while InCommon encourages the use of attributes, and recommends many attributes that are useful for common scenarios, it does not require the use of any particular attributes by participants.
- InCommon recommends a number of common identity attributes intended to support typical federation situations. It is strongly recommended that participants make use of these attributes whenever possible rather than defining new attributes. It is very strongly recommended that, when these common attributes are used, they be used as defined rather than in a locally-modified fashion.
- InCommon is closely associated with the Internet2 Middleware Initiative (I2MI) for its technical work. I2MI's MACE-Dir Working Group specifies directory technology that is recommended for use in Higher Education and Research. The eduPerson activity in particular defines a number of attributes that have proven useful for InCommon sites. Definition of new common attributes for use in InCommon is typically conducted via the MACE-Dir Working Group, and reflected in revised eduPerson specifications.
- Most formal attribute definitions (in eduPerson and elsewhere) are in the form of LDAP directory attribute types. Using these attribute definitions in SAML-based software like Shibboleth requires additional profiling to define the on-the-wire syntax. I2MI has published the SAML
V2.0 LDAP/X.500 Attribute Profile that defines a generic set of naming and syntax rules for both SAML 1.1 and SAML 2.0-based applications. InCommon strongly recommends that sites follow this profile.
- InCommon participants may define additional attributes that are needed within their organizations or in order to interoperate properly with particular federation partners. Attributes of this type must be defined and identified so as not to conflict with attributes defined by other authorities. See Attribute Names and Shibboleth for more information.
Detailed recommendations regarding specific attributes can be found on the InCommon Attribute Summary page.
InCommon is also interested in developing Application Profiles, which would specify attribute usage in a set of common federated application scenarios. If you are interested in helping develop one or more profiles, contact firstname.lastname@example.org.
InCommon encourages Service Providers to publish their attribute requirements to enable Identity Providers to meet them. In particular, Service Provider-defined values for eduPersonEntitlement attributes, and other definitions that might be commonly used by many IdPs, should be well-documented. Contact email@example.com for recommendations on doing this.