ShibbolethGlossary

Attribute: An attribute is an atom of information which is defined by the intersection of attribute name and attribute value. Attributes must be considered in terms of the subject about which they are asserted and the authority who is asserting the atom of information is true.

Attribute Acceptance Policy (AAP): AAP's define the rules that map attributes and information out of the SAML attribute assertion into simpler forms that are usable by the application for policy decisions. These rules may also provide filters on who is allowed to assert certain information.

Attribute Authority (AA, deprecated): The AA is the portion of the IdP responsible for issuing attributes on behalf of an organization. This term has been deprecated, and the AA is now the attribute query protocol handler function in the IdP.

Attribute Assertion: A SAML attribute assertion carries attribute information about a subject such as a browser user. In Shibboleth, the attribute assertion conveys attributes once a context is established from the IdP to the SP.

Attribute Release Policy (ARP): ARP's are rulesets regarding attribute release. These are combined and matrixed against the requester to compute an effective ARP. The effective ARP filters the set of attributes supplied by the directory released to a given relying party by the IdP.

Attribute Resolver: The component of the IdP responsible for retrieving attributes from various data sources or computing advanced attributes and performing the necessary transformations for SAML transport.

Authentication Assertion: SAML authentication assertions carries information regarding the act and results of the authentication of a principal by an authority. In Shibboleth, this is used to transport the handle or other form of name identifier to the SP for authentication or subsequent attribute request.

Bossie: A completely insecure, free CA graciously operated by Eric Norman of the University of Wisconsin which is often used for the initial testing of Shibboleth installations. Bossie is a THREAT to your infrastructure, not an enabler.

eduPerson: This object class was defined by MACE-Dir to handle standard educational attributes in a way that would facilitate collaboration. Shibboleth is often used to transport eduPerson attributes, but the two are distinct entities and each can be used individually with full functionality.

Entitlement: Entitlements form a specialized class of attributes important enough to call out separately. They can be used to identify specific group membership or eligibility to use a given resource. One method of deploying Shibboleth insulates the decision-making logic used by the IdP from the SP by expressing entitlements instead of several individual attributes.

EPPN (eduPersonPrincipalName): This identifier takes the form principal@domain and is the most common form of identity in higher ed. While it may resemble an e-mail address, it is not one.

Handle: A handle is one form of name identifier and is used in an authentication assertion to establish a referential identifier for attribute query in classic Shibboleth. The handle itself is completely opaque and temporary and should never be directly used for authentication purposes, as it corresponds only to a particular unknown browser user.

Handle Service (HS, deprecated): Formerly, the portion of the IdP responsible for handling single sign-on interoperability and functionality. Now known as the SSO Handler.

Federation: A federation is a collection of organizations that agree to interoperate under a certain ruleset. Federations will usually define trusted roots, authorities, and attributes, along with distribution of metadata representing this information. Shibboleth treats federations -- representing multiple relying parties -- like single relying parties. Federations are not required for the use of Shibboleth but can facilitate exchange greatly.

Identity Provider (IdP, Origin): The Identity Provider is the authority responsible for generating and asserting authentication, authorization, and identity information about principals in a security domain.

Lazy Session Establishment: This special form of session establishment allows for access of a URL or resource prior to authentication or attribute transport, preserving the ability for subsequent attribute transport at the application's request. More information is available in the introductions of the deployment guide.

Metadata: Shibboleth relies on metadata to identify and distribute trusted IdP, SP, and certificate authority information. Prior to 1.3, this took the form of sites.xml and trust.xml ; now only metadata.xml , based on the new SAML 2.0 metadata standards, is used.

Name Identifier: There are several different name identifiers, each one representing a different meaning for the Subject field of the SAML authentication assertion, and often, a different set of flows as well. Handles are the name identifier in traditional Shibboleth flows, and actual identities or persistentID's may also be used either for attribute transport or as standalone sign-on assertions.

Persistent Identifier (eduPersonTargetedID): This special identifier type allows an IdP and SP to preserve a single identifier for one principal across all current and future transactions involving that principal without revealing or using that principal's identity. These identifiers are opaque to SP's and vary per SP, protecting against collaborative Denial of Privacy attacks, while preserving a 1:1 guaranteed mapping for liability and preference management purposes.

Principal: The individual being authenticated and about whom assertions are being issued. Note the principal of an assertion is only the subject of the assertion in cases where identity is directly expressed.

providerID: The atom of trust implementation for both the SP and IdP is the providerID of the corresponding partner in a transaction. Often this will be assigned by federations, but at other times individual providers will define their own. Common names may be used in addition to providerID's for UI purposes.

Relying Party: The relying party is defined per-flow and is always the provider receiving and utilizing information from another entity in a given flow. Generally, this will be a particular SP.

SAML: The Security Assertion Mark-up Language consists of a set of assertion format definitions and bindings for these assertions to protocols. Shibboleth supports several formats, protocols, and versions of SAML.

Service Provider (SP, Target): This entity is authorized to request attributes about IdP users on behalf of a relying organization.

SHAR (Shibboleth Attribute Requestor, deprecated): This was the component of the SP responsible for requesting attributes about a browser user with whom a handle had already been associated, but is now a part of the SP package as a whole. shibd performs this functionality.

SHIRE (Shibboleth Indexical Reference Establisher, deprecated): The SHIRE functionality is responsible for helping to associate a browser user with an identifier that the IdP and SP can both refer to. It is now part of the SP package.

URI (Uniform Resource Identifier): The URI is a superset of URN's and URL's, each of which is useful for uniquely naming things. In Shibboleth, these are often used to identify attributes, providers, and endpoints.