Identity Governance and Intelligence (IGI) allows enterprises to provision, audit and report user access and his activities through life cycle, compliance and analytics capabilities. While IGI revolves around typical entities like Users, Entitlements, Accounts, Groups, Roles etc., we are now introducing the notion of a Bot as an entity to manage. There has been a lot of discussion off-late around the use of Bots in enterprises and the need for Identity and Access Management (IAM) products to do something around the same. For instance, I am putting down a few excerpts from Gartner Identity and Access Management Summit 2018, in this context:

• Robotic Process Automation (RPA) will have a profound impact on IAM.
• Technical professionals should extend Identity Governance and Administration (IGA) to include software robots as a new identity type.
• RPA introduces robotic software whose identities and access must be managed and controlled.

As part of the current blog, we are extending the notion of Bot Governance to Bots deployed in a neutral Robotic Process Automation (RPA) Provider. The IGI version used for this discussion is IGI 5.2.5.1 (IGI 5.2.5 FP1), and the RPA Provider that we are integrating with happens to be Automation Anywhere ®.

A pre-cursor for this integration was available here, where we showed how we could tie Governance around a IGI native Bot. In this blog, we are extending that notion to IGI governing entitlements of Bots hosted in an RPA provider like Automation Anywhere ®.

Bot Background

Before we go deep into the article, introducing a few concepts.

What is a Bot?

Bot / roBot is essentially an entity viz. a script / batch file / a piece of program that could perform a set of prescribed steps when told to do so. Take for an example, an end-point which is accessible only via the User Interface. For such an application, a good Bot would be a set of steps which help in:

• Login to the UI.
• Reach the concerned panel.
• Fill in the requisite parameters.
• Complete the request.

What is the need for a Bot?

Enterprises ideally love to automate all the operations in the organization. They just don’t want to rely on manual intervention for any process. While this goal looks reasonable, it is accompanied with a set of technical challenges. The main challenge being, integration of desperate systems. There are just tons of ways in which two systems are reachable. For example, some systems could expose REST Services while some could just be exposing Java APIs, some would be exposing a CLI to interact, whereas for some systems UI might be the sole way to interact. Consequently, enterprises resort to human intervention to make the whole system work.

To put it in the context of IGI, let’s talk of an access provisioning scenario. Many of the end-points / target systems are reachable using the Brokerage Tier of IGI. However, there are still a lot of end-points for which there are technical limitations of even writing a custom adapter. In such cases, administrators typically configure the workflow for Manual Provisioning. As far as the workflow execution is considered, the Operator manually provisions requests based off a Form handed out to him.

Enterprises want to dig out such pockets to the extent possible, introduce Bots to mimic human behavior and then improve the automation percentage of their enterprise and consequently operational efficiency of their enterprise.

Taking the same example forth, an administrator can introduce a Bot that mimics the same set of steps that an Operator would do and hook this Bot in the Workflow. That way, the manual intervention of the Operator is completely avoided.

Why do we need to govern Bots?

From the description of the Bot, it is evident that Bots can be handy for automation. However, Bots can be risky, if there is no tab on what they are doing. At the end of the day, Bot is a script, a bunch of commands and who knows what side-effects can be caused by the execution. Unknowingly, Bots become identities of their own, who have got a power to execute any step on the end-points, without revealing their identity. That’s the biggest threat of having Bots in the organization, i.e. Accountability. It should be pretty clear on who owns all the actions being performed by the Bot.

Alternatively, there should be a clear indication of the entitlements and activities of the Bot and an assurance from the system that corporate policies are not being violated by the Bot. Likewise, there has to be governance around the Bot Owners, since the risk level of a Bot Owner might escalate owing to combined entitlements of the Bot Owner and the Bot.

RPA Providers

There are a set of RPA Providers in the market which facilitate enterprises to create and deploy BOTS. One of them happens to be Automation Anywhere. This blog is an attempt to demonstrate how we could tie a layer of governance around Automation Anywhere. The same can be extended for other RPA Providers as well.

The main integration aspects around IGI-Automation Anywhere integration that show up in this blog are:

• Bot identity life cycle management
• Bot access controls
• Bot SoD
• Bot access certification
• Bot Credential management

Bot Identity Life Cycle Management

Automation Anywhere provides the right platform to host the Bots needed by enterprises. However, to ensure that we tie a governance layer around the Bots, we need to get the Bots in IGI. The Bots are extracted from Automation Anywhere and reconciled into IGI.

Before we get the Bots, some ground work to be done in IGI:

• Launch IGI Admin Console and create a new User Type, named "Bot".
• All Bots will be reconciled into IGI as a User of Type "Bot".
• Create a new Organizational Unit with the name "BotOU".

Once we get the ground work done in IGI, the next step would be to get the Bot metadata from Automation Anywhere and import the same into IGI:

• Extract the Bots into a CSV Feed:
  • For the scope of this discussion, we've written an SDI (Security Directory Integrator) based Assembly Line (GetBot.xml), which does the following:
    • Fires REST Services against a running instance of Automation Anywhere to extract the BOT Data.
    • Processes this data to tune into the format of a typical CSV Feed of IGI.
    • Dumps that data in the form of a CSV.
    • Am attaching a Sample CSV (BotFeed.csv) that is retrieved using this mechanism.
• Once the BotFeed.csv is generated, consume it in IGI, using the default CSV Connector. Here's an old reference (IGI 5.2) of configuring a CSV Connector for IGI. In principal, the steps should be the same, just that the User Experience & UI are quite different in IGI 5.2.5.x.
• This can be a repetitive process, whereby you can use the CSV to update the latest status of the Bots from Automation Anywhere into IGI, be it adding new bots, modifying existing bots OR removing bots.
• Here's a preview of how you could list down the Bots available in the system, once the BotFeed.csv is successfully reconciled into the system:

Figure 1. Successful Bot Feed

• A few notes while following the above steps:
  • To be able to run the project on SDI in a new system, we have to make sure that:
    • The control room credentials present in the text file (TestRequest.txt) needs to be updated as appropriate. This file is referenced in the Assembly Line GetBot.xml, in the project folder workspace.
    • The control room URL has to be updated wherever it is present inside the assembly line. In the Assembly Line GetBot.xml, the Automation Anywhere is running on desktop-3r06lfk at port 80. Replace those instances with the instance of the Automation Anywhere in your deployment.
    • The paths to access the text files that are needed in the project have to be updated. This essentially means fix the absolute path of TestRequest.txt as appropriate.
  • Things to be kept in mind to make sure Automation Anywhere is up and running:
    • Microsoft® SQL Server® has to be up and running.
    • Control Room admin cannot login to client. Hence, a client user account, with appropriate license assigned, should be made to login to client application.
    • We have to make sure that control room is listening on to the port that it is assigned to.
    • The bots on the client application have to be uploaded to control room, otherwise they won't show up in the Bot Listing, in the control room.

Bot Access Controls

Once Bot data is reconciled into IGI, in the way, prescribed above, you could potentially do every single operation with a Bot, that you would normally do with a user. You could setup BirthRight Accesses to Bots and you can also regulate them.
For e.g. you could select the "Printer Manager" bot and create an account on say a ticketing tool like ServiceNow™, which would entitle this bot, access to the ServiceNow application:
Figure 2. Accounts for Bots

Likewise, you can add other entitlements as well. Another point to note is that, in the above example, we are doing the account management / entitlement management using the Admin Console. It is very well possible that we can have workflows which can be opened up for Bot Developers, so that they can request for access to specific Bots on specific applications, per business need. There can be approvals configured in the workflow, to validate and approve the access requests.

BOT Segregation of Duty (SoD)

The way, users are subjected to SOD checks, we could very well subject Bots to SOD checks as well.

For e.g. here's a view of the Access Request flow for a Bot, which shows a Green Risk Posture for a given Bot:
Figure 3. Low Risk Bot.

Now, say if I select a sensitive access for that Bot, OR for that matter any access that will create an SoD violation, then the risk posture for that Bot turns Red immediately, as shown below:
Figure 4. Bot with High Risk.

BOT Access Certification

Now that we understand that Bots can have accounts on the end-points, they can have entitlements on the end-point, it becomes imperative that there has to be a periodic review of the Bot entitlements. The way, we drive certification campaigns for Users, we can very well drive certification campaigns for Bots as well. Here's a glimpse of the Entitlement View of a Certification Campaign specifically for certifying the accesses of a given Bot:

Figure 5. Bot Certification.

A reviewer can very well revoke the unwanted entitlements and allow only those entitlements which are needed by business.

BOT Credential Management

Lastly, a very critical aspect of why IGI helps governing Bots. Bot Developers typically write Bots and deploy the same in Automation Anywhere. There's no way an admin can decipher the source of the credentials of a given Bot. For e.g. If a Bot needs to login to ServiceNow and generate a report on the tickets opened say in the last 1 month, then it definitely needs credentials to authenticate. The very big question is who gives out those credentials to the Bot Developer and how do we really ensure that the credentials are not getting misused.

With IGI in place:

• Any access that the Bot Developer desires for his / her Bots, they have to place an access request in the tool.
• Post approvals, accounts will be provisioned for the Bots on the requisite end points.
• Any use of these credentials, in the Bot would be for legitimate use.
• Later on if the Bot is no longer needed in the organization, admin can very well de-provision the accesses of the Bot.
• Thereafter, even if the Bot gets triggered, it won't be able to authenticate to specific end-points, since the Bot Access was decomissioned.
• With this approach, the health of the system is always maintained in the right stride.

All in all, IGI serves as a very good tool to add a slice of governance around the Bots deployed in typical RPA Providers like Automation Anywhere.

In case of any added queries, do feel free to reach out to:

• Ramakrishna J Gorthi (rjgorthi@in.ibm.com).
• Vubbara C Reddy (vubreddy@in.ibm.com).

​