Following on from some of my recent posts on interoperability with open source and choice + community engagement, I wanted to give a quick up on Bill Hilf's recent announcement at OSCON unveiling a new web site giving some new insight into Microsoft's open source strategy. Bill followed the announcement up with a blog post on Port 25. Bill also announced our plans to submit the Microsoft Permissive License (MS-PL) and Microsoft Community License (MS-CL) to the OSI.

One of the things that stuck out for me on the new site was "Participating in a world of Choice" – This is a theme that you can see running broadly across the company to allow customers to select the right tools and technologies to suit their needs. Just check out my post linked above on choice for some interesting examples in the developer space. The other key message was how we are partnering to build bridges with the open source community. Beyond the Shared source programs and our commitment to the Open Specification Promise, there are some specific examples of interoperability achievements on the site such as improving the PHP experience on Windows with Zend or improving the SugarCRM experience running with IIS and SQL Server. SugarCRM is also one of a number of open source members of the interoperability vendor alliance, created as a forum for Microsoft partners to come together and demonstrate real-world interoperability in customer-centric scenarios.

So check out the new open source site and see some of the great new partnerships we've created with the open source community.

Thanks,

Adam

A new step-by-step interoperability guide detailing configuration for ADFS federation with Oracle's Identity Federation has been published. This is the third step-by-step guide in the series including CA's Siteminder and IBM's Tivoli product. All the guides can be found in the ADFS Technet homepage. This is a great demonstration of some of the real world federation interoperability that is possible based on the WS-Federation protocol supported by ADFS and other industry vendors.

I know when I think about .Net programming languages the first thing that pops into my head is "C#" followed very closely by "VB.Net" and "managed C++" but now the number of languages I'm going to have to keep fresh in my mind is climbing. eWeek ran a story today on the availability of the first source drop for the new "IronRuby" language for .Net giving Ruby fans a new opportunity to use their favorite tool in their programmer's toolbelt to integrate Ruby with other .Net languages. Support for IronRuby was first announced back at MIX during Scott Guthrie's keynote – if you missed it you can actually go back and re-watch from your computer – but just yesterday, John Lam announced the very first pre-alpha sneak. The code right now is just a .zip download from a link off of John's blog but the plan is to get it posted onto Rubyforge later this summer and begin taking contributions from the community.

Support for IronRuby is actually the second dynamic scripting language to be supported in .Net after IronPython was released last September. This amazing step forward was enabled by the Dynamic Language Runtime (DLR), driven by Jim Hugunin, which adds new capabilities on top of the CLR to support dynamic languages. This investment in the DLR makes language innovation simpler since a lot of the plumbing is already taken care of. It makes it easier for language designers to innovate around the specific language features they are building. One of the quotes from Scott Guthrie's keynote at MIX that really stuck in my head was his statement that he has a hope that someday we can build such a robust language runtime that it will be possible to build a prototype language from scratch during a keynote demo. Now maybe that's stretching a bit but I do think it really shows Scott's commitment to language innovation and giving developers the powerful tools they are asking for to do their work.

The amount of buzz and positivity that these announcements seem to be generating is really impressive – Jim posted the availability of the DLR as well as the plans for new language support for JavaScript (EcmaScript 3.0), and VB in addition to Ruby and Python in the Silverlight 1.1 release and people seem very excited. Out of the 97, mostly positive, comments on Jim's post, my favorite was "Quick, where's my drool bucket?"

Perhaps that's not the most enticing visual but I think this is really a significant step forward – it's an amazing technical achievement, it gives developers more choice on language usage, it marks a high level of community engagement by taking contributions back from the developers who use the language, and provides seamless integration / interoperability with existing .Net apps built in the more "traditional" .Net languages.

Awesome!

Thanks for reading,

Adam

Just a quick note to let everyone know there's a new step-by-step guide available detailing how to achieve interoperability between ADFS and IBM's Tivoli Federated Identity Manager. From the download page:

    "Through its support for the WS-Federation Passive Requestor Profile (WS-F PRP), Microsoft® Active Directory® Federation Services (ADFS) provides cross-domain Web single sign-on (SSO) interoperability with non-Microsoft federation solutions. IBM® Tivoli® Federated Identity Manager (TFIM)—which extends the SSO capabilities of IBM Tivoli Access Manager for ebusiness (TAM)—also supports WS-F PRP."

This is the second paper in the growing library of step-by-step ADFS interoperability guides – The ADFS – CA SiteMinder Federation Security Services paper has also been published.

ADFS can federate identity with any federation service that supports the WS-Federation protocol. The WS-Federation specification was written by Microsoft and IBM and is covered by the Microsoft's Open Specification Promise. The current version of the specification as of this post is 1.2 - Check out the WS-Federation OASIS technical committee page for updates on WS-Federation participation and standards status.

Thanks for reading,

Adam

So for those of you who read Port 25, this is old news. However I just wanted to echo Sam Ramji's welcome for Tom Hanrahan as our new Director of Linux Interoperability. Clearly Tom will have lots to do with our continuing work with Novell as well as our recent announcements for collaboration and interop with Linspire and Xandros. As a side note, I just read Linspire CEO, Kevin Carmony's, letter regarding the community reaction to the Microsoft – Linspire deal and I was extremely impressed. Carmony, in my opinion, takes a realistic and pragmatic view around open source and commercial software working together highlighting the need to enable customer choice, regardless of whether that choice comes from the commercial software or open source software world. The reality is that both are out there, and both will continue to be out there for the foreseeable future. IT departments around the world need to manage diverse heterogeneous systems. So the better those systems interoperate, the more utility (and lower cost) the overall collection of systems has for its administrators and users. Right on, Kevin.

One thing from Tom's welcome that really hit home for me was the depth of experience he has "developing in the open" as Sam said. Having just finished my first milestone on the OpenLDAP adapter (see my posts tagged OpenLDAP) I'm still adjusting to the differences of running a project in front of the firewall but I look forward to learning more from the folks over at Port 25. It's funny when I think back a few years at how far we've come here at Microsoft in terms of transparency with our customers and willingness to engage the community early and often in the development process.

5 or 6 years ago we were arguing about blogs… was it OK for employees to blog about what they were working on? Turns out customers loved it! I remember only 3 or 4 years ago we were arguing on my team about a project codenamed "ladybug" and whether or not we should participate. Fortunately for us, and for our customers, cooler heads prevailed on those discussions and "ladybug" lived on. The "ladybug" project has morphed and evolved over the last few years to become Microsoft Connect. This is a fantastic tool that gives customers web access to our bug tracking system to submit and track issues and suggestions they've got through using our products. When I was back on the XML team we got tons of great feedback during the Visual Studio 2005 and SQL Server 2005 Beta/CTP cycles through ladybug and fixed a bunch of bugs we might not have found on our own. After Connect, we invented Channel 9 (and its offspring), started Codeplex, and began rewarding engineers for customer engagements online in the forums as well as in person, user groups, and at conferences.

All of these things are little steps, but I think it's important to look at the evolution of the culture and mindset to get some indication of where it's going. Creating Port 25, hiring Tom, building up the IVA (more on the IVA in a future post), creating the Interoperability Executive Council and our commitment to interoperability by design are part of the new generation of initiatives in a shift that started many years ago towards transparency, customer connection, and customer choice. I'm really looking forward to what's coming up – stay tuned.

Thanks for reading,

Adam

We're in the home stretch getting the OpenLDAP Management Agent prepped and ready for our Milestone 1 release this Friday. The release should contain an installable MSI (remember you need to have MIIS/ILM installed on the same machine) and a zip with the project documentation. Of course if you want to build the project we've already got an SVN repository with the source and the docs checked in so give it a whirl. I personally like Tortoise SVN as my client for keeping code in sync.

We're in full test mode this week and we've found a few bugs so far but the more testers the better.

In terms of features you can expect on Friday we're supporting the following:

• FullImport from OpenLDAP (IMAExtensibleFileImport)
  • Ability to skip DSML generation for improved performance
• DeltaImport from OpenLDAP (IMAExtensibleFileImport)
  • Based on attribute tracking
  • Based on changelogs (this is to support additional directories but hasn't been tested thoroughly)
  • Ability to skip deletes for improved performance
• Call-based export to OpenLDAP (IMAExtensibleCallExport)
• Password Management (IMAPasswordManagement)
• Support for multiple naming contexts
• Paged Searches (if supported by target directory)
• Support for SSL
• Support for multiple authentication types (Basic, Digest, and Kerberos)*

*Our goal is to support SASL's EXTERNAL mechanism as well however we ran into some difficulty with the underlying support in System.DirectoryServices.Protocols in .Net 2.0 and have alerted the team at Microsoft to the issue.  In the meantime, we've commented out the code in the project for EXTERNAL support however one of the developers on the project did come up with a little workaround by calling into the underlying native wldap.dll directly (thanks, Franck!).  We haven't tested this so use at your own risk, but I thought it was clever so I thought I would share it here. If the lack of support for EXTERNAL impacts your ability to use the adapter send me a note and let me know – I'm interested to hear about your scenarios. I will certainly keep you up to date as we move forward in coming to a resolution.

public class Class1

{

[DllImport("wldap32.dll", EntryPoint = "ldap_bind_sW", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Unicode)]

    public static extern int ldap_bind_s(IntPtr ldapHandle, string dn, string credentials, uint method);

    static void Main(string[] args)

    {

        LdapConnection cxn = new LdapConnection("ServerName:636"); //SSL port

        try

        {

            cxn.AuthType = AuthType.External;

            cxn.Timeout = System.TimeSpan.FromHours(1000);

            cxn.SessionOptions.ProtocolVersion = 3;

            cxn.SessionOptions.SecureSocketLayer = true;

            FieldInfo fildaphandle = cxn.GetType().GetField("ldapHandle", BindingFlags.Instance | BindingFlags.NonPublic);

            IntPtr ldaphandle = (IntPtr)fildaphandle.GetValue(cxn);

            uint LDAP_AUTH_EXTERNAL = 0xa6;

            int res = ldap_bind_s(ldaphandle, null, null, LDAP_AUTH_EXTERNAL);

            if (res == 0)

            {

FieldInfo ficonnected = cxn.GetType().GetField("connected", BindingFlags.Instance | BindingFlags.NonPublic);

FieldInfo fibounded = cxn.GetType().GetField("bounded", BindingFlags.Instance | BindingFlags.NonPublic);

FieldInfo fineedRebind = cxn.GetType().GetField("needRebind", vBindingFlags.Instance | BindingFlags.NonPublic);

                ficonnected.SetValue(cxn, true);

                fibounded.SetValue(cxn, true);

                fineedRebind.SetValue(cxn, false);

            }

            else

            {

                throw new LdapException(res, string.Format("External bind failed with error code {0}", res));

            }

        }

        catch (Exception e)

        {

            throw e;

        }

    }

}

Dan'l Lewin recently authored a post at AlwaysOn that I thought was an interesting read - it summarized Microsoft's history of interoperability and cross-platform support, and broke down our existing investments in interoperability into the 4 primary buckets we use to enable interoperability by design: Products, Community, Access, and Standards.  You can read more about the overall interoperability mission at http://microsoft.com/interop.

One other thing I picked up here that I found extremely interesting was reference to Sun's Project Tango designed to improve interoperability between Sun's Java Web Services implementation and the Windows Communication Framework.  It's great to see this kind of effort to enable interoperability between to heavily used web service stacks.

HP just announced their support for the OpenXML file format as a standard in a position statement on their website. The thing that really caught my attention was HP's position that both OpenXML and ODF can "co-exist interoperably" and "customer's should have the opportunity to select the standards which best fit their needs."

We've already demonstrated interoperability between the two file formats (ODF and OpenXML) through the OpenXML/ODF Translator project. Brian Jones has blogged about support for OpenXML and ODF translation in OpenOffice, as well.

Check out http://openxmlcommunity.org/learnmore.aspx about the benefits of standardization, why standardization is important, and co-existence of formats. If you're intrigued, show your support

Thanks for reading!

Adam

OK, maybe I'm way behind the ball here but I thought I'd share a funny story from implementing the OpenLDAP management agent project. The OpenLDAP interaction is based on the LDAP support in System.DirectoryServices.Protocols in the .Net Framework (version 2.0 and higher). So, the dev team was adding support for SASL binding over Kerberos and the code looked really simple (check out Wikipedia for a good overview of Kerberos and SASL), but for some reason the bind operation from the management agent to the OpenLDAP server was always failing. It looked like our MIT KDC (Kerberos server) was issuing a session ticket to authenticate against the OpenLDAP server, but OpenLDAP just kept mocking us with the elusive "wrong principal name" error. The team was stumped. They tried modifying the code, checking, double checking, and triple checking the setup of the KDC, the host registration in the KDC database, everything. No luck.

Finally, they started sniffing the network traffic between the management agent, the KDC and the OpenLDAP server. And suddenly it was all clear – the OpenLDAP server had a mixed-case hostname, which was properly registered as mixed-case in the KDC's case-sensitive host registration database. However, during the protocol conversation between the three processes, the Kerberos client in System.DirectoryServices.Protocols was doing a DNS reverse lookup to get the fully qualified domain name of the OpenLDAP server, and the DNS service was returning it in all lower case. So when we went to send our ticket off to the OpenLDAP server the ticket intended for a mixed-case host didn't match the resolved domain name of the lower-case target (even though it really was the same machine).

So we changed the servername and the registration in the KDC database to all lower-case and, automagically, the code started working as we expected. Voila! So on the upside, the Kerberos code was simple and it was already checked into the sourceforge project…we just didn't know it yet!

Of course, as soon as the culprit was known I went groveling around the web and found a handful of posts talking about the same basic issue…if only foresight was also 20/20…

It is interesting that when working across platforms the interoperability challenge here wasn't related to platform A's support of Kerberos being different from platform B… in fact the team tried to use Active Directory as the KDC as well and got exactly the same "wrong principal name" error as our Linux-based MIT KDC. Instead it was the relationship to an orthogonal technology that the team stumbled over, because they didn't know this little convention of lower case host names.

As a side note I came across a couple of great resources for programming with System.DirectoryServices.Protocols while I was researching this issue:

• Introduction to System.DirectoryServices.Protocols (S.DS.P)
• NET. LDAP. Geekery (Joe Kaplan's blog)

Thanks for reading!

Adam

I was reading Brian Jones' post this morning on the Open XML SDK tech preview which is a new managed .Net API for programming against the Open XML formats that was announced today at TechEd. There is also a channel 9 interview on the OpenXML formats and the availability of the .Net API. The preview is available for download from the Microsoft Download Center. One thing that caught my attention in the post was that there is a Java SDK as well for programming against the Open XML formats – check out the project website and Brian's post on the topic.

It looks like Altova is also adding support for OpenXML in the new version of XMLSpy – here's the press release from Altova and a quick rundown on the features.

If Open XML development is something you're interested in – check out http://openxmldeveloper.org/ and get engaged with the community.

Thanks for reading!

Adam

A couple of interesting updates from around the Identity interoperability world:

• Positive Response to our Identity Announcements! I posted last week on Microsoft's Identity interoperability announcements at the Interop Las Vegas conference and overall response has been very positive. Check out the post from Neil Macehiter on his blog, digging into the details of the interoperability announcement.

   

• OpenLDAP Management Agent (Adapted) for ILM 2007 is moving along - The OpenLDAP sourceforge project is also coming along – we uploaded our first version of the code to the site a couple of days ahead of schedule. The management agent is still in its early stages and there's lots of work left to do, but it implements the IMAExtensibleFileImport and IMAExtensibleCallExport interfaces described by ILM/MIIS. The goal is to add support for the IMAPasswordManagement interface as well, and a number of new connection options, improved robustness, performance enhancements (we need to do some benchmarking first), and more. Documentation should be coming online over the next weeks leading up to our first milestone on June 29^th. Stay tuned for more details.

   

• OASIS WS-Federation Technical Committee (TC) to Convene - Don Schmidt, one of the program managers here at Microsoft working on Federated Identity alerted me via his blog that the OASIS WSFED TC will be held on June 6-7. From the OASIS website the charter of the TC "The purpose of the Web Services Federation (WSFED) Technical Committee (TC) is to extend the basic federation capabilities enabled by Web service Security specifications (WS-Security [2, 7], WS-SecureConversation [3], WS-Trust [4] WS- SecurityPolicy [5]) to provide advanced federation capabilities." The work of the TC will be based on an input document published in December 2006, by BEA Systems Inc., BMC Software, CA Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Novell Inc., and VeriSign Inc. If you're new to the federation space, Don has a couple of good posts explaining the federated identity basics, the relationship of WS-Federation 1.1 to the rest of the WS-* specifications, and the relationship of WS-Federation 1.1 to SAML 2.0. There's also a new whitepaper on MSDN on understanding WS-Federation.

Thanks for reading!

Adam

Last week was the Interop Las Vegas show - I didn't make it but check out Craig Kitterman's blog for interesting details and tidbits from the show.  In particular, Microsoft made a number of interesting announcements around identity management furthering its commitment to deliver interoperability by design.  One of the announcements to "Extend Identity Management in the Enterprise" is the development of an OpenLDAP eXtensible Management Agent (XMA) for Identity Lifecycle Manager (ILM) 2007 that allows bi-directional synchronization of identity information between the OpenLDAP directory and ILM 2007.  The adapter will work against ILM's predecessor, Microsoft Identity Integration Server (MIIS) 2003 SP2 as well and will be built on top of the LDAP support in System.DirectoryServices.Protocols.

I will be working with our partners, KERNEL Networks and Oxford Computer Group as they develop the XMA so if you're interested I'll be discussing the project as it moves along.  If you're familiar with the space you probably know Craig Martin over in the Identity Trench, and he'll probably be blogging on the project from time to time as well.  The project is hosted on Sourceforge at http://openldap-xma.sourceforge.net - it's just getting going right now so please be patient but you should see changes start to roll in over the next few weeks.

As of right now my new blog is open for business.  I recently joined Microsoft’s Developer & Platform Evangelism team focusing on interoperability – connecting people, data, and diverse systems - by design.  In my previous life I was the lead program manager for the XML Technologies team in the Data Programmability organization.  We’re the folks that brought you MSXML, System.Xml, and the Xml Editor and XSLT debugger in Visual Studio.

When I joined the XML team 5 years ago, it was because of XML’s potential to transform our computing experience by unlocking data and allowing new levels of collaboration and interoperability between systems.  The loose coupling that XML enabled gave developers and businesses freedom to choose the tools and technologies that best suited their needs, and that ability resonated with me.

I was at XML 2006, back in Boston this past December on the "10th anniversary" of XML.  Aside from being a great time, it was an opportunity to reflect on what's happened in the XML community and ponder on where it might be going.  XML, in my opinion, for all of it's "gotchas" has been an enormous success.  In many respects XML itself has disappeared into the infrastructure.  XML support is ubiquitous.  When you look around at many of the new technologies targeted at improving collaboration, unlocking data, and creating new interoperability opportunities XML is at the core.

However, there is more to interoperability than XML as I am rapidly learning as I broaden my perspective on the world.  So that’s what I hope you’ll find here – just my observations and ideas on what’s going on in technology around interoperability, as well as musing on other cool new technology and clever innovations.

Thanks for reading this far.