Transcription
Collaboration Technology Support Center – Microsoft – Collaboration BriefSeptember 2007Unleash the Power of Single Sign-On withMicrosoft and SAPWhite PaperAuthorsTilo Boettcher, Microsoft Corp (tiloboet@microsoft.com)Juergen Daiberl, Microsoft Corp (jdaiberl@microsoft.com)André Fischer, SAP AG (andre.fischer@sap.com)Lei Liu, Spell GmbH (lei.liu@spell‐gmbh.com)SummarySingle Sign‐On (SSO) becomes more and more crucial for today’s complex IT landscape driven bythe ever‐increasing request to integrate existing systems to support cross‐organizationalbusiness processes. In context of Identity Management, it means to bridge differentauthentication models used by these systems, which results in high administrative overhead aswell as low usability. To enforce a consistent authentication policy throughout the enterpriseand to offer simplified and homogeneous logon experience for enterprise users, Microsoft andSAP provide a set of technologies to unleash the power of SSO for enterprises. In this whitepaper, we review the mainstream enabling technologies for authentication as well as SingleSign‐On within the Microsoft/SAP context and outline their usage in some typical scenarios onthe enterprise level.Applies to SAP NetWeaver Application ServerSAP NetWeaver PortalSAP GUIMicrosoft .NETMicrosoft Office SharePoint ServerKeywordsSingle Sign‐On, Authentication, Federation, SAML, SAP Logon Ticket, SAP Assertion Ticket,Kerberos, CardSpaceLevel of difficultyTechnical consultants, Architects, Developers, IT Managers
CopyrightThis document is provided to you by SAP and Microsoft to drive interoperability. Please check the .NETinteroperability area in the SAP Developer Network (http://sdn.sap.com) or the SAP interoperability section in theMicrosoft and SAP Customer Information Center (http://www.microsoft.com/isv/sap) for any updates or furtherinformation.This document is a common publication by SAP and Microsoft (“Co‐Editors”) who have both contributed to its contentand retain respective rights therein.The information contained in this document represents the current view of the Co‐Editors on the issues discussed asof the date of publication. Because the Co‐Editors must respond to changing market conditions, it should not beinterpreted to be a commitment on the part of the Co‐Editors, and the Co‐Editors cannot guarantee the accuracy ofany information presented after the date of publication.This document is for informational purposes only. NEITHER OF THE CO‐EDITORS MAKES ANY WARRANTIES, EXPRESS,IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights undercopyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, ortransmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for anypurpose, without the express written permission of the Co‐Editors.Either Co‐Editor may have patents, patent applications, trademarks, copyrights, or other intellectual property rightscovering subject matter in this document. Except as expressly provided in any written license agreement from therespective Co‐Editor(s), the furnishing of this document does not give you any license to these patents, trademarks,copyrights, or other intellectual property. 2007 Microsoft Corporation. All rights reserved. 2007 SAP AG. All rights reserved.Microsoft, Active Directory, ASP.NET, CardSpace, Internet Information Server (IIS), Microsoft .NET Framework,Microsoft Office, SharePoint, Windows, Windows Communication Foundation (WCF), Windows Server, and otherMicrosoft products and services mentioned herein as well as their respective logos are trademarks or registeredtrademarks of Microsoft Corporation.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned hereinas well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several othercountries all over the world. All other product and service names mentioned are the trademarks of their respectivecompanies. Data contained in this document serves informational purposes only. National product specifications mayvary.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Table of ContentsIntroduction.2The Anatomy of Single Sign‐On .2Enabling Technologies for SSO .5Authentication Infrastructure.5Authentication on Windows Platform . 5Authentication on SAP Platform . 5Pluggable Authentication Services (PAS). 6Java Authentication and Authorization Service (JAAS). 7Single Sign‐On for Web‐Based Scenarios on SAP .9User Authentication . 9User ID/Password based Authentication . 9HTTP Header Variable Authentication . 12X.509 Client Certificate Authentication. 13Integrated Windows Authentication. 15Authentication based on SAP Logon Ticket. 17Authentication based on SAML Token . 19User Mapping . 21Single Sign‐On for SAP GUI for Windows. 22Secure Network Communication (SNC) . 22SAP Runs on Windows Platform. 22SAP Runs on a non‐Windows Platform. 22Summary . 23SSO Usage Scenarios .25SSO from Windows‐based Workstations to SAP using SAP Frontends . 25SSO from Windows‐based Applications to SAP . 26SSO from SAP Applications to Microsoft . 27Conclusion & Outlook .30Conclusion . 30Outlook . 31Federation with Windows Platform . 31Table of Figures .33Page 1
IntroductionToday’s fast paced and ever changing enterprise enables the enforcement of a consistentauthentication policy throughout the enterprise. The abilities to integrate with existing systems,to bridge different authentication models, and to offer simplified and homogeneous logonmechanism on desired client platform(s) are the primary goals of such a consistentauthentication policy. It is to envision that the further convergence of enterprise systems, e.g.CRM, ERP, etc, towards integrated enterprise‐level business applications demands for moreconvenient security model to enable user authentication. As an efficient way to facilitatesimplified user authentication in enterprise, Single Sign‐On (SSO) refers the mechanisms forenterprise users to authenticate themselves by a single authentication authority once and thengain access to other protected resources without re‐authenticating.SSO is advantageous for both administrators and enterprise users. A user only needs to dealwith a single set of credentials during the daily work, which increases indirectly a user’sproductivity. For an enterprise administrator, SSO means that all the authentication relatedinformation are centralized on a single security service provider, which enforces consistentauthentication policy throughout the complete identity management process within theenterprise, including a centralized user repository and a simplified central user management.In this whitepaper, we will review SSO as a security model and discuss the general securitymodel for SSO in an enterprise environment. Furthermore, we will examine the existing SSOapproaches in the SAP/Microsoft context, i.e. how to utilize SSO to access SAP systems fromMicrosoft platform as well as to access Windows‐based applications from inside of SAP.Therefore, the remainder of this whitepaper is organized as follows: the introduction sectiondiscusses the basic concept of SSO. The state‐of‐the‐art section reviews the existing approachesenabling SSO in the SAP/Microsoft context while the “SSO Usage Scenario” section shows sometypical SSO scenarios from the real world. The last section concludes the whitepaper andprovides an outlook concerning the further development of SSO.The Anatomy of Single Sign‐OnHistorically, a traditional enterprise computing infrastructure has been assembled from varioustechnical systems that act as independent security domains from each other. Each securitydomain comprises its own security model for authentication. Enterprise users have toauthenticate themselves independently to the domains with which they wish to interact. Thislegacy security models lead to possible vulnerabilities in enterprise, since enterprise users areforced to deal with a large number of passwords. In this case, users tend to choose simple, easy‐to‐remember but also easy‐to‐guess passwords. For enterprise administrators, it means highadministration cost due to high administration efforts for maintaining user data in various userrepositories.Overall, the goal of applying Single Sign‐On to the enterprise is to reduce the overalladministration effort and to enhance the usability of enterprise‐level applications while meetingthe same security requirements as the conventional authentication mechanisms have. Figure 1depicts a typical implementation of Single Sign‐On with all the essential components in anenterprise, including users, authentication authority, resource servers, directory service as wellas security token. Comparing to the legacy security models mentioned above, SSO isPage 2
characterized by the trust‐relationship between authentication authority and resource servers,as illustrated in Figure 1. The trust‐relationship specifies explicitly that the resource servers trustin the claims provided by the authentication server. In other words, after successful initialauthentication, any claims asserted by a trusted authentication server are handled as credible byall the related resource servers. In this way, the authentication authority along with all theresource servers establishes a single security domain, within which all the enterprise resourcesare protected by the single authentication authority. A backend directory service provides theauthentication authority with appropriate authentication information via some accessingprotocol, e.g. LDAP.Figure 1: General Security Model for Single Sign‐OnAn essential component in an SSO‐enabled infrastructure is security token – any digital identitythat has been verified by an authentication authority is represented as some kind of securitytoken in the network. Technically, a security token is just some bytes that express some part oftotal information about an identity, e.g. name, e‐mail, department, company, etc. All theseinformation are saved as claims in the security token. Constructing such a security token with acollection of claims depends on the usage scenarios – some simple token may only have a singleclaim containing the username, such as the HTTP header variable containing user IDs forauthentication; some other token may contain complex claim sets according to particularfunctional requirements, such as an SAP Assertion Ticket, a X.509 certificate or a SAML token. Inthis way, security tokens are not focused on authenticating an identity anymore; instead, theycan carry some useful information about an identity that can be of interest for the targetresource servers. Table 1 summarizes the various components within an SSO infrastructure andmaps each of them to sample technologies from the practice.Furthermore, it is important to figure out that SSO is only a specific form of “authentication” andpart of the enterprise‐wide identity management infrastructure. Usually, the concept of SSO isconfusedly thought as an “access control”‐related technology. Comparing to authorization, SSOonly defines the process to assure that the current requesting user’s identity is authentic.Although a security token may contains claims necessary for access control, it is not the task ofSSO to decide whether a particular user can be granted access to particular resource on theserver. Each resource server should have its own authorization mechanism to control access toits resources.Page 3
ComponentRoleAuthenticationauthorityEnterprise users authenticate themselves initially to anauthentication authority. For this purpose, users nation, or result of a cryptographic operationinvolving their credentials, i.e. hash‐value of thepassword, to the authentication authority. It validatesthe credentials submitted. If the credentials are valid,the user’s identity is considered as “authentic” and theauthentication authority issues a security token back tothe user.Directory service The directory service stores either a copy of usercredentials or the result of some cryptographicoperation based on the credentials. The authenticationauthority access the directory service via somepredefined protocols, such as LDAP.Resource serverThe resource server provides services to the end users.In general, a resource server does not feature its ownauthentication mechanism; instead, it uses the securitytoken issued by the authentication authority as a proofof authentication in subsequent access.Security tokenTo prove that a user has been authenticated, theauthentication authority issues a cryptographic securitytoken to the user. These issued security token are usedin the subsequent access to simplify the authenticationprocess at the resource servers.Table 1: Overview of Technical Components in an SSO InfrastructurePage 4Sample TechnologiesSAP NetWeaver AS Javawith User managementEngine (UME) or OfficeSharePoint Server Directory,SAP NetWeaver AS ABAPor a simple ASP .NETapplicationSAPLogonTicket,Kerberos Ticket, X.509Certificate, or SAML token
Enabling Technologies for SSOIn this section, we will review various enabling technologies to support SSO in Microsoft/SAPcontext. In the following, we will review at first the authentication infrastructure on bothplatforms. After this, we will go on reviewing various enabling technologies for SSO and checkinghow they can work together to access backend systems on Microsoft/SAP platforms.Authentication InfrastructureBoth Microsoft and SAP provide a set of authentication mechanisms in their product line. Basedon functional‐ and non‐functional requirements, on usage scenarios, and existing securityinfrastructure, these authentication methods provide support to ensure different security levelfor user authentication.Authentication on Windows PlatformAs the major application server on the Windows platform, Internet Information Server (IIS)provides a set of build‐in support for user authentication: Anonymous Authentication, BasicAuthentication, Digest Authentication, Certificate Authentication, Integrated WindowsAuthentication as well as .NET Passport Authentication 1 . Furthermore, for ASP.NET applicationssuch as Microsoft Office SharePoint Server (MOSS) running on IIS, ASP.NET also allows to involveexternal mechanisms for user authentication, such as to authenticate users via external LDAPserver. In this way, one can delegate authentication to an external mechanism. Similarly,Windows Communication Foundation (WCF) provides a “plug‐in” mechanism to enable externaluser authentication. Table 2 provides some further reading about authentication on Windowsplatform.Summary: Authentication on Windows mspx?mfr 8.aspx)MSDN Magazine – Security Briefs: Security in Windows Communication s/06/08/securitybriefs/default.aspx)MSDN: WCF – Custom Credentials and Credential ary/ms734697.aspx)Table 2: Overview ‐ Authentication on WindowsAuthentication on SAP PlatformSAP provides also a set of possible authentication methods on the SAP platform. Figure 2illustrates the general architecture of SAP NetWeaver Application Server. A SAP NetWeaver ASexposes functionalities through two interfaces: an interface exposed by the ABAP Engine toenable the classical access through SAP GUI and a second Web‐based interface exposed by theInternet Communication Manager (ICM). Outwards, ICM establishes a Web‐based connection bysupporting various Internet protocols like HTTP, HTTPs, SOAP as well as SMTP. Internally, theICM dispatches incoming requests to various dispatchers of the J2EE Engine or the ABAP Engine.1More information about various authentication mechanisms on IIS and how to configure them isavailable under: 9103‐9808baa00157.mspx?mfr truePage 5
Based on the different ways in which an SAP NetWeaver AS is accessed – either Web‐based orthrough SAP GUI, there are different mechanisms that can be applied to enable SSO.Figure 2: SAP NetWeaver Application Server Architecture 2Both ABAP Engine and J2EE Engine support a set of internal as well as external authenticationmethods. As standard authentication methods on SAP platform, both of them support userauthentication on the base of User ID/Password, SAP Logon Tickets, and X.509 Client Certificate.Additionally, both of them also provide programming APIs to include external authenticationmechanisms into existing security infrastructure on the SAP platform.Pluggable Authentication Services (PAS)As an approach to enable external authentication in combination with the SAP InternetTransaction Server (ITS), PAS provides a programming API interface allowing developers to plugin third‐party authentication into existing SAP landscapes. Figure 3 illustrates the concept of PASwith an external ITS. Users submit their credentials directly to a Web server with an enabled ITS‐WGate. Now, the external user authentication can be performed on either of the ITS’scomponent – AGate or WGate via PAS. The PAS informs the ITS about the authentication result.If the credentials submitted by the user are valid, the ITS issues an SAP Logon Ticket to the userfor subsequent authentication.With PAS, it is possible to integrate existing security infrastructure into SAP systems. TheWGate‐Variant supports user authentication based on NTLM, X.509 Client Certificate as well asany mechanisms that can set a User ID as an HTTP header variable. The AGate‐Variant supportsany mechanisms that can authenticate User ID/Password, for instance against a domaincontroller or an external LDAP server. However, PAS requires the availability of an external ITSfor operation. Since an external ITS is only available on SAP Web Application Server 6.20 (orlower) and meanwhile ITS becomes an integral part of SAP NW AS, PAS interface is notsupported any more by the SAP application server from SAP NW 2004 and up. Table 3summarizes PAS and provides further reading for it.2Adapted from SAP Library:http://help.sap.com/saphelp /frameset.htmPage 6
Figure 3: External Authentication with Pluggable Authentication Service (PAS)Summary: Pluggable Authentication Service (PAS)OverviewPAS in combination with an external ITS allows integrating externalauthentication mechanisms into existing SAP landscape.AvailabilityOnly supported by SAP Web Application Server ABAP 6.20 or lowerSSOPAS provides a possibility to perform initial user authenticationSAP Library: Pluggable Authentication Service for External Authentication le 3: Pluggable Authentication Service in a NutshellJava Authentication and Authorization Service (JAAS)Defined as part of the Java SE Development Kit (JDK) standard 3 , JAAS contains a set of APIs thatallows Java applications performing authentication and authorization upon users in a pluggablefashion. Similarly to the PAS interface for SAP ITS, integrating JAAS into SAP NetWeaver AS JavaEngine allows Java applications to be independent from the underlying authenticationmechanisms – new or updated authentication mechanisms can be plugged in to existingapplications without any modification on them.The authentication functionality is organized in a “Login Module”, which implements a set ofpredefined methods, such as initialize(), login(), commit() and abort() 4 . On SAP NW AS JavaEngine, various login modules are bundles into “login module stacks”, which can contain one ormore login modules with different JAAS control flags attached to each module. The JAAS controlflags defines the priority of each login module in the stack and may vary from “required”,“requisite”, “sufficient” to “optional”. The overall authentication result of the complete loginmodule stack depends not only on the authentication result of a particular authenticationmodule in the stack, but also on the priority of particular module’s control flag. To performauthentication at runtime, all the login modules in the stack are processed. Therefore, a“failure” in a “required” login module leads to a “failure” of the overall login module stack atonce, while a “failure” in an “optional” login module may not cause the overall login process to3JAAS is originally introduced as an optional package for J2SE 1.3. Since J2SE 1.4, JAAS has 4Please refer to the technical documentation on Sun Developer Network for more information about howto implement JAAS Login ecurity/jaas/JAASRefGuide.html .Page 7
fail, if the credentials submitted can pass another login module in the stack with control flag ofhigher priority, e.g. “requisite” 5 .Meanwhile, SAP provides a number of predefined login modules for J2EE Engine. Next to somestandard login modules such as BasicPasswordLoginModule, or EvaluateTicketLoginModule,there are also login modules for external authentication, such as DigestLoginModule orSPNegoLoginModule. The Simple and Protected GSS API Negotiation Mechanism (SPNego)enables the SAP Java NetWeaver AS to negotiate Kerberos authentication with Web clients, suchas Web browsers, thus allowing Windows Integrated Authentication.Another noteworthy login module is the CreateTicketLoginModule, which can be used to issueSAP Logon Tickets after successful authentication. With this login module, the J2EE Engine canissue SAP Logon Tickets for other SAP Systems, such as for an ABAP Engine. In other words, theJ2EE Engine can be used as an “authentication authority” to any ABAP‐based applications, if anexternal authentication method that is not supported by the ABAP Engine has to be used in thescenario. Actually, this is also a typical scenario for SSO with the J2EE Engine as theauthentication authority for the initial authentication. Table 4 provides a summary of JAAS.Summary: Java Authentication and Authorization Server (JAAS)OverviewJAAS is a JDK standard for integrating external authentication methods intoexisting Java application in a “pluggable” fashion. SAP NW AS Java Engineimplements/extends this concept to allow using existing authenticationinfrastructure for initial authentication.AvailabilitySAP NetWeaver Application Server Java Engine (as well as SAP Web ApplicationServer Java)SSOJAAS provides a possibility to perform initial user authentication by usingexternal authentication mechanisms.Sun Developer Network: Java Authentication and Authorization Service (JAAS)FurtherOverview nformationSun Developer Network: Java Authentication and Authorization Service (JAAS)Reference curity/jaas/JAASRefGuide.html)Sun Developer Network: Java Authentication and Authorization Service (JAAS)LoginModule Developer’s curity/jaas/JAASLMDevGuide.html)SDN: Authentication for Web Application Users on the J2EE Engine(http://help.sap.com/saphelp /frameset.htm)SDN: Authentication on J2EE Engine(http://help.sap.com/saphelp 4/frameset.htm)Table 4: Java Authentication and Authorization Service (JAAS) in a Nutshell5SDN provides detailed description about the various control flags. You can find a sample there to seehow the overall authentication result can be calculated from the results of each login module in the stack:http://help.sap.com/saphelp 4/frameset.htm.Page 8
Single Sign‐On for Web‐Based Scenarios on SAPIn a Web‐based scenario within SAP context, SAP NetWeaver AS is always somewhere involved –either as an authentication authority or as a resource server. To accelerate SSO in suchscenarios, SAP NetWeaver AS provides a set of mechanisms for authenticating users. Among allthese mechanisms, some of them are only available on SAP NW AS Java while some other onesare available on both SAP NW AS Java as well as SAP NW AS ABAP; some ones are only in effectfor initial authentication while some other ones can be used for both initial authentication aswell as SSO after that. In the following, we will review all the mechanisms one after another andtry to provide a clear picture about the SSO‐related technologies discussed in this section withinthe SAP/Microsoft context.User AuthenticationUser authentication aims to ensure a user’s identity before granting that user further access toresources. In order to check a user’s identity, that user has to provide his credentials, forinstance in form of user ID/password or an X.509 Ticket, to the authentication authority. Theauthentication authority verifies the submitted identity and, if applicable, grant that user accessto the backend system, including SAP and Non‐SAP systems. Both Microsoft and SAP provide aset of authentication methods in their product line, as described in this following section.User ID/Password based AuthenticationUsing credential sets consisting of user ID and password is an often‐used and simplest approachfor authenticating users. Generally, a user submits his user credentials ‐ user ID and password ‐via browser or other client applications to the destination application to authenticate himself.User credentials are transferred e.g. via HTTP(s) protocols to the application server. At theserver side, the application server compares the values submitted by the user with the valuesstored in the database or in the directory server. To enhance the usability and significance levelof this approach in practice, passwords are often encrypted by building their hash values beforethey are saved to the database. The irreversible nature of hash algorithms ensures that only theuser knows the password. Even administrators with access to the database cannot retrieve userpasswords from hash value stored there.Both Microsoft and SAP support User ID/Password based authentication in their Web‐basedproducts. In practice, several authentication schemes support this authentication method: Basic Au
SAP provide a set of technologies to unleash the power of SSO for enterprises. In this white paper, we review the mainstream enabling technologies for authentication as well as Single Sign‐On within the Microsoft/SAP context and outline their
