Everyone who has worked and is working with SAP JAVA systems are more or less familiar with Software Deployment Manager or SDM. In short it is the standard tool that you use to install J2EE components on the SAP J2EE Engine. The tool is fantastic and it just works fine (at least the times I tried to work with it). Now, problem with this tool is that (and I borrow from SAP documentation) "SDM Server recognizes only one user, the SDM administrator. That means Anybody who has the password of this user can perform any activity in the SDM (such as deployment and undeployment). It is not easy to trace which user performed a particular activity".
Well, it's not really a problem as long as you or your System Administrator guards this password closed in a dark envelop in a secret chamber and only uses it when Java Server needs patching. Then your Java developer comes to you asking for SDM password because he or she has developed a new version of a WebDynpro application and wants to deploy it on SAP server in order to test it. You look at the SAP security guide to check the potential risk of giving away SDM password and the best practice documentation says "Use restrictive guidelines for the password. Also keep the group of people that knows the SDM password as small as possible". It's very important, because with SDM you not only can install/deploy new Software component, but also can remove/un-deploy them.
Now, you start scratching your head, wondering whether you will give away the SDM password to your developer. You decide: okay, you will deploy the new package for your developer. After all, doing it one time, does not harm ! The developer goes away happily only to return within 10 minutes because there was some minor modification in the new WebDynpro application and a new archive file needs to be deployed !
The story does not end there. Last month we were trying to activate new Netweaver Mobile Administrator (new WebConsole) for our Mobile Infrastructure (MI) Server. There is a new feature called "Mobile Archive Converter" where you can now convert your Mobile Component Archive (*.war) files in SDA format and deploy on the MI Server. The huge benefit is that you will not need to worry about copying the Mobile Component Archives in OS level manually between your Java Application servers or even updating links in High-Availability environment. So, enthusiastically we went ahead with showing the functionality, and then...it striked again, asking "The SDM Password" !!!
Even worse, if you continue without putting a password, it tries SDM logon with an empty password and it counts as a wrong login. As you may know, you can only try to logon three times with wrong password before SDM shuts itself down.
We have large user base working with Mobile solution and these Mobile components are generally developed and managed by Mobile Application team. They need to be able to deploy/un-deploy new archives for their users at a short period of time and sometimes frequently. But how to share SDM password (in a secured but effective way) ?
Well, I am still searching for a solution. I think there should be a clear demarcation between two different needs: the Developer community and the System/Security Administrators. Sometimes, the system installation, patching are done by a complete different group of people than regular system admin tasks (e.g. SAP Infrastructure managed by a third party).
A multiple user access possibility inside SDM with different/delegated authorization (e.g. based upon Software Component Name space e.g. "sap.com", "com.adobe", "mycompany.com" etc) might be a good solution. Another option would be to provide different tools for different audience. It's worth to note that JSPM (Java Support Package Manager) still uses SDM password.
I do not know if SAP will consider this to improve in future releases. We can only hope.
