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