Identity Federation Requirements

Transcription

1 Identity Federation Requirements By: Technical Editing Author: Stephen Skordinski Version: Published: September 26, 2012

2 Document Change History for Technical Documents Template Version Number Version Date Information Affected Author (s) Authorized by /13/2012 First Draft Stephen Skordinski IdF v2 Working Group Document Contributors Contributor Name Richard Skedd Christopher Olsen Mark King Pierre Pavlenyi Tony Bass Dave Smith Luis Dannenfels Stephen Skordinski Contributing Company BAE Systems The Boeing Company EADS EADS Lockheed Martin Lockheed Martin Raytheon TSCP IdF v.2 Requirements i

3 Copyright 2012 Transglobal Secure Collaboration Participation Inc. All rights reserved. Terms and Conditions Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as further specified at (each a TSCP Member ). This specification was developed and is being released under this open source license by TSCP. Use of this specification is subject to the disclaimers and limitations described below. By using this specification, you (the user) agree to and accept the following terms and conditions: 1. This specification may not be modified in any way. In particular, no rights are granted to alter, transform, create derivative works from or otherwise modify this specification. Redistribution and use of this specification, without modification, is permitted provided that the following conditions are met: Redistributions of this specification must retain the above copyright notice, this list of conditions, and all terms and conditions contained herein. Redistributions in conjunction with any product or service must reproduce the above copyright notice, this list of conditions, and all terms and conditions contained herein in the documentation and/or other materials provided with the distribution of the product or service. TSCP s name may not be used to endorse or promote products or services derived from this specification without specific prior written permission. 2. The use of technology described in or implemented in accordance with this specification may be subject to regulatory controls under the laws and regulations of various jurisdictions. The user bears sole responsibility for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such laws or regulations. 3. THIS SPECIFICATION IS PROVIDED AS IS AND WITHOUT WARRANTY OF ANY KIND. TSCP AND EACH TSCP MEMBER DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, ACCURACY, AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER TSCP NOR ANY TSCP MEMBER WARRANTS (A) THAT THIS SPECIFICATION IS COMPLETE OR WITHOUT ERRORS, (B) THE SUITABILITY FOR USE IN ANY JURISDICTION OF ANY PRODUCT OR SERVICE WHOSE DESIGN IS BASED IN WHOLE OR IN PART ON THIS SPECIFICATION, OR (C) THE SUITABILITY OF ANY PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF TSCP OR ANY THIRD PARTY. 4. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS SPECIFICATION, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM AGAINST TSCP OR ANY TSCP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 5. TSCP reserves the right to modify or amend this specification at any time, with or without notice to the user, and in its sole discretion. The user is solely responsible for determining whether this specification has been superseded by a later version or a different specification. 6. These terms and conditions will be interpreted and governed by the laws of the State of Delaware without regard to its conflict of laws and rules. Any party asserting any claims related to this specification irrevocably consents to the personal jurisdiction of the U.S. District Court for the District of Delaware and to any state court located in such district of the State of Delaware and waives any objections to the venue of such court. IdF v.2 Requirements ii

4 Contents 1 Introduction Purpose Target Audience Document Notation Overview Identity Federation Process Flow Identity Federation Entities Requirements Establishing the Trust Authenticating the User Home Realm Discovery Level 4 Holder of Key Assertions Authorizing the User Information Provisioning between Identity Providers and Relying Parties Step Up Authentication TSCP Assertion Profile Extension Session Termination Audit and Verification... 6 Figures Figure 1. Identity Federation Business Activities... 2 Figure 2. Federation Entities Interaction and Roles... 3 Tables Table 1. Federation Business Activity Definitions... 2 IdF v.2 Requirements iii

5 1 Introduction 1.1 Purpose The purpose of this document is to identify the requirements for the TSCP IdF v.2 project. The document only captures the requirements for the project and is not intended to describe how the solution design will meet these requirements. IdF v.2 is intended as a solution which builds on the existing TSCP IdF v.1 infrastructure and documentation. As such, this document does not duplicate the contents of the IdF v.1 project, and captures only requirements which are not addressed in IdF v.1. In addition, the IdF v.2 requirements are aligned with the TCSP Architecture Board s Roadmap for Identity Federation and the IdF v.2 stakeholder group. 1.2 Target Audience The intended audience for the document is the TSCP SE v.2 Project Team, TSCP Gold and Silver members with solutions related to the requirements, and the TSCP Architecture Board. 1.3 Document Notation The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. IdF v.2 Requirements Page 1 of 6

6 2 Overview 2.1 Identity Federation Process Flow Defining a Common Taxonomy: Identity Federation is a vast subject matter. In order to define requirements and areas where TSCP can develop specifications and services to improve secure collaboration and reduce costs, we must first agree to a taxonomy and classification of the business activities that make up Identity Federation. Figure 1 below shows the flow of activities that occur. Establishing Trust Authenticating the User Authorizing the User Session Termination Audit and Verification Figure 1. Identity federation business activities. Table 1 below provides additional details around the definitions for each of the business activities. Table 1. Federation business activity definitions. Business Activity Establishing Trust Authenticating the Sender Authorizing the Sender Session Termination Audit and Verification Definition Establishing trust combines both technical and policy aspects of trust between parties. This activity covers how an organization connects to federation partners, from everything from contracts, SLAs, permitted credential types, and legal agreements, through system configuration of Identity Provider (IdP) and Relying Party (RP) endpoints. Authenticating the sender encompasses the process by which the user attempts to access an application, initiated at either the IdP or RP. For the purposes of this document, this activity includes credential issuance, credential management, home realm discovery, and the IdP authentication process. Authorizing the sender addresses the process used by the RP to grant access to a resource. The Identity federation activities covered under this activity include attribute exchange mechanisms between the IdP, attribute providers, and the RP; provisioning of account and organization; and step up and step down authentication by the RP. Upon completing a transaction, a user may wish to securely disconnect from the RP application they accessed, and/or the IdP session they opened to authenticate to the RP. Users may want all sessions closed with all providers (global logout), or they may choose to end sessions with a specific subset of RP applications with which they were doing business. Verification that federation participants are operating securely and according to agreements. Examples of these activities include IdP monitoring and reporting, third party assessments, and incident forensics. IdF v.2 Requirements Page 2 of 6

7 2.2 Identity Federation Entities The purpose of this section is to provide a high level overview of the key entities that play a role in identity federation, and specifically to identify terms that will be referenced throughout the remainder of this document. Figure 2 below describes federation entities interaction and roles. Figure 2. Federation entities interaction and functional roles. An identity federation infrastructure involves the following entities: Attribute Provider An entity which stores authoritative data related to the Security Principal. The attribute provider may provide attributes to the IdP that are included in the assertion issued by the IdP. Auditor An entity which audits the implementation of the COR by the IdP and Credential Provider(s). Audits 1) compare the mapping of the COR to the IdP s practice statement and 2) examine the IdPs systems and operations for compliance with the practice statement. Credential Provider An entity that issues digital identities to Security Principals, and which performs any identity proofing or vetting that may be required to ensure a valid binding of a Credential to the Security Principal. Relying Party (RP) An entity that accepts an assertion as a method of authentication of a Security Principal. Examples of relying parties include systems that will use the attributes associated with the identity to make access control decisions. IdF v.2 Requirements Page 3 of 6

8 Security Principal This role is an entity, usually a person, who requests access to resources maintained by the Relying Party. The Security Principal can be positively identified and verified via an authentication process by the IdP using the Credential provided by the Credential Provider. Identity Provider (IdP) An entity which validates that the Security Principal has possession and control of a Credential that is issued by the Credential Provider. The IdP may or may not be the same entity as the Credential Provider. The IdP consumes one or more Credentials presented by the Security Principal, supplements that Credential with attributes obtained from one or more Attribute Authorities, and creates a new assertion incorporating the obtained attributes, for transmission to Relying Parties. Trust Framework Provider (TFP) - A TFP is an entity that defines or adopts an on-line identity trust model and then, certifies identity providers that are in compliance with that mode. The TFP is responsible for establishing and maintaining the COR. IdF v.2 Requirements Page 4 of 6

9 3 Requirements This section identifies the requirements to be addressed in IdF v.2 capability. 3.1 Establishing the Trust No Requirements 3.2 Authenticating the User Home Realm Discovery The IdF v.2 capability MUST support IdP initiated application sign on. The IdF v.2 capability SHOULD support RP initiated application sign on. The IdF v.2 capability MUST support internal domain hub initiated application sign on. IdF v.2 capability MUST reduce the burden on the user to select their Identity Provider, when authenticating to a federated application. (This is commonly referred to as IdP pick list bloat; as the number if IdPs for an applications grows, so does the complexity for the end user.) The IdF v.2 capability MUST use existing COTS tools to improve Home Realm Discovery issues. The IdF v.2 capability MUST use existing standards to improve Home Realm Discovery issues. The IdF v.2 capability SHOULD address the EU policy requirements for cookie usage Level 4 Holder of Key Assertions The IdF v.2 capability MUST meet the requirements identified in the TSCP Common Operating Rules for the technical implementation of level 4 assertions. The IdF v.2 capability SHOULD leverage COTS solutions and existing standards for the implementations of level 4 claims. The IdF v.2 capability MUST support level 4 claims for SAML 2.0. The IdF v.2 capability MUST support level 4 claims for WS-Federation. The IdF v.2 capability SHOULD reference the implementation approach documented in the TSCP Architecture Committee Level 4 Bearer Claims. 3.3 Authorizing the User Information Provisioning between Identity Providers and Relying Parties IdF v.2 capability MUST address the provisioning of user data. IdF v.2 capability MUST address the provisioning of organizational data. IdF v.2 capability SHOULD address the provisioning of the TSCP BAF Protection Profile. The IdF v.2 capability MUST identify a repeatable means to provision shadow accounts from IdPs to RPs. The IdF v.2 capability MUST consider pre-provisioning use cases. The IdF v.2 capability SHOULD consider the Just in Time provisioning use cases. The IdF v.2 capability SHOULD leverage COTS solutions for the implementations of provisioning solutions. The IdF v.2 capability SHOULD leverage existing standards for the implementations of provisioning solutions. IdF v.2 Requirements Page 5 of 6

10 3.3.2 Step Up Authentication IdF v.2 MUST enable a means for RPs to request a stronger credential assertion from the IdP when the user transitions from a lower LoA application to a higher LoA application. IdF v.2 MUST enable a means for RPs to request a stronger credential assertion from the IdP when the user transitions from a lower LoA action to a higher LoA action within the same application. The IdP MUST be able to support secondary requests from the RP for stronger assertions. The RP MUST be able to hint back to the IdP the authentication (LoA, credential type, etc.) required by the RP (this is to avoid a looping scenario, e.g., a user authenticates with LoA 2, takes action that requires LoA 3, and is redirected back to RP who enters a LoA 2 credential.) The IdF v.2 capability MUST support step up authentication using SAML 2.0. The IdF v.2 capability MUST support step up authentication using WS-Federation TSCP Assertion Profile Extension The IdF v.2 assertion profile MUST build on the assertion profile developed by the DSIF v.1 program. The IdF v.2 assertion profile MUST address the extended attribute requirements identified by the TSCP ILH team. The IdF v.2 assertion profile SHOULD be extended to address non-human entities, such as devices. The IdF v.2 assertion profile MUST be extended to address the Holder of Key requirements. The IdF v.2 assertion profile MUST continue to support WS-Federation. The IdF v.2 assertion profile MUST continue to support SAML 2.0. Where necessary, the corresponding sections of the TSCP Common Operating Rules MUST be updated to reflect the changes necessary for definitions of attributes defined in the assertion profile. 3.4 Session Termination No Requirements 3.5 Audit and Verification No Requirements IdF v.2 Requirements Page 6 of 6