Skip to Content

Setup SAML 1.1-based Web SSO from NetWeaver CE to non-SAP systems

It has been years since NetWeaver Portal started to suppport SAML 1.1 Browser Artifact profile as a SAML Destination Site. Now SAP NetWeaver CE has taken this further: it can also act as a SAML 1.1 Source Site, so that the NetWeaver CE system can serve as a central Single Sign-On (SSO) gateway to various SAP and non-SAP backend systems.

SAP online documentation provides step-by-step guide on how to setup SAML 1.1-based Web-SSO between NetWeaver CE and remote WebDynpro applications; however when it comes to setting up SAML-based Web-SSO between NetWeaver CE and non-SAP systems, people can easily get lost. In this blog, I will go through the key steps to setup this scenario.

Let’s use a simple Web SSO scenario from SAP NetWeaver CE to a non-SAP SAML 1.1 Destination Site. Suppose the NetWeaver CE system’s URL is, and the non-SAP system’s URL is

*Note: this article assumes that you have basic understanding of SAML 1.1 Browser Artifact Profile. If you are not familiar with SAML 1.1 Browser Artifact based SSO, it is advisable to read the following online documentation first:

Using SAML Browser Artifacts


Now let’s get started. 

1. Preparing the NetWeaver CE system

First of all, let’s prepare the NetWeaver CE system as a SAML 1.1 Source Site. As most of the steps are already well documented, I would just like to outline the major steps below. The detailed description of the steps can be found at

  1. Change the Startup mode of the SAML service using Configtool, so that it always starts automatically together with system startup.
  2. Create a role and assign the UME action “SAML_RESPONDER” to the role.
  3. Create a user in the CE system and name it SAML_RESP. Assign the above-mentioned role to this user. For the ease of explanation, let’s name the user samlrespuser.

2. Configuring the non-SAP SAML Outbound Partner parameters

The next task is to configure the CE system with Outbound Partner parameters:

  1. Log on to the SAP NetWeaver Administrator (NWA) of the CE system, go to Configuration Management and choose Security -> Trusted Systems -> SAML Browser Artifact from Detailed Navigation.
  2. Choose the Outbound Partners tab to create a new outbound partner that represents the external non-SAP SAML 1.1 Destination Site , e.g., NonSAPPartner_0. Assign values for the Outbound Partner parameters as follows:

          1) Partner Key: NonSAPPartner_0

          2) Issuer Name:

           Here you can use any name to refer to the NetWeaver CE system (the SAML source site). However, it is a common best practice to use the URL of the SAML source site to uniquely identify itself.

          3) Source ID:

            Use the “Generate” button to generate a Source ID to technically represent the SAML source site in the SAML communication. The Source ID can use either Base64 or Hexedecimal format. If the external system accepts only Base64 format or Hexedecimal format, make sure you select the matching format. In our case, let’s assume the Source ID is DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 in Hexedecimal format.

          4) Validity Before Issue and Validity After Issue

           These parameters are used to accommodate time skew between the SAML Source Site and the SAML Destination Site. The default value for these parameters are 120 seconds and 180 seconds, respectively. If the external system (SAML Destination Site) has different settings for these parameters, try to match them.

          5) Assertion Version: SAML 1.1 or SAML 1.0

           The assertion version must match the supported SAML version on the external SAML Destination Site.

          6) URL Parameter for Artifact (default=SAMLart)

           Some non-SAP SAML Destination Site uses a custom URL parameter to transfer the SAML Browser Artifact. If that is the case, change the default parameter to match the URL parameter used by the SAML Destination Site.

          7) Artifact Receiver: Direct call to resource or Artifact Receiver URL

           *IMPORTANT*: For NetWeaver-based SAML Destination Sites, either of these two settings can be used. However for non-SAP SAML Destination sites, you have to select the option “Artifact Receiver URL” and provide the Receiver URL. An example of the SAML Artifact Receiver URL is:

          8) URL parameter for Target (default=TARGET)

           This parameter contains the actual URL that the end user is trying to access on the SAML Destination Site. Afte successful SAML authentication, the SAML Artifact Receiver component (on the SAML Destination Site) will redirect users to their originally requested URL contained in this parameter. If the SAML Destination Site uses a different parameter for this purpose, enter the name of the parameter here.

          9) Responder Access: Require fixed user

           As a security best practice, you should always use a fixed user ID for the SAML Destination Site to access the SAML Responder URL on the SAML Source Site. Enter samlrespuser here, which was created earlier.

After configuring the Outbound Partner, it should look like the following:



3. Configuring the non-SAP SAML Destination Site 

Now we have finished configuring the SAML Source Site. The next task is to configure the SAML Destination Site with the following parameters that should be taken from the last task:

          – Source ID

          – SAML Responder user name/password

In addition, you will also need the following information to configure the SAML Destination Site:

          – SAML Responder URL

          The SAML Reponder URL on NetWeaver CE is /saml/responder. Since the base URL of the NetWeaver CE SAML Source Site is, the SAML Responder URL is

          – Authentication Method for accessing SAML Responder

          Configure your SAML Destination Site to use BASIC authentication to access the SAML Responder.

It is a common best practice to enable HTTPS for the access to the SAML Responder because the user credentials of the samlrespuser user is transferred on the network. HTTP is used here for the purpose of simplicity, but in real world implementations, HTTPS access to the SAML Responder URL should be enforced.

Note: It is often the case that the end user has different user IDs in the SAML Source Site and the SAML Destination Site. If that is the case, a user mapping module needs to be configured on your SAML Destination Site to map the SAP user IDs to the user IDs of the non-SAP system. How to develop/configure such a user mapping module varies on different systems/vendors, and is beyond the scope of this article.

4. Creating an HTTP System object in the NetWeaver CE System

Now we have finished the underlying SAML configurations for the SAML Source/Destination sites. Let’s move on to create a portal iView on the NetWeaver CE system to take advantage of the SAML SSO capability.

1.  Create a blank HTTP System object in the portal

The first step is to create an HTTP system object in the CE portal. Log on to the CE sytem ( as a portal administrator, and navigate to System Administration -> System Configuration -> System Landscape. Create a blank HTTP system in a PCD folder:


Give the System object a name. In this example let’s call it NonSAP_HTTPSystem.


Then add an alias for the system. For convenience here let’s use NonSAP_HTTPSystem as the alias. 



2. Add SAML-specific properites to the HTTP System

This is one of the key points to make the entire scenario work. By default, the HTTP System object does not contain SAML-specific properties like SAP System objects. By adding the following two SAML-specific properties to the HTTP System, iViews based on the HTTP System object would be able to take advantage of SAML SSO:

     – samlpartnername

     – logonmethod

To do this, launch PCD Inspector in the CE portal:



Locate the HTTP System object that we just created in the PCD and click on PropEditor:



In the Property Editor, click on p* on the topright corner of the window to create a new property:



Enter the following values in the Property Editor:

    Property ID: logonmethod

    Property Value: SAML Browser/Artifact

    Property Type: STRING



Repeat the above step and add one more property:

    Property ID: samlpartnername

    Property Value: NonSAPPartner_0 (i.e. the Outbound Partner created in task 2)

    Property Type: STRING


Now we have finished creating the HTTP System object.

5. Creating an iView based on SAML 1.1 Browser Artifact SSO

Now we are at the last step. We need to create an iView to integrate the non-SAP system. The most important thing here is that we have to use the generic Application Integrator iView, not a regular URL iView.

1. Delta-link a generic SAP Application Integrator iView. The generic Application Integrator iView can be found at Portal Content -> Content Provided by SAP -> Admin Interfaces -> Admin iView Templates -> SAP Generic.

Change the iView’s name to a name you like. In our case, let’s name it iViewToExternal.



2. Set the System property of the iView to the HTTP System that we created in the last step, NonSAP_HTTPSystem.



3. Set the “URL Template” property of the iView to the non-SAP system’s URL. In our case,



Now we are done! Sit back and enjoy SAML 1.1 Web SSO between the NetWeaver CE system and the non-SAP system:).


6. Summary 

As a brief summary, I would like to reiterate the following key points that make the scenario possible:

1. Extend the HTTP System object with SAML-specific properties using PCD Inspector.

2. Always use SAP Generic Application Integrator iView to integrate the non-SAP systems. Do not use URL iViews.

3. Always specify an Artifact Receiver URL for the SAML Outbound Partner. Do not use “Direct call to URL”.


Thank you for your patience if you have read all the way here from the beginning. I would be happy to answer any questions you may have.

You must be Logged on to comment or reply to a post.
  • Hi Dong,

    The document is very good and articulated step by step. It’s really helpful and very easy to follow.

    I need one clarification on the same, as per my client requirement we need to configure a third party web based application in SAP Portal-Consumer (not in CE Portal)using SAML 2.0 & HTTP Post Binding with SSO.  In our case, the portal will the Source site and it will issue a SAML2.0 related ticket and send it to destination site,which is third party system using HTTP Post Binding.

    As per your article this is clearly talks about Artifactrelated configuration, however, if we want to do the same using HTTP POST Binding will it be possible thru configuration or does it require a development to achieve this.

    Hope Artifact Binding & HTTP Post Bindings both are two diffrent approaches.

    Last but not least, In the article-> section 2- item 9 – Responder Access: Require fixed user, do we need to create this user in LDAP / Portal DB? as our portal Data Source is LDAP. And the same user we need to maintain the same user in Portal & destination sites too?

    Plese clarify and kindly reply.


  • great work! Informative blog!

    Is this procedure same for SAML SSO set up between ECC portal and external(outside company intranet) non-SAP systems?