Single Sign-On with Azure AD and SAP
Many of our customers are using Microsoft Azure for different purposes now, and there’s a common requirement for Single Sign-On (SSO) from Azure AD to their on-premises SAP systems. People would like to use the Microsoft account they use for Office 365 and other Azure technologies to log into SAP.
A user attempts to access an SAP web resource, such as Fiori Launchpad, Neptune or even an older solution like NWBC or Enterprise Portal. Instead of getting an SAP logon screen, they will get a Microsoft logon screen similar to logging into Office 365.
If they are already logged in to their Microsoft account, the SSO is silent and they are signed in to SAP immediately.
Users can also launch SAP applications from My Apps and from the apps launcher on the top left of all Office 365 applications, allowing a seamless user experience with no further authentication.
How to do it
Azure AD uses SAML2.0 to pass the authentication to SAP. You require an Azure Active Directory Premium license to integrate the SAP application in this way.
Azure AD will act as a SAML2.0 identity provider (IdP), and SAP will act as a service provider (SP). SAP will trust assertions that are passed to it via HTTP redirects from the identity provider, after the user has authenticated to the identity provider.
Often two people work together to configure this, an Azure AD administrator and an SAP administrator, although one person can easily complete the task if they have access to both Azure AD configuration in the Azure Portal and administrative access to the SAP system.
The Azure AD Administrator starts by adding the SAP web application as an Enterprise Application in the Azure Portal.
On the SAP side, you use transaction SAML2. I recommend you export the metadata XML file from transaction SAML2 and pass this to the Azure AD administrator to import, as that approach is far more reliable and straightforward than entering the data by hand. The Azure AD Administrator can send a similar metadata XML back for import to the SAP side.
You can expect to get the technical configuration of SAML2.0 working for a single SAP system in a few hours or less, although beware of more time consuming activities such as ensuring users are mapped between Azure AD and SAP, and of course testing and change management.
Multiple Azure ADs for a single SAP system
A requirement I’ve worked on recently is for a railway operator, who have multiple Azure ADs as they operate several different rail franchises through different train operating companies (TOCs). The UK rail industry’s franchise model often brings a unique challenge to SAP projects, including SSO.
SAP fully supports multiple Identity Providers, and can provide a drop-down list for the user to select from when they log in. The problem with this is that the mapping between Azure AD and an employee’s place of work may not be simple, and it may not be common knowledge amongst end users which Azure AD domain they should select.
IdP-initiated SSO with My Apps tiles is a good solution. The users log in to My Apps directly, or to Office 365 and any other Microsoft products using their ordinary account, then they can link from there to SAP using IdP-initiated SSO. They will always arrive at SAP with an assertion from the correct Azure AD because that is where they started.
Of course, you can also take organisational steps to share the correct URLs to the correct users, or integrate it into other areas such as company bookmarks or an intranet, if you don’t want to use the tiles.
What about SAP GUI?
Many organisations are still using SAP GUI, and in some SAP support functions it is still essential. SSO solutions for SAP GUI have an additional license requirement, either from SAP themselves or from a third party vendor.
One option to achieve SSO to SAP GUI without additional license is to launch SAP from an SAP Enterprise Portal, with SSO configured to the portal. At Absoft we have extended this idea further, so we have Neptune and Fiori applications that can launch SAP GUI on the end user’s computer with SSO, either directly from a My Apps tile in Azure or from the Launchpad.
Logging out is always a controversial topic in an SSO project, as the SSO will often mean the user log straight back in after they have logged out! In some cases, users will actually be able to log out of Azure AD, or select from multiple Azure AD accounts, so it’s slightly different from the old world of SSO to Active Directory on-premises and logging out is a valid requirement that needs careful thought.
There are a few options with Azure AD. One option is to leave the SAP functionality default, so pressing ‘Log out’ removes their session in SAP as they would expect. If they visit the SAP application again, they will be signed back in – often silently as they are still signed into Azure AD. You need to make sure SAP is not configured to redirect back to the log in page after log out, as the user will be logged straight back in via SSO and log out will effectively be broken.
Another option is to make SAP log out functionality also log the user out of Azure AD. At any time, an Azure AD user can access the URL https://login.microsoftonline.com/logout.srf and they will be logged out, and taken to a friendly screen telling them so.
Logging out of the Microsoft account entirely is the best choice if you have users on shared PCs, who may authenticate to Azure AD only for using SAP, and expect to then be logged out of everything. You must keep the current log out functionality of your application to remove the SAP session, then redirect the user to the Microsoft log out URL.
Azure AD really simplifies the process of setting up SAML2.0 based single sign-on for SAP. I have previously worked on quite a few projects with Microsoft ADFS as the SAML2.0 identity provider, and I have found that Azure AD is far easier to configure and works well with SAP with default settings.
Generally in SSO projects you need to expect a much larger proportion of time is spent on management discussions and designing the user experience, particularly in edge cases and special cases such as secure use of shared PCs. I normally help facilitate quite a few workshops before we can go live with SSO, and the relative ease of technical setup from Azure AD means a larger proportion of the project will be spent on design and decisions than actual configuration.
Using Azure AD for single sign-on is a great example of integrating an on-premises SAP landscape (or an Azure VM hosted SAP landscape) into Azure. You get a single user experience for all enterprise applications if you launch SAP from Office 365, and you gain all the usual benefits of single sign-on.
We are seeing customers looking to integrate different cloud products far more, and picking the best options from a range of vendors including SAP and Microsoft is becoming the obvious choice, with an associated expectation that they will integrate nicely. SAP and Microsoft have both made extensive progress towards open standards in recent years, and more integration is definitely a big part of the future.