Management Considerations for Single Sign-On in SAP

Share This Post

Single Sign-On for SAP has a lot of advantages for user experience and security, with a business case possible for almost any organisation based on helpdesk time saving alone.

Every SAP single sign-on (SSO) project I’ve worked on has had a common theme: management-level meetings on the finer details of how SSO affects procedures and operations take far more effort than expected, whilst the technical configuration is quite predictable and contained.

I’ve posted a few articles recently that covered specific technical details of specific SSO projects for SAP, including using Azure AD SSO with SAP and making custom SSO for SAP mobile applications. This article covers the management topics that are common to all SSO projects.

Building the business case

SSO is a very common IT objective, but the individual project must be justified with quantified benefits against the cost in a business case.

The most tangible cost-saving benefit of SSO is helpdesk time saved. In one project we calculated the SAP authorisations team would save around 4 hours every day if they could eliminate SAP passwords. Time saved by the helpdesk gives an instant business case for SSO in most organisations.

The user experience benefits of SSO are harder to quantify, as it is difficult to measure a specific value of everybody in the organisation having one less password to remember and type each day. It is still possible to include user experience in the business case, as initial desire for SSO may have come from user feedback. Any application offers a poor experience sign-on is hard, particularly on mobile.

SSO improves security. There are fewer accounts to lock out when a user leaves, and fewer to be compromised. It can enforce a consistent level of security for authentication to all applications, such as two-factor authentication. A single password policy becomes universal across all applications. With fewer passwords to remember, the users are less likely to write them down.

The tangible helpdesk time saved forms the backbone of a business case for SSO, usually demonstrating a relatively short period in which the project will pay for itself financially or in terms of staff time saved. Additional material that addresses specific user experience and security concerns, aligned to the IT strategy, helps to ensure the SSO project is prioritised.

Edge Cases

Management need to handle edge cases that affect the chosen design. An edge case is a specific scenario that exists in the real world but may not be immediately obvious when designing or testing the solution, such as a single user who accesses SAP differently from others.

On one project I encountered two users who had a special exception to share a Windows user account because they were in a remote outpost in Northern Canada without adequate bandwidth to log off and on, whilst they had to use individual SAP accounts: how can SAP know who is logging on via SSO?

Another project was going to steer users into a new web link that got them into SAP with SSO in a single click. It was not known that workflow was sending emails to users, including an old SAP link that didn’t handle SSO properly.

The earlier you know all the edge cases, the less problems they cause, as the technical design can take them into account. If edge cases are uncovered later, rework and redesign is required. The late discovery of edge cases is the biggest cause of SSO projects exceeding their planned budget.

I find office-based workers don’t raise many difficulties, so the search for edge cases should be focussed on mobile or remote users, and those who are not normally at a desk. If you have manufacturing plants, find out how the workers in those locations use SAP, in detail from log in to Windows onwards. If you are working in a local authority, find out how the snowplough driver submits his timesheet.

Mapping User Accounts

It is necessary to map the SSO user accounts, usually from Active Directory (AD), to an SAP user account. If the usernames already match, you are in the fortunate case of not needing to worry about mapping. For everyone else, it’s a really big topic.

Changing the SAP accounts to use the AD username is an option, but the SAP username field is much shorter than in AD so it’s not normally possible. Instead, the alias or email fields in SAP are used, or you can use a table in SAP that lists a direct mapping between usernames.

Email addresses work well as they are already set in AD and in SAP. It is still important to verify the data, checking cases like email addresses that have changed (through marriage, for example) in the current records and in the procedure for future changes.

Mapping is the number one opportunity for security vulnerabilities to creep into an SAP SSO solution. You need to take management steps to make sure the fields used for mapping are always set correctly by everybody who has access to change them, without exceptions, or a user could log in and find themselves in somebody else’s SAP account.

An interesting audit point was raised by the SAP authorisations team during an SSO project. We planned to store the SAP username in a custom field in AD for mapping, but that would have moved control of who can access a SAP account from the SAP authorisations team, to everyone who had access to change AD accounts. It would have brought controls and procedures from across IT into the scope of SAP authorisations audits, causing a lot of extra work. Avoid that by storing the AD username in the SAP system for mapping and not the other way around.

Top tips for delivery and support

The implementation of single sign-on is usually done by SAP and Active Directory specialists working together. Effective teamwork is key, so ensure the team is made up of people who are a good fit and foster a good environment for teamwork by reminding everyone that they are all crossing disciplines.

At the go live, change management is used to make sure everybody knows what to expect. An important consideration is the experience of the helpdesk or first level support; they are no longer troubleshooting password issues but now looking at mapping issues or SSO failures. They will need training during go live and immediately after.

Moving into long-term support, it’s important to capture information on the setup. SSO is out of usual comfort zones and usually requires research and learning to set up, that is soon lost as time passes. Any certificates with expiry dates will need to be replaced periodically, so get them into the planning calendar with documentation to avoid getting caught out.

Summary

Single Sign-On for SAP has a lot of advantages for user experience and security, with a business case possible for almost any organisation based on helpdesk time saving alone.

To manage SSO effectively, find the edge cases up-front, make a robust plan for mapping users securely, and create a project team who can work together to deliver it and support the helpdesk and users through the process.