HR, your source of identies?

For a few years I had the pleasure to work for Novell. I did several consulting projects with Identit Manager and even have some experience with the predecessor DirXML. After the Novell era, I worked for an independent service provider and got to know Sun Identity Manager and IBM Tivoli Identity Manager. This just to say that I have at least some experience in the world of Identity Management and directory synchronisations.

Matt Flynn is chiming in on the virtual directory versus meta directory “blog wars” that have been going on earlier this year. You can catch up here, here, ah, also here and then here as well.

In that post Matt Flynn starts with a simple scenario: there is an HR database, an Active Directory and a custom build SQL identity store. So far so good, that looks like something standard and simple. Then he continues by requiring that the HR database is the primary source for account creation and status.

This is where I have to disagree, strongly disagree. For years IDM product vendors have been telling us that the HR database should be the primary source for Identity information. This is just not true. The HR platform can not fulfil this role of primary source. The platform has been built and is driven by the need to manage the employee status of people and make sure they are paid properly and in time. This difference between what the HR platform actually is and what IDM product vendors want it to be, becomes more visible if you look at the following typical issues:

  • New employees are not entered fast enough in the HR system. The IDM system can’t act on events if they don’t happen in time.
  • Some of the attributes kept in the HR system are of lesser importance to HR and therefore typically are of lower (data) quality. The IDM system however depends on correct and up to date values for these attributes.
  • When employees migrate internally (to a different department or business division) the HR system often lags behind in changing the employee records. It also rarely models the typical transition periods involved in migrating.

For me these are all signs that the HR system, at least as they are managed today, should not be used as a primary source for account creation and status. In fact, the HR system should probably be “just a slave” of the IDM system. Leave the HR system for what it is: a system for managing the legal and financial aspects of an employee.

If you use the HR system as your primary source, you will soon find yourself implementing numerous ugly hacks and workarounds to compensate for low quality data and events that are either triggered too late or without enough detail. Demanding that the HR department should get their act together and improve is not a good solution. Doing identity management is not their job, they manage the legal and financial relationships. That’s just a part of the Identity. It’s the IDM product that should manage the identity and inform the HR system of changes that are relevant to the legal and financial aspect of the relationship.

None of the current IDM product vendors however have a product that can serve this role. As far as I know, most of these products are expensive data synchronisation tools with some workflow and UI layers on top. As the years pass by, I am wondering if any of these vendors is ever going to radically change and improve how (enterprise) Identity Management is dealt with. Since the first of these IDM products, over 10 years ago, not much has changed. It’s just more of the same.

Single Account without OpenID or Carspace!

In the country I live, Belgium, the various utility providers have discovered the Internet as a place to interact with their customers. Over the last two years I received letters from all of my utility providers (electricity, gas, internet, telecommunication …) that I now can manage my account on their website.

Great! 24/7 I can login to their site and check my current balance, buy more features or do whatever that needs to be done.

Today however, I am running away from them. Each and every one of those sites requires me to register, including creating a new account with user name and password. Not to mention how difficult it often was to correlate my existing products with that new online account.

Almost every time I have to login to those sites, I forgot the user name or password I picked at registration. I do try to keep a single user name for that kind of accounts but that is not always possible due to conflicting rules or my default user name already taken.

Today I realized that I am not even bothering anymore to remember the user names or passwords. Somehow I found a way to use my Google Account on all of them. Instead of supplying my user name and password to that site, I use the following procedure:

  1. Surf to the site
  2. Immediately pick the “Forgot user name or password” link, I don’t even bother trying to log in
  3. Enter my Google email address somewhere (all those sites offer to mail you your existing or new credentials, either based on email address or based on user name)
  4. Wait for the mail to arrive in Google
  5. Open it, click on the link inside
  6. Create a one time password and log in with it
  7. Use the site

The only account I have to remember is my Google Account. Now I just wait for someone to write a Firefox add on that automates most of the above.

So if the following companies would be so kind to read up on OpenID so I don’t have to act like a fool with the above procedure: Electrabel, Telenet, Belgacom, Nuon, Proximus, Luminus … and probably others I forgot.

OpenSSO Identity Services

OpenSSO (Sun’s attempt at open sourcing some of there access management solutions) has published a first draft of some Identity Services. It’s a four part article with the first two parts already published: authentication and authorization.

When I first saw this announcement, I was very interested and almost rushed over to those articles. After a first read however I was somehow disappointed. The interface definitions are very simple, a little too simple. The authentication API merely allows you to send over a username and password and it’ll return you some kind of subject identifier. The authorization API suffers from the same faith: feed it a URI, an action and a subject identifier and it will tell you if that subject is allowed in or not.

Everyone who knows something about the specifications and standards surrounding Identity Services, know that there is more to it. A lot more. You can leave stuff out to make things simpler, but I have this feeling OpenSSO has left out too much. Some of the things I feel are missing or not that good:

  • Abstraction from authentication methods, it’s just username and password now. Aren’t we all working very hard to get rid of those? What about SAML, WS-Trust tokens …
  • Proper countermeasures for obvious threats like replay, message insertion, message modification, message deletion … Please, don’t answer “oh, we’ll just apply SSL to the transport”, that gives you only part of the solution. You do need controls at the message and API level as well.
  • The ability to tie authentication to a certain context (just returning a subject identifier leaves that aspect to the calling party). What if I would like to bind a positive authentication to a particular resource? The subject identifier might contain that information, but their specification is very silent on that aspect. For the moment, that identifier is an opaque handler.
  • The returned subject identifier is currently used to bind all services together, but the specification doesn’t say how it is protected and how I can verify it’s validity. If these services are placed on the Internet, I see a lot of security holes.
  • What about time windows for the validity of the authentication?

And finally, I wonder why these Identity Services from OpenSSO don’t attempt to place a higher level API around what we already have from OASIS (SAML, WS-Security, WS-Trust, WS-SecureConversation …) and Liberty Alliance (ID-FF, ID-WSF …).

Not being you

Lately there has been a lot of talk about anonymity and pseudonimity. Just read around on the blog agregation Planet Identity.

There is a strong interest in walking around on the Internet, participating in transactions and doing whatever without people knowing who you are. Most federation and user centric protocols have some sort of support for this. Most of it driven by Kim Kameron’s identity law on minimal disclosure: only disclose that part of your identity that is absolutely necessary.

I happen to be a fervent player of World of Warcraft. For those of you who don’t know, that is an MORPG (massive online role playing game). Divided across hundreds of servers, players can create avatars, give them names and create an entire new personality in the virtual world. That sounds like pseudonimity heaven to me. You can literally recreate an entire new identity, new in every aspect. You can choose a different avatar from eight races. A human character versus an orc based, how different can it get?

Using that avatar you can play whatever you like. A female, suspicious priest or a strong and eager hunter. You can even start multiple characters, all completely different. This is in fact what most players do. Sounds easy to create different identities right?

Surprise … no it isn’t. Even seasoned players have complained about how difficult it is to create two different identities. Even when you have all the tools at your disposal: new avatars, new names, different clothing, different professions, different cities … It still isn’t easy to change identity. After a few weeks of playing their new character, most of them eventually are discovered: “Hey, aren’t you also playing this other character?”

You might think “Why?” Well, it seems there is one thing you cannot change, one thing none of the MORPG, games nor federation or user centric can change: YOU.

No matter who hard you pretend, no matter what tools you have at your disposal for creating a new identity, it is still you. You might be different in the way you look, in your name but you are still you. You betray yourself by talking, walking and liking the same things. Even if you try hard and pretend to like other things or walk differently, there are so many details of you, that are you, that people recognize and will blow your cover after a while.

Even if Cardspace of OpenID gives me anonymity or pseudonimity, I will probably betray myself the moment I start posting on the forum or buy my favorite music.

The hard part of anonymity or pseudonimity is not in the identification or authorization process, it is afterwards, when you start posting in forums or do stuff on the Internet. Thereby exposing the real you. Remember how search queries on AOL (or Google, Live …) could identify you?

Driver’s License to be the Next Debit Card

I just came across this article on Business Week “Use Your Driver’s License as a Debit Card“.

The intent is to use your drivers license for payment transactions. By coupling your license number to your bank account, they make your drivers license suitable for payments. Just swipe it, enter your personal code and the money is transfered. This way the shop owner doesn’t have to pay credit card companies those exorbitant fees and can carry less plastic around in your wallet.

Sounds like a good idea? Yes and no. Yes, since you don’t have to carry yet another card for doing payments. No, because they are overloading the drivers license to do stuff that it wasn’t made for.

We all know the the verification process for the US drivers license is shaky yo say the least on most states. The REAL ID act tries to improve this situation by introducing extra measures. But in the end, the verification process remains faulty. It is just less faulty but still faulty enough. Piggy backing a payment authorization is not such a good idea. You could couple the bank account of John to the drivers license of Jeff. And what happens if your drivers license is revoked? No payments anymore?

Their aim, reducing the number of plastic in your wallet, is worthy. Their modus operandi isn’t. Piggy backing one type of identification and authorization on to another type is often dangerous. Not always bad, but often questionable.

Why not introduce a blank card that can store multiple virtual ID cards like your credit card, drivers license … You just pick and unlock the one you would like to use. That reduces the plastic weight while still separating identities and authorization when needed and when you wish. Sounds like user centric identity in your wallet.

Identity Ownership

During lunch on the first day of the Identity Open Space in Brussels one of the attendants mentioned that he wanted more power over his identity since he owns his own identity.

He used the following example: when he send his resume to a potential employer, he wanted to be informed about what happened to that resume. That sounds fair to me, it contains private and potential sensitive information. However, he went even further and said that when the recruiter ranked the resume, he wanted to be informed of that rank and why it was ranked like this. His reasoning was: that resume is part of my identity, an identity I own, so I am entitled to that information.

Immediately I was thinking about this article. The article explains in great detail the difficulties you have with “user consent” and “owning your identity”.

If I meet a person, I build up an identity of that person. Part of that identity is based on my perception: the way he walks, talks and behaves. Other parts of that identity are based on what that person told me: his name, phone number, telephone number … Reasoning that the other party also owns the identity I created based on my perception is a bridge to far for me. I should not be forced to disclose my perception about a person because it is somehow connected to him.

You don’t own your identity, in fact, without other people around you, you don’t even have an identity. For me, identity only exists in a relationship with some other party. That identity is the perception that other party has about you. That perception might be based on information it got through several channels. In all cases, you only own a small part of that identity if you own a part at all.

The only identity you really completely own is the identity you have built about yourself in the relationship you have with yourself.

I would like to blog more about this idea of identity only existing within the context of a relationship. Feedback is more then welcome.

Two Must-Reads

It has been a while since I have blogged about identity. That does not mean I haven’t been actively thinking, reading or discussing the subject. Recently I came across one recent and one older article on identity, I consider both articles a must-read.

The first one, the oldest, was written by Bob Blakley and discusses the feasiblity of the first law of identity “User control and consent”. A very good read. It touches on most of the difficulties with “user-centric” identity systems. In the Identity Gang discussion group I have touched on the feasability of identity meta-systems and the forces that could make or break it. This article however does a much better job at this. No matter how interesting identity meta-systems are, I yet have to see some good arguments that proof that current silos (Google, Yahoo!, MSN …) would want to give up the control they have over your personal (identity) information. Or will we end up with a Hobson’s Choice. They support the identity meta-system and will play along with specifications like OpenID or Infocards … as long as they are the identity provider issuing the assertions.

The second one, titled “Law of Relational Symmetry” was posted only a few days ago on the Identity Blog of the Burton Group. It builds upon the reservations made in the first article and gives a, well thought out, try in explaining why user-centry identity systems are very hard to accomplish and where potential solutions may be found.

So, grab some quality identity time and go read these articles!