Skip to Content

BPC 10 for NetWeaver Authentication Scenarios


One of the major differences in BPC 10 for NetWeaver from previous releases is that all client to server traffic from the EPM Add-In (Office client) and Web client go through NetWeavers WAS (Web Application Server) as opposed to the .NET server.  Since the web server performs authentication services, this change brings new options and security considerations to the table.


Client Communication Overview

As I alluded to earlier, there are two primary ways users access BPC 10:

  1. The EPM Add-In which is the new office client.
  2. The BPC Web client which has been totally redesigned in this release.

Both clients access content in BPC by querying RESTFUL web services, which is similar to previous versions – just a different format.  Why am I going over all this?  The different clients each support different authentication mechanisms, in addition to the web services themselves.  The chart below provides an overview of what is supported where.  We will cover each scenario in more detail later on.



Basic Authentication

Basic authentication is used in the EPM Add-In by default and results in a prompt for your username and password during each login.

This authentication type is not secure unless using SSL as usernames and passwords are only Base64 encoded.  Due to this, SSL should always be used when using basic authentication.


HTML Form based Authentication

HTML form based authentication is used by default by the BPC web client and results in an HTML form that prompts you for your username and password.

Like basic authentication, form based authentication requires SSL (HTTPS) to be secure “across the wire”.   Due to this, SSL should always be used when using form based authentication.


Client Certificate

Client certificates are supported by both the EPM Add-In (for BPC 10 NetWeaver connections) and the BPC web client.  Users are not prompted for credentials when using client certificates, and as such it provides Single Sign On capabilities.  The configuration of client certificates is beyond the scope of this blog; however they basically work like this:

  1. The BASIS team installs an SSL certificate on the BW instances and enables the HTTPS protocol.
  2. The BASIS team then maps X.509 certificates to BW users (using STRUST, etc).
  3. The security or networking teams deploy user specific X.509 certificates to end users’ desktops.
  4. When a user executes a request, the client (either the EPM Add-In or web browser) verifies that it trusts the server certificate, and the server verifies that it trusts the client certificate allowing each side to validate each other’s identity before carrying out the request.

Client certificates must be installed in the end users’ desktop certificate store to be used with the BPC web client or EPM Add-In.  Additionally, you must enable client certificates for the EPM Add-In connection by checking the Client Certificate checkbox and selecting the appropriate certificate in the connection manager.

This authentication mechanism is convenient since it delivers SSO but comes along with more overhead then the other scenarios, since the X.509 certificates have to be maintained and deployed to end users systems.


SAP Logon Ticket

SAP Logon ticket’s allow users to obtain a ticket (which is stored in the form of a MYSAPSSO2 cookie) from one system and use it to authenticate to other trusted SAP systems.  SAP Logon tickets can also be used to generate reentrance tickets, which can be used by applications other than browsers (like the EPM Add-In) for authentication purposes without prompting users for credentials.

This makes a number of single sign on scenarios possible.  For example:

  1. A user can login to the EPM Add-In from the BPC web client without being prompted for credentials using a reentrance ticket.
  2. A user can logon to an SAP Portal instance, connect to the BPC web client (as a new page in Portal Content) and launch the EPM Add-In while only having to log in once – at the Portal.
  3. A user can logon to an SAP Portal instance and launch the EPM Add-In directly while only having to login to the portal.
    • Note – This doesn’t work out of the box, but I was able to create a relatively simple web application that can be deployed in an AS JAVA portal that enables this behavior.  It will be posted to SDN as an HTG soon.

Like the basic and html form authentication models, it is crucial that all communication occurs over HTTPS to ensure that the MYSAPSSO2 cookie is not compromised.  This scenario also requires that the BASIS team configure the required SAP systems to “trust” each other.


SAML 2.0

SAML 2.0 authentication is not used directly by any of the BPC clients at this time, but is supported by the BPC Web Services.  SAML 2.0 may be valuable for integration and custom development scenarios.



I have but one suggestion and if you’ve made it this far, you probably already know what it is.  Whatever authentication mechanism(s) you chose to deploy, ensure you enable and use SSL / HTTPS.  Your network security auditors will thank you.


Additional Resources

SBOP PC 10 for NetWeaver Security Guide

SAP NetWeaver 7.3 Security Guide > User Authentication and SSO

You must be Logged on to comment or reply to a post.
  • Hello Daniel,

    Thanks for the nice details on the SSO options for BPC 10.0 on NW 7.3. I would like to use the SAP Logon ticket and would appreciate if you can provide me some configuration documentation.

    • Hello Mohammad-

      By far the easiest way to use SAP Logon tickets is to have your portal link to the web client, then have users select the EPM Add in link from there.

      If you absolutely have to have a one click launch from EP into Excel, you can sit a small javascript page on the NW server that generates the COM Objects necessary to launch into excel and authenticate, but that is significantly more complex.

      Thank you

    • Hello Steven-

      This document is from 2011.  The one major difference is that SAML 2.0 is now supported.

      There is no appreciable logon difference for 10.0 versus 10.1, as the Add-In is the same.

      Yes, active directory SSO is supported via Kerberos tokens.  I strongly recommend that you validate that SSO is working for Internet Explorer first.  You can hit any of the BPC endpoints through your web browser.  Then, once you have validated that your SPNEGO configuration is working properly on your NW Server, you can attempt login through the EPM add in.  I recommend you have a packet sniffer such as Fiddler on hand to debug any issues you run into.



  • As documented in security guide, SMAL 2.0 is supported. And as far as I know, EPM Add-in client also uses web service to communicate with server. Not sure why you said SMAL 2.0 is not support with EPM Add-in client.

    • Hello Charlie-

      Daniel left SAP to found his own company in 2012.  My recommendation would be to create a new SCN post detailing that certain SAML (SAML 2.0 spec, not any of the off-spec javascript solutions) authentication scenarios are now supported.  Then ask a moderator to put a note on this page linking to your post.

      EDIT: I wanted to add a little context regarding what I meant by SAML 2.0 spec.  As part of the SAML2 process, there is a HTTP Code 302 browser redirect.  Many SAML solutions use a javascript redirect instead of this 302 redirect.  Since the EPM add in does not recognize javascript, it cannot handle this workaround. 

      Thank you


  • Hi Daniel,

    We have a requirement for setting up SSO between EPM add-on and ECC system at backend. Going through your blog, can you please help me with the link, how you achieved SSO with the logon ticket ?

    "Note – This doesn’t work out of the box, but I was able to create a relatively simple web application that can be deployed in an AS JAVA portal that enables this behavior.  It will be posted to SDN as an HTG soon."