[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Overview of Policy Editor

Policy Editor allows you to define policies in the policy repository. It is a Java swing application that acts as an X11 application on Solaris. As a result, it complies with and provides complete X11 functionality.

Key Mapping

Figure 18 shows the keyboard modifier map and key map table that Policy Editor uses to convert event code into key symbols (keysyms) in X11.


Figure 18: Keyboard Modifier Map

You generate this map by entering the following command in UNIX:

xmodmap

To customize your keyboard, the key mapping can be changed with standard X11 utilities.

Nonroot Users

Nonroot operators can access Policy Editor. The home directory for nonroot operators stores operator customization and log files.

The files and directories in pom_install_dir are not changed when various operators use Policy Editor. Nonroot operators who want to use Policy Editor must have read/write permission on files and directories in pom_install_dir. The Policy Editor default installation gives read/write permission to all users (that is, user, group, and others). The operating system commands are used to restrict access as required.

When Policy Editor is started, the directory POM_USER_DIR, which is <$HOME>/.UMC/pom, is used. The <$HOME> variable is the user's home directory. The <$HOME> directory must exist. The .UMC/pom directory path is created if it does not exist.

There are two subdirectories in POM_USER_DIR:

Exception Handling for the Directory

If Policy Editor detects a problem, such as a connection loss, when it accesses the directory, it displays a dialog box that describes the LDAP problem. If such a problem occurs, you can back up modified data to a different directory or to a file, or you can ignore the changes and open a different data source. You must either open or cancel the current operation.

The open operation opens the Open Directory Server dialog box, allowing you to change the connection parameters if it is necessary to connect to another directory.

Typically, there is one primary directory in the main office of the service provider and various secondary directories in regional centers. The service provider synchronizes policies between the master directory and the slave directories. As a result, changes to policies in each of the directories are controlled and propagated to the other required directories.

Providing Data Security

Policy Editor implements data security through:

Simple authentication occurs when Policy Editor sends the fully qualified distinguished name (FQDN) of the client and the client's clear-text password to the directory.

The directory supports access control that defines and monitors different clients' access privileges on LDAP entries.

Working with Policy Data Files

Policy Editor does not support the reading of policy data files produced with earlier versions of the SDX software. This feature may work under some circumstances; for example, when Policy Editor is used in JUNOSe mode.

Multi-User and Multi-Instance Concurrence

Multiple operators with multiple instances can use Policy Editor simultaneously. Concurrence control manages different instances or different operators while they perform operations on the same policy object at the same time.

Concurrence control is transparent; that is, the system does not notify you of simultaneous changes to the same object. However, be aware that, if multiple operators work on the same objects at the same time, the object properties that one operator configures can be overwritten by another operator; that is, the system stores the second operation in the directory.

Table 15 shows various concurrence control scenarios. In this table both operation 1 and operation 2 are performed on the same object by two different operators or application instances. The commitment of operation 2 is later than that of operation 1.




Table 15: Concurrence Control Scenarios  
Operation 1
Operation 2
Changes in the Directory

Delete

Delete

The object is deleted from the directory.

Operation 2 is ignored.

Add

Add

The object created by operation 2 is stored in the directory.

Modify

Modify

The modification made by operation 2 is stored in the directory.

Delete

Modify

The modification made by operation 2 is stored in the directory.

The object is re-created.

Modify

Delete

The object is deleted from the directory.

For the scenario of delete/delete, the object is deleted from the directory at the commitment of operation 1. When the same request is received from operation 2, it is silently ignored. For all other operations, operation 2 (that is, the latest operation) always prevails.

The directory ensures consistency for each entry but not across multiple entries. See SRC-PE Integration Guide, Chapter 2, Overview of LDAP Integration.

In summary, the directory does not maintain consistency among objects. To maintain consistency, all operators must be in contact with each other and agree on what the final state of the data should be.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]