Tag Archives: Identity Bus

Microsoft and SAML 2.0

According to Don Schmidt Microsoft is finally going to support SAML 2.0:

At the Professional Developers Conference this week Microsoft is announcing the beta release of “Geneva”, the codename for its new claims based access platform.  This platform helps developers and IT professionals simplify user access to applications and other systems with an open claims-based model.  “Geneva” helps developers to externalize user authentication and identity processing from application code by using claims that are obtained with pre-built security logic that is integrated with .NET tools.  “Geneva” helps IT professionals to efficiently deploy and manage new applications by reducing user account management, promoting a consistent security model, and facilitating seamless collaboration across departmental, organizational and vendor boundaries.  User access benefits include shortened provisioning lead times, reduced accounts, passwords and logins, and enhanced privacy support.  “Geneva” implements the Identity Metasystem vision for open and interoperable identity, and includes built-in support for standard federated identity protocols.

A fundamental goal of “Geneva” is to extend the reach of its predecessor, Active Directory Federation Services, and provide a common identity programming model for developers of both web applications and web services.  To maximize interoperability with clients and servers from other vendors, it supports the WS-Trust, WS-Federation and SAML 2.0 protocols.  To maximize administrative efficiency “Geneva” automates federation trust configuration and management using the new harmonized federation metadata format (based on SAML 2.0 metadata) that was recently adopted by the WSFED TC.

This is very interesting. It looks like in the Geneva release what was ADFS will now support SAML 2.0 along with WS-Federation. It also looks like Cardspace, Zermatt, and ADFS are going to be combined into a single “platform”.

Interesting times.

Advertisements

Configured Identities

Here is an interesting post from Glenn O’Donnell of Forrester that argues the CMDB should contain identities (hat tip to Ryan Shopp):

Well, actually vice-versa! The configuration management database (CMDB) is a hot topic these days in IT. With my arrival at Forrester, I am ambitiously building upon the solid foundation of thought leadership my colleagues have built on CMDB. One topic I wish to address is the notion that people (yes, you and me) are configuration items within the whole CMDB discussion.

I find it interesting that nowhere in the article is the word identity used. I wonder if that was intentional? 

The more I work in the CMDB area (the product I currently work on, ChangeGear, has a CMDB) the more similarities I see with the concepts being discussed as an Identity Bus.

It’s a shame there aren’t more people that work on both the IdM and ITSM sides of the fence. Both groups are trying to solve some of the same problems but with different technologies and standards. I think some convergence between these two areas, especially around Identities, would be a very good thing.

Identity Infrastructure or Duct Tape?

Radovan Semančík has some interesting thoughts on this recent Identity Bus discussion. Radovan sees a whole lot of Duct Tape:

All the “buses” are just that. A duct tape. The best product for temporary fixes ever made. But you cannot really build an infrastructure on duct tape, can you?. How you would make a water supply system for a big city using a duct tape? How long can that last? Can you duct tape an electricity distribution system?

 My question is if all these buses go somewhere. What is the systemic solution that we want to achieve? What is our vision? Where we want to go? As the Cheshire Cat observed, if we do not know where we want to go it does not matter which road we take.

On the one hand I think Radovan is too hung up on the name “Identity Bus”. I think what we are discussing here is more of an Identity Layer that is intended to be ubiquitous in an enterprise infrastructure. Of course as I have pointed out before, we already have that in AD. What we are discussing is how to improve on that.

On the other hand Radovan is spot-on about one of my frustrations about the Identity Bus discussion. There is not nearly enough discussion about what such a system would actually do. So far the general consensus seems to be that an Identity Bus is:

  • Enterprise Ubiquitous (i.e. an Identity Layer)
  • Based on Claims and Claims Transformation
  • Multi-protocol (i.e. supports LDAP, SAML, XACML, SPML, etc)
  • Supports both push and pull models

 OK, fine. Those are all laudable goals. But what exactly are we going do with all that? Is this a solution looking for a problem or is there a real vision? Is the Identity Bus a real infrastructure, or is it duct tape?

BTW: Why is duct tape like the Force? There is a light side and a dark side and it binds the Universe together.

IGF and LDAP, again

Phil Hunt has some good thoughts here on my recent post about IGF and LDAP. Just to be clear I am not suggesting that IGF replaces enterprise AD. But as I understand the some of the IGF proposals around the Identity Bus concept, IGF APIs would replace LDAP APIs on the client side. At least for new applications. From Phil’s post:

The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It’s a situation that cries out for standardization.

As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.

Let take a concrete example. Suppose an IT shop wants to build a replacement time card application. If the requirements are that the web app looks the current user up in AD and routes the time card to the person in the manager field for approval, we know what the problems are. There could be data integrity issues where the manager field is not getting properly updated. There can also be compliance issues.

So IGF can tell the app developer what the data quality is for the manager field. But what is the business value? They still need the information regardless of the data quality. Yes there is a compliance issue. But again, what is the business value? The manually process of noting the field access by the compliance person only needs to happen once.

Switching to a new identity API is going to require tools and training. That is going to come out of the project budget and schedule. What are you going to tell the project manager to convince him to commit budget and schedule?

We all agree that for enterprise identity data AD is the clear incumbent and that isn’t going to change anytime soon. But on the application side LDAP is also very likely the incumbent. And you are trying to change that.

All I was trying to get across (not well I fear), if that displacing an incumbent technology is very difficult. I personally hope it happens on the client API side. But my past experience working on identity service standards tell me it’s a big hill to climb.

I have failed to communicate

Clayton Donley of Oracle makes some excellent points here about my “Elephant in the Room” post.  But I have apparently done a poor job in communicating the whole point of the post. In his post:

What I think his post misses is the fact that most LDAP access in most applications is poorly written, even when using ADSI or ADO to talk natively to Active Directory. I can’t count the number of virtual directory deployments that we’ve sold to help customers in environments that were nearly 100% Microsoft (ADO/ADSI-enabled apps talking to Microsoft AD). Many of these deployments were to get around bad schema assumptions, others were to get around topology issues or forest boundary issues.

While we sell virtual directory technology, we hate making our customers pay money to solve such tactical issues. We want to be layering on higher-order value.

So when Phil Hunt or others talk about the Liberty IGF project, what they’re really saying is that we want a better way to give application developers a way to code something in a way they understand and can do well rather than a native access protocol that requires specialization. So while LDAP isn’t going away and everything from virtual directories to identity buses will need to support native access over LDAP to be successful, not looking at what developers are learning and using every day would be a mistake.

Keep in mind that developers must integrate with a LOT of technologies to build an enterprise application or portal. For example, a portal may be integrating with HR, CRM, and ERP systems. That integration is increasingly happening via web services. Giving these developers a mandate to use a completely different type of technology to integrate identity will only make identity more specialized and less standardized and understood over time. That is a recipe for disaster.

I did not mean to imply LDAP was a better choice that Liberty IGF. I was in fact the BMC rep to Liberty TEG and am very supportive of their work. I also agree there are a lot of problems with LDAP and how developers use it.

But having been involved at some level in the standardization efforts of DAML, XRPM, DSML v2, SPML, SAML, WSDM, OATH, Liberty, WS-Trust, WS-SecureConversation, and WS-Federation. I have spent a lot of time working on identity service standards and developing implementations of those standards at several different companies.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they  know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

Of course AD isn’t all identity in an enterprise. But for extranet identities you will have to justify why IGF or some other identity service is better than just throwing in an ADAM, OID,  or OpenLDAP instance. Or even a virtual directory like OVD or OptimalIdM VIS (for the .NET centric customer). The enterprise architects know they already have a wide variety of tools and APIs to leverage LDAP. They don’t yet have those for IGF and other identity services.

Bottom line – identity services will not reach the level of adoption to where you could say there is an “Identity Bus” until there are compelling business cases made for it. Enterprises not only have to adopt the identity service standards, but they need to make vendor support of those standards a selection criterion to drive adoption.

The elephant in the room

In the latest installment of the Great Meta-Virtual-Directory-Identity-2.0-Bus-Hub Debate, Dave Kearns is groping elephants. Dave allows that we are all really talking about the same Meta-Virtual-Directory-Identity-2.0-Bus-Hub, but like the three blind men and the elephant, we just can’t agree we are all groping the same animal.

Kim Cameron elaborates what features needed for the Meta-Virtual-Directory-Identity-2.0-Bus-Hub. Kim’s requirements:

  • By “next generation application” I mean applications based on web service protocols.  Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP. 
  • Developers and users need places they can go to query for “core attributes”.  They must be able to use those attributes to “locate” object metadata.  Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
  • Applications need to be able to register the information fields they can serve up. 

Today’s virtual directories just don’t do this any better or any worse than metadirectories do.  Virtual directories expose some of the fabric, just as today’s metadirectories do, but they don’t get at the big prize.  It’s what I have called the unified field of information.  Back in the 90’s more than one analyst friend made fun of me for thinking this was possible.  But today it is not only possible, it is necessary.

Phil Hunt throws in his requirements Meta-Virtual-Directory-Identity-2.0-Bus-Hub:

  • There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
  • Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of “authoritativeness”. Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn’t authoritative over an attribute, it probably shouldn’t be storing or managing that attribute. Instead, this “non-core” attribute should be obtained from the “identity network” (or metaverse as Kim calls it). An application’s “core” data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  • Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application’s requirements.

Since Dave first brought up elephants, let me point out the elephant in the room no one is talking about; AD. For the vast majority of enterprises AD plus other identity services already serves the role of the identity hub. It is your company’s identity store, authentication service, authorization service, and attribute service. It is used to identity enable your remote access gateways and your email servers. If you are using a Virtual Directory, chances are AD is at least one of the stores behind it. Other companies such as Quest and Centrify have developed products to extend AD authentication to wide range of heterogeneous OSs.

Vendors have created products for provisioning from AD out to disparate systems. When I started at Access360 AD didn’t exist yet and our strategy was to get the buy-in from HR up front because the HR system was the source of all identity information. By the time I started doing provisioning at OpenNetwork Technologies, we assumed that customer already had an HR feed into AD.

While I like both Kim and Phil’s vision of what a Meta-Virtual-Directory-Identity-2.0-Bus-Hub should be, the big question customers are going to ask is why? Companies have spent an incredible amount of money building out AD as their identity hub. What specific cost saving or new capabilities will they achieve by implementing this vision?

Kim thinks web services are the answer. But what specific web services and what specific advantages do they offer? Will they be easier to adopt than LDAP? If we think LDAP hard for developers, wait till we try explaining WS-CombinatorialExpansion. 

Phil thinks a key requirement is to abstract the protocols and schemas. Is that really an important requirement given the near ubiquity of AD?

I know this isn’t pleasant to hear, but AD is the incumbent. It’s nearly everywhere. It’s scalable to millions of users. The LDAP protocol is efficient and mature. It’s supported by countless applications. Before a customer considers displacing or adding another identity layer on top of AD they are going to need real cost savings or additional capabilities and order of magnitude over what they have now.

That’s not to say LDAP is the perfect solution or even the best solution. But if we are going to propose a better one we have to say specifically why it’s better. With real examples that customers can relate to. With cost savings and capabilities they can’t reach today with AD.

Are we getting on the bus or thrown under it?

It seems the furious debate over the Virtual-directory vs the Meta-directory is now devolving into the general agreement that we need an Identity Bus to move forwards. Dave Kearns writes:

Kim talks about a “second generation” metadirectory. Metadirectory 2.0 if you will. First time I’ve heard about it. First time anyone has heard about it, for that matter. There is no such animal. Every metadirectory on the market meets the definition which Kim provides as “first generation”. It’s time to move on away from the huge silo that sucks up data, disk space, RAM and bandwidth and move on to a more lithe, agile, ubiquitous and pervasive identity layer. Organized as an identity hub which sees all of the authoritative sources and delivers, via the developer’s chosen protocol, the data the application needs when and where it’s needed.

I think, I hope, that Kim will agree with me that this ID layer (the “ID bus”) instituted as a hub (or transformation device) is what we need to go forward. I’m not wedded to calling it the Virtual Directory, but I’m certainly not going to call it the metadirectory, either.

In my opinion an Identity Bus should act as both a Virtual-directory and Meta-directory. In fact I have often discussed exactly this with colleagues in the IdM space. Why isn’t there a product on the market today that can be both a Virtual-directory and a Meta-directory? What makes the notion especially appealing to me is that the same connectors (or adapters if you prefer) that can be used for Meta-directory functionality to push data to legacy applications could be turned around to expose the same data virtual directory fashion to other directory enabled applications.

I am looking forward to a discussion about what an Identity Bus would look like. Perhaps I will build a prototype for fun (I’m kind of weird that way). But in this discussion we should always keep in mind that customers cannot move forwards without a means to identity enable the hodge-podge of legacy applications that must still be supported. It may not be sexy to provision users and do password resets to an AS400 application that has been in production since the 90s, but it must be done.

And there is one important thing that must happen. Customers need to start demanding identity enablement of some sort from their vendors. Far too many enterprises don’t make identity enablement an important criterion when selecting a vendor. Thus they wind up with products that force them into a Meta-directory solution. Until that changes, no one is getting on the bus.