About User Authentication
User-based security allows access to an application by authenticating a user's username and password. You must setup each user of the application, entering their username and password into the system. A user is anyone who will be accessing the application, including developers, special user-types, administrators, and so on.
To authenticate a user, the application developer must call the loginSession( ) method. Through this method, the username and password entered by the user are passed to the server. The server then verifies that the user can login to the system by checking the entered information against the list you created. The application developer must use sessions for the system to know who the user is.
Once a user is logged into the system, his or her access to specific AppLogic objects can be managed programmatically by the application developer using Access Control Lists and the isAuthorized( ) method. For more information about Access Control Lists, see "About Access Control List Authorization."
Alternatively, users can be managed by explicitly mapping them to the AppLogic objects to which they have access. This is a more tedious approach to application security, but it might be useful when first deploying and testing the application. For more information about mapping users to AppLogic objects, see "About AppLogic Access Authorization."
When you install a Netscape Application Server, two default user names and passwords are stored in the registry, kdemo/kdemo for sample application users, and the administrator user name and password you specify during install.
How Netscape Application Server Stores and Manages Users
The information you specify for each user you create is stored in the local registry, which is managed by the Global Directory Service (GDS). The local registry is not held in a database, but rather a local file system that is typically cached in active memory. The information held in the registry is shared between all Netscape Application Servers when you have multiple servers supporting an application.
Because each user is stored in the local registry, this level of application security is most useful for applications where the number of expected users is limited. For example, for an Internet online shopping with potentially tens of thousands of customers, the local registry is not the best place to manage those users. Instead, you should use roles. For more information about roles, see "About Role Authentication."
|
Previous
