User Authentication and Single Sign On PDF

User Authentication and Single Sign-On
PDF 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.
Note
This 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 purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable 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 express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC Page 1 of 119

© 2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 User Authentication and Single Sign-On
2 SAP Single Sign-On
3 Authentication Concepts
3.1 Authentication for SAP GUI
3.1.1 User ID and Password Authentication for SAP GUI
3.1.2 Client Certificate Logon for SAP GUI
3.1.3 Kerberos for SAP GUI Authentication
3.1.4 Windows NT LAN Manager (NTLM) Authentication
3.1.5 SNC with SAP Single Sign-On Secure Login
3.2 Authentication for Web-Based Access
3.2.1 Basic Authentication (User ID and Password)
3.2.2 Logon Tickets
3.2.3 X.509 Client Certificates
3.2.4 SAML 1.x
3.2.5 SAML 2.0
3.2.5.1 SSO with SAML 2.0
3.2.5.2 SLO with SAML 2.0
3.2.5.3 Identity Federation
3.2.5.4 Common Domain and Identity Provider Discovery
3.2.6 Kerberos Authentication
3.2.7 Header Variables
3.2.8 OAuth 2.0 Introduction and Concept
3.2.8.1 OAuth 2.0 Server with AS ABAP
3.2.8.2 OAuth 2.0 Scopes
3.2.8.3 OData
3.2.8.4 Resource
3.2.8.5 Resource Owner in OAuth 2.0
3.2.8.6 OAuth 2.0 Token Context Revocation
3.2.8.7 OAuth 2.0 Flows Supported by SAP
3.2.8.7.1 SAML 2.0 Bearer Assertion Flow for OAuth 2.0
3.2.8.7.1.1 Business Example for Accessing Resources with OAuth 2.0 Using a SAML Bearer Assertion
3.2.8.7.2 Authorization Code Flow for OAuth 2.0
3.2.8.7.2.1 Business Example for Accessing Resources with OAuth 2.0 Using an Authorization Code
3.3 Authentication for Web Services
3.3.1 Authentication at HTTP Transport Level
3.3.2 Authentication at SOAP Message Level
3.3.2.1 SAML Token Profile
3.3.2.2 WS Security UsernameToken
3.4 Authentication for Communication between Systems
3.4.1 Authentication Assertion Tickets
4 Authentication Infrastructure
4.1 AS ABAP Authentication Infrastructure
4.1.1 Profile Parameters for Logon and Password (Login Parameters)
4.1.2 Secure Network Communications (SNC)
4.1.3 System Logon
4.1.3.1 Security Aspects for BSP
4.1.3.2 Security Considerations for Web Dynpro Applications
4.1.4 Maintaining Logon Procedures
4.1.4.1 Logon Checks: Overview
4.1.4.2 Standard Logon Order
4.1.4.3 Alternative Logon Order
4.1.4.4 Logon Ticket Cache
4.1.4.5 Logon Using Service Data
4.1.4.6 Logon with SSL Certificate
4.1.4.7 Logon Using Basic Authentication.
4.1.4.8 Logon via SAML
4.1.4.9 Specifying the Client
4.1.4.10 Determining the Logon Language
4.1.4.11 Inserting an HTTP Request Handler
4.1.5 Activating HTTP Security Session Management on AS ABAP

4.1.6 Disabling the Display of Last Logon for HTTP Logons
4.1.7 OAuth 2.0 Implementation with AS ABAP
4.1.7.1 Authorization Server of the OAuth 2.0 Implementation
4.1.7.1.1 Token Endpoint for OAuth 2.0
4.1.7.1.2 Authorization Endpoint for OAuth 2.0
4.1.7.2 Resource Server for OAuth 2.0
4.2 AS Java Authentication Infrastructure
4.2.1 Declarative and Programmatic Authentication
4.2.2 Login Modules
4.2.2.1 Managing Login Modules
4.2.2.2 Creating the Configuration File for Login Modules
4.2.3 HTTP Sessions and Security Sessions on the AS Java
4.2.4 Policy Configurations and Authentication Stacks
4.2.4.1 Creating Authentication Stack Templates for Policy Configurations
4.2.4.2 Editing the Authentication Policy of AS Java Components
4.2.4.3 Configuring Authentication Properties
4.2.4.4 Setting a Logon Policy for a Policy Configuration
4.2.5 User Mapping and the AS Java
4.2.6 Application Server Java as a SAML 2.0 Provider
4.2.7 Kerberos and SAP NetWeaver AS for Java
5 Integration in Single Sign-On (SSO) Environments
5.1 Single Sign-On for the SAP GUI
5.1.1 Logon and Password Security for SAP GUI
5.1.1.1 Password Rules
5.1.1.2 List of Customizing Switches for Generated Passwords
5.1.1.3 Logging Off Inactive Users
5.1.2 Single Sign-On for SAP Shortcuts
5.1.2.1 Integrating SAP GUI for Windows in a Portal iView
5.1.3 Single Sign-On with Client Certificates
5.1.3.1 Preparing the Central Instance
5.1.3.2 Activating SSO on the SAP Logon
5.1.4 Single Sign-On with Microsoft Kerberos SSP
5.1.4.1 Preparing the Primary Application Server Instance
5.1.4.2 Configuring the SAP Front End
5.1.4.3 Configuring the SAP Logon
5.1.4.4 Mapping Windows Users to SAP Users for Kerberos SSO
5.1.5 Single Sign-On with Microsoft NT LAN Manager SSP
5.1.5.1 Starting the Windows LM Security Support Provider Service
5.1.5.2 Configuring the Application Server
5.1.5.3 Configuring SAP GUI and SAP Logon for Single Sign-On
5.1.5.4 Mapping Windows Users to SAP Users for NTLM SSO
5.2 Single Sign-On for Web-Based Access
5.2.1 Using User ID and Password Authentication
5.2.1.2 Logon Using User ID and Password on the AS Java
5.2.1.2.1 Configuring User Mapping with User ID and Password on an AS Java
5.2.1.3 Using Rules for User Mapping in Basic Password Login Module
5.2.2 Using Logon Tickets
5.2.2.1 Using Logon Tickets with AS ABAP
5.2.2.1.1 Configuring the AS ABAP for Issuing Tickets for Logon
5.2.2.1.2 Configuring AS ABAP to Accept Logon Tickets
5.2.2.1.2.1 Accepting Logon Tickets Issued by Another AS ABAP
5.2.2.1.2.2 Accepting Logon Tickets Issued by the AS Java
5.2.2.2 Using Logon Tickets with AS Java
5.2.2.2.1 Configuring the AS Java to Issue Logon Tickets
5.2.2.2.1.1 Specifying the Client to Use for Logon Tickets
5.2.2.2.1.2 Replacing the Key Pair to Use for Logon Tickets
5.2.2.2.2 Configuring the AS Java to Accept Logon Tickets
5.2.2.2.2.1 Checking or Updating the Certificates of Trusted Systems
5.2.2.2.3 Testing the Use of Logon Tickets
5.2.2.2.4 Sample Login Module Stacks for Using Logon Tickets
5.2.2.2.5 Configuring the Validity Period of Logon Tickets

5.2.3 Using X.509 Client Certificates
5.2.3.1 Using X.509 Client Certificates on the AS ABAP
5.2.3.1.1 Configuring the AS ABAP to Use X.509 Client Certificates
5.2.3.1.2 Rule-Based Certificate Mapping
5.2.3.1.2.1 Managing Rules for Certificate Mapping
5.2.3.1.2.1.1 Checking Certificates for Rule Coverage
5.2.3.1.2.1.2 Creating Rules for Certificate Mapping
5.2.3.1.2.1.3 Creating Explicit Mappings for Certificates
5.2.3.1.2.2 Migrating to Rule-Based Certificate Mapping
5.2.3.1.3 Mapping X.509 Certificates in Table USREXTID
5.2.3.1.4 Assigning Users an Existing Certificate for Single Sign-On with SSL
5.2.3.2 Using X.509 Client Certificates on the AS Java
5.2.3.2.1 Configuring the Use of Client Certificates for Authentication
5.2.3.2.2 Modifying Client Certificate Authentication Options
5.2.3.2.2.1 Using Stored Certificate Mappings
5.2.3.2.2.1.1 Maintaining the User's Certificate Information
5.2.3.2.2.1.2 Maintaining Certificate Mappings Automatically
5.2.3.2.2.2 Using Rules Based on Client Certificate Subject Names
5.2.3.2.2.3 Using Rules Based on Client Certificate V3 Extensions
5.2.3.2.2.4 Defining Rules for Filtering Client Certificates
5.2.3.2.2.5 Using Rules for User Mapping in Client Certificate Login Module
5.2.3.2.3 Using Client Certificates via an Intermediary Server
5.2.3.2.4 Enabling Certificate Revocation
5.2.3.2.4.1 How the Certificate Check Revocation Service Works
5.2.3.2.4.2 Modifying Additional Settings
5.2.3.2.4.3 Checking Certificates Manually
5.2.3.2.4.4 Removing or Updating CRL Cache Entries
5.2.4 Using SAML Browser Artifacts

1 User Authentication and Single Sign-On
Use
User 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 securely
establishing 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 an
already 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.
Integration
User 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.
Features
SAP NetWeaver supports a number of mechanisms to enable user authentication and integration in SSO. SAP NetWeaver Application Server for Java and AS
ABAP 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 the
following sections:
Authentication Concepts
Information about the security aspects that apply when using the authentication mechanisms that are supported by SAP NetWeaver.
Authentication Infrastructure
Information about the underlying ABAP and Java technology stack infrastructure to support the authentication and SSO in SAP NetWeaver.
Integration in Single Sign-On (SSO) Environments
Information about configuring the use of mechanisms for authenticating user access, as well as, their integration in SSO environments.
Developing Authentication Enhancements
Information about enhancing the standard SAP NetWeaver authentication and SSO functions with custom development. You can also find information about
developing custom authentication enhancements for SSO to non-SAP systems.
2 SAP Single Sign-On

For Single Sign-On (SSO) scenarios, we offer the SAP Single Sign-On product (SAP SSO). SAP Single Sign-On centralizes and greatly simplifies the way
users log on to systems and applications in your IT landscape. It includes mobile single sign-on with the SAP Authenticator app, risk-based authentication using
access 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 not
the 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 the
central 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 through
the network 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 name or password. The SNC interface directs calls through the SAP Cryptographic Library to encrypt all communication between
SAP 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 alternative
option is the use of an external identity provider. For more information, see the related link.
Related Information
http://help.sap.com/sso20
SAML 2.0
3 Authentication Concepts
Authentication is an element of information security that enables you to protect the confidentiality, integrity and availability of the information flow, supported by the
information systems in your business operations. With the increasing use of distributed systems based on open standards and flexible information sharing with
multiple 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 allowing
the person or system component access to a SAP NetWeaver server system.
Implementation Considerations
SAP NetWeaver is a component in your system landscape that enables integrated access to use various back-end resources. Therefore, the authentication
process 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 for
authentication in SAP NetWeaver are specific to the communication channel you use to access system data.
Integration
SAP NetWeaver enables you to use a number of user authentication mechanisms. The supported authentication mechanisms also enable you to efficiently
integrate your SAP NetWeaver systems in Single Sign-On environments. When using Single Sign-On you can provide seamless user access to back-end
systems.
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 minimal
development effort. You can, however, use the development capabilities of SAP NetWeaver systems to develop custom enhancements of the standard
authentication mechanisms.
For more information, see Developing Authentication Enhancements .
Features
Conforming to the client-server architecture of the system, the authentication process is negotiated between the client front-end and the back-end SAP NetWeaver
server. 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 Access
Provides information about the available authentication mechanisms for interactive user logon when using the SAPGUI as a front-end client.
Authentication for Web Based Access
Provides information about the available authentication mechanisms for interactive user logon when using HTTP based front-end clients, for example, Web
Dynpro.
Authentication for Web Services
Provides information about the available mechanisms for authenticating Web Service access to SAP NetWeaver systems.
Authentication for Communication between Systems
Provides information about the supported mechanisms for authenticating system specific (non-dialog) communication to and from SAP NetWeaver systems.
3.1 Authentication for SAP GUI
Use
You can use the SAP GUI authentication mechanisms to protect access to your SAP NetWeaver Application Server for ABAP (AS ABAP) systems. When users
access 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 to
authenticate access transparently with Single Sign-On.
The 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 ABAP
systems, 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 that
enable the communication between the SAP GUI and the AS ABAP are SAP-specific.
Integration
To 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 then
evaluates the provided credentials and determines whether to grant or deny access based on the set of preconfigured authentication criteria and the authorizations
assigned 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 SAP
GUI 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 ABAP
system to authorize access.
Note
Depending on the authentication mechanism you use, the authentication credentials can become vulnerable to security attacks during the transfer from
the SAP GUI to the AS ABAP. Therefore, we recommend that you secure communication with additional transport layer security mechanisms.
Features
For more information about the available user authentication functions when using the SAP GUI and relevant implementation considerations, see the following
topics:
User ID and Password Authentication
Information about authentication with user ID and password.
Authentication with SAP shortcuts

Information about authentication aspects when using SAP shortcuts. SAP shortcuts store the authentication information for SAP systems and enable you to
access a specific AS ABAP transaction directly from your desktop.
Client Certificate Logon for SAP GUI
Information about using client certificates for logon with the SAP GUI.
Kerberos for SAP GUI Authentication
Information about using Kerberos for authentication.
Windows NT LAN Manager (NTLM) Authentication with SAP GUI
Information about using Windows NTLM for authentication.
SNC with SAP Single Sign-On Secure Login
Information about integration with SAP Single Sign-On
More Information
SAP Logon in Getting Started
3.1.1 User ID and Password Authentication for SAP GUI
Use
The 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.
The AS ABAP security model requires that all users log on with valid authentication credentials. With user ID and password authentication, users enter their
authentication credentials consisting of user ID, password and an AS ABAP client system.
Note
A 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 logging
on 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 access
protection 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 load
from 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 to
keep passwords secret, your systems can become vulnerable to system engineering attacks, where user's passwords can be guessed or deceitfully acquired
from a user.
Recommendation
For additional security when using user id and password authentication, we recommend that you configure rules for password complexity and require that
users 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 Security
The 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 to
your AS ABAP systems is maintaining the secure storage and transport of entered user passwords. After users provide their passwords, the SAP GUI uses
hashing 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 Checks
After 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 User
Maintenance 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 of
passwords.
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 does
not record the logoff date and time.
Configuration
For information about configuring the security protection mechanisms for user ID and password logon with the SAP GUI, see Logon and Password Security for
SAP GUI.

Use
The 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 secure
authentication 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 bulk
administration of access protection. When using client certificates for authentication, SAP GUI users are logged on to the AS ABAP transparently, without the need
to interactively enter a user ID and a password for system access. In addition, the authentication credentials are protected during their transport over the network
due to the use of public-key technology in X.509 client certificates.
Prerequisites
To use client certificates for authentication, the AS ABAP system must be enabled to use Secure Network Communications (SNC). SNC provides a
Generic Security Services API (GSS API) to use SAP Single Sign-On or an external security product to perform the authentication between the
communication 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 established
PKI then you can use a Trust Center Service to obtain certificates.
For more information about client certificates and PKI, see Public-Key Technology.
Security Considerations
The 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 security
product 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 keys
are stored in a secure location.
Protecting Private Keys
To 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 Solutions
A 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 are
saved 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 (for
example, 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 encrypt
documents. In this case, each user needs to protect his or her smart card from theft or loss.
Caution
We 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 Solutions
As 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 files
from unauthorized access. For example, you can require that the user enters a password for each access request to the private key.
Features
For 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
Use
The authentication mechanisms available for the AS ABAP also enable you to use Kerberos for SAP GUI authentication. You can use Kerberos authentication to
enable 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 weakness
characteristic of more basic authentication mechanisms such as user ID and password authentication.
Prerequisites
To use Kerberos for authentication, your AS ABAP system must be enabled for using Secure Network Communications (SNC) with an external security
provider 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 can
use 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 .

Kerberos employs several systems in your landscape and cryptographic mechanisms for access authentication, thereby overcoming the disadvantages of
weaker authentication mechanisms such as user ID and password. SAP GUI users that are authorized to use Kerberos logon must log on to their local computer
and can subsequently access the AS ABAP from the SAP GUI without the need to interactively provide user IDs and passwords. For more information about the
Kerberos 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 a
Kerberos 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 user
identity 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 the
SAP 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 landscape
this can result in performance lags related to network performance. In addition, Kerberos makes use of several systems in your landscape, which may result in
additional administrative effort and costs.
Configuration
For 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
Use
The SAP GUI also enables you to use NTLM for authenticating access to AS ABAP from the SAP GUI in a Microsoft Windows environment. NTLM authentication
is available for the SAP GUI as a tailored version for SSO with Secure Network Communications (SNC), which uses Microsoft's NT domain authentication and
NT LAN Manager Security Service Provider (NTLM SSP).
Prerequisites
NTLM 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 (no
integrity or privacy protection is provided), you can use Microsoft's NT LAN Manager Security Support Provider (NTLMSSP) from Microsoft as the security
provider.
Note
Microsoft's NTLM SSP does not provide you with the full SNC protection capabilities. To enable data integrity and privacy protection with NTLM, you need to
use an additional security product. We recommend that you use Kerberos for SAP GUI Authentication for system environments consisting of Microsoft
Windows 2000 and higher.
NTLM 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 ensure
data 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 with
SNC.
For more information about the SAP-certified security products, see http://service.sap.com/security .
Configuration
For more information about configuring NTLM authentication, see Single Sign-On with Microsoft NT LAN Manager SSP.
SNC with SAP Single Sign-On Secure Login
Use
SAP 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 solutions
through secure Single Sign-On to the SAP environment.
Note
SAP 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 Secure
Network Communications (SNC). Secure Login support SAP GUI clients such as SAP Logon, SAP Logon Pad, SAP NetWeaver Business Client, SAP Business
Explorer 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 the
network 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 name
or password. The SNC interface can also direct calls through the Secure Login Library to encrypt all communication between the client and SAP server, thus
providing 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 following
advantages:
Kerberos and X.509 authentication separately or in parallel
Flexible level of security: Kerberos, software certificates, 2-factor authentication, one time password (OTP), smart card or smart token integration, PKI
integration

Better integration with existing IT landscapes: Diverse server connectors, integration with SAP Identity Management, user name mapping
More Information
For more information, see SAP Help Portal at http://help.sap.com/nwsso.
3.2 Authentication for Web-Based Access
Purpose
The Web server capabilities of the SAP NetWeaver platform enable you to provide effective solutions to the divergent information requirements posed by the
various 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 varied
information sources. Respectively, to implement an effective and flexible access policy, corresponding to the information requirements of the portal users, SAP
NetWeaver enables you to use a number of options for authenticating Web-based access requests.
SAP NetWeaver Application Server for Java is the underlying technology that enables authentication for portal users. The Web browser acts as a client for the
portal and sends the user credentials that correspond to the configured authentication mechanisms on the AS Java where the portal runs.
Note
For supported Web browser versions, see the SAP NetWeaver Product Availability Matrix (PAM) available from SAPService Marketplace at
service.sap.com/pam
Features
SAP NetWeaver enables you to configure and use a number of authentication mechanisms with varying degrees of complexity and security. You can customize
the 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 Tickets
X.509 Client Certificates
SAML 1.x
SAML 2.0
Kerberos
Header Variables
OAuth 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 a
user 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 NetWeaver

SAP 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 a
base-64 encoded string.
digest - represents an advanced form of basic authentication. For this authentication mechanism, the user credentials are hashed using a message
digest 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 the
URL as URL parameters.
The different methods for Web-based access authentication with a user ID and password enable you to use a simple authentication mechanism that is widely
supported 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 and
rely on the assumption that the connection between the Web client and the server can be trusted. Therefore, for increased security of the access to SAP
NetWeaver systems, you have to use transport layer security mechanisms in combination with the HTTP methods for authenticating users with a user ID and
password.
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.

Note
We recommend that you use a transport layer security mechanism, such as Secure Socket Layer (SSL) or a Virtual Private Network (VPN), when
authenticating 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 your
administrative costs for authentication management in multiple systems. In addition, users have to remember and securely store a large number of authentication
credentials, which can lead to a decrease in the overall security of your SAP NetWeaver systems. The requirements for password secrecy can also expose your
systems to social engineering attacks where user's passwords can be guessed or deceitfully acquired.
Note
For additional security when using authentication with a user ID and password, we recommend that you configure the use of rules for password complexity and
require 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 SAP
NetWeaver systems in a Single Sign-On environment.
Configuration
SAP NetWeaver Application Server (AS) Java and AS ABAP are the underlying technology platforms that SAPsystems use to authenticate user access requests
over HTTP with a user ID and a password. Configuring user ID and password authentication is specific to the underlying technology used by the application
server 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 Tickets

For user authentication to multiple systems, SAP NetWeaver enables you to configure the use of logon tickets. You can use logon tickets to provide and administer
user authentication based on cookie technology for complex system landscapes
For an overview of the authentication process when using logon tickets, see the figure below.
Authentication with Logon Tickets

When 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. The
issuing system uses cryptographic functions to digitally sign the logon ticket, thus certifying its authenticity. Users can then use the logon ticket to access other
systems (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 logon
ticket based on its trust relationship with the issuing system.

Prerequisites
AS 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 release
requirements:
Release 4.6A/B: 4.6D kernel as of patch level 74
Release 4.5: 4.5B kernel as of patch level 459
Release 4.0: 4.0B kernel as of patch level 758
For more information, see SAP Note 177895.
When 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 cookie
contains the public information necessary to authenticate the user to additional systems without the need to interactively provide a password. The information
contained 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 various
systems. For more information, see Accessing Back-End Systems with a Different User ID .
Validity period
Issuing system
Digital 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 own
digital 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 issuing
server is located, for example to all servers registered in the domain mycompany.com.
Caution
To 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.
Configuration
For more information about configuring SAP NetWeaver systems to use logon tickets for authentication, see Using Logon Tickets .
3.2.3 X.509 Client Certificates

As an alternative to authenticating with a user ID and passwords, users can present X.509 client certificates for accessing Web applications. In this case, user
authentication 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.

X.509 Certificate Authentication Flow
Authentication with X.509 Certificates makes use of a Public Key Infrastructure (PKI) to securely authenticate users. After users receive their X.509 certificates
from a certificate issuing Certification Authority (CA), they can use them to securely access SAP NetWeaver, as well as non-SAP systems. The SAP NetWeaver
and 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, you
can use certificates for authentication in open environments such as the Internet.
Note
SAP 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 .
Prerequisites
You 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.
X.509 certificates use industry standard cryptographic mechanisms to securely authenticate user access. The exchange of the authentication credentials
between 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 SSL
protocol. For additional security, you can also enable mutual authentication, where both the front-end client and the back-end application server exchange X.509
certificates 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 users
yourself, 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 NetWeaver
system.
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 is
contained 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 a
password 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 a
password.
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 on
the Web front-end client is protected by the operating system.
Note
We 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 (for
example, Windows 95).
Configuration
For more information about enabling authentication with X.509 client certificates, see Using X.509 client certificates .
3.2.4 SAML 1.x
Use
SAP 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 encoding
security-related information (assertions) into XML and exchanging this information in a request/response fashion.
The figure below illustrates the authentication process when using SAML.

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. SAML
authorities produce assertions in response to client requests. An assertion can be either an authentication or an authorization assertion, with the following
respective functions:
Authentication assertion: a piece of data that represents an act of authentication performed on a subject (user) by the authority
Authorization 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 the
AS Java and the AS ABAP can act as SAML destination sites.
Constraints
The 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 the
Conditions 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.
SAML is a standard for encoding authentication information that relies for message exchange on standard security protocols like SSL and TLS use XML
signatures. Therefore, to protect the data exchange, SSL is required for the connection between the source and destination sites.
Note
SSL is required by the SAML specification, and therefore its use is enforced by default in the SAML configuration. However, for testing purposes, you can
disable 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 network
performance, and affect the availability of the systems enabled to authenticate access with SAML.
Configuration
For more information about configuring the use of SAML 1 for SAP NetWeaver systems, see Using SAML Assertions .
3.2.5 SAML 2.0
Use
The Security Assertion Markup Language (SAML) version 2.0 is a standard for the communication of assertions about principals, typically users. The assertion
can 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.0
SAML provides a standard for cross-domain Single Sign-On (SSO). Other methods exist for enabling cross domain SSO, but they require proprietary
solutions to pass 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.
SLO with SAML 2.0

Single Log-Out (SLO) enables users to cleanly close all their sessions in a SAML landscape, even across domains. Not only does this save system
resources that would otherwise remain reserved until the sessions time out, but SLO also mitigates the risk of the hijacking of unattended sessions.
Identity federation
Identity 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 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 of
Web applications with a common session management, identity management, and trust management. The identity provider is a system entity that manages
identity information for principals and provides authentication services to other trusted service providers. In other words, the service providers outsource the job of
authenticating the user to the identity provider. The identity provider maintains the list of service providers where the user is logged in and passes on logout
requests to those service providers.
The client that is trying to access the resource must be HTTP-compliant.
Prerequisites
You have a SAML 2.0 identity provider in your landscape.
Constraints
The SAP NetWeaver Application Server (AS) Java 7.2 service provider supports SP lite as defined in Conformance Requirements for the OASIS Security
Assertion Markup Language (SAML) V2.0
For 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 Information
For information about implementing SAML 2.0 with SAP NetWeaver, see Using SAML 2.0 .
3.2.5.1 SSO with SAML 2.0
Use
SAML provides a standard for cross-domain Single Sign-On (SSO). Other methods exist for enabling cross domain SSO, but they require proprietary solutions to
pass 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 you
protect resources with SAML on a service provider, the service provider is configured to request authentication from the identity provider.
Process
SAML provides options to pass SAML messages back and forth between the identity provider and the service provider.
Front channel
SAML messages are passed back and forth over the user agent with HTTP redirect or HTTP POST methods.
Back channel
Only SAML artifacts are exchanged over the user agent by the identity provider and service provider. When a provider receives an artifact, it queries the
other 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 and
digital signatures. You can mix the communication options.
Front-Channel Communication
The following figure illustrates service-provider-initiated SSO with front-channel communication.

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 Communication
The 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
Use
Use
Single Log-Out (SLO) enables users to cleanly close all their sessions in a SAML landscape, even across domains. Not only does this save system resources
that would otherwise remain reserved until the sessions time out, and SLO also mitigates the risk of the hijacking of unattended sessions.
Process
SAML provides a number of binding options to pass SAML messages back and forth between the identity provider and the service provider.
Front channel
For front-channel communication, SAML messages are passed back and forth over the user agent with HTTP redirect or HTTP POST methods.
Back channel
For back-channel communication, the identity provider and service provider can use either SAML artifacts or communicate directly over SOAP. For SAML
artifacts, the identity provider and service provider exchange SAML artifacts over the user agent. When a provider receives an artifact, it queries the other
provider directly over SOAP to resolve the artifact. For the SOAP binding, the providers pass no artifacts. They exchange SAML messages directly over
SOAP.
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 and
digital 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 the
other 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 Information
HTTP Sessions and Security Sessions on the AS Java
3.2.5.3 Identity Federation
Use
Identity 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 a
common 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.

Name ID Format Description
E-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 a
service provider or an affiliation of service providers.
Transient The name ID is a temporary opaque string generated by the identity provider for a service
provider for the lifetime of a security session.
Unspecified The implementation of this name ID is vendor-specific. SAP assumes this value to be
either a user ID, a logon alias, or another attribute value depending on your technology
stack.
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.
Types of Federation
SAML describes the following types of federation:
Out-of-band account linking
Transient pseudonym identifiers
Persistent pseudonym identifiers
Out-of-Band Account Linking
The 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 of
agreement 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 the
identity provider maps to the user in the service provider.
Example
Users 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 provider
agrees to provide the Unspecified name ID format including the logon ID. After a user successfully logs on to the identity provider, whether by Kerberos
name 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 provider
is 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 searches
for 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 identity
provider. 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 two
accounts 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

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 federation
only 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 Identifiers
Federation 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 an
affiliation 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 ID
for 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 your
systems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses. It requires you to
establish the pseudonym on both providers ahead of time.
Federation with persistent name IDs also offers the following additional options:
Interactive federation
Federation 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 to
configure these mappings as you go.
Automatic creation
Federation is established on the basis of attributes passed to the target system. If the user has no account in the target system, the service provider
automatically 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.
Note
The AS ABAP does not support automatic creation.
Example
The 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 be
agreed upon in advance by the two system administrators or generated by the identity provider and distributed to the service provider. When Laurent Becker
authenticates on the identity provider, the service provider receives the SAML assertion with the opaque ID as the subject. The service provider searches for
the user based on the opaque ID and logs the user on.
Figure 2: Account Linking with Persistent Name ID
Securing Data
You 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 service
provider). 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
Use
Use
The Security Assertion Markup Language (SAML) 2.0 service provider uses common domain cookies (CDC) to determine to which identity provider the service
provider 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 the
service provider. Identity providers identify themselves to a service provider by writing their alias into the CDC. The service provider of SAP NetWeaver
Application Server reads the alias from the CDC. This service provider includes an internal read service for identity provider discovery. It can also use an external
read service. When enabled, these services read CDCs to help the service provider determine which identity provider to use. When to use the external and
internal 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 .
Example
Common Domain is the Shared Domain
The 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 shared
domain 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 Domain

The figure below illustrates a service provider and an identity provider in two different domains. The operators of both providers have agreed on a common domain
for 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 the
common 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 the
CDC.
Figure 2: Service Provider and Identity Provider Reside in Different Domains and Access Common Domain Cookie in Common Domain

3.2.6 Kerberos Authentication
Use
Kerberos is an authentication protocol developed by the Massachusetts Institute of Technology. Kerberos allows individuals communicating over an insecure
network to prove their identity to one another in a secure manner. Kerberos authentication can be used to overcome weak points such as eavesdropping and
replay 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 the
basis of tickets, which serve to prove the authenticity of client requests. Kerberos authentication makes use of a trusted third party system called Key Distribution
Center (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 and
to 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 KDC
generates a session key for communication between the client and the application server, which they can use to secure their interactions.
While Kerberos can overcome the vulnerabilities of other Web-based authentication mechanisms, the Kerberos configuration and administration can result in a
relatively high administrative effort. In addition, Kerberos relies on authentication infrastructure, such as a Key Distribution Center, that enforces a Mandatory
Access Control approach to authentication. Therefore, the use of Kerberos in open environments such as the Internet can increase the administrative load
associated 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 Microsoft
Developer Network (MSDN) at http://msdn.microsoft.com. .
Integration
SAP 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 Information
Kerberos and SAP NetWeaver AS for Java
Using Kerberos Authentication on SAP NetWeaver AS for Java
For more information about SAP Single Sign-On, see http://help.sap.com nwsso
3.2.7 Header Variables
Use
SAP NetWeaver Application Server (AS) Java supports the use of header variables for authentication and Single Sign-On (SSO). With header variables, you can
use a third-party Web access management (WAM) product to authenticate your users. The WAM product returns an authenticated user ID as part of the HTTP
header. 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

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 to
authenticate 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 use
authentication mechanisms that are not directly used by the AS Java, such as token cards or biometrics.
Prerequisites
To use a third-party product with the header variable login module for authentication, you must use an external intermediary server for access to the AS
Java. 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.
Attackers 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 the
following:
Using appropriate measures, make sure that the HTTP and HTTPS ports of the AS Java cannot be directly accessed by client Web browsers, for example
by using firewalls. Users should only access the AS Java through its intermediary server. This prevents attackers from bypassing the intermediary server
and 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 between
the 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 a
trusted 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 trusted
root 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 an
Intermediary 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 logon
screen 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, redirect
users to a screen other than the default logon screen at logoff.
For more information, see the portal documentation.
Configuration
The 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 or
templates of the applications to use header variable authentication.
For more information, see Using Header Variables .
3.2.8 OAuth 2.0 Introduction and Concept
Concept
OAuth 2.0 is an open authorization framework based on an IETF specification. It was originally developed for social networks, but it evolved to become an
authorization concept for the cloud and business-to-business integration. In the cloud, people use services from different service providers. As software vendors
are moving their products to the cloud with offerings such as SAP Business ByDesign or cloud office services, more and more business users need to access
resources 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 the
resources 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 located
are 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 resource
owner by orchestrating an approval interaction between the resource owner and the resource, or by allowing the third-party application to obtain access on its own
behalf.
The interface to the OAuth 2.0 client is a REST API.
More Information
For more information, see the Web site of the Internet Engineering Task Force (IETF). See also Business Example for Accessing Resources with OAuth 2.0 and
OAuth 2.0 Scopes.
3.2.8.1 OAuth 2.0 Server with AS ABAP

An 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.
Restriction
SAP 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

OAuth 2.0 Flows Supported by SAP
3.2.8.2 OAuth 2.0 Scopes
Definition
To 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 of
resources that can be accessed by remote applications. Developers of the OAuth 2.0 enabled services predefine scopes. They are delivered together with a
framework 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 the
number 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 to
protect the service.
More Information
For 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
Definition
OData (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 in
applications today. Since OData applies Web technologies, it enables you to access information from a variety of applications, services, and stores and thus
assures interoperability across a broad range of clients, servers, services, and tools. OData is being used to expose and access information from a variety of
sources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites. It uses URIs to identify resources
and uses an HTTP-based uniform interface for interacting with those resources.
More Information
For more information, see the Web sites of the Open Data Protocol.
3.2.8.4 Resource
Definition
A 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 application
in 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 Information
For more information, see SAP NetWeaver Gateway SAP NetWeaver Gateway Cookbooks and OAuth 2.0 Scopes.
3.2.8.5 Resource Owner in OAuth 2.0

Resource 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.
Definition
They make resources (see Resource) available for other users by delegating their scopes to OAuth 2.0 enables client applications. These applications use an
OAuth 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 can
freely decide which applications can access which business resources by assigning them to the business resources.
Integration
A 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) that
has 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

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 respective
resource.
More Information
OAuth 2.0 Scopes
Setting Up an OAuth 2.0 Client
Business Example for Accessing Resources with OAuth 2.0
3.2.8.6 OAuth 2.0 Token Context Revocation
Use
You 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 these
users no longer need to access those resources. You therefore want to revoke the access tokens of these users. Either the resource owner or an administrator
performs 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 SAML
bearer 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. The
following 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:
User User who issued the access token
Type Type of access token, for example, authorization code
Creation date Creation date of the access token
Creation time Creation time of the access token
Expiration date Expiration date of the access token
Expiration time Expiration time of the access token
Scopes OAuth 2.0 scopes with a link with which you can display the scopes assigned to the
selected token context
OAuth 2.0 Scope ID OAuth 2.0 scope ID granted by the resource owner
OAuth 2.0 Scope Description Description entered by the resource owner. This should list the resources.
More Information
For 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
Integration
There 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:
Scenario Authentication Method Recommended Flow
Server-to-server communication: A user authenticates at a SAML 2.0 on behalf of the user SAML 2.0 Bearer Assertion Flow for OAuth 2.0
web application. The web application needs to access
resources from an OAuth 2.0-enabled back-end on behalf
of the user.
Loosely integrated communication between web All resource owner authentication methods supported by Authorization Code Flow for OAuth 2.0
applications. No trust for Single Sign-On needs to be an AS ABAP, for example, user name and password. For
established between the web application and the AS ABAP more information, see Standard Logon Order.
system hosting the protected resources. The user gives
consent to grant access to a certain set of resources.
3.2.8.7.1 SAML 2.0 Bearer Assertion Flow for OAuth 2.0
Prerequisites
There 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-

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.
Procedure
You 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 (for
example 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 a
cloud 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 authenticate
at the cloud or Web-based application and get the authorization to access the respective resources. The OAuth 2.0 client handles the entire authentication and
authorization 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 contains the user information of the resource
owner and has a digital signature from the identity provider.
2. The cloud or Web-based application requests an access token from the authorization server. The access token request contains the following:
OAuth 2.0 client ID (corresponds to the AS ABAP user name for the application that requests access to the resources)
SAML 2.0 bearer assertion received from the identity provider
List of OAuth 2.0 scopes for the requested resources
The following is an example of an access token:
POST /sap/bc/sec/oauth2/token HTTP/1.1
Authorization: Basic ...=
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Host: host.example.com:443
Content-Length: 3947
Connection: Keep-Alive
client_id=OA2_TEST&scope=OAUTH2_TEST_SCOPE1&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=PEFzc2VydGlvbiB
3. In exchange for the SAML 2.0 bearer assertion, the authorization server issues an OAuth 2.0 access token after having checked the client credentials, the

trust relationship with the SAML 2.0 identity provider, and the authorization of the client and the resource owner for the requested scopes. The server
response contains the following elements:
Access token
List of granted OAuth 2.0 scopes for the requested resources. This list may contain less entries if the OAuth 2.0 client or the resource owner is not
allowed to access the full list of requested scopes.
Lifetime of the access token
The following is an example of a SAML 2.0 bearer assertion:
<Assertion ID="_ba59ce78-478a-4e81-ba59-4e8cb6ec4644" IssueInstant="2012-01-04T12:03:21.852Z" Version="2.0" xmlns="urn:oas
<Issuer>TEST_CLIENT</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_ba59ce78-478a-4e81-ba59-4e8cb6ec4644">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>a+W4gwTA3TsjFu/4Ay3q2T9tcuQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>sfg0LT2Pb2kFD9lW5WKCC8bbhTf1j3YHWvF5HcM5jFT0ZW7aI0KKfjT9QQqytd7UkCKNwU1LX++eeCeWTyhTJjD
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>...=</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID>SOKOLOVA</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2012-01-04T20:03:21.868Z" Recipient="https://host.example.c
</SubjectConfirmation>
</Subject>
<Conditions>
<AudienceRestriction>
<Audience>OAT_000</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2012-01-04T12:03:21.870Z">
<AuthnContext>
<AuthnContextClassRef>urn:none</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
4. The authorization server stores the client ID, the resource owner, and the granted scopes in the internal OAuth 2.0 server context store.
5. To access a requested resource, the client embeds the access token (such as authorization: bearer 4711 ...) into an authorization header and
forwards it with the resource request to the resource server.
6. The resource server checks the following:
OAuth 2.0 client ID
Scope assigned to the OAuth 2.0 client
Validity of the access token
Lifetime of the access token
Scope covered by the access token
Validity of the SAML 2.0 bearer assertion in the OAuth 2.0 server context store
Authorization for the scopes make available by the resource owner
7. The resource server grants access to the requested resource if it is covered by one of the scopes assigned to the access token.
Result
Using the OAuth 2.0 client you need not share credentials and you can access permitted resources with restricted authorizations.
More Information
Business Example for Accessing Resources with OAuth 2.0
SAP Note 1688545
Configuring OAuth 2.0
3.2.8.7.1.1 Business Example for Accessing Resources with

OAuth 2.0 Using a SAML Bearer Assertion

Use
In a business setup, you want to limit access so that user can access only specific resources. In OAuth 2.0, you can defined access permissions depending on
the user, the application, and the OAuth 2.0 scope.
Prerequisites
You have registered your OAuth 2.0 client at the OAuth 2.0 authorization server.
The client must know the token endpoint.
The resource owner has configured the client so that it knows the resources it wants to access and the scopes to which they belong.
The user must be allowed to delegate access to these scopes to the respective OAuth 2.0 client.
Example
In a sales environment, salespersons access an application in the AS ABAP that enables them to create invoices for business partners in their sales region.
When working on the invoices, these salespersons should not be able to access or change business partner master data of another sales region. For this reason,
the resource owner restricts the access to the resources by setting up different OAuth 2.0 clients and scopes for salespersons of different sales regions.
You are working as a regional salesperson in the cloud application, and this application needs to retrieve project data (resources: for example invoices, contract
data, and business partner master data) from an AS ABAP back-end system. You do not want to directly authenticate at the AS ABAP, but instead want to use
OAuth 2.0 access acting on behalf of yourself.
The cloud application accesses SAP NetWeaver Gateway using the OData protocol. SAP NetWeaver Gateway uses the OAuth 2.0 server role. Your OAuth 2.0
scope contains the resources A (invoices), B (contract data), and C (business partner master data). This data, which you need to work with frequently, is restricted
to your sales region.
You use an OAuth 2.0 client to enable the cloud application to access the resources. You give the client a name that indicates the cloud application that uses it
(for example, OA2_ClApp. This client is used to request an access token, to authenticate, and to transmit your scope (resources A (invoices), B (contract data),
and C (business partner master data)) to the authorization server in the AS ABAP.
During authentication, an identity provider requests and gets an access token (in this case a SAML 2.0 bearer assertion) from the authorization server. The
authorization server sends the SAML 2.0 bearer assertion to the resource server. The resource server checks whether you are authorized to access the resources
A (invoices), B (contract data), and C (business partner master data) with OAuth 2.0. If this is the case, the AS ABAP back-end approves your request and
makes the resources A (invoices), B (contract data), and C (business partner master data) for your sales region available.
Note
Both, the authorization server and the resource server reside in the AS ABAP although they are separate components.
More Information
3.2.8.7.2 Authorization Code Flow for OAuth 2.0

This topic gives you an overview of the OAuth 2.0 grant type authorization code flow for accessing resources in the OAuth 2.0 server.
Prerequisites
If you want to use the authorization code flow for OAuth 2.0, you must make sure that the following prerequisites are fulfilled:
The OAuth 2.0 resource owner is a user of type Dialog in the AS ABAP.
The resource owner has the necessary authorizations to access the protected resources to be accessed by an OAuth 2.0 client.
During the registration of the OAuth 2.0 client, you have assigned OAuth 2.0 scopes in Scope Assignment .
You have authorized the resource owner to delegate access to an OAuth 2.0 client.
The OAuth 2.0 client must be identical to a user of type System.
You have activated the grant type authorization code in the OAuth 2.0 client registration.
You have registered an endpoint of your OAuth 2.0 client web application as a redirection URI in the OAuth 2.0 client registration.
You have installed an application that supports OData on AS ABAP, such as SAP NetWeaver Gateway.
For more information, see SAP Note 1688545 and Configuring OAuth 2.0.
Procedure
You want to allow a browser-based web application that acts as an OAuth 2.0 client to access a selection of protected resources hosted on an AS ABAP. The
web application itself can either be hosted on-premise or in the cloud. OAuth 2.0 allows resource owners to delegate a subset of their permissions to an OAuth
2.0 client without sharing their credentials (such as user name and password). The client can then access the resources on behalf of the resource owner.
To allow access to the resources, the OAuth 2.0 client and the authorization server interact to authenticate the resource owner and delegate the necessary
authorizations to the OAuth 2.0 client within the authorization code flow.

Figure 1: OAuth 2.0 Grant Type: Authorization Code
1. The resource owner makes a call to protected resources using the OAuth 2.0 client.
2. The OAuth 2.0 client has no access token for the target system and redirects the browser to the authorization endpoint of the authorization server. This
redirection is called authorization code request. At the authorization server, the resource owner is authenticated and can further restrict access or simply
grant access to the preselected scopes.
3. The authorization server sends the authorization code back to the OAuth 2.0 client by redirecting the resource owner's user agent back to the redirection URI
(that was defined during OAuth 2.0 client registration).
4. The OAuth 2.0 client sends an access token request to the authorization server's token endpoint. This access token request contains the authorization code.
5. The authorization server receives the access token request at its token endpoint and validates the authorization code. After a successful validation, the
authorization server returns an access token to the OAuth 2.0 client.
6. The OAuth 2.0 client uses the access token to request resources.
7. The resource server grants the OAuth 2.0 client access to protected resources in accordance with the access token.
Result
Using the OAuth 2.0 client, you do not need to share credentials and you can access permitted resources with restricted authorizations.
More Information
Business Example for Accessing Resources with OAuth 2.0 Using Au
SAP Note 1688545
3.2.8.7.2.1 Business Example for Accessing Resources with

OAuth 2.0 Using an Authorization Code
Use
In a business setup, you may want to grant access to only specific resources. In OAuth 2.0, access permissions can be defined depending on the user, the
application, and the OAuth 2.0 scope.
Prerequisites
You registered your OAuth 2.0 client at the OAuth 2.0 authorization server.
The client must know the token endpoint.
The resource owner has configured the client so that it knows the resources it wants to access and the scopes to which they belong.
The user must be allowed to delegate access to these scopes to the respective OAuth 2.0 client.
Example
A resource owner wants to grant a printing service access to protected photos stored at a photo-sharing service (resource server) without sharing his or her user
name and password with the printing service. The resource owner uses a browser as a user agent and wants to access his or her resources on the resource

server, for example, an SAP NetWeaver Application Server for ABAP. The browser sends an authorization code request to the authorization server. The
authorization server authenticates the resource owner and issues an authorization code representing the selected set of OAuth 2.0 scopes to the OAuth 2.0 client.
The OAuth 2.0 client receives the authorization code and sends an access token request, which includes the authorization code, to the authorization server. The
authorization server receives the access token request at its token endpoint and validates it. If the validation of the authorization code is successful, it issues an
access token. Finally, the resource owner can use this access token to access the protected resource and grant access to the printing service.
Note
Both, the authorization server and the resource server reside in the AS ABAP although they are separate components.
More Information
3.3 Authentication for Web Services
Use
With Web services, you can operate standards-based communication between systems that is independent of the technology platform. A Web service (WS) is a
standalone, modular function that can be published and located, and which can be accessed over a network using open standards. For a caller or sender, a Web
service is a "black box" that requires input and delivers a result.
You can use authentication nd security for consuming and providing Web services either at HTTP transport level or at SOAP message level. To do this, you can
use standard HTTP authentication mechanisms, such as HTTP standard authentication with user ID and password, and standard WS mechanisms to allow
authentication at the higher SOAP message level. Authentication at SOAP message level is suited to the specific authentication requirements for WS access and
allows you to use strong SOAP message authentication mechanisms, such as XML signatures, for incoming and outgoing WS connections.
The AS ABAP and AS Java WS frameworks allow you to use authentication mechanisms that are based on the WS-Security standard produced by the
Organization for the Advancement of Structured Information Standards (OASIS). You can configure the use of authentication for consuming and providing Web
services at the HTTP transport level and the SOAP message level for the SAP NetWeaver application platform.
The figure shows that the solutions for authentication and Single Sign-On supported by SAP provide secure access with the following levels of security:
Authenticate a hard-coded service user for access to a service
A hard-coded service user and its password are set up in the consumer. The provider authenticates the user ID of the service user for access to the service
application. The security of this approach is low and the user ID and data are not protected while they are transported over the network, meaning that they
could easily be captured and used to cause damage. The security risk for the provider is also increased by the fact that the service user requires
authorizations. Its authorization profiles and roles must be sufficiently extensive to meet the requirements of all of the users who use this service user on the
consumer side.
Authenticate a consumer application with a client certificate
For reasons of scalability, with this approach you can use the same client certificate to authenticate all service applications of the consumer of an
application server, where the System-key key pair of the application server is used. This approach provides more security and functions when sending
the encrypted authentication data and the message over the network. This approach is based on asymmetrical cryptographic key pairs and the trust
relationship between the consumer and the provider.
Propagate a user ID of a user authenticated by the consumer
This approach offers a high level of security. The provider can permit a user call of a service on the basis of an identity of a user authenticated by the
consumer. The consumer wraps this identity, for example, in a SAML ticket, signs the ticket, and sends it to the provider. The provider checks the token
signature to determine whether it comes from a trustworthy partner. It then unpacks the ID contained in the token and permits the execution of service
functions by this user. In this way, the user ID was propagated from the consumer to the provider. This approach also allows the user's activities to be
logged in a way assigned to the user (auditability). SAP NetWeaver supports the SAML token profile and therefore offers interoperability with and the use of
service applications with non-SAP applications. The authentication data is propagated in a format with built-in protection of integrity. You can also use the
confidentiality protection of the underlying transport protocol or work with XML encryption at SOAP level.

To use a Web service, a WS consumer initiates a transaction with a WS provider using the Simple Object Access Protocol (SOAP). The WS consumer can be a
system that is configured to consume a specific Web service of the WS provider. The SOAP transaction request can be made over the Internet using the HTTP
protocol.
When authenticating at HTTP transport level, the authentication data is transported in the HTTP header for the WS message. If you use this transport level for
authentication, you can use a number of authentication and SSO mechanisms that are supported for Web-based access, such as logon tickets, for WS
authentication. With AS ABAP and AS Java, you can also use authentication at HTTP level with user name and password and SSO with X.509 certificates, for
which the configured mechanisms use the corresponding authentication infrastructures for Web-based access.
However, Web Service messages can be passed through any number of connections and, potentially, a large number of intermediary systems. Point-to-point or
connection-oriented authentication at the HTTP transport level might be insufficient or inappropriate for supporting this decoupled interaction.
SAP NetWeaver therefore also allows you to use authentication at SOAP message level or at document level, where the authentication data is transported in the
SOAP header of the WS message. The authentication mechanisms supported by SAP NetWeaver at document level are based on the WS-Security standard and
allow you to use WS authentication and SSO in accordance with the specific security requirements for WS connections.
Features
You can use the configuration tools of the underlying SAP NetWeaver technology stacks to configure the use of supported mechanisms for WS authentication.
These available configuration options allow you to use authentication to provide and consume Web services both at HTTP transport level and at SOAP document
level.
More information about relevant security aspects of using supported WS authentication mechanisms:
Authentication at HTTP Transport Level
Authentication at SOAP Document Level
Configuration
More information about configuring the use of WS authentication for SAP NetWeaver components: Single Sign-On for Web Services .
More Information
Recommended WS Security Scenarios
3.3.1 Authentication at HTTP Transport Level
Use
If you use authentication at HTTP transport level for Web services, the authentication data is contained in the HTTP header. With this approach, the authentication
mechanisms for consuming and providing WS for SAP NetWeaver components are based on the authentication infrastructure for Web-based access over HTTP.
Security Aspects
Authentication at HTTP transport level allows you to use point-to-point security and authentication that was designed for the client/server connection pattern for
Web-based access over the HTTP connection protocol. Authentication at HTTP transport level for SAP NetWeaver uses the same connection channel for the
access and authentication infrastructure as for Web-based access, and similar security aspects therefore also apply.
More information about the security aspects for the correpsonding Web-based authentication mechanisms is available in the following sections about
authentication for Web-based access:
Standard Authentication (User ID and Password)
X.509 Certificates
Logon Tickets
Features
The table below provides an overview of the authentication and SSO mechanisms that you can use for authentication at HTTP transport level for providing and
consuming Web services on the AS ABAP and AS Java.
AS ABAP AS Java
User name/password X X
X.509 Certificate X X
Logon Ticket X X
Configuring the Use of Authentication at HTTP Transport Level

More information about the runtime configuration options with which you activate the use of authentication at HTTP transport level and SSO mechanisms for
providing and consuming Web services:
Configuration Examples for AS ABAP
Configuration Examples for AS Java
More Information

Use
With authentication at SOAP message level, the WS authentication data is transported with token profiles in the SOAP message header. With this approach, the
authentication takes place at SOAP level, which allows the customizing of authentication and Single Sign-On (SSO) to meet the specific security requirements for
Web services.
The mechanisms supported by SAP NetWeaver for authentication at SOAP message level and SSO are based ont he WS-Security standard. The WS-Security
standard describes the standard XML syntax with which authenticaiton data is included in the SOAP header, and allows the interoperability of security between
WS-supported systems that are based on different programming languages.
Security Aspects
With authentication at SOAP message level, you can use end-to-end authentication that is adjusted to the security requirements of the WS communication. With
SAP NetWeaver, you can use multiple types of WS authentication mechanisms at document level and strong message authentication options based on WS-
Security, such as XML signatures, XML encryption, SOAP message age, and error reports.
Authentication at message level is customized to the specific security requirements for Web services, which only require the protection of some of the
security aspects during the authentication and SSO process. The use of XML signatures allows you, for example, to permit access to SOAP messages for
intermediary WS systems and therefore to ensure integrity, that is, to ensure that the message is not modified during its transfer.
Authentication at message level on its own does not offer a point-to-point solution to protect the overall security of the WS interactions between systems.
However, the reliability of SOAP messages at the lower level of the HTTP connection protocol allows you to extend the security at SOAP level with security
solutions at HTTP transport level. You can, for example, use HTTPS as a protected connection channel that uses the SSL security level for transport level
security.
More Information
3.3.2.1 SAML Token Profile
Use
Security Assertion Markup Language (SAML) is a standard that defines a language to exchange security information between partners. The SAML standard is
driven by the Organization for the Advancement of Structured Information Standards (OASIS). SAML uses assertions that contain statements about a subject,
authentication, authorization and attributes.
SAML Token Profile is developed by the OASIS Web Services Security (WS Security) Technical Committee as a standard to integrate and use SAML for Web
Services Security.
Although the SAML token profile, SAML browser artifact, and SAML 2.0 all use the SAML standard for transferring security information, they are used for different
authentication purposes, as described below:
SAML token profiles are used for WS access authentication at the SOAP message level.
More information: Configuring Single Sign-On with SAML Token Profiles .
SAML 2.0 and SAML browser artifacts are used for authenticating Web-based access from a Web browser.
More information: Using SAML 2.0 and Using SAML Browser Artifacts .
More Information
Configuring SAML Holder-of-Key with Symmetric Connection Creation (AS ABAP)
Configuring SAML Sender-Vouches and WS-SecureConversation (Asymmetric Connection Creation) (AS ABAP)
STS Scenario with Asymmetric Consumer Key for Confirming Signature (Authentication Only)
STS Scenario with Symmetric Key for Message Protection (Signature, Encryption, and Authentication)
STS Scenario with Symmetric Key for Confirming Signature (Authentication Only)
3.3.2.2 WS Security UsernameToken
Use
The UsernameToken is a security token that is defined in the WS Security standard. It is a mechanisms with which the user ID and password can be transported
within a SOAP message.
If you are using UsernameTokens, an element SOAP:Envelope/SOAP:Header/wsse:Security/wsse:Username is added to the message, which
contains a time stamp, a user name, and a password.
AS Java also supports password hash values. In this case, an SHA-1 hash value of the base64-encrypted password is calculated and added to the password
element.
More Information
Configuring Message Authentication with Username Token Profiles (AS Java)

The open architecture of SAP NetWeaver technology platform enables you to use communication destinations for various other systems to perform frequent tasks
or functions. For such cases, you can configure SAP NetWeaver systems to perform authentication in the background without interactively choosing authentication
credentials.
Communication for such tasks, and respectively the transfer of the security credentials, can be performed over SAP-specific protocols such as RFC, over the
HTTP communication protocol, or SOAP used for Web Service-based communication. You can protect your SAP NetWeaver systems against unauthorized
access by enabling the use of authentication with system users.
To facilitate administration, the AS Java and AS ABAP technology stacks enable you to use centralized administration of the security options for system-specific
communication. The configuration options are technology stack-specific:
For the AS ABAP you configure the authentication options for communication destinations using the configuration transaction for maintaining system
destinations. ( SM59 ).
For the AS Java, you can configure the authentication options for communication destinations using the destination management functions of SAP
NetWeaver Administrator.
SAP NetWeaver enables you to use several options for authenticating user access, for example with a system user ID and password or with assertion tickets.
The security aspects of the authentication process are similar to the security aspects involved in using the corresponding authentication mechanisms for the other
access channels to SAP NetWeaver with the following specifics:
For user ID and password authentication, you can use any SAP NetWeaver user ID for the system-specific logon. For additional security, however, we
recommend that you configure the use of system-specific users that cannot be used to log on to the SAP NetWeaver system interactively. The creation of
such users is system-specific.
For more information, see Identity Management .
Using the configuration functions for system-specific configuration, you can establish uni- or bi-directional trust between systems that commonly interact with
each other. The trust relationship between the communicating systems is based on public-key technology and involves storing in specially designated key
stores public certificates for trusted systems.
The corresponding SAP NetWeaver technology stack can then use the stored certificates to encrypt communication or to accept authentication credentials,
for example assertion tickets that are protected with signatures. Establishing trust relationships between frequently communicating systems enables you to
reduce the administrative load for configuring multiple systems in complex system landscapes, while protecting the communication with cryptographic
mechanisms.
For more information, see:
Public-Key Technology
Maintaining Trust Relationships between SAP Systems
Configuration
Configuring SSO for system destinations is specific to the SAP NetWeaver technology stack that you use.
For more information, see Single Sign-Onfor Interaction between Systems .
3.4.1 Authentication Assertion Tickets
Use
Authentication assertion tickets are a form of bearer token used by SAP NetWeaver Application Server (AS) to identify a user to another SAP NetWeaver AS.
SAP NetWeaver AS issues the assertion ticket on the behalf of the current user. SAP NetWeaver AS issues assertion tickets for all user types.
Example
A batch job triggers a Web service that calls another SAP NetWeaver AS. SAP NetWeaver AS issues an assertion ticket on the behalf of a user, Giovanni
Ricci, and logs on to the second SAP NetWeaver AS in Giovannis name.
The figure below illustrates two systems, System A and System B, in a use case for assertion tickets. System A requests a resource from System B and issues
an assertion ticket for the current user. System B reads the assertion ticket from the HTTP header to log the current user on. It does this assuming the assertion
ticket is still valid and assuming System B trusts System A.
Figure 1: Architecture of Assertion Ticket Usage Scenario
Assertion tickets are carried in the HTTP header. They differ from logon tickets in the following ways:
Logon tickets are used for user-to-system communication, whereas assertion tickets are used for system-to-system communication.

Logon tickets are transmitted as cookies, whereas assertion tickets are transported as HTTP headers.
Validity of logon tickets is configurable, whereas the validity of assertion tickets is hard-coded (2 minutes).
Logon tickets never identify a recipient, as they target multiple systems. Assertion tickets are always issued for a single recipient.
Re-Entry Scenario
SAP NetWeaver AS issues a authentication assertion ticket for itself to enable users logged on with one front end to call the same application server in another
front end, albeit with a new session. In this scenario, you do not need to configure trust as SAP NetWeaver AS trusts itself implicitly.
Example
Giovanni Ricci is using SAP GUI to access an AS ABAP. The application calls an interactive Web application. Rather than force Giovanni to log on again,
the AS ABAP issues an assertion ticket with the AS ABAP as the issuer and recipient, enabling Giovanni to log on with Single Sign-On.
This ticket contains the public information necessary to authenticate the user to additional systems without the need to interactively provide a password. The
information contained in the assertion ticket includes:
User ID
The UTC creation date
Issuing system, identified by SID and client ID
Receiving system, identified by SID and client ID
Digital signature
To guarantee the integrity and authenticity of the assertion ticket, the SAP system that issues the ticket signs the ticket with its own digital signature.
For more information, see Digital Signatures and Encryption and Network and Transport Layer Security .
Prerequisites
AS ABAP systems that issue assertion tickets must be release 6.40.
For more information, see SAP Note 612670 .
The system accepting the assertion ticket trusts the system issuing the assertion ticket.
The clocks are synched.
The hard-coded 2 minute validity period leaves little room for tolerance.
The user ID of the current user is identical in the accepting and issuing systems.
Activities
To configure authentication assertion tickets, you follow the same procedures for configuring the issuing and acceptance of logon tickets.
Using Logon Tickets with AS ABAP .
Using Logon Tickets with AS Java
4 Authentication Infrastructure
Use
You can use this section for an overview of the underlying technology to support user authentication and SSO in the SAP NetWeaver technology stacks.
Integration
The user authentication and SSO functions of SAP NetWeaver are supported by the underlying application server technology stacks. Thereby, the AS Java and
AS ABAP offer the application server level infrastructural mechanisms to support user authentication and SSO for corresponding SAP NetWeaver usage types.
If you have SAP Enterprise Portal in your landscape, the portal uses supplemental mechanisms to support authentication for portal iViews. For more information,
see the portal documentation.
Features
For more information about the system infrastructure that supports the authentication functions of AS ABAP and AS Java based technology stacks of SAP
NetWeaver, see the following sections:
AS ABAP Authentication Infrastructure
Information about the infrastructural elements that support authentication and SSO in AS ABAP systems.
AS Java Authentication Infrastructure
Information about the Java Authentication and Authorization Services (JAAS ) infrastructural elements to support authentication and SSO
in AS Java.
4.1 AS ABAP Authentication Infrastructure
Use
SAP NetWeaver Application Server (AS) ABAP authentication infrastructure provides authentication and SSO functions for the communication channels
supported for the AS ABAP. This including access from the SAP GUI, Web-based access and non-dialog access for communication between systems.
The access management configuration options and the configuration properties of the AS ABAP enable you to configure basic user authentication or a number of

Single Sign-On (SSO) mechanisms. For advanced authentication scenarios that require cryptography, use Secure Network Communications (SNC). To enhance
standard authentication functions with custom development, SNC enables the use of GSS API V2, for example, to use smart cards for authentication.
For AS ABAP components that are enabled for Web-based access, use the configuration options for the Internet Communication Framework (ICF). You can
configure options such as the order of logon checks and HTTP request handlers. The SOAP runtime functions of the ICF enable you to configure authentication for
Web service access.
Features
For more information about the AS ABAP authentication infrastructure and relevant configuration information, see the following sections:
Profile Parameters for Logon and Password
Information about configuring relevant profile parameters for user authentication to the AS ABAP.
Secure Network Communications (SNC)
Information about using SNC for the AS ABAP.
System Logon
Information about the security aspects of using Business Server Pages (BSP) and Web Dynpro as AS ABAP user front ends and enabling technologies for
Web-based access.
Defining the Logon Procedure
Information about configuring authentication options for the Internet Communication Framework (ICF).
Activating HTTP Security Session Management on AS ABAP
You can use optional HTTP security sessions and activate or deactivate these for each client of AS ABAP. With an existing security session, users can
then start applications that require a user logon without logging on again. When a security session is ended, the system also ends all applications that are
linked to this security session.
OAuth 2.0 Implementation with AS ABAP
Information about the implementation of OAuth 2.0 on SAP NetWeaver AS for ABAP.
4.1.1 Profile Parameters for Logon and Password (Login

Parameters)
Use profile parameters to set password and logon rules.
These profile parameters define the minimum requirements for passwords. You cannot set upper limits for password rules, except for generated passwords. For
example, users can use any number of special characters in their passwords, as long as they follow the other password rules.
The profile parameters replaced by security policies are shown in the last table. You can continue to use these parameter instead of the security policies.
However, in this case, you cannot control the system behavior on a user-specific basis.
Note
To make the parameters globally effective in an ABAP System (system profile parameters), set them in the default system profile DEFAULT.PFL. However,
to make them instance-specific, set the parameters in the profiles of the system application servers.
To display the parameter documentation, in the profile parameter maintenance tool (transaction RZ11), enter the parameter name and choose Display . On the
next screen, choose the Documentation button.
Table 1: Password Rules
Parameter Value Description
login/password_charset Default: 1 This parameter defines the characters of which a password

Permissible values: can consist.
0:
Restrictive. The password can only consist of digits,
Caution
With login/password_charset = 2 , the system
letters, and the following (ASCII) special characters:
stores passwords in a format that systems with older
!"@ $%&/()=?'*+~#-_.,;:{[]}\<>, and
kernels cannot interpret. Therefore, ensure that all
space and the grave accent.
systems involved support the new password coding
1:
before setting the profile parameter to the value 2 .
Backward compatible. The password can consist of
any characters including national special characters
(such as ä, ç, ß from ISO Latin-1, 8859-1).
However, all characters that are not contained in the
set above (for value = 0 ) are mapped to the same
special character, and the system therefore does not
differentiate between them.
2:
Not backward compatible. The password can
consist of any characters. It is converted internally
into the Unicode format UTF-8. If your system does
not support Unicode, you may not be able to enter
all characters on the logon screen. This restriction is
limited by the codepage specified by the system
language.
Table 2: Password Hash
login/password_downwards_compatibility Default: 1 Specifies the degree of backward compatibility.

Permissible values:
0:
Caution
With
Stores passwords in a format that systems with
login/password_downwards_compatibility =
older kernels cannot interpret. The system only

older kernels cannot interpret. The system only
0 , the system stores passwords in a format that
generates new (non-backward-compatible)
systems with older kernels cannot interpret.
password hash values.
Therefore, ensure that all systems involved support
1:
the new password coding before setting the profile
The system also generates backward compatible
parameter to the value 0 .
password hash values internally, but does not
evaluate these for password-based logons (to its
own system). This setting is required if you use this
system as the central system of a Central User
Administration and systems that only support
backward compatible password hash values are
also connected to the system group.
2:
The system also generates backward compatible
password hash values internally, which it
evaluates if a logon with the new, non-backward
compatible password failed. In this way, the system
checks whether the logon would have been
accepted with the backward compatible password
(truncated after eight characters, and converted to
upper-case). The system records this in the system
log. The logon fails. This setting is to allow the
identification of backward incompatibility problems.
3:
As with 2 , but the logon is regarded as successful.
This setting is to allow the avoidance of backward
incompatibility problems.
4:
As with 3 , but the system does not create an entry
in the system log.
5:
Full backward compatibility: the system only
creates backward compatible password hash
values.
login/password_hash_algorithm Default: Depends on the kernel version Specifies the hash procedure and the coding format for the
Permissible values: see 991968 (unit: special calculation of new password hash values. You do not
character string). usually need to change the default value set by the kernel.
Note
If the profile parameter
login/password_downwards_compatibility
has the value 5 , only backward compatible
passwords are permissible. This means that the
parameter login/password_hash_algorithm
would be meaningless.
Table 3: Multiple Logon
login/disable_multi_gui_login Default: 0 Controls the deactivation of multiple dialog logons

Permissible values: 0 , 1
1 : The system blocks multiple dialog logons in the
same client and under the same user name.
login/multi_login_users Default: <empty_list> List of excepted users, that is, the users that are permitted
to log on to the system more than once.
Table 4: Incorrect Logon
login/fails_to_session_end Default: 3 Defines the number of unsuccessful logon attempts before

Permissible values: 1 - 99 the system does not allow any more logon attempts. Set
the parameter to a value lower than the value of parameter
login/fails_to_user_lock.
Table 5: Logon with Single Sign-On (SSO) Ticket
login/accept_sso2_ticket Default: 0 Allows or locks the logon using SSO ticket.

Permissible values:
0 : Logon with an SSO ticket is deactivated.
1 : Logon with an SSO ticket is permitted
login/create_sso2_ticket Default: 0 Allows the creation of SSO tickets.

Permissible values:
0 : Ticket generation is deactivated
Recommendation
We recommend you set this to 2 . The SSO tickets
1 : SSO ticket including certificate
are significantly smaller without the certificate and
2 : SSO ticket without certificate
therefore have less overhead.
login/ticket_expiration_time Default value: 8 (in hours) Defines the validity period of an SSO ticket.
login/ticket_only_by_https Default: 0 Specifies how the system sets the logon ticket, generated
Permissible values: at logon using HTTP(S), in the browser.

0 : Browser always sends ticket.
1 : Browser only sends ticket for HTTPS
connections.
login/ticket_only_to_host Default: 0 Specifies how the system sets the logon ticket, generated
Permissible values: at logon using HTTP(S), in the browser.
0 : Sends the ticket to all servers in the domain.
1 : When logging on over HTTP(S), sends the
ticket only to the server that created the ticket.
Table 6: Other Logon Parameters
login/disable_cpic Default: 0 Refuse inbound connections of type CPIC

Permissible values: 0 , 1 (Boolean)
1: Refuses inbound connections of type CPIC. Inbound
connections of type RFC remain unaffected.
login/no_automatic_user_sapstar Default: 1 , that is, you need to explicitly activate the Control the emergency user SAP*.
emergency user For more information, see 2383 and 68048 )
login/server_logon_restriction Default: 0 Use this profile parameter to prevent other users from
Permissible values: logging on to the system. This can be useful during
0 : Normal operation. Users can log on to the system maintenance.
system normally. This feature requires specific kernel releases. For more
1 : Only users with the security policy attribute information, see 1891583 .
SERVER_LOGON_PRIVILEGE with the value 1
can log on to the system.
2 : No users can log on to the system.
login/system_client Default: 000 Specifies the default client that the system automatically
Permissible values: 000 - 999 enters on the logon screen. Users can, however, overwrite
the default value with a different client.
login/update_logon_timestamp Default: m Specifies the exactness of the logon timestamp.

Permissible values:
d : exact to the day
h : exact to the hour
m : exact to the minute
s : exact to the second (backward compatible)
Table 7: User Parameters
rdisp/gui_auto_logout Default: 0 (unrestricted) Defines the maximum idle time for a user in seconds
Permissible values: Any numeric value (applies only for SAP GUI connections).
Table 8: Parameters Replaced by Security Policies
Parameter Security Policy Attribute Value Description
login/min_password_lng MIN_PASSWORD_LENGTH Default: 6 Defines the minimum length of the

Permissible values: 3 - 40 password.
login/min_password_digits MIN_PASSWORD_DIGITS Default Value: 0 Defines the minimum number of digits (0-
Permissible values: 0 - 40 9) in passwords.
login/min_password_letters MIN_PASSWORD_LETTERS Default Value: 0 Defines the minimum number of letters (A-
Permissible Values: 0 - 40 Z) in passwords.
login/min_password_lowercase MIN_PASSWORD_LOWERCASE Default Value: 0 Specifies how many characters in lower-

Permissible Values: 0 - 40 case letters a password must contain.
login/min_password_uppercase MIN_PASSWORD_UPPERCASE Default Value: 0 Specifies how many characters in upper-

Permissible Values: 0 - 40 case letters a password must contain.
login/min_password_specials MIN_PASSWORD_SPECIALS Default Value: 0 Defines the minimum number of special

Permissible Values: 0 - 40 characters in the password.
All characters that are not letters or digits
are regarded as special characters.
login/password_compliance_to_cu PASSWORD_COMPLIANCE_TO_CURRENT_ Default: 0 Used to check password to current security

rrent_policy POLICY Permissible values: policy.
0 : No Check
1 : During the password check, the
system checks whether the current
password fulfills the current
password rules. If this is not the
case, it forces a password change.
login/disable_password_logon DISABLE_PASSWORD_LOGON Default: 0 Controls the deactivation of password-based

Permissible values: logon
0 : Password logon is possible This means that the user can no longer log
1 : Password logon is only possible on using a password, but only with single
for users in the group specified in the sign-on variants (X.509 certificate, logon
parameter ticket). See Logon Data Tab Page
login/password_logon_userg

roup.
2 : Password logon is not possible
in general
login/password_logon_usergroup DISABLE_PASSWORD_LOGON Default: <empty_character_string> Controls the deactivation of password-based

logon for user groups
login/password_max_idle_product MAX_PASSWORD_IDLE_PRODUCTIVE Default: 0 : the check is deactivated Specifies the maximum period for which an
ive Permissible Values: 0 - 24,000 (in days) unused productive password (a password
set by the user) remains valid. After this
period has expired, the user can no longer
use the password for authentication. The
user administrator can reactivate password-
based logon by assigning a new initial
password.
login/password_max_idle_initial MAX_PASSWORD_IDLE_INITIAL Default: 0 : the check is deactivated Specifies the maximum period for which an
Permissible Values: 0 - 24,000 (in days) unused initial password (a password set by
the user administrator) remains valid. After
this period has expired, the user can no
longer use the password for authentication.
The user administrator can reactivate
password-based logon by assigning a new
initial password.
This parameter replaces the profile
parameters
login/password_max_new_valid and
login/password_max_reset_valid.
login/min_password_diff MIN_PASSWORD_DIFFERENCE Default: 1 Defines the minimum number of

Permissible values: 1 - 40 characters that must be different in the new
password compared to the old password.
login/password_expiration_time PASSWORD_CHANGE_INTERVAL Default: 0 Defines the validity period of passwords in

Permissible Values: 0 - 1000 (in days) days.
login/password_change_for_SSO PASSWORD_CHANGE_FOR_SSO Default: 1 If the user logs on with single sign-on,

Permissible values: checks whether the user must change his
0 : Requirement to change or her password.
password is ignored (backward
compatible)
1 : Dialog box with options 2 and
3 (user decides)
2 : Password change dialog only
(enter: old and new passwords)
3 : Deactivation of the password
(automatically, no dialog box)
login/password_change_waittime MIN_PASSWORD_CHANGE_WAITTIME Default: 5 Specifies the number of passwords (chosen

Permissible values: 1 - 100 (number of by the user, not the administrator) that the
entries) system stores and that the user is not
permitted to use again.
login/password_change_waittime MIN_PASSWORD_CHANGE_WAITTIME Default: 1 Specifies the number of days that a user

Permissible values: 1 - 1000 (in days) must wait before changing the password
again.
login/fails_to_user_lock MAX_FAILED_PASSOWRD_LOGON_ATTEM Default: 5 Defines the number of unsuccessful logon

PTS Permissible values: 1 - 99 attempts before the system locks the user.
login/failed_user_auto_unlock PASSWORD_LOCK_EXPIRATION Default: 0 : Locks due to incorrect logon Defines whether user locks due to
attempts remain valid for an unlimited unsuccessful logon attempts are
period automatically removed at midnight.
Related Information
List of Customizing Switches for Generated Passwords
Changing and Activating Profile Parameters
4.1.2 Secure Network Communications (SNC)

Secure Network Communications (SNC) integrates SAP Single Sign-On or an external security product with SAP systems. With SNC, you strengthen security by
using additional security functions provided by a security product that are not directly available with SAPsystems.
SNC protects the data communication paths between the various client and server components of the SAP system that use the SAP protocols RFC or DIAG.
There are well-known cryptographic algorithms that have been implemented by the various security products, and with SNC, you can apply these algorithms to
your data for increased protection.
Note
If you are using standard protocols such as HTTP, then you can use the Secure Sockets Layer (SSL) protocol to provide such protection.

There are regulations in various countries that restrict the use of encryption in software applications. Pay close attention to the regulations that apply to your area of
application.
Features
SNC secures the data communication paths between the various SAP system client and server components. There are well-known cryptographic
algorithms that have been implemented by security products supported and with SNC, you can apply these algorithms to your data for increased protection.
With SNC, you receive application-level, end-to-end security. All communication that takes place between two SNC-protected components is secured (for
example, between the SAP GUI for Windows and the application server).
You can use additional security features that SAP does not directly provide (for example, the use of smart cards).
You can change the security product at any time without affecting the SAP business applications.
Levels of Protection
There are three levels of security protection you can apply. They are:
Authentication only
Integrity protection
Privacy protection
Authentication only
When using authentication only, the system verifies the identity of the communication partners. This is the minimum protection level offered by SNC.
Note
No actual data protection is provided!
Integrity Protection
When using integrity protection, the system detects any changes or manipulation of the data which may have occurred between the two end points of a
communication.
Privacy Protection
When using privacy protection, the system encrypts the messages being transferred to make eavesdropping useless. Privacy protection also includes integrity
protection of the data. This is the maximum level of protection provided by SNC.
Constraints
The product that you use must meet the following requirements:
The product must provide the entire functionality defined in the GSS-API V2 (Generic Security Services Application Programming Interface Version 2)
standard interface. SNC uses this interface to communicate with the security product.
The functions must be dynamically loadable.
The product must be available on platforms supported by SAP.
The product must be certified for use by SAP.
Note
The SAP Cryptographic Library is available with this release to be used by customers for SNC connections between system components. For more
information, see Using the SAP Cryptographic Library for SNC and SAP Note 1848999 .
4.1.3 System Logon
Use
When creating Web applications using Web Dynpro for ABAP or Business Server Pages ( BSP), you can define logon screens for end users to log onto your
system. For the sake of simplicity you can use a logon screen which is similar to the classic logon screen, where you must enter the client, user name, password
and language. Without much programming you can define which fields should be available, which additional help should be offered and how the logon screen
should be designed for your Web applications.
You activate and configure the system logon in the Internet Communication Framework ( ICF) using the respective service nodes for your application.
In addition to these settings, you can also make user-specific changes using a separately developed class.
Example
An example (NW7.01) of a logon screen for a Web application that has been configured with the system logon functionality:

Note
The graphics in the following documentation are examples only. The design is continually developed. For this reason, the UIs may vary in the different
versions and logon screens.
If problems occur during the logon process, the system outputs various error messages or warnings depending on the cause. In addition to errors that refer to the
status of the user data and input errors during the logon, problems in the server or client configuration can also mean that the logon cannot be performed correctly.
You can find these error messages and their long texts about solving the errors in the system in message class ICF_SYSTEM_LOGIN.
Prerequisites
You can find the steps that you must carry out in order to ensure that the logon functionality works smoothly in Prerequisites.
Features
The following functions are supported within the logon application:
Logon and password change
Configuration of the layout and process using the ICF service
Log of the toggle to HTTPS to transfer the user data securely
Various implemented layouts and selectable stylesheet categories
SSO2 support
Changing Passwords for Basic Authentication
Customization for the logon layout and process
Accessibility support
System message display
Check for existing user sessions during the logon
Logon with X.509 certificates
For more information about the various default settings, see Configuration Settings.
Caution
If you start the logon directly using HTTPS and client certificate, then no system messages are displayed and there is no check for multiple logons.

Scenarios for Changing the Password
Activities
1. Go to the service node for your Web application in transaction SICF to the service node for your Web application.
2. Call the detail view of the service by double-clicking it or press F8.
3. Choose the Error Pages tab page.
4. In change mode, select the System Logon radio button and the Configuration pushbutton.
This may appear as follows:

You branch to the configuration screen for the system logon.
5. Enter your configurations for the system logon.
6. Select ( ) for your configuration settings.
7. On the Create/Change Service screen, first select and then .
You return to the node for your application.
8. Position the cursor on your application's node and then choose Test service in the context menu.
The logon screen you have configured is displayed in the browser.
4.1.3.1 Security Aspects for BSP
Use
It is important to consider security aspects when you create Web applications using the BSP programming model. Security functions are available both for when
you create BSP applications as well as for when you operate them.
Security in AS-ABAP
For basic information about security aspects in an AS-ABAP system in which you are creating your BSB application, see the security guide under
Network Infrastructure and
Security in AS-ABAP.
Note
Note in particular the Configuration for SSL Support. Furthermore, a function is provided for increasing performance in the case of multiple logons, namely the
Logon Ticket Cache.
Certain Virus Scan Profiles are delivered by SAP in the standard system. A virus scan is possible during an HTTP Upload (you can find more information about
keyword Virus Scan Interface in the security guide).
The Internet Communication Manager (ICM) receives the HTTP requests from the Internet and returns a response.
Logging on to BSP Applications
To access a BSP application, AS ABAP uses the HTTP framework from the Internet Communication Manager (ICF), which provides functions for logging on to the
AS ABAP.
Caution
Refer in particular to Activating and Deactivating Services. For security reasons, the only services that should be active in the HTTP service tree are those
services that you really need. If, however, you activate nodes at a higher level, this means that the whole part of the service tree below this level is completely
open and is therefore not secure if an anonymous user is defined, for example.
You can find a list of the services required for each usage scenario in Business Server Pages Administration.
To create logon procedures for your BSP application there is a simple procedure for developing and configuring the system logon. For more information, see
System Logon.
Accessing a BSP Application

A browser accesses your BSP application using HTTP or HTTPS. The most important aspects are summarized in Accessing a BSP Application.
You can also determine that your BSP should always be accessed using HTTPS. You can find more information about defining the transmission options in the
description of the Properties of a BSP application.
You have to configure the secure sockets layer (SSL) so that your BSP application can communicate with the browser. Make sure that your BSP application
supports HTTP POST requests. For more information, see SAP Note 904249.
Security Risk List

A white list infrastructure in the HTTP framework fends off XSS attacks: Security Risk List
URL Generation
See URL Generation in an AS-ABAP - Web Dispatcher Configuration
Notes
Note Number Title
510007 Setting Up SSL on the Web Application Server
517860 Logging on to BSP Applications
434918 DNS Configuration for BSP Applications under Windows 2000
420085 Logon Ticket Cache
853878 HTTP Whitelist Check (security)
904249 Start BSP with a POST Request
1532403 BSP XSRF Framework as Transport Files (only for stateful applications)
1551982 XSRF Protection for Stateless BSP (also for stateless applications)
4.1.3.2 Security Considerations for Web Dynpro Applications

It is important to consider security issues when you create Web applications using the Web Dynpro ABAP programming model. Security functions are provided
for when you create Web applications as well as for when you operate them.
Note
For basic information about security issues in an AS ABAP system in which you are creating a Web Dynpro application, see the SAP NetWeaver Security
Guide on the SAP Help Portal at http://help.sap.com/nw_platform. In particular, refer to the following sections:
Network and Communication Security
SAP NetWeaver Application Server ABAP Security Guide
Note in particular the Configuration for SSL Support.
Furthermore, a function is provided for increasing performance in the case of multiple logons, namely the Logon Ticket Cache.
Certain Virus Scan Profiles are delivered by SAP in the standard system. A virus scan is provided for HTTP upload.
More information: Virus Scan Interface).
If problems occur with missing certificates for Web Dynpro ABAP applications, follow the recommendations for building trust relationships for server-
side authentication.
More information: SSL -Scenario 1: Trust Relationship for Server-Side Authentication.
Configuration
In a production system, the following HTTP service nodes (transaction SICF) are not active for the Configuration, since a configuration always represents a
development.
/sap/bc/webdynpro/sap/CONFIGURE_APPLICATION
/sap/bc/webdynpro/sap/CONFIGURE_COMPONENT
/sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_APPL
/sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_COMP
/sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_USER
For more information, see Active Services in SICF.
Data Security in Web Applications

See Data Security in Web Applications.
Security of View Context Data

See Security of View Context Data.
Permissibility of Database Changes for Start, Resume, TimedTrigger, and Notification Service
See Permissibility of Database Changes for Start, Resume, TimedTrigger, and Notification Service.
Read Access Logging

See Read Access Logging.
Security for UI Element Events

In an SSR client only those events can be triggered by a JavaScript attack that can also be triggered by a user interaction. The UI element associated with each
event arriving on the server is checked to ensure it is visible and enabled. Certain events are also restricted by the attribute readOnly of the UI element when it
is executed. In such cases this is also checked.
See also: Security Notes for FileUpload UI Elements

Security of URL Parameters
An application can define its own URL parameters. The content of these parameters should be checked by the application to avoid any attacks occurring this
way. URL Parameters provided by Web Dynpro are automatically checked by the Web Dynpro runtime (see Application Parameters and URL Parameters).
User Management
Logging on to Web Applications
To access a Web application, AS ABAP uses the HTTP framework from the Internet Communication Manager (ICF), which provides functions for Logging
On to AS ABAP.
Caution
Refer in particular to Activating and Deactivating Services. For security reasons, the only services that should be active in the HTTP service tree are
those services that you really need. If, however, you activate nodes at a higher level, this means that the whole part of the service tree below this level
is completely open and is therefore not secure if an anonymous user is defined, for example.
A simple procedure is available for developing and configuring the system Logon with Web applications. The security functions are integrated in this
procedure.
Authorizations
General authorization checks for services and application are available in the ICF.
More information: Authorizations). If required, special authorization checks for Web Dynpro Applications are made by the respective application.
There is a separate authorization check for launching Web Dynpro ABAP applications. The authorization component S_START is provided for this
purpose. For more information, see SAP Notes 1413011 and 1413012 .
For personalization, an authorization check is provided by Web Dynpro ABAP. It checks the administration authorization for personalizing UI elements
(see Authorizations for Personalization and Customizing).
Application Logoff Page
You can use your own logoff page for your Web Dynpro application: Application Logoff Page
SAP Trust Center Service
Customers can use the SAP Trust Service Center to have SAP passports issued. Here the customer ABAP system acts as the registration authority (RA)
and SAP as the certification authority (CA).
Note
For this, note that the users first have to log on (once) to the browser-based ABAP system using the password at the customer-side so that they can
then request the SAP passports. Once these have been requested, they can be used from the browser - provided that an HTTP URL is used. In this
case, the browser-based logon takes place completely automatically (using the SAP passport or X.509 certificates), irrespective of whether you call the
browser directly, click on an HTTP URL in a mail, or the BEx Analyzer triggers the URL.
For more information about SAP Trust Center Services for SAP Passports, see the SAP Service Marketplace at Certificate Policy of the SAP Passport .
Web Applications Without Domain Relaxing

Before SAP NetWeaver 7.0 SP6 a Web Dynpro application could not be run isolated in an environment (for instance, in SAP Enterprise Portal), since it always
relaxed the domain in its environment. However, for applications where security is critical this opens up a gateway for attack. Attackers could run their own
application in a different IFrame, relax their domain too, and access sensitive data from the original application.
To ensure this does not happen, application parameter WDPROTECTEDAPPLICATION can be set for an application on the server, regardless of whether the
application relaxes its domain or not (see Application Parameters and URL Parameters).
The standard setting is where the domain remains relaxed. The parameter is used to deactivate this standard setting for applications where security is critical.
Check for which of your applications security is critical and set the indicator in the Web Dynpro application accordingly. To do this select the Web Dynpro
application in SE80 and go to the tab page Parameters . Using F4 help on the parameter you can select the entry WDPROTECTEDAPPLICATION and set its
value to X.
Web Dynpro Console

If parameter sap-wd-ssrconsole=true is set to true, the Web Dynpro console is displayed. This contains various information, such as the build number of
the rendering, the version in use and other information to support error handling. No data can be input.
Application Error Page

You can suppress the standard error page generated by the ICF and define your own error page instead (see Application Error Page).
Security Risk List

A whitelist infrastructure in the HTTP framework fends off XSS attacks (see Security Risk List).
The whitelist is also relevant for the Web Dynpro ABAP portal integration; for a WDA view, the portal stylesheet URL is passed to Web Dynpro ABAP by means
of the URL parameter. You must therefore enter the URL of the portal into the whitelist if using the portal integration.
To prevent external stylesheet information being used, that is prevent external control, you can set Web Dynpro ABAP application parameter
WDUSEEXTERNALSTYLESHEET to value OFF (see Application Parameters and URL Parameters).
For security reasons, a whitelist is also required to use the UI elements AcfExecute and AcfUpDownload. For more information, see the documentation for these
two UI elements and the Implementation Guide (IMG) in the system.

URL Generation in an AS-ABAP - Web Dispatcher Configuration
See URL Generation in an AS-ABAP - Web Dispatcher Configuration.
Security for Portal Integration

For security reasons, we recommend that you use SAP logon tickets or X.509 certificates for portal integration. Other logon procedures are not fully supported.
Relevant SAP Notes

SAP Note Number Title
1088717 Active Services for Web Dynpro ABAP in Transaction SICF
510007 Setting Up SSL on the Web Application Server
420085 Logon Ticket Cache
853878 HTTP Whitelist Check (security)
1413011 New start authorization check for Web Dynpro ABAP
4.1.4 Maintaining Logon Procedures
Use
You can choose from several different logon procedures when you use a HTTP request to log on to SAP Web AS. You can configure the procedure individually for
each service or for an entire service node, including all its services.
Prerequisites
At least one HTTP request handler must have been entered for the service or service node.
Integration

Features
You can specify for every ICF service what logon procedure must be used to execute it. The following options are available:
Standard (default): When you log on, multiple checks are run in a specified order.
Alternative Logon Procedure: When you select this option, you can choose the checks yourself, and the order in which they run.
Logon Data Required: Only the logon data specified in the service ( User , Password , Client , and Language ) is used to check the logon.
SSL Certificate Required: Logons are performed using X 509 Certificate only.
Note
You can use only one of these options for each service or service node.
If you use the Standard or Alternative Logon Procedures , you can use the All Logons checkbox to specify whether the appropriate checks are run (in
the specified order) until one of the logon procedures is successful (checkbox activated), or whether the logon is rejected with a message as soon as a logon
procedure fails (checkbox not activated).
Note
A logon procedure is then only checked when the corresponding logon data is also provided by the HTTP request.
Note
An HTTP request can also contain logon data for multiple logon procedures, for example, for Basic Authentication and SAP Logon Ticket.
For each service, you can also choose the Logon via SAML option. With SAML ( Security Assertion Markup Language ), you can use XML-based single
sign-on mechanisms for your services.
For each service, you can define an individual response page that appears if the logon fails.

More Information
Logon Checks: Overview
Standard Logon Order
Alternative Logon Order
Logon Using Service Data
Logon with SSL Certificate
Logon with Logon Ticket
Logon with SAP Assertion Ticket
Logon Using Basic Authentication.
Logon Using SAML
Specifying the Client
Determining the Logon Language
For information about making ICF communications secure, see the following:
RFC/ICF Security Guide
4.1.4.1 Logon Checks: Overview
Procedure
When an ICF service is called through an external client in SAP ABAP Application Server, a series of checks is performed to authenticate the caller. This
document provides an overview of these checks in the order in which they are performed.
An initial check is used to ensure that the called service exists and is active. If the service exists and is active, the next step checks whether the service is
Public or Non-Public . A Public Service can be called in the system without the logon being checked.
If the service that is being called is non-public , the service configuration is used to check whether logon data or an SSL certificate is required:
If Logon Data Required has been selected, the logon procedure uses the anonymous logon data specified for this service.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_SERVICE.
If Client certificate with SSL has been selected, this is used for the logon procedure.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_CERTIFICATE.
If neither of these procedures is required, the system checks whether the standard logon order or an alternative logon order has been selected.
If the standard logon order has been selected, the system attempts to log the user on in the following order:
1. Logon using HTTP fields (HTTP header fields or form fields): These changes are:
sap-language
sap-client
sap-user
sap-alias
sap-password
(If sap-user is specified, sap-alias is then unimportant, see Basic Authentication.)
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_FIELD.
2. Logon using SSL certificate (HTTPS and certificate). In this case, the system attempts to log on the user using a client certificate and SSL. The
following conditions must be met:
The appropriate header field is set.
The connection for HTTPS is configured.
The client certificate exists.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_CERTIFICATE.
3. Logon using SSP ticket (MYSAPSSO2 cookie field). If no logon data is transferred as form fields or header fields, the system then tries to log on
using an SSO ticket. To enable this, the cookie field MYSAPSSO2 must be set.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_SSO.
4. Logon using Basic Authentication. If the request contains the header field for Basic Authentication , the user name is interpreted either as a
standard SAP user (default) or as an Internet user (user name alias, see transaction SU01), depending on the settings made under Basic
Authentication.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_BASIC.
5. Logon using SAP logon. This is a normal logon procedure using client, user, password, and logon language. This method is used primarily between
SAP Systems, and not so much for logon via a Web browser. A header field is also used to indicate that this logon method should be used.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_SAP.
6. Log on using SAML Logon (Log on Using SAML).
7. If none of these methods are possible because the request does not contain any information regarding logon procedure, the default logon procedure
is used. Logon using Service User Account . If you have maintained the Anonymous Logon Data, the logon procedure uses this user name, client,
and logon language. If you have not entered any data for an anonymous user, HTTP response 401 is sent. If you are using a Web browser, this
response is displayed in a popup. The user can then log on to the SAP System using HTTP Basic Authentication on this popup. The default client
and logon language of the user in question are used.
The AUTHENTICATION_METHOD attribute, which belongs to IF_HTTP_SERVER, is set to AUTHMETHOD_SERVICE.
If Alternative Logon Order applies, the procedures described under the standard logon order (or a selection of them) run in the user-defined
order.
If none of the selected logon procedures are successful, the system checks to see whether an individual error page has been configured for the
service.
If no error page exists, a default response (http 401) is sent to the caller, together with a Basic Authentication prompt in a dialog box.
Note
If Alternative Logon Order is specified, and Basic Authentication is not permitted as a procedure, then no Basic Authentication prompt is sent
when an error occurs.

4.1.4.2 Standard Logon Order
Use
Features
In the standard logon order, the following checks are performed in this order:
1. Logon Using HTTP Fields
2. Logon with SSL Certificate
3. Logon with SAP Logon/Assertion Ticket
4. Logon with SAP Assertion Ticket
5. HTTP Basic Authentication
6. Logon Using SAP User and Password (RFC Logon)
7. Logon Using SPNEGO
8. Logon Using SAML
9. Logon Using User Data Stored in Service
Note
If the All Logons flag is set, all logon procedures are checked one by one until a check is successful. If the flag is not set, only the first procedure in the
sequence is checked. If it is not successful, an appropriate error appears.

Note
Note
You need SAP NetWeaver Single Sign-On to use the SPNEGO logon procedure.
Activities
If you want to use the standard logon order, proceed as follows:
1. In transaction SICF, call the required service or service node.
Note
If you define the logon order in a service node, the settings are passed on to all services under this node, unless different data has been entered for
them.
2. Choose Change . The standard logon order is set as the default.

3. If you want all selected logon procedures to be checked until a logon is successful, select the All Logons flag.
4. Save your data by choosing .
4.1.4.3 Alternative Logon Order
Use
When you choose the alternative logon order, you can select the logon procedures of your choice, and change the order in which they are checked.
Features
When you use the alternative logon order, you can include or remove the following procedures:
Logon Using HTTP Fields
Logon with SAP Logon/Assertion Ticket
Logon with SAP Assertion Ticket
HTTP Basic Authentication
Logon Using SAP User and Password (RFC Logon)
Logon Using SPNEGO
Logon Using SAML
Logon Using User Data Stored in Service
You can change the order of the checks to meet your requirements.
Note
If the All Logons flag is set, all logon procedures are checked one by one until a check is successful. If the flag is not set, only the first procedure in the
sequence is checked. If it is not successful, an appropriate error appears.
Note
Note
You need SAP NetWeaver Single Sign-On to use the SPNEGO logon procedure.
Activities
To define an alternative logon order, proceed as follows:
1. In transaction SICF, call the required service or service node.
Note
If you define the logon order in a service node, the settings are passed on to all services under this node, unless different data has been entered for
them.
2. Choose Change .
3. Under Service Data/Logon Procedure , choose Alternative Logon Order . The Logon Order tab appears on the service maintenance screen.
4. Choose the Logon Order tab.
5. Select any logon procedures that you do not want to use, and choose Delete Line .
6. Enter numbers to specify the order in which you want the checks to run.
7. If you want to go back to the standard logon order, choose Restore .
8. Once you have defined the defined the procedures you want to use and the order of the checks, choose Save .
9. If you want all selected logon procedures to be checked until a logon is successful, go to the Service Data tab and select the All Logons flag.
10. Save your entries.

4.1.4.4 Logon Ticket Cache
Use
Logon ticket caching is used to increase the speed of the logon procedure for a specific user, after that user has logged on for the first time.
See also:
Using Logon Tickets
The logon ticket mechanism is used to set up Single Sign-On. On SAP Web Application Server, you set up the Logon Ticket mechanism using profile
parameters. Appropriate profile parameters are provided.
The logon ticket is stored in a non-persistent HTTP cookie in the user's Web browser. To prevent logon tickets from being forged, the issuing server digitally signs
every ticket. This digital signature is then verified when a logon ticket is used in a logon session. Complex cryptographic operations are used to create and verify
tickets. This has the disadvantage that subsequent logons with a logon ticket can take longer than the initial logon with a user name and password. To avoid
possible reduction in performance when using logon tickets, logon ticket caching has now been introduced.
Features
New and verified tickets are stored in a cache memory located in the shared memory on the SAP Web Application Server. When a user attempts to log on to SAP
Web Application Server using a logon ticket, the system searches the cache memory. If the system finds a cache entry for this logon ticket, it simply reads the
logon information from the cache memory and does not perform a signature check. The cache entry stays in the cache memory until the expiry date of the new or
received logon ticket. Thus, cache entries cannot be used after the ticket itself has expired. The Hash procedure used to encode the cache entry ensures that the
probability of anyone correctly guessing a valid cache entry during its lifetime is very low.
Note
Logon ticket caching causes no visible changes for the user, except improved performance.
The logon ticket cache is activated by default. You can change this setting using the profile parameter login/ticketcache_off. In all SAP Web Application
Server systems, the default value of this parameter is 0.
Note
If you experience problems (for example, with the shared memory), you can switch off ticket caching by setting the profile parameter to 1 (
login/ticketcache_off=1).
Each entry in the logon ticket cache requires approximately 150 bytes of shared memory. The standard size of the cache is 1000 entries (profile parameter
login/ticketcache_entries_max=1000).
Note
You can change the size of the cache by changing the defined value of the profile parameter login/ticketcache_entries_max.
Each cache entry is identified by the client it applies to and by the coded ticket with user ID, lifetime, and signature. The lifetime of the cache entry is set to the
remaining validity period of the ticket.
4.1.4.5 Logon Using Service Data
Use
In a service or service node, you can store anonymous logon data. In this way, you make sure that this data is checked when an HTTP request connects to AS
ABAP for this service or service node.
Features
You can store the following data in a service or a service node for authentication purposes:
Client
Users
Caution
Here, you should only store users that have been created as service users (composite users) in transaction SU01. If you store a dialog user, a warning
message will appear.
Password
Language
This logon data is used differently depending on which logon procedure you choose:
If you have chosen the standard logon procedure or the alternative logon procedure, the logon data is checked using the appropriate methods.
If you have chosen the Logon Data Required option, the system uses only the logon data you have entered for its checks.

Activities
If you want to store logon data in a service or service node, proceed as follows:
1. In transaction SICF, double-click the required service or service node.
2. Choose Change .
3. Under Logon Data , enter a client, user, password, and language.
Note
If you store logon data in a service node, this data is passed on to all services under this node, unless different data has been entered for them. This rule
applies irrespective of whether or not you have selected Logon Data Required .
Example
You have created a service A, with subservice B, which in turn has subservice C, and have defined the following logon data:
Service Logon Data
Client User and Password Language
A franky/****** de
B 001 en
C susan/******
If you call up service C by adding the ICF path /A/B/C to the URL, the logon data will be as follows:
Client 001: C: no client has been specified for C, so the B's client is used.
User/password susan/******: as this is maintained in C, the system does not search for user/password.
Language en: No language is specified for C, B has the language en. A is ignored in this case.
4. If you want the logon to be performed using only the logon data stored in the service, choose the Logon Data Required option under Logon Procedure .
5. Save your data by choosing .
4.1.4.6 Logon with SSL Certificate
Use
When you log on with a client certificate, you can use an X.509 certificate .
Prerequisites
The appropriate header field is set.
The connection for HTTPS is configured.
The SSL certificate exists
Features
You can use a client certificate to check logons in two different ways:
As part of the standard logon order or an alternative logon order (if selected)
As the only logon check (if the SSL Certificate Required option is selected)
Activities
If you only want logons for services or services nodes to be performed with a client certificate, proceed as follows:
2. Choose Change .
3. Choose Logon Data .
4. In the Logon Procedure field, enter the option Mandatory Using SSL Certificate .
Note
If you make settings in a service node, this data is passed on to all services under this node, unless different data has been entered for them.
5. Under Service Data/Security Requirements , select the SSL option.

6. Save your entries with Save .
Use
If you use Basic Authentication to log on to ABAP Application Server, you can choose either a standard SAP user or an internet user :
The default SAP user is the user name entered in transaction SU01.
The Internet user is the alias name. This can be longer than the normal SAP user name. This can also be set in SU01.
Depending on the settings, the input in the HTTP popup for Basic Authentication is interpreted as either a user name or an alias.

Activities
If you want to change the user type for the Basic Authentication logon procedure in a service or service node, proceed as follows:
2. Choose Change .
3. Under Logon Data/Authentication , choose Standard SAP User or Internet User .
Note
If you make this setting in a service node, the data is passed on to all services under this node.
4.1.4.8 Logon via SAML
Use
For each ICF service, you can define whether you want to allow logon via SAML (Security Assertion Markup Language). This procedure makes it possible to
exchange logon and authorization information between business partners for using XML-based web services. Using this procedure, you can avoid having to log on
repeatedly when using web services of the same kind.
Integration
The SAML logon procedure is listed as last but one (position 6) in the logon procedure in both the standard logon order and the alternative logon order (default
setting).
Note
If you explicitly deactivate the SAML logon procedure, it will not be used in the standard logon order either.
Caution
If you use the alternative logon order and want to use SAML, you need to activate the procedure and must not remove it from the list of logon procedures.
Prerequisites
The logon procedure you are using is either Standard or Alternative Logon Order . In the logon procedures Required with Client Certificate and Required with
Logon Data , the SAML application is not active.
Activities
If you want to allow logon via SAML, proceed as follows:
2. Choose Change .
3. Choose logon data and define one of the following options for SAML:
Choose SAML Configuration and define whether you want to take over the configuration settings from higher-level nodes. If you want to make a
configuration of your own for this service, remove the selection for this option and maintain the displayed settings especially for this service.
Choose Accept Data and save your entries with .
Example
Example
For travel planning, a user is using web services on various web pages to book a flight, rent a car and reserve a hotel room. If the relevant services use the
SAML logon procedure, the user only needs to log on once (for the first activity) and can then perform all other services without needing to log on again.
More Information
For more details about using SAML in SAP Web AS, see
Using SAML 2.0
4.1.4.9 Specifying the Client
Use
The logon client for the Application Server is defined using the following procedure.
1. If the flag Mandatory Logon Data has been set in a service/service node in transaction SICF, the system uses the client that is entered there.
2. If this is not the case, but the HTTP request contains the client in the HTTP header (as a header or a form field), you log on to the system using this client.
3. If a client is entered for the service in transaction SICF, this client is used.
4. If no client is defined with this procedure, then the default client of the application server is used.

More Information
Determining the Logon Language
4.1.4.10 Determining the Logon Language
Use
The logon language is specified in the Application Server according to the following procedure.
1. If the Mandatory Logon Data flag has been set for a service in transaction SICF, the system uses the language that was entered there.
2. If this is not the case, but the HTTP request contains the language in the HTTP header (as a header or a form field), you log onto the system using this
language.
3. The browser settings of the calling client are then used. The system selects as the logon language the first language from the list that is maintained in the
browser, and which is also installed in the SAP system.
The language list is specified using the HTTP header field accept-language.
Note
With Internet Explorer, you can for example set the language you require by choosing Tools Internet Options Languages .
4. If the flag Logon Data is set for a service in transaction SICF (and not flagged as obligatory) the language entered there is used.
5. If no language is defined by this process, the classic SAP system mechanisms are used. The logon language is based on the user settings (in transaction
SU01) and if nothing is entered here, the default language of the SAP system is used automatically.
More Information
Specifying the Client
4.1.4.11 Inserting an HTTP Request Handler
Prerequisites
You have created a request handler.
Context
For an HTTP request handler to be called using a URL, it must first be defined in a service. If you have developed your own request handler, you need to insert it
into the relevant service in order for it to be usable.
Procedure
1. Call transaction SICF.

2. If no suitable service exists, create a new service.
3. If a suitable service does exist, double-click on it to open it..
4. Choose Handler list .
5. Choose Change .
6. Enter a request handler in the list (by choosing F4 if necessary).
Note
You can create multiple HTTP request handlers for a single service. These are then called in the specified order. You can use return codes to control
whether other handlers from the list are called, and if so, which ones.

8. Check that the service is active.
Results
The request handler can be called up via a URL that contains the relevant service path.
Example
The SAP NW Application Server runs on the computer saphost on port 8080. In transaction SICF, you have created the service sap/bc/ping in the HTTP
service tree and entered your handler class CL_HTTP_MYHANDLER in the handler list.
If you enter the URL http://saphost:8080/sap/bc/ping , the method handle_request(), which you created for your HTTP request handler, is called.
4.1.5 Activating HTTP Security Session Management on AS

ABAP
Context
You can use optional HTTP security sessions and activate or deactivate these for each client of AS ABAP. With an existing security session, users can then start
applications that require a user logon without logging on again. When a security session is ended, the system also ends all applications that are linked to this
security session.
A security session starts with the logon to the system and ends with the logoff from the system. Logoff can be triggered in the following ways:
By the user
By the system administrator
A system administrator can use transaction SM05 to end an HTTP security session (and all application sessions linked to this security session). The
Security Audit Log logs this event.
By inactivity, that is, no HTTP communication with the system.
You can set the time period as of which the system assesses a lack of communication as user inactivity in profile parameter http/security_session_timeout.
The following profile parameters are relevant for HTTP security session management.
Profile Parameter Possible Values Additional Notes
login/create_sso2_ticket 0: Do not create tickets (SSO Tickets) Permits the generation of logon or authentication assertion
1: Create SSO Ticket with certificate tickets.
2: Create SSO Ticket without certificate
3: Create assertion tickets only (no logon tickets) Recommendation
For an issuing system, we recommend the value 3
with security session management. The use of logon
tickets with security session management makes it
impossible for the automatic logoff from inactivity
function to work properly. With this value the system
still issues assertion tickets, which are used for
system to system communication. If you cannot do
without logon tickets, then we recommend that you
use the value 2 as tickets without certificates are
smaller.
For receiving systems, we recommend that you
deactivate ticket generation, that is, value 0.
login/accept_sso2_ticket 0: Logon with tickets is not permissible Defines whether the system accepts logon and assertion
1: Logon with tickets is permissible tickets.
login/ticketcache_entries_max Default value: 1000 Defines the maximum number of possible entries in the
cache for logon tickets.
login/ticketcache_off 0: Hold logon tickets in the cache (default value) Defines whether the system holds logon tickets in the
1: Do not hold any logon tickets in the cache cache
login/ticket_only_by_https 1: Cookie is only sent by the browser during HTTPS Specifies how the system sends the logon ticket cookie
connections. and the HTTP session management cookie generated
0: Cookie is always sent when you log on using HTTP(S) in the browser.
icf/set_HTTPonly_flag_on_cookies 0 = HTTPonly attribute active for all ICF cookies Sets the attribute HTTPonly for ICF cookies
1 = HTTPonly attribute deactivated for ICF logon cookie
2 = HTTPonly attribute deactivated for cookies except ICF Caution
logon cookie Declaring a cookie as HTTPonly increases the security
3 = HTTPonly attribute deactivated for all ICF cookies of your system because it eliminates access to this
cookie in the Web browser from client-side scripts,
applets, plugins, and the like. This can have side
effects because some applications use such
technologies and also rely on this information. These
applications may no longer function correctly because
they cannot access this information.
Example
An example of this is an application that uses Java
applets to perform a certain function within a Web
browser application. When the user accesses the Web
browser application, the backend server may
authenticate the user and may issue the user a cookie
(for example, a logon ticket or a session ID) to use for
further authentication. If the HTTPonly attribute is set
for this cookie, then neither the applet can access it,
nor the cookie is automatically sent back to the server
because the applet uses its own communication
channel. Therefore the user will either see a logon
screen or notice other function defects (for example, a
blank screen), even though the user was already
authenticated in the Web browser session.
icf/user_recheck 0 = Check is not active Defines whether, for stateful HTTP communication (and
1 = Check is active therefore the addressing of an existing session), the
system checks the logon data again for HTTP requests.
The authentication data needs to match the data held in the
session.

Note
This parameter is only relevant if Security Session
Management is not active.
http/security_session_timeout Default value: 1800 (30 minutes) Defines the maximum time period between the receipt of
two HTTP requests (with valid security session ID). After
this period has expired, all application contexts that are
connected with a security session on this application
server (if you are using stateful Web applications) are
closed (and resources that are connected with these
sessions are released; more information:
rdisp/plugin_auto_logout). If the security session is
no longer actively used on another application server, the
security session is also closed. For Web-based applications
or services that require authentication, all subsequent
HTTP requests lead to an authentication request.
http/security_context_cache_size Default value: 2500 With active HTTP security session management, the
system stores session contexts in a local server cache to
monitor whether the session inactivity timeout is
exceeded. You cannot change the cache size at runtime. It
is defined by the retention period of the cache entries (that
is, the session timeout value) and the expected number of
simultaneous users of an application server instance.
rdisp/plugin_auto_logout Default value: 1800 seconds Specifies the maximum period of inactivity for the user
0: System does not automatically delete the context context of an external plug-in (such as HTTP), before the
system closes it.
You can specify the value with or without a time unit.
Specifying a value without a time unit means that the
system uses seconds as the unit. However, you can also
specify M for minutes or H for hours.
rdisp/autothtime Default value: 60 seconds Defines the time interval between the periodically-
performed checks in the task handler, such as the
automatic resetting of trace files, the checking of the
context pool for RFC servers or external plug-ins (HTTP,
and so on), and the automatic logon for external plug-ins
(HTTP, and so on).
You can specify the value with or without a time unit.
Specifying a value without a time unit means that the
system uses seconds as the unit. However, you can also
specify M for minutes or H for hours.
Procedure
1. Start HTTP Session Management (transaction SICF_SESSIONS).
A list of all of the clients that exist in the system appears.
2. Select the relevant line and choose Activate .
The Security Audit Log records the activation or deactivation of HTTP Security Session Management.
4.1.6 Disabling the Display of Last Logon for HTTP Logons
Prerequisites
You have configured the AS ABAP to support logon with user ID and password.
Your system logon uses a logon layout and procedure supported by the last logon popup.
For more information about system logon, see System Logon.
Context
SAP NetWeaver Application Server (AS) ABAP displays the last logon information as a popup after users successfully log on with user ID and password over
HTTP. The system displays the following:
Date of last successful logon
This enables users to confirm that they were indeed the last person to log into their user account. If the user sees a logon event, when the user knows that
he or she did not logon, the user should alert the administrator of a security breach.
Number of failed logon attempts with user ID and password since the previous successful logon
This enables users to detect a potential attack on their passwords. If the user sees an unusual number of failed logon attempts, that the user knows he or
she did not make, the user should alert the administrator about the activity. The administrator can then refer to the appropriate logs and determine if there is
unusual activity. You can configure the system to display only the failed logon attempts and not the successful logons.
Example
You see in the security audit logs a systematic attempt to guess passwords (many failed logon attempts) followed by a successful logons. This could
indicate an attack on your users. You can then lock accounts that you suspect have been compromised. You can then consider other options, such as,
increasing the strength of the password policy or blocking the source of the attacks.

increasing the strength of the password policy or blocking the source of the attacks.
Procedure
1. Start Maintain Services (transaction SICF).

2. Select a service or alias.
3. Choose .
4. Choose .
5. Choose the Error Pages tab.
6. On the Logon Errors tab, choose the Configuration pushbutton.
7. Determine which information you want to display.
To display on the failed logon attempts, select the Only Failed Logon Attempts checkbox.
This reduces the number of popups your users must face when logging on to the system. This option is only available after you have enabled the
Show Last Logon Attempt checkbox.
To stop showing the logon information popups, clear the Show Last Logon Attempt checkbox.
Note
If the checkboxes are disabled, the logon layout does not support the last logon popup.
4.1.7 OAuth 2.0 Implementation with AS ABAP
Features
The OAuth 2.0 implementation with AS ABAP has the following components:
Authorization server
The authorization server includes the token endpoint (see Token Endpoint for OAuth 2.0 and Authorization Server of the OAuth 2.0 Implementation). The
authorization server issues tokens which are used to delegate access.
Resource server
The resource server (see Resource Server for OAuth 2.0) makes resources available for the OAuth 2.0 client.
The implementation resides in the SAP Basis component and has interfaces to the OData runtime and the OAuth 2.0 authentication in the logon framework of the
ICF.
SAP products running on AS ABAP become OAuth 2.0 enabled by implementing the OAuth 2.0 runtime. In the OAuth 2.0 framework, it determines during
runtime which OAuth 2.0 scopes are being requested.
More Information
Resource
Resource Owner in OAuth 2.0
4.1.7.1 Authorization Server of the OAuth 2.0 Implementation
Use
The authorization server of the OAuth 2.0 implementation manages the authentication process in OAuth 2.0. Its main task is to issue OAuth 2.0 access tokens for
the OAuth 2.0 client. The access tokens can be sent to the resource server.
Prerequisites
SSL must be set up in the AS ABAP (see Parameters for OAuth 2.0 Administration).
Integration
The topic OAuth 2.0 Flows Supported by SAP illustrates the way an OAuth 2.0 client can get access to resources on an AS ABAP.
4.1.7.1.1 Token Endpoint for OAuth 2.0

The token endpoint is a subcomponent of the authorization server. It is a dedicated ICF node for issuing access tokens after having successfully authenticated an
OAuth 2.0 client.
Use
The ICF node has the following URL (SSL is used):
https://<host>:<port>/sap/bc/sec/oauth2/token
The token endpoint is called with the SAML 2.0 bearer assertions to generate access tokens.

Prerequisites
SSL must be set up in the AS ABAP (see Parameters for OAuth 2.0 Administration).
Process
The following process illustrates which activities are triggered when an OAuth 2.0 client requests an access token
1. The OAuth 2.0 client receives an authorization grant that includes information about the resource owner's identity. If you use the SAML 2.0 bearer flow, this
is a SAML assertion. If you use another flow, this might be an authorization code. For more information on the flows supported by SAP, see OAuth 2.0 Flows
Supported by SAP.
2. Depending on the OAuth 2.0 flow, the client sends an access token request, for example to the token endpoint in the authorization server. It includes the
OAuth 2.0 client and the requested scope IDs.
3. It checks the authorization for the requested scopes.
4. It checks the authorizations of the OAuth 2.0 client for the requested scopes.
5. The token endpoint generates an OAuth 2.0 server context, which stores the local user, the intersecting set of scopes, and the expiration time.
6. It creates an access token (that points to the server context). The response contains the following:
Access token
Token type
Expiration time
Refresh token (optional)
OAuth 2.0 scope (optional)
7. The access token is sent to the OAuth 2.0 client.
Result
The OAuth 2.0 client receives a valid access token and stores the related data.
More Information
Authorization Server of the OAuth 2.0 Implementation
OAuth 2.0 Implementation with AS ABAP
4.1.7.1.2 Authorization Endpoint for OAuth 2.0
Use
The authorization endpoint is a dedicated ICF node that handles requests from the Internet to the OAuth 2.0 scopes. A user (the resource owner) explicitly selects
the OAuth 2.0 scopes to be accessed by a third party.
Prerequisites
You use SSL for secure communication.
Procedure
The following process illustrates which activities are triggered when an OAuth 2.0 client requests an authorization code:
1. The web application hosting the OAuth 2.0 client redirects the resource owner's user agent to the authorization endpoint of the authorization server.
2. The authorization server authenticates the resource owner using an authentication method supported by AS ABAP.
3. The AS ABAP checks the authorizations of the client and resource owner for the requested OAuth 2.0 scopes. The authorization server preselects the
scopes for which the resource owner is authorized and presents them to the resource owner.
4. The resource owner can further restrict the selection or simply accept the proposal.
5. The authorization endpoint receives the result of the resource owner's consent and issues an authorization code that represents the selected set of scopes for
the requesting client and the granting resource owner.
6. The issued authorization code is sent to the redirection URI at the web application hosting the OAuth 2.0 client by user agent redirection.
Note
The authorization server uses the redirection URI that was defined during the client registration.
Result
The OAuth 2.0 client receives a valid access token and stores the related data.
Example
https://<host>:<port>/sap/bc/sec/oauth2/authorize

More Information
4.1.7.2 Resource Server for OAuth 2.0
Use
The resource server is a component of the OAuth 2.0 implementation. Using OAuth 2.0 access tokens issued by the authorization server, users can access the
resources. An access token includes the one or multiple OAuth 2.0 scopes.
More Information
OAuth 2.0 Scopes.
Resource
4.2 AS Java Authentication Infrastructure
Use
The authentication infrastructure of the SAP NetWeaver Application Server (AS) Java implements the Java Authentication and Authorization Service (JAAS)
standard to support various authentication methods. This enables you to choose the authentication mechanisms for your applications in a pluggable manner, using
login modules and login module stacks.
Integration
Applications running on the AS Java can either use declarative or programmatic authentication. Both types of authentication rely on the same underlying
technology, login modules and login module stacks.
For more information about the difference between the two ways applications can use authentication on the AS Java, see Declarative and Programmatic
Authentication .
Features
Login Modules
Authentication on the AS Java is performed using predefined authentication classes, referred to as login modules. A login module contains an implementation of a
Java class that defines authentication logic.
For more information, see Login Modules .
Policy Configurations and Authentication Stacks
The various components on the AS Java, such as applications, services, or modules, are registered with the AS Java security services so that you can apply
security restrictions to them. The set of security restrictions for an AS Java component is referred to as a policy configuration.
To enforce different authentication logic in a component's policy configuration, you can define groups of login modules. Such groups are referred to as login module
stacks or authentication stacks. Login module stacks enable you to choose or combine different combinations of authentication mechanisms for access control to
the applications you create or for the different AS Java components.
For more information, see Policy Configurations and Authentication Stacks .
Session Management
The AS Java maintains application session for all interactions between user agents and stateful applications. Once a user has been authenticated the AS Java
creates a security session.
For more information, see Sessions .
Activities
You can use the authentication management functions of SAP NetWeaver Administrator to manage login modules, authentication stacks, and policy configurations.
The configuration options enable you configure options specific to the use of a login module in an authentication stack, or to perform batch configuration to globally
apply configuration options to each use of a login module in policy configurations.
For more information, see the following sections:
Managing Login Modules
Information about the configuration options you can use to globally apply configuration options to each use of a login module in policy configurations.
Managing Authentication Policy for AS Java Components
Information about configuring authentication stacks and login module instances in the policy configurations for AS Java applications. Includes information
about the configuration options you can use to apply configuration options to the individual use of a login module in a policy configuration.
4.2.1 Declarative and Programmatic Authentication

The AS Java enables applications to use two options for authenticating users:
Declarative authentication (also known as container-based authentication):
The application container of the AS Java handles authentication. A component running on the AS Java declares protected resources and the desired

authentication mechanism in its deployment descriptor. When a protected resource of this component is accessed, the container in which the component
runs performs authentication.
Programmatic authentication (also known as UME authentication):
Components running on the AS Java authenticate directly against the User Management Engine (UME) using the UME API. The component explicitly
triggers authentication and afterwards the authentication process is controlled by the authentication framework.
Both declarative and programmatic authentication use login modules and authentication stacks as their underlying technology.
You can configure the authentication policy for both types of applications using declarative or UME programmatic authentication with their deployment descriptors
web.xml and web-j2ee-engine.xml .
For more information, see Protecting Java Web Applications .
After deployment, you can change this assignment in SAP NetWeaver Administrator.
For more information, see Editing the Authentication Policy of AS Java Components .
Portal applications and iViews have their own implementation of programmatic authentication that includes authentication schemes. The authentication scheme in
turn references a login module stack.
For more information, see Login Modules and Login Module Stacks and authentication schemes in the portal documentation.
Integration
The different types of applications can use different means for defining the login module stack to use in its policy configuration. For more information, see the table
below:
Application Type Type of Authentication Where is Login Module Stack defined
Web applications Declarative authentication Declared in the web.xml deployment descriptor of the Web
application.
For more information, see Protecting Java Web
Applications .
Web applications Programmatic authentication This depends on how the application is programmed.
Applications can define an authentication scheme in their
calls to the API. By default, if they do not define an
authentication scheme, these applications use the login
module stack referenced by default in the authentication
schemes file.
Web Dynpro applications Programmatic authentication For more information, see Security Aspects of Web
Dynpro for Java .
Portal iViews Programmatic authentication An iView property defines which authentication scheme
the iView uses. The authentication scheme references a
login module stack.
Declarative and programmatic authentication are integrated so that if an application uses programmatic authentication to authenticate its users, the container where
it runs on the AS Java is also aware that the users are authenticated. Inversely, if an application uses declarative authentication to authenticate its users, UME is
also aware that the users are authenticated. Calls to the APIs of both the container and UMEreturn the authenticated user.
Note
If you change the default authentication scheme, this also affects any portal iViews and Web applications that use the default authentication scheme.
4.2.2 Login Modules
Use
The SAP NetWeaver Application Server (AS) Java enables you to use Java Authentication and Authorization Service (JAAS) login modules to authenticate user
access requests. The JAAS login modules represent the basic building blocks for the authentication mechanisms that you configure for access to applications
and components running on the AS Java.
Integration
The AS Java provides a number of predefined login modules. You can create your own login modules to implement custom authentication logic.
For more information, see Developing Authentication Enhancements on the AS Java .
You can combine the standard and custom login modules in login module stacks. To configure the authentication mechanisms of your applications, assign login
module stacks to their policy configurations.
Standard AS Java Login Modules

The following tables provide an overview of the standard login modules delivered with the AS Java.
Login Modules for User ID and Password Logon
The login module in the table below support the available methods for logon with user ID and password.
For more information about configuring the use of these login modules, see Using User ID and Password for AS Java Logon .

Login Module Name Description
BasicPasswordLoginModule Performs logon for Basic or Form authentication. You can use this login module to
perform authentication with user ID and password.
Login Modules for Logon Tickets

The login modules in the table below support Single Sign-On (SSO) with logon tickets.
For more information about configuring the use of these login modules, see Using Logon Tickets with AS Java .
EvaluateTicketLoginModule Login module to evaluate logon tickets used for SSO.
CreateTicketLoginModule Login module to create logon tickets after successful user logon.
Login Modules for Client Certificates

The login modules in the table below support authentication with client certificates.
For more information about configuring the use of these login modules, see Using X.509 Client Certificates with AS Java .
ClientCertLoginModule You use this login module for user authentication with client certificates.
CertPersisterLoginModule Performs automatic certificate mapping on first user logon. You use this login module in
authentication stacks with the ClientCertLoginModule .
Login Modules for SAML 1.x

The login module in the table below supports SAML 1.x authentication.
For more information about configuring the use of this login module, see Configuring AS Java as a SAML Destination Site .
SAMLLoginModule Performs user authentication using the SAML assertions.
Login Modules for SAML 2.0

The login module in the table below supports SAML 2 authentication.
For more information about configuring the use of this login module, see Configuring AS Java as a Service Provider .
SAML2LoginModule Performs user authentication using the SAML assertions.
Login Modules for Kerberos

The login modules in the table below support Kerberos authentication with the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO).
For more information about configuring the use of these login modules, see Using Kerberos Authentication .
SPNegoLoginModule Used for Kerberos authentication with SPNego.

This login module implements the Simple and Protected GSSAPI Negotiation
Mechanism (SPNEGO) on the AS Java.
SPNEGO is a standard Generic Security Services Application Program Interface (GSS
API) pseudo-mechanism. It is used to determine which GSS API mechanisms are
shared, select one and then establish a security context for communication with it.
Krb5LoginModule The login module is invoked to obtain the AS Java credentials from the Kerberos keytab
file.
The Krb5LoginModule succeeds only if the attempt to log on to the Kerberos KDC as a
specified entity is successful. Therefore, the Krb5LoginModule is a required login module
for Kerberos authentication.
MappingModule The MappingModule is used to retrieve the service user for the AS Java on the Kerberos
KDC.
Login Modules for Header Variables

The login module in the table below supports authentication with header variables.
For more information about configuring the use of this login module, see Using Header Variables .
HeaderVariableLoginModule Login module for SSO using header variables.
Login Modules for Resource Adapters

The login modules in the table below support the available methods for SSO with assertion tickets.
For more information about configuring the use of these login modules, see Single Sign-On for Resource Adapters and JCA .
EvaluateAssertionTicketLoginModule Login module used to evaluate Authentication Assertion Ticket. used for SSO.

CreateAssertionTicketLoginModule Login module to create Authentication Assertion Tickets after successful
logon.
In addition, the Java Connector Architecture for the AS Java can use the following login modules.
CallerImpersonationMapping LoginModule Used when the credentials of the caller principal are directly passed to the Enterprise
Information System (EIS) and used for authentication of the resource principal.
ConfiguredIdentityMapping LoginModule Used when all caller principals obtain a connection to the EIS using the same
preconfigured identity. You have to specify either a user store that contains the identity, or
a user name and a password for the configured identity.
CredentialsMappingLoginModule Used when the credentials of the caller principal are replaced by the credentials that are
used for authentication to the EIS; in this case, you have to specify a user store where
the EIS credentials are stored.
PrincipalMappingLoginModule Used when particular caller principals are mapped to an EIS principal. Only authorized
caller principals can obtain a connection using a specific identity. You can either specify
the user store where this identity is stored, or enter the name and the password of the
resource principal.
Other Login Modules
CSILoginModule Login module for the IIOP service.
SecuritySessionLoginModule Login module used by download.ear. It uses the tickets that are generated by the Security
Provider service on the engine.
4.2.2.1 Managing Login Modules
Use
To add or update a custom login module, you use the Deploy view of the SAP NetWeaver Developer Studio.
To change the options of a login module or to remove a standard login module, you use the authentication configuration functions of the SAP NetWeaver
Administrator.
To remove a custom login module, you use the Undeploy view of the Developer Studio.
Inheriting login module options
If you change the options of a login module in the user store, the changes will be inherited by all policy configurations that use this login module.
If you change the options of a login module in a single policy configuration, the change applies only to that policy configuration. In this case, the login module no
longer inherits its options from the user store. To restore the inheritance, change the options in the policy configuration or in the user store so that they are identical.
If you are deploying a Web application you can set it to automatically inherit the options of a login module in the user store. To do this, enter the login module's
display name in the Web deployment descriptor's tag <login-module-name> , for example: BasicPasswordLoginModule. In this case the system ignores
the options you configure in the Web deployment descriptor. If you want to configure specific login module options for a Web application, enter the class name of
the login module, for example: com.sap.engine.services.userstore.jaas.BasicPasswordLoginModule. In this case the system ignores the
options in the user store and uses the options you specify in the deployment descriptor.
More information about the Web deployment descriptor: web-j2ee-engine.xsd .
The type of the project in the SAP NetWeaver Developer Studio must be an Enterprise Application Project so that you can export a deployable file with an
extension .ear. The Enterprise Archive (EAR) file must contain the following two files:
• A JAR file, containing the login module, which is generated from another Java Project . The Enterprise Application Project must have a Java EE Module
Dependency to the Java Project so that the JAR file is included in the EAR file.
• A LoginModuleConfiguration.xml file that should be located in the root directory of the EAR file.
Procedure
Add or update a login module
1. Make sure the connection to the AS Java is properly configured.
To check the connection, from the menu path choose Window Preferences and choose SAP AS Java . Adjust the parameters if necessary, for
example: in the field Instance host enter localhost, in the field Instance number enter 0 and then choose Register SAP Instance .
2. From the menu path, choose Window Show View Other .
3. In the dialog that appears, choose Deploy View Deploy View .
4. In the Deploy view tab, choose Workspece Deployable Archives or External Deployable Archives , depending on the location of your deployable file.
5. Define the Update Strategy :
If you are deploying the login module for the first time, then you can leave the default settings.
If you are updating a login module, select the proper Update Strategy .
6. Choose the button with the quick info text Add element .
If you selected Workspace Deployable Archives , then a dialog containing all deployable archives in your workspace appears. Select the archive
that contains the login module you want to deploy and choose OK .
If you selected External Deployable Archives , then browse to the location of the archive that contains the login module you want to deploy. Select the

archive and choose Open .
7. To deploy the login module, choose the button with the quick info text Deploy .
Caution
The deployable file must contain a JAR file with the class of the login module and a configuration XML file with the name
LoginModuleConfiguration.xml . The configuration file contains the display name, the class name and the options of the login module and is
used by the system to automatically register the login module on the AS Java.
Note the following:
The display name of the login module must be unique in the user store.
The display name of the login module must not be the same as its class name.
If you are updating a login module, do not change its display name.
More information: Creating the Configuration File for Login Modules .

Manage login module options
1. Using the SAP NetWeaver Administrator, go to Configuration Management Security Authentication and Single Sign-On Authentication .
2. Choose the Login Modules tab.
3. Select the login module whose options you want to change.
4. In the Login Module Options tab choose Edit .
To add an option for the selected login module, do the following:
1. Choose the Add button with the quick info text Add new login module option .
2. Enter the name of the new login module option.
3. Enter the value of the new login module option.
4. Choose Add .
To remove an option from the login module, select the option and choose Remove .
5. Choose Save to save your changes, or choose Cancel to cancel all changes to the last saved configuration.
Remove a Login Module
Caution
Before removing a login module, make sure you have removed that login module from all policy configurations that use it. Otherwise those policy configurations
will not work properly after the login module is removed.
To remove a login module (for example: BasicPasswordLoginModule), proceed as follows:
1. Using the SAP NetWeaver Administrator, go to Configuration Management Security Authentication and Single Sign-On Authentication .
2. Choose the Login Modules tab.
3. Select the login module that you want to remove and choose Delete .
To remove a custom login module, you use the Undeploy view of the Developer Studio:
1. Make sure the connection to the AS Java is properly configured.
To check the connection, from the menu path choose Window Preferences and choose SAP AS Java . Adjust the parameters if necessary, for
example: in the field Instance host enter localhost , in the field Instance number enter 0 and then choose Register SAP Instance .
2. From the menu path, choose Window Show View Other .
3. In the dialog that appears, choose Deploy View Undeploy View .
4. On the Undeploy view tab, select the login module you want to remove.
5. Choose the button with the quick info text Add Items to undeploy list .
6. Choose the button with the quick info text Undeploy all items in the list , to undeploy the selected login module.
Caution
All login modules that have the same class name as the undeployed module will also be removed.
4.2.2.2 Creating the Configuration File for Login Modules
Use
The system uses the LoginModuleConfiguration.xml file to automatically register a deployed login module in the user store of the AS Java.
To create this file you use the SAP NetWeaver Developer Studio.
Procedure
1. From the menu path, choose File → New → Other.
2. In the dialog that appears, choose XML → XML. Choose Next.
3. Specify the location where you want to create the configuration file. Specify LoginModuleConfiguration.xml as the name of the file. Choose Finish.
Caution
The name of the file must be LoginModuleConfiguration.xml . Otherwise the system will not recognize the file.
4. Open the configuration file. Delete any auto-generated content.

5. Implement the code of the configuration file. The structure of the file is shown below:

6.
XML Schema Description
Schema element / attribute Description
login-modules This is the root element of the configuration file. It contains the descriptions of all login
modules.
login-module This element holds the description of one login module.
Caution
If you are deploying more than one login module in the same deployable archive, do
not create different configuration files to describe each login module. Describe all
login modules in one configuration file.
display-name This element holds the display name of a login module. The display name must be
unique in the user store and must not be the same as any class name on the AS Java.
Caution
If you are updating a previously deployed login module, do not change its display
name.
class-name This element holds the full class path of the login module.
description This element holds the description of the login module.
options This element holds all the options of the login module. If you do not want to define any
options you can omit this element.
Caution
If you change the options when you are updating a login module, the new options
you define will override the previously defined options in the user store of the AS
Java.
The new options will be inherited by the policy configurations that use this login
module.
option This element holds the name and the value of one option.
name This element holds the name of an option.
value This element holds the value of an option.
1. Save the file.

2.
4.2.3 HTTP Sessions and Security Sessions on the AS Java
Use
Sessions are used to track information exchanged between the client and the server, and also preserve that information for as long as necessary. A session is
established at a certain point of time, and it is destroyed at a later time. The exact moments of session creation and session deletion depend on the settings for a
given session type.
Stateful Web Applications
Stateful web applications can store information between multiple requests. This allows the application logic on the server side to distinguish between interacting
clients while preserving information tokens for each client. To achieve this, stateful applications require the creation of HTTP sessions.

HTTP Sessions
By design the HTTP protocol is stateless, meaning that it does not retain information about the communicating parties and it cannot create its own sessions.
However, when there is a need to store information between multiple requests, a session mechanism can be utilized.
Creation of HTTP sessions: HTTP sessions are created by the stateful applications with which the user works. A user can have more than one HTTP session
to the AS Java for using different applications at the same time. One way of creating HTTP sessions is by using the APIs, defined in the Java Servlet
Specification. For more information about creating and tracking HTTP sessions, see: HTTP Sessions and AS Java Cookies .
Termination of HTTP sessions: The termination of an HTTP session could be determined explicitly by the application logic or by an automatic expiration
mechanism.
Security Sessions
The authentication information of a Web application user is stored in a session object on the AS Java's Web Container. This session is referred to as a security
session.
Creation of security sessions: A security session is created after the user logs in successfully to the AS Java.
Termination of security sessions: A security session lasts until all HTTP sessions associated with it expire, or are invalidated. On the other hand, if a security
session expires or is invalidated upon user logout, then all associated HTTP sessions are invalidated too.
Relations Between the Different Types of Sessions
After the user logs in, the AS Java creates a security session for this user. The AS Java also creates HTTP sessions, depending on the requirements of the
applications that the user accesses. These HTTP sessions are mapped to the security session that already exists for the user. One security session can have
many HTTP sessions mapped to it. An HTTP session can only be mapped to one security session.
Workflow
1. The user enters the URL of an application in the address bar of the browser.
2. The AS Java requests the user to authenticate.
3. The user authenticates successfully and the AS Java creates a security session for him or her.
4. The AS Java creates an HTTP session that will be used to track the interaction between the user and the application.
5. The AS Java maps the HTTP session to the security session.
Subsequently created HTTP sessions are also mapped to the security session that already exists for this user.
6. Session termination
The user logs out.
When the user logs out, the AS Java destroys the user's security session and that also invalidates the HTTP sessions.
Note
For applications protected by SAML 2.0, an explicit logout by the user or administrator can trigger a logout on all systems, which participate in the
SAML 2.0 Single Log-Out.
Sessions expire.
The AS Java or an administrator terminates one or more sessions because of a problem.
4.2.4 Policy Configurations and Authentication Stacks
Definition
The AS Java enables you to define the use of groups of login modules that contain different authentication logic. These groups are called login module stacks or
authentication stacks.
You assign the authentication stacks to the policy configurations of the applications you create or the AS Java components. This means that you can implement
different combinations of authentication mechanisms for the AS Java applications.
You can use the Web-based SAP NetWeaver Administrator (NWA) to configure runtime options for the policy configurations of AS Java components.
Policy Configuration Types

You can use the filtering functions in NWA to display and configure the policy configurations for the following AS Java components:
Web - policy configurations of all Web application types, for example servlets, portlets, Web Dynpro, portal, and composite applications
Service - policy configurations of services, such as service.iiop, service.telnet, and service.naming
EJB - policy configuration type for migrating existing EJB applications
Template -policy configuration type for standard authentication stacks to use as templates for standard authentication scenarios
Custom - policy configuration type for authentication templates created with the administration tools for the AS Java
Other - policy configuration type for applications that are not covered by the other types
Standard Authentication Stack Templates

You can use the AS Java policy configurations of type Template as authentication templates for standard authentication scenarios.
The standard authentication templates on the AS Java are listed below:
SAP-J2EE-Engine - the default authentication stack for the AS Java. Includes the BasicPasswordLoginModule for Basic or Form authentication.
Basic - supports basic authentication. By default, it includes the BasicPasswordLoginModule.
Client - supports client certificate authentication. By default, it includes the ClientCertLoginModule .
Form - supports form authentication. By default, it includes the BasicPasswordLoginModule.
Ticket - supports SSO with logon tickets. By default, it includes the following login modules:
EvaluateTicketLoginModule to evaluate logon tickets
BasicPasswordLogonModule for Basic or Form authentication for cases when the authenticated user does not have a valid logon ticket
CreateTicketLogonModule to create a logon ticket on successful authentication with the BasicPasswordLoginModule
Evaluation assertion ticket - used for verifying assertion tickets (tickets used between systems). By default includes the

EvaluateAssertionTicketLoginModule .
You can also use the NWA to extend the standard authentication templates by defining custom templates for authentication stacks. The AS Java registers custom
authentication stacks of this type in policy configurations of type Custom . Therefore, to apply a custom policy configuration that you create, you choose it from the
Custom policy configuration types. You can use the standard authentication templates as a basis to develop your own templates or to customize the use of
authentication for AS Java components.
Login Module Flags

You can combine login modules to create authentication stacks that combine the authentication logic for several authentication mechanisms. To perform
authentication, the complete set of login modules is processed in accordance with their place in the authentication stack. The order in which these login modules
are called during the authentication process corresponds to the order in which a client can be authenticated to the AS Java. Following the JAAS specification,
each module is processed in accordance with its login module flag, which you configure.
For more information about the flags that you can use for login modules in an authentications stack, see the table below:
Flag Required to Succeed Description
OPTIONAL No Authentication proceeds down the list regardless of

whether the module has succeeded or has failed.
REQUIRED Yes Authentication proceeds down the list of modules

regardless of whether the module has succeeded or failed.
REQUISITE Yes If successful, the authentication proceeds down the list,

otherwise control returns to the application - that is, the
authentication does not proceed.
SUFFICIENT No If the authentication is successful, control returns to

application; otherwise, the authentication proceeds.
Logon Policy Configuration

You can configure a logon policy for each policy configuration. By performing this configuration, you set rules and conditions for user authentication. If you do not
specify a logon policy, the system generates a default one that allows every user to log on. To enable the use of logon policies of this type, you have to set the
property ume.logon.apply_logon_policies. For more information, see Setting a Logon Policy for a Policy Configuration .
Example
The following table shows how a login module stack is processed based on these flags.
Login Module Stack Processing
Module Flag Pass/Fail Pass/Fail Pass/Fail
Module 1 SUFFICIENT Pass Fail Fail
Module 2 REQUISITE * Pass Fail
Module 3 OPTIONAL * Pass *
Overall authentication Pass Pass Fail
4.2.4.1 Creating Authentication Stack Templates for Policy

Configurations
Context
Create a custom policy configuration template to apply an authentication stack to different components without having to configure the policy configuration of
components individually. Changes to the custom policy configuration then apply to all components that use this template.
Procedure
1. Start SAP NetWeaver Administrator with the quick link /nwa/auth .
2. Choose Components .
3. Choose the Create pushbutton.
4. Enter a name.
5. Select Custom in the Type field.
Results
Edit the authentication stack and apply the custom template to policy configurations.

For more information, see Editing the Authentication Policy of AS Java Components .
4.2.4.2 Editing the Authentication Policy of AS Java Components
Context
The authentication management functions of SAP NetWeaver Administrator enable you to determine what kind of authentication is required for users to access a
component. You can create custom policy configuration templates and apply them to components. You can modify the policy configurations of components
directly. These policy configurations determine what login modules are in the authentication stack and any configurations that apply to that stack.
When you change the configuration options for login modules in the authentication stack of a policy configuration, the login module options apply only to the
component policy configuration where the login module is used. To apply a global change, you need to modify the login module itself.
For more information, see Managing Login Modules.
The authscheme and authscheme reference policy configuration types are only useful if you have the SAP EP available. For more information, see the Portal
Authentication Infrastructure section.
Procedure

2. Choose Configuration Management Authentication and Single Sign-On Authentication Components .
3. Select a policy configuration.
4. If you want to apply a logon policy to the policy configuration, select the logon policy.
To enable the use of logon policies, you have to set the property ume.logon.apply_logon_policies . For more information, see Setting a Logon Policy for a
Policy Configuration .
5. On the Authentication Stack tab, choose the Edit pushbutton.
6. Determine whether you want to use an existing template, or to change the policy configuration of the current component.
To use an existing template, select a template from the Used Template field.
For authscheme references, select a template from Used Authscheme .
The component uses the settings and authentication stack from the template. To edit these settings, edit the settings of the policy configuration
template. To create a new template, see Creating Authentication Stack Templates for Policy Configurations .
To change the policy configuration of the current component, proceed as follows:
1. Add and remove login modules as required.
The system applies the login modules in the order they appear in the list.
2. Set a processing flag for each login module.
For more information about login module flags, see Policy Configurations and Authentication Stacks .
3. Add options to and/or remove options from the login modules.
4. Set the authentication stack parameters in accordance with the type of policy configuration.
The following table lists the parameters available for the different types of policy configurations.
Parameter Policy Configuration Types Description
Front-end Target Authscheme Defines which iView the system launches when a
Authscheme Reference user's session does not satisfy the authentication
scheme.
Policy Domain Web A user that accesses a Web application in a policy

domain can access another Web application in the
same policy domain without reauthenticating.
For more information, see Single Sign-on for Web
Applications .
Priority Authscheme A user that accesses an iView with one

Authscheme Reference authentication scheme can access an iView with a
lower priority authscheme without reauthenticating.
Session Fixation Protection Custom Determines how the component handles parallel
Template HTTP requests. By default, the Common Session
Web Management applies a strict policy, allowing access
to resources only when the authentication types are
identical and within the grace period. By default, the
grace period is 2 seconds.
Caution
Use this property with caution.
For more information, see Parallel HTTP
Requests and Session Fixation Protection .
To allow parallel requests with different
authentication types within the grace period,
choose Grace Period .
Otherwise, choose Strict .
4.2.4.3 Configuring Authentication Properties

Context
The authentication properties are UME properties that control the default behavior of the authentication mechanism of the AS Java, the default logon application,
and portal authentication settings.
Procedure
2. Choose the Properties link.
3. Choose the Modify pushbutton.
4. Enter data as required.
Choose the Information pushbutton to display more information about the property.
4.2.4.4 Setting a Logon Policy for a Policy Configuration
Use
Logon policies are used to set restrictions for authentication for specific policy configurations. You can set the policy configuration to use a specific logon policy.
When setting a logon policy [for a policy configuration], consider the following:
Logon Policies
The logon policy specifies the rules that apply for users under this policy configuration. For a successful authentication, there must be at least one
successful rule. If you do not set a specific logon policy for a policy configuration, the system uses a default one that is automatically generated.
Caution
The default logon policy is automatically set to allow every user to log on at any time. If you decide to change its settings, make sure that you do not set
restrictions that will prevent you from logging on to the whole system. If this does happen, you can log on only with the emergency user SAP* . Also,
you cannot rename or delete the default logon policy.
Caution
If you log on with the emergency user SAP* , the system does not apply the logon policy. For more information about emergency users, see Activating
the Emergency User .
Rules
Each rule contains a set of conditions that specify the cases in which the user is allowed authentication. A rule is successful when all conditions of that rule
allow authentication.
Conditions
Each condition evaluates the current request and allows user authentication in accordance with the fulfillment of the condition and its type. A condition is
fulfilled when the user complies with the value of the condition. There are four possibilities:
Condition Type
Allow
Allow
Deny

Deny
Procedure
To configure the logon policies, proceed as follows:
1. Set the property ume.logon.apply_logon_policies to allow the use of logon policies during authentication. You can set this configuration in SAP NetWeaver
Administrator by choosing Configuration Authentication and Single Sign-On Authentication Properties and selecting the checkbox Apply
logon policies during authentication (ume.logon.apply_logon_policies): .
Note
The option Apply logon policies during authentication (ume.logon.apply_logon_policies): is disabled by default.
2. Access the logon policies window by choosing the Logon Policies link.
3. Add a new logon policy by choosing the Add button.
4. Add at least one rule for the logon policy.
5. Add at least one condition for each rule.
Each condition contains three elements:
Type
Allow
This type allows authentication of a user that fulfills the condition. A user that does not fulfill the condition is denied authentication.
Deny
This type allows authentication of a user that does not fulfill the condition. A user that fulfills the condition is denied authentication.
Category
The category specifies what kind of condition the system uses. You can configure the following categories:
Category Description
User Defines a condition for allowing or denying the authentication of a user with a
specific logon ID.
Note
A user with this logon ID must exist and must be unique.
Role Defines a condition for allowing or denying the authentication of users that have a
specific role.
Note
The role must exist in the user management engine (UME).
Group Defines a condition for allowing or denying the authentication of users that are
members of a specific group.
Note
The group must exist in the user management engine (UME).
Days of Week Defines a condition for allowing or denying the authentication of users on specific
days.
Time Defines a condition for allowing or denying the authentication of users in a specific
time period on the days.
HTTP Header Defines a condition for allowing or denying the authentication of users in
accordance with the HTTP header name and value.
Caution
Users submitting requests that do not contain headers , such as Web
service requests , are allowed authentication by the HTTP Header condition
when the type is Deny .
IP Address The user can enter an Internet Protocol (IP) version 4 (IPv4) address or an IP
version 6 (IPv6) address. In addition, the user has to enter a subnet prefix after the
slash (/) symbol that specifies how many bits of the IP address are used for the
condition.
Caution
Regardless of the IP address settings, in local requests all IP Address
conditions of the type Allow allow authentication and all IP Address
conditions of the type Deny do not allow authentication.
Caution
If there is a proxy in front of the server, all IP conditions will check the IP of
the proxy by default. For the system to check the client's IP address, you have
to do the following:
Configure the proxy to send the IP address of the client in the X-
Forwarded-For header.

Configure the HTTP provider service to read the IP from this header.
For more information, see HTTP Provider Service .
Set the property ClientIpHeaderName to X-Forwarded-For .
Condition Value
Specify only one value for all categories except Days of Week and Time . To add or edit a value, choose the Modify Condition Value button.
The following categories have specific requirements for their values:
HTTP Header
You can set the value in a regular expression format. If you select the checkbox Use regular expression for the HTTP Header category, the
system checks whether the header value matches the regular expression pattern.
Example
Michael wants to configure his system to allow HTTP requests with a header containing the value <name>@company.com . To do this, he
sets the HTTP header name From with the regular expression value (.+)\Q@company.com\E and selects the regular expression
checkbox. When a user John with the e-mail address john@company.com makes an HTTP request, the system finds the name-value
pair From: john@company.com in the request, checks the regular expression pattern, and authenticates the user.
IPv4
An IP version 4 address contains 32 bits. Each decimal number, which is in the range of 0 to 255, before or after the dot, represents an 8-bit
binary number. The subnet prefix defines which most significant bits in the request must match the entered IPv4 value. If you set the maximum
number 32 for the prefix, the system will check if all the bits in the IP address match.
Example
If you set an IPv4 address and prefix with a value 145.234.10.1/ 24 , then the system will check if the request's IP address starts with
the decimal numbers 145.234.10 . The subnet prefix 24 signifies that the 24 most significant bits (145.234.10) are used for the condition
validation.
IPv6
An IP version 6 address contains 128 bits. Each hexadecimal number before or after the colon represents a 16-bit binary number. Furthermore,
the subnet prefix defines the most significant bits that are to be checked for the IP address condition. If you set the maximum number 128 for
the prefix, the system will check if all the bits in the IP address match.
Example
If you set an IPv6 address and prefix with a value 2012:0db8:85a3:0052:0010:8a2e:0370:7334/ 64 , the system will check
whether the request's IP address starts with the hexadecimal numbers 2012:0db8:85a3:0052 . The subnet prefix 64 signifies that the
64 most significant bits (2012:0db8:85a3:0052) are used for the condition validation.
Note
For the default logon policy, the system generates one condition with Type Allow , Category Role , and Condition Value Everyone .
6. Activate the rule(s) you want to apply.
Caution
The system ignores inactive rules.
7. Activate the logon policy.

9. Choose the Components link and select the policy configuration to which you want to assign the logon policy.
10. Choose the Authentication Stack tab and select the logon policy.
Caution
If the logon policy is inactivate , the system will apply the default logon policy.
Example
Denise Smith wants to configure her system to allow all users except administrators to log on every working day of the week from 09:00 to 18:00. In addition, she
wants to allow administrators to log on to the system on Mondays, Wednesdays, Fridays, Saturdays, and Sundays from 18:00 to midnight with an IPv6 address
that starts with the numbers 2012:8329 . She therefore creates a logon policy users and sets two rules named userRule and adminRule .
For the userRule , she sets the following conditions:
Type Category Condition Value
Allow Group Everyone
Deny Group Administrators
Allow Days Of Week Monday, Tuesday, Wednesday, Thursday, Friday
Allow Time from 09:00 to 18:00
For the adminRule , she sets the following conditions:
Type Category Condition Value
Allow Group Administrators
Allow Days Of Week Monday, Wednesday, Friday, Saturday, Sunday
Allow Time from 18:00 to 24:00

Allow IP Address 2012:8329:0:0:0:0:0:0 / 32
After Denise adds the users logon policy to her policy configuration, she tests her system with user Michael and administrator Julie. Michael accesses the
system at 10:00 on Monday. Because he is a member of the group Everyone and he is not a member of the group Administrators , the first rule succeeds and
he is able to log into the system. Julie decides to log on at the same time as Michael does with the IPv6 address
2012:8329:0000:0000:0456:ff00:0042:0db8 . The first rule userRule fails because its second condition with value Administrators does not allow
authentication. The second rule also does not succeed because the condition Time does not comply. Because both rules fail, Julie is denied access to the
system. She then calls Denise and asks for help. Denise advises her to try again the same day after 6 o'clock in the evening and informs her of the logon
principles for administrators. When Julie tries again at 19:00, she is able to log on with the same IPv6 address, which proves to Denise that the configuration is
working properly.
4.2.5 User Mapping and the AS Java
Use
User mapping is only necessary for Single Sign-On (SSO) when users have different user IDs in the SAP NetWeaver Application Server (AS) Java and in the
back-end systems.
Caution
When possible, avoid user mapping by using the same user ID in the portal and back-end ABAP systems and enable SSO with tickets. If you cannot avoid
user mapping, configure the connection to the back-end system to use Secure Sockets Layer (SSL) and Secure Network Communications (SNC).
More information: Transport Layer Security
If you cannot avoid different user IDs in the AS Java and back-end systems, you can use user mapping to enable SSO. With user mapping you define systems
in the destination service. Then for the defined systems you map AS Java users to back-end system users with the user management engine (UME).
When an application, which is programmed to use the destination service, attempts to connect to a back-end system, the AS Java requests the connection
information from the destination service. If the system is configured for user mapping, the destination service queries the UME about any user mapping for the
current user. The AS Java uses this information to establish a connection to the target system.
User Mapping with User ID and Password

This method maps a user, group, or role with a user ID in the back-end system. When the application tries to connect to the back-end system, the UME tries to
map the user to a user in the remote system. The UME does this bay checking for mappings in the following order:
1. To the AS Java user
2. To any group the AS Java user is a member of
3. To any roles the AS Java user is directly assigned
User mapping does not support mappings to indirect role assignments
The AS Java uses the first mapping found. If the AS Java does not find any mappings that apply, the application prompts the user to enter mapping data,
assuming the application developer programmed the application to do so.
Caution
If you map to a single user in the back-end system, do not map to a super user or administrative user. If you must map to a single user, we recommend
mapping to a guest user with the required rights. Do not map users to back-end accounts, which would pose a security risk if the users learned the user ID
and password.
Note
If you do not maintain individual user-to-user mappings, map roles or groups to a user in the back-end system. If a specific AS Java user in the role or group
needs more or less authorization in the back-end system than allowed by the role-to-user or group-to-user mappings, you can create a user-to-user mapping
for this kind of exception.
Instead of creating mappings to groups like Everyone, consider creating a destination with Technical User authentication. The destination uses the configured
technical user regardless of the local UME user.
Do not create more than one of the same kind of mapping for the same back-end system. The AS Java uses the first mapping found. If you map two roles to
different users in the same back-end system and you assign both roles to an AS Java user, you cannot be sure which mapping the AS Java will use.
Some applications require user mappings to be unambiguous. Applications such as Universal Worklist, perform inverse user mapping and thus require a 1:1
relationship between front-end and back-end users.
See also:
Configuring User Mapping with User ID and Password on an AS Java
4.2.6 Application Server Java as a SAML 2.0 Provider
Use
SAP NetWeaver Application Server for Java (AS Java) supports the SP lite implementation of the Security Assertion Markup Language (SAML) version 2.0. The
following section describes implementation considerations for the use of AS Java as a SAML 2.0 provider.
Transient Pseudonyms and Auditing

Transient users in AS Java are realized as virtual users. AS Java records the creation of these virtual users in the security audit log. The audit log includes the
transient name ID and the name of the identity provider that created it. In this way, AS Java supports auditing of transient users. However, the identity provider
must also support auditing of transient pseudonym federation to identify the real user behind the transient name ID.
Authorizations
The AS Java delivers authorizations to protect access to the user interface for the configuration of SAML 2.0. The table below lists the user management engine
(UME) actions and the default role assignments for access to the configuration user interface.
Service/Application Name Description Default Role Assignments
saml2_cfg editSAML2Cfg Provides read/write access to the SAML 2 Administrator

and Key Storage Web Dynpro NWA_SUPERADMIN
applications. SAML2_SUPERADMIN
saml2_cfg viewSAML2Cfg Provides read-only access to the SAML 2 NWA_READONLY

and Key Storage Web Dynpro SAML2_READONLY
applications.
The SAML 2.0 implementation delivers the roles listed in the table below with AS Java.
Name Assigned Actions Description
SAML2_READONLY viewSAML2Cfg Provides read-only access to the SAML 2 and Key

Storage Web Dynpro applications.
SAML2_SUPERADMIN editSAML2Cfg Provides read/write access to the SAML 2 and Key

Storage Web Dynpro applications.
Note
The access that these roles and actions grant to the Key Storage application is not sufficient for general usage of that application, but rather sufficient access
for the administration of your SAML 2.0 configuration.
Kerberos and SAP NetWeaver AS for Java
Use
SAP NetWeaver Application Server (AS) Java supports Kerberos authentication for Web-based access with the Simple and Protected GSS API Negotiation
Mechanism (SPNego).
SPNego enables you to use Kerberos authentication without an intermediary web server and independently of the underlying operating system (OS) of the SAP
NetWeaver host.
Process
For an overview of the communication flow and the systems involved in Kerberos authentication with SAP NetWeaver, see the following figure.
Figure 1: Kerberos Authentication with SPNego
1. The Web client accesses an AS Java resource with a GET request.

2. The AS Java returns a 401 response code (unauthorized) with a request to initiate SPNego authentication.
3. The Web client recognizes that the host of the AS Java is a member of the Kerberos realm and procures a ticket from the KDC.

4. The Web client then sends the ticket to the AS Java wrapped as a SPNego token.
5. The SPNegoLoginModule reads the token and authenticates the user.
More Information
The AS Java uses SPNego to identify itself as a member of a Kerberos realm, determine a shared authentication mechanism and negotiate its use for
establishing a security context for further communication with the client.
For information about configuring Kerberos authentication for SAP NetWeaver systems, see Using Kerberos Authentication on SAP NetWeaver AS for Java .
5 Integration in Single Sign-On (SSO) Environments
Use
Single Sign-On (SSO) is a specialized form of software authentication that enables a user to authenticate once and gain access to the resources of multiple back-
end software systems. SSO enables authorized users to reliably and transparently access software resources across technical system boundaries.
Integration
Using SSO with your SAP NetWeaver systems complements user authentication and enables you to decrease the system administrative load when users need
to access resources in several different systems. In addition, integrating your systems in SSO environments can strengthen the overall security protection of your
systems and reduce security risks associated with securely storing authentication credentials and frequently providing them interactively to multiple back-end
systems in complex system landscapes.
SAP NetWeaver enables you to configure various mechanisms, which authorized users must use to access a SAP NetWeaver server system with SSO. The
mechanisms you can use and their configuration depends on the underlying technology of the SAP NetWeaver system and the communication channel used for
accessing the system.
Activities
For more information about configuring the AS ABAP, AS Java and the portal for integration in SSO environments, see the following sections:
Single Sign-On for SAP GUI
Single Sign-On for Web Based Access
Single Sign-On for Web Services
Interaction Between Systems (RFC and HTTP)
Single Sign-On for Java Remote Method Invocations
Single Sign-On for Resource Adapters and JCA
See also:
Authentication Concepts
Authentication Infrastructure
Developing Authentication Enhancements
5.1 Single Sign-On for the SAP GUI

The SAP GUI's Single Sign-On (SSO) functions enable you to configure transparent user authentication for access to AS ABAP systems.
With SSO, SAP GUI users can only select the AS ABAP system to log on to from the SAP Logon Pad, without needing to interactively provide a user name and a
password.
You can use the SSO functions of the SAP GUI to facilitate user access to multiple AS ABAP systems in an SSO environment. In addition, the use of SSO can
reduce your administration costs, while strengthening the overall security of your systems.
Note
In this scenario, you cannot use SNC Client Encryption.
Prerequisites
The SAP Logon Pad is installed on client computers. SAP GUI users that are enabled to use SSO can access AS ABAP systems by selecting them from
the SAP Logon Pad.
Use the SAP Cryptographic Library for authentication mechanisms that use cryptographic functions. For more information, see SAP Note 1848999 .
Features
For more information about configuring the AS ABAP authentication mechanisms for SSO when logging on from the SAP GUI, see the following topics:
Logon and Password Security
Information about configuring provided security mechanisms when using logon with a user ID and password, for example from an SAP shortcut.
Single Sign-On for SAP Shortcuts
Information about configuring SSO between a portal and an SAP shortcut.
Single Sign-On with Client Certificates
Information about the configuration steps to enable SAP GUI logon with client certificates
Single Sign-On with Microsoft Kerberos SSP
Information about the configuration steps to enable Kerberos authentication for the SAP GUI

Single Sign-On with Microsoft NT LAN Manager SSP
Information about the configuration steps to enable NTLM authentication for the SAP GUI
5.1.1 Logon and Password Security for SAP GUI
Use
This section contains information about configuring logon and password security in the AS ABAP.
Integration
As of SAP NetWeaver 04, you have the option to use stronger hashing algorithms for storing and transferring the authentication credentials for SAP GUI users. If
your security requirements mean that you need to use exclusively the non-backward compatible passwords of the new type, this affects the following components:
Communication frameworks (RFC, ICF) that transfer or store the passwords
Central User Administration, which distributes the password hash values
If you are using non-backward compatible passwords, communication with older systems (where the older system calls the newer system) and the shared use of
a Central User Administration that consists of old and new systems is no longer possible in principle. For more information, see SAP Note 792850 .
Features
To increase the authentication security in AS ABAP passwords are only stored and transferred as hash values. After SAP NetWeaver 6.40, the password hash
algorithm is changed from MD5 to SHA-1. This means that more secure hash values, which are not backward-compatible, and which make reverse engineering
attacks difficult, can be generated.
The new functions do not initially have any consequences after an upgrade; the operation of the system and password queries continue to run as usual. The
passwords of the new type gradually replace the passwords of the old type.
Initial Password
When you create a user master record, you must assign a password to the user. When a new user logs on for the first time, he or she must change the password.
To do this, the user enters the old password once and then the new password twice. When the user enters the new password, the system checks it against all
password rules defined by SAP and by the administrator.
The password must meet the internal requirements set by the SAP system and your own regulations. For more information about configuring passwords, see
Password Rules.
The following rules do not apply to administrator users:
List of invalid passwords or password templates in table USR040
Password history; that is, the password can also be one of the last five passwords used by the user
Minimum number of different characters between the old and the new password
Password Checks
Password Checks for Password-Based Logon
For every failed password check, the failed logon counter for the affected user master record is increased. If the user changes his or her password, the
system first checks the current password. If this check fails, the system increases the incorrect logon counter.
If the user exceeds the limit set by the profile parameter login/fails_to_user_lock, the user is locked. This operation is logged in the Security Audit
Log and in the Syslog. If a lock is set, subsequent password checks are immediately terminated (without a statement about the correctness of the
password).
The lock is regarded as invalid after the end of the current day. (Exception: see the profile parameter login/failed_user_auto_unlock.)
The failed logon counter is reset by a successful password check at logon or password change; this is also logged in the Security Audit Log. Non-password-
based logons do not affect the failed logon counter; active logon locks, that is, locks that the administrator has set in transaction SU01, are taken into account
at each logon or password change.
Password Checks for Non-Password-Based Logon
When you are using an SAP GUI logon, in the case of non-password-based logon variants (SSO: SNC, X.509, PAS, logon ticket), the system checks
whether the user has a password that must be changed.
In addition, administrator users can use the profile parameter login/password_change_for_SSO and its parameters to display various dialog boxes.
For more information about this, see the documentation for the profile parameter in transaction RZ11.
Logon Errors
If a user enters an incorrect password, then the system allows the user two retries before terminating the logon attempt. Should the user continue to enter an
incorrect password in subsequent logon attempts, then the SAP GUI connection is terminated. By default, this is done after three consecutive failed logon
attempts. You can use the parameter login/fails_to_user_session_end to specify the number of logon attempts that the system should allow before
terminating the connection. For more information, see Profile Parameters for Logon and Password (Login Parameters).
The user can repeat the logon attempt until he or she enters a valid user ID or until the permissible number of logon attempts is exhausted (parameter
login/fails_to_user_lock). After SAP NetWeaver 04, the system differentiates between upper- and lower-case.
The locking of a user due to incorrect logon attempts with a password only applies on the same day (see the parameter login/fails_user_auto_unlock);
however, the user administrator can also remove the lock earlier.
5.1.1.1 Password Rules

Password rules define what form a password can take in SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP. Some rules are predefined in the
system, while others you can configure with the security policy or with profile parameters.
Rule Comment
The password must be at least 3 characters long. Configurable with security policy or profile parameters.
The password cannot be more than 40 characters long. Predefined by the system.

Any Unicode characters can be used. The system differentiates between upper and You can configure how many digits, letters, and special characters are required in new
lowercase. passwords with the security policy or profile parameters.
.
The first character cannot be an exclamation point (!) or a question mark (?). Predefined by the system.
The first three characters cannot all be the same. For example AAA is not allowed. Predefined by the system.
The password may not be in the list of impermissible passwords (table USR40). Configurable. The default value is that all passwords, except PASS and SAP* are
allowed.
The list contains character combinations or terms, where the asterisk (*) and question
mark (?) can be used as placeholders. Asterisk (*) stands for a character sequence, and
the question mark (?) for a single character.
If you break this password rule when assigning initial passwords in user maintenance
as an administrator, you only receive a warning.
The password may not be PASS or SAP* Predefined by the system.
If the user changes the password, the new password cannot be the same as the last Configurable with security policy or profile parameters.
<n> passwords of the user. You can set the size of the password history (up to 100 passwords selected by the user).
You can reset a user's password to any initial password, therefore also to one of the last
<n> passwords for this user. This is necessary, because you, as the administrator,
should not know the passwords of the users, even past passwords. At the first interactive
logon, the system prompts the user to change the initial password.
Users can only change their password after they have entered the old password correctly. Predefined by the system
Users can change the password by choosing System User Profile Own Data
(transaction SU3).
Users can only change their passwords again after a wait period. Configurable with security profile or profile parameters.
The system can reject all password changes during the wait period (in days). If you, as
an administrator, change a user's password, the user must change this initial password
the next time he or she logs on, regardless of when he or she last changed his or her
password.
System administrators can still change passwords as often as necessary.
The password must contain at least <n> lowercase letters. Configurable with security profile or profile parameters.
The password must contain at least <n> uppercase letters. Configurable with security profile or profile parameters.
At least one character in the new password must be different from the old password. Configurable with security profile or profile parameters.
The current password must conform to the current password rules, the user must Configurable with security profile or profile parameters.
change the next time he or she logs on.
An unused productive password (a password set by the user) is valid for a maximum of Configurable with security profile or profile parameters.
<n> days. After this period has expired, the user can no longer use the password for authentication.
The user can still use some other logon method, such as X.509 certificate. You, as the
user administrator, can reactivate password-based logon for this user by assigning a new
initial password.
An unused initial password (a password set by the administrator) is valid for a Configurable with security profile or profile parameters.
maximum of <n> days. After this period has expired, the user can no longer use the password for authentication.
The user can still use some other logon method, such as X.509 certificate. You, as the
user administrator, can reactivate password-based logon for this user by assigning a new
initial password.
Related Information
Security Policy Attributes for Logon and Passwords
Profile Parameters for Logon and Password (Login Parameters)
Programmatically Checking Passwords Against the Password Rules
5.1.1.2 List of Customizing Switches for Generated Passwords

You specify the minimum requirements for generated passwords that are generated in User Maintenance (transactions SU01 and SU10) in profile parameters.
Use customizing switches to define upper limits for some values. These switches correspond to the relevant profile parameters for passwords.
Table 1: Customizing Switches and Corresponding Profile Parameters
Customizing Switch System Profile Parameter Notes
GEN_PSW_MAX_LETTERS login/min_password_letters Maximum number of digits in the generated password
GEN_PSW_MAX_DIGITS login/min_password_digits Maximum number of letters in the generated password
GEN_PSW_MAX_SPECIALS login/min_password_specials Maximum number of special characters in the generated

password
GEN_PSW_MAX_LENGTH login/min_password_lng Maximum length of the generated password
If you do not maintain these parameters, the respective default value is used.
The values of the system profile parameters have precedence over the customizing switch values. If the entries are contradictory, the values of the customizing
switches (GEN_PSW_MAX_*) are ignored and the default values are used.
Example
Even if you set the profile parameter login/min_password_specials = 2 and the customizing switch GEN_PSW_MAX_SPECIALS = 0 , the system
detects the contradictory settings. The system then ignores the customizing switch GEN_PSW_MAX_SPECIALS and uses only the profile parameter value.

5.1.1.3 Logging Off Inactive Users
You can set up your SAP System to automatically log off users with no activity after a specified period of time. This improves system security by assuring that
SAP sessions at unattended terminals do not stay active indefinitely.
By default, automatic logoff is not activated in the SAP System. Users remain logged on no matter how long they may be inactive. You activate automatic logoff by
setting the system profile parameter rdisp/gui_auto_logout to the number of seconds of inactivity you want to permit. Enter as a value for this parameter
the number of seconds of inactivity that must elapse before a user is automatically logged off.
If you activate this function, the inactive users are logged off after the specified period expires. The system does not save data before logging off the user. Unsaved
data in the user session is lost. The system also does not display a logoff confirmation prompt.
Procedure
To activate automatic logoff, proceed as follows:
1. Call the system profile maintenance functions with Administration →CCMS → Configuration →Profile maintenance (transaction RZ10).
2. Define or maintain parameter rdisp/gui_auto_logout. Enter as a value for this parameter the number of seconds of inactivity that must elapse before a user
is automatically logged off.
To activate automatic logoff throughout the system, set the parameter in the default profile (DEFAULT.PFL). However, if you want to activate automatic logoff
only for a specific SAP application server, set the parameter in the profile for that particular instance.
Caution
Remember that some users are inactive for extended periods of time. Such users may include:
Programmers or other users of SAP editors, who regularly work for long periods of time only using the front end software.
Users that enter data only rarely, such as production employees who only enter data in the SAP System during certain procedures, such as when
materials are delivered.
You should either set a high value for parameter rdisp/gui_auto_logout, or deactivate automatic logoff on the servers on which such users are active.
This protects these users from loss of data or the inconvenience of having to log on again.
To deactivate automatic logoff, delete the parameter from your profile(s) or set it to the value 0.
5.1.2 Single Sign-On for SAP Shortcuts
Use
SAP NetWeaver enables you to configure SSO to an AS ABAP system from the SAP Enterprise Portal. You can use these functions to enable integrated access
from the portal to ABAP transactions available in the SAP GUI.
Recommendation
We recommend using SAP Single Sign-On instead of logon tickets for this scenario. This scenario does not support SNC Client Encryption.
For more information, see the documentation for SAP Single Sign-On.
For this scenario, the portal and the AS ABAP system use logon tickets to enable SSO. The logon ticket is passed to the SAP shortcut using a portal iView.
For an overview of the authentication process flow, see the following figure.

Figure 1: SSO Between Portal and SAP Shortcut
Prerequisites
Users have the same user ID in all of the systems they access using the logon ticket. Passwords do not have to be the same in all systems.
The Web browsers used for accessing the portal can accept cookies. For example, in Internet Explorer 5.0 you can configure the Web browser to accept
session cookies for the local intranet zone.
The ticket accepting AS ABAP system is located in the same DNS domain as the ticket issuing server system.
The clocks of the ticket accepting and issuing systems must be synchronized. If you do not synchronize the clocks, then the accepting system may receive
a logon ticket that is not yet valid, resulting in an authentication error.
The ticket issuing server must possess a public-key certificate and a public and private key pair to digitally sign the logon ticket.
The UME of the Portal and back-end AS Java systems use the same user store as the AS ABAP system.
Activities
1. Configure component systems to accept portal logon.
2. Restart the AS ABAP.
3. Integrate SAP GUI for Windows in a Portal iView.
5.1.2.1 Integrating SAP GUI for Windows in a Portal iView
Prerequisites
The AS ABAP is configured to accept and verify logon tickets.
For more information, see Configuring AS ABAP to Accept Logon Tickets
Context
To enable Single Sign-On (SSO) for SAP shortcuts, you must create and configure a portal iView that users of SAP GUI can use to launch a transaction on the
target SAP NetWeaver Application Server (AS) ABAP system.
Procedure
1. In the portal, create a system object for the target AS ABAP system you want to integrate and choose a system alias for the system object.

2. Create an iView using the SAP Transaction iView template.
1. In the portal, choose Content Administration Portal Content .
2. In the context menu of the folder in the Content Catalog , in which you want to create the iView, choose New iView .
3. In the iView wizard, choose SAP Transaction iView , then Next .
4. Enter the iView name, then choose Next .
5. Choose SAP GUI for Windows , then choose Next .
6. In the System field, choose the system alias for the system object you created in step 1, enter a transaction code, then choose Next .
7. Choose Finish .
3. Assign the iView to a role and assign the role to AS ABAP users.
Results
Portal users can launch transactions on the target AS ABAP system from the portal iView.
5.1.3 Single Sign-On with Client Certificates
Use
The AS ABAP enables you to configure the use of client certificates for SSO when users access the system from an SAP GUI.
For SAP GUI authentication with client certificates, the security context for authentication is made available from the GSS API of the AS ABAP system. Therefore,
to enable the use of client certificates for SSO, the AS ABAP system must be configured to use SNC.
Integration
The use of client certificates for logon with the SAP GUI makes use of public-key cryptography and the AS ABAP Personal Security Environment (PSE) for
establishing the user identity. The client certificate information, however, is used only for authenticating SAP GUI users. Transport layer security, the integrity and
confidentiality of the authentication credentials is enabled by the SNC used on the AS ABAP.
Prerequisites
To enable SAP GUI SSO with client certificates, users must possess valid client certificates. SAP GUI users can receive client certificates from an
established Public-Key Infrastructure.
The SAP GUI client computers and the AS ABAP systems must use SAP Single Sign-On or an external security product that enables the creation of a
Personal Security Environment (PSE). The use of an external security product is enabled by Secure Network Communications (SNC).
Note
You can use external security products for client certificate authentication that are certified by the SAP Partner Program. For more information about the
SAP certified security products, see http://service.sap.com/security .
Activities
To enable users and AS ABAP systems to use SSO with client certificates, you must:
1. Prepare the central instance.
2. Activating SSO on the SAP Logon.
3. Import the user's public-key certificates to the AS ABAP.
More Information
Configuring SNC for Using the SAPCRYPTOLIB on the AS ABAP
5.1.3.1 Preparing the Central Instance
Context
To use Single Sign-On with Client Certificates, you need to adapt the central instance profile and make sure that the necessary libraries are located in an
accessible directory.
With this SNC configuration, you can protect inbound and outbound RFC connections, run encrypted SNC communication, and Single Sign-On is possible with
SAP Single Sign-On. For more information on SAP Single Sign-On, see http://help.sap.com/nwsso.
Procedure
1. Copy the dll file for the security product that is certified for SSO with X.509 client certificates to a directory on the central instance.
2. In the instance profile of the central instance, configure the SNC parameters as shown below:

snc/enable = 1
snc/gss api_lib = <full_path> \ <filename> .dll
snc/identity/as = p:< DN name of the AS ABAP >
Note
The Distinguished Name part must match the Distinguished Name that you specify when creating the SNC PSE. For more information, see Setting SNC
Profile Parameters.
1. Observe the following:
Note
Although you can freely choose the Windows account under which the SAP system runs, it is normally SAPService<SID>.
Single Sign-On using the Microsoft Kerberos SSP with the Kerberos wrapper library is only available for user accounts that belong to the Active
Directory, that is, domain accounts. It cannot be used with local computer accounts.
2. Set the following parameters to allow users to be able to log on to the SAP system using user ID and password.
Note
The following profile parameters permit users to continue to use password-based access to the SAP system when SNC has been enabled. You
have to use these additional parameters at least once after enabling SNC to be able to log on to the SAP system as an administrator for
maintaining the mapping of Windows NT user accounts to SAP system user IDs (user and client). Once the mapping (at least for the
administrator) has been entered, you can disable further password-based logons by removing the respective profile parameter(s).
snc/accept_insecure_cpic = 1
snc/accept_insecure_gui = 1
snc/accept_insecure_rfc = 1
snc/permit_insecure_start = 1
3. To disable the user of user ID and password as a logon mechanism altogether, you can reset these parameters after maintaining the user mappings.
4. Stop and restart the SAP system so that the profile parameters take effect.
Next Steps
Creating or Replacing a PSE
5.1.3.2 Activating SSO on the SAP Logon
Prerequisites
You have Prepared the Central Instance for using SSO with client certificates.
Context
To enable the use of SSO with Client Certificate, you have to activate the use of SSO on the SAP Logon.
Procedure
1. Select an entry in the SAP Logon window and choose → Properties Advanced .
2. Select Enable Secure Network Communications .
3. In SNC name , enter:
p:< DN name of the AS ABAP >
Note
For a DN name of the AS ABAP, enter the distinguished name of the AS ABAP as configured on the central instance parameter
snc/identity/as
4. Choose OK to confirm your entries.
Results
The SAP Logon window now displays an icon with a key beside the system entry. This indicates that Single Sign-On is active for the system. Users can log on
to the AS ABAP from the SAP Logon.
5.1.4 Single Sign-On with Microsoft Kerberos SSP

Use
Kerberos Single Sign-On (SSO) is a secure method of logging on to the SAP system that simplifies the logon procedure. It is suitable if your clients use Windows
2000 or higher. The Application Server ABAP can run on the operating systems specified in the relevant Product Availability Matrix.

When your system is configured for SSO, an authorized user who has logged on to Windows can access the SAP system simply by selecting it in the SAP logon
window or using a shortcut. There is no need to enter a user ID and password every time that the user logs on to the SAP system with SAP GUI for Windows.
Therefore, SSO makes it easier for you to manage SAP system users.
The Microsoft Kerberos Security Service Provider (SSP) provides secure authentication plus encryption of the network communication. In contrast, SSO with
Microsoft NTLM SSP, as described in the next section, does not provide encryption of the network communication.
Note
When using the Kerberos wrapper library (gsskrb5.dll), the Microsoft Kerberos SSP might be interoperable with Kerberos implementations from other
vendors and suppliers. However, we do not provide support for third-party libraries loaded at the BC-SNC interface. Documentation and support must be
provided by the vendor(s)/supplier(s) of the third-party software. SAP SAP NetWeaver Single Sign-On and all third-party BC-SNC certified security products
offer data integrity and privacy protection. To use these security features, you must obtain a product license.
Prerequisites
SSO based on Kerberos can only be set up for users that are members of a Windows 2000 or higher domain.
Before beginning with the configuration, read SAP Notes 352295 and 595341 .
Activities
To implement SSO with the Microsoft Kerberos SSP, you have to take the following steps:
1. Prepare the primary application server instance.
2. Configure the SAP front ends.
3. Configure the SAP Logon.
4. Map Windows users to SAP users.
Note
In the directory paths specified in the related topics, \%windir%\ refers to the location of the Windows directory corresponding to the Windows operating
system release.
5.1.4.1 Preparing the Primary Application Server Instance

To set up Single Sign-On (SSO) using Microsoft Kerberos, modify the instance profile of the primary application server and make sure that the SNC library is
located in the Windows directory.
Prerequisites
You have registered a Service Principal Name (SPN) for SAP NetWeaver Application Server (SAP NetWeaver AS) with the domain controller.
For example, enter the following command:
setspn -A SAPService <SID> / <do_not_care> SAPService <SID>
Context
Restriction
You cannot use this SNC library to protect outbound RFC connections.
Procedure
1. Determine which variant of the library is appropriate for your application server platform.
See the following table.
Table 1: Kerberos Wrapper Library According to Platform
Platform Library
32-bit Windows NT (Intel x86) gsskrb5.dll
64-bit Windows NT (x86_64) gx64krb5.dll
64-bit Windows NT (ia64/Itanium) gi64krb5.dll
For more information about how to download the library, see SAP Note 352295 .
2. Copy the library to the appropriate Windows system directory on the primary application server instance.
<Drive> :\%windir%\system32
<Drive> :\%windir%\SysWOW64
3. In the instance profile of the primary application server instance, set the profile parameters.
snc/enable = 1
snc/gssapi_lib = <DRIVE> :\%windir%\system32\ <library>
snc/identity/as = p:SAPService <SID> @ <KERBEROS_REALM_NAME>
where <KERBEROS_REALM_NAME> is the Kerberos realm that the SAPService <SID> user belongs to. This is typically the Microsoft Windows
domain converted to uppercase characters.
Caution
<KERBEROS_REALM_NAME> and the SAPService <SID> user are case-sensitive. Make sure that you enter the case correctly, for example:

p:SAPServiceC11@REALM.EXAMPLE.COM.
Note
Although you can freely choose the Windows account under which the SAP system runs, it is normally SAPService <SID> .
Single sign-on using the Microsoft Kerberos SSP with the Kerberos wrapper library is only available for user accounts that belong to the Active
Directory, that is, domain accounts. It cannot be used with local computer accounts.
4. Set the following parameters to enable users to log on to the SAP system using user ID and password.
Note
The following profile parameters permit users to continue to use password-based access to the SAP system when SNC has been enabled. Use these
additional parameters at least once after enabling SNC to be able to log on to the SAP system as an administrator for maintaining the mapping of
Windows NT user accounts to SAP system user IDs (user and client). Once the mapping (at least for the administrator) has been entered, you can
disable further password-based logons by removing the respective profile parameters.
To disable the user of user ID and password as a logon mechanism altogether, you can reset these parameters after maintaining the user mappings.
5. Stop and restart SAP NetWeaver AS so that the profile parameters take effect.
5.1.4.2 Configuring the SAP Front End
Use
To prepare the SAP front end for SSO when using Microsoft Kerberos, you choose between the following approaches:
Configure each SAP front end individually
You configure each machine where the SAP front end is running.
Configure all SAP front ends automatically
You define a Group Policy for a Windows domain. This policy causes the wizard for configuring SSO to be started automatically in the background the next
time any member of the domain logs on to an SAP front end.
These approaches are described below.
Prerequisites
You have completed Preparing the Primary Application Server Instance.
You have downloaded the Kerberos configuration wizard (SAPSSO.MSI). For more information, see SAP Note 595341.
Procedure
Configuring SAP Front Ends Individually
1. Log on to the machine where the SAP front end is running.
2. Copy the SAPSSO.MSI program to a local directory or to a shared directory on the network.
3. To start the wizard, double-click the SAPSSO.MSI file.
The wizard SAP Single Sign-On Support for Windows 2000 automatically starts and configures the SAP front end for SSO.
Configuring SAP Front Ends Automatically
1. Log on to a front-end machine as a domain administrator of the Windows domain.
2. Copy the program SAPSSO.MSI to a shared directory.
3. Choose Start → Programs → Administrative tools → Active Directory Users and Computers.
The dialog box Active Directory Users and Computers appears.
4. Right-click the domain for which you want to set up SSO and choose Properties.
The dialog box <Domain_Name> Properties appears.
5. Choose Group Policy → New to start creating a new policy object.
The dialog box for creating a new policy object appears.
6. In Group Policy Object Links, enter a name for the new policy object, such as SAPSSO.
7. Choose Edit to define the contents of the policy.
8. In the Group Policy Editor choose User Configuration → Software Settings → Software Installation.
The Deploy Software dialog box appears.
9. Right-click Deploy Software and choose New → Package.
The Open dialog box appears.
10. Select the file SAPMSSO.MSI from the shared location.
11. Specify the path with the UNC name (\\<hostname>\<share>).
12. Select Assign and confirm with OK.
You have now created a new Group Policy.
The next time any user logs on to the domain with the SAP front end, the wizard SAP Single Sign-On Support for Windows automatically starts and configures the
front end for SSO.

5.1.4.3 Configuring the SAP Logon
Use
To set up the use of Microsoft Kerberos with SAP systems, you need to activate the SAP Logon option on each SAP front end. The SAP Logon window includes a
list of systems or machines that you can log on to. For each of the systems or machines in the list for which you want to implement SSO, follow the procedure
below.
Prerequisites
You have completed the following:
Preparing the Primary Application Server Instance
Configuring the SAP Front End
Procedure
1. Select an entry in the SAP Logon window and choose Properties → Advanced.
2. Select Enable Secure Network Communications.
3. In SNC name, enter the application server's SNC name:
p:SAPService<SID>@<KERBEROS_REALM_NAME>
where <KERBEROS_REALM_NAME> is the Kerberos realm that the SAPService<SID> user belongs to.
Note
Enter the same string that you entered in the primary application server's instance profile for snc/identity/as.
Tip
If the system C11 is running on account SAPServiceC11 of the domain Domain.example.com, you would enter:
p:SAPServiceC11@REALM.EXAMPLE.COM
Note
If the entry you selected in the logon dialog box is a group entry, the SNC name field is already filled. In this case, the application server's SNC name is
determined by the message server at connection time.
4. Choose OK to confirm your entries.

The SAP Logon window now displays an icon with a key beside the system entry. This indicates that SNC is active for the system.
5.1.4.4 Mapping Windows Users to SAP Users for Kerberos SSO
Use
To set up the use of Microsoft Kerberos with SAP systems, you need to authorize SAP users to log on with SSO by assigning them to Windows users.
Prerequisites
You have completed the following:
Preparing the Primary Application Server Instance
Configuring the SAP Front End
Configuring the SAP Logon
Procedure
1. Log on to the SAP system as an administrator.
2. Choose Tools → Administration → Maintain Users → Users or call transaction SU01.
The User Maintenance window appears.
3. Enter the name of the SAP user and choose User names → Change.
4. Choose SNC.
5. In SNC name, enter the case-sensitive name of the Kerberos principal for the Windows user that is to be assigned to the SAP user:
p:<WINDOWS_USERNAME>@<KERBEROS_REALM_NAME>
where <WINDOWS_USERNAME> is the logon ID of the Windows user and <KERBEROS_REALM_NAME> is the Kerberos realm that the user belongs to. This
is typically the Microsoft Windows domain converted to uppercase characters.
Tip
For the user MILLER, belonging to the domain realm.example.com, enter:
p:MILLER@REALM.EXAMPLE.COM

6. If the user should also be allowed to log on with user ID and password, then select Insecure communication permitted. (This option is only available if the
profile parameter snc/accept_insecure_gui is set to 1.)
This can be useful, for example, to let the user work in a different domain where SSO using Kerberos is not available.
Result
Kerberos SSO is now set up. The next time this SAP system user logs on to the system, the application is opened without requiring the user to enter a user name
and password.
If only one possible match exists between the Windows account and the SAP system user ID, the logon screen is skipped, unless the profile parameter
snc/force_login_screen = 1 is present in the instance profile of the application server.
5.1.5 Single Sign-On with Microsoft NT LAN Manager SSP
Use
Single Sign-On (SSO) is a secure method of logging on to the SAP system that simplifies the logon procedure without reducing security. When your system is
configured for SSO, an authorized user who has logged on to the operating system can access the SAP system simply by selecting it in the SAP logon window or
clicking the shortcut. No SAP system user name or password is necessary. SSO makes it significantly easier for you to manage SAP system users.
In this section, we describe the option that is the easiest to implement when using a full 32-bit Microsoft Windows landscape (that is, Windows 9x, Windows ME,
Windows NT, or Windows 2000 and higher). It is a tailored version for SSO with Secure Network Communications (SNC), which uses Microsoft's NT domain
authentication, NT LAN Manager Security Service Provider (NTLM SSP).
Prerequisites
Typically, SNC requires SAP Single Sign-On or an external security product that adheres to the Generic Security Service API V2 (GSS-API V2) interface
and that has been certified by the SAP Software Partner Program. However, in this scenario, we provide a library that adheres to the GSS-API V2 interface
on one side and that communicates with Microsoft's NTLM SSP on the other. Since NTLM SSP is already built into Microsoft Windows 32-bit platforms, you
do not need to purchase an additional security product to use SSO.
Note
The Microsoft NTLM SSP only provides authentication based on a challenge-response authentication scheme. It does not provide data integrity or data
confidentiality protection for the authenticated network connection. SAP Single Sign-On and all third-party BC-SNC certified security products offer data
integrity and privacy protection. To use these security features, you must obtain a security product.
If you only use Windows 2000 and higher, we offer an alternative library (gsskrb5.dll) that uses the Microsoft Kerberos SSP instead of the NTLM
SSP for authentication. For more information, see Single Sign-On with Microsoft Kerberos SSP.
We distribute two different versions of the wrapper library for Microsoft's NTLM SSP. The older version is called gssapi32.dll and the newer version
is called gssntlm.dll. For more information on how to get gssntlm.dll, see SAP Note 595341.
For more information on security aspects of this scenario, see SAP Note 165485.
A pure Microsoft Win32 environment is required (that is, Windows 9x, Windows ME, Windows NT, Windows 2000 and higher). The Microsoft NTLM SSP is
not available for UNIX or any other operating system.
Bi-directional trust between Windows domains is required if there are separate domains for users, front-end PCs, and SAP application servers.
The GSS-API V2 library wrapper (gssntlm.dll) must be installed on every application server.
The GSS-API V2 library wrapper must also be installed on every front-end PC.
We recommend that you use the 7-bit ASCII character set for all Windows user IDs.
When the code page of the SAP system is different from the code page on the Windows machines, it is not possible to enter Windows user IDs that contain
8-bit characters into the USRACL table (for example, by calling transaction SU01). The combination of Windows ANSI (=ISO Latin 1) and the default SAP
code page 1100 provides the same encoding of 8-bit characters and permits the use of 8-bit characters with gssntlm.dll.
Activities
To implement SSO with the Microsoft NTLM SSP you:
1. Start the service Windows LM Security Support Provider.
2. Configure the application server for Single Sign-On.
3. Configure SAP GUI and SAP Logon for Single Sign-On.
4. Map Windows users to SAP system users.
5.1.5.1 Starting the Windows LM Security Support Provider

Service
Use
Before you can use Windows NTLM for SSO, you must start the Windows LAN Manager Security Support Provider service. Therefore, configure this service to
start automatically.

Procedure
1. Choose Start Programs → Administrative Tools → Services.
2. Select the service NT LM Security Support Provider.
3. Choose General.
4. Change the startup type from manual to automatic.
5.1.5.2 Configuring the Application Server

Restriction
The following configuration does not enable you to run SNC with encryption, and it does not provide data integrity. Here, SNC protects inbound RFC
connections only.
1. Copy the gssntlm.dll file to the following directory on your central instance:
<DRIVE>:\USR\SAP\<SID>\SYS\EXE\RUN
For more information on how to get the gssntlm.dll file see SAP Note 352295 .
2. Set the environment variable SNC_LIB to the location of the library.
3. In the central instance profile, set the following SNC parameters:
snc/data_protection/max = 1
snc/data_protection/min = 1
snc/data_protection/use = 1
snc/enable = 1
snc/gssapi_lib = (<DRIVE>:\USR\SAP\<SID>\SYS\EXE\RUN\<gssntlm.dll>)
snc/identity/as = p:<DOMAIN_NAME>\SAPService<SID>
where SAPService<SID> is the user who runs the SAP system.
and < DOMAIN_NAME> is the Windows NT domain of this user.
Note
Although you can freely choose the Windows NT account under which the SAP system runs, it is normally SAPService<SID>.
Note
If you use a local account for SAPService<SID>, most operations are successful. However, any operations or communications where the SAP
system initiates SNC-protected communication to a remote machine do not work with a local account for SAPService<SID>. Therefore, use a
domain account.
Additional SNC Parameters

The following profile parameters let you continue with password-based access to the SAP system when SNC has been enabled. To log on to the SAP
system as an administrator to maintain the mapping of Windows user accounts to SAP system user IDs (user and client), you have to use these additional
parameters at least once after enabling SNC. Once the mapping (at least for the administrator) has been entered, you can disable further password-based
logons by removing the respective profile parameters.
4. Stop and restart the SAP system to activate the profile parameters. Changes to SNC profile parameters always require an application server restart to take
effect.
5.1.5.3 Configuring SAP GUI and SAP Logon for Single Sign-On
Use
To set up the use of Microsoft NTLM with SAP systems, you need to activate the SAP Logon option on each SAP front end. The SAP Logon window includes a list
of systems or machines that you can log on to. For each of the systems or machines in the list for which you want to implement SSO, follow the procedure below.
Prerequisites
You have completed Configuring the Application Server.
Procedure
1. Copy the gssntlm.dll file to the SAP GUI directory.
The gssntlm.dll file is located on sapserv<x> in the directory /general/misc/security/gssntlm.
2. Set the Windows environment variable SNC_LIB on the PC where your SAP GUI runs.
The variable specifies the path to the gssntlm.dll file. You can do this using one of the following methods:
Copy gssntlm.dll to a location of your choice and set the environment variable SNC_LIB to that location, for example,
<DRIVE>:\<SAPGUI_PATH>\gssntlm.dll.

1. Right-click My Computer and choose Properties → Advanced → Environment Variables.
2. In User Variables for <user> enter the following:
Variable: SNC_LIB
Value: <DRIVE>:\<SAPGUI_PATH>\gssntlm.dll
3. Confirm your entries with OK.
4. To activate the new environment variable setting, log off and then log on to your Windows system again as the same user.
Copy gssntlm.dll to a directory of the default search path, for example, %SystemRoot%\system32 and rename the file to sncgss32.dll.
This is the default file name that SNC uses when SNC_LIB is neither entered on the command line nor available in the environment.
3. Set the required logon options to activate SSO:
1. In the SAP Logon window, select the entry to modify and choose Edit → Advanced.
The Advanced Options dialog box appears.
2. In the SNC name field, enter:
p:<DOMAIN_NAME>\SAPService<SID>
where <DOMAIN_NAME> is the Windows domain that the user SAPService<SID> belongs to.
Tip
If the system HWA is running on account SAPServiceHWA of the MYDOMAIN domain, you enter:
p:MYDOMAIN\SAPServiceHWA
Result
The SAP Logon window now displays an icon with a small yellow key beside the system entry. This indicates that SSO is active.
5.1.5.4 Mapping Windows Users to SAP Users for NTLM SSO
Use
To set up the use of Microsoft NTLM with SAP systems, you need to authorize SAP users to log on with SSO by assigning them to Windows users.
Prerequisites
You have completed the following procedures:
Starting the Windows LM Security Support Provider Service
Preparing the Application Server
Preparing SAP GUI and SAP Logon for Single Sign-On
Procedure
1. Log on to the SAP system.
2. Choose Tools → Administration → User Maintenance → Users or call transaction SU01.
The User Maintenance window appears.
3. Enter the name of the SAP system user and choose User names → Change.
4. Choose SNC.
5. In SNC name, use uppercase to enter the name of the Windows user that is to be assigned to the SAP system user:
p:<DOMAIN_NAME>\<NT_USERNAME>
where <DOMAIN_NAME> is the Windows domain that the Windows user belongs to
and <NT_USERNAME> is the logon ID of the Windows user.
p: is a prefix that all SNC names require.
Tip
For the Windows user Miller belonging to the domain MYDOMAIN, enter:
p:MYDOMAIN\MILLER
6. If the user should also be allowed to log on with user ID and password, then select Insecure communication permitted. (This option is only available if the
profile parameter snc/accept_insecure_gui is set to 1.)
This can be useful, for example, to let the user work in a different domain where SSO using NTLM is not available.
Result
You have now finished setting up SSO. The next time this SAP system user logs on to the system, the application is opened without requiring the user to enter a
user name and password.
If only one possible match exists between the Windows account and the SAP system user ID, the logon screen is skipped, unless the profile parameter
snc/force_login_screen = 1 is present in the instance profile of the application server.
5.2 Single Sign-On for Web-Based Access

Use
SAP NetWeaver enables you to use a number of options for Single Sign-On (SSO) when users access the system from a web client, such as a web browser.
You can use the SSO options for web-based access to enable users to securely access information and back-end system resources located in an intranet or on
the Internet. The communication for web-based authentication and respectively access authentication use mechanisms that are supported by the HTTP protocol
for Internet communication.
Integration
For this access scenario, users can access resources from a web browser. SAP NetWeaver Application Server (SAP NetWeaver AS) Java and ABAP are the
technology stacks that support the authentication functions for the web-based access to SAP NetWeaver AS.
The authentication functions of SAP Enterprise Portal are enabled by SAP NetWeaver AS for Java. You can access AS ABAP web-enabled applications by
using the Internet Communication Framework (ICF).
SAP NetWeaver AS for ABAP and AS Java enable you to use a number of authentication options for integrating web-based user access in SSO environments.
For advanced integration scenarios, for example logon tickets, SAML, and client certificates, SAP NetWeaver AS for ABAP and AS Java enable the use of
cryptographic functions to support the security of the authentication process.
For more information, see Digital Signatures and Encryption .
To increase security of the user authentication and SSO process for open environments such as the Internet, you can also use network and transport layer
security mechanisms.
In addition, the identity management functions of SAP NetWeaver AS enable you to manage the users that can access resources in a SSO environment.
For more information, see Identity Management .
Features
For more information about configuring SSO access to SAP NetWeaver, see the following:
Using User ID and Password Authentication
Using Logon Tickets
Using Client Certificates
Using SAML Browser Artifacts
Using SAML 2.0
Using Kerberos
Using Header Variables
Accessing Back-End Systems with a Different User ID
5.2.1 Using User ID and Password Authentication
Use
You can use the security configuration options of SAP NetWeaver to enforce access control by requiring users to interactively enter their user ID and password.
Users can submit their credentials in a browser popup or using a specifically designed Web page.
For the case where users have to access multiple SAP NetWeaver systems, you can enable SSO by using an intermediary mapping system to map user IDs
in different systems.
Integration
After a user enters and submits a user ID and a password, these authentication credentials are transported over the network to the SAP NetWeaver Application
Server (AS). The SAP NetWeaver system checks the authentication credentials and uses its Identity Management functions to determine the user account
authorizations on successful authentication.
For more information about authorizations in SAP NetWeaver, see Identity Management .
Your SAP NetWeaver systems can deploy cryptographic solutions to protect the integrity and confidentiality of the user ID and password during their transport over
the network. For additional security and in open communication environments such as the Internet, however, we recommend that you enable transport layer
security solutions, such as Secure Socket Layer or Secure Network Communications (SNC).
Features
Depending on the methods used to protect the confidentiality and integrity of the user ID and password, SAP NetWeaver can use the HTTP standard basic, form,
and digest authentication.
For more information about the security aspects when using the user ID and password authentication, see Basic Authentication (User ID and Password) .
Activities
To authenticate users with a user ID and password, you have to configure the appropriate SAP NetWeaver Application Server mechanism.
The configuration activities depend on the underlying technology used for the SAP NetWeaver Application Server.
Logon Using User ID and Password on the AS ABAP

Information about configuring logon with a user ID and password on the AS ABAP.
Logon Using User ID and Password on the AS Java
Information about enabling the use of user ID and password logon on the AS Java.
Use
If you use Basic Authentication to log on to ABAP Application Server, you can choose either a standard SAP user or an internet user :
The default SAP user is the user name entered in transaction SU01.
The Internet user is the alias name. This can be longer than the normal SAP user name. This can also be set in SU01.
Depending on the settings, the input in the HTTP popup for Basic Authentication is interpreted as either a user name or an alias.
Activities
If you want to change the user type for the Basic Authentication logon procedure in a service or service node, proceed as follows:
2. Choose Change .
3. Under Logon Data/Authentication , choose Standard SAP User or Internet User .
Note
If you make this setting in a service node, the data is passed on to all services under this node.
5.2.1.2 Logon Using User ID and Password on the AS Java
Use
The AS Java uses the JAAS login modules BasicPasswordLoginModule to perform the authentication with user ID and password. You can add these login
modules to the login module stacks of the policy configurations of applications to enable authentication with user ID and password.
The AS Java uses BasicPasswordLoginModule for applications that specify in their deployment descriptors the use of basic or form authentication.
Note
For the case when the User Management Engine uses an ABAP user store, the BasicPasswordLoginModule enables you to log on users that provide an
AS ABAP alias. Adding an alias for a user account is possible only from the ABAP back-end user store. For more information, see the Logon Data Tab Page
section in the User and Role Administration of AS ABAP documentation.
The AS Java supports Single Sign-On (SSO) to back-end systems using user ID and password with user mapping. For more information, see Configuring User
Mapping with User ID and Password on an AS Java .
Procedure
Use the authentication management functions of the SAP NetWeaver Administrator to configure user ID and password authentication. For more information, see
Managing Authentication Policy .
1. Go to the Components tab.
2. Select the policy configuration for the component to use logon with user ID and password from the list of policy configurations. Choose the Edit button.
3. In the Authentication Stack table for the chosen policy configuration, add the login module that corresponds to the user ID and password
authentication type that you use
For basic or form authentication, choose BasicPasswordLoginModule .
To enable logon with an ABAP alias, configure the LogonWithAlias option for the BasicPasswordLoginModule .
The possible values for this option are true or false . The default value for this option is false . If you change this value to true , then entered
user IDs are regarded as ABAP aliases.
4. Save the configuration changes.
Result
Users who access applications in a policy configuration that uses authentication with a user ID and password are prompted to enter their user ID and password on
initial access.
5.2.1.2.1 Configuring User Mapping with User ID and Password

on an AS Java
Prerequisites
The AS Java has a functional connection to the System Landscape Directory (SLD)

A system exists in the SLD to use as an identifier for the user mapping. Ideally this is the target system, but this is not required.
For more information, see Working with SLD .
Context
Use this procedure to enable SAP NetWeaver Application Server (AS) Java users to access back-end systems with Single Sign-On (SSO) with a different user
ID and password.
For more information, see User Mapping and the AS Java .
Procedure
1. Create a destination for the target system.

For the destination, enter the following values:
Choose User Mapping in the Authentication field.
Under System Mapping for User Authentication , choose a system from the SLD to use to identify the user mapping in the Target System field.
This is the system that appears in the user mapping interface, when you choose which system to map users to.
For more information, see Destination Service .
2. Map users to back-end systems and users.
You have the following options for performing this mapping:
The administrator maps the users to their users in the back-end system.
This requires the administrator to keep track of user IDs in the portal and their user IDs and passwords in the back-end systems.
When the administrator configures a mapping for a user, the user management engine (UME) by default checks the mapped user ID and password
against the reference system. You can disable the check for administrators.
To disable the check, set the UME property ume.usermapping.admin.pwdprotection= FALSE .
For more information, see the following:
Configuring User Mappings on the Behalf of Users
Editing UME Properties
Let users map themselves.
This requires users to know what systems they need to map to and their user IDs and passwords in those systems.
Note
To map their own user IDs, users require authorizations for self-management.
Configuring Self-Management
If you have the SAP EP available, see the Setting Portal Preferences section from the Portal documentation
5.2.1.3 Using Rules for User Mapping in Basic Password Login

Module
Context
BasicPasswordLoginModule can use different rules to map users authenticated with their password to users in the User Management Engine (UME). By default,
it maps the users to the value of their logon IDs. However, you can define mapping to another user attribute or account attribute. This means that users will be able
to log on using options such as their e-mail address, last name, or a custom attribute in the UME.
You define the rule for user mapping by creating a set of login module options.
The following table summarizes the login module options for user mapping.
Name Possible Values Description
UserMappingMode (case insensitive values) Required for user mapping. Specifies the user mapping
mode. AS Java retrieves users using the value of the
specified property.
LogonID The mapping property is the logon ID. This is the default
value.
LogonAlias The mapping property is the logon alias. For users from
the ABAP data source, the logon alias may be different
from their logon ID. For AS Java users, the logon alias is
the same as the logon ID.
Email The mapping property is the user's e-mail address (as

defined in the corresponding user attribute).
UserAttribute The mapping property is a user attribute in the UME. It can

be a predefined property or a custom property. For custom
properties, you also need to specify
UserMappingAttributeNamespace .
AccountAttribute The mapping property is an account attribute (realm,

principal, and so on).
UserMappingAttribute <attribute name> If UserMappingMode is set to UserAttribute , this

option specifies the name of the user attribute for the
mapping.
UserMappingAttributeNamespace <attribute namespace> Specifies the attribute namespace in the UME.
Procedure
1. Using SAP NetWeaver Administrator, go to the configuration options for BasicPasswordLoginModule . For more information, see Managing Login Modules .
2. Construct the required mapping rule by adding the corresponding set of login module options (see the examples below).
3. Save the changes to the login module.
Results
Once you have configured BasicPasswordLoginModule 's options for user mapping, when a user tries to log on, AS Java attempts to map the user ID attribute
specified during logon to the specified user or account attribute in the UME database. In other words, AS Java will recognize this user as the user whose specific
attribute has the same value as the user ID used during logon.
Example
Example 1: User Mapping by E-Mail
Donna Moore is an employee at the MyCompany corporation. Some of the attributes of her account in AS Java's UME database are:
Logon ID s13345dmoore
Last Name Moore
First Name Donna
E-mail Address donna.moore@mycompany.com
To avoid using the complex logon IDs for its employees, MyCompany uses user mapping to employees' e-mail addresses.
This is done with the following option for BasicPasswordLoginModule :
Option Value
UserMappingMode Email
5.2.2 Using Logon Tickets
Use
You can use logon tickets to integrate applications running on SAP and non-SAP systems in SSO environments with SSO based on cookie technology.
For this SSO scenario, you configure a system such as a portal in your landscape to issue digitally signed logon tickets. Users authenticate initially to this system
to obtain a logon ticket. After being issued, the logon ticket is stored as a digitally signed cookie in the user's Web browsers and enables the user to logon
transparently to trusting systems in the SSO environment.
Prerequisites
Users must have the same user ID in all of the systems they access using the logon ticket. If you have a portal, you can use an intermediary mapping
system for the user IDs in different systems.
The Web clients of the application server users must be configured to accept cookies.
Systems that accept logon tickets access the issuing server's public-key certificate to verify the digital signature provided with the ticket. SAP NetWeaver
Application Servers (AS ABAP and AS Java) receive a key pair and a self-signed public-key certificate during the installation process.
The clocks for the accepting systems are synchronized with the ticket-issuing system. If you do not synchronize the clocks, then the accepting system may
receive a logon ticket with an invalid time stamp, which causes an error.
Integration
To ensure data integrity and non repudiation, logon tickets are digitally signed by the issuing system. Therefore, to enable SSO, on the accepting system you
must establish a trust relationship to the issuing system. SAP NetWeaver Application Server (AS) systems are shipped with the necessary functions and a
Personal Storage Environment (PSE) to enable logon ticket verification.
The trusted systems management functions of the SAP NetWeaver Administrator enable you to manage the necessary trust relationships for integrating AS ABAP
and AS Java systems in logon ticket-based SSO environments. You can use these functions to facilitate the remote configuration of trust relationships between
SAP NetWeaver systems that are registered in System Landscape Directory (SLD) environments.
Note
Logon tickets use cookie technology to save persistency information about the authenticated user on the client. Therefore, for additional security we recommend
that you protect the Web client's cookie cache and employ transport layer security mechanisms such as SSL.
Features
Logon tickets enable you to integrate SAP NetWeaver and non-SAP systems in an SSO environment. To use SSO with logon tickets, you configure a system in

your landscape to authenticate users and issue a logon ticket upon successful authentication. Subsequently, users can transparently access systems that
accept logon tickets for SSO.
For more information about logon tickets depending on the underlying technology of SAP NetWeaver, see the following topics:
Using Logon Tickets with AS ABAP
Using Logon Tickets with AS Java
Activities
You use the Trusted Systems Single Sign-On with SAP Logon Tickets configuration functions in the SAP NetWeaver Administrator to configure logon
ticket-based SSO in landscapes with systems supported by the AS ABAP or AS Java technology stacks of SAP NetWeaver.
1. Configure SAP NetWeaver server system to authenticate users and issue logon tickets
1. Configure AS ABAP for issuing logon tickets
2. Configure AS Java for issuing logon tickets
2. Configure SAP NetWeaver server system to accept logon tickets
1. Configure AS ABAP to accept logon tickets
2. Configure AS Java to accept logon tickets
5.2.2.1 Using Logon Tickets with AS ABAP
Use
SAP NetWeaver Application Server (AS) ABAP enables you to use Single Sign-On (SSO) with logon tickets both in the role of a logon ticket-issuing and logon
ticket-accepting system. After receiving a logon ticket, AS ABAP users can access other systems in the SSO environment using the logon ticket for
authentication instead of having to repeatedly enter their user ID and password.
Prerequisites
Users must have the same user ID in all of the systems they access using the logon ticket. Passwords do not have to be the same in all systems. If users
have different user IDs, you also have to use a reference system for user mapping.
The users are dialog users. AS ABAP does not issue logon tickets for system or service users.
Note
For system to system communication, the AS ABAP issues an authentication assertion ticket. The assertion ticket is structured the same as the logon
ticket, but has a limited validity period (2 minutes). The configuration for issuing and accepting logon tickets also applies to the issuing and accepting of
authentication assertion tickets.
Business users must configure their Web browsers to accept cookies.

Any systems that accept the logon ticket as the authentication mechanism must be placed in the same DNS domain as the issuing server. The logon ticket
cannot be used for authentication to servers outside of this domain.
The issuing server must possess a public and private key pair and public-key certificate so that it can digitally sign the logon ticket. The AS ABAP
receives a key pair and a self-signed public-key certificate during the installation process.
By default, the AS ABAP uses the system Personal Security Environment (PSE) for storing these keys; however, you may need to use a different PSE in
the following cases:
If the system has been upgraded from a release less than or equal to 4.6B, then the PSE used for logon tickets is the SAPSSO2 PSE.
If you have defined an explicit PSE to use for logon tickets, then this PSE (as specified in the table SSFARGS) is used.
Systems that accept logon tickets must have access to the public-key certificate of the issuing server so that they can verify the digital signature provided
with the ticket. Therefore, the public-key certificate of the issuing server must be added to the certificate list of the accepting system.
For landscapes that include only AS ABAP systems, you can use the SSO administration wizard (transaction SSO2) to automatically establish the
configuration for the accepting system.
For system landscapes with AS Java and AS ABAP systems you can use the Trusted Systems Single Sign-On with SAP Logon Tickets
configuration functions of the SAP NetWeaver Administrator to establish trust between a ticket-issuing and a ticket-accepting system, registered in a
system landscape directory.
Features
You can configure the AS ABAP to act as a ticket-issuing and a ticket-accepting system in your landscape. For more information about the authentication flow,
see the following sections.
Issuing Logon Tickets
1. The user authenticates him or herself on the AS ABAP (for example, using user ID and password).
2. The AS ABAP verifies the information from the user. If the authentication was successful, then the user is logged on to the server and a ticket is issued to
him or her.
3. The Web browser of the user stores the logon ticket and uses it for authentication on to ticket-accepting systems.
Accepting Logon Tickets
1. The Web browser sends the logon ticket of the user logon ticket with the access request.
2. The AS ABAP verifies the information contained in the ticket, as follows:
1. Verifies the digital signature of the issuing server based on an established trust relationship with the ticket-issuing system.
2. Makes sure the ticket has been issued by a trusted server (either itself or a server listed in the corresponding access control list).
3. Checks the expiration time.
If the ticket is valid and has been issued by a trusted server, then the AS ABAP grants the user access to the system.

Activities
For more information about configuring the AS ABAP to issue and accept logon tickets, see the following:
Configuring the AS ABAP for Issuing Logon Tickets
Configuring AS ABAP to Accept Logon Tickets
5.2.2.1.1 Configuring the AS ABAP for Issuing Tickets for Logon
Use
Use this procedure to enable SAP NetWeaver Application Server (AS) ABAP to issue tickets for authentication. There are two types of tickets:
Logon tickets
These tickets enable SSO for Web-based access.
Recommendation
For cross system SSO, especially across domains, we recommend using SAML 2 and HTTP security session management to implement SSO in your
SAP landscape. This requires the use of an identity provider.
For more information, see Configuring AS ABAP as a Service Provider.
Authentication assertion tickets

These tickets enable system-to-system communication on the behalf of a given user or service.
Prerequisites
You have configured the ticket-accepting system to trust the ticket-issuing system.
You have ensured the system clocks remain synchronized.
Users in the issuing and accepting systems have the same user IDs.
Procedure
1. Set the profile parameters on AS ABAP according to the table below.
Parameter Value Comment
login/accept_sso2_ticket 1 Set this parameter to enable the server to accept an

existing logon or assertion ticket.
login/create_sso2_ticket 2 or 3 Enter the value 3 to enable the AS ABAP to issue

authentication assertion tickets and no logon tickets. We
recommend you use this value.
Enter the value 2 to enable the AS ABAP to issue logon
and assertion tickets. Use this value if you use legacy
systems that require you to use logon tickets.
login/ticket_expiration_time Required value Default = 8 hours (logon tickets only)
For more information, see the documentation provided for the profile parameters in transaction RZ11.
Note
Use the SSO administration wizard to view the SSO configuration of the current server. Execute the tool without specifying an RFC destination.
Result
Caution
Be sure to replace the SSO PSE of the server before the public-key certificate expires. Otherwise, users cannot receive logon tickets and cannot use SSO.
For more information, see Creating or Replacing a PSE.
5.2.2.1.2 Configuring AS ABAP to Accept Logon Tickets
Use
To integrate SAP NetWeaver Application Server (AS) ABAP in Single Sign-On (SSO) environments, you must configure your systems to accept and verify the
logon tickets issued by other systems in your SSO landscape.
Accepting systems must be able to verify logon tickets and the digital signature of the issuing server. The accepting system requires the following information for
verification:
The system should only accept logon tickets issued from a trusted server. Therefore, the identity of the trusted server must be entered in the SSO access
control list of the accepting system.
The system must be able to verify the digital signature of the issuing server.

For this purpose, the accepting system needs access to the public-key information of the issuing server, which must be entered in the certificate list of the
accepting system.
The system must know where the information is stored that it uses to verify the digital signature of the issuing server. The file name and location where this
information is stored (the server's designated SSO PSE) is release-dependent.
For more information, see Using Logon Tickets with AS ABAP.
Activities
The procedure to configure the AS ABAP to accept logon tickets depends on whether the issuing server is an AS ABAP or AS Java.
Accepting Logon Tickets Issued by an AS ABAP System
Accepting Logon Tickets Issued by an AS Java System
5.2.2.1.2.1 Accepting Logon Tickets Issued by Another AS ABAP
Use
Use this procedure to configure the AS ABAP to accept a logon ticket issued by another AS ABAP system in your landscape.
Prerequisites
The issuing server must possess a public and private key pair and a public-key certificate. For the AS ABAP, this information must be available in the
issuing server's SSO PSE.
If the accepting system is an SAP system <= Release 4.6D, then the system must have the Workplace Plug-In installed and must meet the following
release requirements:
Release 4.6x: 4.6D kernel as of Support Package level 74
Release 4.5x: 4.5B kernel as of Support Package level 459
Release 4.0x: 4.0B kernel as of Support Package level 758
The SAP Cryptographic Library must be installed on all of the accepting system's application servers. For more information, see SAP Note 1848999 .
For releases that are not covered by SAP Note 1848999 , you can obtain the most recent version of the SAP Security Library from SAP Service
Marketplace in the SAP Support Portal Software Downloads Support Packages and Patches Entry by Application Group Additional
Components SAPSECULIB .
Procedure
Configure the required parameters on all the logon ticket accepting AS ABAP systems.
1. Set the profile parameter login/accept_sso2_ticket= 1.
Note
Set login/create_sso2_ticket= 0 for a scenario where the ticket accepting AS ABAP should also be able to issue tickets. (Use
DEFAULT.PFL.)
2. For Releases 4.0 and 4.5, also set the profile parameter SAPSECULIB to the location (path and file name) of the SAP Cryptographic Library.
For each of the accepting AS ABAP systems
1. Execute the SSO administration wizard (transaction SSO2).
The SSO2 Administration screen appears.
2. Enter the RFC destination or the <host name> and <system number> for the issuing server in the appropriate fields.
Note
Note the following:
You must specify the destination host for the issuing server's logical system, namely, the system ID and client.
If you do not enter a destination host on the SSO2 Administration screen, then the status for the local system is displayed.
If you enter the <host name> and <system number> , the system automatically creates a corresponding RFC destination to use for the
connection.
The SSO administration report for the designated server is displayed. The following information is shown:
Profile parameter values on both the issuing server and on the accepting system's application server.
The accepting system's SSO access control list.
The accepting system's certificate list.
Red traffic lights in any of these areas indicate configurations that are not operational for using logon tickets.
3. If the report indicates errors on the issuing server (for example, profile parameters are not set correctly), correct these errors on the issuing server and re-
execute the SSO administration wizard on the accepting system.
4. To initiate the configuration steps on the accepting system, choose Edit Activate ().
The following occurs:
The SSO administration wizard enters the issuing server's system ID and client in the accepting system's access control list.
If the issuing server's public-key certificate is a self-signed certificate, then the SSO administration wizard enters the public-key information contained
in the certificate in the accepting system's certificate list.
The SSO administration wizard makes the SSO PSE available to the accepting system's application servers:
In Releases >= 4.6C, the SSO administration wizard distributes the SSO PSE to all of the system's application servers.
In Releases < 4.6C, it stores the SSO PSE in the directory specified by the profile parameter DIR_PROFILE.

Note
If the DIR_PROFILE directory is not globally accessible to all of the application servers in the accepting system, then you have to
manually copy the SSO PSE to each application server's DIR_PROFILE directory.
All changes take place immediately and you do not have to explicitly save any data.
5. If any of the areas indicate errors, correct these errors and re-execute the SSO administration wizard.
Note
You can also add or delete entries from the access control list or certificate list by placing the cursor on the appropriate line and choosing Edit
<function> .
Example
For example:
To add the issuing server's system ID and client to the SSO access control list, place the cursor on the line SAP System
<Issuing_Server_SID> Client <client> and choose Edit Enter ACL .
To delete an entry from the certificate list, place the cursor on the system ID and choose Edit Delete from certificate list .
To add the SAP CA certificate to the certificate list, choose Edit Add SAP CA .
Note
You can also manually change the access control list (table TWPSSO2ACL) using the table maintenance transactions (for example, SM30).
You can also manually change the certificate list using the PSE maintenance transaction ( PSEMAINT) or the trust manager (transaction STRUST or
STRUSTSSO2).
The PSE maintenance transaction PSEMAINT is available for SAP systems <= Release 4.6D and the trust manager is available with the SAP Web
Application Server ABAP.
Result
The accepting systems are able to accept logon tickets and verify the issuing server's digital signature when they receive a logon ticket from a user.
Note
You may execute the SSO administration wizard at any time and as often as you wish.
5.2.2.1.2.2 Accepting Logon Tickets Issued by the AS Java
Use
To use Single Sign-On between the AS Java and an AS ABAP system with logon tickets issued by the AS Java, you configure the corresponding AS ABAP
application server to accept logon tickets.
When your AS ABAP server is integrated in a System Landscape Directory you can configure the AS ABAP for accepting logon tickets from the Trusted Systems
functions of the SAP NetWeaver Administrator.
Prerequisites
The public-key certificate to use for verifying AS Java's digital signature is available as a file in the file system. It must exist either in base 64 or in DER format.
For more information, see Managing Entries.
In either case, the certificate must exist either in base 64 or in DER format.
Note
The AS Java uses a self-signed public-key certificate for digitally signing logon tickets. It is located in the TicketKeystore entry in the AS Java Key Store.
For more information, see Managing Entries .
Procedure
On the AS ABAP application server:
1. Set the profile parameter login/accept_sso2_ticket = 1.
Note
Set login/create_sso2_ticket = 1 if the server should also be able to issue tickets. (Use DEFAULT.PFL .)
2. For Releases 4.0 and 4.5, also set the profile parameter SAPSECULIB to the location (path and file name) of the SAP Security Library (or SAP
Cryptographic Library).
3. Add the AS Java's public-key certificate to the corresponding certificate list.
For Releases >= 6.10, use the trust manager (transaction STRUST or STRUSTSSO2). Import the AS Java's public-key certificate into the PSE that is
used for logon tickets. By default this is the System PSE.

Note
In the following cases a PSE other than the system PSE is used:
If the system has been upgraded from a Release <= 4.6B, then the PSE used for logon tickets is the SAPSSO2 PSE.
If you have defined an explicit PSE to use for logon tickets, then this PSE (as specified in the table SSFARGS) is used.
For Releases <= 4.6D, use the transaction PSEMAINT.

4. Add the AS Java's information to the access control list:
5. Enter the AS Java's system ID and Distinguished Name from the certificate found in the T icketKeystore entry. For the client, see Determining the
Client to Use for the AS Java .
For Releases >= 6.10, use the transaction STRUSTSSO2.
For Releases <= 4.6D, use table maintenance (transaction SM30) to edit the table TWPSSO2ACL.
5.2.2.2 Using Logon Tickets with AS Java
Use
The AS Java uses JAAS login modules to support the use of logon tickets for SSO. For this scenario, the user authenticates with a supported mechanism against
a ticket-issuing system in your landscape. After successful authentication, the system issues the user a logon ticket, which he or she can use for SSO access to
other systems in the SSO environment.
Integration
When using logon tickets for Single Sign-On, you must set up one system as the ticket-issuing system. This may be the AS Java, or it may be a different SAP
application server or a portal system. You can then configure the AS Java as well as other systems in your landscape to accept logon tickets.
On the AS Java, you enable the use of logon tickets for SSO by configuring the login module stacks for the corresponding applications.
Note
Special Case: Authentication Assertion Ticket
For system connections between the AS ABAP and a AS Java using jRFC or HTTP, you can use a logon ticket called authentication assertion
ticket . It is used similarly to logon tickets with the following restrictions:
Used for connections between systems where no user interaction is necessary.
Can only be used for SSO one-time. Once the ticket has been verified, it is deleted.
Has a very limited validity period (a few seconds).
The configuration is the same as with the standard logon ticket with the exception that specific login modules exist to enable the use of authentication
assertion tickets.
Prerequisites
The Web browsers of the users are configured to accept cookies.
The ticket-accepting systems, including the AS Java and AS ABAP, must be located in the same DNS domain as the issuing server. The logon ticket
cannot be used for authentication to servers outside of this domain.
The clocks for the accepting systems are synchronized with the ticket-issuing system. If you do not synchronize the clocks, then the accepting system may
receive a logon ticket that is not yet valid, which can result in authentication errors.
The issuing server must possess a public and private-key pair and public-key certificate to use for digitally signing the logon ticket. Systems that accept
logon tickets must have access to the issuing server's public-key certificate so that they can verify the digital signature provided with the ticket.
Features
When a user is authenticated on the AS Java, the server processes the stack of login modules that apply to the application that the user accesses. To use logon
tickets for SSO, you adjust the applications' login module stack to include the login modules enabling SSO with logon tickets.
The AS Java is delivered with the following JAAS login modules for creating and verifying logon tickets.
CreateTicketLoginModule for creating logon tickets
EvaluateTicketLoginModule for verifying logon tickets.
To configure the use of SSO with logon tickets you can also use the authentication stack of the T emplate policy configuration ticket , which contains these
modules in the correct order for using logon tickets.
Note
When using authentication assertion ticket for system connections between the AS ABAP and a AS Java, the corresponding login modules you
use are called CreateAssertionTicketLoginModule and EvaluateAssertionTicketLoginModule . The corresponding template is
evaluate_assertion_ticket .
You can adjust either individual login module stacks or any of the corresponding policy configuration templates. If you change the templates, then the changes will
be replicated to all applications that use the templates for their authentication needs. For more information, see Managing Login Modules and Managing
Authentication Policy .
Activities

Activities
For more information about configuring the use of logon tickets for the AS Java, see the following sections:
1. Configure the AS Java to issue logon tickets
2. Configure the AS Java to accept logon tickets
3. Test the Use of Logon Tickets
Example
For an example of the login module stack configurations to enable the use of logon tickets for SSO on the AS Java, see Sample Login Module Stacks for Using
Logon Tickets .
5.2.2.2.1 Configuring the AS Java to Issue Logon Tickets
Use
When a user requests access to an AS Java application, the AS Java processes the stack of login modules that apply to the application. Therefore, to configure
the AS Java as a logon ticket-issuing system, you adjust the login module stacks for the policy configurations of AS Java applications.
Prerequisites
The AS Java has to possesses a public and private key pair and public-key certificate that it can use to digitally sign the logon ticket. By default, the AS Java is
delivered with a key pair and a public-key certificate to use for issuing logon tickets that are stored in the AS Java's TicketKeystore .
In addition, the systems that accept logon tickets from the AS Java must have an established trust relationship with the AS Java and access to the AS Java's
public-key certificate to verify the digital signature provided with the ticket.
Procedure
Configuring the Login Module Stacks to Issue Logon Tickets
Use the authentication configuration functions of the SAP NetWeaver Administrator to configure the login module stacks. For more information, see Managing Login
Modules and Managing Authentication Policy .
1. Choose Configuration Management Authentication and Single Sign-On Authentication and the Components tab.
2. From the list of policy configurations, select the policy configuration for the component name that corresponds to the application for which the AS Java issues
a logon ticket upon user logon.
Using the Ticket Template to Configure the Login Module Stacks for Issuing Logon Tickets
1. On the Authentication Stack tab for the selected component policy configuration, choose ticket from the dropdown list for Used Template .
2. The login module stack specified by the ticket template appears in the table Login Modules . The login modules appear as shown in the table below:
Login Modules Flag
EvaluateTicketLoginModule SUFFICIENT
BasicPasswordLoginModule REQUISITE
CreateTicketLoginModule OPTIONAL
Note
For this login module stack, the AS Java is both a ticket-accepting and ticket-issuing system. The AS Java first checks to see if the user presents a
valid logon ticket with the EvaluateTicketLoginModule . If this is the case, the AS Java accepts the logon ticket and authenticates the user with the valid
logon ticket.
If no logon ticket exists for the user, the AS Java authenticates the user using Basic Authentication. If successful, then the user is issued a logon ticket.
3. Save your changes and restart the application for the changes to take effect.
Configuring the Login Module Stacks for Issuing Logon Tickets Manually
To adapt another template or to manually adjust the login module stacks to issue logon tickets for access to individual applications, follow the steps below:
1. On the Authentication Stack tab for the selected component's policy configuration, add the login module that authenticates the user before issuing a ticket
and choose its flag.
2. For example, to authenticate users with user names and passwords, you can add the BasicPasswordLoginModule with a REQUISITE flag.
3. Add the login module CreateTicketLoginModule to the login module stack so that it takes place after the login module that actually authenticates the user.
4. Assign the flag SUFFICIENT to the CreateTicketLoginModule .
5. Save your changes and restart the application for the changes to take effect.
Configuring Logon Ticket Options
To change logon ticket options, edit the following UME properties accordingly:
login.ticket_lifetime
Note
The time tolerance when verifying the creation and the expiration date of login tickets is set to 3 minutes.
login.ticket_client
Caution
In a combined ABAP and Java system, where both servers have the same system ID, you must specify a unique client ID to use for logon tickets on

the AS Java. For more information, see Specifying the Client to Use for Logon Tickets .
For more information about changing UME properties, see Editing UME Properties .
Result
When the user accesses the application, it processes the login module stack as specified. After successfully authenticating the user, the JAAS login module
CreateTicketLoginModule creates a logon ticket for the user.
Note
You can see the key that the AS Java uses to sign issued logon tickets on the Show SSO Certificate tab in the Trusted Systems Single Sign-On with
SAP Logon Tickets configuration functions of the SAP NetWeaver Administrator. To change the key, use the TicketKeystore keystore view that is
accessible from the Key Storage management functions of the SAP NetWeaver Administrator. For more information, see Replacing the Key Pair to Use for
Logon Tickets and Using the AS Java Key Storage .
5.2.2.2.1.1 Specifying the Client to Use for Logon Tickets
Use
When issuing logon tickets, it is necessary to make sure that the user ID for which the logon ticket has been issued is unique. If the accepting system is an AS
ABAP, this includes determining the system ID and the client where the user exists. These attributes are required when maintaining the access control list in
accepting systems and are therefore included in the user's logon ticket.
When the AS Java is the ticket-issuing system, its system ID is used as specified in the installation. Although the AS Java does not have a client, it still needs to
provide a client value to use for logon tickets so that the tickets can be accepted by other systems, for example, an AS ABAP system. The default client for the
AS Java is 000, however, you can configure the use of a different value.
Caution
The system ID and client combination must be unique when tickets are accepted by an AS ABAP system. Therefore, in a combined ABAP and Java
installation, where the system IDs are the same, you must change the default client for the AS Java (000) to a client that does not exist on the AS ABAP
system.
You configure the client ID with the UMEproperty login.ticket_client .
Additionally, you can override the client per user by assigning the following UME user attribute:
Name: SAP_CLIENT
Namespace: $usermapping$
Procedure
1. Using the identity management functions of the SAP NetWeaver Administrator, enter the AS Java client ID as a value for the UMEproperty
login.ticket_client .
For more information, see Editing UME Properties .
2. Restart the AS Java.
5.2.2.2.1.2 Replacing the Key Pair to Use for Logon Tickets
Use
There are several use cases for replacing the key pair to use for logon tickets on the AS Java, for example:
In a dual-stack system where the SIDs for both the AS ABAP and the AS Java are the same, you must replace one of the key pairs so that the
Distinguished Names are unique.
You must replace the key pair used for logon tickets before the public-key certificate expires.
This procedure describes how to replace the AS Java's key pair to use for logon tickets.
When creating the key pair, you must use the following information.
The key pair must exist in the keystore view TicketKeystore .
The entry must have the name SAPLogonTicketKeypair .
Later, you have to be able to export the public-key certificate so that you can import it into the accepting servers' keystores or Personal Security
Environments (PSEs). Therefore, store the public-key certificate separately using the Store certificate option.
Use the DSA algorithm.
Procedure
Using the Key Store management functions of the SAP NetWeaver Administrator:
1. Select the TicketKeystore view.
2. Delete the SAPLogonTicketKeypair and SAPLogonTicketKeypair-cert entries.

3. Create a Key Pair and a Public-Key Certificate with the following properties.
For more information about creating key pairs in a key store view, see Creating a Key Pair and Public-Key Certificate .
1. Enter SAPLogonTicketKeypair as the key pair Entry Name.
Caution
Do not enter a different name. This AS Java uses the entry with this name to sign logon tickets.
2. Choose DSA as the algorithm to use.

3. Select the options to store the public key certificate
4. Enter the Subject Properties in the corresponding fields.
The entries in these fields build a Distinguished Name in the form:
CN=<Common Name>, OU=< Organization Unit Name >, O=< Organization Name >, L=< Locality Name >, ST=<
State/Province >, C=DE
Note
Use capital letters for the Country Name.
Result
The AS Java uses this public-key certificate to digitally sign logon tickets.
You must also import this key pair into all ticket-accepting systems.
5.2.2.2.2 Configuring the AS Java to Accept Logon Tickets
Use
The AS Java uses EvaluateTicketLoginModule to accept logon tickets for SSO. After receiving the logon ticket from the user's Web browser, the AS Java verifies
the ticket signature based on the established trust relationship with the issuing system. Based on the ticket validity, the AS Java authenticates the user.
Note
If you are using authentication assertion tickets for SSO between the AS ABAP and the AS Java, the corresponding module is
EvaluateAssertionTicketLoginModule .
Prerequisites
To check the validity of a user's logon ticket, the AS Java must be able to verify the issuing server's digital signature.
If the AS Java is both the ticket-issuing server and the accepting server, it can automatically verify its own digital signature.
If the ticket-issuing server is a different server, that server's public-key certificate must be available in the keystore view that the AS Java uses for verifying
logon tickets.
Procedure
The Trusted Systems SSO Wizard configuration functions of the SAP NetWeaver Administrator enable you to use wizard-based management of trust
relationships for SSO with logon and assertion tickets. The configuration changes made with the wizard have a global effect for ticket-based SSO to the AS Java.
Open the SSO Wizard.
Note the following:
If the ticket-accepting system is SAP NetWeaver 7.0 SP14 or higher, you can access the SSO Wizard by choosing Configuration Management
Security Trusted Systems .
If the ticket-accepting system is SAP NetWeaver 7.0 SP 13 or lower, you must first deploy the SSO Wizard. For more information, see SAP Note 1083421.
The system which you configure is displayed in the Selected Accepting System section.
There are two ways to add a trusted system:
By connecting to the system and requesting its certificate.
Caution
If the ticket-issuing system is SAP NetWeaver 2004 SP20 or lower, or SAP NetWeaver 7.0 SP13 or lower, you must configure it so it can send a
response to the certificate request. For more information, see SAP Note 1083421.
By manually uploading the certificate of the system.

Adding a Trusted System by Connecting to It
1. In the Trusted Systems section, choose Add Trusted System By Querying Trusted System .
2. The System Landscape Directory (SLD) opens automatically and lets you select the system you want to add. Select the system and choose OK . The
connection details for the selected system are displayed automatically.
Note
If you cannot find the system you want to add, choose Cancel and provide the connection details:
1. Select the type of the system from the System Type dropdown list.

2. Enter the necessary connection details.
Note
If you want to add an AS ABAP system, the field System Number appears. You can get the system number of an ABAP system using its license
key, which you received from SAP.
3. Enter your user name and password in the provided fields and choose Next .
4. The details about the selected system's certificate appear. To add the system, choose Finish . If you want to make changes, choose Back .
Adding a Trusted System by Manually Uploading its Certificate
Before you start the following procedure, you must export the trusted system's public-key certificate.
1. In the Trusted Systems section choose Add Trusted System By Uploading Certificate Manually .
2. Enter the System ID and Client in the relevant fields.
3. Browse to the location of the system's certificate. Select the certificate and choose Open .
4. Choose Next . The information about the system and the certificate is displayed. To add the system as trusted, choose Finish . If you want to make
changes, choose Back .
Configuring the Login Module Stack
Add the login module EvaluateTicketLoginModule (or EvaluateAssertionTicketLoginModule ) to the login module stacks for the AS Java policy configurations of
the application components that accept login tickets for SSO.
1. In the SAP NetWeaver Administrator go to Configuration Management Security Authentication and Single Sign-On Authentication .
2. Select the policy configuration for the application component to accept logon tickets from the Policy Configuration Name table.
3. In the Details of policy configuration <name> section, choose the Edit pushbutton.
4. Choose the Add pushbutton with the quick info text Add login module to the policy configuration .
5. Choose the EvaluateTicketLoginModule (or EvaluateAssertionTicketLoginModule ) from the Login Module Name list and choose the Add pushbutton.
Choose the Save pushbutton.
Note
If you change the options of a login module in the user store, the changes are inherited by all policy configurations that use this login module.
If you change the options of a login module in a single policy configuration, the change applies only to that policy configuration. In this case, the login
module will no longer inherit its options from the user store. To restore the inheritance, change the options in the policy configuration or in the user store so
that they are identical.
Result
After you complete the wizard, the ticket-issuing system is shown in the Trusted Systems list. The AS Java accepts logon tickets that have been issued by the
corresponding server.
More Information
Checking or Updating the Certificates of Trusted Systems
Testing the Use of Logon Tickets
Sample Login Module Stacks for Using Logon Tickets
5.2.2.2.2.1 Checking or Updating the Certificates of Trusted

Systems
Use
You can check the identity of a trusted system or update the certificate of a trusted system by using the wizard-based management of trusted systems.
Procedure
Open the SSO Wizard.
The system which you configure is displayed in the Selected Accepting System section.
Checking the Certificate of a Trusted System
You can check the identity of a trusted system either by connecting to that system and requesting its certificate or by manually uploading the system's certificate:
Checking Certificates
Action Procedure
Checking the certificate by connecting to the system. 1. In the Trusted Systems list, select the system whose certificate you want to
check.
2. In the Trusted System SSO Certificate Information section choose Check
Against Issuing System By Querying Issuing System . The connection
details of the trusted system are displayed automatically.
Note
If there is more than one system in the System Landscape Directory (SLD)
with the same System ID and Client , then choose Browse SLD and
select the proper system.

If the trusted system you are querying is not in the System Landscape
Directory (SLD) then its connection details are not displayed automatically
and you must provide these details manually.
4. If the certificates on the accepting and on the trusted systems do not match, the
wizard proposes to update the certificate on the accepting system. To update the
certificate, choose Update .
Checking the certificate by manually uploading it. 1. In the Trusted Systems list, select the system whose certificate you want to
check.
2. In the Trusted System SSO Certificate Information section, choose Check
Against Issuing System By Uploading Certificate Manually .
3. Browse to the location of the certificate. Select the certificate and choose Open .
4. To start the certificate check, choose Next .
5. If the certificates on the accepting and on the trusted systems do not match, the
wizard proposes to update the certificate on the accepting system. To update the
certificate, choose Update .
Updating the Certificate of a Trusted System

You can update a trusted system's certificate either by connecting to that system and requesting its certificate or by manually uploading the system's certificate:
Updating Certificates
Action Procedure
Updating the certificate by connecting to the system. 1. In the Trusted Systems list select the system whose certificate you want to
update.
2. Choose Update Certificate By Querying Trusted System . The
connection details of the system are displayed automatically.
Note
If there is more than one system in the System Landscape Directory (SLD)
with the same System ID and Client , then choose Browse SLD and
select the proper system.
If the trusted system you are querying is not in the System Landscape
Directory (SLD) then its connection details are not displayed automatically
and you must provide these details manually.
4. Information about the selected system's certificate is displayed. To update the
certificate, choose Finish . If you want to make changes, choose Back .
Updating the certificate by manually uploading it. 1. In the Trusted Systems list select the system whose certificate you want to
update.
2. Choose Update Certificate By Uploading Certificate Manually .
3. Browse to the location of the certificate. Select the certificate and choose Open .
Choose Next .
4. Information about the uploaded certificate is displayed. To update the certificate,
choose Finish . If you want to make changes, choose Back .
5.2.2.2.3 Testing the Use of Logon Tickets
Use
Because the AS Java always accepts its own tickets, you should use two separate servers to test the use of logon tickets. Configure one as the issuing server
and a different one to accept the logon tickets from the first server.
Prerequisites
You have set up a test application for creating logon tickets.
If the AS Java is the ticket-issuing server, then you can use one of the example programs provided with the server, such as Hello. The application is
deployed on the ticket-issuing AS Java and its login module stack is configured to authenticate the user and then create a logon ticket.
You have a test application for testing the use of logon tickets for successive logons to the AS Java. This application is also deployed on the corresponding
AS Java and its login module stack configured to accept logon tickets.
Your Web browser is configured to prompt for session cookies.
If you do not set your Web browser to prompt for cookies, then alternatively you can verify the use of logon tickets in the security log using the Log Viewer.
The corresponding log is security.log under Cluster → Server → .\log → system.
Procedure
Testing the Creation of Logon Tickets
1. Call the test application for creating a logon ticket (such as Hello).
2. Authenticate yourself as necessary, for example, using user ID and password.
You receive several cookies.
3. View the detailed information for each cookie that you receive.
The logon ticket is a cookie with the name MYSAPSSO2.
The message New SAP Logon Ticket for user <user_ID> has been created. in the security log indicates that the logon ticket has been

created successfully for the user.
Testing the Use of Logon Tickets for Successive Access
Using the same Web browser as you used for the first test, access the test application for using logon tickets.
You should receive access to the application without having to authenticate yourself. If you are not allowed access, then Single Sign-On using logon tickets is not
set up correctly.
The message Ticket verify of user <user_ID> successful. in the security log indicates that the logon ticket was used for authentication on the
server.
Possible Reasons for Unsuccessful Single Sign-On
The application used for accepting logon tickets does not reside in the same DNS domain as the application that issued the logon ticket.
The login module stacks are not set up correctly.
5.2.2.2.4 Sample Login Module Stacks for Using Logon Tickets
Use
Sample Login Module Stack for Creating Logon Tickets
When processing the following login module stack, the server will issue the user a logon ticket after successful authentication using the Basic Authentication
mechanism (user ID and password).
Login Modules Flag
BasicPasswordLoginModule OPTIONAL
CreateTicketLoginModule SUFFICIENT
Sample Login Module Stack for Accepting Logon Tickets

When processing the following login module stack, the server will accept a user's logon ticket. If the user does not possess a valid logon ticket, then the server
reverts to using Basic Authentication.
Login Modules Flag
BasicPasswordLoginModule SUFFICIENT
Sample Login Module Stack for Creating and Accepting Logon Tickets
When processing the following login module stack, the server will revert to authentication using Basic Authentication if the user does not possess a valid logon
ticket. After successful authentication, the server then issues a logon ticket to the user. This is the login module stack provided with the ticket component.
Login Modules Flag
BasicPasswordLoginModule REQUISITE
CreateTicketLoginModule OPTIONAL
5.2.2.2.5 Configuring the Validity Period of Logon Tickets
Use
To reduce the risk malicious users reusing logon tickets in replay attacks, reduce the validity period of the logon tickets. The default validity period is eight hours.
Prerequisites
This procedure requires you to restart the SAP NetWeaver Application Server (AS) Java, so you should plan for the required downtime while the AS Java
restarts.
You have configured the AS Java to support Single Sign-On (SSO) with logon tickets.
Procedure
1. Configure the required UME properties.
For more information about editing UME properties, Editing UME Properties .
Set the UME property ume.admin.login.ticket_lifetime . You can set hours and minutes.
Note
hh:mm
2. Restart the AS Java.

5.2.3 Using X.509 Client Certificates
Use
SAP NetWeaver systems enable you to authenticate user access in an SSO environment with X.509 certificates. For this SSO scenario, SAP NetWeaver
Application Server (AS) uses X.509 client certificates to authenticate web users transparently with the underlying SSL security protocol. In addition, you can
perform the issuing and administration activities for the client certificates of the user centrally, using a trust center service and a public-key infrastructure.
Prerequisites
Client certificate authentication uses cryptography to secure user access to SAP NetWeaver systems. Therefore, to use authentication with client certificates
your SAP NetWeaver systems must be enabled to use strong cryptography.
Users accessing SAP NetWeaver have to possess valid X.509 client certificates, issued by a trusted CA..
The use of SSL is configured for your SAP NetWeaver systems.
AS ABAP: Configuring the AS ABAP for Supporting SSL
AS Java: Configuring the Use of SSL on the AS Java
Integration
Public-Key Infrastructure / Trust Center Services
Users must receive their client certificates from a Certification Authority (CA) as part of a public-key infrastructure (PKI). If you do not have an established PKI then
you can use a trust center service to obtain certificates.
For more information about PKI, see Public-Key Technology .
SSL
When using client certificates, users are authenticated at the communication protocol level using the SSL protocol. Enabling the use of SSL is necessary for the
connections where user authentication takes place.
Features
When using X.509 client certificates, the integrity and the confidentiality of the authentication credentials is provided using cryptographic functions and the SSL
protocol. In addition, to establish higher levels of trust and non-repudiation for business transactions, users can use produce digital signatures with the client
certificates.
When users authenticate with their client certificates, SSO is enabled by the underlying PKI technology and established trust between certificate issuing and
certificate accepting systems. Thereby, users can use their certificates for secure access to many Intranet and internet services. PKI technology can also reduce
reliance on other authentication mechanisms. After users receive their certificates from the CA, they no longer need to authenticate with a user name and
password.
Activities
The activities involved to enable user authentication with X.509 client certificates are specific to the underlying technology of your SAP NetWeaver system. The
configuration activities can differ depending on whether you use an intermediary proxy server that terminates the SSL connection.
For more information about configuring the use of client certificates for SAP NetWeaver systems see:
Using X.509 Client Certificates on the AS ABAP
Using X.509 Client Certificates on the AS Java
More Information
X.509 Certificates
5.2.3.1 Using X.509 Client Certificates on the AS ABAP

Users who access SAP NetWeaver Application Server (SAP NetWeaver AS) for ABAP from a Web browser and present a valid client certificate can be
authenticated on the server using the SSL protocol.
For this scenario, the information contained in the certificate is passed to the server and the user is logged on to the server based on this information. User
authentication takes place in the underlying SSL security protocols and no user ID and password entries are necessary.
Prerequisites
Users possess valid X.509 client certificates issued by a trusted CA.
The user's client certificates are imported in their client system's Web browsers.
The AS ABAP is configured to support HTTPS connections and SSL.
The identification of the user, the Distinguished Name, that is specified in his or her certificate must map to a valid user ID on the AS ABAP.
Public-Key Infrastructure
To authenticate with client certificates, users must receive their X.509 client certificates from a trusted Certification Authority. The AS ABAP uses the established
Public Key Infrastructure (PKI) to verify the identity of certificate owners and to issue, validate, renew, and revoke certificates. If you use X.509 client certificates for

authentication, then you need access to a PKI.
Using SSL for Client Authentication

When using X.509 client certificates, users are authenticated on the AS ABAP using the SSL protocol. Therefore, HTTPS connections are necessary for the
communication between the Web browser and the AS ABAP.
Features
The integrity and confidentiality of the authentication credentials is provided using the SSL protocol and PKI technology. In addition, users can produce digital
signatures using the client certificates to establish higher levels of trust and non-repudiation for business transactions.
Once users receive their client certificates from the CA, they can use them to access the AS Java and passwords are no longer used for authentication purposes.
In addition, users can use their certificates for secure access to other Intranet or Internet services.
Related Information
Configuring the AS ABAP for Supporting SSL
Public-Key Technology
Rule-Based Certificate Mapping
Configuring the AS ABAP to Use X.509 Client Certificates
5.2.3.1.1 Configuring the AS ABAP to Use X.509 Client

Certificates
Prerequisites
The AS ABAP is enabled to use SSL. For more information, see Configuring the AS ABAP for Supporting SSL.
Context
You can use this procedure to enable the use of client certificates for authentication with SAP NetWeaver Application Server (AS) ABAP.
Procedure
1. Set the profile parameter icm/HTTPS/verify_client to the value 1 (accept certificates) or 2 (require certificates).
Note
If you are configuring X.509 certificate logon for message-based authentication with Web services, you do not have to set this parameter.
2. Restart the IC manager using transaction SMICM.

3. Maintain the SSL server PSE of the server.
Use the trust manager (transaction STRUST) and import the root certificate of the issuing CA into the certificate list of this PSE.
4. Map users to the distinguished names of their certificates.
Recommendation
We recommend you use rule-based certificate mappings.
For more information, see Rule-Based Certificate Mapping.
If you previously used manual mapping in table USREXTID and do not want to migrate to rule-based mapping, you can continue to use the legacy
method.
For more information, see Mapping X.509 Certificates in Table USREXTID.
Results
The AS ABAP can accept X.509 client certificates for user authentication.
5.2.3.1.2 Rule-Based Certificate Mapping
Use
Rule-based certificate mapping (transaction CERTRULE) enables the mapping of users from parts of the subject or the subject alternative name of an X.509
certificate for a given issuer to the user ID or alias of a user master record. With a few rules, you can enable logon with X.509 certificates for all your users. The
tool also enables you to load an X.509 certificate and check if a rule applies to the certificate and if the certificate maps to a user. For individual users that do not
map to the rules you create, you can create exceptions.

Once enabled, rule-based mapping replaces manual mapping in the table USREXTID. If you currently use table USREXTID for certificate mapping, use
transaction CERTRULE_MIG to create a set of rules based on your current entries.
Prerequisites
You have the required authorizations. Rule-based certificate mapping requires the following authorization objects:
CC control center: System administration ( S_RZL_ADM)
Activity 03 grants display authorizations.
Activity 01 grants change authorizations.
User Master Maintenance: User Groups ( S_USER_GRP)
Activity 03 grants display authorizations.
Activity 02 grants change authorizations.
Class : Enter the names of user groups for which the administrator can maintain explicit mappings.
You have enabled the login/ certificate_ mapping_ rulebased profile parameter.
Caution
Before enabling this profile parameter, you must have migrated any entries in the USREXTID table to a mapping rule or explicit mapping.
More Information
Managing Rules for Certificate Mapping
Migrating to Rule-Based Certificate Mapping
5.2.3.1.2.1 Managing Rules for Certificate Mapping
Use
As a system administrator, you must ensure that new X.509 are covered by your existing body of rules. When they do not, you must decide if you must modify an
existing rule, create a new rule, or whether to handle the X.509 certificate as an exception.
More Information
Checking Certificates for Rule Coverage
Creating Rules for Certificate Mapping
Creating Explicit Mappings for Certificates
5.2.3.1.2.1.1 Checking Certificates for Rule Coverage
Prerequisites
You have an X.509 certificate saved as a file.
You have the required authorizations.
Procedure
1. Start Rule-based Certificate Mapping (transaction CERTRULE).
2. Choose .
3. Check the results in the Certificate Status Based on Persistence section.
The display indicates whether the certificate can be mapped with a rule or an explicit mapping. If the system can map the certificate, the display indicates
the user ID or alias the system reads from the certificate and whether such a user exists in the system.
Results
If the system cannot map the certificate to a rule or exception, you must decide whether you want to create a new rule or exception for the certificate.
If the system can map the certificate, you can choose to jump to the relevant mapping source.
5.2.3.1.2.1.2 Creating Rules for Certificate Mapping
Prerequisites
If you plan to match certificates to aliases of user master records, you have ensured that the aliases include the relevant content.

Context
This procedure enables you to create a rule for mapping X.509 certificates from a given issuer to user records of SAP NetWeaver Application Server (AS) ABAP.
Each certificate contains attributes in the subject, and sometimes, in the subject alternative name fields. You select one of these attributes for the AS ABAP to
match to either the user name or alias of the user master record.
Procedure
2. Choose .
3. Choose to switch to edit mode.
4. Choose the Rule pushbutton.
5. Choose whether you want the AS ABAP to read the logon name (user name or alias) from an attribute of the subject or the subject alternative name.
6. From the subject or subject alternative name, choose the certificate attribute to read as the logon name. The AS ABAP uses the value of this attribute,
ignoring case, to identify the user master record to which this certificate maps.
7. Select User Name or Alias as the logon attribute.
This is the attribute of the user master record that the AS ABAP matches with the value in the certificate attribute.
8. Configure the subject filter.
AS ABAP uses the subject filter together with the issuer filter to check whether a rule can be used for a certificate. To do this, the system evaluates the
attributes and the associated values of the subject filter and their position in reverse order.
Example
Assume a certificate with a the following attributes:
CN=MarcoRicci,C=IT,O=SAP
A rule with the subject filter C,O can, for example, expect that the attribute C is in the penultimate position and the attribute O is in the last position for
the certificate subject. The AS ABAP applies a rule only if the order of the attributes matches exactly.
You can also remove attributes from the subject filter to make the attribute a wildcard. If you remove C=IT from the subject filter, the AS ABAP still expects
the attribute in the same position, but the attribute can include any value. The rule includes the attribute as C=*.
Note
The system always expects the common name (CN), user ID (UID), and e-mail (E) attributes to be wildcards, even if you do not choose one of them as
the mapping attribute nor do they appear in the subject filter. The rule includes the attributes as CN=*, UID=*, E=*.
To regenerate the default list of attributes after you make changes to the subject filter or change the subject certificate attribute for mapping, choose .
9. Move the rule up or down in the list of rules as required.
Note
The AS ABAP checks the rules in order and applies the first rule that matches. If the AS ABAP finds a rule that applies, but does not find a user to
match the certificate, the logon fails even if a later rule would apply and result in a successful logon.
Results
When a user agent presents an X.509 certificate to the AS ABAP for authentication, the AS ABAP checks the rules in order. The AS ABAP applies the first rule
that matches. For each rule, the AS ABAP applies the issuer filter and subject filter to determine if the rule applies. The issuer filter and the issuer must be
identical. The table below shows examples of the application of a subject filter.
Subject Filter Certificate Subject Result
CN=*, C=IT, O=SAP CN=MarcoRicci, C=IT, O=SAP Match. Attempt to log on user MARCORICCI. If the AS
ABAP can find a single user with this name as user ID or
alias according to the configuration, logon is successful.
CN=*, C=IT, O=SAP CN=MarcoRicci, O=SAP, C=IT Fail. Attributes O and C are in not in identical order.
CN=*, C=IT, O=SAP CN=MarcoRicci, C=IT, O=SAB Fail. The values of the O attributes are not identical.
CN=*, C=IT, O=SAP CN=MarcoRicci, C=IT, O=SAP, OU=DEV Fail. The filter requires that the first attribute from the end
must be O=SAP. In this case, the first attribute is OU=DEV.
5.2.3.1.2.1.3 Creating Explicit Mappings for Certificates
Prerequisites

Context
Use this procedure to create an exception to the rules for X.509 certificate mapping. This maps a certificate with a specific subject and issuer to a specific user
record in SAP NetWeaver Application Server (AS) ABAP.
Recommendation
Try to avoid creating explicit mappings. Too many mappings can lead to administrative overhead. Use mapping rules when possible.
For more information, see Creating Rules for Certificate Mapping.
Create such mappings when the user ID and alias cannot be mapped to an attribute in the subject of the certificate or you only want to allow the bearers of
specific certificates entry to your system, and not allow other bearers of certificates from the same issuer.
Procedure
2. Choose .
4. Choose the Explicit Mapping pushbutton.
5. Select a user record to map to.
5.2.3.1.2.2 Migrating to Rule-Based Certificate Mapping
Use
Use this procedure to migrate your certificate mappings in the USREXTID table to rule-based mapping. Rule-based certificate mapping reduces the cost of
operating an X.509 certificate infrastructure by enabling you to convert most mappings to rules. You can carry over any remaining mappings as exceptions.
Prerequisites
Procedure
This procedure assumes you have a large number of entries without issuers. If you have already maintained issuers in table USREXTID, you must change this
procedure slightly as noted in the procedure below.
1. Start Rule-based Certificate Mapping Migration (transaction CERTRULE_MIG).
2. Select users or user groups.
Select by user groups if you only have authorizations for specific user groups.
4. Ensure that you are only displaying users with no mappings and not displaying users with mappings either explicitly or by rule. Use the buttons with the
red , yellow , and green indicators at the top of the list.
5. Choose to select all subjects in the table without issuers.
6. Choose and enter a likely issuer manually or import it from a certificate in the file system or the server PSE.
Do not worry about whether the issuer is correct for all entries. You just want to cover as many entries as possible.
Note
AS ABAP saves all issuers in a migration table. Entries in table USREXTID do not change. If the issuer already exists in the USREXTID table, it
appears in the Issuer column and the Classic checkbox is selected. You cannot change the issuer value from the USREXTID table.
If you already maintained issuers in table USREXTID, select entries by issuer and create rules to match the entries.
7. Create rules that match the users.

To create a rule, choose the Rule pushbutton.
For more information, see Creating Rules for Certificate Mapping from step 5 on.
As you save the rule, entries covered by the rule disappear from the list and appear under the green indicator .
8. Repeat steps 5-7 until you have reduced the list to a manageable number.
As you work through the list, your goal is to change the status of the entries from to . As rules apply to the mappings, they disappear from the list.
What a manageable number is depends on how many entries you are willing to create explicit mappings for. For the remaining entries, create explicit
mappings.
9. Create any exceptions.
To create an exception, select an entry and choose the Explicit mapping pushbutton.
This creates an explicit mapping of certificate subject and issuer to the specific user. The entry receives the status .
11. Enable the use of rule-based certificate mapping.
Set the profile parameter login/ certificate_ mapping_ rulebased to 1.

For more information, see Changing and Switching Profile Parameters.
5.2.3.1.3 Mapping X.509 Certificates in Table USREXTID
Use
Use this procedure to map users of SAP NetWeaver Application Server (AS) ABAP to external IDs used in X.509 certificates.
Recommendation
Maintaining table USREXTID is a manual process. We recommend you use rule-based mapping for X.509 certificates.
Prerequisites
If you mass configure user mappings, you have determined what common factor to use to create the external ID. You can choose from the following:
User ID
Logon alias
A value determined by a custom BAdI
You must create your own BAdI. SAP provides the BAdI USREXTIDMAPPING as an example of just such an implementation.
Procedure
Performing Mass Configuration of Mapping Data
1. In transaction SA38, open report RSUSREXT.
2. In the User section, determine the selection criteria for the users to which you want to map external IDs.
3. In the Ext. Name Changed section, enter the following data:
Enter DN in the External ID type field.
Enter any text that is to appear before or after the common part of the external name ID.
Example
Enter CN= as the prefix and , O=EXAMPLE, C=US as the suffix.
Choose the source for the common part of the external name ID.
4. Enter further options as required.
5. Choose .
Mapping a Single User
1. In transaction SM30, open view VUSREXTID.
2. Enter DN in the External ID type field.
3. Edit the table entries.
4. Set the Activated indicator to activate the client certificate logon for the user.
5.2.3.1.4 Assigning Users an Existing Certificate for Single Sign-

On with SSL
Context
To log on to Web applications with Single Sign-On (SSO) using Secure Sockets Layer (SSL), users who already have a browser certificate can assign this
certificate to their own user. The system administrators can use the following procedure to create a URL that allows the users to make this assignment.
Procedure
1. Start transaction SICF.
2. Enter the service name CERTMAP and choose Execute .
3. Under Virtual Hosts/Services , choose the Web Dynpro application CERTMAP.
4. Choose Service/Host Activate .
5. Choose Service/Host Test .
A web page appears, on which the logged-on user can assign a certificate. The page displays the SSL certificate of the user. For a Web Dynpro
application, the URL of this page looks like this: https://<host>:<port>/sap/bc/webdynpro/sap/certmap?sap-client=<client>&sap-language=<language>.
6. Make the URL available to the users, for example, as a link on a portal page.
5.2.3.2 Using X.509 Client Certificates on the AS Java
Use
In addition to using SSL for encrypting connections, you can use SSL and X.509 client certificates to authenticate client or user access requests for AS Java
applications.

When using client certificates, authentication takes places transparently for the user with the underlying SSL security protocol. Therefore, you can use
authentication with client certificates to integrate the AS Java into a Single Sign-On environment.
Integration
Public-Key Infrastructure
Users need to receive their client certificates from a Certification Authority (CA) as part of a public-key infrastructure (PKI).
For more information about PKI, see Public-Key Technology .
SSL
When using client certificates, users are authenticated at the communication protocol level using the SSL protocol. Therefore, you need to configure the use of SSL
for the connections where user authentication takes place. The AS Java enables you to use SSL, or user authentication with certificates, when users access the
AS Java applications with or without an intermediary gateway proxy server.
For more information, see Using SSL With an Intermediary Server .
Prerequisites
Users possess valid X.509 client certificates issued by a trusted CA.
There must be an SAP Cryptographic Library installed. You can also use the SSL plug-in. For more information, see Installing the SAP Cryptographic
Library for SSL .
The user's client certificates are imported into their client system's Web browsers.
The AS Java is configured to support HTTPS connections and SSL. For more information, see Configuring the Use of SSL on the AS Java .
Features
The AS Java enables you to authenticate users with client certificates using the following configuration scenarios:
You can store client certificates for users from the Identity Management functions of the AS Java and authenticate access based on the user-certificate
mapping in the UME data source of the AS Java.
Alternatively, you can configure rules for login with client certificates and authenticate user access directly from the certificate information. For this scenario,
you do not need to store the certificate information for users.
The integrity and confidentiality of the authentication credentials is provided using the SSL protocol and PKI technology. In addition, users can produce digital
signatures using the client certificates to establish higher levels of trust and non-repudiation for business transactions.
Once users receive their client certificates from the CA, they can use them to access applications and passwords are no longer used for authentication purposes.
Users can also use their certificates for secure access to other Intranet or Internet services.
Activities
To use X.509 client certificates on the AS Java, you need to make the following configuration settings:
1. Allow use of the certificate.
To allow use of the certificate for proper authentication, you have to configure a property ume.logon.allow_cert. This property is used when an HTTP logon
page contains a link to an HTTPS page that permits certificate authentication. To modify this property, choose SAP NetWeaver Administrator →
Authentication and Single Sign-On → Properties.When this property is selected, the logon URL link of the certificate is displayed on the logon page. On the
certificate logon page, users can map their certificates to their user IDs. As a result, the authentication is performed using the user certificate instead of user
name and password.
2. Configure SSL so that X.509 user certificates are in a trusted relationship with the SSL server certificates.
For the configuration of a port, you need to define whether the system asks for a certificate or uses it as required.
To perform this configuration, choose SAP NetWeaver Administrator → Configuration Management → SSL. You can make these settings in the Client
Authentication Mode column of the SSL Access Points table.
You have to configure the CA certificates for the respective port so that the system can accept user certificates issued by specific CAs.
That means the user certificates must be signed by one or more CAs.
The root CA certificate must be present in the table on the Trusted CAs tab.
3. Configure appropriate user mapping using the ClientCertLoginModule options.
For more information about configuring user mappings, see Modifying Client Certificate Authentication Options .
4. Add the ClientCertLoginModule to the authentication stack.
To add the login module, follow these steps:
1. Choose SAP NetWeaver Administrator → Authentication and Single Sign-On → Components.
2. Select the Policy Configuration Name.
3. Choose the Editbutton
4. On the Authentication Stacktab, add ClientCertLoginModulewith a necessary flag.
Note
The selection of a flag depends on the specific scenario. For example, if you set ClientCertLoginModulewith the flag SUFFICIENT, and
BasicPasswordLoginModulewith flag REQUIRED, the system will try to authenticate the user with the ClientCertLoginModule. If the authentication
with this module is not successful, the system will use the next module BasicPasswordLoginModule. For more information about the use of the
flags, see Policy Configurations and Authentication Stacks .
See Also
For more information about the configuration activities for using X.509 client certificates for AS Java authentication, see the following sections:
Configuring the Use of Client Certificates for Authentication
Information about configuring client certificate authentication in scenarios where users access the AS Java directly or through an intermediary proxy server

that tunnels the connection without terminating it.
Using Client Certificates via an Intermediary Server
Information about scenarios where users access the AS Java through an intermediary server that terminates the connection.
Enabling Certificate Revocation
Information about how to use certificate revocation lists (CRLs) on the AS Java to make sure that a given certificate has not been revoked by the issuing
Certification Authority (CA).
Note
If you are using authentication with client certificates in the portal, you can configure what happens when users log off from the portal. By default, they
are redirected to the default logon screen after they log off. If the portal is set up to use client certificates, they are automatically logged on again, so it is
impossible for them to log off the portal. To prevent this, you can redirect them to a screen other than the default logon screen after they log off the portal.
5.2.3.2.1 Configuring the Use of Client Certificates for

Authentication
Prerequisites
The AS Java is configured to support SSL with the given certificates. For more information, see Transport Layer Security on the AS Java .
The root certificates of the client certificates' Certification Authorities (CAs) either exists in a keystore view of the AS Java Key Storage or are available in the
file system as a DER-encoded or Base-64-encoded certificate.
Context
Use this procedure to configure the use of client certificates for authentication when users access the AS Java using an end-to-end connection.
For cases where they access the server via an intermediary proxy server that terminates the connection, see Configuring the Use of Client Certificates via an
Intermediary Server .
Note
Client certificates enable you to authenticate users without the need for a user name and a password provided from a logon screen. Therefore, you can also
use client certificates for integrating the AS Java in Single Sign-On environments.
When using client certificates for user authentication, the AS Java uses the certificate information to determine the user's identity.
The algorithm for determining the user ID can be configured by specifying rules. Each of these rules can include several configuration options and, using filters,
be restricted to apply only to certain certificates. In addition, each rule specifies the mechanism to use to determine the mapping between the certificate matching
this restriction and the user ID for the authenticating user.
You can configure the use of the following mechanisms to establish the user ID associated with a client certificate during the logon process:
The AS Java can match the provided certificate to a client certificate stored for the user ID in the AS Java user data store.
The AS Java can determine the user ID directly from the fields in the client certificate.
Procedure
1. Using the Key Storage management functions of the SAP NetWeaver Administrator, place the root certificates for each of the client certificates CAs as a
CERTIFICATE entry in the ICM_SSL_ < instance_ID > view.
If the certificate already exists in another Key Storage view on the AS Java, you can copy the existing certificate entry to the corresponding view.
Alternatively, if the certificate exists as a file in your file system, you can import it to the AS Java Key Storage. For more information, see Using the AS Java
Key Storage .
2. Using the VCLIENT profile parameter of ICM for the AS Java, select whether the AS Java should:
Request (but not require) that the user presents a client certificate for authentication.
Require that client certificates are to be used for authentication.
For more information, see icm/server_port_<xx> and Maintaining ICM parameters for Using SSL .
3. Configure the ClientCertLoginModule for establishing the AS Java user ID from the client certificate and filtering provided certificates.
For more information, see Modifying Client Certificate Authentication Options .
4. Adjust the login module stacks and configure the login modules for those applications that accept client certificates as the authentication mechanism.
Results
The selected applications accept client certificates for user authentication.
Next Steps
Managing Policy Configurations

Use
The AS Java enables you to use client certificates for authentication with the JAAS login module ClientCertLoginModule . You can use the configuration
options of the ClientCertLoginModule to determine the user ID from the client certificate and to filter provided certificates based on rules for certificate
authentication.
Integration
The options for the ClientCertLoginModule enable you to configure the use of a sequence of several rules for client certificate authentication. To configure a
single rule, you use combinations of several login module options and a prefix that marks the rule number. The prefix that marks the rule number also determines
the sequence for the rule execution.
To enable the use of rule-based certificate authentication, you add the ClientCertLoginModule to the login module stacks of the policy configurations of the
applications to use authentication with certificates. You can configure the options to enable rule-based certificate authentication for individual applications or for all
applications that contain the ClientCertLoginModule in their login module stacks.
For more information, see Managing Login Modules and Managing Policy Configurations .
Features
The login module configuration options enable you to determine the user ID from the client certificate information during logon. You configure several login module
options to specify a single rule for performing authentication with the client certificates. You can use certificate filters and configuration options to determine the user
ID from the certificate information as building blocks to form a single rule. You can combine several rules in a rule sequence, using a prefix for the rule options to
mark the rule number in the sequence of all rules configured for authentication.
The figure below illustrates this concept:
Entity relationship for rules and login module configuration options

Filter client certificates to use for authenticating a user
The configuration options enable you to filter client certificates either by certificate issuer or by certificate subject names.
When you configure the use of filters based on the certificate issuer, you enter the issuer attributes as specified in the client certificate. When you configure filters
based on the certificate subject name, you can enter only several of the certificate subject attributes to define the filtering rule.
Note
The use of filters for a rule is an optional configuration step that you can use to specify criteria about whether to use a rule in a sequence of rules to determine
the user ID from the certificate information. You can configure rules to only determine the user ID without applying filters to restrict the use of only certain
certificates for the authentication. In this case, if the AS Java can not determine a user ID from a certificate, the authentication fails and following rules in a rule
sequence are not checked.
Authenticate a user ID from certificate information

The configuration options support the following modes to determine the user ID from the certificate information:
Search the AS Java user store for a user who is already mapped to the client certificate. This is the default behavior for determining the user ID when you
are using client certificate authentication.
Determine the user ID from the SubjectName field of the X.509 client certificate. You can use this configuration mode for the majority of your certificate
authentication needs to determine the user ID from the certificate information.
Determine the user ID from the V3 extension SubjectAlternativeName of the X.509 client certificate. This is an advanced configuration mode for which
you configure the use of a certificate V3 extension to determine the user ID.
Note
When you use an AS ABAP for UME data source, the determined user ID must be in a valid format for the authentication to succeed. For more
information, see the AS ABAP documentation.
Activities
1. Using the SAP NetWeaver Administrator, go to the configuration options for the ClientCertLoginModule .
For more information, see Managing Login Modules .
2. Configure the ClientCertLoginModule options to determine the user ID based on the client certificate.
Configure the use of stored certificate mappings .
Configure the use of rules based on certificate subject names .

Note
We recommend that you use this configuration for standard client certificate authentication needs.
Configure the use of rules based on certificate V3 extensions .

3. In addition, when using rules based on certificate subject names or V3 extensions, you can also define rules for filtering client certificates .
Result
Authorized users can log on to the AS Java using SSL and X.509 client certificates for authentication. Based on the rule you configure, the
ClientCertLoginModule of the AS Java can determine the user ID from the client certificate and apply filters to the certificates provided for authentication.
See also:
Managing Policy Configurations
5.2.3.2.2.1 Using Stored Certificate Mappings
Use
You can use this procedure to configure the login module stacks of applications to enable the SAP NetWeaver Application Server (AS) Java to authenticate users
based on established mapping of client certificates to user IDs in the UME data source of the AS Java.
To use this mode for client certificate authentication, you have to establish a mapping between the client certificate and the user ID. The AS Java enables you to
map client certificates to user IDs manually with the Identity Management functions of the AS Java. Alternatively, you can add the
CertPersisterLoginModule to the login module stack for client certificate authentication to map automatically client certificates to user IDs on first successful
logon with another authentication mechanism.
Prerequisites
To store users' client certificates in your LDAP directory, or if your users' client certificates are already available in your LDAP directory, you must map the
relevant attributes. For more information, see Attribute Mapping for Client Certificates .
To enable the mapping of client certificates to user IDs, the UMEproperty ume.logon.allow_cert must be set to true . For more information, see
Editing UME Properties .
Procedure
To map certificates to user IDs during logon, add the login modules for client certificate authentication to the login module stacks for the applications that use
authentication with client certificates.
For more information about setting up login module stacks, see Managing Authentication Policy for AS Java Components .
1. Add the ClientCertLoginModule to the login module stack and configure its processing flag.
1. Enter wholeCert as a value for the option Rule1.getUserFrom .
Note
This is the default behavior when you do not configure any options for the ClientCertLoginModule .
2. Add the login modules necessary for the fallback mechanism you are using. For example, to use Basic authentication as a fallback authentication
mechanism, add the BasicPasswordLoginModule to the login module stack and configure its processing flag.
3. Configure the mapping between the client certificates and the user ID. This is a required configuration step for this mode, as based on this mapping the AS
Java can determine the identity information for the user that is logging on.
You can map user IDs to client certificates either manually or by configuring the AS Java to map certificates to user IDs automatically during the first user
logon. For more information, see the following sections:
Maintain the certificate mapping manually .
Maintain the certificate mapping automatically .
Result
Users can access AS Java applications with client certificates. The AS Java determines the user ID based on the mapping between the client certificate and the
user ID in the UME data source.
5.2.3.2.2.1.1 Maintaining the User's Certificate Information
Prerequisites
The UME property ume.logon.allow_cert is set to TRUE .
You can edit this property with the SAP NetWeaver Administrator:
1. Go to Configuration Management Security Authentication and Single Sign-On .

2. Choose the Properties sub-tab and choose the Modify button.
3. Select the checkbox of the ume.logon.allow_cert property.
4. Save the changes.
You have user administration rights for using the UME user management administration console.
Context
When using SSL and client certificates for user authentication, the user is identified using a client certificate. To allow the AS Java to identify users, their client
certificate must be available in their user account. There are several options:
The administrator imports users certificates manually and adds them to the user's data. The following procedure describes the steps required.
Users map their own certificates to their user ID at logon. The administrator does not need to perform any steps.
Users' certificates are already stored as a user attribute on the LDAP directory. In this case you need to map the relevant attributes. For more information,
see Attribute Mapping for Client Certificates . You do not need to perform the steps in the following procedure.
Procedure
1. Start identity management.

For more information, see User Administration Console .
2. Select a user.
3. Modify the user.
4. On the Certificates tab, maintain the user's certificate.
Note
If the Certificates tab does not appear, check the UME parameter ume.logon.allow.cert .
Results
The user can log on to the AS Java using SSL and this client certificate for authentication.
5.2.3.2.2.1.2 Maintaining Certificate Mappings Automatically
Prerequisites
You have configured the ClientCertLoginModule to use a stored certificate mapping to determine the user ID for client certificate authentication.
For more information, see Using Stored Certificate Mappings .
The UME property ume.logon.allow_cert is set to TRUE .
For more information about changing UME properties, see Editing UME Properties .
Context
Use this section to configure automatic mapping of client certificates to user IDs during user logon.
The AS Java can use the CertPersisterLoginModule to automatically map client certificates to user IDs on first logon. To enable automatic mapping, you
add the CertPersisterLoginModule to the login module stacks for the application that use certificate authentication based on a stored certificate mapping.
Procedure
1. Add the CertPersisterLoginModule to the login module stack for client certificate authentication after the login modules for the fallback mechanisms
you are using.
For more information about adding login modules to login module stacks, see Managing Login Modules .
Note
If the CertPersisterLoginModule is not available in the list of login modules, add with the following procedure:
2. Enter CertPersisterLoginModule in the Display Name field.
3. Enter com.sap.security.core.server.jaas.CertPersisterLoginModule in the Class Name field.
2. Choose OPTIONAL for the processing flag of the CertPersisterLoginModule in the login module stack.
Example
The example in the table below is based on the ticket template for SSO with logon tickets, and uses user ID and password authentication for fallback
mechanisms. The example shows a login module stack configuration for automatic certificate mapping on first user logon:
Login Modules Flag Option

EvaluateTicketLoginModule SUFFICIENT {ume.configuration.active=true}
ClientCertLoginModule OPTIONAL { Rule1. getUserFrom=wholeCert}
CreateTicketLoginModule SUFFICIENT {ume.configuration.active=true}
BasicPasswordLoginModule REQUISITE None
CertPersisterLoginModule OPTIONAL None
CreateTicketLoginModule OPTIONAL {ume.configuration.active=true}
The login module stack from the example works as follows:

1. Checks if the user has a valid logon ticket. If yes, authentication succeeds, control returns to the application and the authentication check is concluded.
2. The ClientCertLoginModule checks for a valid user certificate and determines the user ID based on its configuration.
3. If the ClientCertLoginModule can retrieve the user ID based on an already established certificate mapped, the CreateTicketLoginModule
issues a logon ticket for this user ID. Authentication succeeds and the accessed application resumes control.
4. If the ClientCertLoginModule cannot determine the user ID, the BasicPasswordLoginModule authenticates the user with the user ID and
password.
1. If basic authentication is successful, the CertPersisterLoginModule maps the certificate to the user ID and the
CreateTicketLoginModule issues a logon ticket for the user.
2. If the user ID and password authentication is not successful, authentication fails.
5.2.3.2.2.2 Using Rules Based on Client Certificate Subject

Names
Context
You can use this configuration mode to determine the user ID from the SubjectName field of the certificate. You use the configuration options for the
ClientCertLoginModule to configure the rules to determine the user ID based on the SubjectName field in the client certificate.
To enable the use of certificate authentication, you add the ClientCertLoginModule to the login module stack for the applications to use certificate authentication.
Procedure
1. Using the SAP NetWeaver Administrator, go to the configuration options for the ClientCertLoginModule. For more information, see Managing Login Modules .
2. Enter subjectName as a value for the option Rule <n> .getUserFrom of the ClientCertLoginModule .
3. Enter a value for the option Rule <n> .AttributeName of ClientCertLoginModule to specify the attribute of the certificate SubjectName field, which
identifies the user ID.
If an attribute name for the value that you enter does not exist in the SubjectName field of the certificate, then the ClientCertLoginModule determines
the user ID from the first existing attribute name in the certificate SubjectName field.
If the SubjectName field contains more than one matching attribute name, then the ClientCertLoginModule determines the user ID from the first
matching attribute name in the certificate SubjectName field.
Note
This is a mandatory configuration step. Not providing a value for this option results in the certificates used for authentication being rejected.
4. To use rules for filtering the provided client certificates, see Defining Rules for Filtering Client Certificates .
5. Substitute <n> in the Rule <n> prefix of the ClientCertLoginModule configuration options to match the place of this rule in the sequence of configured rules
for client certificate authentication. If you use a single rule, then substitute Rule <n> with Rule1 .
6. Add the ClientCertLoginModule to the login module stacks of the applications to authenticate users based on client certificate subject names.
Results
Users that access the AS Java with client certificates are logged on with user IDs that correspond to the rule for the SubjectName field attribute that you
configured.
Example
The example ClientCertLoginModule configuration below assumes that a user provides a X.509 certificate with the following attributes for the certificate
SubjectName field:
CN= myuser, OU= people, OU= CA, O= mycompany, C= DE

Determining user ID from attribute CN of certificate SubjectName
Option Value
Rule1.getUserFrom subjectName
Rule1.AttributeName CN
Result: The authenticated user ID is myuser .

Determining the user ID from multiple attribute names in the certificate SubjectName
Option Value

Rule1.AttributeName OU
Result: The authenticated user ID is people , matching the first leftmost occurrence of the SubjectName attribute OU .
5.2.3.2.2.3 Using Rules Based on Client Certificate V3

Extensions
Use
You can use the ClientCertLoginModule configuration options to determine the user ID based on rules for the certificate V3 extension
SubjectAlternativeName . You can configure that the AS Java authenticates users either based on extension attribute fields rfc822name or on extension
attribute fields OtherName .
For more information about X.509 certificate extensions and the structure X.509 certificates, see Internet standard RFC 3280.
Procedure
1. Using the SAP NetWeaver Administrator (NWA), go to the configuration options for the ClientCertLoginModule . For more information, see Managing
Login Modules .
2. Enter expertMode as a value for the option Rule <n> . getUserFrom of ClientCertLoginModule .
3. Enter 2.5.29.17 for a value of the option Rule <n> . OID of ClientCertLoginModule .
Note
The ClientCertLoginModule uses the value for the Rule <n> . OID option to find the AttributeName that identifies the user ID. You provide
values using the Abstract Syntax Notation Object Identifier (ASN.1 OID) for the attribute. Entering the ASN.1 OID 2.5.29.17
enables you to retrieve the user ID from an attribute field in the certificate V3 extension SubjectAlternativeName .
4. Enter a value for the option Rule <n> .AttributeName of ClientCertLoginModule to determine the attribute of the SubjectAlternativeName
certificate extension that identifies the user ID. You can use one of the following values:
rfc822Name
For this value,the ClientCertLoginModule chooses for a user ID the first attribute field of type rfc822Name within the certificate V3 extension
SubjectAlternativeName .
OID=< ASN.1 OID >
The ClientCertLoginModule searches the OtherName attribute fields in the certificate V3 extension SubjectAlternativeName for an
attribute with the specified ASN.1 OID . If an OtherName attribute with a matching the ASN.1 OID you enter is found, the
ClientCertLoginModule uses its value for the user ID.
Note
This is a mandatory configuration step. Not providing a value for the rule option Rule <n> .AttributeName results in the certificates used for
authentication being rejected.
Tip
For example, you can choose values for the configuration options of ClientCertLoginModule as shown in the table below:
Name Value
Rule1.getUserFrom expertMode
Rule1.OID 2.5.29.17
Rule1.AttributeName OID=1.3.6.1.4.1.311.20.2.3
For this configuration, the ClientCertLoginModule determines the user ID from an OtherName attribute in the certificate V3 extension
SubjectAlternativeName . The OID of this attribute is 1.3.6.1.4.1.311.20.2.3
5. To use rules for filtering the provided client certificates, see Defining Rules For Filtering Client Certificates .
6. Substitute <n> in the Rule<n> prefix of the ClientCertLoginModule configuration options to match the place of this rule in the sequence of all
configured rules for client certificate authentication. If you use a single rule, then substitute Rule <n> with Rule1 .
7. Add the ClientCertLoginModule to the login module stacks of the applications to authenticate users based on client certificate V3 extension.
Result
Users who authenticate to the AS Java with client certificates can log on with user IDs that correspond to the rule for the certificate V3 extension that you
configured.
Example
Assumptions
The examples below assume that a user provides a X.509 certificate with the following fields:
SubjectName
CN= myuser, OU= people, OU= CA, O= mycompany, C= DE
Issuer

CN= DE User CA 1, OU= DE 010, OU= CA, O= mycompany, C= DE
Extension SubjectAlternativeName with the following attributes:
otherName attribute with fields OID= 1.3.6.1.4.1.311.20.2.3 andvalue = t006472@mycompany.com
rfc822Name = myuser@mycompany.com
Determine user ID from first attribute field of type rfc822Name within the certificate V3 extension SubjectAlternativeName
Option Value
Rule1.OID 2.5.29.17
Rule1.AttributeName rfc822Name
Result: the authenticated user ID is myuser@mycompany.com .
Determine user ID from a field of type OtherName with ASN.1 OID= 1.3.6.1.4.1.311.20.2.3 in the certificate V3 extension
SubjectAlternativeName
Option Value
Rule1.OID 2.5.29.17
Rule1.AttributeName oid= 1.3.6.1.4.1.311.20.2.3
Result: the authenticated user ID is t006472@mycompany.com .
5.2.3.2.2.4 Defining Rules for Filtering Client Certificates
Use
You can use configuration options for the ClientCertLoginModule to filter client certificates based on the certificate issuer and/or the certificate subject name.
You can use client certificate filters as building blocks to define rules for user ID authentication with client certificates.
You configure the use of filters in addition to configuring a mode to determine the user ID from the certificate information during logon.
Procedure
Using the SAP NetWeaver Administrator, go to the configuration options for the ClientCertLoginModule . For more information, see Managing Login Modules .
Filter Client Certificates by Certificate Subject Names
1. Enter the attributes of the certificate subject as a value of the option Rule <n> . FilterSubject of the ClientCertLoginModule . The order of the
values in the list does not matter. The comparison check for this rule is case-sensitive.
Note
You can use this option to specify comma-separated X.501 standard compliant values of type AttributeTypeAndValue . The
ClientCertLoginModule uses the configured values to filter provided certificates based on the certificate SubjectName field.
1. If the filtering rule specified with this configuration option finds a matching attribute in a provided certificate, then:
1. The filter succeeds.
2. The corresponding rule number is always used to determine the user ID.
3. Subsequent rules are not checked.
For example, if you configured a sequence of several rules to use for authentication, then the ClientCertLoginModule will use the first rule
in the sequence for which the filter succeeds.
2. If one of the specified values is missing from the certificate SubjectName field, then the authentication check for the corresponding rule is skipped. If
you configured other rules, then the check continues with the next ClientCertLoginModule rule number in the rule sequence you configured.
3. If the value of the rule field Rule <n> . FilterSubject is empty, the authentication check for this filter succeeds and the authentication check
continues with the configured options for the corresponding rule to determine the user ID.
2. Substitute <n> in the Rule <n> prefix of the ClientCertLoginModule configuration options to match the place of this rule in the sequence of configured
rules for client certificate authentication. If you use a single rule, then substitute the option prefix Rule <n> with the prefix Rule1 .
Example
For the configuration in the table below, the ClientCertLoginModule applies the configured filter for the certificate subject name and uses for
authentication only those certificates that contain attributes O= mycompany and OU= CA in their SubjectName field. If there are such certificates, then
the ClientCertLoginModule determines the user ID from the first attribute name of type rfc822Name in the filtered certificate V3 extension
SubjectAlternativeName .
Option Value
Rule1.filterSubject O=mycompany, OU=CA
Rule1.oid 2.5.29.17

Filter Client Certificates by Certificate Issuer

1. Enter the attributes of the certificate issuer as a value of the option FilterIssuer of the ClientCertLoginModule .
Note
The values entered must be of type X.501 Name and in comma-separated format. In addition, the value entered for this option must be an exact match
to the Issuer fields in the client certificates for the check in this filtering rule option to succeed.
1. If the filtering rule specified with this configuration option finds a matching attributes in a provided certificate, then:
1. The filter succeeds
2. The corresponding rule number is always used to determine the user ID.
3. Subsequent rules are not checked.
For example, if you configured a sequence of several rules to use for authentication, then the ClientCertLoginModule will use the first rule
in the sequence for which the filter succeeds.
2. If the configured values are different from the values in the certificate Issuer field, the check for the corresponding rule is skipped. If you configured
other rules, then the check continues with the next ClientCertLoginModule rule number in the rule sequence you configured.
3. If the value of the rule field FilterIssuer is empty, the authentication check for the corresponding rule is skipped and continues with the next
ClientCertLoginModule rule you configured.
2. Substitute <n> in the Rule <n> prefix of the ClientCertLoginModule configuration options to match the place of this rule in the sequence of configured
rules for client certificate authentication. If you use a single rule, then substitute the option prefix Rule <n> with the prefix Rule1 .
Example
For the configuration in the table below, the ClientCertLoginModule the applies the configured filter for certificate Issuer and uses for
authentication only certificates with an Issuer field that exactly matches CN= myCA, OU= mydept, OU= CA, O= mycompany, C= DE . If there
are such certificates, the ClientCertLoginModule determines the user ID from the attribute CN in the SubjectName field of the filtered certificate.
Option Value
Rule1.filterIssuer CN=myCA, OU= mydept, OU= CA, O= mycompany, C= DE
Rule1.getUserFrom SubjectName
Result
The AS Java can determine the user ID and filter client certificates based on the filtering rules that you configured.
5.2.3.2.2.5 Using Rules for User Mapping in Client Certificate

Login Module
Context
ClientCertLoginModule can use different rules to map users authenticated with their certificate to users that exist in the User Management Engine (UME), or to
virtual users. It can take different certificate attributes and map them to the specified user or account attribute. For example, it can map the RFC822 Name
certificate attribute, which usually contains the subject e-mail address, to the Email user attribute in the UME. For virtual users, you can also specify the default
roles of groups the virtual users will have on AS Java.
You define the rules for user mapping by creating sets of login module options.
The following table summarizes the login module options for user mapping.
Name Possible Values Description
Rule<n>.UserMappingMode (case insensitive values) Required for user mapping. Specifies the user mapping
mode. AS Java retrieves users using the value of the
specified property.
LogonID The mapping property is the logon ID. This is the default
value.
LogonAlias The mapping property is the logon alias. For users from
the ABAP data source, the logon alias may be different
from their logon ID. For AS Java users, the logon alias is
the same as the logon ID.
Email The mapping property is the user's e-mail address (as

defined in the corresponding user attribute).
UserAttribute The mapping property is a user attribute in the UME. It can

be a predefined property or a custom property. For custom
properties, you also need to specify
Rule<n>.UserMappingAttributeNamespace .
AccountAttribute The mapping property is an account attribute (realm,

principal, and so on).
VirtualUser The authenticated user is mapped to a virtual user. This

means that no such user exists in the UME database.
Instead, the user is temporarily created for the current
session.
Rule<n>.UserMappingAttribute <attribute name> If Rule<n>.UserMappingMode is set to

UserAttribute , this option specifies the name of the
user attribute for the mapping.
Rule<n>.UserMappingAttributeNamespace <attribute namespace> For custom user attributes, specifies the attribute
namespace in the UME.
Rule<n>.VirtualUserDefaultGroups <comma-separated list of groups (display names)> Optional. This property is used when the user mapping
mode is VirtualUser . In this case, AS Java creates a
virtual user (which exists only for the current user session)
for the user logged with a client certificate by this login
module. This property specifies the default groups
assigned to the virtual user when it is created.
Rule<n>.VirtualUserDefaultRoles <comma-separated list of roles (display names)> Optional. This property is used when the user mapping
mode is VirtualUser . In this case, AS Java creates a
virtual user (which exists only for the current user session)
for the user logged with a client certificate by this login
module. This property specifies the default roles assigned
to the virtual user when it is created.
Note
To create a complete rule for user mapping, you may need to combine these options with other login module options (see the examples below). For more
information about the other login module options, see:
Using Stored Certificate Mappings
Using Rules Based on Client Certificate Subject Names
Using Rules Based on Client Certificate V3 Extensions
Defining Rules for Filtering Client Certificates
Procedure
1. Using the SAP NetWeaver Administrator, go to the configuration options for the ClientCertLoginModule . For more information, see Managing Login Modules
.
2. Construct the required mapping rules by adding the corresponding sets of login module options (see the examples below).
3. Save the changes to the login module.
Results
After you have configured ClientCertLoginModule 's options for user mapping, when a user tries to log on, AS Java attempts to map the specified attribute from
the user's client certificate to the specified user or account attribute in the UME database. In other words, AS Java will recognize this user as the user whose
specific attribute has the same value as the specified certificate attribute.
Example
Example 1: User Mapping by E-Mail
Donna Moore is an employee at the MyCompany corporation. The corporation has issued her a certificate with the following data:
Subject
CN = d.moore
O = MyCompany
C = DE
Subject Alternative Name
RFC822 Name=donna.moore@mycompany.com
In AS Java's UME database, Donna's user account looks like this:
Logon ID dmoore
Last Name Moore
First Name Donna
E-mail Address donna.moore@mycompany.com
Obviously, the only certificate attribute that matches a user attribute in Donna's account is her e-mail address . The best choice for user mapping in Donna's
corporation is therefore to map the value of the RFC822 Name attribute, which contains the e-mail address, to the Email user attribute.
To do this, you need to define the following set of options to the ClientCertLoginModule :
Option Value
Rule5.getUserFrom expertmode
Rule5.OID 2.5.29.17

Rule5.UserMappingMode Email
Example 2: User Mapping for Virtual Users

XYZShop is a company that offers an e-shop for its customers. It also has a contract with MyCompany that MyCompany employees are allowed to order items
from that e-shop. MyCompany employees already exist in MyCompany's corporate database, and it is not necessary for XYZShop to have their accounts
duplicated in its system as well. When an employee from MyCompany wants to order items from XYZShop, he or she is authenticated on XYZShop with a
certificate issued by MyCompany. A virtual user is then created for the current user session. It has the rights to order as a shop visitor.
This user mapping can be done with the following set of ClientCertLoginModule :
Option Value
Rule1.UserMappingMode VirtualUser
Rule1.filterIssuer MyCompany
Rule1.VirtualUserDefaultRoles Purchaser
Rule1.VirtualUserDefaultGroups Shop_Visitors
5.2.3.2.3 Using Client Certificates via an Intermediary Server
Use
If users connect to the AS Java via an intermediary server that terminates the connection, for example, a Web proxy, then the user's SSL client certificate cannot
be directly used for authentication on the AS Java. In this case, the intermediary server passes the user's certificate to the AS Java in a header variable and the
AS Java accepts this certificate based on its trust relationship to the intermediary server.
Note
Although you have the option to use HTTP for the connection between the intermediary server and the AS Java, we recommend also using HTTPS for this
connection.
Prerequisites
To use HTTPS for the connection between the intermediary server and the AS Java the AS Java must be configured to support SSL.
To use SSL with mutual authentication between the intermediary server and the AS Java, the intermediary server possesses a public-key certificate to use
for SSL.
The intermediary server is configured to pass the user's client certificate to the AS Java.
You know the name of the header variable that contains the user's certificate.
Procedure
1. If you are using the Web dispatcher as the intermediary server, set the Web dispatcher profile parameter icm/HTTPS/forward_ccert_as_header =
true .
2. Set the following ICM profile parameters on the AS Java.
ICM Profile Parameters
Parameter Value Comment
icm/accept_forwarded_cert_via_http <true , false> Enter true if you want to accept HTTP without using SSL
for the connection between the intermediary server and the
AS Java. Default value is false .
icm/HTTPS/trust_client_with_subject <Distinguished Name of subject to trust> String containing the Distinguished Name for the trusted
proxy server(s).
icm/HTTPS/trust_client_with_issuer <Distinguished Name of issuer to trust> String containing the Distinguished Name of the certificate
issuer for the trusted proxy server(s).
1. Maintain the user's certificate information in his or her user account on the AS Java.
Result
The intermediary server passes the user's client certificate to the AS Java to use for authentication.
5.2.3.2.4 Enabling Certificate Revocation
Use
With the AS Java, you can use certificate revocation lists (CRLs) to make sure that a given certificate has not been revoked by the issuing Certificate Authority

(CA).
Certificate revocation is available for the following use cases:
User authentication using the Secure Sockets Layer (SSL) protocol and X.509 client certificates.
In this case, the check is integrated into the login module ClientCertLoginModule . If the user's certificate has been revoked, the user is denied
access to the server.
Outgoing connections to other servers that use HTTPS, if the HTTPS Connection Factory is used to establish the connection, for example, connections that
use the Destination service.
In this case, the check is performed by the HTTPS Connection Factory. If the target server's certificate has been revoked, the connection is not established.
To verify whether a certificate has been revoked, the AS Java uses the Certificate Revocation Check service. For each use case, the service maintains a
certificate revocation profile that contains the information needed to perform the check, for example, the name of the certificate issuer (CA) and its CRL distribution
point. For checking user certificates, the service uses the profile named ClientCertLoginModule , and for checking server certificates, it uses the profile
named SSLClientLib .
By default, the service is called for each of these use cases, however, the corresponding profiles are deactivated. Therefore, to check for revoked certificates, you
must activate the corresponding profile.
Note
For more information about how the Certificate Revocation Check service works, see How the Certificate Check Revocation Service Works .
Prerequisites
Each CRL is digitally signed by its CA. Therefore, to verify the digital signature provided with the CRL, the corresponding CA root certificate needs to be
imported into a keystore view on the AS Java. The default view to use is the TrustedCAs view.
The AS Java can connect to the each CRL distribution point used.
Note
By default the CRL distribution point specified in the certificate is used to locate the CRL. This location is determined by the issuing CA and is normally
located at the CA's site.
The distribution point may be located behind a proxy server, therefore, make sure the AS Java can connect to it.
As an alternative, you can download the CRL from the distribution point and save it to a local file. In this case, you must make sure you keep the local
file up-to-date.
Procedure
1. Start the Certificate Revocation Check Management application.
Note
You can find the Certificate Revocation Check Management in the SAP NetWeaver Administrator under SAP NetWeaver Administrator ->Configuration
Management ->Security->Certificates and Keys.
As an alternative, you can start the Certificate Revocation Check Management application directly using the URL:
http://<host>:<port>/webdynpro/dispatcher/sap.com/tc~sec~certrevc~ui/LocalServiceApp
1. Configure the Certificate Revocation Check service.

Under Configuration → Profiles:
1. Select Edit to change to edit mode.
2. Activate the profile for the use case where you want to check for certificate revocation.
3. Select the error behavior:
Continue means that processing continues if an error other than a revoked certificate occurs. This ensures smooth operations in case of errors
that are not related to the actual revocation check, for example, network errors when attempting to establish the connection to the CA's
distribution point.
Error means that processing discontinues if such an error occurs.
In either case, the check returns an error if the certificate has been revoked.
1. To edit attributes for individual certificate issuers that are contained in the profile, select the profile.
The certificate issuers contained in the profile are displayed in the lower section of the screen.
For each certificate issuer, you can:
Activate or deactivate the certificate issuer.
If you deactivate an entry, no revocation check is performed for certificates issued by this CA.
Specify an alternative distribution point.
Enter an alternative distribution point if you want to override the distribution point contained in the certificate being checked.
2. Save the data.
Example
The following shows an example of the Certificate Revocation Check configuration.
List of Profiles
Active Profile Name Error Behavior Issuers
Activate ClientCertLoginModule Error 1
Inactive SSLClientLib Continue 1

Certificate Issuers for the Selected Profile (ClientCertLoginModule)
Active Certificate Issuer Alternative Distribution Point
Active CN=ExampleCA, O=ExampleCompany, C=DE file:///C:/LocalCRLs/ExampleCA.crl
Result
Certificates used for the corresponding use case are checked when the SSL connection is established. If the certificate has been revoked by the issuing CA, an
error occurs.
Optional Tasks
In addition to activating the profiles, you can configure additional settings or perform optional tasks. See the following:
Modify additional settings
Check certificates manually
Remove or update CRL cache entries
5.2.3.2.4.1 How the Certificate Check Revocation Service Works

If a certificate that is presented to the AS Java contains a CRL distribution point for the issuing CA, the Certificate Revocation Check service checks the CRL from
this distirbution point to see whether the certificate has been revoked.
The first time that a CRL for a specific CA is checked, the Certificate Revocation Check service saves the default configuration in the corresponding profile,
depending on use case for which the certificate was presented. An entry is stored in the CA's profile for each CRL distribution point provided by the CA. If no
profile or corresponding entry exists for the CA's CRL being checked, it is automatically created.
The service also downloads the CA's CRL from the CRL distribution point and saves it in the CRL cache. For future checks, the service uses the CRL contained
in the cache. If the CRL in the cache is expired, the service downloads the newest version from the CA's CRL distribution point.
5.2.3.2.4.2 Modifying Additional Settings
Use
You can modify the settings for the following options:
Additonal Settings for the Certificate Revocation Check Service
Setting Default Description
Keystore for CRL signature TrustedCAs Specifies which keystore view contains the public-key
certificate used to verify the signature provided with the
CRLs.
You cannot specify different keystore views for different
CAs or different CRLs. All of the public-key certificates
used to verify the signatures used for the CRLs must be in
the same keystore view.
Keystore for SSL TrustedCAs Specifies which keystore view contains the server's SSL
certificate for the servers hosting the CRLs, for the case
that SSL is used for the connections to the distribution
points.
As with the keystore used for the CRL signatures, all of
the SSL server certificates used for the connections to the
distribution points must be in the same keystore view.
Auto Update Begin (Days) 2 Specifies the number of days prior to expiration that the
CRL will start to be automatically updated.
Auto Update Interval (Hours) 3 Specifies the interval used for updating the CRL in the
case of failure.
Procedure
In the Certificate Revocation Check service, under Configuration:
1. Select the Settings tab page.
2. Select Edit to change to edit mode.
3. Modify the settings as desired.
4. Save the data.

Use
You can also use the Certificate Revocation Check service to manually check individual certificates, for example, for certificates that exist outside the scope of the
applications provided.
Prerequisites
The certificate to check must either exist in the file system or in base64 format in the clipboard.
Procedure
In the Certificate Revocation Check service, under Check Certificate:
1. Select the profile to use for the check.
This specifies which configuration is used, for example, the location of the CRL used for the check.
If none of the profiles match the configuration necessary for the certificate you want to check, then create a new profile by selecting <New Profile> from
the drop-down list.
1. Enter a name for the profile in the New Profile field.
The Certificate Revocation Check service creates a profile using the default values. By default, the profile is inactive.
2. Activate this profile under Configuration → Profiles.
2. If you want to check the certificate for a specific date or time, then adjust the value accordingly in the Check Time field. Otherwise the current date and time
are used.
3. Select the location of the certificate in the Certificate Source field.
4. Upload the certificate from the file system or paste it into the text field, depending on the option you chose.
5. Choose Check.
The result of the check is displayed.
Note
Choose Change or Reset to check a different certificate. By selecting Change, you can select a different certificate using the same profile.
Note
To keep the Certificate Revocation Check service's configuration transparent, we recommend removing any profiles after checking individual certificates.
5.2.3.2.4.4 Removing or Updating CRL Cache Entries
Use
The first time the Certificate Revocation Check service checks a certificate, it downloads the corresponding CRL into the CRL cache for later use. The entry in the
CRL cache expires after a given time, as specified in the CRL attributes. If a check is performed, whereby the existing CRL cache entry is expired or about to
expire, the service updates the entry automatically.
To enforce an update of the CRL cache entry prior to expiration, or to clean up the cache by removing expired entries that are no longer needed, see the
procedure below.
Procedure
1. In the Certificate Revocation Check service, select the CRL Cache tab page.
2. Select the entry or entries to remove or update and choose Remove or Update, respectively.
Note
When you select an entry, the details about the entry appear in the lower section of the screen and you have to option to download the CRL to a local file
by selecting the link Download CRL . You can then view the CRL's attributes and its contents.
5.2.4 Using SAML Browser Artifacts
Use
You can use SAML for Single Sign-On in a scenario where a user is authenticated on an authentication system that acts as an SAML authority. Based on this
authentication, the user receives an SAML assertion (upon request) that he or she can use to access a resource on a different system without having to
authenticate again.
You can use SSO with SAML assertions with all usage types of SAP NetWeaver. In this case, the underlying AS Java or AS ABAP supports the configuration
and execution of the SSO and the SAP NetWeaver system acts as a SAML destination site. In addition, the portal can act as a SAML authority, or a SAML
source site, to issue SAML assertions.

Constraints
There are some limitations of the SAML implementation on the AS Java. The following constraints apply:
Versions 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 the
Conditions 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.
Prerequisites
To protect the data exchange, SSL is required for the connection between the source and destination sites. For more information, see Using SSL and SNC for
Transport Layer Security .
Note
SSL is required by the SAML specification, therefore its use is enforced by default in the SAML configuration. However, for testing purposes, you can disable
the enforcement of SSL for the SAML-based document exchanges. In this case, you receive warnings in the log files.
Integration
There are several components involved in the SAML Single Sign-On scenario:
The site that authenticates the user establishes a source site server that initiates the SAML communication. This source site provides the destination site
with an assertion artifact, which is an identifier for the user's assertions.
The source site also provides a responder, which acts as the SAML authority that actually provides the user's assertions when the destination site presents
the assertion artifact.
In addition to the desired resource, the destination site provides an artifact receiver, which is the entry point for resource requests carrying an artifact.
Note
The artifact receiver is a component defined by the SAML specification. However, in SAP NetWeaver, any resource can accept assertion artifacts in the
request URL.
If the user's ID as provided by the SAML authority is not identical to the user ID at the destination site, then the destination site must also provide a user
mapping mechanism.
The figure below shows in detail a server landscape with AS Java as a SAML destination site:
The figure also shows the process flow when the user accesses the AS Java applications using authentication with a SAML assertion.
1. The user authenticates against a SAML source site, for example, using user ID and password.
2. The user requests a resource at a destination site (via the source site), for example, the resource www.dest.com/resource.
3. The source site then contacts the destination site's artifact receiver. Thereby, it sends the target URL for the requested resource and an assertion artifact,
which identifies the user's assertions in the next steps.

4. The artifact receiver redirects the user client to the desired destination.
Note
The requested resource may also be the assertion receiver. In this case, the user is allowed access directly and no redirect is necessary. This is the
case for applications in SAP NetWeaver. See (3') in the graphic above.
5. The SAML login module, which is used by the resource at the destination site, evaluates the artifact, which includes determining the source site based on
the source ID information provided with the artifact.
6. The login module requests the user's authentication assertions from the source site's responder. This request occurs using the SOAP over HTTP binding of
the SAML protocol.
7. The source site's responder sends the user's assertions.
8. The login module analyzes the assertions and authenticates the user. If necessary, you can apply user mapping to obtain the user's correct ID for the AS
Java. See Step (8') in the figure.
9. The resource is sent to the user.
Features
SAP NetWeaver enables you to use SAML for SSO with both the AS ABAP and AS Java. You can configure the portal (which runs on an AS Java) to be a
SAML source site that issues SAML Browser Artifacts. These can then be used to access the AS ABAP, the AS Java or the portal as destination sites in the
SAML-enabled SSO environment.
For more information about the available configuration options, see SAML Parameters .
For the case where users have different user IDs in the different systems, you have to configure the use of user mapping. For a scenario where you use an AS
ABAP as a UME data source for the AS Java, you can use the user mapping features of the AS ABAP. For more information, see Mapping SAML Principals to
SAP NetWeaver User IDs .
For the case of AS Java standalone installations with local database user store, the source site must include the user name in the assertion.
Activities
Configuration
For more information about configuring the use of SAML on the AS ABAP and AS Java, see the following sections:
Configure AS Java as a SAML destination
Configure the use of SAML for SSO with the AS ABAP
Using SAP NetWeaver for a SAML source site
Access Applications that accept SAML Assertions
Use the SAML Test Application
Monitoring
For the AS Java, SAML authentication functions record log data to the category /System/Security/SAML . You can view the data using the AS Java log
viewer tools in the server's log system_security_log .
By default, the log file used is <instance_dir>\j2ee\cluster\server<n>\log\system\security.<x>.log .
In the AS ABAP, errors during the SAML protocol are reported in the system log (message numbers SM0 and SM1) as well as in the developer trace of the work
process.


User Authentication and Single Sign On PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Authentication and Single Sign On PDF

Uploaded by

Copyright:

Available Formats

User Authentication and Single Sign-On

PDF download from SAP Help Portal:

Created on May 21, 2015

PUBLIC Page 1 of 119

PUBLIC Page 2 of 119

PUBLIC Page 3 of 119

PUBLIC Page 4 of 119

2 SAP Single Sign-On

3.1 Authentication for SAP GUI

PUBLIC Page 6 of 119

3.1.1 User ID and Password Authentication for SAP GUI

3.1.2 Client Certificate Logon for SAP GUI

3.1.3 Kerberos for SAP GUI Authentication

PUBLIC Page 8 of 119

3.1.4 Windows NT LAN Manager (NTLM) Authentication

SNC with SAP Single Sign-On Secure Login

PUBLIC Page 9 of 119

3.2 Authentication for Web-Based Access

3.2.1 Basic Authentication (User ID and Password)

User ID and Password Authentication in SAP NetWeaver

PUBLIC Page 10 of 119

3.2.2 Logon Tickets

Authentication with Logon Tickets

PUBLIC Page 11 of 119

3.2.3 X.509 Client Certificates

PUBLIC Page 12 of 119

3.2.4 SAML 1.x

PUBLIC Page 13 of 119

3.2.5 SAML 2.0

PUBLIC Page 14 of 119

3.2.5.1 SSO with SAML 2.0

PUBLIC Page 15 of 119

1. A user attempts to access resource protected by SAML 2.0.

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

1. A user attempts to access resource protected by SAML 2.0.

3.2.5.2 SLO with SAML 2.0

Figure 1: Process Flow for SLO with SAML 2.0

1. The user initiates a logout request at a service provider.

3.2.5.3 Identity Federation

PUBLIC Page 17 of 119

E-mail The name ID is an e-mail address.

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

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

Figure 1: Account Linking with E-Mail Address

PUBLIC Page 18 of 119

Figure 2: Account Linking with Persistent Name ID

3.2.5.4 Common Domain and Identity Provider Discovery

Common Domain is a Different Domain

PUBLIC Page 20 of 119

3.2.7 Header Variables

Figure 1: Process Flow for Authentication with Header Variables

PUBLIC Page 21 of 119

3.2.8 OAuth 2.0 Introduction and Concept

3.2.8.1 OAuth 2.0 Server with AS ABAP

PUBLIC Page 22 of 119

3.2.8.2 OAuth 2.0 Scopes

3.2.8.5 Resource Owner in OAuth 2.0

PUBLIC Page 23 of 119

3.2.8.6 OAuth 2.0 Token Context Revocation

User User who issued the access token

Type Type of access token, for example, authorization code

Creation date Creation date of the access token