Earl PerkinsIt seems that keeping a blog current requires focus and discipline, areas in which I am clearly deficient– my apologies for the lengthy time between entries. It would be better to make excuses, but I won’t do so, since this is important.
Our upcoming IAM Summit in San Diego in November gives rise to reflection on the state of IAM technology and design, and will be discussed there through a number of venues. In this blog, I’d like to introduce one of those reflections. It may seem obvious to many of you, but I tend to document the obvious just to be sure. In this case, let’s take a brief glimpse at the boundaries of IAM.
While there may be some disagreement about the definition of IAM still, many would agree that the market of products consists of a “core” of products that address access, administration and ‘intelligence’ and then a more nebulous set of technologies that are currently considered to be IAM but are also still evolving, but still addressing those key areas. In the core is directory services, user provisioning, web access management and enterprise single sign-on. Most IAM suites today have at least these solutions as a basis in one form or the other.
The other IAM solutions inside the boundary are role (lifecycle) management, entitlement management and different kinds of analytics solutions for correlation, analysis, forensics of IAM information. Identity proofing is often considered in the IAM boundary as well. If I have not mentioned your favorite technology, by all means let me know. Most of these solutions are in the early stages of development when it comes to feature sets, scale, audience and the like.
At the boundary of IAM are what I term “adjacent technologies”, those products and services that complement, supplement or otherwise share something with those products and services inside the IAM boundary. This includes governance, risk and compliance management (GRCM), network access control (NAC), security information and event management (SIEM), privileged user management (PUM) and data loss prevention (DLP) to name a few. Some IAM suite vendors have acquired some of these products and are developing a tighter form of integration between them and IAM. I even think some of them would prefer to expand the boundary of IAM to entirely include them.
In any case, the boundary is volatile, porous, even unstable. It is not possible at this stage to say with any measure of reliability which feature sets of adjacent technologies may even be incorporated into IAM products permanently, resulting in overlapping functionality. It is important, though, for customers to be aware of the progression of IAM up to and past the boundary to ensure they align their strategy properly when using these solutions. You may already have one or more of the adjacent technologies in-house and in operation and will be interested in knowing how they may help you with a future IAM implementation– or vice versa. Knowing the boundaries of IAM today helps plan more effectively for its use tomorrow.
Category: Uncategorized Tags:
3 responses so far ↓
1 Rob Lewis October 2, 2009 at 8:30 pm
Hi Earl,
I am following your posts with interest because we do something that is in the IAM realm. However, I am having a little trouble reconciling what we do with your descriptions of inside the boundary and adjacent technologies, since we touch on entitlement management, analytics solutions, PUM and GRCM. We say that we do an authorization component post-authentication, for simplicity, but we don’t do authentication ourselves.
We do a new, more user friendly implementation of MLS that scales into a full cross domain solution with commonly used enterprise systems.
Any thoughts?
2 Earl Perkins October 14, 2009 at 2:43 pm
Rob,
to show my ignorance, i have to ask what “MLS” means. your description also sounds a bit marketing-like, since i don’t know it means. not trying to sound confrontational, i suppose it would require more discussion.
the boundary isn’t hard and fast– that’s one of the reasons why it keeps expanding and, in some cases, contracting. it also doesn’t preclude any one vendor from attempting to reconfigure the “logical feature set”, i.e. create a product whose features may come from several different existing product sets, but by the nature of combination make more business sense for the client– as well as the architecture to deliver it. it’s the wild west at the boundary.
3 Rob Lewis October 15, 2009 at 12:21 pm
MLS, or multilevel security, matches security ranking of files with the clearances of users. Access controls in secure installations, usually found in the military or intelligence setting.
I am sure that I have seen mentions of it on John Pescatore’s blog in the past.