Cool Solutions

The Future of Identity Management Is Pull?



By:

August 2, 2010 12:27 pm

Reads: 231

Comments:3

Score:0

Guest post by Ben Goodman, security specialist, Novell

Burton Group Catalyst Conference in San Diego last week was thought-provoking as always. There was great discussion about IT management strategies and identity. My biggest beef with the conference is that it overlaps with Black Hat every year and they have yet to invent a way for me to be in two places at once. To be honest, one prediction we heard this year stood out, and it’s based on the presentation titled “The Emerging Identity Architecture,” given by Gartner’s VP and research director for Identity and Privacy Strategies, Bob Blakley. I appreciate that it isn’t easy to read the IT tea leaves in order to predict the future, but this time I think he may have gotten it wrong.

According to Blakley’s assertions, identity management today is based on a “push” model as IdM applications centrally store user entitlements and those entitlements are “pushed” out to the applications so that users with the appropriate rights can access them (we are aligned on this part). Blakley contends that this model is broken and that a new identity paradigm needs to emerge now. One where user access privileges are “pulled” at the time of use to the application or service the user wants to consume (not so much here).
For such a paradigm to work, entitlements and access information about users would need to be gathered and maintained across many identity stores, some from outside an enterprise, some hosted internally and others potentially within a cloud environment.

I think this idea is overly ambitious and may never reach fruition. First, consider how provisioning is conducted today. When a user requests access to a resource, there are a series of management requests and approvals that must be completed. Typically, access entitlement changes are updated in directories, and those directories express access rights through connectors to the specific end-point applications and resources.

What Blakley asserts is that we move on from identity connectors that bridge identity stores with end-point applications. He’s arguing that connectors are fragile, unwieldy and that the industry needs to get away from them.

That’s an incredibly broad brush, and one I think does not hold true with all connector technology. I’ll detail why below.

The way around identity connector architecture that Blakley advocates is to put into place a “pull” architecture. There are two potential ways to achieve this. The first is to have all identity information externalized to the point where the applications have virtually zero identity intelligence. This approach would require that each time a user accesses a resource, something inside that resource would make a call out to an entitlement management system to see if the user has legitimate access. That strikes me as nothing more than externalization for the sake of externalization: with little benefit returned.

The other method is to take the opposite approach. Which is to build a tremendous amount of identity intelligence into the application so that it understands what its entitlements are; understands whether or not a user has access rights; and understands where to go ask for access if the user isn’t already authorized. In order for this to work, the entire current paradigm of how authentication and authorization is managed would have to be re-written.

I just don’t see that happening. Here are a number of reasons why:

  1. The current system isn’t as broken as Blakely asserts. Certainly, like all technology, the current way of managing enterprise identities can be improved. And, frankly, most of our customers are happy with the power and flexibility connectors we provide. Certainly, they want more, and would like to see technology enhanced. But in no way does it resemble a broken and fragile architecture. Which brings me to my second point.
  2. Synchronization and connector pains. Gartner is lumping all connector technology into a single bucket as “push” technology. The challenges associated with connectors still exists whether a push or a pull model is employed. The real answer to connector challenges is to get application vendors to adopt more standardized mechanisms in both allowing for access and modification of the data that the applications maintain. Not all enterprises that leverage identity connectors are experiencing the hurt Gartner painted. Especially when they choose a vendor that utilizes very strong data management technologies. We will have a follow on post explaining why Novell’s data management technology is unique and why many of the pains Garter cited such as lack of scalability, rigidity and lack of cloud readiness are simply not realized by our customers.
  3. Application developers need to focus on the application. Application developers, whether in house or ISVs need to focus on building the best, most robust and sustainable applications they can – as quickly as they can. They don’t have the bandwidth, and in many cases the expertise, necessary to build the identity intelligence needed to achieve push into the application. These groups are focused on making applications. They are not interested in embedding a ton of authentication and authorization logic into their applications: but that is exactly what this approach would require.
  4. Which comes first? Let’s assume an enterprise wants to embark down this path and implement a “pull” identity architecture. Currently it’s not even possible for them to re-develop their identity architecture because there is no standard for them to write to. The standards that would be necessary for all applications and identity stores to communicate do not yet exist and would still need to be adopted once they do. It’s a classic chicken and egg situation.  Will IdM vendors adopt these interfaces and capabilities, prior to the existence of applications that could leverage it? Would applications be written to leverage an interface not yet supported by IdM Vendors? Also, as the standard that would have to inevitably arise changes — each application would have to be updated to be able to continue to fully interact and function within the identity ecosystem.

The smarter — much more realistic approach — is to leverage processes and technologies that are already here now. The idea is to put into place a sustainable, scalable, identity and access management environment that is extensible enough to address potential future identity management models and standards as they arise — and to do this without modifying, or hardwiring identity management into the application.

Fortunately, this is possible today with Novell Compliance Management Platform. And in a post I’m working on now, we will detail exactly how we can achieve many of the benefits of Bob’s scenario with “off-the-shelf” Novell Technology.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , , , , , , ,
Categories: Expert Views, General, PR Blog

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

3 Comments

  1. By:Richard Baker

    Unfortunately I was not able to attend Bob’s presentation, but pull technologies are already available as emerging standards. Take a look at http://www.sifinfo.org. This is a set of standards that are being adopted within some education establishments. This provides the option for a service provider to pull information from an identity or provisioning provider. When I first engaged with the education market I was challenegd by the approach as I came from the enterprise space I originally thought that push was best for timeliness and integration with legacy apps. But applications do exist that can operate in a pull world, either in a batch mode or real time. It comes back to the business and operational requirements. If you need to manage the update of 1M records for the start of a school year this is a very different problem to nightly enterprise churn. It may also provide some insight into ways that companies might manage M&A. As with most options a middle way often brings advantages.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  2. By:shrdlu

    I think the pull model could work IF the applications are allowed to write their own (individually labeled) attributes to a central identity store. They could also agree to use other applications’ attributes if the business rules align.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  3. By:xargs

    To a certain degree a lot of apps do use a pull method when using a directory server such as AD. More granular permissions can then be mapped on to groups within AD. Or perhaps I’m not familiar with the use cases being talked about here.

    That being said, it seems like the bigger issue with IdM is that it’s not integrated with the business process, and exists as its own niche industry for some reason. Why can’t this just be collapsed into say BPM?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Pingbacks

  1. From: Johannes Ernst’s Blog » Push vs. Pull in identity — sounds familiar?

  2. From: links for 2010-08-06 • Bare Identity

Comment

RSS