Many users of your SAP-enabled web applications will be people who do not have named SAP userids, either because they are employees who do not require constant access to SAP or because they are business partners. So your applications will use a generic userid (or several, for different types of applications). In many applications, though, you require a userid/password mechanism that guarantees that only authorized persons can access the functionality.
While you could implement the required mechanism yourself (outside of SAP), it is probably faster and easier to use the password BAPIs that SAP provides for the object types Employee, Customer, Vendor, Applicant, and BusPartnerEmployee. (There are some additional object types with password BAPIs but they are either obsolete or have incomplete password functionality.) These object types have a set of BAPIs that allow you to create object type-specific userids and passwords and manipulate and check them.
In SAPGUI, you can use transaction code SU05 to maintain these userids. A normal application will at least need to check the password that a user enters and may also let the user change the password. A more sophisticated application might even enforce a periodic password change.
An administrator application (as an easy-to-use alternative to SU05) must be able to create, delete, and lock userids, re-initialize the password (in case the user has forgotten it), and check the status of a userid. The SAP password BAPIs allow you to do all these things, without you having to worry about a separate database, password encryption et cetera.
If you want to save some time in getting up to speed with these BAPIs, read my article "Password Management for Extranet Applications" in the July/August issue of the SAP Professional Journal (www.sappro.com). And if you are using the SAP Java Connector (JCo) for your applications (the best BAPI middleware I am aware of) then you can even save more time: I have developed a Java component that encapsulates access to the password BAPIs and allows you to manipulate the userids and passwords with a few lines of code. Contact me (firstname.lastname@example.org) if you want to receive an evaluation copy.
By the way, if you are already on 4.6C or later, there is a new mechanism for dealing with external users. RFM SUSR_USER_INTERNET_CREATE allows you to create new standard users through RFC. Details about how to deal with the associated license issues can be found in OSS Note 313585.
Thomas G. Schuessler, www.arasoft.de