Undoubtedly the biggest and easiest win for system administrators and users alike is Single Sign-On authentication, where access to SAP's Infrastructure can be translated into application access. Nowadays, most of us take SSO for granted, but it wasn't that long ago we logged into our computers in the morning and then logged into the various systems we used throughout the day. In this section, I want to outline the steps from an Azure perspective on how to implement single sign-on by integrating Azure Active Directory with various SAP systems and applications.

No matter the application integrating authentication involves setting up the target SAP application as an Enterprise application within Azure Active Directory. From the Azure portal home page, select Azure Active Directory if it's visible or search for it in Search resources, services, and docs. Then select Enterprise Applications from the Manage menu on the left. Within Enterprise applications, click the New application button at the top to add an SAP app. In Browse Azure AD Gallery, you can filter the selection with the keyword SAP and check SAML (security assertion markup language) from the single sign-on filter. It turns out that all SAP applications support SAML. Selecting SAP HANA will add it to my application list. From here, I can click the SAP HANA application to set up single sign-on and other access parameters.

As single sign-on uses the same SAML mechanism for SAP, the setup process is from the Azure end is similar for all applications. The differences are in the Basic SAML Configuration, where URLs and parameters are application dependent. 

Users are configured within User Attributes and Claims by clicking the edit button. Typically, you want to strip off the username from the email address used for logging in to Azure. Clicking on the Unique User Identifier will allow you to modify how it is passed through to the application by selecting the ExtractMailPrefix transformation on user mail. This transformation extracts everything before the email "@".

You will need to associated active directory users with each Enterprise application by adding them through Users and groups.

Once you have set up the SAP application endpoint through Basic SAML Configuration and user claims, you can download the certificates and the Federation Metadata XML to load into the SAP application. How you do this depends on the application and its version. 

In the case of SAP HANA, you can upload the Federation XML within the XS Hana admin application by adding a new SAML identity provider and pasting the SAML XML into the metadata text box. Alternately, upload the SAML XML into a new Trust Configuration within the XS Advanced Cockpit. In either case, the relevant certificate and URL information is extracted and saved. Users can be set up to authenticate via SAML through HANA studio administration.

I have an SAP Cloud Platform trial set up here, and I want to enable single sign-on using Azure Active Directory. The beauty of the SAP cloud platform is that I can download the correct configuration in SAML metadata from trust configuration. I'll save the metadata to my PC and head over to the Azure portal. Within Azure Active Directory, I'll set up an SAP Cloud Platform enterprise application. That's a new application, SAP Cloud platform, and then the SAP Cloud Platform product. I'll stick with the default name and hit the create button. Before configuring the single sign-on, I'll select myself as an SAP Cloud Platform user, confirming with the assign button. 

Over to the SAML setup in single sign-on. Most of the basic SAML configuration can be filled in with data from the SAML XML file we downloaded from the SAP Cloud Platform. I can import it with the upload metadata. The SAML fills in the authentication URLs, and we are left with just the sign-on URL to specify. I'm feeling particularly ironic this morning, so I'll grab the users' URL from the SAP cloud platform and paste it in as the sign-on URL, click save, and close the configuration pane. Hmmm, pretty sure I supplied the reply URL. Let me refresh the page. There we go, that's more like it.

Now to set up the user authentication by editing user attributes and claims. I'll modify the existing required claim by saying I want to match on the user name part of the email address. This will involve doing a transformation. Select transformation as the source and then ExtractMailPrefix as the transformation and user.mail as the parameter, and click add. I'm using the email address instead of the principal name as being a subscription owner, the two aren't the same. After adding the transformation, click save.

I can download the Azure federation XML with this end configured and go back to the SAP cloud platform's trust configuration. Now, I can tell SAP about Azure by creating a new trust configuration. I'll upload the XML file, give the configuration the name AZURESCPSSO and save it. Next, I'll create a user associated with the new AZURESCPSSO identity. The user name is hallam, matching my email prefix, and I'm required to enter an email address. Finally, I'll assign the new user a bunch of roles. Back in the Azure portal, I'll test the single sign-on by clicking sign-in as current user. A new tab opens, and briefly, we see the account active directory URL before we're directed to the SAP cloud platform.