Skip to Content
Technical Articles

An Unofficial, Non-Marketing Community Announcement – Is your SCP Tenant with Sensitive Data Secure?

How Secure are your SCP Platform Users/Administrators?

In Australia, there is a nice new payroll requirement to send all payroll data through to the Australian Tax Office called Single Touch Payroll. For many customers, this will be the first implementation of SAP Cloud Platform in the organisation beyond WebIDE tenants.

If you’ve used WebIDE before, you know you most likely log-in with your companies SAP S-ID with a username/password or x.509 Certificate from anywhere in the world – The performance and user experience benefits for those who work remotely without needing to VPN are great!

But does it sounds a little concerning if that’s all you need to do to access a system as an administrator which has all your companies’ employee data flying through SAP Cloud Integration?

Let’s talk about the S-ID’s themselves and how secure they are in your company to begin with:

  • Do users ever share S-ID’s or give out username/passwords (obviously a big no-no)?
  • Do you protect your x.509 certificates from being exported (very scary since these don’t expire for quite some time)?
  • Do you deprovision S-ID’s immediately when someone leaves?
  • Do you allow SAP logon id’s from outside of your company (C, P, D, I, etc) access to any of your tenants and know when to deprovision them?

Unfortunately, in reality, most companies probably do not have a good handle on the security of these SAP accounts I’m guessing.

Let’s also not forget we are talking about internet accessible web “services”.  Most likely, if your company knows anything about internet security, they have introduced “controls” like Multi-Factor Authentication and have their own Identity Provider to support this.

And it’s at this point, you start to scratch your head and say “What is everyone else doing?” which is where I was over a month ago. A little later, I discovered that the secret sauce no one forced you to purchase a subscription to is “SAP Identity Authentication Service”.

So what is SAP Identity Authentication Service (IAS)?

Now rather than give you a detailed product explanation of IAS, I’m going to tell you why you need SAP IAS if you use SCP for anything of a serious production nature.

IAS gives you the ability to remove the default SAP Account Identity Provider for your platform users to use your own Identity Provider; or at the very least, allow you to restrict access to your tenant for platform users with additional attributes such as dual-factor authentication, IP address ranges, etc.

Lots happens behind the scenes when you use this as an Identity Provider proxy apparently (like creation and mapping to new p-users) but for the sake of this post, that is irrelevant.

Note – It is important to note that licensing of IAS is based on number of individuals who logon per day.

Platform vs Application Identities

From my research (with lots of help from various sources both in and out of SAP), Application identities do not necessarily require IAS, and you can use your own Identity Provider and avoid any subscription logon licensing costs. But for Platform identities, you have no other option except single factor SAP user-id’s which, is probably obvious from above, I don’t believe is really an option.

How do I test this all out?

There is some good information out there about this, but unfortunately, no Trial access to IAS and the all-important Platform Users from what I could find. I hope SAP address this in the future as the more friction that stops you from getting security, single sign-on and access sorted; the more likely customers will be in a compromised situation.

So what is the Unofficial “Community Announcement”?

Until Dual-Factor Authentication is available for all SAP account usage by default, if doing anything serious with SCP, do not forget to you will need IAS!

Or more importantly, have I misunderstood this requirement & solution? Please help me and more importantly, the community understand if there is a better way and comment below and I’ll do my best to try keep the overarching post up to date.

A Last Minute Thought for the Day

Did you ever think about the internal systems’ usernames/password stored in the SAP support portal for SAP to support your production issues. Sometimes they are even stored directly in the message not in the secure area.

Now think about the fact that it is single factor authentication to this information via your potentially unmanaged S-ID’s.

With that thought in mind, you might want to consider everything you have available on the Internet and how you protect from malicious access. e.g. I remember a company that published an WebGUI application externally, but with a little url manipulation, I was able to get to a full WebGUI ERP logon screen. Now if I had an SAP_ALL username/password from the support portal…Well that could be interesting.

Appendix: Point of Clarification around STP/SCI

The actual solution for STP is very secure, and the point of this whole post is simply that if you don’t lock down your tenant administrators, they could easily get access to SAP Cloud Integration, turn on tracing and start to read your sensitive data (well that’s the theory at least)…

6 Comments
You must be Logged on to comment or reply to a post.
  • Hi Matt, we are also doing some research on how to elevate security level for our subaccounts.

    My impression is that some subaccount functionality does not work anymore as soon as a Platform IDP is configured:

    • Managing Git repositories (we get error messages as soon as a P-IDP is activated)
    • Deploy JAVA applications from Eclipse
    • Console Client

    Even if we would get it to work with an ordinary IAS (no MFA), I don’t see how an MFA could be integrated into JAVA deployment or into console client. We are curently reaching out to SAP to get this clarified.

    We were thinking of incorporating our Corporate SAML2-IDP into subaccount authentication (via IAS as SAML2 proxy). But this will probably never work because auf these Basic Authentication interfaces.

    What is your practical experience with Platform Identity Provider?

    Cheers, Lutz

    • That’s good feedback Lutz. My practical experience is very limited, so the above is the culmination of my research and talking with quite a few knowledgeable people, but they also raise your points.

      That said, my hope is that SCI as a solution doesn’t have that issue, but I’m assuming that I can use the application users and not the corporate users to get around that issue and use other factors like certificates and ip addresses.

      I believe you’ve highlighted the scariest bit which is not knowing whether a solution will impose an issue with using your own IdP or MFA for s-id’s; and the fact you need to make these changes to see what breaks (also known as “suck it and see”)!

      Maybe the only fix is to enforce the IP Address check in IAS for S-ID’s or for your own single factor IdP?  All I know is IAS is the only option to give me a chance of locking the SCP tenant down from external access.

      Cheers,

      Matt

  • Nice blog post Matt Harding – this is a very interesting topic as I believe there is a misconception that because it is cloud it is sort of protected and not requiring the usual administration duties that would normally be in place (e.g. SAP Basis Administration)  in on-premise SAP ERP systems. There is very limited knowledge in this space and I do worry about the ease with which some organisations allow Admin rights to their SAP Cloud Platform. For instance, one organisation I see has over 30 members in their DEV subaccount which is crazy and 1/2 of them are Administrators – seriously scary! I have been lucky enough to set up a number of environments end to end and each time I learn new things – especially about security elements and Platform security is one such area I want to get to know more on.

    Knowledge in customer land about SAP Cloud Platform is also very limited – definitely no best practices out there but a SAP Cloud Identity Authentication Service (SCIAS) tenant is available with SAP Cloud Platform for the reverse proxy authentication process but I have found the reality is that setting up authentication against an organisations ADFS is the main requirement. This means all services are authenticated via a company’s Active Directory and Federated Services used for when the user logs in outside of the network. This protects ALL SAPCP services, applications, and connectivity to the backend systems so I think in this respect it does offer a robust security element. Any backend connectivity is normally also controlled via the good old External ID mapping rules or by a certificate.

    As far as the platform itself, definitely needs more focus as the basic member roles of Administrator, and Developer pretty much give all rights – like a SAP ALL – especially the Admin role. The difficulty I see is that there is never time added to projects to provide a robust security method across the Platform and across subaccount services and applications. This needs to change.

    On an ongoing basis though those Administrators need to revise the members in all subaccounts and ask the question – do they really need that access – and remove those that don’t. This is housekeeping like any other system requires but agree with you that at the moment not sure that it happens.

    Two factor authentication I think is a good idea for the key areas that need to be protected – which would be the main Administration areas so I think this has a place and it is offered in SCIAS nicely using different user/security groups. I saw recently SMS functionality added as well so this may be the best approach in the future!

    cheers

    Phil

    • Hi Phil,

      Seems SCN doesn’t give me notifications on my posts anymore so missed this originally hence the delayed reply…

      Ignoring that – Thanks for the comments – Finding my current customer with a solution without IAS initially was definitely a frustration (apparently customers are not wanting to know they need this solution by default and looks like a recent change to offer to not include it).  e.g. To use ADFS for Platform Users, you need it.

      Role design is also a good point, and something to discuss with SAP further to ensure customers don’t think of PaaS like SaaS and assume all the right roles are perfect out of the box.

      BTW – From a MFA perspective, I’m liking what Azure AD provides for this, as it allows you to put the controls into the hands of the AD people in terms of MFA requirements; meaning that SCP just needs to get the Platform and Application User set-up working with SAML2 and ADFS.

      That said, for many customers, simply getting IAS, activating additional factors of authentication for the “s” users is probably enough (provided they don’t hit limitations like what Lutz refers to.

      Cheers,

      Matt

  • Hi Matt,

    Thanks for posting on this topic. I can now forward this to customers to make sure they subscribe to IAS for few admin users.

    Please note there are limitations when using IAS tenant act as a proxy to a Corporate Identity Provider. I have documented this in my blog post towards the end – “Setup a Platform Identity Provider for SAP Cloud Platform

    Further to this, you would have also noticed “Platform Roles” within the SCP cockpit. I would highly recommend to create your own custom platform roles and assign only the relevant scope to members administering various parts of the SCP account.

    • Thanks Murali. Working in a smaller project/support group – The granularity for admins and developers is not a big concern, but definitely a valid one to focus on over time and an important post to be aware of.