JP5701111B2 - Information processing apparatus, information processing method, and program - Google Patents

Description

  The present invention relates to an information processing apparatus, an information processing method, and a program.

Conventionally, each application manages application resources. For example, consider a case where the first application receives an access request for a resource managed by the first application from the second application. In such a case, conventionally, the first application itself has determined whether or not the second application is an application permitted to access the resource.
For example, in Patent Document 1, the purpose of service A is to control access to resources owned by service B in security domain X. In the technique of Patent Document 1, the service B itself, which is the resource management source, determines whether or not the service A can be used.

JP 2000-148469 A

  However, when considering a service that centrally manages resources of a plurality of applications, the service manages resources independently of the application. For this reason, the service does not belong to any security domain, and even if the second application requests access to the resource of the first application, there is a problem that it is not possible to determine whether or not the service is available.

  The present invention has been made in view of such problems, and it is possible to control access from a second application to a resource of a first application by a service that centrally manages resources of a plurality of applications. Objective.

Therefore, the present invention provides an information processing apparatus having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate. a is, the first not belong to the security domain and the second security domain, has a management unit that manages a log of a plurality of applications including the first application, pre-Symbol management means When the access request to the log of the first application is received from the second application, the authentication result for the first application included in the access request is delivered to the first application, and the first application To the second application If by receiving the result of determination whether to permit access to the log, and returns the determination result to the second application.

  ADVANTAGE OF THE INVENTION According to this invention, the access control from the 2nd application with respect to the resource of a 1st application by the service which manages the resource of a some application collectively can be enabled.

FIG. 2 is a diagram illustrating an example of a hardware configuration of a digital multi-function peripheral that is an example of an information processing apparatus. It is a figure which shows an example of the execution environment etc. of software. It is a figure which shows an example of the execution environment etc. of the conventional software. It is a figure which shows the structure of a log area. It is a flowchart which shows an example of a process from installation of an application until the log area | region of an application is ensured. It is a figure for demonstrating the process of access control with respect to a log (or log area | region) using a software structure.

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

<Embodiment 1>
FIG. 1 is a diagram illustrating an example of a hardware configuration of a digital multi-function peripheral that is an example of an information processing apparatus. In FIG. 1, a CPU 103, a RAM 105, a network interface 104, a printer unit 102, an operation unit 108, and an I / O control unit 106 are connected, and an HDD (meaning hard disk) 107 is connected via the I / O control unit 106. ing. The HDD 107 stores a program, which is read from the HDD 107 to the CPU 103 and executed. When the CPU 103 executes the program, a software module described later and processing of a flowchart are realized. The software module can receive user operation input from the operation unit 108, and can use and control the printer unit 102, the RAM 105, the network interface 104, and the HDD 107.

FIG. 2 is a diagram illustrating an example of a software execution environment and the like. In FIG. 2, 201 indicates the entire software execution environment. The basic part in the software execution environment is the OS 202. The OS is a software module generally called an operating system (Operating System) in computer technology, and all the software modules described below operate on the OS 202. Further, all the software modules described below are used or controlled by the hardware modules shown in FIG. 1 directly or indirectly through an API provided by the OS 202 via a Java (registered trademark) execution environment 204 described later. I do. API stands for application programming interface. Note that an API entity is provided by being included in the OS 202, and is not particularly shown in FIG. The Java execution environment 204 provides a uniform API to software that operates on the OS 202 and the type of API and hardware configuration provided by the OS 202 and the hardware. This provides a virtual execution environment (virtual machine) that improves the development efficiency and reusability of software modules.
The application execution framework 205 is an entire software execution environment 201 such as management of application installation and uninstallation, control of the execution order of applications, and a communication function via an API between applications and software modules on the framework. Provide a mechanism to control and control Note that the application execution framework 205 is a generic term for a group of software modules that provide the above-described functions.
The Java execution environment 204 and / or the application execution framework 205 is an example of an application execution environment.

The log service 206 is a software module that exists in the software execution environment 201 from the beginning. The log service 206 provides a function of recording and managing a log of an application to be installed later as a log on the HDD 107, and details thereof will be described later with reference to FIG. Here, the log is a general term for recording various behaviors of applications and processing histories as a file on a recording medium such as a hard disk or a flash memory. In the present embodiment, the recording medium is recorded as a file on the hard disk, but may be recorded on another recording medium. The log service 206 is an example of resource management means.
Here, FIG. 3 shows an example of a typical old configuration. FIG. 3 is a diagram illustrating an example of the conventional configuration. In FIG. 3, an application log 509 is recorded in a file that can be accessed only by the application 507. When the application 508 accesses the application log 509, the application 508 needs to acquire permission that can be accessed in advance and user authority for log reading of the application 507. In other words, the application 508 acquires the authority of the log acquisition for the application 507 and the authority of the user under the management of the application 507 by the API provided by the application 507. Then, after obtaining these, the application 508 can obtain the application log 509.
Here, the application 507 not only has an authentication function for the application 507 and an access control function for the application log 509, but also has an application log 509 that may be accessed by another application. In other words, the application log 509 is arranged in an area managed by the application 507 itself.

  On the other hand, in FIG. 2, an arbitrary application can use the function of the log service 206 via the API registered by the log service 206 with respect to the application execution framework 205. That is, in the example of FIG. 3, the application 507 has an application log 509, but in the example of FIG. 2, the log service 206 has a plurality of application logs as shown in FIG. . In other words, the log service 206 provides a log area for a plurality of applications such as the application 207. The greatest motivation for adopting the configuration shown in FIGS. 2 and 4 is the consolidation of log areas. The log area is consolidated in one place (in the case of this embodiment, the log service 206). This makes it possible to unify the log format, log acquisition method, and API for recording / acquiring them for each application, and any application as a whole system can conform to the unified log format. Further, if logs in the log area aggregated from only the log service 206 can be collected, logs of all applications existing in the system can be collected at once by a unified manner. As a result, there are merits of reducing the load related to the user's log collection and reducing the creation load of the application author's log recording / acquisition processing.

  Also in FIG. 2, the log service 206 provides the following functions for an arbitrary application by its API. First, the first function is to create and secure a dedicated log area recorded only by the application as a file (log file) on the HDD 107 that can be directly accessed only by the log service 206. The second function is a function of recording a log for an application via an API. The third function is a function of reading a log via an API for an application. Details of each function will be described in FIG. Here, although the log service 206 can create a plurality of log areas, in order to simplify the description, in FIG. 4, the entire log area managed by the log service 206 is indicated as 301. Also, the application 207 creates and secures a log area 302 in the entire log area 301, and the log areas of other applications are described as log areas 303 of other applications.

FIG. 5 is a flowchart showing an example of processing from installation of an application to securing a log area of the application. It is assumed that the log service 206 has already been executed by the application execution framework 205.
First, in step 401, the application 207 is installed and executed by the application execution framework 205.
The executed application 207 requests the log service 206 to secure the log area 302 dedicated to the application 207 via the above-described API. Further, the application 207 registers the user authority confirmation API and application permission (here, application permission A) in the log area 302 (step 402).
Application permission is a code-level security mechanism applied to an execution body of an application introduced in Java, and its definition and behavior are defined by processing inside the API. On the other hand, whether or not the permission is held is implemented by declaring a definition for each application in a file in the execution body. Further, when a function or process is requested to be executed through a certain API, the permission should be held by the application that calls the API, and in general, different permissions can be defined depending on the API function or process. If the application tries to use the API without possessing the permission necessary for the use, it is considered that the permission is insufficient, and the use of the API is interrupted and fails. The application permission A shown below is considered to have the right to access the log area 302 via the action prescribed by the application permission A, that is, the API, if the application permission A is possessed by the application.

Here, the user authority confirmation API is used by the log service 206 to confirm the user authority with respect to the application 207 in a later description, and the details will be described later. The registration of the user authority confirmation API is not essential. Registering the application permission A means that any application that accesses the log area 302 secured in step 402 is required to be held among the permissions that can be held by the application. That is, only an application having application permission A among arbitrary applications has an authority to access the log area 302 secured here.
Note that the registration of the application permission is determined by the definition of the application 207 that is the owner of the log area 302, and is not necessarily set. It should be noted that the user authority and the application permission are independently defined by the application 207 and are controlled independently by the log service 206, and details thereof will be described later. The application permission is described in an arbitrary application entity (installation package) when the application is installed. The application permission is interpreted by the application execution framework 205 at the time of installation, and while the application is being executed, it is verified whether or not the permission is held by the Java execution environment 204. In this embodiment, the log service 206 can verify whether or not the application permission A is held via the permission check mechanism of the Java execution environment 204 when an arbitrary application uses the service via the API. it can.
Next, the log service 206 records the application permission A and the user authority confirmation API together with the log area 302 as a file on the HDD 107 (step 403).

Next, in step 404 and subsequent steps, processing when an application 208 different from the application 207 that is the owner of the log area 302 accesses the log area 302 will be described in detail. In step 404, the application 208 requests the log service 206 via the API to read the log recorded in the log area 302. This API is different from the above-mentioned API, but is provided to the application by the log service 206 for accessing the log area by the same mechanism.
In response to this request, the log service 206 verifies whether or not application permission is set for the log area 302 (step 405). The log service 206 can perform this verification based on information stored in the file together with the log area 302 as described above.
Next, when it is verified that the log area 302 holds the application permission A, the log service 206 verifies whether the application 208 has the application permission A based on the information (step 406). . If application permission is not set in the log area 302 in step 405, the verification in step 406 is not performed and the processing moves to step 407. If the application permission A is set in the log area 302 and the application 208 has the application permission A, the processing moves to step 407.

If the application 208 does not have the application permission A, the log service 206 rejects the read request of the application 208 and returns the result to the application 208 (step 412).
In step 407, the log service 206 confirms whether the user authority confirmation API is registered in the log area 302 from the application 207. If the user authority confirmation API is not registered in the log area 302, the log service 206 can permit the application 208 to access the log area 302 at this time, and returns the result to the application 208 (step 411).
On the other hand, if a user authority confirmation API is registered in step 407, the log service 206 inquires of the application 207 whether the user authority for the log area 302 is appropriate using the API. Here, it is assumed that the application 208 completes user authentication with respect to the application 207 without going through the log service 206 in advance. The user authentication here refers to authentication performed by a user who operates the application 208 and accesses the log area of the application 207 via the application via the predetermined API, for example. . In other words, the application 207 includes an API that uniquely authenticates another application. With this API, the application 208 can perform user authentication under the management of the application 207, and further obtain the authentication result from the application 207. That is, the application 208 does not request user authentication from the log service 206. This user authentication may be executed by a combination of a user name including a domain name to which the application 207 belongs or a user name not including the domain name and a password. The user authentication may be performed by authentication using biometrics such as an IC card or fingerprint / iris authentication via an external authentication device attached to the device. It should be noted that the authentication result may be delivered to the API that the application 208 has requested to access the log service 206, or may be delivered using another API. In any case, the log service 206 delivers this authentication result to the application 207 via the user authority confirmation API (step 408). Then, the application 207 determines whether the access authority to the log area 302 exists for the user indicated in the authentication result, and returns the result to the log service 206 (step 409).

  Based on the result, the log service 206 determines whether or not the authentication result of the user operating the application 208 has the authority to access the log area 302 (step 410). When access to the log area 302 is not permitted, the log service 206 returns a result of refusing access to the application 208 (step 412). When access to the log area 302 is permitted, the log service 206 returns the access-permitted result to the application 208 (step 411). The result shown here determines whether or not access to the log area 302 is permitted by the authenticated user via the application 208, and results in the following actions. That is, if a user authenticated for the application 207 is determined as an administrator in the application 207, the user is regarded as having administrator authority. A user who is regarded as an administrator by the application 207 is permitted to access the log area 302 held by the application 207. However, if the authenticated user is a general user for the application 207, it is not permitted. The result thus returned is required to be designated as a parameter even when the log area 302 for the log service 206 is subsequently passed via the API. That is, only when the authentication result information is included in the API argument, the API performs processing while permitting access to the log area 302.

  As described above, the log service 206 can do the following through the processing from step 401 to step 412. In other words, in response to an access request from the application 208 to the log area 302 that the application 207 holds under the management of the log service 206, access control can be performed based on the application permissions set in the log area 302 in advance. In other words, the log service 206 can delegate all access determinations to the log area 302 based on the user authority managed by the application 207 to the application 207. In other words, although the log service 206 manages the log area 302 of the application 207, access control to the log area 302 can be performed according to the access control method defined by the application 207.

FIG. 6 is a diagram for explaining access control processing for a log (or log area) using a software configuration.
In SQ1, the log service 206 receives, for example, a request for securing the log area 302 from the application 207 belonging to the security domain A via the API. Further, the log service 206 also receives a registration request including an API for user authority confirmation in the log area and application permission A from the application 207 belonging to the security domain A. Security domain A is an example of a first security domain. Security domain B is an example of a second security domain.
Then, in SQ2, the log service 206 secures the log area 302 in the entire log area 301 to be managed, and associates the application permission A and the user authority confirmation API as a file on the HDD 107 in association with the log area 302. Record.
In SQ3, for example, the log service 206 receives an access request for a log (or log area) recorded in the log area 302 from the application 208 belonging to the security domain A and the security domain B.
In SQ4, the log service 206 verifies whether application permission is set for the log area 302 based on the information recorded in the file.

When the application permission is set, in SQ5, the log service 206 verifies whether or not the application 208 that has transmitted the access request has the application permission A set in the log area 302. The log service 206 performs the verification via the permission check mechanism of the Java execution environment 204 as described above.
If the application permission A is possessed, in SQ6, the log service 206 confirms whether the user authority confirmation API is registered in the file or the like in association with the log area 302.
When the user authority confirmation API is registered in the file or the like in association with the log area 302, in SQ7, the log service 206 delivers the above-described authentication result to the application 207 via the user authority confirmation API.
In SQ8, the log service 206 receives from the application 207 a determination result as to whether or not the user indicated in the authentication result has access authority to the log area 302.

In SQ 9, the log service 206 verifies the determination result received from the application 207, and confirms whether access to the log area 302 is permitted. For example, when the determination result received from the application 207 indicates that the access authority to the log area 302 exists for the user indicated in the authentication result, the log service 206 grants access to the log area 302. On the other hand, the log service 206 does not permit access to the log area 302 when the determination result received from the application 207 indicates that the user indicated in the authentication result does not have the authority to access the log area 302.
In SQ 10, the log service 206 returns a result indicating whether or not to permit access to the log area 302 to the application 208. In this embodiment, a result indicating whether or not access is permitted is returned. However, in response to confirming that the access is permitted, the log service 206 logs the log in the log area 302 at the time of reply of SQ10. 208 may be transmitted.
As described above, since the log service 206 does not belong to the security domain to which the application 207 or the application 208 belongs, the log service 206 can determine whether to permit the application 208 to access the log area 302 of the application 207. Can not. However, the log service 206 performs processing as shown in FIG. 6 and the like, thereby enabling access control from the application 208 to the log area 302 of the application 207.

<Other embodiments>
The present invention can also be realized by executing the following processing. That is, software (program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, etc.) of the system or apparatus reads the program. It is a process to be executed.

As described above, according to each of the above-described embodiments, it is possible to control access from the second application to the resource of the first application by the service that centrally manages the resources of the plurality of applications.
In the above-described embodiment, a log or a log area has been described as an example of a resource. However, this does not limit the embodiment.

  The preferred embodiments of the present invention have been described in detail above, but the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims.・ Change is possible.

Claims (9)

An information processing apparatus having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate,
Not belong to the first security domain and the second security domain of has a management unit that manages a log of a plurality of applications including the first application,
Before SL management means, wherein when the second receiving the access request to the log of the first application from the application of, passing the authentication result for the first application included in the access request to the first application An information processing apparatus that, upon receiving a determination result as to whether or not to permit access to the log by the second application from the first application, returns the determination result to the second application. The second application belonging to the first security domain can authenticate the first application belonging to the first security domain, and the authentication result included in the access request is the second application Is the result of the authentication performed by the application in advance,
It said first security domain and the second security domain before Symbol management means which does not belong to, it is impossible to perform the determination whether to permit access to the log claim 1 information processing apparatus according. Before SL management means receives the determination result indicating the permission of the access to the log by the second application from the first application, access to the log with respect to the second application When a determination result indicating permission is returned and a determination result indicating that access to the log by the second application is not permitted is received from the first application, the log is sent to the second application. The information processing apparatus according to claim 1, wherein the information processing apparatus returns a determination result indicating that access to the access is not permitted. When the management means receives an access request to the log of the first application from the second application, the management means determines whether or not an interface for inquiry to the first application is associated with the log. When an interface for inquiry to the first application is associated with the log, an authentication result for the first application included in the access request is delivered to the first application via the interface. The information processing apparatus according to any one of claims 1 to 3. The information processing apparatus according to claim 4 , wherein the management unit associates and registers the log of the first application and an interface for inquiring to the first application . An information processing apparatus having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate,
Management means for managing log areas of a plurality of applications that do not belong to the first security domain and the second security domain and include the first application,
When the management means receives an access request to the log area of the first application from the second application, the management means hands over the authentication result for the first application included in the access request to the first application, An information processing apparatus that receives a determination result as to whether or not to permit access to the log area by the second application from the first application, and returns the determination result to the second application . An information processing method in an information processing apparatus having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate. And
The information processing apparatus includes:
Not belong to the first security domain and the second security domain of has a management unit that manages a log of a plurality of applications including the first application,
Previous SL management unit, the steps of from the second application receives a request for access to the log of the first application,
Previous SL management unit, a step of passing an authentication result for the first application included in the access request to the first application,
Previous SL management unit, receiving a determination of whether the result is allowed to access the log by the second application from the first application,
Previous SL management unit, a step of returning a determination result to the second application,
An information processing method including: An information processing method in an information processing apparatus having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate. And
The information processing apparatus includes:
Management means for managing log areas of a plurality of applications that do not belong to the first security domain and the second security domain and include the first application,
The management means receiving a request for access to the log area of the first application from the second application;
The management means handing over an authentication result for the first application included in the access request to the first application;
The management means receiving a determination result as to whether or not to permit access to the log area by the second application from the first application;
The management means returning the determination result to the second application;
An information processing method including: 7. A computer having an application execution environment in which a first application belonging to a first security domain and a second application belonging to the first security domain and the second security domain operate. A program for functioning as each means of the information processing apparatus according to claim 1.

Images