Start of Content Area

Function documentation Using SAML Assertions for Single Sign-On  Locate the document in its SAP Library structure


The SAP J2EE Engine supports the use of the Security Assertion Markup Language (SAML) for Single Sign-On. You can use SAML for Single Sign-On in a scenario where a user is authenticated on an external 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 the SAP J2EE Engine.


The SAP J2EE Engine accepts SAML assertions for Single Sign-On. However, it cannot act as an SAML authority that issues such assertions.


There are some limitations of the SAML implementation on the SAP J2EE Engine. The following constraints apply:

        Assertions must not contain the elements Condition and AudienceRestrictionCondition.

        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 or verifying digital signatures is not supported.


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.


Because SSL is required by the SAML specification, per default, its use is activated 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, but you can still process the communication requests.


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.

        In addition to the desired resource, the destination site provides an artifact receiver, which receives the initial assertion artifact and passes it on to be evaluated by the SAML login module.


The artifact receiver is a component defined by the SAML specification. However, because the SAP J2EE Engine uses a login module to evaluate the SAML assertions, any of its applications can be used as the artifact receiver.

        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 this server landscape in detail:

This graphic is explained in the accompanying text


The figure above also shows how this process occurs when the user accesses the destination site.


       1.      The user authenticates him or herself at the source site, for example, using user ID and password.

       2.      He or she requests a resource at the 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 will identify 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 on the SAP J2EE Engine. 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 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, a user mapping module can be applied after the login module to obtain the user’s correct ID for the SAP J2EE Engine. See Step (8’) in the figure.

       9.      The resource is sent to the user.


We do not provide a user mapping module with the SAP J2EE Engine. However, you can easily insert your own module in the login stack for the corresponding applications or templates. This mapping module can use any desired technology, for example, entries in a directory server, hard-coded mappings, or a mapping table in a database. For a sample mapping module, see the Example SAML Mapping Module Used by the SAML Test Application.

For more information about creating login module stacks, see Managing Authentication Modules.


The SAML authentication service writes log data to the category /System/Security/SAML. You can view the data using the LogView in the server’s log system_security_log.


When configuring the SAP J2EE Engine to support SAML, messages will appear in the log due to the incomplete configuration. However, such messages should not appear once you have finished the configuration.

Per default, the log file used is  <instance_dir>\j2ee\cluster\server<n>\log\system\security.log.<x>.



        Mapping SAML Principals to SAP J2EE Engine User IDs

        Configuring the Use of SAML

        Accessing an Application that Accepts SAML Assertions

        The SAML Test Application


End of Content Area