Skip to Content

Single sign-on Technologies supported by the SAP NetWeaver Application Server as a Service Provider in Microsoft based environments

It has been two years that I published this blog. Since a few things have changed meanwhile I thought that it’s time to provide an update. The main change is that SAP now offers SAP NetWeaver Single Sign-On as a solution for various SSO scenarios.

I wrote this blog because 2 years ago I had been asked by a colleague to provide some information for partners how they could achieve Single sign-on in a scenario where an ABAP system is accessed via Web-Dynpro and a .NET based Rich Client application that calls a web service in the ABAP backend. It turned out that though numerous publications have been published about this topic there seems still the need for a compact overview. Therefore I thought this would be a good topic for a blog. This statement still holds true 😉 .

I plan to add also some additional information how Single Sign-On can be achieved for SAP NetWeaver Gateway which is the product I am currently working for as a product manager.

If customers want to achieve Single sign-on to access the systems of their SAP System landscape they have different options. The options being available mainly depend on the underlying technology stack (ABAP or Java), the underlying NetWeaver release and the type of user agent (SAP NetWeaver Business Client, Browser, SAPGUI or Web Service Client) that is being used to access a SAP system. Let us first have a look which user agents can be used to consume services from a SAP NetWeaver Application Server:

User Agents

The ABAP server offers the still widely used legacy type access through the RFC protocol (SAPGUI) or diag protocol used by external applications that are performing RFC calls. Both the SAP ABAP stack as well as the SAP Java stack support browser based access (SAP NetWeaver Business Client, WebDynpro, iViews, BSP pages and SAPGUI for HTML) and web service based access that can be called by any web service client.Customers that are running their client computers in a Microsoft Active Directory are usually looking for an option to leverage this infrastructure. Since “Single sign-on (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems” (Wikipedia) the ideal Single sign-on scenario they are looking for is shown in the following figure.

The “ideal” Single sign-on scenario

The ideal SSO scenario

In this scenario a user logs on to his workstation using his Windows Domain credentials (1). During this process the user requests a Kerberos ticket that is issued by the Active Directory (AD) Domain Controller (DC) (2). This Kerberos ticket would then be used by any subsequent service call (3) and the user would be authenticated (4) by the SAP system without the need to enter username and password and would be able to retrieve the requested data (5).

In reality this scenario can usually not be used because the SAP NetWeaver Application server does support Kerberos for Single sign-on only for two scenarios. One is the browser based access to systems that are based on the Java stack that is configured to use the SPNego Login Module. The other is the use of a Kerberos based SNC solution for SAPGUI.

Since Kerberos tickets can thus not be used for authentication by all user agents, Single sign-on can only be achieved if we use an additional ticket issuing instance that itself accepts Kerberos tickets and that issues tokens that are accepted by the SAP NetWeaver Application Server instead. A “real”-World scenario would therefore look like this:

The “real-world” Single sign-on scenario

The real world SSO scenario

In this scenario a user logs on to his workstation using his Windows Domain credentials. During this process the user requests a Kerberos ticket that is issued by the Active Directory (AD) Domain Controller (DC) (1). This Kerberos ticket would then be used to perform an authenticated access to a ticket issuing system that issues other tokens (2) such as SAML tokens or SAP Logon Tickets. The user would then finally access the SAP System using this token without the need to enter username and password and would be able to retrieve the requested data (4).So what are the authentications options (tokens) that are supported by the SAP NetWeaver Web Application Server? Let us have a look at the authentication options that are listed in the following table:

SAP Stack

User Agent

X.509

Kerberos

SAP Logon Tickets

SAML 1.1

SAP NW AS ABAP

SAPGUI/RFC

Yes (1)

Yes(2)

Yes

No

Web Browser/ SAP NW BC

Yes

No(3a)

Yes

Yes(4)

.NET Web Service

Yes

No(3b)

Yes

Yes(5)

SAP NW AS Java

WebBrowser / SAP NW BC

Yes

Yes

Yes

Yes(6)

.NET Web Service

Yes

No(3b)

Yes

Yes(7)

  1. In this case one need to deploy SAP NetWeaver Single Sign-On or a 3rd party SNC product that is able to leverage the X.509 certificates from the user’s certificate store
  2. In this case the SAP NetWeaver Application Server ABAP has to run on Windows. See SAP Note 150380. If the SAP NetWeaver Application Server ABAP does not run on Windows one can achieve SSO by using SAP NetWeaver Single Sign-On.
  3. Though Kerberos Authentication is only supported for browser based access on the Java stack this technology can be leveraged indirectly to achieve Single sign-on as follows:
    (a) The authentication options offered by the Java stack can be leveraged for browser based access to a Web Application Server ABAP as well if users are redirected to a a Web Application Server Java in the event of a logon error. This scenario is described in the following SDN Whitepaper.
    (b)Kerberos tickets can only be used using a workaround described in the following Single Sign-On of Windows-based Web Service Clients using SAP Logon Tickets. A SAP Application Server based on the Java Stack has to be used as a ticket issuing instance
  4. SAML Browser / Artifact Profile as of NW 7.1 ABAP
  5. WS-Security SAML Token Profile (HoK) as of NW 7.01 SP1 and NW 7.11 SP1 ABAP
  6. SAML Browser / Artifact Profile as of NW 04 JAVA
  7. WS-Security SAML Token Profile (HoK) as of NW 7.11 SP1 JAVA

From the table above we can conclude that we have basically three options to achieve Single Sign-On.

The first option is to use SAP Logon Tickets. This works well for browser based access where a SAP NetWeaver Portal is used that is configured to support Integrated Windows Authentication. Such a portal can also act as the ticket issuing instance for SAP Logon Tickets for .NET Web Service Clients though this scenario does not work out of the box using standard WCF bindings since the .NET client has to perform an additional service call to the SAP Logon Ticket issuing system. This scenario is described Single Sign-On of Windows-based Web Service Clients using SAP Logon Tickets in SDN.

The second option is to use SAML tokens. SAML tokens can be used for Single-Sign-On in browser based scenarios as well as in Web Services based scenarios. If a user agent in a SAML based scenario tries to access a SAP resource it will automatically being told to access the SAML ticket issuing instance that can be configured to accept Kerberos tickets. Since the Identity Providers (IdP) and Secure Token Service (STS) servers of both vendors are not available yet this scenario will be adopted once these infrastructure components are available.

The third option is the usage of X.509 certificates. These can automatically be issued to end users and distributed to their computers with the help of Microsoft Active Directory. Using automatic enrollment of user certificates Microsoft Active Directory provides a quick and simple way to issue X.509 certificates to users after they have successfully authenticated against Microsoft Active Directory. This scenario has been described in the SAP TechEd session SIM208.

In addtion to my TechEd session I have provided more details in the following Single Sign-On for SAP NetWeaver Leveraging X.509 Certificate Auto Enrollment in Microsoft Active Directory. A solution that does not require the setup of a PKI infrastructure is the usage of SAP NetWeaver Single Sign-On . In this case the secure login server issues a client certificate and pushes it to the Windows Certificate Store. These certificates can also be shortlived and thus do not require the usage of a Certificate Revocation List.

A recommendation which technology one should choose in a specific scenario is out of the scope of this article. There are Pro’s and Con’s with all of them. Therefore I would like to point you to some articles that describe the topic in more depth. 

To report this post you need to login first.

52 Comments

You must be Logged on to comment or reply to a post.

        1. Community User
          I have several customers wanting Active Directory Federation Services v2 and Active Directory as their ‘Identity Provider’ working against SAP Netweaver 7.01 portals, how does one get these ‘Relying Party’ portals SAML v2 enabled without having to upgrade to 7.02 etc. In short: how does one make a Netweaver portal ‘claims aware’?
          (0) 
      1. Dimitar Mihaylov
        Hi Tobias,

        SAML 2.0 Service Provider support is or will be available in AS Java 7.2/7.3 and AS ABAP 7.02/7.3.

        SAML 2.0 Identity Provider functionality will be released as part of SAP IdM and will require at least AS Java 7.2 to run on it.

        Regards,

        Dimitar

        (0) 
    1. Wolfgang Janzen
      You need to differentiate between SAML 2.0 for web-applications (browser-based, NWAS as SAML 2.0 Service Provider) and SAML 2.0 Token (NWAS as WS Provider supporting WS-Security: SAML 2.0 Token Format). Regarding release coverage, you also need to specify whether you intend to use NWAS ABAP or NWAS Java.

      SAP NetWeaver Identity Management (IdM) plans to include an SAML 2.0 Identity Provider (IdP) with the next version (coming soon).

      (0) 
  1. Guillaume GARCIA
    Hi,
    Thanks for putting all this together. Although information is available on SDN about these many different aspects, it is nice to have such a blog as a reference! I’m glad you did it.  🙂
    Best regards,
    Guillaume
    (0) 
  2. Nelis Lamprecht
    Nice blog although your comment “2. In this case the SAP NetWeaver Application Server ABAP has to run on Windows.” for SAPgui and Kerberos is a bit misleading. SSO using Kerberos works just fine on Linux and Unix based ABAP systems too when authenticating to a Windows domain. Just thought I’d point that out 😉
    (0) 
    1. Andre Fischer Post author
      Hi Nelis,

      it is true that it can be configured.

      There is however the question whether it is supported.

      My statement refers to SAP Note 150380  “Is MIT Kerberos 5 supported for use with SNC ?”

      https://service.sap.com/sap/support/notes/150380

      Another solution is to use products that are certified for the BC-SNC interface. A list of certified products is available here:

      http://www.sap.com/ecosystem/customers/directories/SearchSolution.epx

      (0) 
  3. Gregor Wolf
    Hi André,

    thank you for this great overview. I especially liked the link to the SIM208 TechEd session. There you’ve mentioned that I can use Transaction EXTID_DN or the BSP Application /sap/bc/bsp/sap/certmap/ to assign the X.509 Distinguished Name to a User.

    At Siteco we do successfully use the Central User Administration to maintain all the users for  ERP, CRM, SCM and BW from one central place. Can it also be used to centrally maintain the mapping? Or do we have to introduce SAP Identity Management?

    Best regards
    Gregor

    (0) 
    1. Andre Fischer Post author
      Hi Gregor,

      Central User Administration cannot be used to distribute mapping information stored in USEREXTID.

      There is however the option to use a BADI implementation together with the report RSUSREXT.

      SAP Note 1254821

      BADI support is available for recent support package levels for 7.00, 7.01, 7.10 and 7.11 as specified in SAP Note 1254821.

      The recommended way as a long term solution would be to implement SAP IdM.

      Best Regards,
      Andre

      (0) 
  4. Gregor Wolf
    Hi André,

    I would love to see Kerberos Support for a Web Browser against an ABAP Stack. I think that this solution would be easier to deploy than X.509 certificates. Especially with the renaissance of the ABAP Stack for WebDynpro ABAP and the CRM WebUI which is based on BSP it would make a lot of sense. The way through the Java Stack to get a SSO Ticket is a poor workaround.

    Best regards
    Gregor

    (0) 
      1. Andre Fischer Post author
        There are currently no plans to support Kerberos authentication for browser based access for the ABAP stack.
        If one uses the autoenrollment capabilities for X.509 certificates that are provided by Microsoft Active Directory a X.509 certificate is automatically stored in the users certificate store after the user has successfully authenticated using Integrated Windows Authentication.
        From an end user point of view this is in the end Single sign-on based on Integrated Windows Authentication because the user does only have to authenticate once against AD and is then automatically authenticated (by the X.509 certificate) if he or she tries to access the ABAP System using browser based access.

        Best regards,
        André

        (0) 
        1. Tobias Hofmann
          Hi Andre,

          are your really thinking that it is more likely that a company will configure and maintain a PKI just for the Intranet so that a user can authenticate with the certificate logon stack on an ABAP server and not using the Kerberos ticket???
          X.509 certificates … no, this is not an SSO for the end user. Normally he’ll have to select the certificate in the browser when accessing a X.509 enabled authentication.
          And if it’s really bad configured (service market place from SAP: yes, there the certificate based authentication is really bad realised) the user will die trying to access the server.
          Please SAP, take a look at what your customers are using, and it’s not X.509 certificates, it’s AD and Kerberos. Please implement Kerberos SSO for the ABAP stack.
          Add some value to the customers: Kerberos for ABAP.

          br,
          Tobias

          (0) 
              1. Dimitar Mihaylov
                Hi Guillaume,
                The final implementation is available in ABAP 7.03 but cannot be released due to missing integration with other components – e.g. ICF, etc. Currently we are checking if we can release it as an add-on solution for already shipped releases – which might be more relevant for you. I’ll keep you updated on the progress -e.g. when we are ready and in case you would like to try the add-on solution.
                Regards,
                Dimitar
                (0) 
    1. Wolfgang Janzen
      NWAS ABAP will provide support for SAML 2.0 (as Service Provider) – as of 7.02. Using any SAML 2.0 IdP which is capable of supporting Kerberos authentication (e.g. MS ADFS 2.0) will allow you to achieve the intended goal: to use web-based ABAP applications using Kerberos authentication (via SAML 2.0 IdP). This does not require any Public Key Infrastructure (PKI) to be set-up.
      (0) 
  5. Raoul Shiro
    Hi André,
    Thank you very much for this eye opening presentation.

    We are trying to implement SUN OpenSSO (based on SAML 2.0) with the SAP Enterprise Portal 701.
    We are still in the configuration phase and are facing many issues.

    I searched for some documentations about SAML 2.0 and SAP portals in sdn/Sap notes etc .. but I couldn’t find any.

    Do you know if SAML 2.0 is supported on EP 701 ?
    Do you know if OpenSSO is widely used by others SAP customers ,

    thank you !

    (0) 
    1. Tobias Hofmann
      Hi,

      you should really rethink the idea of using OpenSSO. After Orace/SUN, the future of OpenSSO is a little bit unclear.
      And EP7 doesn’t support SAML 2.0. You’ll have to wait for NW 7.3

      br,
      Tobias

      (0) 
    2. Dimitar Mihaylov
      Hi Raoul,

      As correctly pointed by Tobias EP 7.01 does not natively support SAML 2.0. However you still could enable it by using another AS Java 7.2 system. There are two sub-cases:
      1. EP 7.01 should be an SAML 2.0 Service Provider (SP)
      In this case there is an SAML 2.0 Identity Provider (IdP) which issues the assertions and the EP 7.01/AS Java 7.2 system should be able to consume them and authenticate the user. This could be achieved in the following way: The AS Java 7.2 is configured as SAML 2.0 SP and consumes the SAML 2.0 assertion issued by the IdP, after authenticating the user it issues an SAP Logon Ticket and redirects to the EP 7.01 which is configured to accept Logon Tickets issued by the AS Java 7.2 system. This way the only change at the EP 7.01 is to establish the trust to the AS Java 7.2 system and thus the risk of any technical issues with your existing setup is minimal.
      2. EP 7.01 should be an SAML 2.0 Identity Provider (IdP)
      This is the case where you would like to integrate content from a third party system which does not accept the SAP Logon Ticket issued by the EP but supports SAML 2.0 authentication. In this case the flow is in reverse order – after authentication at EP an SAP Logon Ticket is issued, when the user clicks at an iView which points to the 3rd party system the browser will be redirected to this system and then to the AS Java 7.2 which will act as Identity Provider. The AS Java 7.2 system is configured to accept SAP Logon Tickets from EP and could transparently authenticate the user and issue a SAML 2.0 assertion for the 3rd party system.
      In both case the AS Java 7.2 system is used to convert the SSO tokens.

      SAML 2.0 SP is available by default in AS Java 7.2.
      SAML 2.0 IdP will be released in the next weeks and could be run on AS Java 7.2.
      If you are interested in other details do not hesitate to ask me.

      Regards,

      Dimitar

      (0) 
        1. Dimitar Mihaylov
          Hi Gary,

          Yes, what details are you interested in? Here is again the setup:
          [1] EP 7.01
          [2] CE 7.2 with SAML 2.0 Identity Provider (IdP)
          [3] 3rd party SAML 2.0 Service Provider

          Just some days ago SAP SAML 2.0 IdP was released as part of SAP IDM 7.1 SP5 (http://www.sdn.sap.com/irj/sdn/nw-identitymanagement).

          Trusts:
          [i]: [2] should accept SAP Logon Tickets (MYSAPSSO2 cookie) issued by [1]
          [ii]: [3] should accept SAML 2.0 assertions issued by [2]

          – At EP [1] you should configure URL iView to the 3rd party system [3].
          – [1] EP and [2] IdP should run in common DNS domain.
          – At [2] you should configure authentication with SAP Logon Tickets as one of the default ones

          The SSO (SAML 2.0 SP-initiated SSO)from [1] to [3] should work the following way:
          1. The user logs into the EP
          2. Domain cookie MYSAPSSO2 is set in the user browser
          3. The user navigates in the EP and loads the iView to the 3rd party system
          4. The browser access the 3rd party system (

          (0) 
          1. Gary A. Craig
            As far as system #2, I’m looking to see if SAP IDM is required or just an option.  It sounds like any NW 7.2 AS Java could work, correct?

            Thanks for the information.

            Gary

            (0) 
            1. Dimitar Mihaylov
              Hi Gary,

              The IDM solution consists of the following components:
              1. Identity Center (IC)
              2. Virtual Directory Server (VDS)
              3. SAML 2.0 Identity Provider (IdP)

              Each of them could be run separately from the others. This means that you can select to run IdP without IC or VDS. The only limitation is that you need IDM license even for the IdP.

              For the IdP you need to deploy only IDMFEDERATION.SCA on AS Java 7.2. It is available for download from SAP Service Marketplace and you should be able to get it. See also SAP Note 1471322.

              Regards,

              Dimitar

              (0) 
                1. Dimitar Mihaylov
                  You are welcome. Two additional comments:
                  [1] CE 7.2 – you just need “pure” AS Java installation, no BPM or other components. I think the correct usage type for installation is [AS Java] or something similar. Of course it will work if you select also other usage type but this will consume more system resources.
                  [2] IDM license – as far as I know the IDM license is free of charge in certain cases but I do not know the details. Nevertheless you should be able to download and test the IdP functionality even without such license. No activation key is required to enable the IdP functionality – just deploy the IDMFEDERATION.SCA.

                  Dimitar

                  (0) 
          2. Gary A. Craig

            Dimitar,<br/><br/>Just wanted to let you know your solution worked superbly!  I have implemented an IdP-initiated SSO with a third-party payroll provider.  <br/><br/>I do have a scenario for another vendor that I have not been able to solve and was hoping you can point me in the right direction.<br/><br/>I need a custom attribute with a constant value.  Like this.<br/><saml:Attribute Name=“clientId”><br/>    <saml:AttributeValue xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>19941</saml:AttributeValue><br/></saml:Attribute><br/><br/>This is not something I want to put in LDAP for every user.  Is there a solution to this?<br/><br/>Thank you,<br/>Gary

            (0) 
            1. Dimitar Mihaylov
              Hi Gary,

              Currently the SAP IDP could issue attributes only when transient or persistent NameID formats are used for the subject in the assertion. In those cases the source for the SAML2 attributes could be either user attributes or group or role assignments. Unfortunately at the moment we do not provide an option for setting attributes with a constant value however we have it on our list and in some of the next SPs this will be possible. As a temporary workaround I would propose to you the following: create either a group or a role with name “19941” and assign it either to the “Everyone” group or role. Afterwards add Authorization Attribute with name “clientId” and Filter based on the group or role “19941”. This is not the nicest solution but should resolve your issue until we provide support for constant attributes. Also I’m not sure about your scenario but I think it is more relevant if such constant attributes are set at the SP side and not at the IdP side because a malicious IdP could issue assertions with the same clientId which would be a security issue if accepted by the SP.

              Regards,

              Dimitar

              (0) 
              1. Gary A. Craig
                Dimitar,

                I tested creating the constant attribute as you described by creating a group with name 19941 and assigning to it the Everyone role.  When I test, the attribute is not created.  If I add the user explicitly to the group, then the attribute is created as needed.  Am I missing something on how to use “Everyone”.  I’m not wanting to create a group will all users as members.

                From the log using Everyone:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates false

                From the log with user as member:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates true


                19941

                Thanks for any help you can provide.
                Gary

                (0) 
              2. Gary A. Craig
                Dimitar,

                I tested your workaround and when using a group with member of Everyone the attribute is not created.  When I put my user in as a member then attribute is created.

                With Everyone debug log:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates false

                With user as member:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates true


                19941

                How can I get this to work without adding my users as members to the group and use Everyone.

                Thanks, Gary

                (0) 
              3. Gary A. Craig
                Dimitar,

                I tested your workaround and when using a group with member of Everyone the attribute is not created.  When I put my user in as a member then attribute is created.

                With Everyone debug log:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates false

                With user as member:
                Condition for descriptor Condition Descriptor {
                Type:GROUP,
                Negation State:false,
                Elements:[GRUP.PRIVATE_DATASOURCE.un:19941],
                Logical Operator:OR
                } evaluates true

                How can I get this to work without adding my users as members to the group and use Everyone.

                Thanks, Gary

                (0) 
                1. Dimitar Mihaylov
                  Hi,

                  I just want to update the forum in case others are following the topic. The issue was caused by a wrong configuration. The correct way to do it is to create a new group – e.g. “19941” and assign it as parent of built-in group “Everyone”. Because every user is a member of group “Everyone” he/she will became member also of its parent group “19941”.

                  Regards,

                  Dimitar

                  (0) 
  6. ShivKumar Devara
    Hi Andre,

    For ABAP stack with user agent SAP GUI/RFC you mentioned SAP logon tickets are supported.  But as per sap help link http://help.sap.com/saphelp_nw70ehp2/helpdata/en/e5/4344b6d24a05408ca4faa94554e851/frameset.htm, go to Authentication on the AS ABAP – Using logon tickets – prerequisite, it is mentioned that under step “End users need to configure their Web browsers to accept cookies”.  Could you please clarify on this.

    Thanks
    Shiva

    (0) 
    1. Andre Fischer Post author
      Hi Shiva,

      “End users need to configure their Web browsers to accept cookies” refers to browser based communication.
      For SAPGUI/RFC nothing has to be configured on the client side.

      Best Regards,
      Andre

      (0) 
      1. ShivKumar Devara
        Hi Andre,

        Thanks for your quick response.

        Actually I am under the impression that we can’t configure SSO for ABAP using logon tickets when accessing from SAP GUI/RFC, if it is possible, could you please let me know some info on how to configure it.

        Thanks
        Shiva

        (0) 
  7. James Lorenzana
    Hi Andre,
    Quick question. In our case it is a X.509 V3 issued by TrustAlert when they try to login via SECUDe to SAP Web GUI / SAPGUI. Since this is a standard X.509, can we reuse the same certificate when users login to a federated portal with (AS JAVA, EP, EPC)?
    Regards,
    James
    (0) 
    1. ShivKumar Devara
      I would like to add to Dimitar, NW ABAP is supported for SAML 2.0 for browser based application from 7.02 SP 03.  Logically speaking 7.2 is greater than 7.02, hence it should support.

      Apart from SSO, if you are looking data security than I suggest you to go for X.509 certificates which supports both.

      Regards
      Shiva

      (0) 
      1. Tobias Hofmann
        Shiva,
        “Logically speaking 7.2 is greater than 7.02, hence it should support.”

        That’s not how SAP product releases are working. Given that 7.2 was released earlier than 7.02, it may be without SAML, as SAML was only introduced in EHP2 of 7.00 and wasn’t part of the features of the 7.2 release.

        To have SAML support in 7.2 you may wait for an EHP for 7.2 that includes SAML.

        br,
        Tobias

        (0) 

Leave a Reply