HR has valid reasons to keep the same employee ID for individuals that work for the company. Figuring out years of service and retiree benefits are good examples of why one employee ID is tied to an individual for the life of their service to the company.
In our IDM solution, we deal with re-hires, temporary workers, and summer workers all the time. Fortunately, HR’s system sends us a myriad of status codes that we interpret. HR tells us when an individual is termed and will also tell us when they have been rehired. When they are rehired, they do not get their old account back, they get a new account. The user gets a new identity number as well that is associated with their active HR employee ID.
So for your scenario of querying the system for new hires, I would look not to the HR data but the Identity Management data. Also, IDM has a better understanding of who potentially has a PC and who doesn’t then the HR system. Roughly a third of our company (10,000 employees) use kiosks compared to their own PCs. IDM data can be used to filter out these users.
Another interesting twist to the scenario is contractors who become employees doing the same job. Contractors are brought in and if the manager likes them, they are hired as an employee. A contractor could be working for the company for a long time before they become an employee. They already have a computer and will not need one when they become an employee. Ideally, your asset management system is tied to your identity management system so that changes like this can be managed seamlessly.
Dave
|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary 
[1,407]
Women 4 times more likely than men to cough up personal info [589]
Japan's 10 funniest tech-related commercials [Videos] [407]
Throwing away a promo CD is "unauthorized distribution"? [1,265]
Adults too quick to dismiss educational video games [682]
Attack of the iPhone clones [Slideshow] [578]
10 things IT needs to know about AJAX [1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow] [409]
|
|
How to handle rehires
Hi Dave. When an employee leaves my company, their relationship with the company doesn’t end; it just changes. They are still benefits recipients. So we update their value(s) in the multi-valued relationship attribute in our directory. They still have access to some company web sites (e.g., the employee classified ads). They can still authenticate at the company and have their identifier asserted to the websites of our benefits providers. If/when they rehire, it’s not really reassigning their employee ID; rather, it’s just updating their relationship attribute in the directory.
Exactally
This hits the nail on the head. "Former Employee" is a different affiliation from "Complete Stranger". Now there may be deprovisioning rules as to when someone would transition from "Former Employee" to "Complete Stranger", but that's got to be done on a company by company basis.
Looking forward to best partice on id reuse
Thanks for the very even handed response on this issue. Looking forward to following the discussion.
Identifier Recycling in OpenID has been solved....
Hello,
Nice post. I work for Vidoop and we run an OpenID provider at http://myVidoop.com
We support the OpenID 2.0 specification which has specific guidelines for dealing with recycling identifiers. There is a good description of how it works here: http://developer.yahoo.com/openid/faq.html
...OpenID 2.0 specifies that OpenID Providers append URL fragments to the end of an OpenID URL as a generation identifier. The entire OpenID URL with the fragment, if present, should be used to identify the user. For instance, the following two OpenIDs are unique and represent different users:
* http://openid.example.com/username#aa
* http://openid.example.com/username#bb
Anywho, hope this helps!
Cheers,
Kevin
Re-hires?
Hi Dave,
great debate, but it all seems a bit off-topic.
The real answer is that identities are usually created in trusted sources as a result of a business process: eg HR, Customer Info System, Contact Management system, shareholder register and so on. These identities are then subscribed to by the IAM system - it doesn't usually create its own identities (except for some self-register web apps). So IAM must reflect its trusted sources, not just the data but also the process - if the business rule is to reissues the identifier, then so be it (but we would still try to get them to avoid it, of course).
Lately the approach used by most new business systems overcomes this problem. They have a "person-id" as an internal unissued identifier (like a GUID) that provides the flexibility for multiple salary numbers per person if the business decides to do so - see the latest Oracle Financials for a good implementation of this approach.
IAM then provisions 'person-id' with basic access (building, LAN, email, phone, etc) and then provisions role-based access depending on certain attributes such as salary id, job-title and status.
Some of this discussion seems to be treating the LDAP identity directory as a data-warehouse (DW). This is not recommended - better to 'publish' the attributes and let the DW 'subscribe' to it. To use SQ-type queries on an heirarchical file that was designed fto do quick authentication is not a smart thing.
And as usual, OpenId is "discovering" that a problem that has already been resolved in the real world, then applying an amateurish solution. The Oracle approach above can be applied, but recycle its identifiers, or even identities - I don't think so!
Allan Milgate
Linking IDs
I would imagine assigning a new ID at the time of re-hire and linking the old ID to the new ID can be a fix to the re-hire issue. This can be a one-to-many relationship too.
Linking IDs and new ID
Yes, a re-hire could be given a new ID but it just would multiply the relations in many cases and sometimes it might even be beneficial but also a headache for DBA, bigger than it already is..
Because the value of an ID is to track the relation between business and person (or whatever the ID means, sometimes a company, a community, etc) and the relation may be in future, now, past or (one or many) combinations of now and past and of course "back to the future" again. Simple? Add to that the role(s) the ID represents at any time, add to that the different tax, work, salary, etc laws, contracts (personal, union, etc), currency changes (a global company), personal and location info, and so on - which all change over time. AND which all have to be available years, by law, for payments and billing, for auditing and/or security reports, business statistics and forecasts, etc. Now, add to that the benefit rules, discounts, etc which are allowed or calculated based on roles, locations, laws (local and/or global), years in company or as a customer or both, and of course change all the time. Now top of that there comes of course security - roles have security but it may not be the same for all in same roles all the time (time of day, day of week, current location, etc rules), change by time, business, other contracts, etc and all the time!
This is just a (very) simplified example of an ID in real life - there is more and it gave at least to me a headache to model so the system would also be manageable and efficient now and in future, and not just work because when you start having (many!) thousands in your system, changing every day you better to think manageability and performance! We do it later thinking is a sure way to a disaster!
Double user identities
Besides the rehire problem the are situations when a person has several positions in a company with separate user identities.
This means that you have to distinguish between the person and the user identity/identities.
In the IM solution we designed, the person was related to one or several positions, user identities, and organisational units.
In that way we could handle several dimensions in a dynamic and effecient way. But it was not done in a directory but in a specially designed database.
Post new comment