Identity and Access Management (IAM) is complex. When I’m working with customers, you can get lost quickly when trying to describe all the different capabilities and functions of IAM. Especially when you start talking about Identity Governance (IGA) and all the connected applications, it can become a bit unwieldly. Given I always try to keep things simple, I fall back to Newton and his laws of motion when talking IGA.
Specifically, Newton’s third law of motion states (in summary):
“For every action, there is an equal and opposite reaction”
Why is this important when looking at IGA? When you break down IGA, ultimately its just a system of inputs / outputs or actions / reactions. To put this into perspective, you can look at all the different flows that may or may not happen in the context of an identity, or you can start breaking this down into actions / reactions (see the below diagram).
To put this into perspective, we can start breaking this into sub actions / events and down-stream reactions.
- Authoritative Sources:
- Action: Receive a new user event from HR / authoritative source
- Reaction: Process JML operations and provision appropriate targets
- Requests:
- Action: Request for access is APPROVED
- Reaction: Process the user object / role change and provision appropriate targets
- Attestation:
- Action: Completed periodic review of access and submitted appropriate job changes
- Reaction: Remove access and make necessary updates based on periodic review
Granted, this is a pretty simplistic view of IGA and the flow of operations. But, focusing too much on the complex we start having a breakdown in the action / reaction mindset and lose sight of what needs to be done. For example, most people I talk to have miss-conceptions or missed expectations of what their IGA purchases can do given they have limited integrations (reactions) or inputs (actions). This is due to the focus on a specific action/reaction and not the bigger picture.
When starting, or re-evaluating your IGA component of your IAM program, take a step back and start looking at inputs / outputs and what needs to happen. Don’t focus on the ‘connected’ component, but what needs to happen. Where you are lacking today (action or reaction side), introduce manual inputs / outcomes to help enhance the capability and strive to mature / automate in the future as you build out your program more. By doing this, you’re starting with at least the action / reaction that needs to happen, and you can figure the HOW to make it happen (manual fulfillment, RPA, connectors) as you grow.
Using this approach (simplistic as it may be), now you’re getting a complete picture and lifecycle of your identities in your IGA component. From there, you can start moving out to the enforcement capabilities and how they consume the reactions from your IGA tooling.
