Microsoft SSO Interop - what it is NOT

Big News

Everyone has probably already seen the regarding Sun and Microsoft and announcement regarding interoperability. This is a very cool announcement and it is something that we have been working on for quite a while in lots of different ways.

The technical details in these announcements are typically glossed over and discussed at a very high level. At my level, I've been involved in various "Microsoft Interoperability" projects for several years, mostly involving Kerberos and single-sign on technologies. I have worked with Microsoft people in various IETF working groups for several years and always found them to be very smart and easy to work with. As engineers, we are usually more interested in getting stuff to work correctly and less interested in the executive level sparring that has occurred in the past.


Regarding the new interoperability

This document describes the protocols used to achieve the web-based single-sign on that is covered by the agreement. Note that this is NOT the same as the GSSAPI/SPNEGO web-based single sign-on technology that I described here. This new interoperability protocol is based on Web Single Sign-On Metadata Exchange Protocol, which involves XML, SOAP, HTTP, and a bunch of "WS-\*" protocols. It does not involve any Kerberos or GSSAPI token exchanges.


The other SSO protocol

HTTP Auth-Negotiate with GSSAPI/SPNEGO is useful for extending the Kerberos SSO to internal web sites that only need to authenticate the user. The Web SSO MEX protocol gives the server access to alot more information beyond just the users authentication credentials, the "metadata exchange" part of the name (MEX) refers to all of the other information that can be conveyed in the exchange. The Kerberos SSO exchange typically only involves authentication credentials (tickets) but not alot of extra data associated with the identity being asserted.

Kerberos by itself would never get us close to the level of interop provided by Web SSO MEX. Web SSO MEX allows for interop across environments that use Liberty and WS-Federation and makes it possible to use the Java Enterprise System OR Windows 2003 Servers, which is a big win for enterprise customers that typically have a mix of both and have been frustrated in the past by the inability to leverage both in a compatible way. This announcement should not discourage companies from moving forward with Kerberos integration and improving internal security. Kerberos SSO is more than just web authentication, it can be applied to lots of other non-Web based protocols as well. In Solaris 10 (and later) SSH, LDAP, FTP, telnet, rlogin, and rsh are all Kerberized. Other protocols like SMTP (mail), POP, and IMAP can also be Kerberos enabled with combinations of protocols like SASL/GSSAPI/Kerberos thus extending SSO to almost all of the most commonly used protocols inside of an enterprise (big or small).

So, while I view this announcement as a very positive step forward for Sun, I think there may be some confusion by some over the details of the protocols being used (or not used as the case may be for Kerberos). As I learn more, I will try to clarify the differences more in the future.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

wyllys

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today