user authentication and single sign on.pdf

User Authentication and Single Sign-OnPDF download from SAP Help Portal:http://help.sap.com/saphelp_nw74/helpdata/en/e5/4344b6d24a05408ca4faa94554e851/content.htm

Created on May 21, 2015

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

NoteThis PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing subtopics.

2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SEand its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided bySAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not beliable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the expresswarranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and otherSAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and othercountries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 119

Table of content1 User Authentication and Single Sign-On2 SAP Single Sign-On3 Authentication Concepts3.1 Authentication for SAP GUI3.1.1 User ID and Password Authentication for SAP GUI3.1.2 Client Certificate Logon for SAP GUI3.1.3 Kerberos for SAP GUI Authentication3.1.4 Windows NT LAN Manager (NTLM) Authentication3.1.5 SNC with SAP Single Sign-On Secure Login3.2 Authentication for Web-Based Access3.2.1 Basic Authentication (User ID and Password)3.2.2 Logon Tickets3.2.3 X.509 Client Certificates3.2.4 SAML 1.x3.2.5 SAML 2.03.2.5.1 SSO with SAML 2.03.2.5.2 SLO with SAML 2.03.2.5.3 Identity Federation3.2.5.4 Common Domain and Identity Provider Discovery3.2.6 Kerberos Authentication3.2.7 Header Variables3.2.8 OAuth 2.0 Introduction and Concept3.2.8.1 OAuth 2.0 Server with AS ABAP3.2.8.2 OAuth 2.0 Scopes3.2.8.3 OData3.2.8.4 Resource3.2.8.5 Resource Owner in OAuth 2.03.2.8.6 OAuth 2.0 Token Context Revocation3.2.8.7 OAuth 2.0 Flows Supported by SAP3.2.8.7.1 SAML 2.0 Bearer Assertion Flow for OAuth 2.03.2.8.7.1.1 Business Example for Accessing Resources with OAuth 2.0 Using a SAML Bearer Assertion3.2.8.7.2 Authorization Code Flow for OAuth 2.03.2.8.7.2.1 Business Example for Accessing Resources with OAuth 2.0 Using an Authorization Code3.3 Authentication for Web Services3.3.1 Authentication at HTTP Transport Level3.3.2 Authentication at SOAP Message Level3.3.2.1 SAML Token Profile3.3.2.2 WS Security UsernameToken3.4 Authentication for Communication between Systems3.4.1 Authentication Assertion Tickets4 Authentication Infrastructure4.1 AS ABAP Authentication Infrastructure4.1.1 Profile Parameters for Logon and Password (Login Parameters)4.1.2 Secure Network Communications (SNC)4.1.3 System Logon4.1.3.1 Security Aspects for BSP4.1.3.2 Security Considerations for Web Dynpro Applications4.1.4 Maintaining Logon Procedures4.1.4.1 Logon Checks: Overview4.1.4.2 Standard Logon Order4.1.4.3 Alternative Logon Order4.1.4.4 Logon Ticket Cache4.1.4.5 Logon Using Service Data4.1.4.6 Logon with SSL Certificate4.1.4.7 Logon Using Basic Authentication.4.1.4.8 Logon via SAML4.1.4.9 Specifying the Client4.1.4.10 Determining the Logon Language4.1.4.11 Inserting an HTTP Request Handler4.1.5 Activating HTTP Security Session Management on AS ABAP


Page 2 of 119

4.1.6 Disabling the Display of Last Logon for HTTP Logons4.1.7 OAuth 2.0 Implementation with AS ABAP4.1.7.1 Authorization Server of the OAuth 2.0 Implementation4.1.7.1.1 Token Endpoint for OAuth 2.04.1.7.1.2 Authorization Endpoint for OAuth 2.04.1.7.2 Resource Server for OAuth 2.04.2 AS Java Authentication Infrastructure4.2.1 Declarative and Programmatic Authentication4.2.2 Login Modules4.2.2.1 Managing Login Modules4.2.2.2 Creating the Configuration File for Login Modules4.2.3 HTTP Sessions and Security Sessions on the AS Java4.2.4 Policy Configurations and Authentication Stacks4.2.4.1 Creating Authentication Stack Templates for Policy Configurations4.2.4.2 Editing the Authentication Policy of AS Java Components4.2.4.3 Configuring Authentication Properties4.2.4.4 Setting a Logon Policy for a Policy Configuration4.2.5 User Mapping and the AS Java4.2.6 Application Server Java as a SAML 2.0 Provider4.2.7 Kerberos and SAP NetWeaver AS for Java5 Integration in Single Sign-On (SSO) Environments5.1 Single Sign-On for the SAP GUI5.1.1 Logon and Password Security for SAP GUI5.1.1.1 Password Rules5.1.1.2 List of Customizing Switches for Generated Passwords5.1.1.3 Logging Off Inactive Users5.1.2 Single Sign-On for SAP Shortcuts5.1.2.1 Integrating SAP GUI for Windows in a Portal iView5.1.3 Single Sign-On with Client Certificates5.1.3.1 Preparing the Central Instance5.1.3.2 Activating SSO on the SAP Logon5.1.4 Single Sign-On with Microsoft Kerberos SSP5.1.4.1 Preparing the Primary Application Server Instance5.1.4.2 Configuring the SAP Front End5.1.4.3 Configuring the SAP Logon5.1.4.4 Mapping Windows Users to SAP Users for Kerberos SSO5.1.5 Single Sign-On with Microsoft NT LAN Manager SSP5.1.5.1 Starting the Windows LM Security Support Provider Service5.1.5.2 Configuring the Application Server5.1.5.3 Configuring SAP GUI and SAP Logon for Single Sign-On5.1.5.4 Mapping Windows Users to SAP Users for NTLM SSO5.2 Single Sign-On for Web-Based Access5.2.1 Using User ID and Password Authentication5.2.1.1 Logon Using Basic Authentication.5.2.1.2 Logon Using User ID and Password on the AS Java5.2.1.2.1 Configuring User Mapping with User ID and Password on an AS Java5.2.1.3 Using Rules for User Mapping in Basic Password Login Module5.2.2 Using Logon Tickets5.2.2.1 Using Logon Tickets with AS ABAP5.2.2.1.1 Configuring the AS ABAP for Issuing Tickets for Logon5.2.2.1.2 Configuring AS ABAP to Accept Logon Tickets5.2.2.1.2.1 Accepting Logon Tickets Issued by Another AS ABAP5.2.2.1.2.2 Accepting Logon Tickets Issued by the AS Java5.2.2.2 Using Logon Tickets with AS Java5.2.2.2.1 Configuring the AS Java to Issue Logon Tickets5.2.2.2.1.1 Specifying the Client to Use for Logon Tickets5.2.2.2.1.2 Replacing the Key Pair to Use for Logon Tickets5.2.2.2.2 Configuring the AS Java to Accept Logon Tickets5.2.2.2.2.1 Checking or Updating the Certificates of Trusted Systems5.2.2.2.3 Testing the Use of Logon Tickets5.2.2.2.4 Sample Login Module Stacks for Using Logon Tickets5.2.2.2.5 Configuring the Validity Period of Logon Tickets


Page 3 of 119

5.2.3 Using X.509 Client Certificates5.2.3.1 Using X.509 Client Certificates on the AS ABAP5.2.3.1.1 Configuring the AS ABAP to Use X.509 Client Certificates5.2.3.1.2 Rule-Based Certificate Mapping5.2.3.1.2.1 Managing Rules for Certificate Mapping5.2.3.1.2.1.1 Checking Certificates for Rule Coverage5.2.3.1.2.1.2 Creating Rules for Certificate Mapping5.2.3.1.2.1.3 Creating Explicit Mappings for Certificates5.2.3.1.2.2 Migrating to Rule-Based Certificate Mapping5.2.3.1.3 Mapping X.509 Certificates in Table USREXTID5.2.3.1.4 Assigning Users an Existing Certificate for Single Sign-On with SSL5.2.3.2 Using X.509 Client Certificates on the AS Java5.2.3.2.1 Configuring the Use of Client Certificates for Authentication5.2.3.2.2 Modifying Client Certificate Authentication Options5.2.3.2.2.1 Using Stored Certificate Mappings5.2.3.2.2.1.1 Maintaining the User's Certificate Information5.2.3.2.2.1.2 Maintaining Certificate Mappings Automatically5.2.3.2.2.2 Using Rules Based on Client Certificate Subject Names5.2.3.2.2.3 Using Rules Based on Client Certificate V3 Extensions5.2.3.2.2.4 Defining Rules for Filtering Client Certificates5.2.3.2.2.5 Using Rules for User Mapping in Client Certificate Login Module5.2.3.2.3 Using Client Certificates via an Intermediary Server5.2.3.2.4 Enabling Certificate Revocation5.2.3.2.4.1 How the Certificate Check Revocation Service Works5.2.3.2.4.2 Modifying Additional Settings5.2.3.2.4.3 Checking Certificates Manually5.2.3.2.4.4 Removing or Updating CRL Cache Entries5.2.4 Using SAML Browser Artifacts


Page 4 of 119

1 User Authentication and Single Sign-On

UseUser authentication and Single Sign-On (SSO) is an element of your security policies that you can use to protect access to your system infrastructure by securelyestablishing and propagating the identity of a sender of an access request.

User authentication includes the process of securely establishing the identity of a user as a client requesting access to a server system.SSO complements user authentication and includes the process of authenticating an access request once and transparently propagating the identity of analready authenticated user for access to multiple back-end systems.

You can use authentication and SSO to enable secure points of access to your systems in open environments, such as the Internet.

IntegrationUser authentication and SSO is closely related to the following security functions in SAP NetWeaver:

Identity Management : Functions that support access authorization decisions by providing user authorization information.Network and Transport Layer Security : Functions that support the security aspects in transporting authentication credentials across systems.Digital Signatures and Encryption : Functions that support the security of stored credentials and user information.

FeaturesSAP NetWeaver supports a number of mechanisms to enable user authentication and integration in SSO. SAP NetWeaver Application Server for Java and ASABAP provide the underlying technology for authenticating users.For more information about the conceptual, administrative, and development aspects relevant to user authentication and SSO in SAP NetWeaver, see thefollowing sections:

Authentication ConceptsInformation about the security aspects that apply when using the authentication mechanisms that are supported by SAP NetWeaver.Authentication InfrastructureInformation about the underlying ABAP and Java technology stack infrastructure to support the authentication and SSO in SAP NetWeaver.Integration in Single Sign-On (SSO) EnvironmentsInformation about configuring the use of mechanisms for authenticating user access, as well as, their integration in SSO environments.Developing Authentication EnhancementsInformation about enhancing the standard SAP NetWeaver authentication and SSO functions with custom development. You can also find information aboutdeveloping custom authentication enhancements for SSO to non-SAP systems.

2 SAP Single Sign-OnFor Single Sign-On (SSO) scenarios, we offer the SAP Single Sign-On product (SAP SSO). SAP Single Sign-On centralizes and greatly simplifies the wayusers log on to systems and applications in your IT landscape. It includes mobile single sign-on with the SAP Authenticator app, risk-based authentication usingaccess policies, or two-factor authentication.Seamlessly integrated into your existing authentication processes, SAP Single Sign-On offers enhanced security through state-of-the-art technology. But that is notthe only benefit SAP Single Sign-On has to offer. Reduce your operating costs by eliminating password-related helpdesk calls, and improve user productivity -more than enough reasons to start thinking about implementing a single sign-on solution in your company.For more information, see SAP Single Sign-On.Secure Login provides strong encryption, secure communication, and single sign-on between a wide variety of SAP components. For more information, see thecentral SAP Note 1912175 .

SAP GUI and SAP NetWeaver platform with Secure Network Communications (SNC)HTML-based user interfaces and SAP NetWeaver platform with Secure Socket Layer SSL (HTTPS)Third-party application servers supporting Kerberos and X.509 certificates

In a default SAP setup, users enter their SAP user name and password on the SAP GUI logon screen. SAP user names and passwords are transferred throughthe network without encryption. To secure networks, SAP provides a Secure Network Communications interface (SNC) that enables users to log on to SAPsystems without entering a user name or password. The SNC interface directs calls through the SAP Cryptographic Library to encrypt all communication betweenSAP GUI and the SAP NetWeaver application server, thus providing secure single sign-on. For more information, see the related link.In a scenario with SAML 2.0, the user is authenticated by an identity provider. SAP also offers an identity provider as part of SAP Single Sign-On. An alternativeoption is the use of an external identity provider. For more information, see the related link.

Related Informationhttp://help.sap.com/sso20SAML 2.0

3 Authentication ConceptsAuthentication is an element of information security that enables you to protect the confidentiality, integrity and availability of the information flow, supported by theinformation systems in your business operations. With the increasing use of distributed systems based on open standards and flexible information sharing withmultiple business partners, establishing the identities of communicating parties also becomes an important element in protecting your business operations.Authentication in SAP NetWeaver includes the process of establishing and verifying the identity of a person or a system component as a prerequisite for allowingthe person or system component access to a SAP NetWeaver server system.

Implementation ConsiderationsPUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 119

Implementation ConsiderationsSAP NetWeaver is a component in your system landscape that enables integrated access to use various back-end resources. Therefore, the authenticationprocess is initiated when a client system requests access to various system resources.You can use several types of client frontends to access SAP NetWeaver systems over different corresponding communication channels. The mechanisms forauthentication in SAP NetWeaver are specific to the communication channel you use to access system data.

IntegrationSAP NetWeaver enables you to use a number of user authentication mechanisms. The supported authentication mechanisms also enable you to efficientlyintegrate your SAP NetWeaver systems in Single Sign-On environments. When using Single Sign-On you can provide seamless user access to back-endsystems.For more information, see Integration in Single Sign-On Environments .In addition, the available authentication mechanisms give you the flexibility to customize user authentication policies for your security needs with minimaldevelopment effort. You can, however, use the development capabilities of SAP NetWeaver systems to develop custom enhancements of the standardauthentication mechanisms.For more information, see Developing Authentication Enhancements .

FeaturesConforming to the client-server architecture of the system, the authentication process is negotiated between the client front-end and the back-end SAP NetWeaverserver. See the topics below for an overview of the authentication functions available with each of the access channels for your SAP NetWeaver systems.

Authentication for SAP GUI AccessProvides information about the available authentication mechanisms for interactive user logon when using the SAPGUI as a front-end client.Authentication for Web Based AccessProvides information about the available authentication mechanisms for interactive user logon when using HTTP based front-end clients, for example, WebDynpro.Authentication for Web ServicesProvides information about the available mechanisms for authenticating Web Service access to SAP NetWeaver systems.Authentication for Communication between SystemsProvides information about the supported mechanisms for authenticating system specific (non-dialog) communication to and from SAP NetWeaver systems.

3.1 Authentication for SAP GUI

UseYou can use the SAP GUI authentication mechanisms to protect access to your SAP NetWeaver Application Server for ABAP (AS ABAP) systems. When usersaccess the system from this communication channel they are required to provide valid authentication credentials to authorize access.The SAP GUI enables you to authenticate user access with interactive dialog authentication functions. Alternatively, you can configure the SAP GUI toauthenticate access transparently with Single Sign-On.Implementation ConsiderationsThe SAP GUI is a front-end presentation software that enables access to applications running on the AS ABAP. To use the SAP GUI to log on to AS ABAPsystems, you have to install the SAP GUI client software on your workstation.You can launch the SAP GUI from the SAP Logon pad, which is a software component that you install on client workstations. The communication protocols thatenable the communication between the SAP GUI and the AS ABAP are SAP-specific.

IntegrationTo log on to an AS ABAP system for dialog access from the SAP GUI, users have to provide a user ID, password, and an AS ABAP client number. Alternatively,when using SSO, the SAP GUI can transparently provide the authentication credentials to the AS ABAP without user intervention. The AS ABAP system thenevaluates the provided credentials and determines whether to grant or deny access based on the set of preconfigured authentication criteria and the authorizationsassigned to the user's identity information.Therefore, the authentication process for access from an SAP GUI follows the pattern below:

On the SAP GUI client software, users provide the authentication credentials that the client sends to the AS ABAP. In addition, you can configure the SAPGUI client to use SSO.On the AS ABAP systems you configure the required user credentials and logon options that must be met for authentication to succeed and the AS ABAPsystem to authorize access.

NoteDepending on the authentication mechanism you use, the authentication credentials can become vulnerable to security attacks during the transfer fromthe SAP GUI to the AS ABAP. Therefore, we recommend that you secure communication with additional transport layer security mechanisms.

FeaturesFor more information about the available user authentication functions when using the SAP GUI and relevant implementation considerations, see the followingtopics:

User ID and Password AuthenticationInformation about authentication with user ID and password.Authentication with SAP shortcuts


Page 6 of 119

Information about authentication aspects when using SAP shortcuts. SAP shortcuts store the authentication information for SAP systems and enable you toaccess a specific AS ABAP transaction directly from your desktop.Client Certificate Logon for SAP GUIInformation about using client certificates for logon with the SAP GUI.Kerberos for SAP GUI AuthenticationInformation about using Kerberos for authentication.Windows NT LAN Manager (NTLM) Authentication with SAP GUIInformation about using Windows NTLM for authentication.SNC with SAP Single Sign-On Secure LoginInformation about integration with SAP Single Sign-On

More InformationSAP Logon in Getting Started

3.1.1 User ID and Password Authentication for SAP GUI

UseThe SAP GUI user ID and password authentication functions enable authorized users to access the AS ABAP by interactively providing a user ID and password.From the SAP Logon Pad, the user must choose the AS ABAP system, and subsequently specify the user ID, password and client system to log on to.Implementation ConsiderationsThe AS ABAP security model requires that all users log on with valid authentication credentials. With user ID and password authentication, users enter theirauthentication credentials consisting of user ID, password and an AS ABAP client system.

NoteA user must always provide both a user ID and password. When creating a user record you must specify an initial password for the user. To enable loggingon without a password you can use Single Sign-On. For more information, see Single Sign-On for SAP GUI.

User ID and password authentication enables you to enforce access control to your AS ABAP systems with an authentication mechanism that offers basic accessprotection with relatively low complexity of security configuration tasks.Using user ID and password authentication in complex system landscapes where users must log on to multiple systems, however, increases the user work loadfrom the required multiple entries of user IDs and passwords for system access.In addition, the overall security of your systems could be reduced due to the greater number of passwords that users must keep secret. Due to the requirement tokeep passwords secret, your systems can become vulnerable to system engineering attacks, where user's passwords can be guessed or deceitfully acquiredfrom a user.

RecommendationFor additional security when using user id and password authentication, we recommend that you configure rules for password complexity and require thatusers change passwords on regular time intervals. In addition, you can develop authentication extensions to store the user's credentials in a secure medium,for example smart cards. For more information, see the SAP NetWeaver Library: Function-Oriented View Security User Authentication and Single Sign-On. Developing Authentication Enhancements .

Password SecurityThe user password represents a secret form of authentication data that is used to establish the user's identity. Therefore, a critical element in protecting access toyour AS ABAP systems is maintaining the secure storage and transport of entered user passwords. After users provide their passwords, the SAP GUI useshashing algorithms to disguise the password and ensure the confidentiality and integrity of the password during its transport and storage.As of SAP NetWeaver 6.40, the password hash algorithm changed from MD5 to SHA-1. This means that more secure hash values, which are not downward-compatible and which make reverse engineering attacks more difficult, can be generated. By default, new systems generate two hash values: a downward-compatible value and a new value. You can configure the system so that only the new hash value is generated.For more information, see the information about profile parameter login/password_downwards_compatibility in Password Rules.Security ChecksAfter the AS ABAP system receives the authentication information for the user, the system performs the following checks to grant access:

1. Whether the user has a password and whether the user can log on with a password logon.2. Whether the user has been locked and is therefore not allowed to log on:

The user administrator can lock a user to prevent the user from logging on to the system. For more information, see the Lock/Unlock section of UserMaintenance Functions.The system also sets a logon lock if the user exceeds the permitted number of logon attempts (only for password-based logons).

3. Whether the user's logon data authentication credentials are correct.4. Whether the user must set a new password. Users must set new passwords in the case of an initial password, an expired password, or a password that

has been reset by the administrator. You can specify how long passwords remain valid in the system profile. By default, there is no limit on the validity ofpasswords.

If the user ID and password are correct, then the system displays the date and time of the user's last logon under System Status . With the date and time,the user can check that no suspicious logon activity has occurred. The logon date and time cannot be changed in a standard production system. The system doesnot record the logoff date and time.ConfigurationFor information about configuring the security protection mechanisms for user ID and password logon with the SAP GUI, see Logon and Password Security forSAP GUI.

3.1.2 Client Certificate Logon for SAP GUIPUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 119

3.1.2 Client Certificate Logon for SAP GUI

UseThe SAP GUI enables you to use X.509 client certificates for user logon to AS ABAP systems. You can use X.509 client certificates to enable secureauthentication instead of using the traditional user ID and password-based authentication.X.509 client certificate authentication enables you to protect access to the AS ABAP with a standards-based authentication mechanism that facilitates bulkadministration of access protection. When using client certificates for authentication, SAP GUI users are logged on to the AS ABAP transparently, without the needto interactively enter a user ID and a password for system access. In addition, the authentication credentials are protected during their transport over the networkdue to the use of public-key technology in X.509 client certificates.

PrerequisitesTo use client certificates for authentication, the AS ABAP system must be enabled to use Secure Network Communications (SNC). SNC provides aGeneric Security Services API (GSS API) to use SAP Single Sign-On or an external security product to perform the authentication between thecommunication partners, for example between the SAP GUI for Windows and the AS ABAP.To use SNC for authentication, you must use SAP Single Sign-On or an external security product certified by the SAP Partner Program.For more information, see Secure Network Communications (SNC).Users need to receive their client certificates from a Certification Authority (CA), using a Public Key Infrastructure (PKI). If you do not have an establishedPKI then you can use a Trust Center Service to obtain certificates.For more information about client certificates and PKI, see Public-Key Technology.

Security ConsiderationsThe security measures you need to take depend on the security product that you use and the type of infrastructure that it supports. For example, if the securityproduct uses public-key technology, then you need a public-key infrastructure (PKI).You need to define procedures for generating and distributing the key pairs for the users and system components and you need to make sure their private keysare stored in a secure location.Protecting Private KeysTo prevent misuse of the private keys, you must ensure that they are stored in a secure place. There are two methods of storing private keys. They are:

Hardware solutions (for example, smart cards or crypto boxes)Software solutions (for example, Personal Security Environments or PKCS#12 format)

Hardware SolutionsA solution that offers a high degree of protection for the private keys of AS ABAP users is to use smart cards that you issue to each individual user. The keys aresaved on the card, and the card is designed to never reveal the private key. Users have to authenticate themselves to their cards, either using biometrics (forexample, a fingerprint) or knowledge (for example, a PIN, password or pass phrase entry) and can then use the card to create digital signatures or to encryptdocuments. In this case, each user needs to protect his or her smart card from theft or loss.

CautionWe recommend that you do not allow your users to share smart cards or give them to others to use.

On the server, you can use a cryptographic secure storage instead of a smart card for higher performance.Software SolutionsAs an alternative, you can also use a software solution to store the private keys of users. The software solution is not as safe as the use of hardware solutions,however, it is less expensive to implement. If you use files to store the users' information and private keys, then you need to take extra care in protecting the filesfrom unauthorized access. For example, you can require that the user enters a password for each access request to the private key.

FeaturesFor more information about configuring the use of client certificates for SAP GUI authentication, see Single Sign-On with Client Certificates.

3.1.3 Kerberos for SAP GUI Authentication

UseThe authentication mechanisms available for the AS ABAP also enable you to use Kerberos for SAP GUI authentication. You can use Kerberos authentication toenable access to AS ABAP from an SAP GUI with Single Sign-On, for example, by enabling Windows Integrated Authentication.Kerberos is an authentication protocol, created by the Massachusetts Institute of Technology. You can use Kerberos to overcome the security weaknesscharacteristic of more basic authentication mechanisms such as user ID and password authentication.

PrerequisitesTo use Kerberos for authentication, your AS ABAP system must be enabled for using Secure Network Communications (SNC) with an external securityprovider that supports Kerberos. SNC is a software layer that provides a GSS API v2 interface to an external security product.For more information about SNC, see Secure Network Communications (SNC).SAP provides a gsskrb5.dll library that enables the use of Kerberos for SAP GUI authentication for Microsoft Windows only system environments. You canuse an alternative Kerberos supporting product certified by the SAP Partner Program.For more information about the SAP certified security products, see http://service.sap.com/security .

Implementation Considerations


Page 8 of 119

Kerberos employs several systems in your landscape and cryptographic mechanisms for access authentication, thereby overcoming the disadvantages ofweaker authentication mechanisms such as user ID and password. SAP GUI users that are authorized to use Kerberos logon must log on to their local computerand can subsequently access the AS ABAP from the SAP GUI without the need to interactively provide user IDs and passwords. For more information about theKerberos authentication protocol and infrastructure, see Kerberos V5 Administrator's Guide , available from http://web.mit.edu .The Kerberos authentication process relies on the exchange of session tickets between the SAP GUI and the AS ABAP. The session tickets are issued by aKerberos Key Distribution Center (KDC) when the user attempts to connect to the AS ABAP from the SAP GUI. The KDC itself establishes and verifies the useridentity and the user is not required to interactively provide a user ID and password for the AS ABAP logon.As a result of the use of session tickets, the AS ABAP authentication credentials of users are not communicated over the network for the connection between theSAP GUI and the AS ABAP. Thereby, the credential confidentiality and integrity protection is guaranteed.The process of authenticating access to the AS ABAP, however, requires the exchange of several messages over the network. In a distributed system landscapethis can result in performance lags related to network performance. In addition, Kerberos makes use of several systems in your landscape, which may result inadditional administrative effort and costs.ConfigurationFor information about configuring the use of Kerberos for SAP GUI authentication, see Single Sign-On with Microsoft Kerberos SSP.

3.1.4 Windows NT LAN Manager (NTLM) Authentication

UseThe SAP GUI also enables you to use NTLM for authenticating access to AS ABAP from the SAP GUI in a Microsoft Windows environment. NTLM authenticationis available for the SAP GUI as a tailored version for SSO with Secure Network Communications (SNC), which uses Microsoft's NT domain authentication andNT LAN Manager Security Service Provider (NTLM SSP).

PrerequisitesNTLM is only available for Microsoft Windows 32-bit system environments, consisting of Microsoft Windows 9x, Microsoft Windows ME, Microsoft Windows NT,Microsoft Windows 2000 and higher.To enable NTLM, the AS ABAP system must be enabled for using SNC. To integrate the AS ABAP into a Single Sign-On environment under Windows NT (nointegrity or privacy protection is provided), you can use Microsoft's NT LAN Manager Security Support Provider (NTLMSSP) from Microsoft as the securityprovider.

NoteMicrosoft's NTLM SSP does not provide you with the full SNC protection capabilities. To enable data integrity and privacy protection with NTLM, you need touse an additional security product. We recommend that you use Kerberos for SAP GUI Authentication for system environments consisting of MicrosoftWindows 2000 and higher.

Security ConsiderationsNTLM uses a challenge-response sequence of messages between the a client and a server system. NTLM provides authentication based on a challenge-response authentication scheme. It does not provide data integrity or data confidentiality protection for the authenticated network connection. Therefore, to ensuredata integrity and privacy protection in the authentication process, you must use SAP Single Sign-On or an external security product that is certified for use withSNC.For more information about the SAP-certified security products, see http://service.sap.com/security .ConfigurationFor more information about configuring NTLM authentication, see Single Sign-On with Microsoft NT LAN Manager SSP.

SNC with SAP Single Sign-On Secure Login

UseSAP Single Sign-On Secure Login is an add-on product to improve user and IT productivity and to protect business-critical data in SAP business solutionsthrough secure Single Sign-On to the SAP environment.

NoteSAP Single Sign-On requires additional software licenses.

Secure Login provides strong encryption, secure communication, and single sign-on between SAP GUI or Web GUI and SAP NetWeaver platform with SecureNetwork Communications (SNC). Secure Login support SAP GUI clients such as SAP Logon, SAP Logon Pad, SAP NetWeaver Business Client, SAP BusinessExplorer in addition to Web GUI through the browser.In a default SAP setup, users enter their SAP user name and password into the client logon screen. SAP user names and passwords are transferred through thenetwork without encryption.To secure networks, SAP provides a Secure Network Communications interface (SNC) that enables users to log on to SAP systems without entering a user nameor password. The SNC interface can also direct calls through the Secure Login Library to encrypt all communication between the client and SAP server, thusproviding secure single sign-on to SAP.Secure Login enables you to benefit from the advantages of SNC without being forced to set up a Public Key Infrastructure (PKI). Secure Login has the followingadvantages:

Kerberos and X.509 authentication separately or in parallelFlexible level of security: Kerberos, software certificates, 2-factor authentication, one time password (OTP), smart card or smart token integration, PKIintegration


Page 9 of 119

Better integration with existing IT landscapes: Diverse server connectors, integration with SAP Identity Management, user name mapping

More InformationFor more information, see SAP Help Portal at http://help.sap.com/nwsso.

3.2 Authentication for Web-Based Access

PurposeThe Web server capabilities of the SAP NetWeaver platform enable you to provide effective solutions to the divergent information requirements posed by thevarious users. For example, you can use the Web-based portal interface to enable Web browser access to information from multiple sources.The portal delivers advanced capabilities for categorizing and searching for information, allowing selective and intuitive targeting of files and documents at variedinformation sources. Respectively, to implement an effective and flexible access policy, corresponding to the information requirements of the portal users, SAPNetWeaver enables you to use a number of options for authenticating Web-based access requests.

Implementation ConsiderationsSAP NetWeaver Application Server for Java is the underlying technology that enables authentication for portal users. The Web browser acts as a client for theportal and sends the user credentials that correspond to the configured authentication mechanisms on the AS Java where the portal runs.

NoteFor supported Web browser versions, see the SAP NetWeaver Product Availability Matrix (PAM) available from SAPService Marketplace atservice.sap.com/pam

FeaturesSAP NetWeaver enables you to configure and use a number of authentication mechanisms with varying degrees of complexity and security. You can customizethe security of your SAP NetWeaver systems to fit your authentication policies and needs.For information about the available authentication mechanisms, see the following topics:

Basic Authentication (User ID and Password)Logon TicketsX.509 Client CertificatesSAML 1.xSAML 2.0KerberosHeader VariablesOAuth 2.0 Introduction and Concept

3.2.1 Basic Authentication (User ID and Password)Basic authentication is an HTTP standard authentication method designed to allow a Web browser or another Web client to provide credentials - in the form of auser ID and password - when making a request to a server system.Basic authentication is supported by the majority of Web clients and is the authentication mechanism that can be implemented with the least additional effort.

User ID and Password Authentication in SAP NetWeaverSAP NetWeaver enables you to use several methods for user ID and password authentication:

basic - users provide their user IDs and passwords by entering them in a browser pop up. The user credentials are transported in the HTTP header as abase-64 encoded string.digest - represents an advanced form of basic authentication. For this authentication mechanism, the user credentials are hashed using a messagedigest and sent over the network in hashed format.form - users use a pre-configured Web page to enter their authentication credentials. The authentication information is then transported to the server in theURL as URL parameters.

Security ConsiderationsThe different methods for Web-based access authentication with a user ID and password enable you to use a simple authentication mechanism that is widelysupported by Web browsers.The HTTP methods for authentication with a user ID and password, however, provide minimal protection for the authentication credentials during their transport andrely on the assumption that the connection between the Web client and the server can be trusted. Therefore, for increased security of the access to SAPNetWeaver systems, you have to use transport layer security mechanisms in combination with the HTTP methods for authenticating users with a user ID andpassword.An additional security consideration is that when using only HTTP methods for authentication with a user ID and password, the server system is not authenticated.This can expose the user's credentials to certain attacks, for example phishing attacks, and thereby compromise the overall security of your systems.


Page 10 of 119

NoteWe recommend that you use a transport layer security mechanism, such as Secure Socket Layer (SSL) or a Virtual Private Network (VPN), whenauthenticating Web-based access requests with a user ID and a password.For more information, see Network and Transport Layer Security .

For complex system landscapes, when users have to access a large number of systems, however, user ID and password authentication can increase youradministrative costs for authentication management in multiple systems. In addition, users have to remember and securely store a large number of authenticationcredentials, which can lead to a decrease in the overall security of your SAP NetWeaver systems. The requirements for password secrecy can also expose yoursystems to social engineering attacks where user's passwords can be guessed or deceitfully acquired.

NoteFor additional security when using authentication with a user ID and password, we recommend that you configure the use of rules for password complexity andrequire users to change passwords regularly.

As an alternative to user ID and password authentication, you can use multi-factor authentication or an alternative authentication mechanism or integrate your SAPNetWeaver systems in a Single Sign-On environment.

ConfigurationSAP NetWeaver Application Server (AS) Java and AS ABAP are the underlying technology platforms that SAPsystems use to authenticate user access requestsover HTTP with a user ID and a password. Configuring user ID and password authentication is specific to the underlying technology used by the applicationserver platform.For more information about configuring User ID and password authentication for Web based access, see Using User ID and Password Authentication .

3.2.2 Logon TicketsFor user authentication to multiple systems, SAP NetWeaver enables you to configure the use of logon tickets. You can use logon tickets to provide and administeruser authentication based on cookie technology for complex system landscapesFor an overview of the authentication process when using logon tickets, see the figure below.

Authentication with Logon TicketsWhen using logon tickets, one system in your landscape is set up to issue logon tickets to users. Users log on initially to this system to obtain the logon ticket. Theissuing system uses cryptographic functions to digitally sign the logon ticket, thus certifying its authenticity. Users can then use the logon ticket to access othersystems (SAP or non-SAP) that have an established trust relationship with the issuing system.Instead of having to provide a user ID and password for authentication, the user is allowed access to the system after the accepting system has verified the logonticket based on its trust relationship with the issuing system.


Page 11 of 119

PrerequisitesAS ABAP systems that issue the logon tickets must be Release 4.6C or higher. SAP systems that are to accept the ticket have to meet the following releaserequirements:

Release 4.6A/B: 4.6D kernel as of patch level 74Release 4.5: 4.5B kernel as of patch level 459Release 4.0: 4.0B kernel as of patch level 758

For more information, see SAP Note 177895.

Security ConsiderationsWhen using logon tickets for authentication with Web applications, the user's ticket is stored as a non-persistent cookie in the user's Web browser. This cookiecontains the public information necessary to authenticate the user to additional systems without the need to interactively provide a password. The informationcontained in the logon ticket includes:

User ID - for the case when the user has multiple user IDs for in different systems, you can use a mapping system to map the user IDs in the varioussystems. For more information, see Accessing Back-End Systems with a Different User ID .Validity periodIssuing systemDigital signature - to guarantee the integrity and authenticity of the user's logon ticket, the SAP system that issues the ticket signs the ticket with its owndigital signature.

Due to the nature of cookie technology, the logon ticket is sent by the user's Web browser to accessed servers within the DNS domain where the ticket issuingserver is located, for example to all servers registered in the domain mycompany.com.

CautionTo protect the logon ticket from being sent to servers that should not receive it, we recommend using a separate domain for your ticket accepting systems(SAP and non-SAP) and restricting the possibility to register new servers in this domain.

Therefore, when using logon tickets for authentication, we recommend that you protect the application server's private key.For more information, see Digital Signatures and Encryption .In addition, we recommend that you also protect the logon ticket from being compromised or manipulated during transfer by using transport layer security solutions.For more information, see Network and Transport Layer Security .

ConfigurationFor more information about configuring SAP NetWeaver systems to use logon tickets for authentication, see Using Logon Tickets .

3.2.3 X.509 Client CertificatesAs an alternative to authenticating with a user ID and passwords, users can present X.509 client certificates for accessing Web applications. In this case, userauthentication takes place using the underlying Secure Sockets Layer (SSL) protocol and users do not need to interactively enter a password for logon.For an overview of the authentication process flow when using X.509 certificates, see the figure below.


Page 12 of 119

X.509 Certificate Authentication FlowAuthentication with X.509 Certificates makes use of a Public Key Infrastructure (PKI) to securely authenticate users. After users receive their X.509 certificatesfrom a certificate issuing Certification Authority (CA), they can use them to securely access SAP NetWeaver, as well as non-SAP systems. The SAP NetWeaverand the non-SAP system can authorize access requests, based on an established trust relationship with the CA.In addition, users can use their X.509 certificates to authenticate their access to systems located on the Internet and within your company Intranet. Thereby, youcan use certificates for authentication in open environments such as the Internet.

NoteSAP Single Sign-On can issue X.509 certificates. SAP Single Sign-On includes a PKI infrastructure specially made for the requirements of SAP systems.For more information, see SAP Single Sign-On .

PrerequisitesYou have deployed a public key infrastructure to support issuing public key certificates to users. For more information, see Public-Key Technology .To use certificates for authentication with AS ABAP, the AS ABAP must be release 4.5B or higher.

Security ConsiderationsX.509 certificates use industry standard cryptographic mechanisms to securely authenticate user access. The exchange of the authentication credentialsbetween the front-end Web client and the AS ABAP, AS Java or non-SAP system is secured through the use of public key cryptography and the underlying SSLprotocol. For additional security, you can also enable mutual authentication, where both the front-end client and the back-end application server exchange X.509certificates to mutually establish their identities.When using X.509 client certificates and SSL for user authentication, you should note the following:

Your users need to possess valid certificates signed by a trusted CA. You can either establish your own CA and distribute certificates to your usersyourself, or you can rely on a Trust Center service. The CA you choose to use must be designated as a trusted CA on the accepting SAP NetWeaversystem.Users should be informed about how to protect their private key.When using authentication with client certificates, each user needs to possess a key pair, consisting of a public and a private key. The public key iscontained in the X.509 client certificate and can be made public. However, the user's private key needs to be kept safe.The possibilities available for securing the private key depend on the Web browser that you use. (For example, you may be able to protect it with apassword or you may be able to use smart cards.) If the private key is stored on the front-end client, your users should use screensavers protected with apassword.If users share Web browsers for clients, then note the following:As long as the operating system separates and protects user data at the operating system level (for example, Windows NT), then the private key stored onthe Web front-end client is protected by the operating system.

NoteWe recommend that you do not store the private key on the Web client frontend when using an operating system that does not separate user data (forexample, Windows 95).

ConfigurationFor more information about enabling authentication with X.509 client certificates, see Using X.509 client certificates .

3.2.4 SAML 1.x

UseSAP NetWeaver enables you to use the standard-based Security Assertion Markup Language (SAML) assertions for user authentication and Single Sign-On(SSO) in open system environments such as the Internet.SAML is a standard driven by the Organization for the Advancement of Structured Information Standards (OASIS). You can use SAML as a protocol for encodingsecurity-related information (assertions) into XML and exchanging this information in a request/response fashion.The figure below illustrates the authentication process when using SAML.


Page 13 of 119

Figure 1: SAML Authentication Process Flow

When using SAML, the authentication of users is performed by a system configured as an SAML Authentication Authority or an SAML Source Web site. SAMLauthorities produce assertions in response to client requests. An assertion can be either an authentication or an authorization assertion, with the followingrespective functions:

Authentication assertion: a piece of data that represents an act of authentication performed on a subject (user) by the authorityAuthorization assertion: a piece of data that represents authorization permissions for a subject (user) on a resource

You can use SAML for authentication and authorization requests to SAML assertion accepting systems, or SAML destination sites.SAP NetWeaver supports only the use of SAML authentication assertions with the Java technology stack. The portal can act as a SAML source site and both theAS Java and the AS ABAP can act as SAML destination sites.

ConstraintsThe following constraints apply to the use of SAML with SAP NetWeaver:

Version 1.0 and 1.1 of the SAML specification are supported.The condition element AudienceRestrictionCondition is accepted by the AS Java, although it is not evaluated. Any other child elements of theConditions element result in processing errors.Assertions must have exactly one AuthenticationStatement element. The authentication statement must have a NameIdentifier element.If they are present, the elements AuthorizationDecisionStatement and AttributeStatement are ignored.Creating digital signatures for outgoing documents is not supported. Digital signatures present with incoming documents are not verified.

Security ConsiderationsSAML is a standard for encoding authentication information that relies for message exchange on standard security protocols like SSL and TLS use XMLsignatures. Therefore, to protect the data exchange, SSL is required for the connection between the source and destination sites.For more information, see Network and Transport Layer Security .

NoteSSL is required by the SAML specification, and therefore its use is enforced by default in the SAML configuration. However, for testing purposes, you candisable the enforcement of SSL for the SAML-based document exchanges. In this case, you can receive warnings in the log files for your system.

SAML also relies on the exchange of several messages over the network to authenticate access. This can lead to performance lags, related to networkperformance, and affect the availability of the systems enabled to authenticate access with SAML.ConfigurationFor more information about configuring the use of SAML 1 for SAP NetWeaver systems, see Using SAML Assertions .

3.2.5 SAML 2.0

UseThe Security Assertion Markup Language (SAML) version 2.0 is a standard for the communication of assertions about principals, typically users. The assertioncan include the means by which a subject was authenticated, attributes associated with the subject, and an authorization decision for a given resource.The main benefits of SAML 2.0 are as follows:

SSO with SAML 2.0SAML provides a standard for cross-domain Single Sign-On (SSO). Other methods exist for enabling cross domain SSO, but they require proprietarysolutions to pass authentication information across domains. SAML 2.0 supports identity-provider-initiated SSO as in SAML 1.x. SAML 2.0 also supportsservice-provider-initiated SSO.SLO with SAML 2.0


Page 14 of 119

Single Log-Out (SLO) enables users to cleanly close all their sessions in a SAML landscape, even across domains. Not only does this save systemresources that would otherwise remain reserved until the sessions time out, but SLO also mitigates the risk of the hijacking of unattended sessions.Identity federationIdentity federation provides the means to share identity information between partners. To share information about a user, partners must be able to identify theuser, even though they may use different identifiers for the same user. The SAML 2.0 standard defines the name identifier (name ID) as the means toestablish a common identifier. Once the name ID has been established, the user is said to have a federated identity.

The two main components of a SAML 2.0 landscape are an identity provider and a service provider. The service provider is a system entity that provide a set ofWeb applications with a common session management, identity management, and trust management. The identity provider is a system entity that managesidentity information for principals and provides authentication services to other trusted service providers. In other words, the service providers outsource the job ofauthenticating the user to the identity provider. The identity provider maintains the list of service providers where the user is logged in and passes on logoutrequests to those service providers.The client that is trying to access the resource must be HTTP-compliant.

PrerequisitesYou have a SAML 2.0 identity provider in your landscape.

ConstraintsThe SAP NetWeaver Application Server (AS) Java 7.2 service provider supports SP lite as defined in Conformance Requirements for the OASIS SecurityAssertion Markup Language (SAML) V2.0For information about the constraints in the implementation of AS Java as a service provider, see Application Server Java as an SAML 2.0 Provider .

More InformationFor information about implementing SAML 2.0 with SAP NetWeaver, see Using SAML 2.0 .

3.2.5.1 SSO with SAML 2.0

UseSAML provides a standard for cross-domain Single Sign-On (SSO). Other methods exist for enabling cross domain SSO, but they require proprietary solutions topass authentication information across domains. SAML 2.0 supports identity-provider-initiated SSO as in SAML 1.x. SAML 2.0 also supports service-provider-initiated SSO.When the identity provider initiates SSO, you must maintain links on the identity provider system to the protected resources on the service providers. When youprotect resources with SAML on a service provider, the service provider is configured to request authentication from the identity provider.

ProcessSAML provides options to pass SAML messages back and forth between the identity provider and the service provider.

Front channelSAML messages are passed back and forth over the user agent with HTTP redirect or HTTP POST methods.Back channelOnly SAML artifacts are exchanged over the user agent by the identity provider and service provider. When a provider receives an artifact, it queries theother provider directly over SOAP.

Back-channel communication provides additional security, by ensuring that potential eavesdroppers of the user agent only access the SAML artifacts. However,back-channel communication requires additional round trips to resolve an authentication request. You can protect front-channel communication with encryption anddigital signatures. You can mix the communication options.Front-Channel CommunicationThe following figure illustrates service-provider-initiated SSO with front-channel communication.


Page 15 of 119

Figure 1: Process Flow for Front-Channel SSO with SAML 2.0

1. A user attempts to access resource protected by SAML 2.0.2. The service provider redirects user to an identity provider for authentication.3. The identity provider queries user for authentication credentials.4. The user or user agent presents the requested credentials.5. The identity provider returns the user to the service providers with an authentication response.6. The service provider presents the requested resource to the user.

Back-Channel CommunicationThe following figure illustrates service-provider-initiated SSO with back-channel communication.

Figure 2: Process Flow for Back-Channel SSO with SAML 2.0

1. A user attempts to access resource protected by SAML 2.0.2. The service provider redirects user to an identity provider and includes a SAML artifact referring to the authentication request.3. The identity provider gets the authentication request from the service provider over a SOAP channel.4. The identity provider queries the user for authentication credentials.5. The user or user agent presents the requested credentials.6. The identity provider returns the user to the service providers with a SAML artifact referring to the authentication response.7. The service provider gets the authentication response from the identity provider over a SOAP channel.8. The service provider presents the requested resource to the user.

3.2.5.2 SLO with SAML 2.0

UsePUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 16 of 119

UseSingle Log-Out (SLO) enables users to cleanly close all their sessions in a SAML landscape, even across domains. Not only does this save system resourcesthat would otherwise remain reserved until the sessions time out, and SLO also mitigates the risk of the hijacking of unattended sessions.

ProcessSAML provides a number of binding options to pass SAML messages back and forth between the identity provider and the service provider.

Front channelFor front-channel communication, SAML messages are passed back and forth over the user agent with HTTP redirect or HTTP POST methods.Back channelFor back-channel communication, the identity provider and service provider can use either SAML artifacts or communicate directly over SOAP. For SAMLartifacts, the identity provider and service provider exchange SAML artifacts over the user agent. When a provider receives an artifact, it queries the otherprovider directly over SOAP to resolve the artifact. For the SOAP binding, the providers pass no artifacts. They exchange SAML messages directly overSOAP.

Back-channel communication provides additional security, by ensuring that potential eavesdroppers of the user agent cannot access the SAML messages.However, the artifact binding requires additional round trips to resolve an authentication request. You can protect front-channel communication with encryption anddigital signatures. You can mix the communication options.The figure below illustrates SLO initiated at the service provider over a front-channel binding, such as HTTP redirect, and between the identity provider and theother service providers over a back-channel binding, such as SOAP over HTTP.

Figure 1: Process Flow for SLO with SAML 2.0

1. The user initiates a logout request at a service provider.2. The service provider forwards this request to an identity provider.3. After the identity provider validates the request, it sends new logout requests to all other service providers, with which the user has a security session that

the identity provider is aware of.4. The service providers validate the request, destroy any session information for the user, and send a logout response to the identity provider.5. The identity provider destroys the user's sessions and sends a response to the original service provider.6. The original service provider informs the user that he or she has been logged out.

More InformationHTTP Sessions and Security Sessions on the AS Java

3.2.5.3 Identity Federation

UseIdentity federation provides the means to share identity information between partners. To share information about a user, partners must be able to identify the user,even though they may use different identifiers for the same user. The SAML 2.0 standard defines the name identifier (name ID) as the means to establish acommon identifier. Once the name ID has been established, the user is said to have a federated identity.The SAML 2.0 standard defines a number of name ID formats. The table below describes the name ID formats.


Page 17 of 119

Types of FederationSAML describes the following types of federation:

Out-of-band account linkingTransient pseudonym identifiersPersistent pseudonym identifiers

Out-of-Band Account LinkingThe identities of a user in system A and system B are identified and agreed upon ahead of time between the administrators of the two systems. This kind ofagreement is supported by SAML 1.x, too. The administrator of the identity provider and the service provider agree how the name ID used for the user in theidentity provider maps to the user in the service provider.

ExampleUsers in the identity provider always log on with their e-mail address. The logon ID and e-mail address are identical. The administrator of the identity provideragrees to provide the Unspecified name ID format including the logon ID. After a user successfully logs on to the identity provider, whether by Kerberosname or client certificate or whatever, the identity provider provides the logon ID of the user to the service provider in the SAML assertion. The service provideris also configured to use the Unspecified name ID format and is configured to use the user attribute for the e-mail address. The service provider searchesfor the user with an e-mail address that matches. So long as the e-mail address in the service provider is unique, the service provider can log the user on.The figure below shows Laurent Becker has different User IDs on the identity provider and service provider. With SAML 2.0 he authenticates on the identityprovider. The identity provider passes his user ID to the service provider, and the service provider searches for his user by his e-mail address. Thus his twoaccounts are linked by user ID and e-mail address.

Figure 1: Account Linking with E-Mail Address

Use this kind of federation to support most scenarios where you need to map user identities across domains.Transient Pseudonym Identifiers

Name ID Format DescriptionE-mail The name ID is an e-mail address.

Kerberos The name ID is a Kerberos Principal Name (KPN).

Persistent The name ID is a permanent opaque string generated by the identity provider for aservice provider or an affiliation of service providers.

Transient The name ID is a temporary opaque string generated by the identity provider for a serviceprovider for the lifetime of a security session.

Unspecified The implementation of this name ID is vendor-specific. SAP assumes this value to beeither a user ID, a logon alias, or another attribute value depending on your technologystack.

For the AS ABAP, this is a mapping in the table USREXTID.For the AS Java this is an attribute of the user.

Windows Name The name ID is a user ID qualified by a Windows domain.

X509 Subject Name The name ID is the subject name of an X.509 certificate.


Page 18 of 119

Federation with transient name IDs creates a federation with a temporary user in the service provider and a permanent user in the identity provider. This federationonly exists as long as the security session with the service provider exists. The service provider does not persist data about the visiting user.User attributes and access rights are generated based on rules applied to attributes sent in SAML messages.Use this kind of federation when the service provider does not need to record information about users or do not need local user accounts.Persistent Pseudonym IdentifiersFederation with persistent name IDs establishes a permanent relationship between a user on an identity provider and a user on a service provider or users on anaffiliation of service providers. The persistent name ID is used by an identity provider and a service provider as a common name for a single user. If this name IDfor a user is the same for multiple service providers, the service providers are said to be affiliated or belong to an affiliation group.Use this kind of federation to link accounts out-of-band, but without using identifiers that can be traced back to a specific user. This increases the security of yoursystems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses. It requires you toestablish the pseudonym on both providers ahead of time.Federation with persistent name IDs also offers the following additional options:

Interactive federationFederation is established on the fly. You can enable users to interactively establish federation between existing accounts.Use this kind of federation if you have not created persistent pseudonyms on the identity provider and service provider ahead of time. It enables you toconfigure these mappings as you go.Automatic creationFederation is established on the basis of attributes passed to the target system. If the user has no account in the target system, the service providerautomatically creates the account. The attributes are generated from rules based on SAML 2.0 attributes sent in SAML messages.Use this kind of federation to create and even provision users as you federate their accounts on the service provider.

NoteThe AS ABAP does not support automatic creation.

ExampleThe figure below illustrates the accounts of Laurent Becker each have an attribute for a persistent name ID, named opaque ID. The value to use here can beagreed upon in advance by the two system administrators or generated by the identity provider and distributed to the service provider. When Laurent Beckerauthenticates on the identity provider, the service provider receives the SAML assertion with the opaque ID as the subject. The service provider searches forthe user based on the opaque ID and logs the user on.

Figure 2: Account Linking with Persistent Name ID

Securing DataYou can ensure that sensitive data is encrypted when two systems share such information.The use of the pseudonym name ID formats (transient and persistent) ensure privacy and anonymity between two partners (identity provider and serviceprovider). Neither partner needs to be aware of the local account name used by the other partner, protecting the user's privacy.

3.2.5.4 Common Domain and Identity Provider Discovery

UsePUBLIC 2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 19 of 119

UseThe Security Assertion Markup Language (SAML) 2.0 service provider uses common domain cookies (CDC) to determine to which identity provider the serviceprovider should send a request. The common domain is the domain where the CDC resides. This common domain is known to both the identity provider and theservice provider. Identity providers identify themselves to a service provider by writing their alias into the CDC. The service provider of SAP NetWeaverApplication Server reads the alias from the CDC. This service provider includes an internal read service for identity provider discovery. It can also use an externalread service. When enabled, these services read CDCs to help the service provider determine which identity provider to use. When to use the external andinternal read services depends on your network architecture.

If the service provider shares the same domain with the common domain, use the internal service.If the service provider exists in a different domain from the common domain, use the external service.

For more information, see Influencing the Identity Provider Used by the Service Provider .

ExampleCommon Domain is the Shared DomainThe figure below illustrates a service provider and an identity provider sharing the same domain. The identity provider writes its alias to a CDC in the shareddomain using domain relaxing to remove its host name. The internal read service of the service provider can read the CDC because it shares the same domain.

Figure 1: Service Provider, Identity Provider, and Common Domain Cookie All Share the Same Domain

Common Domain is a Different DomainThe figure below illustrates a service provider and an identity provider in two different domains. The operators of both providers have agreed on a common domainfor the CDC at itelo.biz. The identity provider writes its alias to the CDC in the common domain. The service provider calls an external read service within thecommon domain to read the CDC. The external read service of the service provider can read the CDC because the read service shares the same domain with theCDC.

Figure 2: Service Provider and Identity Provider Reside in Different Domains and Access Common Domain Cookie in Common Domain


Page 20 of 119

3.2.6 Kerberos Authentication

UseKerberos is an authentication protocol developed by the Massachusetts Institute of Technology. Kerberos allows individuals communicating over an insecurenetwork to prove their identity to one another in a secure manner. Kerberos authentication can be used to overcome weak points such as eavesdropping andreplay attacks in other authentication mechanisms and to ensure the integrity of the data that is communicated.The Kerberos authentication process involves several systems connected in a network, or a Kerberos realm. Kerberos authentication within a realm works on thebasis of tickets, which serve to prove the authenticity of client requests. Kerberos authentication makes use of a trusted third party system called Key DistributionCenter (KDC).The KDC maintains a database of secret keys where each member system of a realm - whether a client or a server - shares a secret key known only to itself andto the Kerberos KDC. Knowledge of this key serves to prove the system's identity and this key never leaves the KDC. After the client is authenticated the KDCgenerates a session key for communication between the client and the application server, which they can use to secure their interactions.

Implementation ConsiderationsWhile Kerberos can overcome the vulnerabilities of other Web-based authentication mechanisms, the Kerberos configuration and administration can result in arelatively high administrative effort. In addition, Kerberos relies on authentication infrastructure, such as a Key Distribution Center, that enforces a MandatoryAccess Control approach to authentication. Therefore, the use of Kerberos in open environments such as the Internet can increase the administrative loadassociated with the scalability of Kerberos supporting infrastructure.For information about the integration of non-Windows server components in the Microsoft Kerberos Infrastructure, see the documents available from the MicrosoftDeveloper Network (MSDN) at http://msdn.microsoft.com. .

IntegrationSAP NetWeaver Application Server (SAP NetWeaver AS) Java supports Kerberos with SPNego authentication.SAP NetWeaver AS for ABAP only supports Kerberos with SPNego in conjunction with SAP Single Sign-On 2.0 or higher.

More InformationKerberos and SAP NetWeaver AS for JavaUsing Kerberos Authentication on SAP NetWeaver AS for JavaFor more information about SAP Single Sign-On, see http://help.sap.com nwsso

3.2.7 Header Variables

UseSAP NetWeaver Application Server (AS) Java supports the use of header variables for authentication and Single Sign-On (SSO). With header variables, you canuse a third-party Web access management (WAM) product to authenticate your users. The WAM product returns an authenticated user ID as part of the HTTPheader. Users only have to authenticate once against the WAM product and can then access applications on the AS Java with SSO.

The figure below presents an overview of the process flow for header variable authentication.

Figure 1: Process Flow for Authentication with Header Variables


Page 21 of 119

Authentication with a WAM product works as follows:1. The WAM product authenticates the user and returns an authenticated user ID to the AS Java as part of the HTTP header.2. The AS Java compares this user ID against those available in the data sources of the user management engine (UME).3. The AS Java authenticates the user upon finding a match.

The AS Java provides the HeaderVariableLoginModule login module that reads a user ID from the HTTP header variable and then uses this user ID toauthenticate the user. Use this login module if you are already using third-party WAM product to protect other resources in your company, or if you useauthentication mechanisms that are not directly used by the AS Java, such as token cards or biometrics.

PrerequisitesTo use a third-party product with the header variable login module for authentication, you must use an external intermediary server for access to the ASJava. All requests must pass through the intermediary server.The user ID that the third-party product returns in the HTTP header must exist in the UME data sources.

Security ConsiderationsAttackers can impersonate a user by sending a request with a user ID in the appropriate header variable to the AS Java. To prevent such attacks, do thefollowing:

Using appropriate measures, make sure that the HTTP and HTTPS ports of the AS Java cannot be directly accessed by client Web browsers, for exampleby using firewalls. Users should only access the AS Java through its intermediary server. This prevents attackers from bypassing the intermediary serverand impersonating authenticated users.If it is not possible to block the HTTP and HTTPS ports of the AS Java, you must configure Secure Sockets Layer (SSL) with mutual authentication betweenthe intermediary server and the AS Java. This way, the AS Java can trust that user information contained in the header variable, because it comes from atrusted server.To set up SSL with mutual authentication between the intermediary server and the AS Java, add the certificate of the intermediary server to the list of trustedroot certificates in the AS Java. Then configure the AS Java to accept only incoming requests that are signed with the certificate of the intermediary server.For more information about configuring SSL with an intermediary server on the basis of an example using SAP Web Dispatcher, see Using SSL With anIntermediary Server .

If you deploy a portal on your AS Java, you must consider how header variables can hinder log off. By default, portal users are redirected to the default logonscreen after they log off. If the portal uses a WAM product to authenticate users, the portal logoff cannot delete the session identifiers created by the external tool.Users are automatically logged on again. It is impossible for users to log off the portal. To prevent portal users from being logged on again automatically, redirectusers to a screen other than the default logon screen at logoff.For more information, see the portal documentation.ConfigurationThe exact steps for setting up authentication with header variables depends on the product you use. In all cases, you must adjust the login module stacks ortemplates of the applications to use header variable authentication.For more information, see Using Header Variables .

3.2.8 OAuth 2.0 Introduction and Concept

ConceptOAuth 2.0 is an open authorization framework based on an IETF specification. It was originally developed for social networks, but it evolved to become anauthorization concept for the cloud and business-to-business integration. In the cloud, people use services from different service providers. As software vendorsare moving their products to the cloud with offerings such as SAP Business ByDesign or cloud office services, more and more business users need to accessresources offered by service providers. To make access to the desired resources easier, SAP supports the open authorization framework OAuth 2.0.With OAuth 2.0, users allow Web-based client applications to access the resources. The application that is authorized by the resource owner accesses theresources on behalf of the user. Thus users who do not want to reveal their user names and passwords for the service provider where the resources are locatedare able to delegate access to the resources using an OAuth 2.0 access token.The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to a resource using OAuth 2.0 scopes either on behalf of a resourceowner by orchestrating an approval interaction between the resource owner and the resource, or by allowing the third-party application to obtain access on its ownbehalf.The interface to the OAuth 2.0 client is a REST API.

More InformationFor more information, see the Web site of the Internet Engineering Task Force (IETF). See also Business Example for Accessing Resources with OAuth 2.0 andOAuth 2.0 Scopes.

3.2.8.1 OAuth 2.0 Server with AS ABAPAn AS ABAP acts as an OAuth 2.0 server and offers web-based services to OAuth 2.0 clients.OAuth 2.0 is available for OData services that are integrated with OAuth 2.0 runtime.

RestrictionSAP supports OAuth 2.0 in the context with OData-enabled RESTful services.AS ABAP supports authentication and authorization for server-to-server communication based on OAuth 2.0.SAP supports OAuth 2.0 with a number of different flows (see the related link).

Related Information


Page 22 of 119

OAuth 2.0 Flows Supported by SAP

3.2.8.2 OAuth 2.0 Scopes

DefinitionTo make sure that unauthorized users cannot access the resources, you can restrict access by using OAuth 2.0 scopes. An OAuth 2.0 scope represents a list ofresources that can be accessed by remote applications. Developers of the OAuth 2.0 enabled services predefine scopes. They are delivered together with aframework that can provide OAuth 2.0 enabled services (for example, SAP NetWeaver Gateway.In the customer system, administrators assign scopes to the following:

OAuth 2.0 clients. These clients represent OAuth 2.0 enabled applications that access the services on behalf of the resource owner.Users of the relevant business scenario. These users are the resource owners. Depending on grant type used, the resource owners can further restrict thenumber of scopes for certain clients during the access token request. They can decide which applications are allowed to access which business resource.

You cannot create or edit OAuth 2.0 scopes directly in the AS ABAP. For example, SAP NetWeaver Gateway can provide services that are OAuth 2.0 enabled.Each Gateway service is assigned to a separate scope. Whenever a Gateway service is activated, a new OAuth 2.0 scope is created. You can use the scope toprotect the service.

More InformationFor more information, see the following topics:

SAP NetWeaver Gateway SAP NetWeaver Gateway Developer Guide SAP NetWeaver Gateway Cookbooks Resource Owner in OAuth 2.0.Setting Up an OAuth 2.0 Client

3.2.8.3 OData

DefinitionOData (Open Data Protocol) is a Web protocol for querying and updating data that provides a way to unlock data and free it from restrictions that exist inapplications today. Since OData applies Web technologies, it enables you to access information from a variety of applications, services, and stores and thusassures interoperability across a broad range of clients, servers, services, and tools. OData is being used to expose and access information from a variety ofsources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites. It uses URIs to identify resourcesand uses an HTTP-based uniform interface for interacting with those resources.

More InformationFor more information, see the Web sites of the Open Data Protocol.

3.2.8.4 Resource

DefinitionA resource is data that is owned by a resource owner and that you can access with an external OAuth 2.0 client enabled application, for example an applicationin the cloud or on premise or a mobile device. Typical data can be business data, project data, or any kind of documents. A unique URL points to the resource.For example, a SAP NetWeaver Gateway OData service protects such a resource.

More InformationFor more information, see SAP NetWeaver Gateway SAP NetWeaver Gateway Cookbooks and OAuth 2.0 Scopes.

3.2.8.5 Resource Owner in OAuth 2.0Resource owners are central elements in the OAuth 2.0 concept. Usually resource owners are users who play a certain role in the respective business scenario,for example salespersons.

DefinitionThey make resources (see Resource) available for other users by delegating their scopes to OAuth 2.0 enables client applications. These applications use anOAuth 2.0 client to access the resources on behalf of the resource owners.Depending on the grant type used, the resource owners can further restrict the number of scopes for certain client during the access token request. They canfreely decide which applications can access which business resources by assigning them to the business resources.

IntegrationA resource owner is allowed to delegate OAuth 2.0 scopes. They contain exactly the set of resources a specific application can assess with an OAuth 2.0 client.From a technical point of view, a resource owner is a user of the type Dialog in an AS ABAP. This user has a specific role (assigned in transaction SU01) thathas been designed for OAuth 2.0. In the role for OAuth 2.0, you can determine the OAuth 2.0 client and the respective scope. The resource owner is allowed to


Page 23 of 119

delegate his resource to the scope.If you enter a specific client ID, only this client can access the resource. If the value * is set in OAuth 2.0 Client ID , any client can access the respectiveresource.

More InformationFor more information, see the following topics:

OAuth 2.0 ScopesSetting Up an OAuth 2.0 ClientBusiness Example for Accessing Resources with OAuth 2.0

3.2.8.6 OAuth 2.0 Token Context Revocation

UseYou are working in a project where users from an external company have editing access to documents, files, and diagrams. Now the project is finished, and theseusers no longer need to access those resources. You therefore want to revoke the access tokens of these users. Either the resource owner or an administratorperforms this task.If you use OAuth 2.0 for authentication, access tokens are issued for various users on a regular basis, for example daily. The tokens can be issued in a SAMLbearer assertion flow or in an authorization code flow. The transactions for token context revocation enable a user to filter, display and to revoke access tokens. Thefollowing transactions are available:

OAuth 2.0 Token Context Revocation for resource owners (transaction SOAUTH2_REVOCATION)OAuth 2.0 Token Context Revocation for administrators (transaction SOAUTH2_REVOKE_ADM)

The transactions enable you to see the following items:

More InformationFor more information, see Revoking an OAuth 2.0 Token and Configuring OAuth 2.0 Token Context Revocation.

3.2.8.7 OAuth 2.0 Flows Supported by SAP

IntegrationThere are various OAuth 2.0 flows that enable authentication and authorization with an OAuth 2.0 client at a back-end where you want to access resources.Currently SAP offers the following OAuth 2.0 flows:

3.2.8.7.1 SAML 2.0 Bearer Assertion Flow for OAuth 2.0

PrerequisitesThere is a trust relationship between the authorization server and the issuer of the SAML 2.0 bearer assertion, which is the identity provider.The resource owner must be known by the SAML 2.0 identity provider.The resource owner is a user who has the roles that grant him or her the authorizations to access the resources that are to be accessed by the cloud or web-

User User who issued the access tokenType Type of access token, for example, authorization codeCreation date Creation date of the access tokenCreation time Creation time of the access tokenExpiration date Expiration date of the access tokenExpiration time Expiration time of the access tokenScopes OAuth 2.0 scopes with a link with which you can display the scopes assigned to the

selected token contextOAuth 2.0 Scope ID OAuth 2.0 scope ID granted by the resource ownerOAuth 2.0 Scope Description Description entered by the resource owner. This should list the resources.

Scenario Authentication Method Recommended FlowServer-to-server communication: A user authenticates at aweb application. The web application needs to accessresources from an OAuth 2.0-enabled back-end on behalfof the user.

SAML 2.0 on behalf of the user SAML 2.0 Bearer Assertion Flow for OAuth 2.0

Loosely integrated communication between webapplications. No trust for Single Sign-On needs to beestablished between the web application and the AS ABAPsystem hosting the protected resources. The user givesconsent to grant access to a certain set of resources.

All resource owner authentication methods supported byan AS ABAP, for example, user name and password. Formore information, see Standard Logon Order.

Authorization Code Flow for OAuth 2.0


Page 24 of 119

based application.In the configuration of the OAuth 2.0 client, you have assigned OAuth 2.0 scopes in Scope Assignment .You have assigned a cloud or Web-based service application to an OAuth 2.0 client.The resource owner must also be authorized to delegate access to an OAuth 2.0 client.The OAuth 2.0 client (user with user type System) must have the right to access the resources.The OAuth 2.0 client must have an entry with the trusted identity provider for OAuth 2.0.You have activated the grant type SAML 2.0 Bearer Active in the OAuth 2.0 client.You have installed an application that supports OData on AS ABAP, such as SAP NetWeaver Gateway. For more information, see SAP Note 1688545 .

For more information, see Configuring OAuth 2.0.

ProcedureYou want to access selected resources of an AS ABAP using a browser-based cloud application without being forced to supply your user's login credentials (forexample your password) to the OAuth 2.0 client application. OAuth 2.0 allows users to delegate a subset of their permissions to another application, such as acloud application which can then access the resources on behalf of the users.A user is working in a cloud application and wants to access selected resources in an AS ABAP. To get access to the resources, this user needs to authenticateat the cloud or Web-based application and get the authorization to access the respective resources. The OAuth 2.0 client handles the entire authentication andauthorization procedure with the SAML 2.0 bearer assertion flow:

1. The OAuth 2.0 client gets a SAML 2.0 bearer assertion from the SAML 2.0 identity provider. The assertion contai

user authentication and single sign on.pdf

Documents