Abstract

This document is a product of the FI Work Group, but strongly related to the IAWG as well. It defines the scenarios and use cases of Identity Federations to have a good understanding of the system under discussion when refining the scope.

Status

This document is currently under active development. Its latest version can always be found here. See the GI:Change History at the end of this document for its revision number.

Editors

Rainer Hörbe

Intellectual Property Notice

The FI Work Group operates under Creative Commons Share-Alike Attribution IPR Option and the publication of this document is governed by the policies outlined in this option.

Table of Contents

Introduction

This documents describes a set of identity management scenarios to define the scope for the Federation Interoperability and IAF. Each scenario is a collection of business level use cases. Starting with a well-known baseline scenario of 3 actors (Subject, Identity Provider and Relying Party), derived scenarios shall reflect variants of actors and their trust relationships by adding following aspects:

1. Completeness of trust model: Trust establishment, subject life cycle management
2. Actor centricity: Depending on the background, users, service providers or network operators might shape the use case.
3. Jurisdictional structure:
   • Intra-organizational (single policy authority, centralized enforcement)
   • Cross-organizational (single policy authority, negotiated between autonomous actors)
   • Federation (shared or external policy authority)
   • Cross-border (across multiple national legislations)
   • Grid/cloud: is it a different structure?
4. AA (Attribute Authority) different from IdP
5. Organizational context: Enterprise user vs. consumer/natural person
6. Subject class: human user vs. device/service
7. Trust type: peer to peer, hierarchy/trust anchor, reputation based.
8. Type of communication payload: document-centric vs. session-centric (or both in case of messaging)
9. Restriction to electronic communication vs. physical access
10. Off-line mapping of EAA policies vs. automated policy negotiation in real-time

Trust Relationships in Federated Identity Management (Pending)

A common interpretation of trust in an identity federation is that a RP trusts the IdP to provide entity authentication at an expected assurance level. However, this view is incomplete, as there are several trust relationships involved:

Not all of these trust relationships are usually associated with the term Identity Management, but are required to fulfill the complete set of security and privacy requirements by all actors.

Scenarios

Scenario S01: Delegated Authentication (Pending)

This view primarily shows the separation of identity services from the RP’s service.

Prerequisite

• Subject is subscribed to IdP service
• RP delegated subject authentication (including registration) to IdP

Description

• A subject is requesting access to a resource owned by RP
• RP is delegating authentication to IdP
• IdP will require authentication from subject, or use a valid previously authenticated session
• IdP will assert the authentication event, and possibly include subject attributes for the RP
• IdP will deliver the assertion to the RP
• RP will grant subject access to the requested resource

Trust Relationships

Even though this use case has a minimalistic view on identity management, most trust relationships can be shown:

• TR-1-EntityAuthN
• TR-2-IdPAvailibility
• TR-3-3rdPartyDP
• TR-4-UserSec
• TR-5-PII@IdP-Prot
• TR-6-IDM-PII@RP
• TR-7-Service-DP@RP
• TR-8-RP-Maleware

Actors

IdP (Identity Provider), RP (Relying Party), Subject
Any one of these actors can be primary actor.

Scenario S10: Delegated Identity Management (Pending)

Extends and completes scenario S01

This use case is more complete as it includes the registration of the subject to the IdP and the establishment of trust by the RP.

Actors

Inherited: IdP, RP, Subject
Subscriber, Registration Officer

Scenario S20: Service Provider Centric model (Pending)

Extends scenario S01, shows aspect of actor centricity

This scenarios is dominated by the demand to protect the assets of a service provider (as relying party), like application data. As Identity Management is an important part of the information security management, service providers are concerned that those functions that are delegated to IdPs are executed at the same or better level as the SP would do it on its own. As a consequence, the trust relationship requirements focus on:

• TR-1-EntityAuthN
• TR-2-IdPAvailibility
• TR-3-3rdPartyDP (This is frequently managed outside the trust federation with the RP’s Terms of Use.)

This view works well for the case when enterprise work on data owned by third parties and end user privacy is of little concern, like in typical B2B and G2G scenarios.

Actors

RP (primary actor), IdP, subject

Scenario S21: User Centric model (to be completed)

Extends scenario S01, shows aspect of actor centricity

This use case is driven by the demand to protect the privacy of a user. As a consequence, priority is given to following trust relationships:

• TR-5-PII@IdP-Prot
• TR-6-IDM-PII@RP

The desired result is, that users can control and enforce various privacy and security policies governing the exchange of identity information and PII person-to self-type applications.

Actors

Subject (primary actor), IdP, RP

Scenario S22: Network-centric RP (to be completed)

Extends scenario S01, shows aspect of actor centricity

The primary stakeholder in this scenario is a network operator which needs to protect the network (as relying party), like service and transport management functions in PSTN, mobile and IP/multimedia networks. Trust concerns have their priorities at

TR-1-EntityAuthN
TR-2-IdPAvailibility
TR-3-3rdPartyDP
TR-4-UserSec
TR-5-PII@IdP-Prot
TR-6-IDM-PII@RP
TR-7-Service-DP@RP
TR-8-RP-Maleware
TR-9-RP2FO
TR-10-IdP2FO

• TR-1-EntityAuthN and
• TR-2-IdPAvailibility

Actors

Inherited: IdP, RP, Subject

Scenario S30: Intra-organizational IDM, loosely coupled units (to be completed)

Extends scenario S01, shows jurisdictional structure aspect

Some organizations have loosely coupled organizational units with certain autonomy. There is a single policy authority with some centralized enforcement, but functions of identity management and user provisioning are delegated to subunits.

This use case blends the S32 Federation S31 Ruling Party scenarios.

Scenario S31: Ruling Party IDM (pending)

Extends scenario S01, shows jurisdictional structure aspect

By expanding the acronym RP to “Ruling Party” the whole use case is almost explained.
Typically one company owns the roles of RP and IdP and is the sole authority for the access policy of its service. Although the autonomous actors are in theory free to negotiate the terms of use, in practice the organizations subscribing the service will have to take or leave the terms.

This is a degenerated use case, as this federation is not a circle of trust, but a trust hierarchy. 

Actors:
Service Provider (acting both as IdP and RP) is primary actor; Subject
Secondary RPs (with less important services) may join, but are subject to the governance of the primary RP.

Scenario S32: Identity Federation (Pending)

Extends S10, shows aspect of jurisdictional structure

This scenario adds 2 major views:

1. Identity life cycle management (attribute updates, credential revocations)
2. Trust management (policy implementation, maintenance and enforcement)

Trust Relationships

As this federation makes the concepts of trust anchor, meta data and audit explicit, additional trust relationships are introduced:

• TR-9-RP2FO
• TR-10-IdP2FO

Actors

Inherited: IdP, RP, Subject, Subscriber, Registration Officer
Auditor, FO (Federation Operator), PMA (Policy Management Authority)

Scenario S33: Cross Border Identity Federation (pending)

Extends scenario S32, shows aspect of jurisdictional structure

Key point is the federation across multiple national legislations. The trust framework must accommodate to different laws and a common set of federation-specific rules. The structures for policy management need to accommodate this fact.

Sample case: the epSOS project, which provides health care professionals access to patient summaries and prescriptions across borders of European countries. The core system consists of a set of national gateways forming a circle of trust. At the point of care a query is sent to the national gateway, which brokers trust to the gateway of the country the patient is affiliated with.

Trust replationships are the same as in S32.

Scenario S40: Attribute Provider separate from IdP (pending)

Extends scenario S01, shows aspect where AA is different from IdP

Attribute providers (AP) are actors separate from IdPs, because they have a different business model, are operated by a different legal entity (like the authoritative source), or there is only a partial overlap between the managed subjects.

RP might need a trust relationship that is a subset of type TR-1. However, it is quite likely that contracts between RP and AA are different from those between RP and IdP, because if the AA is the only source of authority, there is no lever for the RP to require more than best effort. E.g. national law in most countries regulates the qualification of a medical doctor, so the attribute “ophthalmologist” can only be provided by the organization defined by law. Hence trust is based on the fact that the AA operates with due diligence and could be sued in case of a negligence, but there is no legal basis to require audits or other safeguards to prevent damages beyond unsolicitous agreements.

Actors

Inherited: IdP, RP, Subject
AA (Attribute Authority)

Scenario S50: Enterprise user (pending)

Extends scenario S01

Description

Primary Stakeholders in this scenario are the RP and UHO (User Home Organization, like an enterprise). The key difference to scenario S20 (Service Provider Centric model) is that the subject is part of an organization with multiple roles. The legal counterpart to the RP is the UHO.
Identity management in the pure sense of authenticating a named subject may be delegated to an external entity, such as a CA, or can be part of the UHO.
Policy management in the sense that roles or more complex policies are assigned to subjects is best executed within the UHO, because it has the responsibility and knowledge to do this.

Example: RP is a hospital and provides an appointment service where external health care providers (HCP) can manage appointments for their clients. The application provides 3 attributes: Role (doctor, assistant, patient), department (<the list of medical departments>) and affiliation (HCP, self). The policy for a joint practice (ophthalmologist and GP) would look roughly like this:

• Doctor (ophthalmology) can manage appointments in the departments for eyes and internal medicine and add and review some medical data for her affiliated patients;
• Assistant may manage appointments for all departments (because she is assistant to the GP) for the surgery’s affiliated patients;
• Patient may view and cancel appointments related to herself.
  The doctors are responsible to assign roles within the joint practice and use an external policy management service to maintain electronic policies that can be consumed by other HCPs.
  When a user wants to perform a transaction on the appointment service, following sequence is executed:

• RP requires authentication
• User authenticates to IdP
• IdP asserts identity to RP
• RP requires policy (containing policy attributes related to the user)
• PDP asserts policy to RP
• RP takes access decision

Trust Relationship TR-3-3rdPartyDP is extended to cover the trust in policy management by the UHO.

Actors

Inherited: IdP, RP, Subject
UHO (User Home Organization), Subscriber, Policy Manager, Policy Decision Point, Registration Officer

Scenario S60: Subject Types (pending)

Extends S10 shows aspect of subject type

There are no new trust relationships. However, specific rules need to address the security challenges of autonomous devices, such as management of key material.

Actors

Inherited: IdP, RP, Subject, Subscriber;
Human subject, device/service

Scenario S70: Reputation-based Trust (t.b.d.)

Extends UC32, shows aspect of trust type

The standard model is hierarchical trust. It requires some root authority, like a body issuing a self-signed trusted certificate. In most cases there are hidden or unspecified root authorities, like browser vendors with their pre-installed root certificates, or operating system vendors with preinstalled DNS root zone files.
Reputations-based systems have a process that will compute trust based on behavior of claimants and rating of members. This is not necessarily limited to humans, but could be used for IdPs and other roles in federation as well.

Actors

Scenario S80: Document-centric Transaction (pending)

Extends S01, showing aspect of payload type

Typical identity federation use cases like those describe above usually imply the session-centric model: subject authenticates to a network or an on-line service, establishes a security context performs the desired communication or transaction within this context.

Exchanging signed documents has the same basic trust relationships as the session-based model, but uses a different terminology for historical and technical reasons. The certificate authority is a case of an IdP, the document receiver who verifies the signature is a case of a relying party.

No additional trust relationships need to be added to the basic scenario.

Actors

Inherited: IdP, RP, Subject

Scenario S90: Physical Access (tbd)

Extends UC01, shows aspect of access type

Whereas all use cases mentioned above imply remote electronic authentication, the system might be applied to physical access as well. The apparatus controlling physical access could be seen as RP, so the scenario would fit to the trust federation.
However, there are some issues that suggest that identity federations should be limited to electronic communication, because

• Physical access is usually in the scope of a single enterprise, and
• Physical access might need a combination of electronic authentication and local supervision or check.

Scenario S100: Inter-Federation requiring automated policy negotiation (t.b.d.)

Extends UC32, shows aspect of method of policy mapping

Actors

Inherited: IdP, RP, Subject

Scenario 99: Abuse Cases (pending)

Not sure if this document is a good place for this scenario. It shows typical attacks on trust relationships.

Extends scenario S32

Actors

(Inherited) + Internal and external attackers

Abbreviations

Change History