|
|
User Management Guide |
This chapter provides an overview of Director's user-related services. It includes these topics:
Director is made up of a variety of subsystems, each of which provides a group of services. Director's user-related services are provided by three subsystems:
The Directory subsystem (authentication)
The Security subsystem (authorization)
The User subsystem (user profiling)
The purpose of the Directory subsystem is authentication, the process of verifying the identity of a user who is requesting access to protected resources in a Director application. Authentication in Director is performed by obtaining a user name and password and checking them against a list of registered users. Knowledge of a registered user ID and the corresponding password is assumed to guarantee that a user is authentic.
Each user registers initially (or is registered by someone else), using an assigned or self-declared user ID and password. On each subsequent use, the user must know and use the previously declared user ID password. Successful authentication results in the user or group being assigned an identity called a principal.
The process of checking a name and password against a list of registered users is done by accessing one (and in some cases two) preconfigured authentication repositories called realms. A realm can be:
A J2EE application server's internal directory of user information
A J2EE application server's interface to an external directory server such as Windows (NT) Domains, Active Directory, or NIS+
Support for Novell eDirectory (LDAP) actually consists of several realms: a base LDAP realm and LDAP realms specific to the exteNd application server, WebLogic, and WebSphere. The base LDAP realm and the user-defined persistence provider realm are intended for use with application servers (such as Tomcat) that do not provide an authentication API.
Non-LDAP realms can be readable (read-only) or writable (read-write). Applications can have one or two non-LDAP realms. In the case of an application with two realms, one realm is readable and the other writable. In contrast, an LDAP realm must be writable and the only realm used by the application.
In addition to authentication, the Directory subsystem API provides the means to add, modify, and delete users and groups. The Directory subsystem provides these services to the other subsystems, relieving them of having to know about server-specific APIs. This allows Director applications to be portable across repositories, application servers and platforms.
For more information about the Directory subsystem, see:
The purpose of the Security subsystem is authorization, the process of restricting access to application resources. The Security subsystem is built on top of the standard J2EE security API. It is designed to be extremely flexible and extensible.
The Security subsystem depends on the Directory subsystem for authentication. In other words, the Security subsystem assumes that requests for application resources can only be made by authenticated users.
In a Director application, authorization is performed by verifying that a principal (an authenticated user or group) has sufficient permission to perform the operation requested. The Security subsystem uses the following types of authorization:
The Locksmith user has complete access to all Director application and ACL subsystem objects, regardless of specified access to the individual objects.
When you first configure your project, the Locksmith is set to Anonymous by default; this allows any user to access a secure server to redeploy the project.
For production deployment, you should change the Locksmith user to a user known to exist in your authentication realm.
For instructions on changing the Locksmith user, see the section on reconfiguring your Director EAR in the Core Development Guide.
ACL-based authorization implements programmatic security, as defined in J2EE:
You can define your own ACLs in your Director application to protect elements that persist for the lifetime of the application server.
Director implements ACL-based authorization in three of its own subsystems:
The Security subsystem uses ACLs to define subsystem administrators, including its own administrator. The PAC provides the means to interactively manage subsystem administrators.
The Content Management subsystem uses ACLs to manage access to directory entries (folders, categories, and documents). It provides a classic example of how ACLs can be used in Web applications. The PMC provides the means to interactively manage CM security.
The Portal subsystem uses ACLs to manage access to group page elements. The PAC provides the means to interactively control Portal security.
For more information about ACL-based authorization, see:
The section on managing content security in the Content Management Guide
Role-based authorization implements declarative security, as defined in J2EE:
In Director, role-based authorization protects application objects that are part of the resource set and thus replaced each time the application is deployed—such as components, PID pages, styles, layouts, themes, rules, and workflow items. You define security roles by editing an XML descriptor in exteNd Workbench.
For more information about role-based authorization, see
Role-Based Authorization.
Director uses standard J2EE security to protect deployable modules such as EARs, WARs, and EJBs.
Although ACL-based and/or role-based authorization is sufficient to express most security conditions, some Director customers have modified the security manager to use the rules engine to provide even greater flexibility. In this case, the security manager fires a rule to check for access control.
For example, the following rule verifies a number of variables (such as database queries, user profiles, Web Services, and so forth) to make its decision and takes actions beyond authorizing or denying access (such as logging, requiring more information, redirecting, and so forth):
If "User belongs to group" Admin AND "Today is" Monday-Friday Then Authorize Access Else Deny Access AND Log Unauthorized Access - Context -
NOTE: Rule-based authorization can be very resource-intensive and should be used only when a very high level of flexibility and a very dynamic access control system are needed.
For more information about rules, see the Rules Guide.
The purpose of the User subsystem is the profiling of Web application users. It allows your Director application to obtain, store, retrieve, act upon, and analyze user profiling information. You can add, modify, and delete profiles in your application code.
Profiles are persistent collections of data associated with individual users. The information in a profile can be supplied by users or collected by your application.
Typically, profiles are used for two general purposes:
Other Director subsystems, such as Workflow and Content Management, rely on the information in the user profile to determine what content can or should be delivered to a given user or what operations can be performed.
For example, in a retail business, a profile for a customer could contain:
Account information such as shipping and billing address, e-mail address, age, gender, occupation, credit card information, and so on
Feature and page layout preferences other than those provided by the Portal subsystem
Login history, pages viewed, links and buttons clicked, and transactions made (items bought and processes started)
How profiles are stored depends on how the application's authentication realm(s) are configured in the Directory subsystem:
In applications that do not use an LDAP realm, a database is needed to store profile information. Director uses the JDBC persistence provider to access the database. For example, a Director application running on an exteNd Application Server typically stores its profiles in a database that has been added to the server configuration. Some applications use the server's own deployment database for this purpose.
In applications that include an LDAP realm, profile information is stored within the LDAP directory. Director uses the JNDI persistence provider to access the directory.
For more information about user profiles, see:
Attributes are individual data items within a profile. Each attribute corresponds to a column or field in database terminology.
Attributes can be any data that you want to associate with a user. There are two kinds of attributes:
For more information about attributes, see:
In applications that do not include an LDAP realm, you can:
Use a different schema. You can provide an alternative database schema and replace the default implementation with one that accommodates the new schema.
Use a different persistence provider mechanism. The Persistence Provider API provides a very generic interface that allows you to write a custom persistence manager for any data store not already supported by Director. For example, if you want to store user profiles in a database of your own design, you can write a persistence manager for it.
Through a number of custom tags, a JSP developer can leverage the user-related services easily without having to make Java API calls directly. The Framework custom tags allow you to manage groups and users (add, list, and remove users; add users to groups; set passwords), retrieve user profile information for personalization, log users in and out, and test whether a user is logged in.
For more information, see the chapter on the Framework tag library in the Core Development Guide.
While default implementations of all Director services are provided, the user-related services can easily be configured or customized to adapt to a specific infrastructure. Through the delegate model and Director's loosely coupled subsystems architecture, you can tailor the behavior of the user-related services to fit your needs.
The Security and User subsystems' default implementations for non-LDAP realms require a database to store persistent information. The schema creation and initial data load are handled by the Framework subsystem's bootstrap mechanism: the boot servlet inspects the subsystem configuration information to determine whether it needs to create the schema and load data. This way you can customize initialization to fit specific requirements, such as using a different set of default users, groups, and user profiles, or a different table structure.
|
|
User Management Guide |
Copyright © 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.