Bill Dettelback's Blog

Product: WebLogic Server Archives

Desperately Seeking Identity Services

I've been out in San Francisco this week at the Burton Catalyst Conference, listening to the sessions, meeting interesting people and participating in the OASIS XACML Interop demo event (more on that in a future blog).

Yesterday I was given the opportunity to be part of a panel discussion on Identity Services.  Mark Diodati from the Burton Group spent some time prior to moderating our panel talking about Identity Services and why they are needed by the enterprise.   His thesis is that identity standards such as SAML, SPML and XACML don't go far enough towards making identity-focused services accessible to developers and end-users.  He drew parallels between the "good old days" of Web Access Management that began with custom ISAPI filters and evolved into a mature SSO market compared to the custom authorization solutions of today and the emerging market for Entitlement Management solutions.

He outlined the types of Identity Services that he's thinking of:

• Authorization (the primary identity service being built today)
• Authentication/Credentialing (mostly credential transformation)
• Provisioning (classic identity provisioning)
• Attribute/Profile (which may be tied to or part of the Auth service)

When I looked at his list I had to smile- it is almost exactly how we've laid out the security framework inside many BEA products (including ALES).  Way back in WebLogic Server 7.0 we (quietly) introduced this pluggable infrastructure for Authentication, Authorization, Role Mapping, Credential Mapping, and Auditing that let WLS interoperate with third party or custom providers of these capabilities.  Today, this framework is utilized by many BEA products and this lets us plug in ALES as the Authorization and Role Mapping provider for WebLogic Portal, Integration, AquaLogic Service Bus and AquaLogic Data Service Platform.  During the panel discussion, it occurred to me that in a small sense, BEA has been leveraging the idea of Identity Services within our own products for years.

But Mark wanted to go deeper on this idea- what exactly makes an Identity Service different from other types of services?  Well, certainly there are specific schemas and protocols we can rely upon (at a very basic level you have things like LDAP and SAML).  But how are organizations going to use an Identity Service?  Should we have a single Identity Service that performs the full gamut of Authentication, Authorization, Attribute retrieval and so forth, or should we have discreet services for each concern?  What sort of service binding is most appropriate- SOAP, REST, XML/HTTP, RMI?  How about performance- can we expect Identity Services to scale to the thousands or hundreds of thousands of users?

I think this is an interesting set of questions- and I certainly don't claim to have the answers.  But what I find most interesting is that the "Identity" folks are now asking the same sorts of questions that the "Application" folks were asking about services in general few years ago.  I'd argue that while Identity Services provide a very specific set of capabilities in your SOA they don't necessarily have to be architected or thought of any differently than your business or data services.   If your SOA needs a single, coarse grained Identity Service, then you can certainly compose it from finer grained services via a service bus proxy model.  If you need greater scalability then it's possible to load balance and distribute Identity Service implementations across multiple physical domains.  In other words, the software side of Identity Services is pretty straightforward to solve.

What really makes Identity Services an interesting challenge is how we can make them standard and dynamically understandable no matter who is using or creating them.  Because Identity Services are so focused on a few narrow concerns it should be possible to come to an agreement on how they "should" be structured.  This will open up a lot of opportunity for users of Identity Services to reduce costs when they need to interoperate with other user's services.  Think of financial institutions that are constantly merging and acquiring smaller banks- if they could simply re-direct the acquired applications to their own Identity Services this would cut out a huge amount of work integrating systems.  We can even toss around the idea of dynamically discoverable and understandable Identity Services where you don't need an architect to explain the subtle semantics of how his Auth service works.

All good stuff for a panel discussion- and by no means are we there yet.  What do you think- are you building Identity Services today?  What do they look like?  Do you think that in 5 years you'll be ripping them out for a COTS solution?  I'm interested in what you think.