Identity Management 2.0

I saw an interesting article that discusses the concept of Identity Management 2.0.

The article starts with a good recap of current, or Identity Management 1.0 capabilities, that we are all familiar with, access management, LDAP, Provisioning, etc.

Where the article gets really interesting, of course is when the Author delves into what he considers to be the revolution of Identity Management.  As the article states:

The core platform of Identity Management 1.0 capabilities such as authentication, authorization, user provisioning, password management and the like has provided a base for improving security and automating manual processes to drive down operational costs. Identity Management 2.0 extends the core platform to offer stronger forms of authentication, risk-based authorization and fine-grained entitlements, user provisioning based on roles and relationships, as well as the ability to virtualize identities, all in an effort to address the next generation of requirements and threats.

What, to me, is even more interesting is that an old IdM technology, Virtual Directory, is considered to be a core component of IdM 2.0.  Dubbed “Identity Virtualization,” the article likes using this technology for creating customized user repositories for applications. Maybe the oft-quoted “Year of the Virtual Directory” is finally coming to pass.

It should be interesting to see how this concept matures over the next 12-18 months, particularly as we’re going into what many consider to be tight times in the IT world.

Import / Export Peculiarities

Recently our IDM team  has noted some interesting issues with the importing and exporting of tasks in NetWeaver Identity Manager. I think it is important to bring these issues forward so that other members of the NetWeaver IDM community can benefit from our experiences.

1. We have observed that when tasks are exported and then imported into another configuration there can be some issues with attached NetWeaver IDM Repositories. 

   For the benefit of those unfamiliar with Repositories in NetWeaver IDM, a repository is a special container within NetWeaver Identity Manager that holds constants and variables used in working with and connecting NetWeaver IDM with Source and Target systems that exist in the Enterprise.

   What we have found is that upon importing the tasks into the new IDM environment the NW IDM Administrator can make changes to the Repository (examples would be in changing LDAP Starting points, Host IPs, or ODBC connection strings) and they will seemto save.  However the changes will not be reflected in the back-end table.  The way around this is to go into the affected task node and change the value in the Repository drop down to something else and then change it back.  This forces NW IDM to commit the values back to the database.

   It would appear that there is a back end issue in the import that is not causing the repository information to be properly updated.  While not the biggest issue to be encountered in the world, I’m sure that this will get in the way of some projects as configurations are ported from one environment to another.

2. On a related note, we have noticed that when importing tasks from one environment to another the while dispatchers can be mapped from one environment to another, they are not automatically turned on.  This can slow down promotion of an IDM implementation from one environment to another. 

   While NW IDM does include functionality to turn on all jobs for a selected dispatcher from the Management node of the Admin console, this does not bring the context in which the jobs were assigned to dispatchers in the original configuration, and is therefore not terribly helpful in the typical production environment. Right now the basic workaround is to create a stored procedure that will properly assign the dispatchers to their jobs. Of course, the risk here is that mistakes in working with base tables can be quite costly so extreme care must be taken here.

Thoughts on the Use of the Term “Stateless Identity”

Gerry Gebel at the Burton Blog has a post titled Can Applications Become Identity-Stateless.  He points out the costs of user provisioning are high and that enterprises would be better served if it could be done away with.  He goes on to say the following:  “For several years, the industry has promoted the use of shared infrastructure services for IdM functions – but only a moderate level of success has been achieved when compared to the potential.”  He then floats the term “stateless-identity” as a possibly better “descriptor” to communicate the desired end state, viz., applications which keep no state on identity and instead share a common store.  The rhetorical question that follows is it in fact a better term?  Consider the concept of ‘stateless’ in software.  When state is not maintained, the software does not keep track of current data, for example, user choices, configuration settings or executed transactions.  When software is stateless it lives in an eternal present, ignorant of what came before and ignorant of what follows.  It carries nothing with on moment to the next.   If we apply this concept, then the meaning which follows from applications using stateless-identity would be applications whose “awareness” of identity is limited only to the current call to the identity service.  Metaphorically, it would be like a man who every time he leaves the room and returns must look up the name of his guest.  Obviously this not what he has in mind because applications must keep persistent information about who is using the application and what they are entitled to do and what limitations they have.  Even if the application is not storing this permanently, it must maintain the state for it’s own functioning and hence stateless-identity lacks descriptive power at best and at worst may cause confusion of the term’s actual meaning such as what occurred in the database world with “relational”.  I understand the goal which is to remove redundant identity data from applications and lower costs, however,  creating new terminology  is a questionable choice when other terms which possess greater descriptive accuracy already exist and are widely known.  I can’t see where this adds any additional communicative power that would speed adoption, but I have been wrong before.

Whitepaper Download

For those of you looking to download a copy of Strategies for Creating an Authoritative Store, it is now available from the SECUDE Global Consulting website.  The paper was initially released through Business Trends Quarterly.

The paper is intended to be a discussion of creating an Authoritative Store for use in an Identity Management Infrastructure.  It provides a good starting point for those considering implementing or revising their IdM landscape.

Gnothi Seauton

The title is latinized Greek which is often translated as “Know Yourself” or better “Know your Limitations”.  We are certainly exploring our limitations watching the markets sell off.  Looking at the cascade effects cycle around the globe never resting, bring to mind nature’s answer to excess. We are witnessing the reward of hubris.  The more regular and predictable things appear to be the more likely one is to assume continuing stability; we grow over confident with each success when in fact success teaches us nothing.  Success fattens us like hogs to be slaughtered.  In failure we learn, that painful negative feedback loop that shakes our “certainty”, that teaches us we are never fortune’s darling.   Lessons of previous generations should remind us of how we should handle risk to the enterprise, avoid over optimization, build in redundancy,  and “don’t bet the farm”.

“The Truth About Identity Theft”

MSNBC, has an excerpt from a book (no, it’s not the Communist Manifesto) “The Truth About Identity Theft” by Jim Stickley.  It interesting read for some I’m sure but I have become thoroughly bored with penetration testing, social engineering and the like.  It’s only difficult when you first start and you have no skills.  After awhile it gets easier and easier.   What is really difficult is securing systems and what is even more difficult is determining what to protect and what not to protect.  Where are the risks that can cascasde and bring the whole company down?  They’re there and they may only be obvious in hindsight.