(Final Release 5/27/2015)

Table of Contents



Executive Summary

Integration of External Identities into internal systems, either single Service Providers or institutional identity and access management systems, can afford multiple benefits, for example:

This is the final report of the External Identities Working Group, formed in August of 2014 by the InCommon Technical Advisory Committee to examine these benefits and “...move the community of knowledge towards the goal of making external identities useful and sufficiently trusted in a variety of campus-based use cases.”

We open with definitions of common terms used in discussion of External Identities and then characterize updated use cases from the previous Social Identities Work Group along three dimensions: scope, longevity, and risk.

We then address the trustworthiness of external identities as it relates to the trustworthiness of internal identities.  There is no hard line between what is be considered “internal” or “external;” it must be determined from the point of view of the relying party, and the same is true when determining trustworthiness.  For a specific identity, trustworthiness is determined by a number of criteria, possibly including formal assurance profile certification, which apply to both external and internal identities.  We provide risk assessment criteria that should be considered for both internal and external identities.  We also discuss strategies for enhancing trustworthiness by linking external and internal identities.

The next section addresses architectural patterns and infrastructure elements required for various uses of external identities, before we close with a list of business and technical criteria to be considered when selecting an External Identity Provider.


Defining Some Terms


An Identity is a collection of information about a person, generally within the context of some organization (an application, a university, Google).  That collection may or may not be associated with one or more Authentication Mechanisms.

Internal vs. External Identities

Internal Identities are those that are managed by your organization, while External Identities are Identities that are not managed by your organization. Which Identities are considered Internal vs. External will depend on the nature of your organization:

Common Types of Identities


The individual pieces of information maintained about a person are often referred to as Attributes.  Typical Attributes are name, electronic mail address, affiliations, group membership, entitlements, in addition to those used specifically as Identifiers (see below). Multiple organizations may store Attributes, according to each organization’s needs, describing the same individuals. These Attributes can be duplicative, complementary or in conflict across different organizations.


Identifiers are Attributes that uniquely reference an Identity. Such Identifiers may be globally unique, or they may be unique only within the scope of the administering organization. Also, it is possible for an Identity to have multiple associated Identifiers. Examples include:

In many ways, Identifiers are just Attributes with specific properties. Identifiers are called out in this document for two reasons:

“Directed” or “targeted” Identifiers are scoped to specific Relying Parties, so that different Identifiers are presented to different Relying Parties for the same Identity. Such Identifiers are generally intended to inhibit correlated tracking of user activity across Relying Parties. Support for targeted Identifiers will vary from provider to provider. For example Google provides a single Identifier that is asserted to all Relying Parties, while Facebook and LinkedIn Identifiers are targeted/directed and so are specific to the Relying Party receiving the assertion.

Authentication Mechanism

A mechanism used by an Identity Provider to determine who the current user is, such as verification of username and password or proof of possession of a software or hardware token.  Different Authentication Mechanisms may mitigate more or different risks and so are appropriate for different circumstances.

Identities are not required to have associated Authentication Mechanisms. For example, organizations have traditionally managed Authentication Mechanisms for their Institutional Identities, but it is possible to Link Identities to enable users to leverage their External Identities’ Authentication Mechanisms for their Institutional Identities.  This is often referred to as “Bring Your Own Identity.”

Assertions may not communicate all relevant details of the mechanism used to authenticate an individual, even when supported by the protocol. Unless specific conventions are defined and followed, the Relying Party may have no way to determine specifics of the actual authentication events.


An Authenticator is something a person can use to prove control of an Identity electronically through use of one of the Identity’s associated Authentication Mechanisms.  The strength of that proof is dependent on the Authentication Mechanism, issuance and management practice, identity proofing practice, among other factors.  Examples of Authenticators are:

The term “Authenticator” in this document is used similarly to the definition of the term “Credential” in the InCommon IAAF 1.2 and the term “Token” in NIST 800-63-2.


External Identities can be used by themselves to grant access to services or they can be Linked to Internal Identities. Linking establishes a mapping from an Attribute asserted by an External Identity provider to an Internal Identity. This allows a Relying Party to leverage the External Identity’s Attributes, its Authentication Methods, or both, and also to supplement that information with Attributes (e.g., campus affiliation) and Authentication Methods (e.g., MFA) managed for the Internal Identity. This can be done to outsource the management of user passwords, to provide convenience for the end user, or to acquire Attributes describing the user from the External Identity. The use cases and implications of such linkages are discussed in greater detail in later sections of this document.

Identity Provider

An Identity Provider is a network service that asserts identity information about the community of people it represents. While “Identity Provider” has a specific meaning for specific protocols, such as SAML, we use this more general definition in this document, unless noted otherwise.

Service Provider

A Service Provider is a network service that provides services to people. As with Identity Provider, this document does not use a protocol-specific definition of Service Provider, unless noted specifically.

Relying Party

A Relying Party is a network service that receives identity information from an Identity Provider. An Relying Party may be a Service Provider, an Identity Provider or both (in the case of “gateway” implementations).


Characterizing External Identity Use Cases

The work group began its work by examining several use cases, many of which had earlier been identified by the Social Identities Working Group.  Those use cases have been collected in the External Identities Working Group’s wiki space.

While there are many use cases, they can be categorized along the following dimensions, which in turn affect the criteria that an institution should consider in evaluating sources of External Identities.

The following sections discuss each of these dimensions in greater detail.

Linking to an Internal Service Provider Identity vs. an Institutional Identity

External Identities can be linked with a scope limited to a single Service Provider, or linked broadly within the institutional Identity and Access Management (IAM) system making them available to multiple Service Providers.  The choice between these two scenarios will be made on the basis of issues such as resource allocation, policy, and organizational responsibility.  Note that there is not always a clear line between these two scenarios, as campus IAM systems may offer identity services for local Service Providers without formally adding the Service Provider’s users to the IAM system itself. Examples of each approach include:

Longevity of the Linkage

Some use cases involve “one shot” relationships between a relying party and the user, often because the service itself is very short-lived (e.g., authentication for WiFi at a conference).  If the service is used on more than one occasion by the same person, it is not necessary to correlate those occasions or recover state from earlier uses of the service.  In this case, the External Identity does not need to be stable over time; Identifiers and Attributes can change without serious impact on the relying party. Also, the External Identity Provider can re-assign Identifiers to other people, as the relying party will not confuse the new user with some previous user who used the service earlier.

If the use case requires maintenance of information about people over time, however, then:

Risk Associated with the Use of the External Identity

There are multiple risks to an authentication event. For example:

The impact of these risks on a particular use case must be considered to determine the importance of the following criteria when selecting External Identity Providers:

It is also possible to apply other mitigations at the local level to address potential concerns of External Identity use. For example:

A Note about Non-Web Protocols

While much of this document comes from the perspective of web-based protocols, no actual dependency on specific protocols should be assumed, unless specifically noted.  Many non-web protocols, however, are not capable of supporting arbitrary external Identity Providers.

Use Cases That Do Not Involve Authentication

The work group did not consider use cases that are not associated with authentication events.  There are, however, use cases involving attribute exchange at other times.  For example, a Relying Party may retrieve information from an LDAP directory even at times when there is no active user session. Another example could be use of an ORCID; an asserted ORCID may need to be linked to or looked up from an external ORCID resolver in ways that would not necessarily involve interactive user authentication during the lookup .

We leave such cases and the trust relationships that must exist between the Identity Provider and the Relying Party for future study.


Trustworthiness of External Identities

Historically, campuses have been hesitant to build their IAM infrastructure with a strong dependence on External Identities.  On the other hand, there have also been arguments made that it is a reasonable approach to leverage External Identities in conjunction with Institutional Identities, where the External Identities can be seen as “External Authentication Mechanism Providers”. Some External Identity Providers may be more likely to detect and respond to compromised Authenticators than a local IT staff would be able. Relying on such Identity Providers’ Authentication Mechanisms, instead of a local password store, could actually be a net security improvement.

In this section, we will discuss issues related to the trustworthiness of External Identities.

Trust in authentication and Attributes from any Identity Provider (internal or external) is based on a number of factors, such as identity proofing practices or Authentication Mechanism strength. (See the “Criteria for Evaluating Identity Providers” section for a more complete list.)

Not all factors are pertinent for all relying parties, but those that are should be considered for both Internal and External Identity Providers.  Internal providers will generally be acceptable across all of these factors, but not always, particularly for high-risk services.  External providers will generally be more variable across their strengths and weaknesses.

Social providers, for example, may have strong authentication technologies, but weak identification and registration practices.  They may have highly mature operational and security practices, but the policies and business practices may lean toward monetization of the information they can collect from authentication events.  They may do regular audits, but they may not provide the results of those audits to users, and there may be no legal agreement beyond a click-through agreement with the end user, not the institution.

The appropriateness of Attributes from external providers should be assessed with the same care put to determining the requirements for business processes and technology to support internal Attributes.  They may be treated as authoritative information, default values to be updated later, or disregarded entirely.

Using Information from Multiple Providers to Increase Trustworthiness

It may be possible to leverage information from multiple Identity Providers to increase trustworthiness.  For example:

External Authentication Mechanisms and Account Recovery

When leveraging External Authentication Mechanisms to control access to internal resources the perceived or measured trustworthiness of the External Identity may impact practices around account recovery, especially where External Authentication is leveraged to initially create Institutional Identities; e.g., for generating applicant or other “affiliate” level identities.

When creating institutionally managed Authenticators, a campus will typically perform sufficient identity verification during the user onboarding process to be comfortable managing account recovery processes. When individuals have institutionally managed Authenticators, any authentication leveraging Linked External Identities is largely provided as a user convenience. If the externally managed Authenticator is compromised or lost, the institution can unlink any lost External Identities and use internal Authenticators to authenticate the user sufficiently to re-establish links to additional External Identities.

In cases where Authenticators exist only associated with a user’s External Identity, and no separate verification of the user’s identity is done, the Institution or Relying Party has no information to map the real world individual to her Internal Identity. If she loses access to her external Authenticator, and thus cannot assert her External Identity, the process an institution supports to allow her to regain access to her Internal Identity may be impacted. Questions to consider in these cases include:


Architectural Patterns for Integrating External Identities

In this section, we will describe architectural approaches to integrating External Identities for Relying Parties.

This section describes approaches to implementing External Identity integration. Many of the options listed support some form of “offloading” of elements of the integration from Service Providers onto dedicated institutional IAM services. These services can be implemented in a standalone manner that the Service Providers can invoke directly, they can be deployed via separate “gateway” or proxy services that sit between the application and External Identity Providers, or they can be integrated directly (and typically transparently) into the campus IAM system. As of this writing it is most common to see these functions made available via standalone gateways.

The term “gateway” implies a separate appliance, but any of these gateway functions can also be built into the native IAM infrastructure.

For clarity, each function will be discussed distinctly to call out its specific pros and cons. However many of these services can be, and in practice are, provided together in the same service.

Detailed technical evaluation of each architectural element, such as specific implementation and configuration details, is beyond the scope of this workgroup, but could be a useful area of focus for future workgroups.

No IAM Services/Direct Integration with External Identities

The most direct approach to integrating with External Identities is to put support for those Identities and providers directly in the Relying Party. The Relying Parties directly connect to/authenticate against External Identity Providers.

Protocol Translation

Protocol Translation services provide a gateway or proxy to allow the Relying Party to communicate with External Identity Providers without using the same protocol as that External Identity Provider. The most common current use case is to support a SAML/Shibboleth Service Provider connecting to an OAuth External Identity Provider.

Attribute Mapping

Provide a service to map Identifiers from External Identity Providers into Attribute names and formats that are already known to the Relying Party.

Shared Relying Party Proxy

The Shared Relying Party Proxy approach advertises a single Relying Party entity to the External Identity Provider. By having multiple Relying Parties behind a single proxy, they appear to be one Relying Party to External Identity Providers. Many use cases combine this approach with the institutional account linking service described in the next section.

Institutional Identity Linking

The IAM can manage account linking between External Identities and Institutional Identities. By itself this service extends the IAM services to allow a user’s External Identities to be linked to the Internal Identities directly, so that given an External Identity a Relying Party can find the appropriate Internal Identity and pull identity information from that Identity.  This pattern is common for virtual organizations.

While such a service could be deployed individually, all cases we’ve seen have combined it with the “Shared Relying Party Proxy” approach listed above.

External Authorization Services

A rapidly evolving best practice for managing authorization or at least some portion of application authorization is to externalize it into its own service. Commonly this will be done with a service such as Grouper that has its own interface for assigning entities to permission groups.

The pros of an authorization service are not at all specific to External ID use cases, and can be used for authorization management even when External IDs are not supported. Externalized authorization services are called out because it is a commonly considered approach for managing permissions of External Identities across an institution, especially for “lightweight” or “authorization only” identities that do not have distinct “person” identities in the campus’ IAM system.

Invitation Services

Invitation Services provide a provisioning workflow to provide access and specific permissions to an External Identity holder. A common use case is to allow students to authorize (invite) their parents to view specific parts of the student’s record (e.g., outstanding balance). The invitation service provides an interface to identify who to invite (a link to the parent’s External Identity) and what permissions to provide the invitee (“view bill”) . The invitation service orchestrates the notification to the invitee, creates any necessary Internal Identity or authorization information, registers the linkage of the External Identity to the Internal Identity and/or authorization information.

The invitation use case is in contrast to the “Just In Time” or “front-channel” provisioning model, where a system is configured to create an Internal Identity on-the-fly using the Identifier and identity Attributes provided in an authentication assertion. It also contrasts with “back end provisioning”, where provisioning is done out of band and is typically driven by independent business rules.


Criteria for Evaluating Identity Providers

The following criteria were identified by the Working Group as important for assessing External (or Internal) Identity Providers.  The relative importance of individual criteria, of course, will depend on the specific use case.

Informal assessments of common External Identity Providers can be found on the External Identities Working Group wiki space:  Evaluating External Identity Providers.

Account Management Policies

Account Identity Vetting

AuthN Policies

Operational Concerns

Company Details

Liability and Legal Concerns

Other Concerns



Integration of External Identities into internal systems can afford multiple benefits. These benefits do not come without a cost, however: The trustworthiness and other aspects of External Identity Providers’ operations must be assessed, and the External Identity Provider’s technology must be integrated into the local system.