As users of SAP systems, when logging in we are periodically bombarded with requests to change our existing passwords, each time facing the challenge of constructing them in such a way as to meet expectations as to the length and complexity. The story repeats itself with each successive application used at work. What if this could be avoided? What if we could take care of just one account, one password so that we could concentrate on work rather than memorizing passwords?
After all, we know this from the mobile services we use every day – we log in to many daily used resources, such as online marketplaces, through social media accounts.
The good news is that we can also log in to SAP without a password.
The Single Sign On mechanism in SAP systems simplifies and automates access. The introduction of the SSO also reduces the time spent on managing the security of user accounts, while increasing the comfort of use and work by requiring only one password for access to multiple systems.
The Central User Administration, on the other hand, is a complement that allows us to manage SAP system access accounts and authorizations assigned to them in one place and automatically distribute them to systems coupled with this mechanism.
This is a necessity in companies where the system landscape consists of as many as a dozen systems and clients for several hundred users – with this mechanism, we can easily set up an account for a new employee in many systems, change authorizations for an existing one, lock an account or change its password if we decided to use the CUA mechanism without parallel implementation of SSO mechanisms in our SAP environment.
SSO 3.0 and SAML 2.0
There are two communication methods available in the Single Sign On authentication scheme in SAP systems – the first one is SSO 3.0 based on the Kerberos token, and the second one uses SSO SAML 2.0.
In the Kerberos-based SSO 3.0 communication method, the user logs in with a domain account to their workstation on which the SAP Secure Login Client is installed. At this point, they receive a Kerberos token assigned to a given workstation and user. When the user logs in to SAP, the information about this fact is transmitted by the SAP Secure Login Client. In the next step – on the SAP side – the token information from the workstation is honored. The user account and the client are then assigned to it.
The main advantages of this method are full SAP integration with SSO (SAP Logon, HTTP/S, Fiori), high security of the SSO mechanism and easy implementation. It is also worth noting that from the users’ point of view, SSO 3.0 is one of the most convenient methods of authorization on workstations.
Disadvantages include the possibility of integrating SSO only with Active Directory and the need to purchase an additional SAP license.
In the second method of communication, based on SSO SAML 2.0, in the first step the user tries to log into the system with SSO through this solution. Their request is automatically forwarded to the identity provider for authentication. The identity provider sends a request to the user asking them to enter credentials. After the user or user agent submits the requested credentials and they are verified, a feedback on granting access to the indicated user is sent.
SAML 2.0 can be integrated with both Active Directory as well as AWS, Azure and other public clouds. No additional SAP license is required. Implementation of this method is relatively easy.
Disadvantages include the fact that SSP SAML 2.0 does not work for access via SAP Logon.
SSO in practice
We present an example of the integration of the login tool using Single Sign On with SAP systems. This integration was made for one of our customers in order to eliminate the need for multiple logins.
During the SAP Fiori implementation, the customer asked us to verify the possibility of using the authorization platform they were using to access other internal systems to log in to SAP Fiori Launchpad. The user could access other systems in the company when they just provided a business e-mail and entered a password once. The integration allows us to avoid the need to perform re-logins, which would increase the comfort of using SAP Fiori.
The SAML 2.0 protocol, which is used for authentication and automatic transfer of information on user authorizations between systems and applications, appeared to be helpful here. It is worth noting that an application of any identity provider (IdP) that allows the use of SAML (e.g. Azure ADFS, Google) can be used to log in.
The basic configuration of the solution in the SAP system is limited to activating the relevant ICF (Internet Communication Framework) nodes and creating the Local Provider on the side of the SAP system and the identity provider, as well as exchanging provider data via generated .xml files.
Later, all that had to be done was to configure the mapping of the field to be used to identify the user in the SAP system. This can be, for example, a user name, an email address, a last name or any other field.
Now our customer’s employees can enjoy a working SSO login.
Mission: centralization
Another aspect of user management in SAP is the expansion of the scale of system environments/clients and the related significant increase in user handling time when creating accounts, managing authorizations, as well as unlocking and changing passwords.
One customer approached us expecting a solution to a user administration problem, including noticeably increasing handling time.
We proposed the Central User Administration (CUA) solution. Now, CUA enables the customer’s administrators to manage users in all SAP systems easier, cheaper and faster. They can create accounts, manage permissions and change passwords or unlock accounts from one place. Centralized authorization management is much more efficient. Security has also improved in terms of access rights to systems and data.
And one more thing – which our customer really liked – there is no need to install an additional system or buy new licenses to use CUA.
One team, one security administrator can simultaneously make a change for users in multiple systems from one place. Changes made in the central system are automatically transmitted to satellite systems using SAP Application Link Enabling (ALE) technology. There is no longer a need to log in to each system/client separately.
Also, a change in the basic data of a specific user (e.g., a phone number, a name) is automatically propagated to all systems in which it occurs.
CUA is very useful for managing teams, implementing new solutions, substituting employees, etc. It also facilitates the management of licenses assigned to individual users and provides full control over them.