I am at Netpro’s Directory Expert Conference in Chicago this week, and very excited to be here! I’m keeping my eyes and ears wide open for the latest tech and trends around Microsoft AD and Identity Management, and also participating at an experts panel this afternoon. Knowing that DEC is an action-packed event, I came a day early, and it was well worth it. Sunday’s ramp-up to DEC 2008 was a pre-conference workshop on Microsoft Identity Lifecycle Manager (ILM) 2 beta, Certificate Lifecycle Manager (CLM), Active Directory Federation Services (ADFS) and Active Directory Rights Management Service (ADRMS). It was a hands-on lab experience given by David Lundell from the Oxford Computer Group, who did a brilliant job putting it together.

Microsoft’s vision is to have Directory Services in the centre of a comprehensive infrastructure that supports Identity Lifecycle Management, Strong Authentication, information protection and federation. Harnessing the tools presented in this workshop, one can see where this is going. Although some of the components (specifically ILM 2) are still in beta and not expected to be released until the “second half of 2008”, the picture may still be a bit rough and blurred, but one can see that it will be quite a beautiful one, once completed.

I was particularly impressed by Certificate Lifecycle Manager (CLM), an add-on to ILM that facilitates string authentication, specifically in the area of smart cards. It seems that Microsoft has managed to add significant value to an area that is often notoriously difficult for many enterprises to implement. Starting with an abstraction layer to the underlying card’s hardware stack to a comprehensive lifecycle implementation, CLM supports the full work-flow of the whole lifecycle of issuance, PIN reset, revocation and retirement. Self service is of course part of the offering and is streamlined for efficient and secure management from initial issuance to retirement and secure recycling. Just like the Dot Net Factory, Microsoft is harnessing the new Windows Workflow Foundation for all of its workflow management. For data flow, uses its MIIS meta-directory technology.

Just before the session closed, Microsoft’s Bobby Gill gave us a “sneak peak” of some additional features of ILM 2 beta 3 “hot off the disk” that he compiled a few hours ago. It is obvious that many significant enhancements are still being made, and Microsoft is very actively involved with its beta partners to collect their feedback and make improvements before the official ILM 2 is released.

Back to keeping my eyes and ears open, and I shall be back soon with some more news from DEC 2008!

Over the last few weeks, the Liberty Alliance’s IGF caught my attention several times. Fulup Ar Foll and Jason Baragry, both working for Sun Microsystems wrote a paper called “Next Generation of Digital Identity”. About a month ago, HP’s Marco Casassa Mont and Oracle’s Phil Hunt published an article in “Sarbanes-Oxley Compliance Journal” entitled “Identity Governance Framework”. I’ve been wanting to blog about this for several weeks, but kept putting it off. Last week I had the fortune to be briefed by Prateek Mishra, Oracle’s Director of Security Standards, who explained in detail what the IGF was about and clarified some of the questions I still had.

In late 2006, several companies got together and created the Identity Governance Framework (IGF), an initiative of the Liberty alliance. Originally driven by Oracle, other companies in the space quickly joined the effort. The purpose of the IGF is to provide an open architecture that addresses governance of identity related information. This architecture is meant to bridge the gap between regulatory requirements and the lower-level protocols and architecture.

What does this mean and why is it so important? I like examples to understand things, so let’s start with a few of them. For a starter, many enterprises still have private identity data stored in many different data stores. Even though the trend is to minimise the number of “data silos” (places where identity data is stored), the reality is still that data can be found in many places. This creates a problem in our globalising society, where the HR department might be run in one country, and the support desk in another, and a myriad of services being outsourced yet to other locations. How can one ensure that the flow of data is controlled in such a way to ensure that all privacy laws are being complied with? Another example could be a federated environment of several suppliers working together in order to process an order. The order is received by company A, which then sends out several orders for parts to companies B1, B2 and B3, who then ship everything to company C that assembles everything and uses company D to ship out the finalised order to the customer.

In both cases, identity data is transferred and processed. How can the inherent risks associated with the creation, copying, maintenance and use of this data be mitigated? Who has access to what data for which purpose, and under what conditions? Ideally, policies on data usage are created by sources (attribute authorities) and consumers (attribute authorities) of identity data. These policies can then then be used for the implementation and auditing of governance. In other words: if you know what the rules are, express them in a policy, and make sure your policy is watertight when the next audit comes.

Exactly this is what the IGF attempts to create: a standardised mechanism for expression and implementation of these policies. The IGF is working on several standards and components to make this happen. One of them is the CARML protocol. It defines application identity requirements, in other words what type of identity information an application needs, and what that application will do with that information. CARML stands for “Client Attribute Request Markup Language”, and yes you’ve guessed right – it’s XML-based. As stated previously, CARML defines what attributes an application wishes to consume, and the privacy rules of the application: Will the data be persisted (stored) by application? If so, how long? What purpose is it used for? Will it be forwarded? When an application is then made available, administrators can review the CARML file for that application, ensure that privacy constraints are being met, and then connect the application to the respective data stores to make the information available.

On the other side of the spectrum there is AAPML, the “Attribute Authority Policy Markup Language” that describes the constraints on the use of the provided identity information – under what conditions specific pieces of identity data is made available to applications, and how this data may be used, and possibly modified. For example: what part of the users data can be modified by the users directly at a self-service portal? Or: under which condition may a marketing application use a users data, and what type of explicit consent needs to be given by the user? AAPML is proposed as a profile of XACML, the “extensible Access Control Markup Language” so that AAPML policies can be consumed directly by a policy enforcement point (PEP) to enforce access over the requests for identity data.

So now you can probably see where this is going. In one side, you have the applications, and CARML that specifies the identity information that they need. On the other hand you have the identity data sources (attribute providers), and the policies under which they make data available. In the middle, an identity service can broker between both sides. This identity service can read the CARML requirements from the applications, and the AAPML policies from the attribute providers, or use an external identity policy engine that enforces the AAPML policies.

So why another set of protocols? Isn’t this already addressed in some other standards? Liberty’s ID-WSF springs to mind, or SAML 2.0′s AttributeQuery, SPML, or even – to a certain extent – WS-Trusts Security Token Service. However, CARML and AAPML bridge a very important gap that is not addressed anywhere else: not how to request and receive attributes, but to express the need and purpose of identity data, and on the other side the allowed use and conditions for its consumption. IGF’s framework conceptually fits seamlessly into architectures harnessing today’s frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust, leave off.

In my mind, the IGF makes some very important contributions for important issues that have somehow “fallen through the cracks” in the last few years. The IGF’s standards ensure that privacy requirements can be met and audited against, and facilite the secure and controlled exchange if identity data. This has the potential to fuel adoption of technologies such as federated identity, and open up business opportunities that were up to now constrained by uncertainty about privacy or lack of tangible technology in that area. I will definitely keep the IGF on my radar!

Now who says that federated identity can’t be entertaining as well. On January 24th, Sun’s Daniel Raskin, who is involved in Sun’s OpenSSO project, poked a bit of fun at competitor Ping Identity by putting a short videoclip up on his blog which would help “explaining the differences” between Sun and Ping. It didn’t take long for Ping’s crew to respond in kind, promising an “epic battle” in their own video posted on Ping’s blog.

What I quite interesting about these little jabs carried out in good humour were the comments about “federation auto-connect” that Ping announced a few weeks ago in the latest version of PingFederate. The idea of this feature is to make federating between different entities easier by automating the exchange of meta-data. At Symlabs, the company I worked for previously, my then-colleague Sampo Kellomaki had developed the same feature about a year earlier, and had even mentioned it in his presentation at the first European Identity Congress last year. At that time, I must confess that I was unsure this feature’s value in most scenarios – apart from very specific low-risk “open” federations which were already being catered to by OpenID. Charts such as the one featured in this blog entry from Ping still raise a certain scepticism, but maybe that scepticism might prove to be wrong. I am certainly interested in exploring further the value proposition of auto-federation and will make sure to tickle some answers out of the participants in the federated identity track that I’m moderating at our next Conference in April.

As both Sun and Ping will be at the European Identity Conference 2008, we will try to set the stage for an epic battle to be carried out there! And to make it even more interesting, we’ll throw the other contenders into the foray as well!

On January 18^th, Yahoo announced support for OpenID 2.0. OpenID is an open framework for decentralized single-sign-on. It effectively allows user to register with one trust Identity Provider (IdP), and then sign in to any other OpenID-enabled site by just providing the details to the IdP where the user has established the account. For example, once Yahoo start with this service, I would be able to go to any web site that also supports OpenIDs, and tell that site that I am a Yahoo user. The site will then verify my credentials using Yahoo’s sign-on system – effectively meaning that once I have my Yahoo account, I will not need to remember many other usernames and passwords for other sites that support OpenID, but just be able to log in straight to them.

Sounds exciting, doesn’t it? Well, it’s certainly exciting news for the OpenID community. But what does this actually mean for the users and for the further advance of the technology? Before I dwell on the question, let’s look at the facts. Yahoo claims 248 million registered users. That’s about as big as it gets in terms of providing, and of course the OpenID scene is thrilled. On January 30^th, Yahoo will debut its first public beta version of the service. Yahoo has, interestingly, chosen to support only version 2.0, instead of offering support for the more established version 1.1.

So why support only version 2.0? Yahoo specifically points to security as the reason (OpenID 2.0 is more secure). This is most likely because of several oversights in the OpenID 1.1 specification that could be exploited for potential phishing attacks. Understandably, Yahoo does not want to be haunted by that. This is why Yahoo is promoting its “sign-on seal” for the OpenID service as well. A “sign-on seal” is a special piece of text or a small image that you can configure, which is displayed every time Yahoo asks you to sign in. This is done in order to prevent phishing attempts from rogue sites that pose as Yahoo branded login sites. Yahoo has introduced this feature in mid-2006, and actually done it in a very elegant and user-friendly way.

Rarely are grand announcements made without some kind of “gotcha” – just like in this case: Yahoo will start by allowing other site to consume Yahoo OpenIDs, but not the other way around – it will not accept OpenIDs from other providers (at least for the time being). This is actually quite a big deal. The big advantage of having an OpenID is that I don’t have to keep manage and remember passwords in the many other sites that I use. So if the “big boys” such as Yahoo, AOL and potentially even Google in the future, claim that they “support OpenIDs” but will only allow their IDs to be used in other places – not the other way around. Hence, it will not be possible yet to sign into Yahoo’s services using, for example, an AOL account.

AOL has been supporting OpenID for some time now, announcing support for providing OpenIDs to its users almost a year ago (similar to what Yahoo has now done, but with Version 1.1). Even though AOL stated that it would work “gradually” in order to accept OpenID identities from other entities as well, this progress has been very slow, and AOL has drawn criticism because of it. Yahoo on the other hand does not directly mention a planned support for accepting OpenIDs from other entities. In Yahoo’s press release, it’s all about adding 248 users to the OpenID “ecosystem”. Ominously, no reference for the other way around. Hopefully this will happen however, because otherwise Yahoo’s step, although in the right direction, is a one-handed one: let the drawbridge to the castle down, but only let people out, not in. Now that Yahoo is the biggest contributors of OpenIDs in the Internet, will it also be a leader? Or will other major players, such as Google, who is experimenting with OpenID already through its blogs, or even AOL, make the first step in also accepting OpenIDs? Not just myself will be watching carefully over the next months.

Hello World! I am excited to have joined Kuppinger + Cole, and my responsibilities will be around the technologies of directory services and identity federation. I would like to kick off my blog by writing about an acquisition that actually happened a week ago, when Nokia Siemens Networks announced that it will acquire Apertio, a Bristol, UK based vendor of telecommunications software. Now what does this have to do with identity management, or even with directories? Simple. Apertio specialises in a very specific type of directory server software. They have come up with a in-memory based, highly efficient and super-scalable directory server that supports LDAP as well as access through protocols used in the Telco space (SS7, IMS).

So what role do directory servers play in the Telco world? Mobile carriers for example, use something called an HLR (Home Location Registry) as the data store for operational subscriber data. A HLR is effectively like a very large directory server, or user database if you wish, that must be highly available (otherwise you might lose service), and highly scalable (able to support many thousands of operations per second, otherwise you, again, might not get the service at the time that you need it). Traditionally, HLRs were sold as “big black boxes” at a juicy prices to mobile operators. What Apertio has done was to very elegantly merge traditional directory server standards and technology with the telco world by writing a specialised directory server that would be accessible via LDAP, and traditional SS7-base telco protocols. Granted – their directory server was so much geared towards that particular use case that it was not sold (nor made much sense) as an enterprise directory. But what fascinated me about Apertio was that they pioneered in successfully marketing the fusion between a LDAP directory and Telco HLRs. At the same time, they were in a great position to also sell the successor technology, called HSS (Home Subscriber Server, part of the IP Multimedia Subsystem, or IMS – effectively the “next generation” in communications).

Apertio has made great inroads with that successful combination. How will technology evolve in the conversion zone between LDAP and HLR/HSSes? I for one, firmly believe that many directory servers are ready for “prime time” when it comes to the stringent demands of the telco industry. Some of the LDAP servers available today can support the thousands of operations required, have the resilience features, and some of them even support transactions. Now that Apertio, who sold their products based on a software solution turns into “boxed HLRs” and “boxes HSSes” with a Nokia Siemens label on them, there might be competition arising from a new company brave enough to add the missing piece to today’s directory server in order to turn them into the next generation telco equipment. I doubt that the traditional vendors will go directly into this – at the end of the day, companies such as Sun and IBM might not want to encroach on the telco equipment manufacturers with whom they have built successful symbiosis by offering competing products – but a third party might well jump into that space.

Very large directory server projects fuel some important developments at the major directory vendors and add scalability and new features that can, to an extent also benefit enterprises, and large service providers that need to store millions of customer entries. Multi-master replication, partitioning and transactional features are all examples of this – who knows if this technology would have been developed if not for one or the other very large directory project. It will be interesting to see who, if anyone, jumps on that bandwagon to offer the next software based HLR/HSS systems based on LDAP technology, and how this may affect directory server vendors in making their software better and faster.