sm Open Data Center Alliance Usage: Identity Interoperability Guide rev. 1.0
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Table of Contents Legal Notice... 3 Executive Summary... 4 Purpose... 5 Audience... 5 Assumptions... 5 General Principles... 6 Overview... 6 Reference Framework... 8 Applicability... 9 Reference Model...11 Usage Models...12 Infrastructure as a Service (IaaS) Privileged User Access...12 Single Sign On...12 Identity Provisioning (add/modify/delete)...12 Access Control Services...13 Identity Federation...13 References...14 Industry Call to Action...14 Summary of Acronyms...15 2
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Legal Notice This Open Data Center Alliance SM Usage Model: Identity Interoperability Guide is proprietary to the Open Data Center Alliance, Inc. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only have the right to review, and make reference or cite, this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc. s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance s bylaws and its other policies and procedures. OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo SM are service marks owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document and its contents are provided AS IS and are to be used subject to all of the limitation set forth herein. Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations. This document does not grant any user of this document any rights to use any of the Alliance s trademarks. All other service marks, trademarks and trade names referenced herein are those of their respective owners. Published April, 2012 3
sm Open Data Center Alliance Usage: Identity Interoperability Guide rev. 1.0 Executive Summary Many organizations that are considering purchasing cloud-based services already have fully integrated identity and access management systems. These systems are normally widely connected throughout the internal systems of an organization and allow automated procedures for provisioning, enabling, and disabling user s entitlements, as well as entitlement analysis and reporting. As the resources in the cloud become more prevalent in the enterprise, the user and systems administrators will expect this functionality to be maintained. This Identity Interoperability Guide provides the structure and guidelines that will promote interoperability between identity management and access management systems that will allow users within organizations to utilize resources in the cloud as if they were located within the organization. 4
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Purpose The purpose of this guide is as follows: to describe the requirements for a cloud specific runtime which will allow companies adopting the cloud to promote interoperability between providers, to define the interface between the Identity management software and the runtime, to define the interface between the runtime and the application software, to support as much automation in the identity management processes as possible. The cloud provider and identity management software communities will first need to propose sample implementations for review within the ODCA. In addition suitable standards should be proposed that will enable standardized communication between the respective elements of the described model. If suitable standards do not exist, proposals should include the appropriate base standard and how it should be further developed. Audience The targeted audience for the ODCA identity management documents is architects and security practitioners in charge of implementing the herein described principles and requirements as cloud providers and as cloud subscribers. Assumptions The assumption for this work is that a cloud subscriber, having identity management (IdM) in place within its own premises, expects to expand its usage into the cloud. It is assumed that cloud subscribers are striving for as much automation in the cloud as in their own premises. Central management of identities and authorizations, as well as cyclic authorization review processes, will include the cloud. Cloud infrastructure must support the cloud subscriber s security standards and procedures, in order to integrate seamlessly with existing systems and applications on premises. The cloud subscriber expects interfaces provided by the cloud provider to support automated management processes and administration procedures. It is assumed that a cloud subscriber adheres (at least) to the same level of maturity as the one expected by the cloud to which it subscribes. 5
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 General Principles All assumptions made in the usage models follow the following principles: 1. Standards required are minimal requirements; it is left open for a cloud provider to provide other standards additionally, especially when a standard gets widely adopted (e.g. Service Provisioning Markup Language (SPML) for provisioning vs. some other provisioning standard). Important standards which might be supported by the cloud provider are as follows: a. SPML for identity lifecycle management b. Security Assertion Markup Language (SAML) and OpenID for identity and authentication management c. EXtensible Access Control Markup Language (XACML) and OAuth for authorization and permission management d. Open Group s Distributed Auditing System (OpenXDAS) for auditing and monitoring. 2. Both cloud provider and cloud subscriber are responsible to check their common agreements and contracts to be compliant with the laws and regulations of their local jurisdictions and any other applicable jurisdiction. Rationale: Beside contractual agreements and/or policy statements, external factors (like local jurisdiction) might lead to force a cloud provider to perform actions not foreseen in his contract with a cloud subscriber, due to contradictory laws between the countries of the could provider and the cloud subscriber. 3. A cloud subscriber and the cloud provider have to ensure compliance to the minimal security requirements of the cloud level of assurance (i.e. bronze/silver/gold/platinum). This minimal compliance is required in order to avoid impacting other subscribers of the same cloud. 4. Following principle 3, users have to provide a trustable identity by being authenticated according to the security requirements of the cloud. If a high level of trust is required, this is also valid for identities. Strong authentication is then required (typically two-factor authentication) to fulfill this requirement. Weak authentication (i.e. user-id and password) is sufficient where high level of trust is not required (e.g. bronze level cloud). Typically, high privileged users are always required to perform strong authentication, in order to provide a trustable audit trail of their activities in the cloud. Overview The overall identity management system envisaged in this document is split into three primary sections as shown below. Identity Software The first of these is the Software. The function of this block is to provide a user interface, password reset, password ageing, Authorization functionality, etc. The management software will typically be located inside the organizational network. The second element is the runtime, the component of the system that directly handles the requests for authentication from an application. Cloud-based runtimes must be capable of communicating, via the standard management interface, with the management software. Typical runtimes that exist within an organization are Active Directory, RACF (z/os mainframe), LDAP, Tivoli Access Manager (TAM), SiteMinder, etc. 6
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 The location of the runtime will depend on the application requirements and will often be decided based on the performance issues and application requirements. The third element is the application. This will hold or will communicate with the runtime component in order to have the access rights of an individual using the application. All identity or entitlement data stored in cloud-based runtimes and communication between system components (between the IdM software and the runtimes) must be encrypted. All communication between system identity and access management components must be encrypted and trusted (i.e., mutual authentication of the components is mandatory). Previously defined standards (such as those developed by the Organization for the Advancement of Structured Information Standards (OASIS) Group) will be utilized throughout the Identity and Access usage models. It is envisaged that a cloud-specific runtime will exist that provides the interface between the identity management software and the cloudbased applications. This runtime component will communicate to the management software and the applications through standard interfaces, thereby ensuring compatibility. This runtime must be capable of running in a fully encrypted mode (which may result in some performance degradation) or unencrypted (faster response times). The instance of the runtime allocated to a single cloud subscriber will only contain information relevant to this cloud subscriber. Identity and access management data must be protected by the cloud provider against any access except from the cloud subscriber. Bronze level: segregation of data through access rights (database privileges) within shared resources (e.g. applications, databases) Silver level: additional segregation through multi-tenancy of resource structures (e.g. own database plan/schema on database server) on a shared virtual machine (VM). Gold level: separate runtime instances and virtual machines (e.g. own Operating System (OS), databases, applications) on shared hardware Platinum level: physically separated instances of hardware, VMs, OS, databases and applications per cloud subscriber. s must accept authentication information from multiple or different runtimes (for example with collaboration projects). Non Cloud Identity Software Cloud Accessible Cloud Encrypted Cloud Accessible Cloud Accessible Component The cloud accessible runtime component is referred to throughout this document and is envisioned to be a standard component that is used for the authorization of all cloud-based resources. It may be stored in the cloud (typically at the same location as the cloud resources) but, in this case must be encrypted. 7
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Reference Framework The following diagram shows a framework of the functional areas of identity management. This framework provides a reference model for the usage models described below. Identity and Access Framework Identity and Access Identity Lifecycle Identity and Authentication Authorization and Permission Lifecycle Authorization and Permission Identity Governance Identity Creation/ Validation Identity Federation Entitlement Externalization Access Control Services Confirm Validation Identity Provisioning (add/modify/delete) Directory Services / User Repositories Entitlement Provisioning Policy Enforcement Point (PEP) Auditing and Reporting Mover / Leaver Process Authentication Mover / Leaver Process Policy Decision Point (PDP) Monitoring Strong Authentication Role Mining and Discovery Weak Authentication Reporting for Audit / Compliance Checks Sign On Multiple Sign On Reduced Sign On (web, desktop) Single Sign On Credential Policy Enforcement Point (PEP) Note: The yellow boxes represent functional areas; they are not IdM functions by themselves. The green boxes represent IdM services or service groups. The blue boxes represent IdM services. 8
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Applicability The following diagram details the applicability of each of the usage models to the relevant hosting scenarios available in the cloud model. Frontend (PaaS / SaaS) Backend (PaaS / SaaS) Hosted Infrastructure (IaaS) Identity Lifecycle Identity Creation / Validation ü ü ü Identity Provisioning (Add / Modify / Delete) ü ü ü Identity Governance (Audit / Confirm Validation) ü ü ü Mover / Leaver Process ü ü ü Identity and Authentication Identity Federation ü ü ð Directory Services / User Repositories Authentication ü ü ü Strong Authentication Weak Authentication Sign On ü ü ü Multiple Sign On Reduced Sign On (web / desktop) Single Sign On Credential ü ü ü Policy Enforcement Point (PEP) Authorization and Permission Lifecycle Entitlement Externalization ü ü ð Entitlement Provisioning ü ü ð Mover / Leaver Process Role Mining and Discovery ü ü ð Authorization and Permission Access Control Services ü ü ð Policy Enforcement Point (PEP) Policy Decision Point (PDP) Legend: ü= mandatory, = optional, ð= not applicable, Ï= not available Optional means optional for the cloud subscriber, but mandatory for the cloud provider to provide! 9
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 The following diagram details the applicability of each of the usage models to the cloud provider. Assurance levels bronze, silver, gold, and platinum are defined in the ODCA Provider Assurance Usage Model 1. Bronze Silver Gold Platinum Identity Lifecycle Identity and Authentication Authorization and Permission Lifecycle Authorization and Permission Identity Creation / Validation ü ü ü ü Identity Provisioning (Add / Modify / Delete) Identity Governance (Audit / Confirm Validation) ü ü ü ü ü ü ü Mover / Leaver Process ü ü Identity Federation ü ü Directory Services / User Repositories ü ü ü Authentication Strong Authentication ü ü ü Weak Authentication ü ü Ï Ï Sign On Multiple Sign On ü Ï Ï Reduced Sign On (web / desktop) ü Single Sign On ü ü ü Credential Policy Enforcement Point (PEP) ü ü ü Entitlement Externalization ü ü Entitlement Provisioning ü ü ü ü Mover / Leaver Process ü ü Role Mining and Discovery ü ü Access Control Services Policy Enforcement Point (PEP) ü ü ü ü Policy Decision Point (PDP) ü Legend: ü= mandatory, = optional, ð= not applicable, Ï= not available Optional means optional for the cloud subscriber, but mandatory for the cloud provider to provide! 1 www.opendatacenteralliance.org/docs/odca_providerassurance_rev.%201.1_final.pdf 10
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Reference Model The following picture illustrates the relation between the services of identity and access management. This picture should be used for indicative purposes only and is not intended to be definitive. Data Sources Extract / Synchronize Identity Mng Systems Resources Identity Information HR Processes / System Data is fed into system / HR processes trigger event Provision (RBAC + Request) Compliance / Reporting Identity Creation / Validation Data Sync / Password Sync / Auto Provision s Infrastructure References Data Workflow Identity Provisioning New Starter Transfer Terminations Provisioning Request Identity Data Distribution Self Service Password Sync Identity Governance Entitlement Provisioning Role Mining and Discovery Provides Access to User Directory / Store Entitlement Store Policy Decision Point Entitlement Internalization Access Control Services Directory Services / User Repositories Federation System Token Generation Identity Federation Authentication System Policy Enforcement Point References to make authentication and authorization decisions Service Facilitation Authentication Requirements Authentication Identity Mapping Trust Level Sign On Session Policy Session Policy Credential Resides on enterprise network Resides in cloud May reside onsite or in cloud 11
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Usage MOdels The following usage models have been created in order to clarify the requirements of the ODCA in the area of identity management. For further details refer to the specific documents concerned. Usage Model 1: ODCA IaaS Privileged User Access 2 This usage model details the requirements for privileged users accessing IaaS. Typically privileged users will have the ability to undertake high level administrative tasks when managing the IaaS services from the cloud provider. In this respect it will be necessary to promote a higher level of security during the authentication process. Usage Model 2: ODCA Single Sign On 3 This usage model details a standard mechanism for ensuring Single Sign On (SSO) capability across cloud services. Typically major organizations will have in place a single sign on capability for services provided inside the organization. When services are extended to the cloud, particularly in the area of Software as a Service (SaaS) the user will expect this to be maintained. This usage model will detail a mechanism that may be used by cloud subscribers to promote that common SSO capabilities are provided by different cloud providers. Usage Model 3: ODCA Identity Provisioning (add/modify/delete) 4 When a cloud service has been purchased from a provider it becomes necessary to provision the users of this service. This usage model covers the process of transferring user information from the subscriber to the provider to support both usage and billing requirements and other agreed requirements. It does not cover the situation where a user is identified by the provider and then access granted based on the trust relationship between the provider and subscriber (i.e., identity federation). Cloud Subscriber Site Cloud Provider Site Identity System Identity Provisioning Identities PEP Reverse Proxy Identities and Entitlements Authentication Service (PDP) PEP Web PEP Enterprise Access Control Engine (PDP) PEP Database 2 www.opendatacenteralliance.org/docs/odca_idm_privaccess_rev1.0_final.pdf 3 www.opendatacenteralliance.org/docs/odca_idm_ SingleSign_Rev1.0_final.pdf 4 www.opendatacenteralliance.org/docs/odca_identity_provisioning_rev1.0_final.pdf 12
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Access Control Services The basic behaviour of (any) access control is illustrated in the following picture: Interaction Tier Business Logic Tier Data Tier C-FAC 1 F-FAC 2 C-DAC 3 DB 1. C-FAC = Coarse grained Functional Access Control (granularity = web application) 2. F-FAC = Fine grained Functional Access Control (granularity = business function/service) 3. C-DAC = Coarse grained Data Access Control (granularity = database table/column) 4. F-DAC = Fine grained Data Access Control (granularity = database row /tupel) Following the request path, access control decisions will become more and more granular: each additional decision reduces the visibility to data on only the data set the user is authorized to access. Simple applications may skip the finest levels of access control, but still follow this approach. The places in the request path of enforcement of an access control decision are called Policy Enforcement Points (PEP). The access control evaluation and decision is made by the Policy Decision Point (PDP); this might be located at the same place as the PEP (typical programmatic access control) or externalized to a dedicated access control runtime. Whichever the approach, the distinction between PEP and PDP allows for a large variety of implementations without being contradictory (e.g., the access control runtime of the interaction tier may look completely different from the access control of the business logic tier or of the data tier). Nevertheless, there is always a well-defined place where an access control decision is enforced and there is always a dedicated piece of code evaluating the access control decision. Identity Federation Identity federation is the technique of passing a user s identity in a trustable form to further connected systems, as external partner s application. Identity federation allows an organization to keep the user s credentials within the premises of the enterprise the user belongs to, rather than to publish its credentials to external partners. Identity federation is basically a simple thing; think of you being introduced to someone by a common friend. The person you were introduced to trusts the person who introduced you, and therefore does not ask for your own credentials to believe who you are. That s identity federation it s just not technical. In IT terms, identity federation is a mechanism which allows the promoting of a user identity in a trustable way. This is typically done by transporting a commonly accepted data container (a.k.a. token) and signing it in order to protect it against tampering. The signer of the token must be known (and accepted) by the peer receiving the token. The combination of these steps provides the expected level of trust to make the federated identity similarly trustable to an identity verified within one s own premises. F-DAC 4 13
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 References OASIS Service Provisioning Markup Language (SPML) Version 2 5 OASIS Security Assertion Markup Language (SAML) Version 2 6 Any use or other implementation of the above cited OASIS markup language specifications / protocols ( OASIS Language ) are subject to any and all intellectual property rights and other rights held by, and any other limitations or restrictions which may be asserted by, OASIS and/or its members as the owner or owners of said OASIS Language ( Proprietary Rights ). ODCA takes no position regarding the validity or scope of any such Proprietary Rights that might be claimed or asserted by OASIS and/ or its members which may pertain to the use or other implementation of said OASIS Language or the extent to which any license of any such Proprietary Rights might or might not be available; nor does it represent that it has made any independent effort to identify any such Proprietary Rights. Each user and implementer of the OASIS Language is solely responsible for obtaining any and all licenses which may be needed in order to use or otherwise implement said OASIS Language. Requests for information regarding the Proprietary Rights and any applicable licenses should only be directed to OASIS and should not be made to the ODCA. Copies of any Proprietary Rights disclosures that may have been made, or potential licenses to be made available, or the result of an attempt made to obtain a license or other permission for the use or implementation of such Proprietary Rights by any implementer or user of the OASIS Language should only be directed to OASIS. This reference to, or citation of, the OASIS Language is provided on an AS IS basis and THE OPEN DATA CENTER ALLIANCE AND ITS PARTICIPANTS AND MEMBERS HEREBY DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY WARRANTY THAT THE USE OR OTHER IMPLEMENTATON OF THE OASIS LANGUAGE (AS DEFINED ABOVE) WILL NOT INFRINGE ANY PROPRIETARY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Industry Call to Action The following further actions are required: Reconciliation/cooperation between ODCA and Cloud Security Alliance (CSA), OASIS, and National Institute of Standards and Technology (NIST) on Identity Usage Models. Usage Model should be presented to NIST and CSA to explain customer view. Usage Model should be forwarded to OASIS to determine if any further development of SAML v2.0 and SPML v2.0 is required. 5 www.oasis-open.org/standards#spmlv2.0 6 www.oasis-open.org/standards#samlv2.0 14
Open Data Center Alliance Usage: Identity Interoperability Guide Rev. 1.0 Summary of Acronyms ACL Access Control List CSA Cloud Security Alliance DAC Data Access Control FAC Functional (function based) Access Control IaaS Infrastructure as a Service IdM Identity IdMaaS Identity as a Service NIST National Institute of Standards and Technology OASIS Organization for the Advancement of Structured Information Standards ODCA OpenXDAS PaaS PEP* PDP* RBAC SaaS SAML SPML UM XACML Open Data Center Alliance Open Group's Distributed Auditing System Platform as a Service Policy Enforcement Point (where the process flow is interrupter to perform authentication or access control) Policy Deccision Point (where an authentication or an access control is evaluated) Role based Access Control Software as a Service Security Assertion Markup Language (v2.0 current during writing of this document) Service Provisioning Markup Language (v2.0 current during writing of this document) Usage Model exensible Access Control Markup Language * PEP and PDP can collapse to one single piece of logic; nevertheless, they will often be separated and will therefore have to be defined and documented as distinct architectural entities. 15