Access Management System, Access Management Robot Promotion System, and Access Management Method

Abstract

Embodiments of the present disclosure relate to an access management system, an access management robot facilitation system, and an access management method. Embodiments of the present application relate to integrated robotics and access management of a target system. The access management robot facilitation system facilitates a robot to perform access management tasks on a target system.

Description

[0001] This application is a divisional application of a Chinese patent application with an application date of December 18, 2017, an application number of 201711366309.2, and a title of "Integrated Robotics and Access Management for Target Systems". Technical Field

[0002] Embodiments of the present application relate to integrated robotics and access management for target systems. Background Art

[0003] In information technology, identity and access management typically includes managing user accounts on various systems. These systems can include different applications, such as database applications, customer relationship management (CRM) applications, accounting applications, factory automation applications, etc. System administrators are often responsible for locally managing the lifecycle of user accounts for these systems on the systems when a user joins, leaves, or changes their role within the organization. System administrators can create user accounts, delete user accounts, modify permissions, and so on.

[0004] In many cases, the systems for which user accounts are being managed have non-standard and manual processes and mechanisms for managing their user accounts. The systems may have well-defined processes for account and access management, but there is no common well-defined process or interface for account and access management across different systems. Therefore, to manage user accounts on these systems, organizations typically rely on a help desk to manage user accounts. Generally, when a user account is to be created, a request is made through an access request management system, email, or phone, and a ticket is generated to create the user account. Then, approval to create the user account is obtained via email or an approval workflow in the access request management system, and then the ticket can be placed in a queue. Then, a system administrator (such as a help desk administrator) can ultimately be assigned to the ticket, and the system administrator creates the user account in the system.

[0005] The help desk is an inefficient and expensive solution for managing user accounts. In many cases, a larger operations team is required to run the help desk, which is not only costly but also has problems such as human error and inefficiency. At the same time, as the organization grows, expensive developers may be required to keep the help desk system relevant and running. Additionally, the help desk is often not timely. A ticket can be generated to create a user account, but due to backlogs, it may take days or even a week to complete the account creation. Additionally, users waiting to access the system may be unable to perform their tasks and responsibilities that require the use of the system. Summary of the Invention

[0006] According to a first aspect of the present application, an access management system is disclosed, comprising: an Identity and Access Management (IAM) system, including: a central directory data storage device that stores the electronic identities of individuals and the certificates of individuals; and an IAM computer configured to: receive a request for performing an access management task; determine whether the request is approved; in response to determining that the request is approved, generate an access management request for performing the access management task based on the received request; an Access Management Robot Facilitation (AMRF) system, including: a robot instruction queue; and an access management robot facilitation computer configured to: receive the access management request from the IAM system without extracting information from the access management request; generate an access management instruction in the robot instruction queue based on the extracted information; determine whether the access management instruction lacks required information; if the access management instruction lacks the required information, obtain the required information from the central directory data storage device, and insert the obtained information into the access management instruction; and mark the access management instruction in the robot instruction queue as not yet started; a Robotic Process Automation (RPA) system, including: a robot including a processor configured to: monitor the robot instruction queue for new access management instructions; identify the access management instruction in the robot instruction queue; mark the access management instruction in the robot instruction queue as pending; execute the access management instruction on a target system specified in the access management instruction; and update the status of the access management instruction in the robot instruction queue based on the execution of the instruction.

[0007] According to a second aspect of the present application, an access management robot facilitation system is disclosed, comprising: a storage device that stores a robot instruction queue; and an access management robot facilitation computer including a processor configured to: receive an access management request from an identity access management system; extract information from the received request; generate an access management instruction in the robot instruction queue based on the extracted information; determine whether the access management instruction lacks required information; if the access management instruction lacks the required information, obtain the required information from a directory of the access management system; insert the obtained information into the access management instruction; and mark the access management instruction in the robot instruction queue as not yet started, wherein a robot including the processor is programmed to monitor the robot instruction queue for new access management instructions, and retrieve and execute the access management instruction to perform an automated access management task in a target system.

[0008] According to a third aspect of the present application, a computer-implemented method for facilitating the execution of access management tasks by at least one robot is disclosed. The method includes: receiving an access management request from an identity access management system; extracting information from the received request; generating an access management instruction in a robot instruction queue based on the extracted information; determining whether the access management instruction lacks required information; if the access management instruction lacks the required information, obtaining the required information from a central directory of the identity access management system; inserting the obtained information into the access management instruction; and marking the status of the access management instruction in the robot instruction queue as not yet started. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments and examples are described in detail below with reference to the following drawings. The embodiments are illustrated by way of examples shown in the drawings, in which like reference numerals indicate like elements.

[0010] Figure 1 Illustrates an access management system according to one embodiment;

[0011] Figure 2 Illustrates the computer architecture of an access management system according to one embodiment;

[0012] Figure 3 Illustrates a robot instruction queue according to one embodiment;

[0013] Figures 4A to 4B Illustrates a method according to one embodiment; and

[0014] Figures 5 to 6 Illustrates additional methods according to embodiments. DETAILED DESCRIPTION

[0015] For simplicity and illustrative purposes, the principles of the present disclosure are mainly described with reference to its examples. In the following description, many specific details are set forth in order to provide an understanding of the examples. However, it will be apparent to those of ordinary skill in the art that these examples may be practiced without limitation to these specific details. In some instances, well-known methods and / or structures have not been described in detail so as not to unnecessarily obscure the examples. Additionally, the examples may be used together in various combinations.

[0016] According to one embodiment of the present disclosure, a robot configured by a robotic process automation (RPA) system automates tasks for managing access to a target system. The robot may include computer software that executes one or more tasks for which it is trained. Examples of tasks may include managing user accounts on the target system, such as creating, deleting, or modifying user accounts. The tasks may be associated with controlling user access to the target system or to one or more resources of the target system. The tasks may include associating user permissions and restrictions with an electronic user identity. Access control may be based on policies that define which devices and users are allowed on the network and which users are allowed to complete depending on device type, location, role, and other factors. The target system may include an application or any type of system for which access by users or other systems is to be managed.

[0017] According to one embodiment, the robot may execute a composite request. For example, a single request may be received that requires multiple tasks to be performed to achieve the desired result of the request. Thus, the received request may be a composite request that requires multiple tasks to be performed to achieve the desired result. Additionally, the composite request may require a series of tasks to be performed in a specific order to achieve the desired result. The system may decompose the composite request to identify the series of tasks to be performed, and one or more robots may perform the series of tasks in a specific order.

[0018] An access management system may include an access management robot facilitation system that may provide instructions to the robot for performing tasks for managing access to a target system. For example, the access management robot facilitation system may receive a request associated with managing access to the target system, and the request may come from an identity and access management (IAM) system or another system, such as a service management system or a help desk management system. The access management robot facilitation system may generate instructions based on the request to provide to the robot to perform tasks associated with the request for managing access to the target system. The access management robot facilitation system is hereinafter referred to as the AMRF system.

[0019] The access management robot facilitation system uses robots that automate complex and critical processes by mimicking human actions that are typically performed manually. Additionally, the access management robot facilitation system reduces operational costs by triggering the automation of access management tasks by the robots and removing the manual intervention required for event notification and process execution.

[0020] Figure 1FIG. illustrates an access management system 100 according to an embodiment. The access management system 100 may include one or more computer platforms. The computer platforms include computer hardware such as processors, memories, storage devices, network interfaces, etc. The computer platforms may include servers or other types of computer systems that execute machine-readable instructions to perform the operations of the access management system 100 described herein. The access management system 100 includes an IAM system 110, an AMRF system 120, and an RPA system 130. The IAM system 110 facilitates the management of electronic identities for users. The IAM system 110 may include a central directory 111 of the electronic identities of individuals in an organization. The central directory 111 may be a database or another type of data storage system including a data storage device. Certificates may include attributes of individuals, such as employee identifiers (IDs), job titles, geographical locations, business unit IDs, etc. For example, when an employee joins an organization, a certificate for the new employee is created and stored in the central directory 111. The IAM system 110 may include a policy database 112 that stores policies for the organization that may be related to access management. For example, the policies may specify the target systems 140 in the target system 140 that employees should be able to access based on their roles, departments, or positions. The target system 140 may include applications 140a - 140n or any type of system, whereby access to the system by users or other systems will be managed.

[0021] The IAM system 110 may receive requests from the user 10 or the system 20 to perform access management tasks. The requests, if approved, may be executed by the system 100. For example, a request may be created by a user to create a new account for a new employee in an accounting application, or a request may be sent from an automated system to create a new account for a new employee. The request may need to be approved by one or more individuals based on the policies stored in the policy database 112. The IAM system 110 may obtain the necessary approvals to perform the task. The approvals may be executed on the IAM system 110 through a self-service user interface, or sent to the IAM system 110 or the AMRF system 120 via email or in some other form. For example, the approvals are found and accepted through emails in the AMRF shared mailbox. The AMRF system 120 may read the email approvals and generate instructions for the robot to continue with user access creation. So, the approvals may be localized at the IAM system 110, or the approval feedback may be sent to the AMRF system 120.

[0022] The IAM system 110 may include a request generator 113 for generating access management requests. In one example, if a request received from one of the users 10 or one of the systems 20 is approved, the request generator 113 may generate an access management request for the approved request. The access management request is, for example, for performing an access management task for managing access to the target system 140. For example, the access management request may be used to create, modify, or delete an account on the target system. The access management request may include attributes of the individual for whom the task is being performed. The attributes may be stored in the central directory 111 and retrieved from the central directory 111 to be included in the access management request. The access management request may identify the task to be performed, such as creating an account, and may identify the target system on which the task is to be performed. The access management request may be in the form of an email, a help desk ticket, an Extensible Markup Language (XML) message, a CSV (comma-separated flat file) file, or other formats. Existing IAM systems (such as those provided by SailPoint TM , Oracle TM or Forgerock TM ) may be used for the IAM system 110.

[0023] The AMRF system 120 receives the access management request from the IAM system 110, stores the request, and creates instructions for the robot to execute the request. The AMRF system 120 may include a request manager 121 for converting the request into instructions that can be executed by the robot and storing the instructions, also referred to as robot instructions. The AMRF system 120 may include a robot instruction database 125 for storing the robot instructions. The AMRF system 120 may include a robot instruction queue 126 for storing the status of the robot instructions. The status may indicate whether the robot instruction has not been started, is pending, completed, failed, or is an exception (e.g., a predefined or unknown exception is encountered during the execution of the robot instruction). Other information related to the robot instruction may be stored in the robot instruction queue 126. The robot instruction queue 126 may include a data structure for storing information for the robot instruction. The data structure may include a database table or a document (XML, JavaScript Object Notation (JSON), etc.) in the robot instruction database 125, or may include a data structure separate from the robot instruction database 125.

[0024] The AMRF system 120 may include an updater 122 that updates the status of robot instructions in a robot instruction queue 126. For example, if a robot instruction is waiting to be executed by a robot, the robot instruction may not have been started yet, or if the robot instruction is currently being executed, the robot instruction may be active or pending, and if the robot executes the instruction, the robot instruction may be completed. The updater 122 may also update whether the instruction was successfully completed or failed. A message processor 123 processes incoming and outgoing messages related to robot instructions. The outgoing messages may include messages to the IAM system 110 indicating the status of a request. For example, the IAM system 110 may request the status of a robot instruction, and the message processor 123 sends the status to the IAM system 110. The AMRF system 120 may push status information when a status change occurs for a robot instruction.

[0025] The RPA system 130 may include a robot generator 131 and a robot 132. The robot generator 131 may generate the robot 132 based on a process and inputs and outputs determined for steps of the process. For example, during a design phase, a process may be created by a user in an editor, such as in the form of a flowchart, and include attributes for steps of the flowchart. In one example, the process may be created according to Unified Modeling Language (UML) standards and stored in the RPA system 130. During a learning phase, the robot learns the behavior of a target system, and field elements on the target system are identified and configured as objects, for example. After the learning is completed, the robot is considered to be generated. After being generated, the robot may navigate through the target system independently and perform actions on the target system.

[0026] In one example, a robot is created to create user accounts in a target system consisting of CRM applications. Typically, to create a user account manually, a system administrator may have to log in to the CRM application through an internal portal, enter the system administrator login ID and password on a graphical user interface (GUI) login page, and then select one or more options and enter user data to create the user account. The robot is programmed to create user accounts, for example, by entering these steps via an editor. The robot generator 131 receives these steps and trains the robot to create user accounts according to steps that mimic the manual steps. One or more robots (e.g., robot 132) may be created to perform access management tasks on a target system 140. The target system 140 may include different types of applications, such as database applications, CRM applications, accounting applications, factory automation applications, cloud applications, on-premises applications, etc. In one example, the robot generator 131 may include RPA robot generation software, such as Blueprism TM, Automation Anywhere TM , UiPath TM or Fusion TM and other components not shown. The robot can be programmed to execute specific access management instructions for a specific target system. The RPA system 130 can identify a robot in the robot 132 to execute specific access management instructions based on the target system and the operations to be performed for the access management instructions.

[0027] Figure 2 An example of the computing hardware architecture for the system 100 is shown. Although not shown, additional hardware components can be used for the system 100. One or more processors can execute machine-readable instructions stored in a non-transitory computer-readable medium to perform the operations of the system 100.

[0028] Figure 2 An example of the computer platform for the IAM system 110, the AMRF system 120, and the RPA system 130 is also shown. For example, the IAM system 110 can include one or more identity access management computers, which can include an application server 201 that executes software for the IAM system 110 (including the request generator 113), and can include a database server 202 for hosting databases for the policy database 112 and the central directory 111. The computer 250 shows an example of components that can be included in a server or any computer system that can be used in the system 100 to perform the operations described herein. For example, the computer 250 can include one or more processors 251 that can execute machine-readable instructions 253 stored on a non-transitory computer-readable medium 252. The computer-readable medium 252 can include hardware storage devices such as memories, hard drives, etc. Although not shown, the computer 250 can include a network interface 254 to connect to a network, which can include a local area network, a wide area network, a public network (e.g., the Internet), a private network, a wired and / or wireless network. The networks 260 and 261 are shown as connecting the IAM system 110, the AMRF system 120, and the RPA system 130. One or more networks can be used to connect these systems. Moreover, the robot 132 can use the network to access the target system 140.

[0029] Similar to the IAM system 110, the AMRF system 120 can include one or more access management robot facilitation computers, which can include a server 210 or other types of computer systems used to host software for the AMRF system 120 and databases for the instruction database 125 and the robot instruction queue 126. In one example, a database server 211 can be used for the robot instruction queue 126.

[0030] The AMRF system 120 may include an expert system for managing the robot instruction queue 126 and performing other functions described herein. The expert system may be hosted by an expert system server 212 or another type of computer system. The expert system server 212 may be a server within the server 210. The architecture of the expert system is shown as 212a in Figure 2 . The expert system may include a computer system that emulates or works with human decision-making capabilities, but the decision-making is performed by an inference engine 213 based on a knowledge base 214. A working memory 215 may store facts on which the inference engine 213 makes decisions.

[0031] The inference engine 213 may be a rule-based engine. The rules for decision-making may be stored in the knowledge base 214, which may include a database or another type of storage system. A set of facts regarding the received access management request or the state of the robot instruction queue 126 is determined and stored in the working memory 215. The inference engine 213 determines which rules the facts satisfy, prioritizes them, and executes one or more rules with the highest priority. As is known in the art, the rule-based inference engine 213 may perform forward reasoning and / or backward reasoning to determine the rules to apply. Forward reasoning is reasoning from facts to conclusions, while backward reasoning is reasoning from an assumption to the facts that support that assumption. Examples of rule-based expert systems that perform forward reasoning and / or backward reasoning include CLIPS, ART, and KEE. The inference engine 213 may apply machine learning to the decision-making process. For example, the inference engine 213 may include a classifier or neural network to make decisions based on the facts in the working memory 215.

[0032] Some examples of decisions that the inference engine 213 may make may include determining whether the received access management request is a composite request and identifying and responding to a failed execution of a robot instruction. In response to determining that the received access management request is a composite request, the inference engine 213 creates robot instructions in the robot instruction queue 126 for a series of tasks that one or more robots 132 are to perform to execute the composite request. For example, rules or classifiers may be used to determine whether the received access management request is a composite request to facilitate the execution of a series of tasks for the composite request.

[0033] The inference engine 213 can identify unexecuted robot instructions from the robot instruction queue 126 and determine whether a remedial action can be performed to execute those robot instructions. For example, because the robot cannot connect to the target system due to a network connection failure or other reasons, the robot may fail to perform access management tasks on the target system. The inference engine 213 can learn that a specific failure message such as a failure to connect indicates a connection failure to the target system and generate an alert to fix the connection problem. The inference engine 213 can identify other reasons for the failed execution of robot instructions, such as changes in the user interface of the target system, and perform a remedial action to correct the failed execution. In one example, the remedial action can include retraining the robot to perform access management tasks based on desktop operations recorded by a system administrator performing access management tasks from their computer system.

[0034] The architecture 212a of the expert system can include software stored on a non-transitory computer-readable medium (which can include the data storage device 217) and executed by one or more processors 216. The software of the expert system can include software for performing operations for the inference engine 213, the knowledge base 214, and the working memory 215. The working memory 215 can include a memory or another type of storage system. At the same time, the expert system can be connected to the help desk system 230. The expert system can send a notice to the help desk system 230 for instructions that have failed to be executed in the robot instruction queue 126. The system administrator can access the help desk system 230 to identify the failed instructions and perform remedial actions.

[0035] The RPA system 130 can include one or more servers 220 or other types of computer systems for hosting software for the AMRF system 120, and can include a database. In one example, the runtime resource 221 is used to execute the robot 132. The runtime resource 221 can include a processor, a memory, and other storage devices, as well as a network interface for docking to the target system 140. The software for the robot 132 (including the programmed process) can also be stored in the runtime resource 221 and executed by the processor of the runtime resource 221.

[0036] According to one embodiment, the AMRF system 120 and the RPA system 130 can be a single system. For example, the RPA system 130 can have a client-server architecture, where the robot 132 acts as a client to receive and process instructions from a central application server. The central application server can include the robot instruction queue 126.

[0037] As described above, the AMRF system 120 can receive requests from the IAM system 110 to perform access management tasks for the target system 140, and create instructions that can be used by the robot 132 to perform the access management tasks specified in the requests. Figure 3 An example of information that can be included in instructions for the robot 132 (i.e., robot instructions) is shown. The information can be stored in Table 300. The robot instruction queue 126 can be composed of Table 300. Table 300 can include fields for LoginID (login ID), Operation, Status, FirstName, LastName, FullName, Password, UserStatus, and Remarks. Although not shown, Table 300 can include other fields, such as a TargetSystem field that identifies the target system for which the access management task is to be performed. One or more of the fields can be mandatory. For example, if a field is empty for a mandatory field (e.g., field value = empty), the request manager 121 of the AMRF system 120 can notify the IAM system 110 or otherwise provide feedback to it to obtain the mandatory information. Some examples of mandatory fields can include LoginID, FullName, and Operation. The IAM system 110 can generate the information or retrieve it from the central directory 111 and send it to the AMRF system 120.

[0038] In Table 300, LoginID, FirstName, LastName, FullName, Password, and UserStatus are for the users of the target system for which the access management task is being performed, and Operation and Status describe the access management task to be performed and the status of the task execution, respectively. For example, the first row of Table 300 is for robot instructions used to delete a user account from OpenAM, which is the target system for this access management task. The AMRF system 120 enables the execution of automated access management tasks on OpenAM by providing instructions for the robot 132 to perform the access management tasks via the AMRF system 120. TM The first row of Table 300 shows the information that can be included in the instructions, such as those used to delete a user account from OpenAM TM on which the automated access management tasks are to be performed. TMBot instruction to delete a user account. The username for the account to be deleted is AlphaAnderson, and the LoginID and password for this user are TestOpenAM001 and Test123!! respectively. The bot executes the instruction and updates the status to failed because multiple records were found for the same username Alpha Anderson. The bot can populate the notes field with the reason for the failed instruction. Other examples of instruction information are also shown in Table 300. Examples with an exception or completed status for the instruction are shown. If the bot is programmed to identify and handle exceptions, the status field can be changed to exception. For example, row 2 in Table 300 is marked as an exception because when the bot tried to create a user with LoginID TestOpenAM002 in the OpenAM TM application, the OpenAM TM application generated the following message: that the LoginID of TestOpenAM002 already exists (e.g., is currently in use) in the OpenAM TM application. The bot can update the notes field based on the error encountered during exception handling. Exception handling can be just providing a notification of the error encountered for exception handling, or can be more complex, such as performing a remedial task. The bot can be programmed to handle multiple exceptions. Other examples of exceptions are shown in Table 300, such as one or more required fields being empty, password length less than 8 characters, etc. Although not shown, other examples of status can be pending or in progress if the access management task is currently being executed, or not yet started if the instruction is waiting to be executed by the bot. The status and notes in Table 300 can be updated by the bot, or the updater 122 of the AMRF system 120 can receive the status information and notes from the bot and update Table 300. The status can be sent from the AMRF system 120 to the IAM system 110 or queried by the IAM system 110.

[0039] Figures 4A to 4B Method 400 according to one embodiment is illustrated. Method 400 can be executed by system 100. At 401, the IAM system 110 receives a request to perform an access management task. For example, a user can submit a request to the IAM system 110 via a request portal, or can send a message to the IAM system 110 using the request. The request can include a request to create, modify, or delete a user account on a target system in the target system 140.

[0040] At 402, the IAM system 110 determines whether the request is approved. For example, policies can specify which target systems a user is authorized to access based on their department, and the IAM system 110 can determine whether the user is authorized to access the target system based on the policy to determine whether to approve a request to create a user account on the target system. Additionally, approval from an authorized person may be required to approve the request.

[0041] At 403, if the request is not approved, a message indicating that the request has been rejected can be generated, and the reason for the rejection, such as failure to obtain approval from an authorized person, can be indicated. The message can be sent to the user who submitted the request.

[0042] At 404, if the request is approved, the IAM system 110 generates a request for performing an access management task based on the request received at 401 and sends the request to the AMRF system 120. The IAM system 110 can send the request to a predetermined network address or uniform resource locator of the AMRF system 120. In one example, the IAM system 110 can send the request to a mailbox, service interface, or request staging database of the AMRF system 120 to add a new entry in Table 300 for the request. The request can include information describing the access management task to be performed. In one example, the request can be an electronic ticket, an email, or can be in a predetermined extensible markup language (XML) format, flexible JSON, or can be in another form. Examples of the information included in the request are shown in Figure 3 Table 300 in

[0043] At 405, the AMRF system 120 receives the request from the IAM system 110 and extracts information from the received request. For example, the AMRF system 120 parses the received request to identify the information for the predetermined fields.

[0044] At 406, the AMRF system 120 generates access management instructions to be executed by the robot based on the extracted information. For example, the AMRF system 120 can create an entry in Table 300 shown in Figure 3 for the instructions including the extracted information. Instead of Table 300, another type of data structure can be used to store the instructions.

[0045] At 407, the AMRF system 120 determines whether the access management instruction is missing required information, such as information for a required field in a form. For example, the AMRF system 120 populates the fields of form 300 and determines whether any of the required fields has a value = empty. At 408, if the access management instruction is missing required information, the AMRF system 120 performs a missing information process to obtain the required information. The missing information process can include sending a message to the IAM system 110 indicating that the request is missing required information, and can identify the missing required information. The AMRF system 120 can attempt to obtain the missing information. For example, as discussed with respect to Figure 1 the IAM system 110 can include a central directory 111 of the electronic identities of the individuals in the organization and their certificates. The AMRF system 120 can use some of the information extracted from the request at 406 to query the central directory 111 for the missing information. For example, FullName can be extracted at 405 and used in the query to retrieve the UserStatus or other information for the user identified by the FullName extracted at 405 from the central directory 111. At 409, a determination is made as to whether the missing information has been obtained. If the missing information has not been obtained, then at 410 the instruction is marked as failed, such as setting the status field to failed for the access management instruction in form 300. For example, when the missing information process is performed at 408, the access management instruction can initially be marked as "exceptional" in the status field of form 300. If the missing information cannot be obtained through the missing information process (such as within a predetermined time period), then at 410 the access management instruction can be marked as failed in the status field of form 300. The comment field can be populated with information about why the access management instruction failed (such as the required information could not be obtained). At 411, if the access management instruction has all the required information, the access management instruction is marked as not yet started in the status field of form 300.

[0046] At 412, the robot in the robot 132 monitors the queue of access management instructions in the AMRF system 120. The queue can include access management instructions in form 300 that have not yet been started. The monitoring can include querying the AMRF system 120 for access management instructions in form 300 that have a status of not yet started. One or more robots in the robot 132 can monitor the queue of access management instructions, and the access management instructions can be executed in an order determined by an instruction execution policy. For example, the instruction execution policy can specify executing the oldest instruction, or the instruction execution policy can specify the priority for executing an instruction based on the target system on which the instruction will be executed or based on the department or role of the user associated with the instruction. For example, an account for a manager can be created before an account for other users.

[0047] At 413, the robot identifies the access management instruction created according to the queue to be executed at 406, and at 414, a message is sent to the AMRF system 120 to mark the access management instruction in the queue (e.g., Table 300) as pending in the status field. The message may include an operation request for modifying the entry for the access management instruction in Table 300 to change its status to pending.

[0048] At 415, the robot executes the access management instruction on the target system specified in the access management instruction. For example, the robot logs into the target system specified in the access management instruction. The robot may log in as a system administrator according to its programming to perform the access management tasks specified in the access management instruction. The robot performs the management tasks specified in the access management instruction, such as creating a user account for the user specified in the access management instruction. The robot may mimic the actions of a system administrator for performing access management tasks. For example, the robot accesses the portal for the target system. The portal may include a login page. The robot logs in as a system administrator. To create a user account, the robot selects an option in the portal to create an account and performs operations through the portal to create the user account.

[0049] At 416, the robot updates the status of the access management instruction in the queue (such as Table 300) based on the execution of the operations for performing the access management tasks specified in the instruction. For example, the robot may send a table update instruction to the AMRF system 120 to update the status in the entry for the access management instruction to be executed in Table 300. The status field may be updated based on whether the access management instruction is successfully completed, fails, or an exception is encountered. The remarks field may be updated to provide an explanation for the exception or failed execution.

[0050] At 417, the updated status is provided to the IAM system 110. For example, the AMRF system 120 determines that the status is updated in Table 300 and sends a notification message including the new status to the IAM system 110. The notification message may include additional details from the entry for the instruction in Table 300, including the information in the remarks field (if the remarks field is populated). At 418, the IAM system 110 may delete the entry for the instruction from Table 300 after receiving the updated status. For example, after receiving the updated status, the IAM system 110 may send an operation request message to the AMRF system 120 to delete the entry for the instruction from Table 300.

[0051] The IAM system 110 can also interact with a system administrator to remedy failed access management instructions or access management instructions that encounter anomalies. For example, if the updated status is failed or anomalous, the IAM system 110 can send a message such as an email, text message, or instant message to the system administrator to take remedial action. The message can be sent to the help desk system 230 so that the system administrator can respond to the failed access management instruction. The message can include information from the entry for the instruction in table 300, including remarks. The system administrator can then take remedial actions such as deleting multiple records for the same user, populating the central directory 111 with the required information for a particular user, and so on. Then, if needed, the IAM system 110 can generate a new request for an access management instruction that will be sent to the AMRF system 120 to be used to execute the access management task for the failed access management task, and the access management instruction should be able to be successfully completed by a robot.

[0052] Figure 5 Method 500 for executing an access management request is illustrated. The steps of method 500 can be performed by the AMRF system 120 to execute the received access management request and can be performed as sub-steps of one or more of the steps of method 400.

[0053] At 501, the AMRF system 120 receives a request from the IAM system 110 and extracts information from the received request. For example, the AMRF system 120 parses the received request to identify information for predetermined fields. The incoming request can be an access management request from the IAM system 110.

[0054] At 502, the AMRF system 120 determines whether the received request is a composite request. A composite request may require a series of tasks to be performed to execute the composite request. Examples of composite requests can include requests to create a user account for a new user on a target system. To allow a new user to access the target system, the user may need to be added to the active directory for network authentication in order to have access to the network to connect to the target system. At the same time, the user may need access to the shared file system for the target system to store files shared by other users. Therefore, the series of tasks for a composite request can include adding the new user to the active directory and providing permissions for the appropriate network, as well as providing the new user with permissions to access the shared file system, and creating a new user account for the new user in the target system. The rules in the knowledge base 214 can specify these tasks that need to be performed to execute the composite request.

[0055] In one example, the AMRF system 120 includes a rule-based expert system that can determine whether an incoming request from the IAM system 110 is a composite request or another type of access management request. The incoming access management request can be parsed to identify the target system, the operation to be performed (e.g., create a user account, modify a user account, delete a user account, etc.), and the user associated with the request. This parsed information can be stored in the working memory 215 shown in Figure 2 the expert system. The inference engine 213 can identify rules from the knowledge base 214 associated with the operation and the target system, and the rule can identify whether the incoming access management request is a composite request based on the operation and the target system. If the incoming access management request is a composite request, the rule can specify a set of tasks to be performed to execute the composite request. According to another example, the expert system of the AMRF system 120 can use a machine learning classifier to classify the incoming request as a composite request or another type of request in order to identify the incoming composite request, and the rule can specify the tasks to be performed for the incoming composite request.

[0056] At 503, if the incoming access management request is determined to be a composite request, the expert system of the AMRF system 120 generates access management instructions to be executed by one or more robots 132 for the tasks to be performed for the composite request. The access management instructions are stored in the robot instruction queue 126. For example, the AMRF system 120 creates an entry in the table 300 for the access management instructions to be executed. If the incoming access management request is determined not to be a composite request, at 504, the AMRF system 120 generates access management instructions to be executed by the robot for the incoming access management request and stores the access management instructions in the robot instruction queue 126. Although not shown, steps 407 - 411 can be performed for the access management instructions created and stored in the robot instruction queue 126 as needed.

[0057] After the robot executes or attempts to execute an access management instruction from the robot instruction queue 126, the status of the access management instruction from the robot instruction queue 126 is updated as described above. In some cases, the robot may attempt to execute an access management instruction, but the execution fails. There can be various reasons for the failed execution of the access management instruction by the robot. For example, there may be a connection failure, which causes the robot to be unable to connect to the target system to execute the access management instruction on the target system. Another reason for the failed execution of the access management instruction by the robot can be due to programming failure of the robot. The robot can be programmed to perform tasks on the target system. Programming failure can include the failed execution of programming instructions by the robot. A common cause of programming failure is a changed interface for the target system. For example, the robot can be programmed to mimic operations performed by a human. For example, to create a user account on the target system, a system administrator can access the uniform resource locator (URL) for the target system via a browser and can be presented with a login page, which includes text boxes for entering a login ID and password. The system administrator can enter the login ID and password for the system administrator in the text boxes to perform the necessary access management tasks on the target system. The robot can be programmed to mimic these operations of the system administrator. For example, the robot enters the URL of the target system in the browser to access the login page, and the robot is programmed to enter the login ID and password for the system administrator in the text boxes. The robot can be programmed to search for a text box with a specific name in the code of the login page (such as hypertext markup language (HTML)). If the name of the text box for entering the login ID changes, such as due to a version update of the target system, the robot may not be able to find the text box for entering the login, resulting in the failed execution of the access management instruction. The robot will need to be reprogrammed with the new text box name. Another example of programming failure can include failing to enter the correct login ID or password of the system administrator. For example, if the password changes, the robot must be reprogrammed with the new password. As discussed further below, the robot can be automatically reprogrammed.

[0058] According to one embodiment, the AMRF system 120 can determine the cause of the failed execution of the access management instruction in the robot instruction queue 126 and perform a remedial action in response to the failed execution. Figure 6 Method 600 is shown. The AMRF system 120 monitors the status of the access management instructions located in the robot instruction queue 126. At 601, the AMRF system 120 identifies a failed access management instruction in the robot instruction queue 126, such as an access management instruction with a status of exception or failure.

[0059] At 602, the AMRF system 120 determines information associated with a failed access management instruction. The information associated with the failed access management instruction can include information that can at least partially explain the reason for the failed execution. For example, the information can include an error message that can be generated by the target system or another system. For example, if the exception is due to a connection error, the robot can receive an error message related to the inability to connect, such as "Connection failed". The error message can be recorded by the robot and can be provided, for example, in the remarks field for the access management instruction in Table 300. In another example, if the login ID or password for the system administrator changes, the robot can receive an error message related to an unknown login ID or password and provide the error message in the remarks field.

[0060] Other examples of information associated with the failed access management instruction are shown in Figure 3 Table 300 in. For example, for a failed attempt to create a new user with the same name, the robot can include information such as the name already exists in the remarks field, or if required information for executing the instruction is missing, it can include information such as the required field is blank. The robot can also identify the steps that failed to be executed. For example, the robot can be programmed to navigate to a text box on a web page to enter the login ID. If the step fails, such as due to a code change in the web page, the robot can include information in the remarks field that identifies the failed navigation step.

[0061] At 603, the AMRF system 120 determines a remedial action to be performed for the failed instruction in the robot instruction queue 126, and can determine the remedial action based on the information associated with the failed access management instruction determined at 602. In one example, the expert system of the AMRF system 120 determines the remedial action. For example, the inference engine 213 can identify a rule from the knowledge base 214 based on the information associated with the failed access management instruction and other information describing the failed access management instruction, and the rule can specify the remedial action to be performed. For example, for a network connection problem, the rule can specify sending a notification to the help desk system 230 and identifying in the notification that a network connection problem has occurred for a specific target system.

[0062] In another example, the rule can specify a remedial action for a programming failure. For example, the rule can specify sending a notification to the help desk system 230 and including information about the failed instruction. A system administrator can access the help desk system 230 to perform the remedial action and / or manually execute the failed instruction. The robot can be automatically reprogrammed in response to a detected programming failure. For example, the help desk system 230 can include a recorder to record the manual execution of the failed instruction. For example, if the execution fails due to a new user interface at the target system, the recorder can record the user actions performed on the browser of the system administrator's computer to perform operations on the new interface of the target system via the browser. The recorded user actions can then be used to program the robot.

[0063] The embodiments and examples have been described above, and those skilled in the art will be able to make various modifications to the described embodiments and examples without departing from the scope of the embodiments and examples.

Claims

1. An access management system, comprising: a central directory data storage device that stores personal electronic identities and personal certificates; and a robotic process automation (RPA) system including one or more processors that execute machine-readable instructions stored in a non-transitory computer-readable medium, the machine-readable instructions including instructions that cause the processors to perform the following operations: access a process including steps for multiple access management tasks for multiple target systems, inputs and outputs for the steps determined for the access management tasks; generate multiple robots using a robot generation software, the multiple robots being used to perform the multiple access management tasks on the multiple target systems, the multiple robots being generated based on the process, the inputs, and the outputs for the steps determined for the process; receive steps associated with a manual execution of the access management tasks on the multiple target systems, wherein each of the multiple robots is trained to perform one of the multiple access management tasks on one of the multiple target systems; train the multiple robots such that the multiple robots perform the access management tasks based on the steps associated with the manual execution of the access management tasks on the multiple target systems; obtain an access management instruction from a robot instruction queue, the access management instruction including information about one of the multiple access management tasks to be performed on one of the multiple target systems; identify at least one of the multiple robots trained to perform the access management instruction on the target system; and perform the access management task on the target system via the identified at least one robot by: entering a uniform resource locator (URL) of a login page of the target system of the multiple target systems in a browser; searching for a text box with a specific name in the code of the login page; and entering a login ID and password of a user authorized to perform the access management task on the target system in the corresponding text box.

2. The access management system according to claim 1, wherein the multiple access management tasks include creating, deleting, and modifying user accounts on the multiple target systems.

3. The access management system according to claim 1, wherein the machine-readable instructions executed by the processors of the RPA system further include instructions that cause the processors to perform the following operation: mark the access management instruction in the robot instruction queue as pending before the execution of the access management task on the target system.

4. The access management system according to claim 3, wherein the machine-readable instructions executed by the processors of the RPA system further include instructions that cause the processors to perform the following operation: update the status of the access management instruction in the robot instruction queue based on the execution of the access management task on the target system.

5. The access management system according to claim 1, wherein the machine-readable instructions for training the plurality of robots to perform the plurality of access management tasks on the plurality of target systems further include instructions that cause the processor of the RPA system to perform the following operations: Program the at least one identified robot to execute the access management instructions on the target system.

6. The access management system according to claim 1, further comprising an expert system, the expert system further comprising a non-transitory data storage medium and one or more processors, wherein the non-transitory data storage medium of the expert system stores and the processor of the expert system executes: A rule-based inference engine that makes decisions regarding the management of the robot instruction queue based on rules stored in a knowledge base.

7. The access management system according to claim 6, wherein the non-transitory data storage medium of the expert system stores instructions that cause the inference engine to further: Determine the rules from the knowledge base that are satisfied by facts obtained from an access management request; and Execute the rules based on the priorities associated with the rules.

8. The access management system according to claim 6, wherein the non-transitory data storage medium of the expert system stores additional instructions that cause the inference engine to further: Determine whether an access management request that provides information for the access management instruction is a composite request.

9. The access management system according to claim 8, wherein after determining that the access management request is a composite request, the non-transitory data storage medium of the expert system stores additional instructions that cause the inference engine to further: Create an access management instruction that includes the access management instructions in the robot instruction queue corresponding to the composite request, the access management instruction being created for a series of tasks to be performed by the identified robot on the target system.

10. The access management system according to claim 6, wherein the non-transitory data storage medium of the expert system stores additional instructions that cause the inference engine to further: Determine whether a remedial operation can be performed to execute a failed access management instruction.

11. The access management system according to claim 10, wherein the instructions for determining that the remedial operation can be performed include additional instructions that cause the inference engine to further: Learn the cause of the failure from specific failure information; and Generate an alert to fix the cause of the failure.

12. The access management system according to claim 1, wherein the machine-readable instructions for accessing the process including the steps for the plurality of access management tasks further include instructions that cause the processor to perform the following operations: Access information about the process created as a flowchart in an editor, the flowchart including attributes for the steps of the flowchart.

13. A method for providing automatic access to a plurality of target systems, comprising: Receive a request to perform an access management task from among multiple access management tasks on a target system of the multiple target systems; Determine that the request is approved; In response to determining that the received request is approved, generate an access management request to perform the access management task based on the received request; Extract information required to generate an access management instruction from the access management request; Generate the access management instruction in a robot instruction queue based on the extracted information; Determine that the access management instruction lacks required information; Obtain the required information from a central directory data storage device, the required information including an individual's electronic identity and the individual's certificate; Insert the required information into the access management instruction; Monitor the robot instruction queue for a new access management instruction; Obtain the access management instruction from the robot instruction queue; Generate multiple robots for the execution of the multiple access management tasks on the multiple target systems, the multiple robots being generated using robot generation software, and the multiple robots being based on a process for the multiple access management tasks, inputs and outputs for steps determined for the process; Train the multiple robots such that the multiple robots perform the access management tasks based on the steps associated with the manual execution of the access management tasks on the multiple target systems, wherein each of the multiple robots is trained to perform one of the multiple access management tasks on one of the multiple target systems; Identify at least one robot from the multiple robots for the execution of the access management instruction, the identified at least one robot being trained to execute the access management instruction on the target system; Enter the uniform resource locator URL of the login page of the target system of the multiple target systems in a browser; Search the code of the login page for a text box having a specific name; Enter the login ID and password of a user authorized to execute the access management instruction on the target system in the corresponding text box; And Execute the access management instruction on the target system via the identified at least one robot.

14. The method according to claim 13, further comprising: Receiving steps associated with the manual execution of the multiple access management tasks on the multiple target systems.

15. The method according to claim 13, further comprising: Pushing status information when a status change occurs in the access management instruction in the robot instruction queue.

16. The method according to claim 13, further comprising: Updating a status associated with the access management instruction in the robot instruction queue based on success or failure of the execution of the access management instruction by the identified at least one robot; And Providing a reason for failure of the execution of the access management instruction by the identified at least one robot.

17. A non-transitory computer-readable storage medium including machine-readable instructions that cause a processor: Access a process that includes steps for multiple access management tasks for multiple target systems, inputs and outputs of the steps determined for the multiple access management tasks; Generate multiple robots for execution of the multiple access management tasks on the multiple target systems, the multiple robots being generated using robot generation software, and the multiple robots being based on the process, the inputs and the outputs of the steps determined for the process; Receive steps associated with manual execution of the access management tasks on the multiple target systems; Train the robots to execute the access management tasks based on the steps associated with the manual execution of the access management tasks on the multiple target systems, wherein each of the multiple robots is trained to execute one of the multiple access management tasks on one of the multiple target systems; Monitor the robot instruction queue for new access management instructions; Obtain access management instructions from the robot instruction queue; Identify at least one of the multiple robots trained to execute the access management instruction on the target system; Enter the uniform resource locator URL of the login page of the target system of the multiple target systems in a browser; Search the code of the login page for a text box with a specific name; Enter the login ID and password of a user authorized to execute the access management instruction on the target system in the corresponding text box; And Execute the access management instruction on the target system via the identified at least one robot; Update the status associated with the access management instruction in the robot instruction queue; If the identified at least one robot fails to execute the access management instruction on the target system, have the identified at least one robot provide a reason for the failure; And Determine a remedial action to be taken to execute the failed access management instruction.

18. The non-transitory computer-readable storage medium of claim 17, wherein the multiple target systems include one or more of the following: database applications, customer relationship management CRM applications, accounting applications, factory automation applications, cloud applications, and on-premises applications.

Images