|
|
User Management Guide |
This chapter is an overview of authentication realms and how the Directory subsystem allows Director to integrate with the Director database and third-party authentication mechanisms. It has these sections:
For background information about the Directory subsystem and other user services in Director, see
About User-Related Services.
For information about setting up a realm, see
Configuring Authentication Realms.
Authentication is the process of verifying the identity of a user who is requesting access to protected resources. Authentication is typically performed by obtaining a user name and password and checking them against the list of users in your authentication realm. Typically, authentication is performed by your application server through either an internal server realm or an external realm like Windows NT or LDAP. The Directory subsystem also includes an API to add, modify, and delete users and groups.
The Directory subsystem provides these services to the other Director subsystems, relieving them of having to know about the application server-specific APIs available for authentication.
JAAS The JAAS (Java Authentication and Authorization Services), now part of the J2EE 1.3 specification, is used in applications to authenticate users and enforce access controls—but is not currently implemented by all application servers that Director supports. The Directory subsystem will leverage JAAS when available for the authentication process. Since JAAS does not provide APIs to manage principals (users and groups), the Directory subsystem enhances the application framework by providing a common API for managing them.
A Director application can be configured with one of these access types:
In a writable realm, administrators can use the Directory subsystem to add, delete, and modify user and group entries.
A writable realm is useful when you want to allow anonymous users to "register" or "create accounts" for themselves. For example, Internet sites often allow users to register and set up personalization.
In a readable realm, the Directory subsystem cannot add new users or groups nor modify existing ones.
A readable realm is useful when you want to control the users and groups that can access an application. For example, intranets often use a central administration application to manage all users and groups.
Director provides a set of pluggable realms for various application server vendors. A pluggable realm is set up to access a specific realm implementation, and can be configured using the Portal Project Wizard (See Configuring Authentication Realms). There are three basic type of pluggable realms that Director supplies::
This section summarizes Director's pluggable realm implementations for application server native realms and LDAP servers.
This realm is for the exteNd application server, which has providers for several readable realms as well as the SilverUsers readable/writable realm defined in the SilverMaster database (LDAP, Windows NT, and NIS+).
The Director EbiSilverServerRealm interface provides access methods to the SilverServer realm API.
This realm exists for compatibility with ePortal 2.x directory services or any application that requires nested groups. It uses a set of database tables for user and group bindings. It also uses the exteNd application server realm's SilverUsers directory as its user repository.
This realm is for BEA WebLogic 6.x. It calls the underlying server API to provide readable access to external realms (LDAP and Windows NT) and readable/writable access to the default realm stored in the file system on the application server.
The Director EbiWebLogicRealm interface provides access methods to the WebLogic server realm API.
This realm is for IBM WebSphere 4.x. Director accesses data through a custom registry based on a relational database to provide directory services. (IBM WebSphere does not provide a realm access API other than authentication.) All method calls go through the Director database.
For authentication, the Director EbiWebSphereRealm interface calls the WebSphere authentication method, which in turn calls through to the database.
This is a generic realm that can be used to access users and groups directly from the Director database using the Directory subsystem API. It does not rely on any native application server APIs.
For writable LDAP realms, Director provides:
Ageneric base class that implements the Java Naming Service Interface (JNDI). JNDI is the standard way in Java to access an LDAP realm hierarchy.
Aderived class for each supported J2EE application server to authenticate users using a Novell eDirectory LDAP realm.
The JNDI realm base class provides an administrator connection to the LDAP server for retrieving groups and users. This connection is internal, so unauthorized external access to data is prevented. A user's JNDI connection is stored as part of the user session when the user is authenticated through the realm.
Authentication to an LDAP application server realm The base class only supports generic LDAP authentication and does not provide authentication through an application server. This is provided by a separate class for each application server (see the diagram above). The application server realm overrides the authenticate() method in the JNDI realm super class and uses the application server API for authentication.
The Directory subsystem provides API access to your configured realms and realm contents. It includes these interfaces:
This code shows how to access a directory delegate and call the authUserPassword() method.
EbiDirectoryDelegate dirService = com.sssw.fw.directory.client.EboFactory.getDirectoryDelegate();
java.security.Principal prin = null;
try {
// Attempt to authenticate the user id and password
prin = dirService.authUserPassword(context, uid, pwd);
} catch (Exception ex) {}
The Director core components include a generic interactive login page for authentication users. You can use it as a template for developing your own login mechanism.
This component requires users to provide a user ID and password in order to be authenticated by the server for a specified realm.
For information about accessing the source, see the PortalLogin component in Samples.
The Director core components also include a page that allows anonymous users to add themselves to the writable realm and automatically creates a profile for each new user.
The New User component is provided as a template for your own application. You can copy and customize the New User component or design a new one.
For more information, see
Using the New User component.
You can access users and groups using the Portal Administration Console (PAC), as described in Using the Directory Section of the PAC. The PAC uses the Directory subsystem API to access realm users. The source files for the PAC are included with your exteNd Director installation at:
installDir/exteNdDirector/samples/src/com/sssw/portal/pac
You can implement your own realm to directly access a directory server—or you can rely on an existing database structure. You can create a custom security realm by implementing these interfaces in the com.sssw.fw.directory.api package:
|
|
User Management Guide |
Copyright © 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.
