Governance of things – II
IGA versus CMDB
(Identity Governance Administration v.s. Configuration Management Database)
In my previous blog, I discussed the topic of managing the digital identity of devices, robots and other things. As I pointed out, effectively managing the identity of things is relevant from 2 viewpoints: the ‘thing’ getting access & the ‘thing’ as a managed object.
The Dual Role of ‘Things’ in Identity Management
The ‘thing’ as an accessing entity
It needs to use an account, in order to get access, to be able to perform tasks as a subject, or actor. Managing the identity cannot be done similarly to managing human identities managed in the human resource joiner-mover-leaver processes. Things are not onboarded in such a process, but thing identities are created in a change, managed in the change management process. The change can be a procurement of a device, or development of a device, or configuring of an RPA (Robotic Process Automation) and there may be multiple parties performing the change. Changes will also be put to the test in testing environments and acceptance environments before being put in production.
The ‘thing’ as a managed object
The thing is a configuration item. It is managed in the configuration management database, through the already mentioned change management process. Furthermore, it is owned by someone who can provide access to a human actor who needs to maintain, read, or configure the thing, RPA (Robotic Process Automation), device, component, robot or whatever we can envision.
Access Protocols for Things: How It Works
As I explained, managing the identities of things are done in the change management process. Access granted to the thing is done in this change management process (including all documentation and test results). And the owner of the thing will grant access to others, like service consumers, making use of the thing-capabilities.
If the thing needs access, a digital identity will be created in the platform that the thing will use. An RPA identity will be created manually and conform to the naming convention for service accounts, like rpa_do_a_customer_analysis.
Why IGA Isn’t Suitable for Non-Human Accounts
The Limitations of Identity Governance and Administration (IGA)
In the previous blog, I focused on the account management processes to reach the conclusion that Identity Governance and Administration (IGA) solutions should not be used to manage non-human accounts. IGA solutions will find the digital identity that has been created during the reconciliation phase (while importing data from target systems). And the IGA administrator will classify the account as a non-personal account, to prevent all kinds of business processes, such as certification and being triggered incorrectly.
The Inherent Differences Between Managing Human and Non-Human Identities
But there is a more fundamental reason why managing non-human accounts in an IGA system is not effective or efficient. And that’s related to the difference in the very nature of things versus humans.
The Concept of Composition in Things
Composed Things: A Complexity Beyond Human Identity
In the article ‘Managing non-human accounts’ by Graham Williamson and me, we show differences between human and non-human accounts. But we didn’t mention the concept of composition.
Real-world Examples: The Transformative Tractor
Humans consist of one persona. And one person will always be one person. The one person can have multiple accounts, but that’s an authorization issue, not an identity issue.
A thing may not be just one thing. A thing can consist of multiple other things. And the assembly will act as one subject, one actor, one identity. The subcomponents are part of the thing. Think of a tractor. The tractor in itself consists of many parts. But a farmer can change the function of the tractor as a whole by changing parts for other special-purpose components. These things by themselves can perhaps not even operate autonomously. So, one tractor can change its nature.
Context Matters: Identifying the True Nature of Composed Things
However, these other parts do not even belong to one tractor, other farmers can also use the component. That means that it’s not possible to identify the function by just looking at the main component (the tractor, perhaps, the hitch, the power take-off, or whatever part looks essential). You need to look at the composed agricultural thing in the context of the workload, to identify its being.
The Flexibility of RPAs and Their Management
Composed RPA (Robot Process Automation)
The same is true for other things. Their nature may vary according to a change. An RPA may perform data harvesting activities, but it may be configured to destroy data after a change. It will not do so by itself, it’s all based on the configuration. You need access to the component to make the component work.
The Stakeholder Dilemma in RPA Management
Some may say that the line manager who is responsible for an RPA changes its role using an IGA system, but that misses the point. The thing has an owner, who needs to consult other stakeholders about the thing’s activities, its character and its working time. The other stakeholders are accountable for granting access to the thing, it’s not the operator of the accountable thing.
A thing is an actor. However, it is only allowed to act as long as the owners of the components that the thing is working on allowing it. For this reason, it is not just giving a role to a thing. It is changing the operation and thus changing its nature. It is a change.
The way to manage these components is using a Configuration Management Database (CMDB). It can register relationships between components, create a hierarchical overview of parts and things, and change the compositions via the change management process.