Show TOC

 Using SAML Browser ArtifactsLocate this document in the navigation structure


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.


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.

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 .


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.


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.

    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
  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.

    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.

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.



For more information about configuring the use of SAML on the AS ABAP and AS Java, see the following sections:


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.