If SAP business applications play an increasingly important role in your company, and if more and more users in your company access SAP, then I’m sure you have been thinking about how to optimize the productivity of your users through a single sign-on solution for the entire SAP landscape. But is single sign-on – in its true meaning – really desirable? It’s worthwhile to think about this quickly.
Single sign-on is a great productivity boost for your users and for the IT organization, because users don’t need to enter SAP user name and password again and again, and because it significantly reduces the number of IT help desk calls about lost passwords. From a productivity perspective, it is best to re-use existing user credentials, e.g. Windows logon information or Windows Kerberos tickets, because users have already authenticated at this level when they start SAP from their Windows desktop. From a security perspective, a stronger, 2-factor authentication via SmartCards, one-time password tokens, etc. offers better protection.
Now, here comes the challenge: there are situations where an increased business risk makes it advisable to explicitly force users to re-authenticate. A few examples:
certain SAP systems include highly sensitive information. Users who want to access this system should use a stronger authentication mechanism (e.g. RSA Token) than for the other SAP systems, where Windows authentication is sufficient.
certain roles in the SAP system (e.g. administrator role) have powerful rights. If a user logs on with this role, the authentication demands should be stricter (2-factor authentication) than if the user logs in with a normal role.
certain business-critical SAP transactions should trigger a re-authentication to verify that the that the person sitting in front of the computer is really the one who has originally signed on. This is a required mechanism in certain SAP industry solutions (for example: pharmaceutical industry), triggered by the FDA or GxP regulations. But it should be good risk management practice in every SAP environment. The important part is that the re-authentication should use the same authentication mechanism as the one used for initial sign-on to SAP, so that you don’t have to maintain passwords just for the re-authentication functionality.
This kind of risk-oriented control of the authentication process is what allows you to implement single sign-on – or one should rather say “reduced sign-on” – without compromising security. SAP delivers the means to implement this.
If you want to learn more, you can download a business whitepaper “Cost-Effective Compliance with FDA Regulations for Your SAP Applications” from www.secude.com or contact me at firstname.lastname@example.org.