Identity Management Interoperability Guide rev. 1.0
Open Data Center Alliance Usage: Identity Management 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
Legal Notice
© 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.
This “Open Data Center AllianceSM Usage Model: Identity Management 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 ALLIANCESM, ODCASM, and the OPEN DATA CENTER ALLIANCE logoSM 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
Open Data Center Alliance Usage:
Identity Management Interoperability Guide rev. 1.0
sm
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 Management 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.
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.
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 first of these is the Management 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.
Runtime Runtime Runtime
Application Application Application Application
Identity Management Software
The overall identity management system envisaged in this document is split into three primary sections as shown below.
Open Data Center Alliance Usage: Identity Management 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 Management usage models.
It is envisaged that a cloud-specific runtime will exist that provides the interface between the identity management software and the cloud- based 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.
Applications must accept authentication information from multiple or different runtimes (for example with collaboration projects).
Cloud Accessible Runtime 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.
Identity Management Software
Runtime Runtime Cloud Accessible
Runtime
Application
Application
Application
Application Application
Encrypted Cloud Accessible
Runtime Non Cloud
Cloud
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.
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.
Authorization and Permission Management
Access Control Services Policy Enforcement
Point (PEP) Policy Decision Point
(PDP)
Identity Governance
Confirm Validation Auditing and Reporting
Monitoring
Identity and Access Management Identity and Access Management Framework
Authorization and Permission Lifecycle Management
Reporting for Audit / Compliance Checks Role Mining and
Discovery Entitlement Externalization
Mover / Leaver Process Entitlement Provisioning
Single Sign On Reduced Sign On
(web, desktop) Multiple Sign On
Sign On
Policy Enforcement Point (PEP) Credential Management
Weak Authentication Strong Authentication Identity Federation
Authentication Directory Services /
User Repositories Identity and Authentication
Management Identity Lifecycle
Management Identity Creation/
Validation Identity Provisioning
(add/modify/delete) Mover / Leaver Process
Open Data Center Alliance Usage: Identity Management 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 Application
(PaaS / SaaS) Backend Application
(PaaS / SaaS) Hosted Infrastructure (IaaS)
Identity Lifecycle Management
Identity Creation / Validation
ü ü ü
Identity Provisioning
(Add / Modify / Delete)
ü ü ü
Identity Governance
(Audit / Confirm Validation)
ü ü ü
Mover / Leaver Process
ü ü ü
Identity and Authentication Management
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 Management
ü ü ü
Policy Enforcement Point (PEP) Authorization
and Permission Lifecycle Management
Entitlement Externalization
ü ü ð
Entitlement Provisioning
ü ü ð
Mover / Leaver Process
Role Mining and Discovery
ü ü ð
Authorization and Permission Management
Access Control Services
ü ü ð
Policy Enforcement Point (PEP) Policy Decision Point (PDP)
Legend: ü= mandatory, ¤ = optional,
ð
= not applicable, Ï= not availableOptional means optional for the cloud subscriber, but mandatory for the cloud provider to provide!
Bronze Silver Gold Platinum Identity Lifecycle
Management
Identity Creation / Validation
ü ü ü ü
Identity Provisioning
(Add / Modify / Delete)
ü ü ü ü
Identity Governance
(Audit / Confirm Validation) ¤
ü ü ü
Mover / Leaver Process ¤ ¤
ü ü
Identity and Authentication Management
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 Management
Policy Enforcement Point (PEP) ¤
ü ü ü
Authorization and Permission Lifecycle Management
Entitlement Externalization ¤ ¤
ü ü
Entitlement Provisioning ü ü
ü ü
Mover / Leaver Process ¤ ¤
ü ü
Role Mining and Discovery ¤ ¤
ü ü
Authorization and Permission Management
Access Control Services
Policy Enforcement Point (PEP)
ü ü ü ü
Policy Decision Point (PDP) ¤ ¤ ¤
ü
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.
Legend: ü= mandatory, ¤ = optional,
ð
= not applicable, Ï= not availableOptional 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 Open Data Center Alliance Usage: Identity Management 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.
HR Processes / System
New Starter Data
Transfer
Terminations
Data Sources
Identity Information
Identity Mng Systems
Compliance / Reporting Provision (RBAC + Request)
Workflow
Identity Data Distribution Self Service
Password Sync
Federation System
Service Facilitation Token Generation
Identity Mapping
Session Policy
Authentication System
Authentication Requirements Policy Enforcement
Point
Trust Level Session Policy
Runtime
Entitlement Store User Directory /
Store
Policy Decision Point
Resources
Applications Infrastructure
Resides on enterprise network Resides in cloud May reside onsite or in cloud Identity
Federation
Access Control Services Directory Services /
User Repositories Entitlement Internalization
Authentication
Credential Management
Sign On Identity
Provisioning Identity Governance Entitlement Provisioning Role Mining and Discovery Identity Creation /
Validation Extract / Synchronize
Data is fed into system / HR processes trigger event
Provisioning Request
Data Sync / Password Sync / Auto Provision
References
Provides Access to
References to make authentication and authorization decisions
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).
Identity Management System
Authentication Service (PDP)
Identities and Entitlements
Identities Identity Provisioning
Access Control Engine (PDP)
Cloud Subscriber Site Cloud Provider Site
PEP Reverse Proxy PEP Web Application
PEP Enterprise Application 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 Open Data Center Alliance Usage: Identity Management Interoperability Guide Rev. 1.0
Access Control Services
The basic behaviour of (any) access control is illustrated in the following picture:
Data Tier Business Logic Tier
Interaction Tier
C-FAC1 F-FAC2 C-DAC3
DB
F-DAC4
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.
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 Management
IdMaaS Identity Management as a Service
NIST National Institute of Standards and Technology
OASIS Organization for the Advancement of Structured Information Standards ODCA Open Data Center Alliance
OpenXDAS Open Group's Distributed Auditing System PaaS Platform as a Service
PEP* Policy Enforcement Point (where the process flow is interrupter to perform authentication or access control) PDP* Policy Deccision Point (where an authentication or an access control is evaluated)
RBAC Role based Access Control SaaS Software as a Service
SAML Security Assertion Markup Language (v2.0 current during writing of this document) SPML Service Provisioning Markup Language (v2.0 current during writing of this document)
UM Usage Model
XACML eXensible Access Control Markup Language
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 Management 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
Open Data Center Alliance Usage: Identity Management Interoperability Guide Rev. 1.0
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 Management
IdMaaS Identity Management as a Service
NIST National Institute of Standards and Technology
OASIS Organization for the Advancement of Structured Information Standards ODCA Open Data Center Alliance
OpenXDAS Open Group's Distributed Auditing System PaaS Platform as a Service
PEP* Policy Enforcement Point (where the process flow is interrupter to perform authentication or access control) PDP* Policy Deccision Point (where an authentication or an access control is evaluated)
RBAC Role based Access Control SaaS Software as a Service
SAML Security Assertion Markup Language (v2.0 current during writing of this document) SPML Service Provisioning Markup Language (v2.0 current during writing of this document)
UM Usage Model
XACML 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.