JP2000148698A - Distributed object security system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently realize usage limitation by functional units under a condition that strong security check, for example, the limitation on rewriting of information from the outside is not necessary without changing any existing system constitution. SOLUTION: A request level bridge 3 for connecting plural distributed object systems 1 and 2 is provided with usage limiting means (a substitute client 4 and a substitute object 5) by functional units. Then, the interfaces of the substitute object 5 to be placed at a using side (distributed object system 2) are not constituted of all the interfaces owned by an original object 7 but are limited only to those whose usage is permitted.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to the security technology of a distributed object system, and more particularly to the use of an object of a local distributed object system from an external distributed object system without requiring authentication or authority check. In a distributed object security system that is suitable for restricting an object by a function unit of an object.

[0002]

2. Description of the Related Art Conventionally, security in a distributed object system has been realized using a mechanism such as authentication or authorization. Note that authentication means that a user or an object proves its identity by presenting a secret key that only the user and the authentication server can know. Authorization means that a user or object whose identity has been
Check if you have permission to access the resource,
Access control.

In order to restrict the use of a certain distributed object by using security, it is necessary to register information in an authentication server, set and notify a secret key, set an authority, and the like. As described above, in the conventional technique, in order to restrict the use, the user must always be authenticated.
Even when it is sufficient to restrict use in a certain function unit, authentication / authority check is required.

For example, in a certain company, a database is constructed by a distributed object system for each department,
Conventional technology can also refer to information from other departments, but also wants to restrict rewriting of information from other departments. It is necessary to use a mechanism called authentication for each user, set the authority, and notify the secret key. In this case, it is necessary to update the authentication information every time a transfer between departments or the like occurs, which requires a great deal of time for management and maintenance.

[0005] For example, 224-22 of "Distributed Object Oriented Technology CORBA" by Hirofumi Onozawa (published by Soft Research Center, Inc. in 1996).
As described on page 9, ORB (Object Request Broke)
r) A technology for providing a security function to itself has been considered. However, in this technique, it is necessary to change the configuration of the distributed object system, and it is difficult to migrate from the existing distributed object system.

[0006]

The problems to be solved in the prior art are that, when a security function is provided in a distributed object system, it takes a great deal of time to manage and maintain authentication information, and the existing system configuration. Is necessary to be changed. It is an object of the present invention to solve the problems of the prior art and to restrict the use of functions in units that do not require strong security checks, such as restricting the rewriting of information from the outside. An object of the present invention is to provide a distributed object security system that can efficiently perform operations without any change.

[0007]

In order to achieve the above object, a distributed object security system according to the present invention includes a domain called a request level bridge (in a distributed object system, objects grouped by operation management methods and protocols). Of the interfaces (functions) provided by proxy objects used for transmitting requests between domains in a bridge that spans a set of By limiting to only the other domains,
Makes restricted functions invisible. As a result, the function of the original object that can be used from another domain can be limited without performing special authentication and checking of authority, that is, use restriction can be performed in units of function.

A request level bridge is provided with a means for automatically generating such a proxy object using interface repository information of an object to be disclosed to an external distributed object system and information describing a function of restricting use. Provide. Also, delete the information of the interface whose usage is to be restricted from the interface repository referenced by the user. In this case as well, the function for which the use of the object to be used is to be restricted becomes invisible from the use side.
It is possible to easily restrict the use of the object in functional units.

[0009]

Embodiments of the present invention will be described below in detail with reference to the drawings. FIGS. 1 and 2 are block diagrams showing first and second embodiments of the configuration according to the present invention of the distributed object security system of the present invention. 1 and 2, reference numerals 1 and 2 denote a distributed object system,
Reference numeral 3 denotes a request level bridge, and communication across the distributed object system 1 and the distributed object system 2 constituting different domains is realized via the request level bridge 3.

The request level bridge 3 is described in Hirofumi Onozawa, “Distributed Object Oriented Technology CO
RBA "(published by Soft Research Center, Inc., 1996), pp. 158-162, which connects a plurality of distributed object systems 1 and 2 and connects each of the connected distributed object systems. 1,2
The proxy object 4 of the distributed object system 2 where the client 6 receives a request from the client 6 to the object 7 in another distributed object system 1 is prepared.
This is a mechanism for relaying a request through a proxy object (hereinafter, referred to as a proxy client) 4 on the distributed object system 1 side of the request destination.

In the present embodiment, the interface implemented by the proxy object 5 provided by the request level bridge 3, that is, the function of the object 7 to be used (“Method (1) 7a” to “Me
function (4) 7d "), but rather the function whose use is to be restricted (function whose use is to be restricted) (" Metho
d (4) 7d ") (" Method (1)
7a "to" Method (3) 7c "), the function (" Method (4) 7d ") from the external distributed object system 2 for which use is to be restricted from the external distributed object system 2
Make it invisible. As a result, it is possible to realize a use restriction for each function without special authentication or authority check.

Hereinafter, the details will be described. Function Method of Object 7 in Distributed Object System 1
(1) 7a to Method (4) 7d, for example, M
The method (4) 7d is a data rewriting function. In consideration of data protection, it is assumed that the distributed object system 2 restricts the method (4) 7d from being used.

In this example, the request level bridge 3 is a proxy object 5 for receiving a request from the distributed object system 2 to the distributed object system 1, and a proxy for sending the request received by the proxy object 5 to the distributed object system 1 side. Client 4 is included.

The proxy object 5 has three functions Met
hod (1) 5a to Method (3) 5c are implemented. This function Method (1) 5a-Method
(3) 5c is a function of the object 7 (“Me
The request for the method (1) 7a to the method (3) 7c) is received by proxy, and processing for instructing the proxy client 4 to call a function corresponding to the request is performed. But M
In order to restrict the use of the method (4) 7d, the corresponding function is not implemented in the proxy object 5.

In such a configuration, the client 6
From, Method (1) which is a function of the object 7
The message flow when using 7a is 10 (“Call Method (1)”) as indicated by an arrow in FIG.
→ 11 → 12 → 13 → 14 → 15 (“Result of Method
(1) ”), and the function Metho
d (4) 7a can be used.

However, from the client 6, a method for restricting the use of the object 7, Method
(4) The message flow when using 7d is shown in FIG.
As shown by the arrow in the above, 21 ("Call Method
(4) ”) → 22 (“ No Implementation ”), and the function Method (4) 7d cannot be used from the client 6.

Next, the flow of the processing in FIGS. 1 and 2 will be described in detail with reference to FIG. FIG.
FIG. 3 is a flowchart showing a flow of processing when a function of an object in another domain is used from a client in one domain in the distributed object security system in FIGS. 1 and 2.

First, FIG. 1 will be described. In the case of FIG. 1, F of the function F in FIG. 3 is “Method (1)”.
Is shown. First, in the client 6, step 30
1 is performed, and the message flow 10 in FIG.
(Request of “Method (1)”) is issued. In response to this request, a determination process in the next step 302 is performed.

The proxy object 5 has a function Method
Since it has (1), it is determined as Yes, and the process proceeds to step 303 to instruct the proxy client 4 to call the function Method (1) of the object 7 (message flow 11). And step 304
, The proxy client 4 calls the function Method (1) of the object 7 (message flow 12).

The object 7 has a function Method
The processing result of (1) is returned to the proxy client 4 (message flow 13), and thereafter, from the proxy client 4 to the proxy object 5 (message flow 14), and from the proxy object 5 to the client 6 (message flow 15). And the result is conveyed.

Next, FIG. 2 will be described. In the case of FIG. 2, the F of the function F in FIG. 3 is “Method (4)”.
Is shown. First, in the client 6, step 30
1 is performed, and a request for using Method (4) is issued (message flow 21). Next, the determination processing in step 302 is performed.

The proxy object 5 has a function Method
Since it does not have (4), it is determined as No and step 305 is executed.
The function Method (4) returns to the client 6 a message indicating that it cannot be used (message flow 22). As a result, it is possible to restrict the use of the object 7 to the function Method (4) by clients in different domains.

Next, a technique for automatically generating the proxy object 5 used in the request level bridge 3 will be described with reference to FIGS. FIG. 4 is an explanatory diagram showing a format of information for designating a use restriction for each function of an object. As shown in FIG. 4A, the information for designating the use restriction is composed of two pieces of information: the name of the object having the function whose use is to be restricted and the function for restricting the use. It should be noted that a plurality of pieces of information on functions for restricting use can be described continuously.

FIG. 4B shows an example of information on the functions of an object B. This object B has three functions Method (1) to Method (3).
Two functions Me among the objects shown in this information 43
FIG. 4C shows a specific example of description of information in the format shown in FIG. 4A when the use of the method (2) and the method (3) is restricted. Note that, in the example of FIG. 1, the object 7 is Meth in FIG.
od (1) to Method (4) are described. For the proxy object 5, Method (4) in FIG.
d (4) is described.

The information shown in FIG. 4C and the information shown in FIG.
The proxy object (for example, FIGS. 1 and 2) is obtained from the information of the interface repository of the distributed object system (for example, the distributed object system 1 of FIGS. 1 and 2) to which the target object (for example, the object 7 of FIGS. Proxy object 5) can be automatically generated. The interface repository is a mechanism for managing information on what functions each object has, and usually has information on all objects used in the distributed object system.

A technique for generating the proxy object 5 and the proxy client 4 by the request level bridge 3 in FIGS. 1 and 2 will be described below. FIG. 5 is an explanatory diagram showing an example of the generation operation of the proxy object and the proxy client by the request level bridge in FIGS. 1 and 2. In this example, the object 7 in the distributed object system 1 is assigned a function Method
(4) A relationship between information for automatically generating the proxy object 5 and the proxy client 4 when the use of the 7d is restricted.

The information of the object 7 extracted from the interface repository in the distributed object system 1, that is, the interface repository information 52,
The proxy object generation tool 53 is operated by using the usage restriction information 51 on the object 7 described with reference to FIG. 4 as input information, thereby automatically generating the proxy object 5 and the proxy client 4.

At this time, the function Me of the proxy client 4
Each of the method (1) 4a to the method (3) 4c outputs a code for calling a function of the corresponding object 7 and performing a process of returning a return value. Also,
Function Method (1) 5a-M of Proxy Object 5
As the method (3) 5c, the functions Method (1) 4a to Met of the corresponding proxy client 4 are respectively provided.
A code for calling hod (3) 4c is output.

FIG. 6 is a flowchart showing a processing operation example of the proxy object generation tool in FIG. Hereinafter, the processing of the proxy object generation tool 53 of FIG. 5 in the example of FIG. 1 will be described with reference to FIG. First, the usage restriction information 51 for the object 7 is obtained (step 601), and then the interface repository information 52 of the target object (here, the object 7) is obtained (step 602). Then, the index variable I is initialized (step 603).

The above is the initialization processing. Hereinafter, processing for automatically generating a proxy object is started, and the processing described below is repeated until the determination processing result in step 604 becomes No. The “number of interfaces” in the determination processing in step 604 indicates the number of functions in the interface repository information of the object 7 acquired in the processing in step 602. In the example of FIG.
There are four functions, Method (1) to Method (4).

In step 602, since the index variable I is initially 0, the result of the determination processing in step 604 is Yes. As described above, when the determination result is Yes, the information of the I-th function is extracted from the interface repository information of the object 7 (step 60).
5). However, the leading information is counted as 0th. In this example, the information of the function Method (1) is extracted.

Then, the extracted function Method
It is checked whether or not (1) is described in the usage restriction information 51 read in the processing of step 601 and usage prohibition (use restriction) is designated (step 606). FIG.
In the example, Method (1) is No because the use restriction is not specified, and the method is transmitted to the proxy client 4 by Method.
outputting the code of d (1) (step 607); and
The method (1) code is output to the proxy object 5 (step 608).

After that, the index variable I is incremented (step 609), and the process returns to the determination processing of step 604 to repeat the above processing. When the index variables I are “1” and “2”, the same processing as in the case of “0” is performed, and Method (2) and Method
Output the code for (3).

However, when the index variable I becomes "3", the information of the function read out in the processing of step 605 is related to Method (4), so that the result of the determination processing in step 606 is "Yes", and , 608 without performing the process. As a result, the function Method (4) is not implemented in the proxy object 5 and the proxy client 4. After this, the index variable I becomes “4”
, And the result of the determination processing in step 604 is No, and the processing ends.

In this manner, the proxy objects (the proxy object 5 and the proxy client 4) are automatically determined from the interface repository information for disclosing the original object to the external distributed object system and the information describing the function of restricting the use. Can be generated. Then, by using the proxy objects (the proxy object 5 and the proxy client 4) automatically generated in this way, it is possible to realize a use restriction on a functional unit basis.

Next, a technique for defining the use of interface information that can be referred to from the interface repository for each work group and thereby restricting the use of functional units of objects will be described with reference to FIG. FIG. 7 is a block diagram showing a third embodiment of the configuration according to the present invention of the distributed object security system of the present invention.

In this example, three work groups 71 to 7
In a distributed object system consisting of
When the function Method (2) 72b of each function of the object 72a in the work group 72 is used by the client 71a in the other work group 71 and the client 73a in the work group 73, the interface information in the interface repository is used. Is used to show the configuration that realizes the use restriction.

The client 71a uses the interface repository information 71b, and the client 73a uses the interface repository information 73b.
The interface repository information 71b does not limit the use of the function of the object 72a, and registers the interface information of all the functions of the object 72a.

On the other hand, interface repository information 73
b, among the functions of the object 72a, the function Meth
Interface information that restricts use of od (2) and function Method (3) is registered. As described above, the function Method (2) 72 of the object 72a is used by both the clients 71a and 73a using the dynamic call that is called via the interface repository.
Trying to use b.

Reference numerals 711 to 71 assigned to arrows in the drawing
Reference numeral 3 denotes a message flow from the client 71a at this time, and reference numerals 714 and 715 denote message flows from the client 73a. A call from the client 71a first goes to the interface repository information 71b (message flow 71
1) It is determined whether the function Method (2) exists. Since the interface repository information 71b includes the information of the function Method (2), a result indicating that the function exists is returned (message flow 712), and the call of the object 72a to the function Method (2) 72b succeeds (message Flow 713).

On the other hand, the function Me from the client 73a
The call to method (2) goes to the interface repository information 73b (message flow 714), and determines the existence of the function Method (2). Since the information of the function Method (2) is not included in the interface repository information 73b, the result is that the function Method (2) does not exist (message flow 71).
5), Function Method from client 73a
The call of (2) fails.

As described above, by using different interface repositories for each work group that can be referred to from the interface repository, it is possible to realize a use restriction for each function. In other words, by deleting the information of the interface (function) whose use is to be restricted from the interface repository referenced by the user, the function whose use is to be restricted becomes invisible from the user, and can be used in units of functions without authentication or authority check. Use restrictions can be realized.

As described above with reference to FIGS. 1 to 7, in the distributed object security system of this embodiment, the original object is disclosed as an interface provided by the proxy object of the request level bridge. By restricting and providing only a part of the interface, but not all of the interface, the functions whose use is restricted from other distributed object systems are made invisible.

As a result, the functions of the original object that can be used from other distributed object systems can be restricted with a small change without performing special authentication and checking of authority. In particular, since there is no need to make any changes to the base of the distributed object system such as the ORB, it can be easily applied to existing systems.

For example, as in the example described as the prior art, access from outside (external) of the own department only requires a mechanism for disabling a specific function such as rewriting of information. Is suitable for restricting the use of each function under conditions that are not required

Further, the proxy object for restricting the use of the function can be automatically generated based on the interface repository information and the information specifying the use restriction of the function unit. In addition, users and objects on one distributed object system, not only between distributed object systems with different domains, are treated as one logical group (work group), and use restrictions between the work groups are determined using the interface repository. It can also be realized.

The present invention is not limited to the embodiment described with reference to FIGS. 1 to 7, but can be variously modified without departing from the gist thereof. For example, in this example, the proxy object is generated by designating the use restriction of the function unit with respect to the interface information registered in the interface repository of the object, but the proxy object is generated in the interface definition language (IDL). The proxy object may be generated by designating the use restriction of the function unit for the interface specification.

[0048]

According to the present invention, in a security system in a distributed object environment, management and maintenance of authentication information, which requires a great deal of trouble, and rewriting of information from the outside without changing the existing system configuration are required. It is possible to efficiently restrict the use of each function under the condition that does not require a strong security check, such as restricting the security.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a first embodiment of a configuration according to the present invention of a distributed object security system of the present invention.

FIG. 2 is a block diagram showing a second embodiment of the configuration according to the present invention of the distributed object security system of the present invention.

FIG. 3 is a flowchart showing a flow of processing when a function of an object in another domain is used from a client in one domain in the distributed object security system in FIGS. 1 and 2;

FIG. 4 is an explanatory diagram showing a format of information for designating use restrictions in units of function of an object.

FIG. 5 shows the request level in FIG. 1 and FIG.
FIG. 11 is an explanatory diagram showing an example of a generation operation of a proxy object and a proxy client by a bridge.

FIG. 6 is a flowchart illustrating an example of a processing operation of a proxy object generation tool in FIG. 5;

FIG. 7 is a block diagram showing a third embodiment of the configuration according to the present invention of the distributed object security system of the present invention.

[Explanation of symbols]

1: distributed object system 3: request
Level bridge, 4: proxy client (proxy object), 4a to 4c: function (Method (1) to
(3)), 5: proxy object, 5a to 5c: function (Method (1) to (3)), 6: client,
7: Object, 7a to 7d: Function (Method
(1) to (4)), 10 to 15, 21, 22: message flow, 51: use restriction information, 52: interface repository information, 53: proxy object generation tool,
71 to 73: work group, 71a, 73a: client, 71b, 73b: interface repository information, 72a: object, 72b: function (Metho
d (2)), 711-715: Message flow.

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Takeki Fujinami 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture F-term in the Software Division, Hitachi, Ltd. 5B045 JJ33

Claims (3)

[Claims] 1. A security system for a distributed object environment comprising a plurality of domains and using a bridge that uses a proxy object for transmitting a request between the domains, wherein the proxy object provides an interface provided by the proxy object. A distributed object security system characterized in that only interfaces excluding those subject to usage restrictions are provided among all the interfaces published by the original object. 2. The distributed object security system according to claim 1, wherein said bridge includes an interface information or an interface definition language (IDL) registered in an interface repository of said original object.
A distributed object security system, comprising: means for generating the proxy object having a restricted interface based on the interface specification described in (1) and information specifying use restrictions on a function basis. 3. A distributed object security system that divides users and objects on a distributed object system into logical work groups and restricts use of the objects in each work group.
A distributed object security system, comprising: an interface repository in which an interface of an object that can be referred to in each work group is defined for each work group.