papau wrote: ...
Jan. 9, 2009 10:53 AM
|
 |
 |
|
|
|
YOUR FEEDBACK Did you read today's front page stories & breaking news?
SYS-CON.TV
|
TOP THREE LINKS YOU MUST CLICK ON Enterprise How Apache & Plan 9 will defeat Microsoft's Passport
Dominance of Apache means Microsoft won't have the votes to enforce its approach
By: Paul Murphy
Sep. 18, 2002 12:00 AM
(LinuxWorld) — Linux gets a lot of press these days, but much of it appears condescending and is more about the phenomenon of its emergence and growth than it is about the value and use of the technology. That may be about to change, and for the better. As a group, the so-called "mainstream press" often appears to favor Microsoft and show an appalling lack of technical depth in its enthusiastic repetition of the latest Microsoft press release. There’s been a lot of speculation on why this is and whether it even happens. So far, no definitive research provides answers one way or the other. I think there are two explanations. First, the press is largely the victim of a Microsoft marketing strategy that plays off of the social rules people learn in high school: Money and social skills define the in-crowd, and only nerds kvetch about the importance of better technology. Second, editors are part of a feedback loop, reflecting the views of their readers in the decisions they make on content and wording. Their perception of their market as a shallow Microsoft PC market therefore leads them to favor cheerleading over analysis because doing so sells more advertising, more subscriptions, and more advertised product. What happens when journalists find themselves reporting the legal and personal risks associated with Microsoft’s Passport can be easily avoided by adopting better technology from the open-source world? The normal legal standard for judging the adequacy of professional services — such as those involved in setting up an e-commerce site — is consistency with the "best" or industry-wide practices. What does the mainstream press do when that standard is largely set by the 66 percent of Web administrators who use Apache and open source? I don’t know, but I think we’re about to find out courtesy of Plan 9’s pending victory over the X-files in the matter of single sign-ons and network authentication. Single sign-on then & nowIn the early days of Unix, resource access and authentication were not problems. Users signed on to the VAX and promptly maxed out the resources for which they were authorized. That worked well... until organizations got a second Unix machine in the door and people who needed two logins complained about the complexity of remembering two passwords.
None of the solutions to this problem were as good as they should have been. Kludges like NIS+ and FNS could be made to work for as long as the sysadmins wore their lucky underwear, but these fixes were never exactly stirring advertisements for the simplicity and user-focus of Unix-design ideas. rhost and the related facilities used with X11 were, on the other hand, both easy to use and wonderfully effective from a user perspective, but largely unacceptable to security-minded system managers. Today, the single sign-on problem has escaped the back rooms to become a front-burner competitive issue. Microsoft’s Passport service attempts to deliver a single sign-on solution for an essentially unlimited number of Windows users accessing Windows servers, while the Liberty Alliance tries to play catch-up from the competitive side of the systems world. Passport brilliantly combines the kludgey and unstable nature of NIS+ with the insecurity of the trusted hosts concept to produce a nine-step process with obvious opportunities (See, for example, Risks of the Passport Single Signon Protocol) for security and other abuses:
You might assume Rube Goldberg concocted the design. In reality, things got this way through an evolutionary process that, in retrospect, looks as logical and inevitable as a slow-motion train-wreck in a B movie. The approach favored by the Liberty Alliance is markedly better, with fewer steps and no monopoly on holding or managing authentication information. That said, it only looks good when you compare it to Passport. Consider it independently and you might feel a touch of nostalgia for the days when federated naming-services provided the backbone for federated identity-services. What’s going to become of the conflict between the empire’s Passporters and the heroic rebels of the Liberty Alliance? I think Sun’s going to make both sides of this debate obsolete by introducing some old technology that solves the problem elegantly. Although Sun is the company that popularized the notion "the network is the computer," Sun has not yet made this as transparent as it should be. Sun developed NFS as part of its first-generation OS, and this helped a lot (particularly within trusted communities), but it also required central control of shared resources. Solaris 2.0 focused more on adding scalability and reliability than on extending Unix out of the box and across the network. Solaris 2.9, the current release, contains many single-identity tools, but they’re all add-ons to the basic OS rather than being truly integrated with it. I think that Solaris 3.0 will change all that by adopting a bunch of user- and resource-authentication ideas from Lucent Technologies' Bell Lab’s Plan 9. More importantly, I think that Sun’s actions will give those ideas, already available to the open source community, new impetus and lead to a battle for Webshare as Linux and BSD Apache administrators decide between joining up with Microsoft and the X-files or taking off for outer space and Plan 9. XML's roots go back to 1957Like Passport, Dot.net is distantly based on a family of extensions to XML. I think of these extensions as the X-files; even Bishop Occam would want to blame vast government cover-ups of alien takeovers to explain the weird stuff we encounter in search of an explanation for Passport and dot.net ideas down the XML rabbit hole.XML started out as a sort of simplified SGML (Structured General Markup Language, a 1983 ANSI standard) and originally inherited many of SGML’s key characteristics. SGML defines how document-markup should be structured and unifies related ideas from both the printing and computing perspectives. On the editorial (or printing) side, SGML got its start the day after Gutenberg’s invention of movable type made it necessary to formalize editorial instructions to typesetters. From this perspective, SGML’s tags were instructional in nature, as in "start using 42 lines per page here".
On the computing-practices side, SGML’s roots only go back to about 1957. It was in this year that Rand Corp. made its first attempts to implement the COLEX text retrieval system, a development that led to the 1967 commercial release of SDC Dialog (probably (?) the first public-network-based information-service). COLEX was aimed at helping the U.S. Air Force sort through hundreds of thousands — maybe even millions — of technical documents, and it needed some way to differentiate text by type. As a result, COLEX tags were descriptive as in: A third type of tag, combining formatting information with procedural information, was pioneered in early '60s MIT products like RUNOFF (which begat troff and ditroff). These tags were intentionally eschewed by the committee because SGML was intended to describe document markup, not document processing. The SGML specification defines two types of information labeling:
Consequently, the rigid separation of markup information from procedural information means that actual use of SGML needs three things:
In general, the document-preparation workflow envisaged in SGML is:
Notice again that the only executables here are the transformer and rendering applications. The markup language is interpreted by the transformer and rendered by the graphics engine, but the markup language does not itself take on the attributes of a programming language and does not contain executable code. How well this works in terms of final product quality depends in large part on the quality with which the output is rendered, something which itself depends on both the rendering application and the physical technology used. The HTML DTD does not offer much direct formatting control; an HTML page displayed using IE on a PC with default fonts, borders, and window sizes will look very different than that same page displayed under Konqueror. What’s going on is that each browser has what amounts to an internal stylesheet that determines how text marked up with a format label like <EM> is actually rendered in the local graphics environment. Cascading stylesheets bring better control where the page meets the PC screen by providing explicit rendering instructions to replace these default choices. For example, the browser default is to show something tagged <H1> somewhat more than three font sizes bigger, but in the same color as, something tagged <P> but <STYLE TYPE=text/css>
H1 { color:blue }
</STYLE>over-rides the default stylesheet to add the instruction that text presented between <H1> tags should also be rendered in blue. Since a document can contain more than one set of rules either directly or by reference, some complexities arise in deciding which rules apply. In the official CSS specification, those inheritance rules are executed by sorting through presentation rules to find the nearest one not overridden by an "important" label attached to an instruction in a higher level stylesheet. This is a strategy roughly analogous to letting the person whose shouts sound loudest win the argument. Graphically, this process can be presented as an inverted tree with formatting authority cascading down it to the lowest applicable level; hence, eventually, some more X-files: including Xpaths, Xlinks, Xschemas (done with the eXensible Stylesheet Definition Language [XSDL] or just .XSD in DOS), and, more recently, XMLNS or XML name-space files. When work started in 1996 on yet another SGML DTD, to be known as XML, the need for stylesheets was a well-established part of commercial reality. Two additional standards, often grouped together under the name XSLFO (Extensible Stylesheet Language, Format Objects) and reasonably considered generalizations of the stylesheet concept, were co-developed with the XML specification to accommodate this. The latter of these control how XML documents are transformed to produce documents that can be rendered by standard engines such as browsers:
Defining an XML DTDIn defining an XML DTD, you create and then tag the tags. i.e., you:
In use, this produces at least an XML document containing the labels, an XMLNS (XML Name Space) document containing the definitions, and an XSL document containing the presentation information for use by the output formatter. This set of solutions met the needs of large numbers of people for controlled document structure and presentation. As a result a number of XML DTDs were quickly standardized, including one I’ve been working with, the XBRL specification for an extensible business reporting language and one many people have been working with, Microsoft’s XML definitions for files produced by Microsoft Office.
One of the side effects of Microsoft’s 1998 decision to embrace XML was its immediate extension to provide access to procedural elements. Starting with ActiveX this has expanded to include various document, or common, object models (DOM/COM) and, most recently, SOAP. The Simple Object Access Protocol was originally intended to provide RPC like services that bypass firewalls by using port 80 with HTTP but is now being extended, via the Web services definition language (WSDL) to allow for more general forms of communications. By taking XML across the gap from markup to procedural language, Microsoft made file interchange and information use both easier for Windows developers and more dangerous for users. After all, an XML file is still just a text file that anyone can edit whether it contains procedural information or not. For example, the extensions made the following possible in an XML document: <xsl:script>
<![CDATA[ Virus=new ActiveXObject("WScript.Shell");
Virus.Run("%systemroot%\\SYSTEM32\\CMD.EXE /C DIR C:\ps");]]>
</xsl:script>
(Note: this example for Microsoft Excel is from http://www.guninski.com/ex$el2.html except that "virus" is not spelled out in the original. This code apparently works with the more recent MSXML4/5.DLL parsers for the major current (mid July, 2002) releases of Windows 2000 and Windows/XP. Also see securitytracker.com’s description of an MSXML.dll exploit with respect to SQL-Server 2000 that can allow the execution of arbitrary code by a remote attacker.)Encryption to the rescue!Obviously, that raises a problem. Let's say someone sends you a PowerPoint document saved as XML. Should you load it? Delete it? Read the XML file looking for external executable references?More generally, how do you know:
The technology needed to assure a document recipient that it originates with the ostensible sender and has not been tampered with uses the XML digital signature and encryption standards. These describe how encryption can be used to authenticate documents by defining what is enciphered, how that is done, and how the results are represented in an XML document.
Specifically, the encipherment is handled via PKI — Public Key Infrastructure on the RSA model. The underlying encryption methodology is clearly explained by Ed Simon, Paul Madsen, and Carlisle Adams in their An Introduction to XML Digital Signatures on the XML.com site. The key point is that two separate keys are used such that, as Simon et al put it, "a cryptographic transformation encoded with one key can only be reversed with the other." These keys are related via a hypothetical mathematical construct known as a one-way function. In these, the computational cost of creating two keys is trivial but the computational cost of finding the second key from knowledge of the first is thought to be very high. Thus a PKI user can publish one key while keeping the other secret, thereby creating a situation in which the ability to decrypt something with the public key asserts that it was encrypted with the private key and, by extension, can only be the work of the only holder of that private key. This therefore ensures that the sender cannot repudiate the encrypted data and so amounts to a digital signature. Similarly, a sender can use the recipient’s public key to encrypt data knowing that only the recipient’s private key can be used to decrypt it, thereby ensuring the privacy of the message. With PKI, senders and receivers can exchange public keys and so enter into a secure, signed, exchange. Neither side can know, however, who the other is unless some third party previously attests to both identities. As a result various certification authorities have evolved on the Web to certify that the identities involved are as represented and, at the cost of an additional pair of PKI encoded digital information transactions, both sender and receiver can be reasonably assured of the other’s real identity. The normal method for validating a digital document’s internal integrity is to record a hash value (a mathematical or heuristic representation of all, or part, of the document in a single, usually short, string of text or a single number) and then to encrypt and transmit that hash value as a "digital digest." Recalculation of the hash value on document receipt and its comparison with the decrypted value is then expected to show whether the document has been tampered with because a content change will result in computation of a different hash, or digital digest, value. The combination of XML with embedded digital signatures allows information suppliers to assure their customers that the documents they get are authentic and unmodified by third parties. In other words, if that hypothetical PowerPoint document contained a digital signature, and you had the software to verify it, and both the hash and key match checked out, then you would be certain that the document came from the ostensible sender and had not been modified en-route. Equally importantly, if it turned out to contain a virus, the sender would be forced to acknowledge responsibility for that since you could prove who it came from and that the problem existed when the sender affixed the digital signature and thus before the document was sent to you. These ideas can, of course, be applied in other ways to other problems. It’s not a long step, for example, from using digital signature standards to authenticate documents for both sender and content to applying the same ideas to authenticate almost any kind of information exchange, including that needed for a single sign-on system, for remote procedure call authentication, or in XML documents that distribute a user’s credit balance or other personal details to third parties. Liberty AllianceOn the open side of the ledger, these ideas pour directly into the XNS (eXtensible Name Service) attempt to specify a vendor-neutral digital identity infrastructure. On the proprietary side, however, they underlie what became Microsoft’s Passport Service.One of the responses to Passport is known as the Liberty Alliance a Sun-inspired effort to produce a genuinely open and interoperable single sign-on and authentication standard. The Liberty Alliance released its 1.0 Federated Network Identification and Authorization specification on July 11th 2002. In many ways, this is both a simplification and a generalization of the ideas behind Passport but without the proprietary overtones and single point of control characterizing the Microsoft solution. One of the most interesting things about this specification is its use of SAML (Security Assertion Markup language) to define and control the messaging structures used in an actual implementation of the specification. Full details, including protocols and the SAML schemas needed, are available at http://www.projectliberty.org/ but, basically, the liberty specification handles authorization in a three-stage process with all communications structured via SAML and flowing through the user’s browser or other software agent. Microsoft, which had previously announced planned upgrades in its Kerberos derived security for Passport also announced, on July 16th, 2002, its intention to embrace SAML. As currently defined, however, SAML is faithful to the distinctions that went into the SGML specification back in 1983 and therefore does not include procedural elements. Thus, SAML is used in the liberty specification as a technology agnostic way of conveying assurance information between two or more procedural applications which, respectively, produce and consume the information. If Microsoft were serious about its support for SAML as a standard it could, of course, adopt the Liberty Alliance single sign-on and authentication specification for its own use and let Passport, and such extensions of XML as its use to bypass firewalls for "Web programming" and remote services execution, die of their own weight. Enter from stage left, Plan 9!That may not strike you as likely any time soon, but stranger things have happened, including the growth of a significant following for Plan 9, the movie, and its eponymous influence on the Liberty Alliance specification.When Ed Wood Jr. put his ideas about film making into Plan 9 from Outer Space the result became a cult classic defining an entire genre of B movies. When Rob Pike and his colleagues at AT&T Bell Labs first defined the Plan 9 operating system many of their ideas seemed to be from outer space. The linkage to the Dantesque horrors of Plan 9 led to such an inexhaustible source of bad puns and in jokes that I half expect to see Sun release SunOS 3.0 on a Good Friday. In operation Plan 9 looks a lot like Unix but it is quite different internally in that the original design took many Unix ideas for single machine environments and re-thought them for fully distributed, multiple-machine environments. Key among these is the link between user and machine. In Unix, a user authorization is defined fundamentally with respect to the resources available on a specific machine. In Plan 9, user authorizations are defined for a distributed virtual machine consisting of many physical machines. Thus, Plan 9 user services present as hierarchical file systems and the machines a user accesses exchange individuality for function. A user may, that is, access a service such as program execution on a CPU server without needing to know anything about that machine in terms of where it is, who owns it, what kind of CPU(s) it has, or what other resources may be available to it locally. Within the current releases of Plan 9 the core user authentication functions are handled by an agent called factotum that handles all security interactions on the user’s behalf: instruct factotum on the clearances you have and any service requiring authentication can query it, instead of you, to determine what to do about the request. Technically, this has the enormous benefit of taking the entire cryptographic exchange burden out of the hands of both users and application designers. Managerially, it completely avoids most of the complexities associated with supporting large numbers of users in many-owner, single sign-on environments.
In its simplest form, you authenticate at the local level, instruct factotum on dealing with authentication queries, and it works with the network operating system and factotum aware applications to automatically recognize that authentication anywhere the system operates. Given that the factotum implementation is rigorously based on a mathematical representation of the authentication problem, can use multiple encryption methods independently, and is operationally quite simple, it is likely to be extremely difficult to subvert. Factotum is considerably simpler in concept and more robust in implementation than the protocol and strategy produced by the Liberty Alliance. The two do, however, bear a vague relationship. It is perhaps what you’d get if some members of the committee putting together the liberty protocol looked at Passport to see what errors to avoid while others remembered reading about Plan 9’s authentication solution. Read the Liberty documentation carefully, recognize that the alliance specification has to work over a much larger and more complex set of ownership, control, and technical interactions, and the two sets of ideas start to look like cousins.
One of the links between them is in an alliance specification concept called "circles of trust" that would map rather well to global or enterprise-wide Plan 9 implementations if those existed in commercial reality. In such an environment, the network really would be the computer — and that’s a key reason I expect Solaris 3.0 to incorporate this functionality as it absorbs more and more of the Plan 9 idea set to deliver truly distributed access to computing resources. If it happens, that will provide a powerful commercial reason for people to adopt these ideas and thus create additional impetus behind their adoption in the general open source world. If so, we’ll have a very clear cut battle for market dominance between Microsoft and open source ideas on single sign-on:
In the old days of Windows dominance, the outcome would have been a no-brainer. When Microsoft pointed its checkbook, people surrendered. However, that world is rapidly going away. Now ordinary users mutter about security, governments look at Windows-brand products as national security risks, and lawyers gear up to feast at the tort table as the courts start to enforce our liability for losses to clients whose information we abuse. With factotum in play, legally "accepted industry practices" may soon no longer include Passport and trying to make a quick change back to Firefly’s original ideas or the MSN wallet solutions will probably just make it all of this worse for Microsoft. Why? because "accepted industry practices" in an unregulated industry are set by a kind of majority vote. The dominance of the Apache toolset means that Microsoft won’t have the votes to enforce its approach over technologists’ objections or in spite of customers’ legal risks. Open source, on the other hand, continues to gain ground as part of the solution. A rapid public win by factotum over Passport may be enough to flip attitudes in the mainstream press from near automatic approval of Microsoft press releases to due cynicism.
LATEST APACHE DEVELOPER STORIES
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK BREAKING APACHE DEVELOPER NEWS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
| | | | | | | | |
|
|
|
|
|
|
| | | | | | | | | | | | | | | | |
|
|
| SYS-CON MEDIA: | | | | |
| SYS-CON EVENTS: | | | | | |
| INTERNATIONAL SITES: | | | | | | | | | | |
 |
Terms of Use & Our Privacy Statement  About Newsfeeds / Video Feeds |
| Copyright ©1994-2008 SYS-CON Publications, Inc. All Rights Reserved. All marks are trademarks of SYS-CON Media. |
| Reproduction in whole or in part in any form or medium without express written permission of SYS-CON Publications, Inc. is prohibited. |
.gif)
What are the benefits from using Cloud Computing services or platforms? Cost efficiency, shorter innovation cycles and scalability are frequently mentioned promises. However, the value proposition of Cloud Computing obviously depends on the corresponding business scenario. You ca...
The year that's just ended was a terrific one for the proliferation of new technologies and frameworks. I have been hearing a lot about the following technologies in the year 2008: mashups, cloud computing, domain modeling, Eclipse - especially Equinox, Single Sourcing, and Eclip...
It’s time to wrap up the year 2008 - a year of change with Obama, the Olympic Games and the financial crisis. It was also the year when Yahoo said no to Microsoft. 2009 will be all about Cloud Computing: the technological hype has started already but the commercial breakthrough...
It's no secret that open source has turned into a market force, which is giving enterprise software some tough competition. The same can be said for SaaS businesses, which are steadily eating into the market share of the established on-premise players. While it could easily be as...
