JPH11195026A - Directory server and information managing method used for the same - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a server which can retrieve registration information having recognized attribute information as one piece of information while plural types of information are contained in shorter time. SOLUTION: The server 2 is provided with a data base 3 storing directory information. A storage means 12 storing attribute definition information defining the array of element information in attribute information contained in directory information, a registration means 5 dividing attribute information contained in a transferred update request based on attribute definition information and registering them in the data base 3, and a retrieval means 6 dividing attribute information contained in the transferred retrieval request into element information based on attribute definition information, designating them as retrieval objects and permitting the data base 3 to execute retrieval are provided.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a directory server connected to another information processing apparatus via a network and providing a directory service.

[0002]

2. Description of the Related Art PCs (Personal Computers), WSs and the like via a network such as a LAN (Local Area Network).
An e-mail system for transmitting and receiving a document created by an information processing device such as a (Work Station) has been widely used. In an electronic mail system, an identifier unique to each user called a mail address is used as destination information.

[0003] In order to allow a user to easily check the mail address of a partner, X.T. Directory services such as 500 (ISO9594) are provided.

X. In a directory service conforming to 500, registration information is hierarchically managed in a tree structure. Directory entries are arranged at locations corresponding to the branches and leaves of the tree. Each entry has a name (dn:
Distinguished Name). In the entry, in addition to the user's e-mail address, various information such as a first and last name, a telephone number, a FAX number, and a photograph can be set as attribute information. Also, a plurality of attribute information of the same type can be set in one entry.

[0005] X. 500 employs a client-server type distributed system architecture, and uses OSI (Open Systems Interconn.) As a communication protocol between information processing apparatuses that play the role of client and server.
Section), a DAP (Directory
Access Protocol).

On the other hand, IETF (Internet Engineering T)
ask Force) is an LDAP (Lightweight Director) as a client-server protocol over TCP / IP.
y Access Protocol). With LDAP, a user can access a directory server from an application program on a client via a network such as a LAN and search for desired information such as a mail address.

FIG. 17 shows the structure of a typical access request defined in LDAP. In the figure,
ASN. Specified in ISO8824. 1 (Abstract Syn
taxNotation One).

In FIG. 17, a search request (Search) 30
Is a request for searching a directory entry, a setting addition request (Add) 31 is a request for adding an entry, and a setting change request (Modify) 32 is a request for changing attribute information in an entry. In addition to the requests shown in FIG. 17, various access requests such as a request to bind a connection (Bind) and a request to disconnect a connection (Unbind) are defined.

[0009] Of the parameters of the search request (Search) 30, "baseObject" is dn representing the highest entry of the subtree as a search range.

[0010] "scope" is used to specify the range up to and including the entry specified by "baseObject". The search target range is “baseObject” that specifies only the specified entry, and “singleLeve” that targets the directly lower entry group of the specified entry.
l ", select from" wholeSubtree "for all entry groups below the specified entry.

"Filter" is a parameter for specifying a search condition. In "filter", it is possible to specify a full-match search and a partial-match search with each attribute value, and it is also possible to specify a compound search in which a plurality of conditions are combined by a logical sum, a logical product, or the like.

"Attributes" is a parameter for designating attribute information to be extracted from entry information that matches search conditions.

Upon receiving the access request shown in FIG. 17 issued by the client, the directory server corresponding to LDAP accesses the database storing the information of each directory entry. When the access request is the search request 30, the database searches for and extracts an entry that matches the specified condition, and returns it to the client. On the other hand, if the access request is an update request (Add31, Modif
If it is y32, the directory information on the database is updated and the result is returned to the client.

By the way, some recent large-scale information systems within a company or between companies allow a directory server to be used to centrally manage various resources in the system. In this information system, not only the user's first and last name and e-mail address but also various other information are managed by the directory server, so that the operation and management of the administrator can be reduced.

In this information system, for example, there is a system in which access control information that defines access authority to various resources such as documents and services is managed by a directory server. Usually, one piece of access control information is composed of a combination of a plurality of types of information such as identification information of a user who accesses the resource and access right information such as read permission and write permission.

In order to enable each resource to be shared by a plurality of users, the access control information is stored and stored as an access control list (hereinafter, referred to as an ACL) in which a plurality of access right information can be set for each resource. It is common to manage.

As described above, X. The directory service conforming to 500 can manage various information on each resource as attribute information in an entry. However, in the directory service, each piece of attribute information is managed as a continuous information string, and attribute information composed of a plurality of types of information is not involved in the information structure at all.

FIG. 18 shows an example of the syntax of access control information managed by the directory service. The access control information includes, as element information, a directory name (dn) 39 of a user accessing the resource, a read authority 41 indicating whether the resource can be read, and a write authority 42 indicating whether the resource can be written. Have. Each element information 39,4
A separator character 40 (# in the figure) representing a delimiter is inserted between 1 and 42. In addition, each authority information 41 and 42
Means that reading or writing is allowed ″
1 "is set, and" 0 "is set when not permitted.

FIG. 19 shows an AC managed by a directory server using a relational database management system (hereinafter, RDBMS) as a database.
The example of the management form of L is shown. In the figure, 22 is a table for managing each entry information of ACL, 24 is a column (column) for managing an ID for uniquely identifying each record (row) inside, and 25 is a uniquely identifying each entry. A column for managing a directory name to be accessed, and a column 26 for managing an acl attribute which is access control information. A plurality of acl attributes can be set for one directory name. For example, in FIG. 19, dn25 is "cn = sales report, ou = Sales, o = ABC, c = J
The resource “P” has two pieces of access control information (ID2
4, the acl attribute values 26) of “1” and “2” are registered.

FIGS. 20 and 21 show an operation example when the conventional directory server receives the LDAP search request from the client 1 and accesses the RDBM 3 for managing the information shown in FIG. In the figure, an attribute search unit 8
Is a functional element of a conventional directory server.

In FIG. 20, the search request 33 issued by the client 1 is “dn =“ cn = sales report, ou = Sale ”
For entries where s, o = ABC, c = JP "," cn = Tanaka, ou =
Judge whether access control information related to the user name Sales, o = ABC, c = JP ″ is included, and if so, extract the acl attribute value. ” Upon receiving the request 33, the search unit 8 of the server sets the RD
An SQL statement 34 for causing the BMS 3 to perform a search is assembled. Specifically, first, the search request 33 “baseObjec
t ”and“ scope ”parameters, the SQL statement 34
WHERE clause character string "dn =" cn = sales report, ou = Sales, o = AB
C, c = JP "", and then a character string "acl LIKE" cn = Tanaka, ou = Sales, o for performing a partial match search with the acl column 26 based on the "filter" parameter. = ABC, c
= JP #% ″ ″ is created. Here, "%" represents a wildcard character. Next, the attribute search unit 8 sets the assembled SQL
The statement 34 is issued to the RDBMS 3 to perform a search, and the search result is returned to the client 1.

In FIG. 21, the search request 36 issued by the client 1 is “dn =“ ou = Sales, o = ABC, c = J
Of the group of entries immediately below the entry that is P ″, ″ cn =
A user named Sato, ou = Sales, o = ABC, c = JP "searches for an entry of a resource permitted to be read, and extracts dn of the entry."
Upon receiving the request 36, the attribute search unit 8 of the server
An SQL statement 37 for causing the MS 3 to perform a search is assembled. Specifically, first, "dn LIKE"%, ou = Sales, o = ABC, c = JP "" of the WHERE clause of the SQL statement 37 is created based on the "baseObject" and "scope" parameters of the request 36. Then, based on the "filter" parameter, a character string "acl LIKE" for performing a partial match search with the acl column 26 is performed.
Create "cn = Sato, ou = Sales, o = ABC, c = JP # 1 #%"". Next, the attribute search unit 8 issues the assembled SQL statement 37 to the RDBMS 3 to perform a search. The search result is returned to the client 1.

[0023]

The above-described conventional directory service recognizes and manages one piece of attribute information as a continuous character string or numerical value, and has no relation to the structure of each piece of attribute information. . For this reason, as in the case of the access control information, the attribute information composed of a combination of a plurality of types of information is managed as a continuous information sequence in which a plurality of types of element information are simply connected as shown in FIG.

However, according to this management method, when performing the search shown in FIGS. 20 and 21, it is necessary to execute a partial match search of the character string in the RDBMS 3. In the partial match search of a character string, for example, since a process of detecting a match by sliding the character string is repeatedly performed, the time required for the search is lengthened, and the quality of service is reduced.

Therefore, an object of the present invention is to manage attribute information that is recognized as one piece of information while including a plurality of types of information, such as access control information, so that the information search can be performed in a shorter time. Directory
To provide a server.

[0026]

In order to achieve the above object, the present invention defines an array of element information in attribute information included in directory information in a directory server provided with a database for storing directory information. A storage unit for storing attribute definition information, the attribute information included in the passed update request is divided into element information based on the attribute definition information, and each of the divided element information is designated as a registration target; Registration means for performing registration in the database, and dividing attribute information included in the passed search request into element information based on the attribute definition information, specifying the divided element information as a search target, and searching the database. And a search means for performing a search.

According to such a directory server, by defining the structure of the attribute information by the attribute definition information, each element information in the attribute information can be divided and stored and managed. In the search of the attribute information, the attribute information specified as the search condition is divided into each element information, and the element information is specified as the search target, so that it is possible to perform a search by a full match search in the database. . As a result, the number of times of performing the partial match search is reduced as compared with the conventional example, and the search can be performed in a shorter time.

[0028]

Embodiments of the present invention will be described below with reference to the drawings. In all the drawings including the conventional example, the same elements are denoted by the same reference numerals.

FIG. 1 is a block diagram showing a functional configuration of the directory server 2 according to the embodiment of the present invention. The directory server 2 is connected to an information processing device such as the client 1 via a network 14 such as a LAN. Here, communication based on the LDAP communication protocol is performed between the client 1 and the directory server 2.

The directory server 2 includes an RDBMS (relational database management system) 3 for storing directory information including attribute information, a communication control unit 13 for performing communication processing with the client 1, and an access request for directory information. A directory management unit 4 for analyzing the contents, an attribute definition information storage unit 12 for storing attribute definition information defining an array structure of element information in the attribute information, and an attribute definition unit 1 for managing the attribute definition information
1. Structured attribute control unit 9 for processing an access request to attribute information defined by attribute definition information (hereinafter, referred to as structured attribute information), and attribute information not defined by attribute definition information It has an unstructured attribute control unit 10 for processing access requests (hereinafter referred to as unstructured attribute information).

The unstructured attribute control unit 10 comprises an unstructured attribute registration unit 7 for processing an update request and an unstructured attribute search unit 8 for processing a search request. Further, the structured attribute control unit 9 includes a structured attribute registration unit 5 that processes an update request, and a structured attribute search unit 6 that processes a search request.

In the present embodiment, all applications that make a request to the directory management unit 4, such as applications on the client 1, recognize one piece of attribute information as a single continuous information string.

FIG. 2 shows a system configuration of the directory server 2 of the present embodiment. As shown in the figure, the directory server 2 includes a central processing unit (CPU) 15, a magnetic disk 17 such as a hard disk device, a main memory 16, a bus 18, a display 19, a keyboard 20, and a pointing device 21 such as a mouse. .

The magnetic disk 17 stores directory entry information 22 and attribute definition information 12 managed by the RDBMS 3 as files.

The main memory 16 stores the communication control program 1
3, directory management program 4, unstructured attribute registration program 7, unstructured attribute search program 8, structured attribute registration program 5, structured attribute search program 6,
An RDBMS control program 23 for processing SQL and an attribute definition program 11 are stored. These programs are stored on a magnetic disk 17 and stored in a main memory 16.
After that, the program is executed by the CPU 15.

An outline of the operation of the directory server 2 will be described.

The operation manager registers attribute definition information using the attribute definition unit 11. With the attribute definition information, the attribute information recognized as one piece of information by the application can be divided and managed as a plurality of pieces of element information.

The LDAP request sent from the client 1 to the directory server 2 is received by the communication control unit 13 and sent to the directory management unit 4. The directory management unit 4 determines whether the attribute information in the passed request includes the structured attribute information defined by the attribute definition information 12 and the type of the request (search, registration, or deletion). According to the result, request information is sent to the structured attribute control unit 9 or the unstructured attribute control unit 10 to request processing. The structured attribute control unit 9 and the unstructured attribute control unit 10 determine the S corresponding to the management form of the RDBMS 3 from the passed request information.
Create a QL sentence and send it to RDBMS3. This gives R
In the DBMS 3, entry information is searched, registered, and deleted. Then, the processing result is stored in the directory management unit 4.
And returned to the client 1 via the communication control unit 13.

When registering the attribute information, the structured attribute control unit 9 divides the structured attribute information in the passed LDAP request into element information using the attribute definition information 12, and Is created as independent registration information and sent to the RDBMS3. As a result, FIG.
As shown in (1), one piece of attribute information is divided and stored in individual areas.

When performing a search, the structured attribute control unit 9
The structured attribute information in the passed LDAP request is divided into element information by using the attribute definition information 12, and an SQL statement is created in which the divided element information is an independent search target.
Send to MS3. As a result, the RDBMS 3 can perform a high-speed entry search by an all-match search. Then, the structured attribute control unit 9 is passed from the RDBMS 3 the requested part of the searched entry, and in a case of a plurality of entries, concatenates them in a predetermined format and returns them to the directory management unit 4.

FIG. 3 shows an example of the structure of directory information managed by the RDBMS 3. It should be noted that FIG.
2 shows an example of managing information having the same contents as the conventional example shown in FIG.

The RDBMS 3 stores and manages attribute information in a table format including rows and columns. The structured attribute information defined by the attribute definition information is divided into element information with a separator character as a boundary, and stored in individual columns. For example, the attribute information having the structure shown in FIG.
After being divided at 0 ("#"), the user name 39 becomes acl
_user column 27, read authority 41 is acl_read column 2
8. The write authority 42 is stored in the acl_write column 29, respectively.

In the directory information, one or more sets of unstructured attribute information and unstructured attribute information can be set in each entry. In the example of FIG. 18, dn25 is the unstructured attribute information. Alternatively, a telephone number, a FAX number, a mail address, and the like may be set as unstructured attribute information. Also, structured attribute information other than ACL can be set as a set. For example, a mail address may be added as structured attribute information.

Here, an example of an outline of the operation of the structured attribute search unit 6 will be described with reference to FIGS. FIGS. 4 and 5 show a case where a request having the same contents as in FIGS. 20 and 21 of the conventional example is received, respectively.

In FIG. 4, when the server 2 receives the LDAP search request 33, the structured attribute search unit 6
An SQL statement 35 suitable for the management form of S3 is assembled. Specifically, first, the request 33 “baseObject” and “sc”
"d" in the WHERE clause of the SQL statement 35 based on the "ope" parameter
n = ”cn = sales report, ou = Sales, o = ABC, c = JP”. ”Then, based on the attribute definition information,“ filter ”of the request 33
Attribute information in parameters is divided and acl_user column 2
"Acl_user =" cn = Tanaka, ou = Sale of the same element part as 7
Create s, o = ABC, c = JP ″ ″. Further, the structured attribute search unit 6 sets “acl_
Create user, acl_read, acl_write "and use SQL statement 3
Assemble 5. Then, the created SQL statement 35 is
Issue to BMS3.

The RDBMS 3 that has received the SQL statement 35 first performs an all-match search on the dn and acl_user in the SQL statement 35 with the dn column 25 and the acl_user column 27, respectively, and finds the acl_user column 27 and ac of the matched entry.
The registration information of the l_read column 28 and the acl_write column 29 is extracted, and the structured attribute search unit 6 is extracted as a search result.
Return to. Then, these search results are connected by inserting a separator character “#” in the structured attribute search unit 6 and then returned to the client 1 as acl information.

In FIG. 5, upon receiving the LDAP request 36 issued by the client 1, the structured attribute search unit 6 of the server 2 executes an SQL statement 38 suitable for the management form of the RDBMS 3.
Assemble. Specifically, first, the request 36 “baseOb
SQL statement 3 based on the "ject" and "scope" parameters
″ Dn LIKE ″%, ou = Sales, o = ABC, c = J in WHERE clause 8
P "" is created, and then the structured attribute in the "filter" parameter is split and "acl_user"
user = ″ cn = Sato, ou = Sales, o = ABC, c = JP ″ ″ and acl_r
After creating “acl_read = 1” corresponding to the ead column 28, the conditions are connected by “and”. Next, the structured attribute search unit 6 creates the SQL statement 38 by assembling the created information and issues it to the RDBMS 3.

The RDBMS 3 receiving the SQL statement 38 firstly stores the acl_user and acl_read in the SQL statement 38 into the acl_user column 27 and the acl_read column 28, respectively.
, A partial match search is performed in the dn column 25, and the registration information in the dn column 25 of the matched entry is extracted and returned to the structured attribute search unit 6 as a search result. This search result is returned to the client 1 as dn.

As described above, in the present embodiment, since the structured attribute information can be searched for all matches, the number of partial match searches can be reduced, and the responsiveness to a search request can be improved.

Next, a method of registering the attribute definition information in the attribute definition section 11 will be described.

FIG. 6 is an example of a screen display used for registering the attribute definition information. The attribute definition section (attribute definition program) 11 displays on the display 19, the keyboard 2
It has a function of controlling an input by 0 or the mouse 21 or the like.
The operation manager or the like operates the display 1 on which the display of FIG.
By setting information on the screen 9 using the keyboard 20 and the mouse 21, attribute definition information can be registered.

The display screen 43 shown in FIG. 6 has an area 44 for inputting the name of the attribute information to be defined, an area 45 for inputting the syntax of the structure of the attribute information, an area 46 for inputting a separator character, and registering the input information. Button 4 to do
7 and a button 48 for canceling the input information.

FIG. 7 shows the information structure of the attribute definition information storage unit 12. The attribute definition information storage unit 12 has an area 49 for storing attribute names and an area 50 for storing separator characters.
And an area 51 for storing each element name after dividing the syntax of the structured attribute. here,
The area 51 can store a plurality of element names.

When the operation manager requests the setting of the attribute definition information, the attribute definition unit 11 first displays the screen 43 of FIG. The operation manager uses the keyboard 20 to input a character string in the attribute name input area 44, the syntax input area 45, and the separator input area 46 on the screen 43, and clicks the OK button 47 with the mouse 21. In response to this, the attribute definition unit 11 registers the character strings input to the attribute name input area 44 and the separator input area 46 in the attribute name storage area 49 and the separator storage area 50 of the attribute definition information 12, respectively. The character string input to the tax input area 45 is divided by the separator character input to the separator input area 46, and each is registered in the element storage area 51. For example, when the input shown in FIG. 6 is made, “acl” is stored in the attribute name storage area 49 of the attribute definition information storage unit 12 and “
# "," Acl_user "," acl_rea "in the element storage area 51
d ”and“ acl_write ”are registered.

The operation procedure of each unit of the server 2 in response to an access request will be described below.

FIG. 8 is a flowchart showing the protocol analysis operation of the directory management unit (directory management program) 4. 8, when the request sent from the client 1 is received by the communication control unit 13 (S130)
1) The directory management unit 4 analyzes the contents of the request (S1302), and checks whether or not the request includes attribute information defined as structured attribute information (S1303). This confirmation is performed by checking each attribute name included in the request and each attribute name 4 stored in the attribute definition information storage unit 12.
9 is checked. That is, when the attribute name is registered in the attribute definition information storage unit 12, the attribute is recognized as structured attribute information, and when the attribute name is not registered, it is recognized as unstructured attribute information.

If all the requested attribute information is unstructured attribute information in S1303, the protocol analysis unit 4 checks whether the received request is a search request (S1304), and the protocol analysis unit 4 shown in FIG. Search request (Search)
If it is 30, the processing is performed by the unstructured attribute search unit 8 (FIG. 1).
0) is requested (S1305). On the other hand, if the received request is an update request such as a setting addition request (Add) 31, a change request (Modify) 32, etc., it requests the unstructured attribute registration unit 7 to perform processing (FIG. 9) (S1306).

In S1303, if the received request includes structured attribute information,
Checks whether the received request is a search request (S1307), and if it is a search request, requests the structured attribute search unit 6 to perform processing (FIG. 12) (S1308). On the other hand, if the received request is an update request, the request is made to the structured attribute registration unit 5 for processing (FIG. 11) (S1309).

Next, the operation procedure of the unstructured attribute control unit 10 will be described with reference to FIGS. In addition,
The unstructured attribute control unit 10 recognizes the specified attribute information as a single piece of information and registers, changes, and searches for the information, as in the conventional example.

FIG. 9 is a flowchart showing the operation of the unstructured attribute registration unit 7. Upon receiving the update request from the directory management unit 4, the unstructured attribute registration unit 7 first checks the type of the update request (addition setting, deletion, update) (S
1401 and S1404). If the update request is an addition setting request (Add31), an SQL statement (INSERT) is assembled based on the dn and attribute information of the entry to be added, and RD
It is issued to BMS3 (S1402). On the other hand, when the update request is a delete request (Delete), an SQL statement (DELETE) is assembled based on the dn of the entry to be deleted, and the RDBM is created.
It is issued to S3 (S1405). If the update request is a change request (Modify 32), an SQL statement (UPDATE) is assembled based on the dn and attribute information of the entry to be changed and issued to the RDBMS 3 (S1406). And
After the processing of the RDBMS 3, the unstructured attribute registration unit 7
Via the directory management unit 4 and the communication control unit 13,
The processing result is notified to the client 1 (S1403).

FIG. 10 is a flowchart showing the operation of the unstructured attribute search unit 8. Upon receiving a search request from the directory management unit 4, the unstructured attribute search unit 8 first
"BaseObject", "scop" of the search request (Search) 30
e, an SQL statement (SELECT) is assembled based on the values of parameters such as "filter" and "attributes" (S1501,
S1502), issue to RDBMS3 (S150)
3). For example, in the case of the search request 33 in FIG.
The sentence 34 is assembled and issued to the RDBMS3. R
After the processing of the DBMS 3 is completed, the unstructured attribute search unit 8 returns the information of the entry that matches the condition as the processing result to the client 1 via the directory management unit 4 and the communication control unit 13 (S1504).

Next, the operation procedure of the structured attribute control unit 9 will be described with reference to FIGS.

FIG. 11 is a flowchart showing the operation of the structured attribute registration unit 5. The structured attribute registration unit 5 requested to process from the directory management unit 4 first checks the type of the received update request (S1601 and S160).
7). If the update request is an addition setting request (Add) 31, it is checked whether each attribute of the entry to be added is registered in the attribute definition information 12 as a structured attribute (S160).
2) In the case of structured attributes, attribute value division processing (FIG. 1)
4) is executed (S1603). After repeating these processes for each attribute information included in the request (S160
4), dn of the entry to be added, unstructured attribute information,
Using the element information of the structured attributes divided in S1603 and their definition information (FIG. 7), the SQL statement (IN
SERT) is assembled and issued to the RDBMS3 (S16)
05).

On the other hand, when the update request is a change request (Modify) 32
If it is determined that each attribute to be changed is registered in the attribute definition information storage unit 12 as a structured attribute (S16).
09), in the case of structured attributes, attribute value division processing (FIG. 1)
4) is executed (S1610). After these processes are repeated for each attribute information included in the request (S161
1) dn of the entry to be changed, unstructured attribute information,
An SQL statement (UPDATE) is assembled using each element information of the structured attribute information divided in S1610 and their definition information (FIG. 7) and issued to the RDBMS3 (S
1612). After the processing of the RDBMS 3, the structured attribute registration unit 5 notifies the client 1 of the processing result via the directory management unit 4 and the communication control unit 13 (S160).
6).

FIG. 12 is a flowchart showing the operation of the structured attribute search unit 6. The structured attribute search unit 6 requested to process from the directory management unit 4 firstly receives the “baseObject” and “scope” of the received search request (Search) 30.
After generating a condition for narrowing the search range from (S170)
1) Check whether each attribute information specified by the "filter" parameter is registered in the attribute definition information storage unit 12 as structured attribute information (S1702), and in the case of a structured attribute, divide the attribute information The processing (FIG. 14) is executed (S1703). After these processes are repeated for each attribute information included in the "filter" parameter (S170
4), an SQL statement (SELECT) is assembled based on the conditions generated in S1701, the unstructured attribute information, each element information of the structured attribute information divided in S1703, its definition information, the "attributes" parameter, and the like. , RDBMS3 (S1705). At this time, if the attribute specified by the "attributes" parameter is defined in the attribute definition information 12, an SQL statement is created so that all the element information (the element area 51 in FIG. 7) is extracted by the RDBMS 3. . For example, in the case of processing the search request 33 in FIG. 4, SQ specifying dn and acl_user as targets of an all-match search and specifying acl_user, acl_read, and acl_write as targets of extraction.
An L statement 35 is assembled and issued to the RDBMS3.

After the processing of the RDBMS 3, the structured attribute search unit 6 receives the information to be extracted, and checks whether the extracted information includes the element information defined by the attribute definition information 12 (S1706). In the case of the element information constituting the structured attribute information, the extracted element information is replaced with the separator character 50 set in the same attribute definition information 12.
(S1707). For example, in the examples of FIGS. 3 and 4, acl_user column 27, acl_read column 28, ac
l_write column 29 is extracted and acl column 2 in FIG.
The attribute information is converted into a series of attribute information such as “6”. After these processes are repeated for each attribute included in the "attributes" parameter (S1708), the information of the entry that matches the condition is returned to the client 1 as the processing result via the directory management unit 4 and the communication control unit 13. (S
1709).

FIG. 13 shows a configuration of a work area on the memory 16 used for the division processing and the combination processing of the structured attribute information. In the figure, the work area 52 stores the structured attribute information before and after the combination and the work area 53 stores the element information of the structured attribute information before and after the division.

FIG. 14 is a flowchart showing the operation of the structured attribute control section 9 relating to the structured attribute dividing process.
In the structured attribute division process, the structured attribute registration unit 5 and the structured attribute search unit 6 first store attribute information to be divided in the work area 52, and then extract one character (S18).
01), it is determined whether the character is equal to the character registered in the separator storage area 50 of the attribute definition information 12 (S180).
2). If the extracted character is not a separator character string, the extracted character is stored in the work area 5 indicated by the write pointer.
3 and the write pointer is moved by one character (S1804). Then, the process shifts to S1801.
Similar processing is performed for the next character in the work area 52.
If the extracted character is equal to the separator character string in S1802, the write pointer of the work area 53 is moved to the next array area in order to save (determine) the character string stored in the work area 53 as one piece of element information. It is moved (S1805). Then, the processing shifts to S1801, and the same processing is performed for the next character in the work area 52. After the above processing is repeated until a character (a null character or the like) indicating the end of the character string is found (S1803), the processing ends.

FIG. 15 is a flowchart showing the operation of the structured attribute search unit 6 relating to the structured attribute combining process (S1707). First, the structured attribute search unit 6 sets the RDBM
After storing the plurality of element information extracted in S3 in the work area 53, the first character string is copied to the work area 52 (S1901). Next, the separator storage area 50 of the attribute definition information 12 is added to the end of the character string stored in the work area 52.
Are linked (S1903), and S1901 is linked.
Then, the same processing is performed for the next character string in the work area 53. After the above processing is repeated for all the character strings in the work area 53 (S1902), the processing ends.

As described above, according to this embodiment, the attribute information whose structure is defined by the attribute definition information is stored and managed by dividing the attribute information to be registered and searched for each element information. It is possible to perform a full match search of the attribute information, and it is possible to improve the response performance as compared with the conventional example. In particular, in a network having a very large number of terminals, such as a corporate network, the amount of information registered in the directory server becomes enormous, so that the effect of applying this embodiment is great.

By the way, in updating the attribute information, there is a need for a partial change in which only the value of a part of the element information constituting the attribute information is to be changed. For example, in the access control information shown in FIG. 18, there is a request to change only the write authority 42 without changing the value already set in the read authority 41.

In the conventional directory service, attribute information is simply managed as a continuous information sequence. Therefore, when making the above partial changes, the application:
Once the target attribute information (acl 26) is obtained from the server 2 using the search request (Search 30), the write authority 42 in the obtained attribute information is changed, and the changed attribute information is transmitted to the setting change request. It is necessary to take a complicated procedure such as re-registering using (Modify 32).

Further, the general directory service does not have a mutual exclusion function at the time of multiple access, that is, a lock function for preventing other applications from accessing the accessed information. For this reason,
For example, immediately after an application that intends to make a partial change obtains the attribute information (acl 26) from the server 2, another application may update the same attribute information. In this case, there is a possibility that an application that intends to perform a partial change overwrites the previous value without knowing the update of the attribute information to be partially changed, which may hinder system operation.

In the present embodiment, in order to solve these problems, the structure attribute information can be partially changed by one request from the client 1. Specifically, the element information of the non-changed part in the partial change is designated by a wild card character (for example, “*”), and the information that has already been set is left as it is.

FIG. 16 shows an operation example of this embodiment relating to the partial change. In FIG. 16, the partial update request 54 issued by the client 1 to the server 2 is “cn = Tanaka registered in the entry whose dn is“ cn = sales report, ou = Sales, o = ABC, c = JP ””. , Ou = Sales, o = ABC, c = JP ”to“ 1 ”. Here, the arrangement of “*” in the partial update request 54 indicates element information that is not changed.

The structured attribute registration unit 5 of the server 2 receiving the request 54 assembles the SQL statement 55. Specifically, first, based on the “object” parameter of the request 54,
"Dn =" cn = sales report, ou = Sal in WHERE clause of SQL statement 55
es, o = ABC, c = JP ″ ″, and then the request 54 ″ typ
"ac" in the SET clause based on the "e" and "values" parameters
l_write = 1 ”and“ acl_user = ”cn = Sa to be added to the WHERE clause
Create to, ou = Sales, o = ABC, c = JP ″ ″. next,
The structured attribute registration unit 5 issues an SQL statement 55 obtained by assembling the created information to the RDBMS 3, and returns a processing result to the client 1.

By this processing, the RDBMS3 shown in FIG.
In the record where the above ID 24 is "1", acl_write
Only the setting in column 29 is changed to "1". "Acl_read" column 28 specified by wildcard characters
Will not be changed.

As described above, according to the present embodiment, the partial change of the structured attribute information can be performed by one request from the client 1, so that the performance at the time of the update request is improved and the reliability of the directory information is improved. Improvements are possible.

In the above embodiment, access control information has been described as an example of structured attribute information. However, according to the present invention, similar effects can be obtained for attribute information having a structure other than the access control information.

In the present embodiment, the RDBMS 3 is used as a database for managing entry information.
The present invention is also applicable to a directory service using another database management system such as an object-oriented database management system.

In the present embodiment, LDAP is exemplified as the communication protocol. However, the present invention can be applied to a directory service using another communication protocol such as DAP.

[0082]

As described above, according to the present invention, when managing attribute information that is recognized as one piece of information while including a plurality of types of information, such as access control information, for example, It is possible to provide a directory server capable of performing a search in a shorter time.

[Brief description of the drawings]

FIG. 1 is a directory server 2 according to an embodiment of the present invention.
FIG. 3 is a functional configuration diagram of FIG.

FIG. 2 is a system configuration diagram of a directory server 2.

FIG. 3 is a diagram showing a storage structure of directory information in an RDBMS3.

FIG. 4 is an explanatory diagram showing an attribute information access operation mode (1).

FIG. 5 is an explanatory diagram showing a mode (2) of an access operation of attribute information.

FIG. 6 is a diagram showing an example of a screen display at the time of attribute definition for attribute information.

FIG. 7 is a diagram showing a data structure of attribute definition information 12.

FIG. 8 is a diagram illustrating an operation related to protocol analysis of a directory management unit.

FIG. 9 is a diagram illustrating an operation of an unstructured attribute registration unit 7;

FIG. 10 is a diagram illustrating an operation of an unstructured attribute search unit 8;

FIG. 11 is a diagram illustrating an operation of a structured attribute registration unit 5;

FIG. 12 is a diagram illustrating an operation of a structured attribute search unit 6.

FIG. 13 is a diagram illustrating a configuration of a work area used for a division process and a combination process of structured attribute information.

FIG. 14 is a diagram illustrating an operation related to a division process of structured attribute information.

FIG. 15 is a diagram illustrating an operation related to a joining process of structured attribute information.

FIG. 16 is an explanatory diagram showing a mode (3) of an access operation of attribute information.

FIG. 17 is a diagram illustrating a configuration example of request information related to search and update defined by a communication protocol.

FIG. 18 is a diagram illustrating a syntax example of access control information.

FIG. 19 is a diagram showing a conventional storage structure of directory information.

FIG. 20 is an explanatory diagram showing a conventional attribute information access operation mode (1).

FIG. 21 is an explanatory diagram showing a conventional attribute information access operation mode (2).

[Explanation of symbols]

1 client, 2 directory server, 3 R
DBMS, 4 directory management unit, 5 structured attribute registration unit, 6 structured attribute search unit, 7 unstructured attribute registration unit, 8 unstructured attribute search unit, 11 attribute definition unit, 12
... attribute definition information recording unit, 13 ... communication control unit, 14 ... network, 15 ... CPU, 16 ... main memory, 17 ... magnetic disk, 18 ... bus, 19 ... display, 20 ... keyboard, 21 ... mouse.

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Yoko Hirashima 1099 Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture Inside System Development Laboratory, Hitachi, Ltd. 1 Semiconductor Company, Hitachi, Ltd. 6-81-cho, Hitachi Software Engineering Co., Ltd.

Claims (6)

[Claims] 1. A directory server having a database for storing directory information, a storage means for storing attribute definition information defining an array of element information in attribute information included in the directory information, and a passed update request Registration means for dividing the attribute information contained in the attribute information into element information based on the attribute definition information, designating each of the divided element information as an individual registration target, and registering the information in the database; Search means for dividing the attribute information included in the request into element information based on the attribute definition information, designating the divided element information as a search target, and causing the database to perform a search. directory·
server. 2. The directory server according to claim 1, wherein the attribute definition information stored in said storage means is inserted between information for identifying the type of attribute information and each element information in the attribute information. A directory server comprising: information indicating a separator character; and information for identifying a type of each element information. 3. The directory server according to claim 2, wherein said registration means and search means divide attribute information into respective element information on the basis of a separator character included in attribute definition information. ·server. 4. The directory server according to claim 1, wherein said registering means, when passed an update request designating a part of element information in the attribute information by a wild card, excluding said element information. A directory server for updating only the information specified by the update request. 5. The directory server according to claim 1, wherein the attribute information included in the passed update request is designated as a registration target, and registered in the database; A second search unit for designating attribute information included in the search target as the search target and causing the database to perform a search; and transmitting the request to the registration unit, the search unit, the second registration unit, and the second search. Which of the means to handle,
A directory server, comprising: management means for determining a request based on the content of the request and the attribute definition information and distributing the request. 6. An information management method used for a directory server having a database for storing directory information, wherein attribute definition information defining an array of element information in attribute information included in the directory information is stored and passed. The attribute information included in the update request is divided into element information based on the attribute definition information, each of the divided element information is designated as an individual registration target, registered in the database, and passed to the search request. An information management method, wherein the included attribute information is divided into element information based on the attribute definition information, the divided element information is designated as a search target, and the database is searched.