Having been in the IAM space for enough years to remember when the idea of a metadirectory was still "cool", I spend a lot of time thinking about where the industry is going, and more specifically, how we can enhance the value that IAM brings to our customers. Recently, one such customer articulated a requirement for an identity governance solution that not only provided them with a global view of access privileges, but allowed them to see who was accessing a particular server or file share.
It occurred to me that most modern identity solutions do a great job of providing a view into who has access to what, but not what they are actually doing with that access. These are two completely different concepts, but from a technical perspective, they don't necessarily need to be.
A standard identity management suite ships with a connector framework that exposes a common interface to abstract the logic that interacts with the target system. These interactions generally comprise standard IdM events such as account creation, modification, enablement, disablement, retrieval and deletion. Obviously, each connector "type" is required to invoke native API calls.
Since vendors are already building connectors that manage accounts across a wide range of target systems, how difficult would it be to extend these connectors to inspect logs on those same systems, and then correlate each log entry to an identity object in the same way that we already do for native accounts? For example, in addition to pulling a list of local accounts from a UNIX server and correlating them to a person's identity, a UNIX connector could expose a method to pull the server logs and update identity records with information about what actions each user had been performing on that server.
It's just a thought, but it strikes me that being able to see who is doing what is as foundational to robust identity governance as being able to see who has access to what.