At EIC there was a very interesting panel discussion regarding an „Identity bus“ idea and how to concretisize it (http://www.id-conf.com/sessions/562).
I just want to pick some small parts and write about some of the thoughts I catched from the discussion and what came to my mind afterwards.
First: there are some different understandings about what an Identity bus should be in detail. However the main idea is quite clear: to get rid of the authentication and authorization mess for any application: Just plug in your application into the Identity Bus and the users could immediately login and authorize with the application. So this means to introduce another general abstraction layer (for authN/authZ only) between the Application and the Identity providers.
This should be a protocol (because that's what is working on bus'es). Or what else could it be?
The bus should provide authentication, authenticated sessions (as token, whatever). It also should contain routing, caching, and mapping mechanisms. We are not talking about a real physical bus here (so you don't have to add another hardware device to your server). It is a virtual, software based bus. And it should work not only on a LAN base but across the Internet.
Now some additions that have not been part of the discussion (in detail):
There could be the following device types plugged in into the Identity bus:
identity providers
service providers
auditing and logging devices (logging everything that is going on on the bus)
network components: gateways/gatekeepers for routing, (auto)-registration of the devices, mapping/translation and caching.
The bus should also contain a logout mechanism (global/local session kill).
Let's take this a bit further by adding some ideas (however I think that these are not really new, I just didn't have the time to grab for them on Google).
I think for the authentication/authorization-part shibboleth can be seen as a start of such an identity bus. It is even called “authentication middleware”. In most of the cases shibboleth uses SAML for authentication/authorization handling, but it has all other opportunities built in (infocard,kerberos,pki,...).
But there are some problems that currently prevent shibboleth from being a real “identity bus”:
- The "silo" problem: You may get verified and true information/attributes about a users identity at the moment of logon but when the user did not log on a while you can not be sure if this attributes are still correct (or if the user still exists).
So there is no (real/easy) scalability in the current implementation of shibboleth and the federative AuthN-approaches in general. This is why the big vendors are laughing about it.
But however I think the problems can be solved:
the wayf problem: to get rid of this, you need to add the authentication target (where to authenticate) to the 1st authentication step. So we need kind of an additional factor. If we are working with some authentication device (pki,smartcard,yubikey next generation etc.) this should be an easy thing although there might be high costs on adapting the hardware-based infrastructure.
The metadata problem: This is the biggest part. The first step could be to implement kind of on demand metadata requests or to somehow make the metadata more dynamic and federation-independent. There are already some thoughts in this direction. However the basic question "whom shuld I trust" has to be answered somehow. We definitely need a chain of trust for that. It's already used in federative contexts, and it is also used on a global level for the SSL-certs and does work quite well.
- The "silo"-problem can be solved with a bus based architecture quite easily, but only by a (daily, whatever) check-back, or by "broadcasts" from the IDPs.
There are still lots of other open topics. But I think the Identity Bus idea can be a leading direction for the ID-based development in the next few years. And it is, in fact, a lot more than just another abstraction layer.
