A lesson learnt on Integration and Complexity

Just recently I got this request from a customer: when using the NetWeaver Developer Studio (NWDS) with NetWeaver Development Infrastructure (NWDI), the Studio effectively is using a server and therefore must log in to it. This results in a small login window that appears. To make this easier the password may be stored for further use.

The request was that in case the password is forced to change by the server, it should be possible to do this without logging into the server via a web interface but also from the NWDS. The current situation is that this change request is not handled by the studio and after several tries (as users are not aware that a change is needed) results in a lock of the user. As this seems to make a lot of sense, I talked to development.

After a short discussion I found myself sent to the next department. As this is not what I would call a good start Idecided to first really understand the problem before running around with other peoples knowledge…

What they had told me was that the Studio does not get any more specific information than an “unauthorized” answer from the server once the password timed out. Unfortuantely it is a security standard to not give more information on login requests for agood reason. In addition, the client does not have any information about when an attempt for a new password will be.

All together this means that to make this requirement happen we would need to either change a security standard or implement a specific login that would keep track on the time left for updating passwords. This seamed pretty much effort to me for such few functionality. I started to think about alternatives.

The actual problem is that the login mechanism doesn’t warn the developer and such functions more like a trap that results in a user lock. After this she finds herself searching for an admin to get unlocked. Wouldn’t it be enough to just give a hint when the window asks you for an unexpected login?

The final decision hit me yesterday: i was looking into the server to get a better overview on htis problem searching for the admin options for user management. Threre is no such option to renew passwords after x days. As you might know the User Management Engine (UME) allows to connect to an internal user system, an LDAP one, or an ABAP server. And I know very well that ABAP servers do have that functionality. In other words, the implementation would have to take care about password changes throöugh another server.

This assured me that I’m on the right track with “second best” .

And if you ever come back to me for more, then please let me know why the heck you need renewing passwords on a development system 😉

Assigned tags

Related Blog Posts

Related Questions

You seem to be missing the point about what an ABAP (transactional) system is when using it as UME and why a Java Development Studio (which can also be installed on the client side) needs to respect server security and authentication.

Have you considered that the problem might be on your side, combined with the sharing of passwords to access the SDM?

If the development is on the development server (How many Java developers do not work from home?) then you might also want to consider calling a standard API (like the portal does) to interogate the valitity of the password (if correct) and provide a (secure) option to set a new one.

=> If the user reset the password on the “server” side, then they should know it…

Hey, Julius, see that little flag on my name? Nobody in this company has the slightest doubt about why security is needed. It’s so deep in our hearts that it doesn’t need to be mentioned.However, I know the “Hey-SAP-Admin-gimmme-access-to-those-servers-and-i-dont-care-if-company-assets-run-on-it”- effect. Usually done by Java programmers, usually starts a war on ressources. But this is another blog about cultural differences in both worlds…

>Out of curiosity, where is the password saved “for further use” and in what form?

I know what you’re thinking, and you’re right (Tom Magnum, 1985). But I mentioned that there are standards for this and they are mandatory even for Java products. Our security people would shudder and shout if they wouldn’t be kept. As far as I know eclipse now has it’s own mechanisms to crypt such stuff.Regards,Benny …. and here’s mine 😉

You could consider using the SecureStore area (the call stacks are protected, so you will need to talk to the above department again) but that still does not solve the problem of saving the password in more than one place and expecting it to remain in sync although the one is a one-way-hash and the other is reversable – or trying to sync them and expecting that to work.

Even in development systems it is more secure to have a security policy which expects that a user’s own private password be changed after a period of time and a necessity that they should be able to voluntarily change it.

I would like to make a confession that in audits I have analyzed the failed logins which lock the passwords of users via the kernel and traced these back to their source terminal. This is not only limited to Java vs. ABAP worlds.

So what I am thinking is “Did he enter his password five times or only once somewhere?” and yes, I am feeling lucky now again… 😉 (The punk from Dirty Harry).

It’s true that the details regarding a failed logon attempt must not be revealed to the client (which might be an attacker) – but that only refers to the validation of the provided credentials.

The requirement to change a password is handled separately – it might even be the case that a user is using some kind of Single Sign-On (SSO) mechanism but posseses a password which needs to be changed.

However: the requirement to change a password is always handled after validating the credentials. It does not make any sense to prompt a user for password change if he is not even able to provide the correct current password (in case of a password-based authentication).