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:
- The EPM Add-In which is the new office client.
- 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 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 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:
- The BASIS team installs an SSL certificate on the BW instances and enables the HTTPS protocol.
- The BASIS team then maps X.509 certificates to BW users (using STRUST, etc).
- The security or networking teams deploy user specific X.509 certificates to end users’ desktops.
- 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:
- A user can login to the EPM Add-In from the BPC web client without being prompted for credentials using a reentrance ticket.
- 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.
- 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 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.