JP2007065971A - System, method and program for generating menu - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the operation load and resource of a system manager by reducing the number of menus to be defined. <P>SOLUTION: A system includes a menu storing means for storing basic menu information where a service is defined; an access authority storing means for associating the authority of a user with a service: and a menu generating means for generating the menu information of each user. The menu generating means accepts a menu generation request including user ID, and reads the basic menu information from the menu storing means, and specifies authority corresponding to the user ID, and extracts the service corresponding to the authority from the access authority storing means, and generates an accessible service list, and compares the service set in the basic menu information with the service list, and erases the service which does not exist in the service list from the basic menu information, and generates the menu information of the user ID. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique for generating a menu according to a user's authority.

  There is SAML (Security Assertion Markup Language) as a technique for realizing single sign-on that allows access to a plurality of systems with one authentication. By using the SAML protocol, authentication information and access control information can be transmitted and received.

As an authentication technique using SAML, for example, Patent Document 1 describes an authentication settlement method for switching a service procedure in accordance with a description content of a service certificate. Patent Document 2 describes a user information distribution system that relays transmission / reception of user information between service providers.
JP 2004-126887 A JP 2004-362189 A

  In a general authentication system using SAML or the like, after authenticating a user, it is necessary to present to the user (client) a menu displaying services that can be used according to the access authority of the user. is there.

  However, when a menu corresponding to the access authority of each user is defined for each user, the number of menus to be defined increases with the increase in the number of users, and the workload on operations and management increases. Further, resources for storing menus defined for each user also increase.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to reduce the operation load and resources of the system administrator by reducing the number of menus to be defined.

  In order to solve the above-described problems, the present invention provides, for example, a menu generation system that associates a menu storage unit that stores basic menu information in which at least one service is defined, a user authority, and the service. Access authority storage means, and menu generation means for generating menu information for each user based on the basic menu information. The menu generation means receives a menu generation request including a user ID, and The basic menu information is read from the menu storage means, the authority corresponding to the user ID is specified, the service corresponding to the authority is extracted from the access authority storage means, an accessible service list is generated, and the basic menu is generated. The service set in the information is compared with the service list, and the service list Remove the nonexistent service from the basic menu information to generate the menu information of the user ID.

  In the present invention, the operation load and resources of the system administrator can be further reduced by reducing the number of menus defined in advance.

  Embodiments of the present invention will be described below.

  FIG. 1 is an overall configuration diagram of an authentication system to which an embodiment of the present invention is applied. Note that the authentication system of this embodiment uses the SAML protocol.

  The illustrated authentication system includes a client 1, an authentication presentation server (hereinafter “authentication PL server”) 2, an authentication business logic server (hereinafter “authentication BL server”) 3, and at least one application server 4. Have.

  The client 1 is connected to the authentication PL server 2 and the application server 4 via a first network 8 such as the Internet, and HTTP (HyperText Transfer Protocol) is used for sending and receiving messages. Further, the authentication PL server 2 and the application server 4 and the authentication BL server 3 are connected by a second network 9, and HTTP or SOAP (Simple Object Access Protocol) is used for message transmission / reception. Each device may be connected to one network in which the first network 8 and the second network 9 are integrated.

  The client 1 first accesses the authentication PL server 2. The client 1 accesses the desired application server 4 after successful user authentication performed by the authentication PL server 2 and the authentication BL server 3. The client 1 includes a web browser (not shown). In this embodiment, it is assumed that each user who uses the client 1 is an employee user who belongs to a predetermined company, and the company code and user ID of the company to which the user 1 belongs are set in advance.

  The authentication PL server 2 and the authentication BL server 3 perform a common authentication process for the plurality of application servers 4 to realize single sign-on. That is, the authentication PL server 2 and the authentication BL server 3 control the user access by generating menu information in which a service accessible according to the user authority is set after the user authentication.

  The authentication PL server 2 performs input / output processing for the client 1. The illustrated authentication PL server 2 includes a control unit 21 and a menu conversion unit 22. The control unit 21 receives data transmitted from the client 1 and transmits it to the authentication BL server 3, and transmits data transmitted from the authentication BL server 3 to the client 1. The menu conversion unit 22 converts the menu information generated by the authentication BL server 3 into a predetermined format such as HTML (HyperText Markup Language).

  The authentication BL server 3 performs user authentication in response to a request from the authentication PL server 2, and dynamically generates menu information of the user after successful authentication. The illustrated authentication BL server 3 includes an authentication unit 31, an attribute information acquisition unit 32, a menu generation unit 33, a user attribute DB 34, an authentication table 35, a menu information table 36, a role mapping table 37, and an access authority. A table 38, an unprovided service table 39, and a service definition table 40.

  The authentication unit 31 refers to the authentication table 35 to authenticate the user's validity. The attribute information acquisition unit 32 acquires the attribute information of the requested user from the user attribute DB 34 and transmits it to the authentication PL server 2 (or the application server 4). The menu generation unit 33 refers to the various tables 35 to 40 and dynamically generates menu information for each user. The user attribute DB 34 stores user attribute information (for example, personal information such as address, name, age, etc.) delivered to the authentication PL server 2 or the application server 4. Various tables 35 to 40 will be described later.

  The application server 4 is a Web server, for example, and provides various services to the client 1. The illustrated application server 4 includes an access control unit 41 and a business processing unit 42. The access control unit 41 receives an access request from the client 1 and controls access to a desired service. Note that the access control unit 41 may query the authentication BL server 3 as to whether access is possible, and may perform access control based on the authentication result (access permission, access denial) of the authentication BL server 3 as necessary. The business processing unit 42 provides services to clients.

  The client 1, the authentication PL server 2, the authentication BL server 3, and the application server 4 described above all include a CPU 901, a memory 902, an external storage device 903 such as an HDD, a keyboard, A general-purpose computer system including an input device 904 such as a mouse, an output device 905 such as a display or a printer, and a communication control device 906 for connecting to a network can be used. In this computer system, the CPU 901 executes a predetermined program loaded on the memory 902, thereby realizing each function of each device.

  For example, the functions of the authentication PL server 2, the authentication BL server 3, and the application server 4 are configured such that the CPU 901 of the authentication PL server 2 in the case of the program for the authentication PL server 2 and the authentication BL in the case of the program for the authentication BL server 3. The program is realized by the CPU 901 of the server 3 and the CPU 901 of the application server 4 in the case of a program for the application server 4. It is assumed that the memory 902 or the external storage device 903 of the authentication BL server 3 is used for the user attribute DB 34 and the various tables 35 to 40 of the authentication BL server 3. In addition, regarding the input device 904 and the output device 905, each device is provided as necessary.

  Next, various tables 35 to 40 of the authentication BL server 3 will be described.

  FIG. 3 is a table relation diagram schematically showing the relationship between the various tables 35-40. The authentication table 35 is a table for authenticating the identity of the user, and has a company code, a user ID, and a menu ID. The menu information table 36 is a table in which menu IDs and corresponding basic menu information are stored.

  The role mapping table 37 is a table in which user IDs and roles are associated with each other. The role indicates the authority (role) of the user. In the present embodiment, the concept of a role is used to associate (link) each user with a service that can be used by the user. As the types of roles, for example, a normal business role and a management information browsing role can be considered. In this case, in the role mapping table 37, only the normal business role is set as the user ID of the general employee, and the normal business role and the management information browsing role are set as the user ID of the officer. In the present embodiment, it is assumed that at least one role is defined for each system ID. The system ID is identification information for identifying an application system provided by each application server 4.

  The access authority table 38 is a table in which each role is associated with a service accessible by the role. In the illustrated example, role a can access services A and B, role b can access service B, and role c can access services C, F, G, and H, respectively. The unprovided service table 39 is a table in which unprovided services that are not provided to users of the company are defined for each company. The service definition table 40 is a table in which definition information necessary for generating menu information is stored for each service.

  FIG. 4 is a diagram illustrating an example of the authentication table 35. The authentication table 35 is a table for authenticating the validity of the user. The illustrated authentication table 35 includes a company code 351, a user ID 352, a password 353, a menu ID 354, a password expiration date 355, and the like. The menu ID 354 is identification information for identifying basic menu information described later.

  FIG. 5 is a diagram showing an example of the menu information table 36. The menu information table 36 includes a company code 361, a menu ID 362, and basic menu information 363. The basic menu information 363 is basic menu screen definition information (so-called templates and templates). In the present embodiment, the basic menu information 363 is described using XML (eXtensible Markup Language). Note that XML is a markup language for describing the meaning and structure of documents and data.

  In the present embodiment, the basic menu information 363 is created for each company and for each predetermined category. For example, when basic menu information is created for each occupation, the basic menu information of company A includes basic menu information for sales, basic menu information for general affairs, basic menu information for finance, and the like. Further, when creating basic menu information for each job title, the basic menu information of company B includes basic menu information for general employees, basic menu information for section managers, basic menu information for department managers, and the like.

  By creating basic menu information for each predetermined category, for example, in the basic menu for sales, services that are frequently used in sales operations are displayed prominently at the top of the menu screen. A good menu screen can be generated.

  FIG. 6 is a diagram illustrating an example of the role mapping table 37. The role mapping table 37 is a table in which users and roles are associated with each other. The illustrated role mapping table 37 includes a company code 371, a user ID 372, a system ID 373, and a role ID 374 for identifying a role. In the illustrated role mapping table 37, the role IDs 374 have an array (repeated) structure so that a plurality of role IDs can be set in one record. When one user can access a plurality of systems, a plurality of records are created for one user ID.

  FIG. 7 is a diagram showing an example of the access authority table 38. The access authority table 38 is a table in which each role is associated with a service accessible by the role. The access authority table 38 shown in the figure has a company code 381, a system ID 382, a role ID 383, and a service ID 384. In the illustrated access authority table 38, the service ID 384 has an array (repetition) structure so that a plurality of service IDs can be set in one record.

  FIG. 8 is a diagram showing an example of the unprovided service table 39. The unprovided service table 39 shown in the figure has a company code 391, a system ID 392, and an unprovided service ID 393. In the illustrated unprovided service table 39, the unprovided service ID 393 has an array (repeated) structure so that a plurality of unprovided service IDs can be set in one record.

  FIG. 9 is a diagram illustrating an example of the service definition table 40. The service definition table 40 includes a system ID 401, a service ID 402, a service name 403, a URL (Uniform Resource Locator) 404, display window information 405, and the like. In the URL 404, an address (destination) on the network where the service exists is set. In the display window information 405, character control information such as the size and color of characters to be displayed, icon image information, and the like are set.

  Next, an overall outline of the authentication process of this embodiment will be described.

  FIG. 10 is a sequence diagram of the authentication process.

  First, the client 1 logs in to the authentication PL server 2 (S11). That is, the client 1 receives the company code, user ID, and password input by the user, and transmits a login message including these pieces of information to the authentication PL server 2.

  Then, the control unit 21 of the authentication PL server 2 receives the login message from the client 1 and transmits an authentication request for the login message to the authentication BL server 3 (S12). The authentication request includes the company code of the received login message, the user ID, and the password.

  The authentication unit 31 of the authentication BL server 3 receives an authentication request from the authentication PL server 2. Then, the authentication unit 31 refers to the authentication table 35 and authenticates whether or not the logged-in user is a valid user. That is, the authentication unit 31 determines that the company code, the user ID, and the password included in the authentication request are valid users when the authentication table 35 exists. On the other hand, when it does not exist in the authentication table 35, the authentication unit 31 determines that the user is an unauthorized user.

  If it is determined that the user is a valid user, the authentication unit 31 issues an account identifier (artifact) that proves that the user is a valid user, and transmits the account identifier (artifact) to the authentication PL server 2 (S13). The account identifier is generated from the company code and user ID included in the authentication request, the date and time of authentication, and the like.

  Then, the control unit 21 of the authentication PL server 2 receives an account identifier indicating that the authentication is successful. And the control part 21 transmits the attribute information request | requirement which requests | requires predetermined user attribute information, such as a user's name, to the authentication BL server 3 as needed (S14). It is assumed that the account identifier received from the authentication BL server 3 is added to the attribute information request.

  The attribute information acquisition unit 32 of the authentication BL server 3 receives the attribute information request, and acquires the user attribute information specified from the account identifier added to the attribute information request from the user attribute DB 34. Then, the attribute information acquisition unit 32 transmits the acquired user attribute information and the account identifier to the authentication PL server 2 (S15).

  Then, the control unit 21 of the authentication PL server 2 transmits a menu information generation request to the authentication BL server 3 (S16). It is assumed that an account identifier is added to the menu information generation request. The menu generation unit 33 of the authentication BL server 3 receives the menu generation request and generates menu information according to the user's access authority. The menu information generation process will be described later. And the menu production | generation part 33 transmits the produced | generated menu information and an account identifier to the authentication PL server 2 (S17). Then, the menu conversion unit 22 of the authentication PL server 2 converts the received menu information into a predetermined format and transmits it to the client 1 together with the account identifier (S18). In this embodiment, menu information in XML format is converted to HTML format.

  The client 1 receives menu information and an account identifier. Then, the client 1 analyzes the menu information using a Web browser and displays a menu screen on which accessible services are displayed on the output device.

  FIG. 11 is a diagram illustrating an example of a menu screen displayed on the client 1. In the illustrated menu screen, each service is displayed using a hierarchical structure. Specifically, service A and service B are displayed in the lower hierarchy of folder 1, and service F is displayed in the lower hierarchy of folder 2-1 connected to folder 2. Further, it is assumed that the URL set in the service definition table 40 is embedded as a link destination in the display portion of each service. Each service is displayed according to the window information set in the service definition table 40.

  The user refers to the menu screen displayed on the client 1 and inputs an access request to the desired service by clicking on the desired service. The client 1 accepts the user's input and accesses the predetermined application server 4 with the input URL of the service as the destination (S19). The client 1 transmits an account identifier to the application server 4 when accessing the application server. By receiving the account identifier, the application server 4 permits access to a desired service without authenticating the user of the client 1 again.

  Next, menu generation processing of the authentication BL server 3 will be described.

  12 and 13 are flowcharts of the menu generation process.

  In FIG. 12, the menu generation unit 33 of the authentication BL server 3 receives a menu information generation request with the account identifier added from the authentication PL server 2 (FIG. 10: S16). And the menu production | generation part 33 specifies the company code and user ID which are contained in an account identifier (S21).

  Then, the menu generation unit 33 refers to the role mapping table 37 and acquires all corresponding system IDs and role IDs using the company code and user ID specified in S21 as search keys (S22). Then, the menu generation unit 33 refers to the access authority table 38 and acquires all service IDs accessible by each role ID using each role ID acquired in S24 as a search key. Then, the menu generation unit 33 generates a provided service list in which all acquired service IDs are set, and stores the generated service list in a memory or an external storage device (hereinafter, “memory etc.”) (S23).

  Then, the menu generation unit 33 refers to the unprovided service table 39, acquires an unprovided service ID that does not provide services to the company, using the company code specified in S21 as a search key, and stores it in a memory or the like (S24). If the unprovided service ID of the company code is not registered in the unprovided service table 39, the process proceeds to the next process.

  Then, the menu generation unit 33 refers to the authentication table 35 and acquires the company code and the menu ID of the user ID specified in S21 (S25). Then, the menu generation unit 33 refers to the menu information table 36, reads the corresponding basic menu information using the company code specified in S21 and the menu ID acquired in S25 as a search key, and stores it in a memory or the like (S26). . The basic menu information is described using XML, and each accessible service is described in a hierarchical structure (see FIG. 3).

  Then, in FIG. 13, the menu generation unit 33 analyzes the tag of the basic menu information stored in the memory or the like, and specifies the <node> entry (S27). The <node> entry indicates a folder storing the service. Then, the menu generation unit 33 analyzes the tag of the basic menu information, specifies the <leaf> entry in the <node> entry specified in S27, and acquires the service ID described in the <leaf> entry. (S28).

  Then, the menu generation unit 33 reads the provided service list generated in S23 from the memory or the like, and determines whether or not the service ID acquired in S28 exists in the provided service list (S29). If it exists in the provided service list (S29: YES), the menu generating unit 33 reads the unprovided service ID acquired in S24 from the memory or the like, and whether the service ID obtained in S28 matches any of the unprovided service IDs. It is determined whether or not (S30).

  If it does not match the unprovided service ID (S30: NO), the menu generating unit 33 refers to the service definition table 40 and acquires the service ID definition information acquired in S28. Then, the menu generating unit 33 describes the acquired definition information in the <leaf> entry specified in S28 of the basic menu information (S31). On the other hand, if it does not exist in the provided service list (S29: NO), or if it matches any of the unprovided service IDs (S30: YES), the menu generating unit 33 changes the <leaf> entry specified in S28 to Delete from the basic menu information (S32).

  Then, the menu generation unit 33 analyzes the basic menu information, and determines whether or not the next <leaf> entry is described in the <node> entry specified in S27 (S33). When the next <leaf> entry is described (S33: YES), the menu generating unit 33 returns to S28 and performs the subsequent processes. On the other hand, when the next <leaf> entry is not described (S33: NO), the menu generating unit 33 determines whether or not at least one <leaf> entry is described in the <node> entry. A determination is made (S34). That is, the menu generation unit 33 determines whether or not the service ID stored in the <node> entry does not exist as a result of deleting the <leaf> entry in S32.

  When the <leaf> entry is not described (S34: NO), the menu generating unit 33 deletes the <node> entry from the basic menu information (S35). Then, the menu generation unit 33 analyzes the basic menu information and determines whether or not the next <node> entry is described (S36). When the next <node> entry is described (S36: YES), the menu generating unit 33 returns to S27 and performs the subsequent processes. On the other hand, when the next <node> entry is not described (S36: NO), the menu generating unit 33 ends this process.

  Hereinafter, the menu generation process will be described in detail with reference to the table relation diagram shown in FIG. In the basic menu information of the menu information table 36 shown in the figure, the <node> entry of the folder 1 describes <leaf> entries of “service A” and “service B”. In the access authority table 38, service A and service B are associated from role a or role b. Therefore, the menu generation unit 33 acquires the definition information of “service A” and “service B” from the service definition table 40 and adds them to the basic menu information.

  In the basic menu information shown in the figure, <leaf> entries of “service D” and “service F” are described in the <node> entry of the folder 2-1. In the access authority table 38, no role is associated with “service D”, but role “c” is associated with “service F”. Therefore, the menu generation unit 33 deletes the <leaf> entry of “service D” from the basic menu information. Then, the menu generation unit 33 acquires the definition information of “service F” from the service definition table 40 and adds it to the basic menu information.

  Further, in the basic menu information shown in the figure, the <node> entry of the folder 2-2 describes the <leaf> entry of “service H”. In the access authority table 38, the role “c” is associated with “service H”. However, “service H” is set in the unprovided service table 39. Accordingly, the menu generation unit 33 deletes the <leaf> entry for “service H” from the basic menu information. As a result, since the <leaf> entry does not exist in the <node> entry of the folder 2-2, the menu generation unit 33 deletes the <node> entry of the folder 2-2 from the basic menu information. By performing the processing described above, the basic menu information shown in FIG. 3 is customized, and the menu information of the menu screen shown in FIG. 11 is generated.

  In this embodiment, basic menu information is defined in advance in the menu information table, the basic menu information is customized according to the user's authority, and user-specific menu information is dynamically generated. Thereby, it is not necessary to define menu information for each user, and the number of menus defined in advance can be reduced. In addition, the operation load and resources of the system administrator can be reduced.

  The basic menu information of this embodiment defines accessible services with a hierarchical structure. Accordingly, since the menu screen generated from the basic menu information displays each service in folder units, the user interface is improved.

  In the present embodiment, a plurality of basic menu information is created for each predetermined category. As a result, a user-friendly menu screen can be generated by customizing a basic menu suitable for user attributes such as job type and job title.

  Further, the authentication BL server 3 of the present embodiment includes an unprovided service table. Thereby, menu information excluding unprovided services that are not provided can be generated for a predetermined company. That is, by providing the unprovided service, the number of menus defined in advance can be further reduced.

  In addition, this invention is not limited to said embodiment, Many deformation | transformation are possible within the range of the summary. For example, in the above-described embodiment, the authentication PL server 2 is included, and menu information (XML document) generated by the authentication BL server 3 is converted into an HTML format. However, when using a rich client that implements the function of the authentication PL server 2 as the client 1, the authentication PL server 2 is not necessary.

1 is a diagram illustrating an overall configuration of an authentication system to which an embodiment of the present invention is applied. It is a figure which shows the hardware structural example of each apparatus. It is a table related figure which shows the relationship of each table. It is a figure which shows an example of an authentication table. It is a figure which shows an example of a menu information table. It is a figure which shows an example of a role mapping table. It is a figure which shows an example of an access authority table. It is a figure which shows an example of an unprovided service table. It is a figure which shows an example of a service definition table. It is a whole sequence diagram of an authentication process. It is a figure which shows an example of a menu screen. It is a flowchart of a menu generation process. It is a flowchart of a menu generation process.

Explanation of symbols

  1: client, 2: authentication PL server, 21: control unit, 22: menu conversion unit, 3: authentication BL server, 31: authentication unit, 32: attribute information acquisition unit, 33: menu generation unit, 34: user attribute information 35: Authentication table, 36: Menu information table, 37: Role mapping table, 38: Access authority table, 39: Unprovided service table, 40: Service definition table, 4: Application server, 41: Access control unit, 42: Business processing unit, 8: first network, 9: second network

Claims (6)

A menu generation system,
Menu storage means for storing basic menu information in which at least one service is defined;
Access authority storage means that associates the authority of the user with the service;
Menu generating means for generating menu information for each user based on the basic menu information,
The menu generation means includes
Accepts a menu generation request including a user ID, reads basic menu information from the menu storage means,
Identify the authority corresponding to the user ID, extract the service corresponding to the authority from the access authority storage means, generate an accessible service list,
A menu that compares the service set in the basic menu information with the service list, deletes a service that does not exist in the service list from the basic menu information, and generates menu information for the user ID. Generation system. The menu generation system according to claim 1,
For each company to which the user belongs, an unprovided service storage means in which unaccessible services that cannot be accessed are stored,
The menu generation means includes
Accepts a menu generation request including a user ID and a company code, reads basic menu information from the menu storage means,
Refer to the unprovided service storage means, identify an unprovided service corresponding to the received company code, and if a service matching the unprovided service is set in the basic menu information, A menu generation system, wherein the menu information of the user ID is generated by deleting from the basic menu information. The menu generation system according to claim 1,
An authentication table for authenticating the user's legitimacy;
Authentication means for authenticating the validity of the user with reference to the authentication table, and issuing a certificate indicating the validity of the user,
The menu generation unit transmits the generated menu information together with the certificate to a client. The menu generation system according to claim 1,
The menu information generated by the menu generation means includes the service defined using a hierarchical structure. A menu generation method performed by an information processing apparatus,
The information processing apparatus includes a menu storage unit that stores basic menu information in which at least one service is defined, an access authority storage unit that associates a user authority with the service, and a processing unit.
The processor is
Receiving a menu generation request including a user ID and reading basic menu information from the menu storage unit;
Identifying an authority corresponding to the user ID, extracting a service corresponding to the authority from the access authority storage unit, and generating an accessible service list;
Comparing the service set in the basic menu information with the service list, deleting a service that does not exist in the service list from the basic menu information, and generating menu information for the user ID. A menu generation method characterized by the above. A menu generation program executed by the information processing apparatus,
The information processing apparatus includes a menu storage unit that stores basic menu information in which at least one service is defined, an access authority storage unit that associates a user authority with the service, and a processing unit.
In the processing unit,
Receiving a menu generation request including a user ID and reading basic menu information from the menu storage unit;
Identifying an authority corresponding to the user ID, extracting a service corresponding to the authority from the access authority storage unit, and generating an accessible service list;
Comparing the service set in the basic menu information with the service list, deleting a service that does not exist in the service list from the basic menu information, and generating menu information for the user ID. A menu generation program characterized by this.

Images