Johan van Zijl

This presentation just popped into my inbox. It describes the new features in SAP NetWeaver 7.1 CE’s Web Dypro Java.

But the screens in the presentation looks exactly like CRM 2007 screens!

Interesting, considering CRM 2007 has been available for almost a year now and is built on ABAP/BSP and not even WebDynpro.

Mmm…The same UI built and supported in 2 languages!?

I recently read a very interesting post by Martin Ceronio that explains an innovative way of gaining shell access to any SAP system.

Obviously, Basis and Security consultants all over will have a fit when they realise this is possible on their precious SAP systems. I must admit though, this is so easy that I am not 100% comfortable with this hole.

But, In order to exploit this you do need access to an SAP system and a fair amount of knowledge of how SAP works …and sufficient authorization.

This brings me to something that has been bothering me lately, which is customers need to trust the consultants they give access to their systems, especially ABAP consultants as they no more about the internals of SAP than anyone else.

The latest trend  is to lock down authorizations in development systems to the point where consultants are unable to perform their work and there is always doubt as to whether the problem is code related or authorization related. I completely support the full lock down of Quality Assurance and Production Systems, but is it really necessary in Development?

The moment you give a consultant debug with variable change authorization(which ABAP consultants must have in development), virtually any check can be bypassed (you can even grant yourself SAP_ALL and a Developer Key).

The other major threat is ABAP developers writing malicious programs and slipping them into production under the radar.

In my view draconian restrictions in development systems frustrates your consultants and leads to a real increase in development time. The assumptions made by the implemter of these authorizations must be(maybe a bit harsh):

• The consultants cannot be trusted to act responsibility
• They are too stupid to find their way around all the restrictions

There is a lighter side to this though and that involves phoning the authorization consultant at 2:00 AM for that transaction code you really need now to the fix problem(and going to bed and booking a delay against him if he doesn’t answer).