Monday, October 27, 2014

The SAP Mobile Integration playing field

SAP NetWeaver Gateway, SAP Mobile Platform, SAP API Management, Integration Gateway: the SAP Mobile Integration playing field includes multiple players. What are their roles, and can they play well together?

SAP Mobile Integration technologies and products

The role of SAP NetWeaver Gateway is exposing SAP ABAP-based Business Suites for consumption by alternative UI-channels, SAP and non-SAP. Including mobile apps, a.o. the SAP Fiori Apps.
SAP delivers also SAP Mobile Platform as a standard product. SMP 3.0 includes an internal component Integration Gateway. This is something different than NetWeaver Gateway, although it’s role is comparable: expose data and functionality for external consumption. Starting SMP 3.0 service pack 4, SAP positions SMP also as “Fiori-compatible”. Elements of this are SAP Fiori Client and Kapsel SDK within the SMP portfolio.
Early October, SAP in addition launched the new product SAP API Management. With this product, organization can manage and govern their service provisioning and usage by consuming organisations and Apps. Also this product thus has its rol in the mobile integration landscape.

How do these products play along?

SAP itself acknowledges that the pure existence of these 3 products, which seem to functionally overlap, likely will result in market confusion. To mitigate that effect, Joav Bally wrote an excellent article to clarify on higher level the difference in role positioning. Instead of repeating him, I simple refer to his post: Uniform Provisioning and Consumption of SAP (and non-SAP) Data. Another good information source is the post ‘There is a Gateway for that …’ by Mustafa Saglam.
Inspired by the insights I gained via these 2 blogs, I sketched a conceptual architecture diagram in which the 3 SAP integration products/technologies are positioned in the architecture layers.

Tuesday, September 2, 2014

HowTo diagnose root cause of Gateway authentication issues

Gateway supports multiple authentication methods to enable Single Sign-On: Basic Authentication, SAML 2.0, X.509 Certificates, SAP Logon Tickets, OAuth. Correct operation of SSO between a Gateway services consumer (e.g. SAP Fiori, SharePoint App, …) and Gateway requires that the consumer and the Gateway system have established an identity trust relationship. This typically (except for basic authentication, but I do not consider that as a viable enterprise-ready SSO option) requires configuration on consumer and Gateway side.
What to do in case the service consumer does not succeed in successfully sign-in on Gateway? How to find out what is the root cause, when you have configuration settings on both the consumer and on the Gateway side? Well, it appears that the NetWeaver stack provides a convenient diagnose tool for this:
https://<hostname>:<port>/sap/bc/webdynpro/sap/sec_diag_tool.
.
Make sure to activate this service in SICF, open the service in a browser, start a recording session, and repeat from consumer side the attempt to single sign-on. Next stop the recording, and inspect the trace file. In case of security related exception, you're likely to find useful information logged in that trace file.

Friday, August 15, 2014

Gateway protection against Cross-Site Request Forgery attacks

Gateway REST services open up the SAP landscape for consumption and operation from clients outside that trusted SAP landscape, including those evil browsers. Evil as we all know, the web cannot be trusted. A critical aspect in the Gateway architecture is therefore to mitigate the impact of web-based security attacks.

Cross-Site Request Forgery (CSRF)

One of the most exploited security vulnerabilities on the web is cross-site request forgery. The essence of a CSRF attack is that a malicious site misleads a trusting site in believing that a transactional request comes with approval of the user. The working of a CSRF attack is as follows: 1) after the user has set up an authenticated session with an application site, 2) the user while still within this authenticated browser session visits a malicious site, and 3) the malicious site tricks the user in sending requests to the application site that are actually constructed by the malicious site. Misleading the trusting site that the request comes with approval from the authenticated and authorized user, while in fact it originates from a malicious site. Hence the name cross-site request forgery.
The success of CSRF attacks depends on 3 factors:
  1. The ability to load malicious javascript code within the authenticated browser session.
  2. The ability to misuse the user authentication to the application site. In most browser/webapplications scenarios the user’s authentication state is maintained in cookies after successful authentication – required to preserve the authenticated state. If the malicious site can lure the user into sending a malicious request from the authenticated browser session, that request will automatically include all cookies including the authentication state. And thus be authorized to the trusting site without the user being aware nor approved the request.
  3. The predictability of the transaction request, so that the malicious site is able to automatically construct a request that will be serviced by the trusting site.
The first factor is common exploited by social engineering. The user is somehow seduced to load javascript code from the malicious site into the current browser session, without the user even be aware. Typical example is to send an email to user with hidden javascript code, and when the user opens it a request is send to malicious site. The protection against this risk are a combination of tooling – mail filters; and educating the users – do not just open any received mail. Although the quality of both security measures increases (yes, users are also more and more aware of the risks on the web), this protection is certainly yet not 100% foolproof.
Note that this factor is only present if the consumption of the webservices is via a browser. In case of a native application, and also in case of an embedded browser in native App (e.g. Fiori Client, Cordova), the user cannot visit others sites and have its client context become infected / compromised.
The second factor is inherent present in all browsers. Without it, each request send from browser would first need to go through the authentication protocol with the remote webapplication, involving browser redirects, identity stores. And in case of username/password browser logon, the user would have to reenter his/her credentials over and over again. Thus: preserving the authentication state after initial authentication is needed to avoid the processing and elapse time for the authentication protocol handling, and to prevent unhappy users. User-friendliness and security are often in contradiction.

Protection against CSRF attacks: CSRF Token

CSRF protection focusses on the 3rd factor: make sure the request cannot be (automically) predicted and thus constructed. Introduce CSRF Token protection.
The essence of CSRF Token protection is that the token is a secret key that is only known to the authenticated browser session and the trusting site, and that the authenticated browser session must include in each modifying request to the trusting site in order to convince the trusting site that the request is coming with consent from the user.
CSRF token protection is utilized on modern webapplication platforms, including SAP ICF, Microsoft IIS, …

CSRF protection applied in Gateway

SAP Gateway applies the following protocol to protect against CSRF:
  1. The user opens in browser a session with the Gateway based webapplication, and must first authenticate. This can be via any of the authentication methods: username/password, integrated Windows Authentication, X.509, SAML2, OAuth. After successful authentication, the browser has established an authenticated user-session with this trusting web application.
  2. The webapplication code loaded in the browser (HTML5, JavaScript) invokes HTTP GET requests to the Gateway REST services to retrieve data. The GET request can only be used to retrieve data, not to request a modifying transaction on a Gateway service.
  3. In case the client application wants to execute a transaction via Gateway REST service, it must invoke this via a POST, PUT or DELETE request. To ensure to the trusting Gateway REST service that the transaction request indeed originates from the user through the client application, the request must be signed with a CSRF-Token as secret key only known by the client application context and the Gateway webapplication.
  4. The CSRF-Token must be requested by the client application from the Gateway webservice. This can only be done via a non-modifying HTTP GET request. If the client application needs the CSRF Token for subsequent transactional request(s), it must include header variable X-CSRF-Token with value ‘FETCH’ in a non-modifying HTTP Get request send to the Gateway service. As all browsers enforce same-origin policy, the browser will only send HTTP GET requests issued from resource/code loaded in the browser that has the same origin/domain as the Gateway REST service. When code loaded via another (cross) site tries to send the HTTP GET request, the browser will refuse to send it.
  5. Gateway webservice only serves request to return X-CSRF-Token for non-modifying HTTP GET Request. It is not possible to retrieve the X-CSRF-Token via a modifying HTTP PUT/POST/DELETE action. Reason is that these requests are not subject to same-origin policy, and thus can be issued from code loaded from another domain (note: the essence of JSONP crossdomain handling).
  6. When Gateway receives a non-modifing GET Request with header variable ‘X-CSRF-Token’ equal to ‘FETCH’, it random generates a new token and returns the generated value to the requesting client in the response: via header variable and cookie. As result of same-origin browser policy, cookies can only be read by javascript code originating from the same domain. Malicious code loaded from another domain cannot read the cookie nor header variable. Also the random generated value cannot reasonable be guessed by the malicious code.
  7. The client application reads the CSRF Token from the HTTP GET Response, and includes the value as header parameter X-CSRF-Token in modifying HTTP requests to Gateway webservice. As the token value is also returned in GET ‘FETCH’ response via cookie, the value will also be included as cookie variable in each subsequent request from the client application in the current browser session.
  8. When Gateway receives a modifying request, SAP ICF runtime inspects the request on presence of X-CSRF-Token in both request header as in cookie. If present in both, it next compares the 2 values. Only if present and equal, the modifying request is guaranteed to come from the client application context, and is granted for execution by the Gateway REST service.

Proofing of Gateway CSRF protection

As stated above, a CSRF attack depends on the ability for malicious site to automatically construct a malicious request, that next the user is somehow lured into sending to the trusting site, and that is well-crafted to mislead the trusting site that the request is with the approval of the authenticated user.
The URL, including REST action is typically static; and could reasonable be ‘guessed’. And as same-origin only applies to HTTP GET request, it is also possible to send PUT/POST/DELETE requests that originate from the malicious site. But in order to have SAP ICF and thus Gateway trust and next execute such a transactional request, the request must be signed with the CSRF-Token as secret key in request header + cookie. The browser automatically includes all the cookies in the request. But the request header is not automatically reused/added by the browser, and the malicious code must therefore explicly set it in the XmlHttpRequest. However the CSRF Token value can only be retrieved and read by JavaScript code that originates from the same domain as the Gateway webservice. Not from JavaScript code that originates from another, external domain. Therefore the malicious code cannot reasonable construct a complete transaction request that includes the proper value of CSRF Token in both request header and client cookie. And Gateway is enabled to detect the malicious request as not being legitimate.

Monday, August 4, 2014

The 5 elemental Gateway Principles

Inspiration: OData and SAP NetWeaver Gateway, SAP Press
SAP developed NetWeaver Gateway as additional middleware technology with the prime goal to increase the reach of SAP Business Applications. The positioning is to enable the development of new types of user-friendly front-ends as new channels for consuming and operating SAP data and functions. Lightweight-consumption Apps.
Gateway provides an open, standards-based (REST, OData), and centralized services-interface [gateway] to the SAP business applications, aimed and optimized for service-consumption through interactive UI-applications. The architectural guiding input for Gateway comes from 2 different perspectives: UI (end-user) and infrastructure (reach, costs).
In the Gateway architecture 5 elemental principles are applied, to achieve openess of SAP business applications also to non-ABAP developers:
  1. Openness
    Gateway services must be open for consumption from any device and any technology platform
  2. Timelessness
    Gateway must support opening up of any SAP business suite version, for which it is reasonable to expect to still be in use by end-organizations
  3. Easy of consumption
    Any front-end developer must be able to utilize Gateway services to consume SAP data, no need for internal SAP knowledge
  4. User focus
    Gateway must support the development of modern, interactive UI-applications
  5. Division of work
    Gateway development must support work in parallel by backend developer for service provisioning, and front-end / Apps developer for the service consumption.
For a deeper understanding and appreciation of the Gateway architecture and it's guiding architecture, I highly recommend the SAP Press book "OData and SAP NetWeaver Gateway".

Thursday, July 31, 2014

Enumeration of Gateway licensing

Last a colleague asked me about the license model of Gateway usage. As this was not the first time I got such request, and a clear answer is hard to find online, I decided to base a blog on the answer I provided my colleague. So I at least myself have a source to refer to in future requests... Mind you that I do not guarantee the answer to be future proof, as SAP already once changed the Gateway license model.
In very short, Gateway licensing is as follows:
  1. Usage of Gateway to consume SAP data and functionality via Gateway Services (preferable REST, but SOAP although not SAP-recommended still supported), requires that the end-user has a Gateway User license.
  2. If end-user is already a SAP business suite user, this now also includes the right to consume SAP data and functionality through Gateway services. This has actually changed from the initial Gateway license model. In the beginning you were required to purchase the Gateway User license on top of already paid business suite usage. SAP later recognized this as double-charging it's customer-base, and corrected this.
  3. For new users, e.g. so-called casual users that have never 'seen' the SAP GUI and have no intention to ever use that, you need to purchase the Gateway User perpetual licence. Current list-price is 1,350 USD per user.
  4. In case the new user is using Gateway indirect in context of another SAP product, e.g. Duet Enterprise or SAP Mobile, SAP provides the Gateway User License for Productivity Apps (GULPA). This license is restricted to using Gateway as part of the Duet Enterprise runtime flow or SAP Mobile product. List-price of this is set at USD 375.00, to my knowledge divided in 250 USD for Gateway usage, and 130 USD for Duet Enterprise.
  5. In case of a volatile and continuous changing user-base with anonymous users, a typical example is that of webshop customers, SAP provides a transaction-based licence model: Gateway Consumer Access License. You purchase a 'bundle' of service calls that you are allowed to invoke and consume in a calendar year. Current stock price of a bundle of 75.000 service calls is USD 450.00.

Sunday, March 9, 2014

GWPAM Rapid Deployment Service on SAP-Microsoft Unite site

Earlier I reported about our involvement in the new SAP product for direct availability of SAP data into Microsoft Office clients: SAP NetWeaver Gateway Productivity Accelerator for Microsoft, short GWPAM.
Based on the knowledge and experience that we have gained early on in applying GWPAM, we have worked out a Rapid Deployment Service for GWPAM. This RDS solution is recognized by the SAP Gateway product team, and published on the SAP-Microsoft Unite Partner Connection site.
In the Rapid Deployment Service, we combine our proven approach for successful implementation of SAP-Microsoft integration scenarios with GWPAM product knowledge. Central concepts in our approach are user-centric focus, UI-design via (preferable) clickable prototypes, integration architecture, and technical expertise with the Microsoft and SAP application platforms. Check out in case you're interested in easily bring SAP data into Microsoft based front-ends.

Saturday, February 1, 2014

On close edge with SAP Gateway product development team

The SAP Fiori suite receives welcome confirmation from end-organisations. The concept of smaller productivity Apps for dedicated business scenarios, with a modern and user-friendly UI, is largely applauded in the SAP users market. The first wave started with 25 standard Apps targeting mainly at HCM and a bit of SRM, and SAP is continuously expanding on this suite to include more scenario's.
However, SAP alone cannot deliver Apps for all scenario's that may be relevant for individual organizations. The strategy is to augment the standard SAP Fiori suite with custom-build Apps. The end-users benefit as all the productivity Apps that a Fiori customer has installed (SAP standard + custom augmentations), have the same and familiar look&feel.
I've started on such a project to build a custom SAP Fiori-like App for Invoice Approvals, a step within the process running as a SAP workflow in the backend. The customer first consulted SAP to inquire whether such an App would be on the radar as standard Fiori App. Answer is no, and SAP's advice to customer was to hire us to build it custom for them.
The customer is (rightfully) very keen on security. One of their concerns is that the confidential invoice data may not remain behind on the device.
We do not use local data storage within the Invoice Approval App. But browsers could cache received data responses. To prevent that, I want to alter the response with 'No-Cache' directions:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
When I could not find explanation how-to include the 'No-Cache' directions in the response of a Gateway REST service, I decided to consult a direct contact within the Gateway development team: the notorious Andre Fischer :-) The response on my request for help is a perfect example of the close collaboration of the Gateway development team with partners [playing] in the field. Not only did I receive an useful response within half an hour (!!). It turned out that Andre also on-the-spot created a page on SCN to share my question + his answer to benefit the larger Gateway development audience: How to Avoid Caching of Confidential Data.