Administration Application Installation
|
 |
 |
|
|
 |
 |
This section describes how to configure a metadirectory to extract user data from your user repository (for example, an LDAP server, an Active Directory, a database server, or NT Domain directory) and import that data into the policy database. As a result, the user, group and attribute data (referred to simply as attributes) are available and synchronized, and can be used to enforce dynamic security policies in your applications through the ASI Authorization and ASI Role Mapping services.
This section covers the following topics:
BEA WebLogic Enterprise Security requires that all policy data be stored in either an Oracle or Sybase policy database. The goal of a metadirectory is to provide your organization with a unified view of all identity information. A metadirectory solves important business issues that result from having information stored in multiple, disparate data repositories throughout an organization. Thus, through the use of a metadirectory, the maintenance cost of sharing information is reduced and the accuracy and the overall security of an application is improved (see Figure 6-1).
Figure 6-1 Metadirectory Architecture
In BEA WebLogic Enterprise Security, the term directory applies to any collection of user data, stored in a database, LDAP directory server, or other type of repository. These directories form the core of any identity management solution because every user repository has its own approach to the storage of information.
An identity directory refers to any user repository configured for use with BEA WebLogic Enterprise Security. In the Administration Console, the identity directory defines a logical collection of users, groups and attributes that can be used to design your authorization and role mapping policy, and store information about who is authorized through your policies. An identity directory typically represents groups of users of a particular application or resource, users in a specific location, or users imported from an external user repository.
A metadirectory can be used to store attributes replicated and synchronized from your user repository into the policy database. Following replication, the user data are available as attributes through the Administration Console identity directories for use in your authorization policies and policy rules. Any changes that you make to the replicated user attributes using the Administration Console are not propagated back to your user repository.
To configure metadirectories, you use several different components (see Figure 6-2). In Figure 6-2, each task is represented by a number that is positioned next to the component that you use to perform the task.
Figure 6-2 Metadirectory Configuration Components
Table 6-1 summarizes the tasks and links each task to a circled number in Figure 6-2.
|
Note: This task is required only if you are using Sun ONE Active Directory as your user repository server. |
|
For detailed instructions on performing each of the tasks listed in Table 6-1, see the following sections:
Before you begin, you must install and start the RadiantOne Synchronization Services. RadiantOne Synchronization Services use the JDBC and Java Message Service (JMS) features of the WebLogic Server that hosts the WebLogic Enterprise Security Administration Application to update the metadirectory. The RadiantOne Synchronization Services tool provides connectors for the master identity repositories that send XML formatted messages whenever information in an user repository is updated. Through the use of the JMS, this tool ensures that all updates are delivered and processed. For installation instructions, see Installing the RadiantOne Synchronization Services.
The RadiantOne Synchronization Services software is available as separate installation CD-ROMs (see install kit disks 3 and 4). After you install the product, you can access the applications from the Start>Programs>RadiantOne menu.
To install the RadiantOne Synchronization software:
Note: A second installation package is available for installing the RadiantOne Connectors. These are included in the RadiantOne Synchronization Services install package and do not need to be installed separately. However, you can install the connector package separately on another machine. For instructions for installing the connectors separately, refer to the RadiantOne Synchronization Services installation documentation. When you install the RadiantOne software, the online documentation is installed in the RadiantOne directory
This section covers the tasks that you must perform to create destination tables in the WebLogic Enterprise Security policy database and install triggers on those tables.
To configure metadirectory tables and database triggers, perform the following tasks:
There are two tables that you have to create in the policy database for the synchronization of users and groups to work properly: ASI_USERS and ASI_GROUPS. After you create these tables, you configure them through the WebLogic Enterprise Security Administration Console. You must create these tables before you perform the remaining tasks in this section.
The following sections provide guidelines and restrictions for the tables and detailed instructions on how to create them:
Two table are required in the policy database for the synchronization of user repositories: ASI_USERS and ASI_GROUPS. The following sections provide guidelines and restrictions for these tables:
The user synchronization table is used by the partner tool to stage user and user attribute information for import into the policy database. The name of the table used for user synchronization is configurable.
While the names of the columns in the table are configurable, the following restrictions apply:
The user synchronization table accommodates source repositories that store group memberships as user attributes. Managing group memberships as user attributes does not impact managing group memberships explicitly through the group synchronization table—both ways can be used.
You must adhere the following restrictions and requirements when setting up group memberships through the user synchronization table:
varchar2).Any number of columns in the user synchronization table may be used for passing attributes into the WebLogic Enterprise Security Administration Server. The columns used for all attributes in the User Synchronization table must be of variable length character (for example, in Oracle: varchar2). For purposes of importing from the user synchronization table, you may map attributes to any of the following WebLogic Enterprise Security policy data types: string, integer, boolean, date, time, dayofweek_type, month_type, and object_type. Attributes are also defined as either list or single. Multiple attribute values of type list are stored as a delimited text string. The delimiter used for attributes of type list must be the same as the delimiter used for groups.
In addition to the user-attribute-based group membership discussed above, group memberships may also be defined by using the group synchronization table. Unlike the User Synchronization table, the schema for the group synchronization table is fixed, that is, it must adhere to the structure shown in Table 6-2.
You must adhere the following restrictions and requirements when setting up the group synchronization table:
The following requirements and restrictions apply to user and group attributes
varchar2 column-size limit for the database.To create the ASI_USERS and ASI_GROUPS destination tables using an Oracle or a Sybase database server,
sqlplususername/password@asi
where: username and password are the username and password you defined when you created the database user account and asi is the database instance name.
SQL> CREATE TABLE ASI_USERS(DisplayName VARCHAR(255) NULL,
COMMONDOMAIN VARCHAR(255) NOT NULL, PRIMARY KEY (COMMONDOMAIN))
SQL> CREATE TABLE ASI_GROUPS(CN VARCHAR(255) NOT NULL,
UNIQUEMEMBER VARCHAR(255) NOT NULL, PRIMARY KEY
(CN,UNIQUEMEMBER))
Note: In addition to DisplayName, you can add more columns to the destination tables to be used as user attributes, such as street address, zip code, email, phone, and so on.
To connect to the RadiantOne Synchronization Services to the WebLogic Enterprise Security asiDomain, you must use the WebLogic Server Administration Console to configure a JDBC connection Pool and the Java Message Service (JMS).
To configure the JDBC connection pool and JMS, perform the following steps:
https://hostname:7010/console, hostname in the name of the machine that is hosting the WebLogic Enterprise Security Administration Application
7010 is the port on which the Administration Console is running
You must configure database triggers for the user and group synchronization tables in the policy database. A database trigger provides a necessary link between the metadirectory database and the policy database. A trigger enables the user attributes to be received by the Administration Server and put into the identity directory (that you define) whenever a change occurs in the underlying metadirectory database.
Note: Any modifications that you make to the existing data records in the synchronization tables must be made with an UPDATE command, not through a series of DELETE and INSERT commands. Use INSERT only for new records and DELETE only for removing records. Also, do not use the "truncate table" command to clean either the user or group synchronization tables because that command does not activate the triggers.
To configure metadirectory database triggers, perform the following steps:
https://hostname:7010/asi, hostname is the name of the machine that is hosting the WebLogic Enterprise Security Administration Application
7010 is port on which the Administration Console is running
user id to the WebLogic Enterprise Security schema owner, which is the same as the database account username. Set the identity directory name field to any directory name that is unique in the asiDomain. This identity directory is the directory in the policy database into which users are populated. Set the COMMONDOMAIN and DISPLAYNAME parameters as shown in Figure 6-3.Figure 6-3 Metadirectory Triggers Configuration
BEA WebLogic Enterprise Security uses a comprehensive schema for tracking and updating all policy data. You use RadiantOne Synchronization Services to configure the schemas required to to upload user and groups information from the user repository to the policy database.
To configure the required metadirectory schemas, perform following tasks:
This section describes how to extract the source schemas for the user repository.
To extract the source schemas from the user repository, perform the following steps:
On Windows: click Start>Programs>RadiantOne>RadiantOne Synchronization Services> Synchronization Services Administrator.
On Sun Solaris: From the RadiantOne/r1syncsvcs/bin directory, run: runSSC.sh.
asi_host.amer.bea.com and the port number is 56763.Figure 6-4 LDAP Schema Extractor Page
Figure 6-5 Sun ONE Server Console
Figure 6-6 RadiantOne Select Objects Page
groupOfUniqeNames and inetOrgPerson object classes and click Next. The Save windows is displayed (see Figure 6-7).Figure 6-7 RadiantOne Select Object Save Window
.orx filename extension as shown in Figure 6-7, and click Save. A "Schema Extraction Completed" message dialog box is displayed.This section describes how to load the source schemas for the user repository.
To load the source schemas from the user repository, perform the following steps:
Figure 6-8 RadiantOne Synchronization Object Candidates Page
asi56763.orx) and click Open. The Schema File field is populated with the filename, including the path.Figure 6-9 Synchronization Select Objects Page
This section describes how to extract the policy database destination schemas for the database server.
To extract the destination schemas from the database server, perform the following steps:
Figure 6-10 Database Schema Extractor Page
Note: If the connection fails, make sure that all the database server parameters are set correctly.
Figure 6-11 Table List Dialog Box
Note: Be sure to save the filename in lowercase. Also, the filename cannot contain any periods (for example, this filename is correct: asi5.orx).
This section describes how to load the policy database destination schemas for the database server.
To load the destination schemas from the database server, perform the following steps:
Figure 6-12 RadiantOne Synchronization Object Candidates Page
asi5.orx) and click Open. The Schema File field is populated with the filename, including the path.Figure 6-13 Synchronization Select Objects Page (Database Server Objects)
This section describes how to configure the RadiantOne topology that serves to link the source user repository to the policy database. The topology shows all of the objects involved in the synchronization process and the data flow. You use the topology to define and connect all of the data objects that are involved in a particular synchronization process.
To configure the topology, perform the following steps:
groupOfUniqueNames node and drag and drop it into the right pane.groupOfUniqueNames and initOrgPerson) and drag it to the red dot of the subscribing object. The tool draws lines connecting to the objects and labels them Transformation1 an Transformation2 (see Figure 6-14).This section describes how to configure the RadiantOne topology transformation scripts. These scripts determine how the source data in the user repository is transformed before it is written to the policy database.
Note: The RadiantOne Synchronization Services tool is capable of very sophisticated transformations, including creating a unified identity from multiple sources. The transformation scripting language is Java. If you want to explore more sophisticated transformations or merging of identity data, refer to the RadiantOne documentation available in the RadiantOne installation directory.
The BEA WebLogic Enterprise Security product ships with sample user and group transformation scripts. They are located at BEA_Home\wles42-admin\examples\r1syncservice. The file names are asi_users.djava and asi_groups.djava. The samples are dynamic java scripts that are compiled and run by the RadiantOne Synchronization Services as part of its transformation runtime. The following procedure uses the asi_groups.djava sample script.
To configure the topology transformation scripts, perform the following steps:
Figure 6-15 Topology Script for Transformation1
COMMONDOMAIN and DISPLAYNAME attributes to uid and cn respectively as shown in Figure 6-15, click Apply, and click Ok.This section describes how to use the transformation topology to upload the user and group data from the source user repository to the policy database.
Note: This task serves to test all that all the configuration tasks you have performed up to this point have been performed correctly and that you can proceed to the next section, Configuring Metadirectory Synchronization, and perform the synchronization tasks. If the upload fails, check the previous tasks to ensure that they were performed correctly. Also, verify that you used the correct passwords in each of the previous configuration tasks.
To upload the user and group data, perform the following steps:
Figure 6-16 Upload Topology Page
Figure 6-17 Topology Uploading Page
This section describes how to configure the metadirectory components for automatic updates to the policy database whenever changes are made to the user repository.
The RadiantOne Synchronization Services provides connectors and a synchronization hub that work together to synchronize data between various data sources. Connectors interface with the data sources. Data flows to and from the connectors asynchronously in the form of XML messages. All messages flow through the synchronization hub, which is a server that transforms the messages and routes them to the connectors that are subscribed to the changes. The BEA WebLogic JMS messaging broker manages the topics and provides guaranteed message delivery.
The role of the connectors is two fold. First, the connectors capture changes in the data source, translate the changes into a common XML format, and send them to the synchronization hub through the messaging server. Secondly, the connectors receive XML messages, translate them, and apply the changes to the data source.
To configure metadirectory synchronization, perform the following tasks:
To configure the synchronization hub, set the parameters in the RadiantOne_Home\r1syncsvcs\rlicon.ini file to match the settings on the WebLogic Server. The require settings are shown in Listing 6-1. This information is used by the RadiantOne Synchronization Services tool to contact the JMS server running on the WebLogic Enterprise Security Administration Server.
Listing 6-1 Synchronization Hub Settings
...
[BEA]
JMS SERVER NAME=RLI_JMS_SERVER
JNDI CLASS NAME=weblogic.jndi.WLInitialContextFactory
CONNECTION FACTORY NAME=weblogic.asiAdminServer.jms.TopicConnectionFactory
URL=t3://localhost:7000
USER_NAME=system
USER_PASSWORD=weblogic
Msg Time-To-Live=3600000
RETRY PERIOD=12
MAXIMUM ATTEMPTS = 11
Note: This task is necessary only if you are using the Sun ONE Directory Server for your user repository. If you are using another type of user repository server, such as Active Directory, Windows NT, or a database, skip this section and go Configuring the Policy Database Connectors. For more information on LDAP connector configuration requirements and procedures, see the RadiantOne Synchronization Services Guide located in the RadiantOne installation directory.
If you are using the Sun ONE Directory Server, you must configure the directory connector for so that changes to the user repository are automatically updated in the policy database.
To configure the directory connector, perform the following steps:
admin User ID. Figure 6-18 Directory Server Replication Page
Note: If you are using an LDAP server other than iPlanet or you do not want to use the iPlanet changelog, Radiant Synchronization Services also has a polling connector. For information on configuring the other LDAP connectors, refer to the RadiantOne online documentation located in the RadiantOne installation directory.
To configure the policy database connector, perform the following steps:
Figure 6-19 ASI_USERS Destination Configuration Page
Note: If the database object that the connector is listening to changes or is modified (for example, one of the data types changes or you add or remove columns), you can reconfigure the connector by right-clicking on the database object in the topology, and then choosing Configure. A note is displayed on the Login Info tab that specifies how the connector is configured. Enter the user and password information and, on the Initialization tab, reconfigure the connector by either Applying the Script or Saving and executing it later.
To start the Synchronization Hub, perform the following steps:
Note: You can also use the Start Hub icon on the Deployment Tab to start the hub.
To start the source and destination connectors, perform the following steps:
Note: The Synchronization Hub must be running before you start the connectors.
To start the Synchronization Hub, perform the following steps:
Note: You cannot modify the topology when you open it using the Deployment tab. To modify a topology you must open it using the Topology tab.
Figure 6-20 Connectors - Topology Page
Note: The connectors can also be started and stopped by clicking the Start Connector and Stop Connectors icons under the Deployment tab.
This section describes how to verify that metadirectory synchronization is properly configured such that changes to user and group entries in the user repository are reflected in the policy database.
To verify that metadirectory synchronization is properly configured, perform the following steps:
|
|
|
