AWS for SAP
Securing SAP Fiori with Multi Factor Authentication
Introduction
Cloud Security is job zero at AWS. We have a Shared Responsibility Model with the customer; AWS manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the services operate. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. Customers should carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations. We provide a wide variety of best practices documents, encryption tools, and other guidance our customers can leverage to deliver application-level security measures.
With this blog, we will provide a how-to guide for SAP customers on AWS to implement multi-factor authentication (MFA) for SAP Fiori (the user interface of SAP S/4HANA system). When you implement MFA, it adds an extra layer of protection on top of your user name and password. When the users sign in to SAP Fiori, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their MFA device (the second factor—what they have). This will reduce security risks such as brute force attacks when the user credentials are compromised.
Due to the fact that many of SAP customers utilize Microsoft Active Directory, we will use AWS Managed Microsoft AD as our directory service in the solution architecture as well as AWS Single Sign-On (AWS SSO) to manage the MFA devices. We will describe the step-by-step implementation details as well
Solution Overview
The first diagram above describes the authentication flow which will happen when a user is accessing SAP Fiori from the browser utilizing SAML2 mechanism that will interact to AWS SSO and AWS Managed Microsoft AD.
As per the second diagram above, you will configure the AWS SSO to integrate with SAP Fiori using SAML2 mechanism, and it will refer to AWS Managed Microsoft AD as directory service for user authentication. The AD Management Server is used to administer the Active Directory from here using ADUC (Active Directory Users and Computers) tools. The application load balancer (ALB), along with SAP web dispatcher in public subnet, will act as reverse proxy to the embedded SAP Fiori in SAP S/4HANA servers in private subnet. This configuration will allow users to be able to access SAP Fiori through internet connection.
AWS SSO is a cloud service that allows you to grant your users access to AWS resources, such as SAP Fiori, across multiple AWS accounts. AWS Managed Microsoft AD enables you to use a managed Microsoft Active Directory on the AWS cloud. You create and maintain your users and groups in the AWS Managed Microsoft AD, as well as in SAP Fiori.
As alternative scenario, where you want to reuse objects such as users and groups from your existing AD domains for authentication, you can create an AD Trust relationship between an existing Active Directory domain and AWS Managed Microsoft AD. Another scenario in which you want to extend an existing Active Directory domain to AWS, by creating an Active Directory secondary domain controller(s) on Amazon EC2 instance(s), which would replace the use of AWS Managed Microsoft AD.
Prerequisite
- Implement configuration of AWS SSO and SAP Fiori as documented in the AWS for SAP blog by Patrick Leung or you can follow the AWS SSO wizard when defining the application as “SAP Fiori ABAP” as per this documentation.
- On top of the above, please enable the SAML2 configuration below using SICF transaction code in SAP Fiori.
- /sap/public/bc/icf/systemloginjs (SAP Note 2900689)
- /sap/bc/webdynpro/sap/saml2 (SAP Note 2323725)
- In order to improve the logon and logoff user experience, I would like to recommend the following changes:
-
- Apply SAP Note 2673366 (SAP S-User ID is required to access) in SAP Fiori. This will avoid the user to manually choose which Identity Provider to use when logging on.
- In SAP Fiori, you can set the Single Logout Endpoints as HTTP Redirect to https://<SSOStartPage>/start#/signout. This will allow users to automatically logoff from SAP Fiori without being redirected to AWS SSO Start page.
-
- You can deploy AWS Managed Microsoft AD by following the procedure described in this documentation.
- You need to make sure that the AD Management Server is in private subnet, and joined to AD created above, and having the relevant ADUC (Active Directory Users and Computers) Tools. You can follow this procedure to achieve this.
Solutions Implementation
- In AWS SSO, you can go to “Settings”, then you change identity source from AWS SSO to “AWS Managed Microsoft AD” that was deployed in the prerequisite step 4.
- Then you set the policy “If user does not have a registered MFA device” to “Require them to register an MFA device at sign in”. This will ensure that every user is MFA-enabled.
- In AWS SSO, under Applications, you can then assign a specific AD user group (example “Domain Users”) to the “SAP Fiori ABAP” application, so whenever you create a user and assign the user to this group, it is automatically granted access to the SAP Fiori.
Solution Testing
- In AWS Microsoft AD, you create and manage user and group via the Windows RDP, you can go to “Server Manager” and then go to “Active Directory Users and Computers”.
- You can browse to the domain corp -> users. Please take note of the user’s email.
- The email address is the attribute that we will use to map the users in SAP Fiori to the users in Active Directory. On top of this, the email address is to be reflected in user principal name (UPN) attribute as recommended by Microsoft as per this documentation. If this is not the case in your current AD, you should align them accordingly. Below is the screenshot of the AWS SSO configuration that drives this mapping. If for some reason you cannot use this mapping, you may review the alternative mapping by referring to the user attribute mapping documentation.
- In SAP Fiori, you create the user using SU01 transaction code with the same email address matching the AD user principal name (UPN) attribute value as per above. In productive deployment, you may want to replicate the SAP Fiori User IDs from Managed Microsoft AD automatically by setting up a scheduled job using LDAP* transaction codes.
- Then test by browsing to the SAP Fiori Launchpad with the following URL https://<sapfiori.example.com>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html. As per screenshot below, when a user try to access SAP Fiori Launchpad for the first time, the user will be prompted to register MFA device. In this example, the user select “authenticator app” (you can see the list of supported authenticator apps in this documentation). After the MFA registration is completed, the user will be redirected to the SAP Fiori Launchpad.
- Once all the activities are finished, you can logoff from SAP Fiori Launchpad, which will redirect you to the sign-in screen.
Managing Replacement or Lost MFA Device
When the MFA device is no longer valid, due to situations such as replacement or loss, you can delete the MFA device by navigating to AWS SSO -> Users, then select on the username -> MFA device, choose on the Device, and then select Delete.
Conclusion
We have discussed about step-by-step how to implement Multi Factor Authentication for SAP Fiori to improve your security posture. The use of AWS SSO simplifies the MFA registration by supporting multiple options such as authenticator app, security key and built-in authenticator.
AWS Managed Microsoft AD enables you to run Active Directory on AWS with ease, and if you wish to use your existing Active Directory domain for authentication purpose, it is also possible to either established AD Trust or Extend to AWS.
You can find out more about SAP on AWS, AWS SSO, AWS Managed Microsoft AD from the AWS product documentation.