Across borders: Cloud single sign-on between SAP and Microsoft

The integration between the Microsoft and SAP world poses great challenges for many companies. The different systems should not only communicate with each other, but also share, transfer and process data. A particularly challenging task is the integration of identities: How can I manage an identity between SAP and Microsoft systems without users having to use multiple accounts or different passwords?

Would you like to offer your employees SSO for cloud systems as well?

Proven on-premise tools

In on-premise systems, common single sign-on solutions such as SAP Single Sign-On (SSO), Microsoft Active Directory Federation Services (ADFS) or Ping Identity are used for this purpose. Technical aids such as Kerberos tokens, SAP tickets, or X.509 certificates are also used. In fact, many companies in the on-premise sector already have solutions that enable them to offer their employees single sign-on across technology boundaries.

In the cloud, however, this quickly reaches its limits. Kerberos infrastructures are rarely accessible outside the corporate network. Mobile devices and BYOD policies make certificate distribution increasingly complicated. At the same time, the question of single sign-on in the cloud is becoming increasingly important. It is virtually essential in cloud systems that address embedded third-party systems. Think, for example, of an SAP S/4HANA system in the cloud that is to offer SAP Cloud Analytics Reports.

When SSO is deceptive

For this purpose SAP offers an identity provider (SAP Identity Authentication Service) in a bundle with its cloud products. However, in this case, the standard configuration starts from scratch again: You have to maintain a user master, store new passwords for the users and generally handle the user administration. The setup and administration effort in such a scenario is enormous. In addition, users receive a new initial password, which they ideally set after their Microsoft password to create a feeling of single sign-on. However, it is not a “real” SSO: If the password is reset in Active Directory, the old one remains the same in the SAP cloud.

Option 1: Single Sign-On with Active Directory backend

One way to overcome many of the hurdles outlined above is to reuse your user base in the Active Directory. To do this, the company’s Active Directory is connected to SAP Identity Authentification Service (IAS) as a backend system.

The advantage: There is no need to manage users manually, and there are no inconsistencies in passwords. The user logs in conveniently with his Windows account and can start right away. A further benefit: The group assignments in the Active Directory are taken over. This allows rights management to be delegated to the Active Directory – without any additional customizing.

Access for external users and customers

Not all identities necessarily end up in the Active Directory. More and more companies offer customer portals in B2B or B2C context. The goal: Customers or suppliers should have access to all services and apps with one central identity. In the context of identities this raises many questions: How does a customer get to his account? How do I ensure the isolation of customer accounts? How can I ensure that unauthorized persons do not have access to internal company systems? Are there restrictions regarding access from certain countries or regions (due to trade restrictions or similar) that I have to observe?

SAP Cloud Identity provides mechanisms for self-registration and for controlling and isolating external identities. The access mechanism works with a connected Active Directory with fallback functionality. Primarily, the account is searched for when logging on to the Active Directory. If it is not found, the system searches for the identity in its own user master record. This means that external users that you do not want to maintain in the Active Directory can be managed in IAS. Of course, only the groups that the user has been assigned in the IAS are read in.

The IAS offers even a self-registration function, which is finely granular controllable – whether with a side in the corporate identity, with an access protection from certain regions or with the setting of own General Terms and Conditions. Users who come via such sources receive their own isolated user area (in this case “public”) and can only access systems that have been explicitly allowed. In addition, users can easily use the functionality “Forgot password” of SAP Cloud Identity to reset their passwords. In addition, the IAS provides interfaces to read out users via protocols such as REST or SCIM, distribute them to other systems, or create analyses and reports.

Option 2: ADFS – partner instead of competitor

Companies often already have a functioning cloud SSO solution in the Azure cloud in form of the Active Directory Federation Service (ADFS). Many of the functionalities offered by IAS are also mastered by the counterpart from the Microsoft world. Companies are therefore faced with the question of whether a dual solution makes sense at all. The temptation to use one of the solutions across the entire technology environment is naturally great. In this respect, the question of whether it makes sense cannot be completely dismissed.

The answer to this question is not technical, but professional. How good is the interdisciplinary cooperation between my Microsoft and SAP colleagues? What efforts, bottlenecks and problems do I cause in such an interaction? How do I deal with responsibilities? Who is responsible if a user cannot log on to an SAP system with his ADFS account? Who does the error analysis? Do I have competencies in the company that can look for errors between the two worlds?

Hybrid efficiency

Those who are not quite sure whether they can overcome the technical hurdles also have the option of a hybrid solution between IAS and ADFS. In this case a kind of proxy functionality of the IAS is used. One connects the IAS once to the ADFS and all SAP systems for which single sign-on should be possible are connected to the IAS. The IAS then routes the authentication to the ADFS. The received authentication ticket is even valid between Microsoft and SAP systems.

In this case, the internal SAP IT can connect its landscape to the IAS and use the functionalities of the ADFS without having to integrate the Microsoft IT each time. Error analysis is then primarily performed at the IAS. Only when a cause can be excluded in the IAS does the Microsoft IT come into play. Such a technological partnership of both solutions increases the flexibility and efficiency of the IT – despite a supposedly redundant double operation.

Conclusion: Cloud SSO overcomes technological boundaries

Thanks to the latest technologies, close integration between the Microsoft and SAP world is no longer an insurmountable obstacle for SSO in the cloud. Whether with an existing ADFS solution or with an initial kick-off with IAS and AD backend – nothing stands in the way of a cooperation between Microsoft and SAP systems.