Sometimes a clarification succeeds only in further muddying the waters. That's what I did last week, not for the first time either. Probably won't be the last, though. It's concerning that issue of re-using identifiers and re-using employee ID numbers. At the risk of further muddying things, let's take a final look (for now) at the issues.

I think we can all agree that re-using an identifier so that it could possibly point to two different entities is a bad idea. This is the issue that riled the OpenID community, and continues to smolder beneath the surface, bubbling over from time to time.

The issue we were discussing, though, was the use of the same identifier for an employee who leaves an organization and then returns. The alternative is to issue a second (or subsequent) identifier each time the employee is re-hired. This could mean a single entity with multiple identifiers.

Those are two different issues.

It’s the employee with multiple identifiers that I was trying to address, and the OpenID problem (of a single identifier for multiple entities) was really a red herring dragged across our path to discovering a solution.

As a number of you pointed out – and as I overlooked – even in the enterprise an entity will have multiple identifiers depending on the number of namespaces (HR, Finance, IT, applications, etc.) they are involved in. You can choose one as the enterprise-wide identifier, but be sure to think it through so it is unique.

Since there are legitimate reasons why some namespaces must tie together all instances of an entity (whether those instances have different identifiers or different time frames) there should be an identifier which uniquely identifies each entity over time. For example, even after someone has terminated their employment it is often necessary to keep their identifier tied to various documents as originator, contributor, editor, modifier, etc. for regulatory or compliance reasons. On the other hand, there may be legitimate reasons to be able to isolate the particular employment cycle of the entity who has more than one such cycle.

The answer, of course, is remarkably simple. So simple that I completely overlooked it when talking about using the employee ID number to indicate hire date. The answer? Don’t do it! Don’t use an identifier designed for one purpose to fill another unless you can be absolutely sure that no anomalies will arise – and build in error trapping in anticipation of the day that the anomaly occurs.

Whitepapers

• Boost Productivity While Cutting Costs with Next-generation Collaboration
• Deploying Virtualized NetWare on Linux Whitepaper
• Driving Business Success Through Workgroup Choice and Flexibility
• Toward More Flexible, Next-Generation Collaboration Solutions
• Collaboration Tools and Organizational Success Whitepaper
• The ROI and TCO Benefits of Data Deduplication for Data Protection in the Enterprise

View more SECURITY whitepapers

Webcasts

• Creating a high performance workplace with wireless networking
• Harnessing the power of communications to increase workplace performance
• Making data centers the IT strategic focus
• Protecting assets and employees with IP Video Surveillance
• Stay out of the headlines: Detecting and preventing network intrusions
• Transforming the Enterprise WAN Edge: Video from Cisco

View more SECURITY webcasts

Special Reports

• The Evolution of Network Security
• IP address management in 2008 - six things to know
• The self-managed network

View more SECURITY special reports