I’m new to wM. I don’t understand why that only developer users can change their own passwords. If there are other users, such as application end users, their passwords are chosen and maintained by the Administrator(s), then there is no privacy. If there is no password privacy, we cannot hold the user account for what had been done by the user account. Is there a logic in wM implementation that I don’t understand, or this is wM’s limitation? Is that true that if password privacy is mandatory then we have to implement LDAP, or even personal certificates? Also, there is no expiry on password and/or account in wM.
User and password management is rather weak.
Annie,
These are great questions. You’re absolutely right that there are tradeoffs in users not being able to change their own passwords. One of the positives is that administrators can ensure that users have strong passwords (i.e., not their dog’s name). The biggest downside, as you note, is that the administrator knows everyone’s password.
The real motivation is that in a server-to-server environment, it doesn’t make sense for a server to be picking its own password. Developers can, however, change their own password using the webMethods Developer tool (it’s on one of the pulldown menus). See Chapter 2 of the Developer’s Guide for details.
One of the cool things about how webMethods works is that it’s actually quite easy to give users the ability to change their own passwords, as in the case you give with application end users. Because webMethods Integration Server uses a service-based architecture, all you do is change the ACL on the password change service so make it available to whatever groups you want. For example, instead of it being Developers (the default), you could create a new ACL called UsersWhoCanChangeTheirOwnPassword containing the groups Developers, Partners, and Administrators, and put that ACL on the password change service. You might even have different types of users, maybe “GradeAUsers” and “GradeBUsers”, and only the former can change their own password.
Once you’ve changed the ACL, you can then use the URL for the service to submit a password change.
Note that you cannot use this mechanism to change a password stored in an LDAP server.
So that’s how you’d make it possible for application end users to change their own password.
Hope that helps; please follow up if you have further comments, suggestions, or questions!
Jeremy Epstein
Director of Product Security
webMethods, Inc.
I tried to do this however my company experienced that if a user changes their own password via the URL that they can’t login when the server is shutdown and then brought back up???