Open Data Center Alliance Usage: Single Sign On Authentication REv. 1.0

Transcription

1 sm Open Data Center Alliance Usage: Single Sign On Authentication REv. 1.0

2 Table of Contents Legal Notice... 3 Executive Summary... 4 Reference Framework... 5 Applicability... 6 Related Usage Models... 6 Taxonomy... 6 Usage Scenarios... 7 Single Sign On Authentication Subscriber initiated... 7 Single Sign On Authentication Provider initiated... 8 Industry Call to Action... 9 References

3 Legal Notice This Open Data Center Alliance SM Usage Model: Single Sign On Authentication 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,

4 sm Open Data Center Alliance Usage: Single Sign On Authentication REV. 1.o Executive Summary Many organizations that are considering purchasing cloud-based services already have fully integrated identity management (IdM) systems. These systems are normally widely connected throughout the internal systems of an organization and allow single sign on (SSO) connectivity to enterprise systems. As resources in the cloud become more prevalent in the enterprise users will expect this single sign on capability to be maintained. SSO represents a specific model of identity federation and is described here to permit organizations to undertake the initial elements of identity federation when purchasing cloud services. This usage model will identify recommended elements of a SSO transaction between the cloud subscriber and the cloud provider, as well as demonstrating the recommended mechanisms for communicating during a SSO transaction. This document serves a variety of audiences. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining end-user relevant and open standards. Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) standards will be used throughout this usage model. 4

5 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. This usage model covers the single sign on element of identity management. Identity and Access Management Framework Identity and Access Management Identity Lifecycle Management Identity and Authentication Management Authorization and Permission Lifecycle Management Authorization and Permission Management 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 Management Policy Enforcement Point (PEP) 5

6 Applicability This usage model is applicable to Software as a Service (SaaS) and may in some models also be applicable to Platform as a Service (Paas) and Infrastructure as a Service (IaaS). The usage model should be applied in the case of Silver, Gold, and Platinum levels of security, as defined in the ODCA Provider Assurance Usage Model 1, being required. Correlation of applicability to other use models can be found in the ODCA Identity Management Interoperability Guide 2. Related Usage Models This usage model is referenced from the ODCA Identity Management Interoperability Guide 2. This guide demonstrates the relationships between the different elements of identity management. The ODCA Single Sign On Usage Model should be read in conjunction with the interoperability guide. General requirements for the levels of security required in cloud solutions can be found in the ODCA Provider Assurance Usage Model 1. Taxonomy Actor Name Cloud Subscriber Cloud Subscriber User Cloud Subscriber Administrator Cloud Provider Identity Provider Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. A user of a cloud subscriber organization who consumes the cloud service provided by the cloud provider as an end user. For example, an organization s user who is using a SaaS service the organization subscribes to would be a cloud subscriber s user. An administrator type of user of a cloud subscriber organization that performs (cloud) system related administration tasks for the cloudcubscriber organization. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the internet. An entity that is responsible for establishing and maintaining the digital identity associated with a person, organization, or (in some cases) a software program. [e.g., National Strategy for Trusted Identities in Cyberspace (NSTIC)] InteropGuide_Rev1.0_final.pdf 6

7 Usage scenarios Single Sign On Authentication Subscriber Initiated In this usage model the cloud subscriber user is already logged onto the corporate network using the credentials required by the cloud provider application. Access to the cloudprovider application is through a web page hosted on a cloud subscriber internal web site. Actors: cloud subscriber, cloud provider, cloud subscriber user Goal: The cloud subscriber user requires access to a cloud provider application without the need to re-authenticate to the application. Assumptions: The following assumptions are made regarding authentication: Assumption 1: The identity provider will be the cloud subscriber. Assumption 2: The service provider will be the cloud provider. Assumption 3: The cloud subscriber user identity has been provisioned into the cloud provider s system. Assumption 4: A prior trust relationship has been created between the cloud provider and the identity management system of the cloud subscriber. Assumption 5: The cloud subscriber user has successfully authenticated to the cloud subscriber identity management system. Assumption 6: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario: A cloud subscriber user is able to authenticate to a cloud provider s system or application without the need to re-authenticate. Steps: 1. The cloud subscriber user accesses the cloud provider resource through a cloud subscriber based web page. 2. The cloud subscriber web page passes the digitally signed SAML authentication assertion as part of the transaction. 3. The cloud provider application verifies the level of access for the cloud subscriber user. 4. The cloud provider grants appropriate level of access to the cloud subscriber user. Failure Condition 1: The cloud provider s system does not receive the SAML authentication assertion of the cloud subscriber user. Failure Handling 1: The cloud provider s system should provide an appropriate error message back to the cloud subscriber user. 7

8 Single Sign On Authentication Provider Initiated In this usage scenario the cloud subscriber user connects to the cloud provider application directly through a web page hosted on the cloud provider web site. Actors: cloud subscriber, cloud provider, cloud subscriber user Goal: The cloud subscriber connects first to the application of a cloud provider and goes through a standard web based authentication and is allowed access to the application. Authentication information is only stored in the cloud subscriber identity management system. Assumptions: The following assumptions are made regarding authentication: Assumption 1: The identity provider will be the cloud subscriber. Assumption 2: The service provider will be the cloud provider. Assumption 3: The cloud subscriber user identity has been provisioned into the cloud provider s system. Assumption 4: A prior trust relationship has been created between the cloudprovider and the identity management system of the cloud subscriber. Assumption 5: The cloud subscriber has a web based authentication system available to the cloud subscriber user. Assumption 6: The interactions defined below are to be carried out in a timely manner. The maximum delay in transaction time should be defined in the contract. Success Scenario: A cloud subscriber user is able to authenticate to a cloud providers system or application using existing enterprise authentication information. Steps: 1. The cloud subscriber user accesses a cloud-based resource through the Internet with no associated SAML authentication assertion. 2. The cloud provider forwards the cloud subscriber user to a web page based on the cloud subscriber website that permits the cloud subscriber user to enter enterprise authentication information. 3. The cloud subscriber s identity management system validates the cloud subscriber user. 4. The cloud subscriber s identity management system forwards a SAML authentication assertion to the cloud provider. 5. The cloud provider application verifies the level of access for the cloud subscriber user. 6. The cloud provider grants appropriate level of access to the cloud subscriber user. Failure Condition 1: The cloud provider s system does not receive the SAML authentication assertion of the cloud subscriber user. Failure Handling 1: The cloud provider s system should provide an appropriate error message back to the cloud subscriber user. 8

9 Industry Call to Action The following further actions are required: The ODCA requests providers of identity management systems for the enterprise and cloud to produce reference models and proof-ofconcept implementations that will show compliance to this requirement. References OASIS Service Provisioning Markup Language (SPML) Version 2 4 OASIS Security Assertion Markup Language (SAML) Version 2 5 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