Can Applications Become Identity-Stateless

Blogger: Gerry Gebel

Over time, we evolve our thinking about different aspects of the identity management market by sharing thoughts internally at Burton Group within the IdPS team – evidenced by the way we discuss the importance of relationship management, which really came together earlier this summer. Another way to accelerate this process is to get out of the office and exchange ideas in person with peers and colleagues in the industry. This past week I had the chance to spend some time with my old friend Felix Gaehtgens and we talked a lot about identity management – but this was after we settled any arguments about Belgian chocolate, Cuban cigars, fine teas, Belgian beer, and politics. Well, maybe we didn’t settle anything but just argued some more…

One of the questions Felix and I were trying to answer was: can we just stop doing user provisioning? It costs a tremendous amount of money, time, and effort to buy and implement provisioning systems – is there another way to approach this? The root cause, of course, is that applications, operating systems, etc typically require a local identity and security context – and provisioning is the way the industry establishes that context by creating accounts and setting entitlements on the local system or platform. Even contemporary applications excessively embed IdM functionality, and identity data into business applications. We can excuse legacy application developers this offense, but why does the approach persist? 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. Maybe the industry needs to consider a different concept that explains the goal state better – we settled on “stateless” as a possibly better descriptor to use.

The idea came into clearer focus the next day when I was invited to join the folks from SURFnet for a session to brainstorm how they should change the SURFfederatie service to meet future demands of the higher education market in a changing world. I was fortunate enough to be joined by identity luminaries Eve Maler and Andre Durand in this effort and it was a great session. Based on conversation during a breakout meeting, I thought we should start suggesting that applications should be stateless, from an identity perspective. That is, application designers should start with the premise that no identity data is stored locally (there will be reasonable exceptions) and this information, data, and policies are resolved during the run time process. Applications that can go any time to an explicit identity service doesn't need to be provisioned; it just needs to be connected. Therefore, if you start with the premise that applications are identity-stateless, you need to consider what identity services are required for fulfillment. Many applications in use today do not perform authentication locally – this is quite common. If applications are truly identity-stateless, we can take it a lot further.

Eventually the conversation will get around to the composition and level of abstraction for the above mentioned identity services. I’ll leave that topic to my colleague Kevin Kampman, who will be providing the latest update next week at Catalyst in Prague.

Comments

[Steve]

Great idea - although the next step is creating state for identity!

[dexter]

Someone really decided to put on their thinking cap, great going! It’s fantastic to see people really writing about the important things.

[Radovan Semancik]

Some applications can (and should) be indentity-stateless and some cannot. I think your direction is good, however there are maybe more cases for statefullness that you would expect.

I've talked about that in a conference back in 2006:
http://storm.alert.sk/work/papers/files/2006-infosecon-contribution-final.pdf

[Eric Norman]

My bank doesn't store my account number locally?

Wow! I want to see how you plan to do that.