Hello World! This is my first blog on SAP blogs, so why not start with a common basis procedure... Configuring single sign-on to SAP systems is one of the most common procedures a basis consultant performs and more so in the era of hybrid IT landscapes. In this blog, you will learn how to configure SAML based Single Sign-on for SAP Fiori / SAP NetWeaver using Azure Active Directory (Azure AD). I will also talk about advanced scenarios like the use of reverse proxies as well as troubleshooting on some common issues.
The scenario is SAML based Single Sign-on for SAP Fiori launchpad using Azure Active Directory. This is a Service Provider initiated single sign-on using front-channel communication and can be used for Fiori or NetWeaver web services.
You will most likely have an Azure AD tenant in your organization which will act as a SAML 2.0 Identity Provider, I am creating one here for demo.
By default, you will create a basic domain name at 'onmicrosoft.com'. You can add a domain name that your organization already uses, such as 'contoso.com'.
Go to Microsoft Azure Portal --> Active Directory --> Create a Tenant
Go to Users --> New User
Go to Enterprise applications --> New application.
Find SAP NetWeaver or SAP Fiori. It doesn't really matter which one you choose.
However, it is likely that you will have or will end up with multiple enterprise applications in your Azure AD tenant for the same category. Therefore, consider adding information such as environment (dev, prod, etc), SID, usage (Fiori), etc to the name of your new application. For instance, I named my application SAP NetWeaver Fiori - DEV.
Go to Enterprise applications --> application.
Click on the new application.
Then click Users and groups --> Add User.
Add the new user to your new application. I chose Default Access, but you can create and assign roles depending on your requirements.
Go to your application, then click Single sign-on and then SAML.
There are three key sub-steps here.
In this step, you assign Service Provider identity and URLs of your SAP NetWeaver system to your SAP Enterprise Application in Azure AD. I am performing all Azure AD configurations first before going into SAP configurations. However, it is also possible to perform the subsequent step "Create SAML 2 Local Provider" before this step.
Key points to note here are:
Click the edit icon next to Basic SAML Configuration.
The SAP application expects the SAML assertions to be in a specific format.
When a user authenticates to the application, Azure AD issues the application a SAML token with information (or claims) about the user that uniquely identifies the user. By default, this information includes the user's username, email address, first name, and last name. You might need to customize these claims if, for example, the application requires specific claim values or a Name format other than username.
During SAML single sign-on, by default, Azure AD will pass the user name or Name ID claim as <username>@yourdomain.onmicrosoft.com whereas the SAP User ID (user02.bname) will be <username>. There are several ways to map Azure AD claim to SAP user, the two main ones are:
I am choosing claim transformation. If you choose the second option, then you don't need to change anything in this step.
Click edit button for User Attributes & Claims.
Click on Claim Name Unique User Identifier (Name ID) and apply the Transformation ExtractMailPrefix() to user.userprincipalname. This transformation will do exactly as its name suggests.
Next you need to download the Certificate (Base64) and Federation Metadata XML. You will need these later when adding Azure AD as a trusted provider in SAP.
Now let's configure SAP NetWeaver for SAML. There are two main steps, create a Local Provider (Service Provider) and add Azure AD as a Trusted Identity Provider.
Launch SAML configuration by calling transaction code SAML2 from SAP or directly opening the following SAML URL in a browser and then click "Create SAML 2.0 Local Provider".
Next, choose Selection Mode Automatic, if you only have one single sign-on method.
The next step is to introduce Azure AD to your SAP system and register as a trusted identity provider. Keep the Certificate and Federation Metadata XML files from Azure AD configuration handy as you will need them in this step.
The easiest way is to choose Upload Metadata File. But I recommend using manual option at least once so you can become familiar with the configuration steps and various endpoints. It is also very easy and quick to delete the configuration and re-create before users start using SAML.
Go to Trusted Providers --> Add --> Upload Metadata File
Add Requested Authentication Contexts, if necessary, for your requirements.
Click Finish to save. There is still one change required so click Edit.
Make sure you are on Trusted Providers --> Identity Federation tab. Click Add to add a supported NameID format.
I want to remind you that I chose the Claim Transformation approach. Therefore, I will accept the default User ID Mapping Mode as Logon ID.
Finally click Save and Enable to activate your Trusted Provider configuration.
Now that we have configured both Azure AD and SAP, it is time for a quick test.
Remember to test using:
My Fiori launchpad URL via Azure Application Gateway and HTTPS is:
https://fioridemo.westeurope.cloudapp.azure.com/sap/bc/ui2/flp
Navigate to SAP web URL. If Trusted Provider is configured correctly, you should be redirected to Azure AD Sign In screen. Login with your Azure AD credentials.
Once authenticated, you will be redirected to and single signed-on into SAP Fiori.
You should now be able to configure SAML 2.0 SSO for your web applications based on SAP NetWeaver using Azure Active Directory as your Identity Provider.
If Azure AD authentication succeeds, but you still reach SAP logon screen, then use the Security Diagnostic Tool in SAP for troubleshooting.
Transaction code SICF --> Service /sap/bc/webdynpro/sap/SEC_DIAG_TOOL OR
http://<hostname>:<port>/sap/bc/webdynpro/sap/sec_diag_tool
A very common scenario is for organizations to use a reverse proxy such as Azure Application Gateway, SAP Web Dispatcher and Citrix Netscaler in front of the SAP application and terminate SSL at reverse proxy. This results in a protocol switch from HTTPS to HTTP on the final leg between the reverse proxy and SAP.
In this scenario, when SAP receives a response from Azure AD, the destination URL in the Response is an https. En route to SAP, due to a protocol switch on the reverse proxy, actual URL where the message is sent is an http. Therefore, SAML response validation by SAP, and hence single sign-on to SAP, will fail with following error:
To solve this issue, you need to convince your SAP system that it is okay to continue. To achieve this, you need to configure your reverse proxy to send a special HTTP header field called ClientProtocol with value https to SAP. This flag tells SAP that a protocol switch was done, and therefore SAP treats the connection as HTTPS, even though it is servicing the request using HTTP.
Here is an example of the solution using Azure Application Gateway as reverse proxy. In Application Gateway, I configured this by creating a Rewrite Set with following rewrite rule and associating it with appropriate routing rules.
https://wiki.scn.sap.com/wiki/display/BSP/Using+Proxies
2577263 - SAML2.0: How to disable SAML 2.0 authentication for a particular ICF service in AS ABAP
If only a few services will use SAML2.0 for authentication, it may be better to create a virtual host and enable SAML2.0 only to the services of this virtual host.
For further details, refer to Creating Virtual Hosts.
The following Guided Answers decision tree will assist you with configuration and troubleshooting of SAML 2.0 with AS ABAP.
SAML 2.0 SSO with AS ABAP - Guided Answers
Azure Active Directory Single Sign-On SAML protocol
Activating HTTP Security Session Management on AS ABAP
For more information on how your service provider communicates with identity providers, see the following:
Configuring Front-Channel Communication
Configuring Back-Channel Communication
YouTube:
SAP on Azure YouTube channel
Single Sign On for SAP NetWeaver and Azure Active Directory (by Holger Bruchelt)
Scenario
The scenario is SAML based Single Sign-on for SAP Fiori launchpad using Azure Active Directory. This is a Service Provider initiated single sign-on using front-channel communication and can be used for Fiori or NetWeaver web services.
- SP or Service Provider: SAP NetWeaver/ Fiori (NetWeaver 7.53)
- IdP or Identity Provider: Azure AD
- Service Provider initiated authentication
- SAML Mode: Front-channel communication - Front-channel communication is comparatively faster and does NOT need a direct connection between IdP and SP. Back-channel communication on the contrary, is slower as it needs more roundtrips to authenticate a user and needs a direct connection (firewalls) between IdP and SP.
- Azure Application Gateway as a Reverse Proxy: If you are using a reverse proxy in front of your SAP application, then refer to Special Scenarios and Troubleshooting section at the bottom.
Process Flow for Front-Channel SSO with SAML 2.0
Prerequisites
- You need an Azure AD Tenant that will act as SAML 2.0 identity provider and (someone with) appropriate permissions to make changes. In this blog, I will create one in my own Azure subscription.
- You have configured your SAP system to use HTTP security sessions. Adjust the parameters based on your organization requirements. For more information, see Activating HTTP Security Session Management on AS ABAP.
- Activate the following SICF services:
/sap/public/bc/sec/saml2
/sap/public/bc/sec/cdc_ext_service
/sap/bc/webdynpro/sap/saml2
- Optional: Activate the following SICF services to run the Security Diagnostic Tool and create traces for troubleshooting:
/sap/bc/webdynpro/sap/sec_diag_tool
/sap/public/bc
Procedure
Configure Azure AD
1. Create a tenant in Azure AD (If you don't have one)
You will most likely have an Azure AD tenant in your organization which will act as a SAML 2.0 Identity Provider, I am creating one here for demo.
By default, you will create a basic domain name at 'onmicrosoft.com'. You can add a domain name that your organization already uses, such as 'contoso.com'.
Go to Microsoft Azure Portal --> Active Directory --> Create a Tenant
2. "Switch Tenant" to the new directory
3. Create a new user in Azure AD
Go to Users --> New User
4. Add a new Enterprise Application from the gallery of type SAP NetWeaver or SAP Fiori
Go to Enterprise applications --> New application.
Find SAP NetWeaver or SAP Fiori. It doesn't really matter which one you choose.
However, it is likely that you will have or will end up with multiple enterprise applications in your Azure AD tenant for the same category. Therefore, consider adding information such as environment (dev, prod, etc), SID, usage (Fiori), etc to the name of your new application. For instance, I named my application SAP NetWeaver Fiori - DEV.
5. Assign your new user access to the newly created application
Go to Enterprise applications --> application.
Click on the new application.
Then click Users and groups --> Add User.
Add the new user to your new application. I chose Default Access, but you can create and assign roles depending on your requirements.
6. Set up Single Sign-on with SAML in Azure AD
Go to your application, then click Single sign-on and then SAML.
There are three key sub-steps here.
6.1 Basic SAML Configuration:
In this step, you assign Service Provider identity and URLs of your SAP NetWeaver system to your SAP Enterprise Application in Azure AD. I am performing all Azure AD configurations first before going into SAP configurations. However, it is also possible to perform the subsequent step "Create SAML 2 Local Provider" before this step.
Key points to note here are:
- The Identifier (Entity ID):
- The "Provider Name" in SAP SAML Local Provider (step 7) must be the same as this.
- It doesn't have to be in the form of a URL as the on-screen hint suggests.
- ACS (Assertion Consumer Service) URL:
- Remember that this must be an HTTPS URL. HTTP isn’t allowed.
- Ensure that you use the correct SAP client number. I am using client 000, but in a real-life scenario, you will have a different client number.
- If you have a reverse proxy in front of your SAP application, then use the URL of reverse proxy.
- We are configuring this step manually. The other way is to first create local provider in SAP, download SAP Metadata File and then come here and upload the file. If you are importing Metadata File from SAP and if you are using a reverse proxy, then remember to access SAML 2.0 configuration UI via the reverse proxy URL. This will ensure that service provider metadata will contain the correct endpoint URLs.
Click the edit icon next to Basic SAML Configuration.
6.2 User Attributes & Claims
The SAP application expects the SAML assertions to be in a specific format.
When a user authenticates to the application, Azure AD issues the application a SAML token with information (or claims) about the user that uniquely identifies the user. By default, this information includes the user's username, email address, first name, and last name. You might need to customize these claims if, for example, the application requires specific claim values or a Name format other than username.
During SAML single sign-on, by default, Azure AD will pass the user name or Name ID claim as <username>@yourdomain.onmicrosoft.com whereas the SAP User ID (user02.bname) will be <username>. There are several ways to map Azure AD claim to SAP user, the two main ones are:
- One way is to use Claim Transformation in Azure AD as below.
- Another way is to use the default (untransformed) Name ID claim (user.userprincipalname) and leverage Alias in SAP user account, in this case you will store <username>@yourdomain.onmicrosoft.com in alias field of the user.
I am choosing claim transformation. If you choose the second option, then you don't need to change anything in this step.
Click edit button for User Attributes & Claims.
Click on Claim Name Unique User Identifier (Name ID) and apply the Transformation ExtractMailPrefix() to user.userprincipalname. This transformation will do exactly as its name suggests.
6.3 Download Certificate (Base64) and Federation Metadata XML
Next you need to download the Certificate (Base64) and Federation Metadata XML. You will need these later when adding Azure AD as a trusted provider in SAP.
Configure SAP NetWeaver for Single Sign-on using SAML
Now let's configure SAP NetWeaver for SAML. There are two main steps, create a Local Provider (Service Provider) and add Azure AD as a Trusted Identity Provider.
7. Create SAML 2.0 Local Provider
Launch SAML configuration by calling transaction code SAML2 from SAP or directly opening the following SAML URL in a browser and then click "Create SAML 2.0 Local Provider".
Next, choose Selection Mode Automatic, if you only have one single sign-on method.
8. Add Azure AD as a Trusted Provider
The next step is to introduce Azure AD to your SAP system and register as a trusted identity provider. Keep the Certificate and Federation Metadata XML files from Azure AD configuration handy as you will need them in this step.
The easiest way is to choose Upload Metadata File. But I recommend using manual option at least once so you can become familiar with the configuration steps and various endpoints. It is also very easy and quick to delete the configuration and re-create before users start using SAML.
Go to Trusted Providers --> Add --> Upload Metadata File
Add Requested Authentication Contexts, if necessary, for your requirements.
Click Finish to save. There is still one change required so click Edit.
Make sure you are on Trusted Providers --> Identity Federation tab. Click Add to add a supported NameID format.
I want to remind you that I chose the Claim Transformation approach. Therefore, I will accept the default User ID Mapping Mode as Logon ID.
Conditional: If you are not using Claim Transformation in Azure AD, and want to leverage Alias in SAP user account for Azure AD to SAP user mapping (instead of claim transformations in Azure AD), then add E-mail as a supported NameID Format and change User ID Mapping Mode to Logon Alias.
In this case, remember to add the alias in SU01.
Finally click Save and Enable to activate your Trusted Provider configuration.
Test
Now that we have configured both Azure AD and SAP, it is time for a quick test.
Remember to test using:
- InPrivate (Edge) or incognito (Chrome) browser window to avoid false test results.
(alternatively, clear your browsing cache, close the window, and open a new one)
- the SAP URL that your end users will use to access your SAP application
My Fiori launchpad URL via Azure Application Gateway and HTTPS is:
https://fioridemo.westeurope.cloudapp.azure.com/sap/bc/ui2/flp
Navigate to SAP web URL. If Trusted Provider is configured correctly, you should be redirected to Azure AD Sign In screen. Login with your Azure AD credentials.
Once authenticated, you will be redirected to and single signed-on into SAP Fiori.
Conclusion
You should now be able to configure SAML 2.0 SSO for your web applications based on SAP NetWeaver using Azure Active Directory as your Identity Provider.
Special scenarios and troubleshooting
Security Diagnostic Tool
If Azure AD authentication succeeds, but you still reach SAP logon screen, then use the Security Diagnostic Tool in SAP for troubleshooting.
Transaction code SICF --> Service /sap/bc/webdynpro/sap/SEC_DIAG_TOOL OR
http://<hostname>:<port>/sap/bc/webdynpro/sap/sec_diag_tool
Handling protocol switch from HTTPS to HTTP when using a reverse proxy
A very common scenario is for organizations to use a reverse proxy such as Azure Application Gateway, SAP Web Dispatcher and Citrix Netscaler in front of the SAP application and terminate SSL at reverse proxy. This results in a protocol switch from HTTPS to HTTP on the final leg between the reverse proxy and SAP.
In this scenario, when SAP receives a response from Azure AD, the destination URL in the Response is an https. En route to SAP, due to a protocol switch on the reverse proxy, actual URL where the message is sent is an http. Therefore, SAML response validation by SAP, and hence single sign-on to SAP, will fail with following error:
SAML20 CX_SAML20_CORE: Message 'Response' did not arrive at the correct destination.To solve this issue, you need to convince your SAP system that it is okay to continue. To achieve this, you need to configure your reverse proxy to send a special HTTP header field called ClientProtocol with value https to SAP. This flag tells SAP that a protocol switch was done, and therefore SAP treats the connection as HTTPS, even though it is servicing the request using HTTP.
Here is an example of the solution using Azure Application Gateway as reverse proxy. In Application Gateway, I configured this by creating a Rewrite Set with following rewrite rule and associating it with appropriate routing rules.
https://wiki.scn.sap.com/wiki/display/BSP/Using+Proxies
Disable SAML 2.0 authentication
2577263 - SAML2.0: How to disable SAML 2.0 authentication for a particular ICF service in AS ABAP
- Temporarily, e.g. for a specific logon test:
Append "?saml2=disabled" or "&saml2=disabled"
- Temporarily, e.g. for all services in an SAP system:
In AS ABAP, run transaction code SAML2 and navigate to Trusted Providers, choose the relevant IdP, in this case your Azure AD Tenant, and click Disable. Disable and Enable is easy and doesn't need any service restart.
- Permanently, e.g. for a specific ICF service in an SAP system:
Remove the SAML Logon Procedure from the Logon Procedure List of the ICF service. For the details, please check KBA 2573379.
If only a few services will use SAML2.0 for authentication, it may be better to create a virtual host and enable SAML2.0 only to the services of this virtual host.
For further details, refer to Creating Virtual Hosts.
Any other errors
The following Guided Answers decision tree will assist you with configuration and troubleshooting of SAML 2.0 with AS ABAP.
SAML 2.0 SSO with AS ABAP - Guided Answers
Additional References
Azure Active Directory Single Sign-On SAML protocol
Activating HTTP Security Session Management on AS ABAP
For more information on how your service provider communicates with identity providers, see the following:
Configuring Front-Channel Communication
Configuring Back-Channel Communication
YouTube:
SAP on Azure YouTube channel
Single Sign On for SAP NetWeaver and Azure Active Directory (by Holger Bruchelt)
- SAP Managed Tags:
2 Comments
