SAP Enterprise Portal and SAP Fiori Common Architecture and Recommendations Authors: Aviad Rivlin, Thomas Csapo, Donka Dimitrova, Dimitar Mihaylov Reviewer: Andrew Silvey May 2015 | Version 1.1

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

TABLE OF CONTENT

1 EXECUTIVE SUMMARY ................................................................................................................... 3

2 WHAT IS SAP FIORI LAUNCHPAD – AN OVERVIEW ................................................................... 4

3 SAP ENTERPRISE PORTAL AND SAP FIORI INTEGRATION ...................................................... 5

4 ARCHITECTURE .............................................................................................................................. 7

4.1 Intranet scenario .............................................................................................................................. 7

4.2 Extranet scenario ............................................................................................................................. 8

5 RISK-BASED AUTHENTICATION & MOBILE SINGLE SIGN-ON ................................................ 10

6 ADDITIONAL REFERENCES ......................................................................................................... 12

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

1 EXECUTIVE SUMMARY

The SAP Enterprise Portal has been implemented by thousands of customers across regions and industries

in the past 10 (plus) years. Today, customer are looking to renew their SAP Portal and enable mobile

consumption of their portal (to increase the ROI of their investment). This renewal is achieved by aligning the

Portal User Experience with the Fiori User Experience.

The SAP Portal UX is aligning with the Fiori UX in two dimensions:

The SAP Fiori launchpad running on the SAP Enterprise Portal (as a new portal framework page)

Fiori applications serving as business content for the portal

A typical scenario for the SAP Enterprise Portal together with the Fiori apps is the consumption on mobile

devices, providing access to the system from inside and outside of the corporate network on multiple

devices. This scenario often raises security concerns about networking and data protection.

Below is a typical architecture outlining the key layers and protocols used to securely allow access to the

Portal and the Fiori apps from inside and outside the corporate network, while keeping the corporate

business date protected and un-vulnerable (as much as possible) from attacks coming from outside of the

corporate network.

Landscape Diagram 1: A common Portal/Fiori secured network

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

2 WHAT IS SAP FIORI LAUNCHPAD – AN OVERVIEW

SAP Fiori launchpad is a real-time, role based and personalized aggregation point for business functions and

applications deployable on multiple platforms – ABAP front end server, SAP Enterprise Portal and HANA

Cloud Platform, thus showcasing the SAP clients’ alignment. It runs on multiple devices and provides a

single point of access for business applications.

The Fiori launchpad is developed based on SAPUI5 and following the responsive design paradigm, providing

end users a coherent user experience across devices and consumption channels.

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

3 SAP ENTERPRISE PORTAL AND SAP FIORI INTEGRATION

Starting with SAP Enterprise Portal 7.4 SP8, the portal user experience is aligned with the Fiori user

experience in two main aspects:

New Fiori framework page – a new SAPUI5 responsive framework page is available in the portal

following the Fiori (launchpad) design. This new framework page is the recommended framework

page for mobile consumption of the portal (available as of SAP Enterprise Portal 7.4 SP7)

Consumption of Fiori and Fiori-like1 applications in the portal – Fiori applications2 serve as business

content for the portal (available as of SAP Enterprise Portal 7.4 SP8 together with UI Add-on SP9 on

the Front End Server)

The integration of the SAP Enterprise Portal and SAP Fiori apps is used very often for mobile scenarios and

hence raises many questions focusing on system landscape architecture, authentication and single sign-on.

In this document we will share best practices and recommendations in this area.

1 Fiori-like SAP Web IDE based applications deployed on-premise

2 Subset of the Fiori apps can run in stand-alone mode and be consumed in the portal

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

In this scenario, the SAP Enterprise Portal1 acts as the single point of access for business applications (Fiori

and non-Fiori) and content. The applications can be hosted on the ABAP Front End Server (Fiori

applications), on the Portal / JAVA sever, or on any other server in the landscape.

The Fiori framework page2 is hosted on the Portal server, aggregating Fiori applications3, together with

additional applications running on the different servers.

A reverse proxy is a mandatory component in this architecture because the Fiori launchpad is implementing

a security mechanism to prevent click-jacking4 attacks. The reverse proxy (or a similar component) role is to

hide or disguise the SAP systems hostnames and therefore assimilate the http calls from the portal server

and the ABAP Front End Server to have a matching host name and domain.

Key reasons to integrate the SAP Enterprise Portal with SAP Fiori

Provide end users a true single point of access, with a single URL, to all the end users daily business

applications (Fiori and non-Fiori) and content

Renew the portal user experience with attractive, responsive and multi-device applications while

keeping the established UI in place

Aligned look&feel of the portal and the business applications (including Fiori apps)

Strong authentication and Single Sign-On concepts provided by the portal and the NetWeaver

platform

Leverage existing investment in the SAP Enterprise Portal

Important notes:

Fiori applications are running on the ABAP Front End Serve. The apps are not running on the

NetWeaver JAVA server

Only a subset of the Fiori applications can be consumed in a stand-alone mode to the portal

1 Minimum version to consume Fiori applications in the SAP Portal: SAP Enterprise Portal 7.4 SP8 and UI Add-on SP9 2 Planned enhancement: consumption of the Fiori applications (and additional standards based applications) in a new standards based Ajax Framework page 3 Another option is to consume the ABAP based Fiori launchpad in the portal. No change in the architecture

and tools when implementing this scenario 4 Clickjacking - A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. Additional info at: http://en.wikipedia.org/wiki/Clickjacking

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

4 ARCHITECTURE

4.1 Intranet scenario

When accessing the SAP Portal and the Fiori applications from within the corporate network, the architecture

(see diagram #2) is relatively simple. None of the landscape components are exposed to the internet and no

special security measures should be applied to secure these servers from external attacks.

All servers are hosted in the same network. Firewalls are optional, but not required.

Reverse proxy is a mandatory component in the landscape to overcome the click-jacking protections

Protocols:

o Device to Portal: HTTPS

o ABAP Front End Server to Portal: HTTPS (recommended) / oData / RFC – depending on the

UI technology

o LDAP

User storage

o Users are typically stored in a central user repository (such as a central LDAP)

Landscape Diagram 2 – Internal SAP Enterprise Portal and Fiori applications landscape1

* HTTP connection is also an option

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

4.2 Extranet scenario

When accessing the SAP Portal and the Fiori applications from outside of the corporate network, special

security measures should be introduced to protect the systems from possible attacks.

We typically introduce 3 levels of network protection; each level is isolated from the outer one via a firewall.

Internet

Outer DMZ – first level networking protection where typically the Revere Proxy is hosted to direct (or

rejects) call from the internet to the internal systems

Inner DMZ – a secured area in the network, located behind two firewalls and typically hosting the user

interface (UI) components (portal, gateway, front end server, etc.)

Intranet – the most secured area in the network (behind three firewalls). In this network level, typically

the most protected software components are hosted (ERP systems, Business Warehouse, data-

bases, etc.)

Access between servers in the different layers is restricted for specific IPs / host-names to secure the access

between the different networking layers and severs.

Addition landscape details

Protocols:

o Device to Portal: HTTPS

o ABAP Front End Server to Portal: HTTPS (recommended) / oData / RFC – depending on the

UI technology

o LDAP

User storage

o Users are typically stored in a central user repository (such as a central LDAP)

o There are options to store the main LDAP in the intranet and provide an external branch for

the inner DMZ LDAP. There are several techniques to achieve this provided by the different

LDAP vendors1

Networking

o The firewall should secure each network layer by locking / approving ports, calls from

specific IPs and hosts, etc.

1 For example: Active Directory Lightweight Directory Services Overview

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

Landscape Diagram 3: A common Portal/Fiori external facing secured network1

Landscape Diagram 4: Another option for Portal/Fiori external facing secured network1

* HTTP connection is also an option for all connections below the Reverse Proxy

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

5 RISK-BASED AUTHENTICATION & MOBILE SINGLE SIGN-ON

Security is one of the most important topics when external access is enabled or mobile devices are used.

Multi-factor authentication helps addressing the risks by adding an additional layer of protection, but it also

brings usability issues. Companies can balance between security and usability thanks to risk-based

authentication and context-based authorizations available with the SAP Single Sign-On product.

Architecture of the customer implementation could be easily integrated by implementing the SAP Single

Sign-On components on the same server where the SAP Enterprise Portal is running. See the proposed

architecture in the Landscape Diagram 5 below.

Landscape Diagram 5: Advanced security for a common Portal/Fiori extranet scenario

SAP Single Sign-On offers the following advanced security features:

Two-factor authentication (2FA) using one-time password (OTP)

o Mobile Device - OTP passcodes are generated on the mobile device using SAP

Authenticator (a mobile application available for iOS and Android devices). The server side

of the 2FA solution is compatible with RFC 6238 and can accept passcodes generated by

other RFC 6238 compatible 3rd party generators available on the market.

o SMS – this is an alternative way to provide the OTP passcode to the end user, as an Out-Of-

band (OOB) token. The solution is important for scenarios that have to enforce 2FA for

corporate users who don’t use smartphones (for example users that does not have a

corporate mobile device, and the company does not allow a BYOD policy).

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

o E-mail – this is another channel for delivering the OTP to a user as an Out-Of-band (OOB)

token. This solution is valuable for protecting various internal scenarios with 2FA for users

who does not have smartphones, and the system cannot send an SMS to them due to a

missing mobile number in their user master record or simply due to unavailable SMS

services for the company.

Risk-based authentication - This solution is offered via access policies – simple or complex rules,

implemented in Java Script and executed by the server at the moment of authentication. Access

policies evaluate the risk based on the available context data, and the result could be that the access

is allowed, denied, or alternatively strong authentication (2FA) is enforced.

Typical examples for implementing risk-based authentication could be the following:

o Group/role assignment – enforcement of 2FA for users with supplementary authorizations

for a system, for example IT administrators, or users who have authorizations for managing

sensitive business data available via the system, for example HR employees, etc.

o (Geo) Location – enforcement of 2FA or even limiting the access when the user is trying to

authenticate from a (geo) location considered risky or suspicious (for example a country that

is different from the list of countries where the company operates).

o Date/time - enforcement of 2FA or limiting the access when the authentication happens in a

time slot that is considered risky – for example, a shift worker is trying to access the system

outside his shift hours, etc.

o Device type - enforcement of 2FA or limiting the access for a concrete device type (for

example mobile device)

Context-based authorizations - offers dynamic authorizations based on authentication context and

risk. This solution is valuable for scenarios, in which we want to protect some corporate resources

due to the risk discovered at the moment of authentication by limiting the access to them, and still to

allow the user to work with the system by using the other resources available for him/her and for

which the risk is not relevant. This solution is implemented combining access policies and specific

scopes defined on authorization role level.

Mobile Single Sign-On – available via the SAP Authenticator and based on two-factor authentication

using one-time password (OTP). This solution offers easy use via mobile devices and strong

protection of business data. For additional security the solution can be combined with the risk-based

authentication and context-based authorizations that moderate the risk for running important

business processes on mobile devices outside the corporate network.

SAP ENTERPRISE PORTAL AND SAP FIORI - COMMON ARCHITECTURE RECOMMENDATIONS

6 ADDITIONAL REFERENCES

SAP Fiori

Official documentation: http://help.sap.com/fiori

Browser / Devices / OS Information: SAP note 1935915

SAP Enterprise Portal

SAP Fiori launchpad on Portal:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/36/e069facded4977b277834c8914de79/frameset.ht

m

- SAP Fiori iView: http://help.sap.com/saphelp_nw73ehp1/helpdata/en/f6/e253dbf51742c0ade3e01feb96c6f7/frameset.htm

- Configuring SAP Web Dispatcher:

http://help.sap.com/saphelp_nw74/helpdata/en/6e/9c5877c825496184b53231cc687783/frameset.htm

- SAP note 2031108 - SAP Fiori Integration with SAP Enterprise Portal - Central note

- SAP note 2008931 - Known issues for Fiori Framework Page (FLP on Portal)

SAP Fiori Launchpad

- Official documentation:

http://help.sap.com/saphelp_uiaddon10/helpdata/en/f9/51b50a07ce41deb08ced62711fe8b5/content.htm?

frameset=/en/b5/2e74afea0c4aeb8b642b8e6ba8911f/frameset.htm

- Running Fiori app as a standalone application:

http://help.sap.com/saphelp_uiaddon10/helpdata/en/53/7758e0deb0477386ea400c915073b3/frameset.ht

m

Risk-based Authentication and Mobile Single-Sign On

Official documentation: http://help.sap.com/sso

Mobile Single Sign-On for SAP Fiori with SAP Authenticator

http://scn.sap.com/docs/DOC-59553 (Step-by-Step Guide Blog on SCN)

http://scn.sap.com/community/sso/blog/2014/11/03/mobile-single-sign-on-for-sap-fiori-with-sap-authenticator

- Risk-based authentication (Blog on SCN):

http://scn.sap.com/community/sso/blog/2014/11/03/risk-based-authentication-for-your-critical-business-

processes

- Two-factor authentication with OTP (Blog on SCN):

http://scn.sap.com/community/sso/blog/2014/05/12/stronger-authentication-with-one-time-password-solution

- Context-based authorizations:

SAP Note 2151025 - User Management Engine Support for Dynamic Authorizations

© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

www.sap.com