JP2001325132A - Directory register and computer readable recording medium recording program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent the specification omission of an object class of an information object provided by directory service and the setting omission of attribute data. SOLUTION: A directory register for registering an information object provided by directory service is provided with a storage means 9 for storing a data sort required to be set up in each sort of information objects, information object sort acquiring means 8a to 8c for acquiring the sort of the information object to be registered and a setting aiding means 10 for aiding the setting of a data sort required to be set up in the information object to be registered by referring to the storage means 9 on the basis of the information object sort acquired by the means 8a to 8c.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a directory registration apparatus for registering object information in a tree-structured database called a directory information tree in a directory service, and a computer-readable recording medium recording a program.

[0002]

2. Description of the Related Art A directory service stores information objects (hereinafter, referred to as "entries") such as "individuals" and "organizations" in a tree-structured database called a directory information tree, and stores keys such as names and organization names. Is a client / server type service for reading and writing attributes (hereinafter, referred to as "attributes") such as telephone numbers and addresses included in entries.

FIG. 6 is a diagram showing an example of a directory structure in a directory information tree.

In this directory information tree 1, an entry 1b for an organization unit name "marketing" is a sub-element of the entry 1a for the organization name "ABC Corp."
And an entry 1c for the organization unit name "sales".

Here, the entry 1b for the organization unit name "marketing" is "local name (l)", "telephone number (Tel
No) ", and data" Tokyo "and" 03-1234-5678 "are set in the respective attributes.

The entry 1c for the organization unit name "sales" has attributes of "local name" and "telephone number".
o "and" 03-8765-4321 ".

As a sub-element of the entry 1b for the organization name unit name “marketing”, a general name “www-se
device entry 1d for "rver" and the generic name "ftp-se"
There is a device entry 1e for "rver".

Here, the device entry 1d for the general name “www-server” is “local name”, “serial number” (serial number).
No) ", and data" Tokyo "and" 0001 "are set in the respective attributes. Also, the device entry 1e for the general name "ftp-server" has attributes of "local name" and "serial number", and each attribute has "Toky".
o "and" 0002 "are set.

Further, as a sub-element of the entry 1c for the organization unit name “sales”, the general name “Jim Smit
There is a person entry 1f for "h".

Here, the person entry 1f for the general name "Jim Smith" has attributes of "local name", "telephone number", and "description", and "Tokyo", "03-" 8765-400
0 "and" General Manager ".

FIG. 7 is a diagram showing an example of providing a directory service, in which LDAP (Lightweight Directory Acquisition) is used for communication (access protocol) between a server and a client.
cessProtocol).

When using the directory service, a directory administrator 3a operating the client 3
In accordance with the instruction from, an operation of adding / deleting an entry to the directory information tree 2a in the directory server 2 and an operation of updating the contents are required. As a technique relating to such a registration operation, for example, there is the following method.

(A) Method using a data exchange file (b) Method using a maintenance tool attached to a directory server (c) Means using a directory access protocol In the case of (a), for example, LDIF (LDAP Data Interc
Hange Format) format is widely used.

FIG. 8 is a diagram showing the operation of the directory server 2 in the LDIF format. The information of the directory entry is mediated by a text file 4 describing the identification name (DN), object class, and attribute of the directory entry. Exchange.

The directory server 2 has an LDIF interface 2b for converting an LDIF format file 4 into directory data.

The directory administrator 3a imports / exports data (values) from the directory server 2 using the file 4, and adds, updates, and deletes directory entries.

Since the LDIF format file 4 is a kind of text file, the directory administrator 3a edits the file 4 with an editor or the like and loads the edited LDIF format file 4 into the directory server 2, thereby obtaining a directory information tree. 2a can be registered. This method is easy to operate and convenient when registering a large number of entries at once. However, since it is necessary to describe the object classes and attributes that constitute the entries in a file one by one, it takes time and effort If you want to register an entry, the procedure may be complicated.

FIG. 2B shows a method of using the management function of the directory server 2 itself.

FIG. 9 is a diagram showing the operation of the directory server 2 by the management function of the server body.

Normally, the directory server 2 has a management program for configuring the server itself, and includes a maintenance tool 2c for changing the directory information tree 2a. These programs and tools can be remotely operated from a console connected to the server 2 or from Web (http) or telnet. This method is interactive, so it is not suitable for a large number of changes, but has the advantage of making directory changes easier.

FIG. 4C shows a case where the directory information tree 2a in the directory server 2 is directly changed from the directory client by using the directory access protocol.

FIG. 10 is a diagram showing an operation of the directory server 2 by the directory access protocol. Examples of the operation include addition, deletion, and change of an entry by LDAP. Although this method uses the directory access protocol inherent in the directory server 2, there is an advantage that it is not necessary to provide a special management application on the server 2 side.
An application for operating an entry using an access protocol is required on the DP client 5 side.

Here, as an example, a case will be described in which a “device” entry is created by an LDIF format file using a Device object class. The Device object class includes the following as attributes. Whether the attribute is required or optional is determined by ITU (In
It is generally defined by technical standards such as ternational telecommunication union recommendations.

"Required" attribute commonName (common name) "Optional" attribute description (description) localityName (local name, abbreviation l) organizationName (organization name, abbreviation o) organizationalUnitName (organization unit name, abbreviation ou) owner seeAlso (reference) serialNumber (serial number) An example in which an entry created using this Device object class is described in the LDIF format is as follows.

Dn: cn = www-server, ou = marketing, o = ABC Corp., c = JP objectclass: top objectclass: device cn: www-server description: WWW server of marketing division l: Tokyo ou: marketiog owner: cn = Taro Yamada, ou = marketing, o = ABC Corp., c = JP serialnumber: 0123 Of these, the “required” attribute commonName must be included in all entries, but the other “optional” attributes are directories It may or may not be present in the definition rules. Therefore, "any"
Regarding attributes, data may be set in one entry but not set in another entry.

[0026]

As described above, in the conventional directory service, data is set in the attribute of one entry even if the entry is of the same type, but the data is set in the attribute of the other entry. May not be set.

FIG. 11 is a diagram showing a specific example of the entry setting state. As described above, the "optional" attribute may or may not be present. Therefore, when two devices corresponding to, for example, www-server and FTP-server are described in the LDIF format, it is possible to change the types of attributes included in the entries 1d and 1e.

Changing the types of attributes included in entries of the same type in this way increases the degree of freedom in creating entries, but causes a problem when a large number of people and devices are comprehensively managed using a directory service. Becomes

For example, when asset management is performed using a directory service, a use of creating a list of devices owned by each organizational unit can be considered. In this case, ou, which is an attribute representing the organizational unit in the entry of the device, is necessary. However, if ou exists or does not exist depending on the device, confusion is caused.

For this reason, although ou is not an “essential” attribute in the specification of the directory, a rule for each department that always sets ou for all device entries is required for operation.

An ITU-T (International Telecommunication Un), which is one of the technical standards of the directory service,
X. of the ion-Telecommunication Standardization Sector). In the case of 500, “Collectiov” is used as an attribute that entries arranged under a certain entry have in common.
e attribute ". If this attribute is defined, the entry under that entry can have the specified attribute regardless of the object class definition. However, in this case, the entry can only have the designated attribute, but does not guarantee that data is set. If the object class of the entry already contains the attribute to be specified, it does not make sense to specify it in “Collective attribute”. For example, in the case of FIG. 11, it is meaningless to specify ou as “Collective attribute” of the device entry. This is because the device entry is generated from the device object class, and the device object class includes the attribute ou.

Further, the object class on which the entry is based can be freely specified. For example, in the device entry in the example shown in FIG. 11, if a person is added as the object class, the entry represents a person. It is possible to have attributes such as a telephone number and a user password to be used.

However, if the object class can be freely specified, an entry that does not have an attribute related to the object class that is not specified may be forgotten, and an entry that is originally required may not be specified.

Therefore, the specification of the object class (L
In the DIF format file, a line beginning with “objectclass:”) is required to specify the same type of object class when creating the same type of entry as in the case of the attribute.

As described above, when a plurality of entries of the same type are defined using the LDIF format file 4, an object class of the same type is specified in all the entries of the same type, and the attribute required for operation is Requires that data be set in all entries. When creating the LDIF format file 4, it is necessary to note them carefully.
It was very time-consuming.

A similar problem occurs when an entry is created using the maintenance tool 2c or the access protocol. In any case, the directory information tree 2a is operated using the directory management screen on the management console or the remote terminal.

FIG. 12 is a diagram showing an example of a directory creation screen for registering an entry at the management console or a remote terminal. FIG. 12A is a directory creation screen 6a for specifying the location (DN) of an entry and an object class, and FIG. 12B is for setting data of each attribute included in the specified object class. This is a directory creation screen 6b.

When creating an entry, the directory administrator 3a first specifies the position (DN) of the entry in the directory information tree 2a and the object class for which the entry is to be created (entry creation step 1). Is set for each attribute included in the file (entry creation step 2). If data is not set in the “required” attribute in the entry creation step 2, an error occurs. However, data may not be set for “arbitrary” attributes that are not “required” attributes.

Therefore, as in the case where the LDIF format file 4 is used, there is a problem that the attributes set by the entries are different.

The present invention has been made in view of the above-described circumstances, and when a directory entry is created,
It is an object of the present invention to provide a directory registration device that supports setting of data related to a predetermined type to prevent omission of setting of an object class and an attribute for each entry and a computer-readable recording medium that records a program. I do.

[0041]

Means taken to realize the present invention will be described below.

According to a first aspect of the present invention, in a directory registration apparatus for registering information objects provided by a directory service, a storage means for storing a data type required to be set for each type of information object; An information object type acquisition unit for acquiring a type, and a setting for referring to a storage unit based on the type of the information object acquired by the information object type acquisition unit and supporting setting of a data type required to be set in an information object to be registered A directory registration device having support means.

The types of data that need to be set include:
For example, there are various object classes and various attributes.

Further, the information object type obtaining means includes:
For example, an instruction from a client requesting registration or a type of an information object registered from a maintenance tool may be obtained, or a type of an information object registered from a data exchange file may be obtained.

As a setting support method by the setting support means, for example, a default value may be set or a screen for forcing the user to input may be displayed. In addition, a warning may be output when the setting has not been made.

According to the first aspect, the data to be set is reliably set for each entry, so that the object class can be prevented from being missed, and the data can be prevented from being missed for the attributes that need to be set in operation. It can improve the quality of directory services.

According to a second aspect of the present invention, in a directory registration apparatus for registering information objects provided by a directory service, storage means for storing, for each type of information object, a data type required to be set and a default value for this data type. Information object type obtaining means for obtaining the type of the information object to be registered; and storage means based on the type of the information object obtained by the information object type obtaining means. This is a directory registration device provided with setting support means for setting a corresponding default value when a data type is not set.

As a result, when the data to be set is not set, the default value is automatically set, the omission of the specification of the object class and the omission of the data of the attribute can be prevented, and the quality of the directory service is improved. be able to.

A third invention is a computer-readable recording medium recording a program for registering an information object provided by a directory service, wherein the computer stores data required to be set for each type of information object. A storage function for storing the type, an information object type acquisition function for acquiring the type of the registered information object, and a reference to the contents stored by the storage function based on the information object type acquired by the information object type acquisition function This is a computer-readable recording medium on which a program for realizing a setting support function for supporting setting of a data type required to be set in an information object to be registered is recorded.

A fourth invention is a computer-readable recording medium on which a program for registering information objects provided by a directory service is recorded. A storage function for storing the type and a default value for this data type, an information object type acquisition function for acquiring the type of the registered information object, and storage based on the information object type acquired by the information object type acquisition means A computer-readable recording of a program for realizing a setting support function that refers to the content stored by the function and sets a corresponding default value when a required data type is not set in the registered information object. Which is a recording medium.

The third and fourth inventions are directed to the first and second inventions.
A computer-readable storage medium storing a program for realizing the functions of the directory registration device described in the invention of the present invention by a computer.

By using a storage medium storing such a program, a computer such as a directory registration device or a directory server which does not have the above-described functions,
The above-described functions can be easily added to a computer system that provides a directory service.

[0053]

DESCRIPTION OF THE PREFERRED EMBODIMENTS In the present embodiment, a directory server having a directory registration function for supporting setting of required data will be described.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing a configuration example of the directory server according to the present embodiment.
The same parts as those described above are denoted by the same reference numerals and description thereof will be omitted.

The characteristic parts of the directory server 7 are mainly the entry type acquisition units 8a to 8c, the entry definition storage unit 9, and the entry default processing unit 10.

The entry type obtaining unit 8 a provided in the LDIF interface 12 obtains the type of the entry from the LDIF format file 11 and outputs the content to the entry default processing unit 10.

The entry type obtaining unit 8b provided in the access protocol interface 13 obtains the type of the entry from the operation content according to the access protocol,
The contents are output to the entry default processing unit 10.

The entry type obtaining unit 8c provided in the maintenance tool 14 obtains the type of the entry from the operation command of the tool, and outputs the content to the entry default processing unit 10.

The entry definition storage unit 9 stores an object class that needs to be specified for each entry type, an attribute that needs to be set, and a default value for each attribute that needs to be set in the entry definition data (hereinafter, “template”).
).

The entry default processing unit 10 is a part that supports setting, and when registering an entry (including changing and updating), based on the entry type and template input from the entry type obtaining units 8a to 8c, The object class of the entry and necessary attributes are set, and are passed to the entry processing unit 15.

The directory manager 3a registers an entry in the directory information tree 2a of the directory server 7 using the client 5 as a directory management terminal.

The directory server 7 and the client 5 are connected by a transmission medium 11. Client 5
For example, a PC for editing an LDIF format file, (offline), a WWW browser, a local console, or the like (online) can be considered. The transmission medium 11 is, for example, LDIF
Format files (offline), LANs (online) and the like are conceivable.

The LDIF interface 12 converts an LDIF format file and directory information tree data.

The access protocol interface 13 is an interface for accessing the directory information tree 2a using a directory access protocol such as LDAP.

The maintenance tool 14 is a program for managing the directory server 7 itself using a management terminal connected locally or remotely.

The schema stored in the schema storage unit 16 is a rule for forming the directory information tree 2a, and defines an object class and an attribute.

The entry processing unit 15 is a part for performing the same entry registration processing as usual, and generates and updates entries based on object classes and attributes.
Check the syntax against the schema or set the system default value. In a normal directory server, the output from the LDIF interface, access protocol interface, and maintenance tool is passed to the entry processing unit 15 as it is, and after the check, the output content is changed to the directory information tree 2.
a.

The operation of the directory server 7 having the above configuration will be described with reference to an example in which an LDIF format file is used.

For example, it is assumed that an LDIF format file 17 as shown in FIG.

Normally, the only parameter that qualifies an entry in LDIF is the object class.
In the IF format file 17, the keyword "#_entrytype" for specifying the type of the entry, which is a higher concept, is used.
_ ".

This keyword starts with “# (lines starting with # in LDIF indicate a comment and are ignored)” in order to maintain compatibility with ordinary LDIF, but the entry type acquisition unit 8 a of the LDIF interface 12 If "#_entrytype_" is found in the input LDIF format file 17, the following character string following ":" is handled as the entry type. The LDIF interface 12 passes an entry type to the entry default processing unit 10 in addition to a normal DN, an object class, and an attribute.

The entry default processing unit 10 reads information on an entry from the template using the entry type as a key.

FIG. 3 is a diagram showing a specific example of the template. In this template 18, for each entry type,
The object class that constitutes the entry, the attribute type that the entry always has, and the default value are stored.

The object class set in the template 18 is used in such a manner as to take a sum with the object class defined by the input LDIF. That is, in this example, since “device” is passed as the entry type, even if no object class is specified in LDIF,
It will have two object classes, "top" and "device".

If another object class other than "top" and "device" is specified in the LDIF, that object class also has that class.

FIG. 4 is a flowchart showing the processing contents of the entry default processing section 10.

The entry default processing unit 10 first reads an object class based on the entry type (s
1) Perform object class processing for setting default attributes for each object class (s)
2).

In this object class processing (s2), it is checked whether a default attribute is set for each object class.

First, it is checked whether an attribute is specified in the template 18 using the entry type and the object class as keys (s21). If there is no attribute to be processed, this object class processing ends. If there is an attribute to be processed, the attribute is read (s22), and a default value is set as attribute data (s23).

The above processing is sequentially performed, and when the processing has been completed for all the object classes, the processing is terminated (s3). In this example, "device" is passed as the entry type, so
Processing is performed for two object classes, “top” and “device”.

After the processing of the entry default processing unit 10 is completed, the entry processing unit 15 writes the value of each attribute in the directory information tree 2a based on the LDIF definition. At this time, if the attribute defined in the template 18 is also defined in the LDIF format file 17, the attribute is overwritten by the LDIF definition, but this operation is in accordance with the specification of the directory administrator 3a.

Next, a case where the maintenance tool 14 attached to the directory server 7 is used and a case where an entry is registered using a directory access protocol will be described.

FIG. 5 shows an example of a directory creation screen for registering entries using the maintenance tool 14 and the access protocol.

In the first step, a directory creation screen 19a for designating only the entry type and the entry position (DN) as shown in FIG. 5A is displayed. The directory administrator 3a selects an entry type from the list,
Specify the location of the entry. In this first step, it is not necessary to specify an object class.

When the process proceeds to the next step by designating the entry type and the entry position, the entry default processing unit 10 uses the entry type as a key to construct an entry from the template 18 as in the case of using the LDIF format file. Read the class and the default value of the attribute.

In the second step, a directory creation screen 19 as shown in FIG. 5B in which default values are set for the object class and some attributes.
b is displayed, and the user can change these default values as needed, or can use the default values as they are if there is no need to change them. Also, attributes for which no default value is set can be left blank.

After the setting is completed, the set data is checked by the entry processing unit 15 and stored in the directory information tree 2a.

As described above, the directory server 7 according to the present embodiment is provided with the entry default processing unit 10 that operates before the entry processing unit 15 when registering an entry.

The entry default processing unit 10 sets default values for object classes and attributes essential for setting based on the template 18.

Therefore, it is possible to prevent an object class required for defining an entry from being designated. Further, it is possible to prevent an attribute from being set as an “arbitrary” attribute according to a standard or the like, but which needs to be set for operation. Thereby, the quality of the directory service can be improved.

In the present embodiment, a case is described in which default values are set for object classes and attributes to be set. For example, when an object class or attribute to be set is not set, an error or Various methods for reliably setting data, such as outputting a warning, can be used.

The directory server 7 according to the present embodiment may change the arrangement of each component as long as the same operation and function can be realized, and may freely combine each component. . For example, the entry type obtaining unit may be combined with the entry default processing unit 10.

The functions and components of the directory server 7 according to the present embodiment include programs that can be executed by a computer, such as a magnetic disk (floppy (registered trademark) disk, hard disk, etc.) and an optical disk (CD). -ROM, DVD, etc.), and can be applied by writing to a recording medium such as a semiconductor memory or transmitted by a communication medium to a directory server, a computer, or a computer system.

A computer that realizes each of the above functions reads the program recorded on the recording medium, and executes the above-described processing by controlling the operation of the program.

[0096]

As described above, in the present invention,
Since data is surely set for the data type required for setting the information object to be registered, it is possible to prevent various elements of the information object from being unset. Therefore, a useful directory service for the user can be provided.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration example of a directory server according to an embodiment of the present invention.

FIG. 2 is an exemplary view showing an example of an LDIF format file used in the directory server according to the embodiment;

FIG. 3 is an exemplary view showing an example of a template used in the directory server according to the embodiment;

FIG. 4 is an exemplary flowchart showing processing contents of an entry default processing unit of the directory server according to the embodiment;

FIG. 5 is a view showing an example of a directory creation screen when an entry is registered by the directory server according to the embodiment using a maintenance tool or an access protocol.

FIG. 6 is a diagram showing an example of a directory structure in a directory information tree.

FIG. 7 illustrates an example of providing a directory service.

FIG. 8 is a diagram showing an operation of the directory server in the LDIF format.

FIG. 9 is a diagram showing an operation of the directory server by a management function of the server body.

FIG. 10 is a diagram showing an operation of a directory server according to a directory access protocol.

FIG. 11 is a diagram showing a specific example of an entry setting state.

FIG. 12 is a diagram showing an example of a directory creation screen for registering an entry on a management console or a remote terminal.

[Explanation of symbols]

 2a: Directory information tree 1a to 1f: Entry 2: Directory server 2b: LDIF interface 2c, 14: Maintenance tool 3: Client 3a: Directory administrator 5: LDAP client 6a, 6b, 19a, 19b: Directory creation screen 7: Directory Servers 8a to 8c Entry type acquisition unit 9 Entry definition storage unit 10 Entry default processing unit 11 Transmission medium 12 LDIF interface 13 Access protocol interface 15 Entry processing unit 16 Schema storage unit 17 LDIF format file 18 …template

Claims (4)

[Claims] 1. A directory registration device for registering an information object provided by a directory service, comprising: a storage unit for storing a data type required for setting for each type of information object; and a type of the information object to be registered. Information object type obtaining means; setting support for referring to the storage means based on the type of the information object obtained by the information object type obtaining means and supporting setting of a data type required to be set in the registered information object A directory registration device comprising: 2. A directory registration device for registering information objects provided by a directory service, comprising: a storage unit for storing, for each type of information object, a data type required to be set and a default value for the data type; Information object type obtaining means for obtaining the type of the information object to be read; and data necessary for setting in the registered information object by referring to the storage means based on the type of the information object obtained by the information object type obtaining means. A directory registration device comprising: a setting support unit that sets a corresponding default value when a type is not set. 3. A computer-readable recording medium recording a program for registering an information object provided by a directory service, wherein the computer stores a data type required for setting for each type of information object. A storage function, an information object type acquisition function for acquiring a type of the registered information object, and a content stored by the storage function based on the type of the information object acquired by the information object type acquisition function, A computer-readable recording medium recording a program for realizing a setting support function for supporting setting of a data type required to be set in the registered information object. 4. A computer-readable recording medium on which a program for registering an information object provided by a directory service is recorded. The computer stores, for each type of information object, a data type required to be set and this data type. A storage function for storing a default value for the type, an information object type obtaining function for obtaining the type of the registered information object, and a storing function based on the type of the information object obtained by the information object type obtaining means. A computer readable program which records a program for realizing a setting support function for referring to stored contents and setting a corresponding default value when a required data type is not set in the registered information object. Do recording medium.