Skip to Content

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 or contact me at

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Babu Jayendran
    Having spent many years in the GRC and Information Systems Audit space, I absolutely endorse your views.

    Multiple systems with User IDs and Passwords only forces users to write it down on ‘Post It’ stickers and place it in their work area!

    SSO is definitely the way forward.

    Thanks for your blog.


  2. Another vector is identity: you may want to reveal a different aspect of ‘you’ depending on the site you log on to.
    For individual in private life this means that you share less with the drugstore than with your photo site. SSO does not differentiate here.
  3. Mike Oswalt
    Yes, it is desirable.  What you are suggesting is that either randomly or for specific transactions that a “challenge” question be asked (or I suppose you could substitute a biometric check, or token) to affirm the SSO credentials are still good.  I noticed the other day at a brokerage firm site that logging on from an “unknown” computer required answering a challenge question.  Please pursue SSO or Sxip or something to better manage identity.  What is being done today make no sense at all.
  4. Tim Alsop
    In my experience the need for SSO is never being questioned these days, since most IT organisations are already familiar with the clear benefits it delivers. The real, more appropriate questions are, for example: “What technology, and approach should be used to implement SSO ?” and “Should I consider a solution that is implemented using propriatory SAP technology, or one which I can use with all of my business applications to give the users the same user experience and give the IT department the common solution they desire ?”.

    It should also be noted that there have been solutions available to implement SSO with applications for 20 years or more, and now IT organisations are more focused on “security” because of compliance / audit needs.

    So, ideally companies should be looking for Secure SSO solutions that are standards based so they can implement the same solution with SAP and non-SAP applications in their company.

    Tim Alsop
    CyberSafe Limited


Leave a Reply