XML School Shares Latest Interop, Security Tips

This July, a unique XML Summer School event will provide devs with their first drill-down look at implications for the Microsoft/Sun proposed specs for building interoperable security/identity for Java and .NET web services. Devs will get sample code, patterns and Best Practices for working with SAML, WS-Security and even the newly-proposed Microsoft/Sun specs from those who worked behind the scenes on the proposal.

Tags: Security, Web Services, Interop, XML, Maler, Developers, SAML,

In the wake of the Microsoft/Sun plan to launch specs to better ensure interop and single sign-on (SSO) for web services security and identity, devs have been scrambling for real code and real details.

This July, XML Summer School will provide devs their first hands-on look at designing and building interoperable security and identity frameworks for web services during a week-long event to be held July 24-29 at the University of Oxford, Oxford, UK.

Sponsored by sponsored by OASIS and Sun Microsystems, The XML Summer School will offer Java, .NET and legacy devs and architects plenty of tips for coding, design patterns and implementation. Of special focus will be to show developers how to best work with SAML, WS-Security and other standards - including the proposed Microsoft/Sun specs for web services SSO.

SAML + WS-* + Microsoft/Sun Cooperation
An Equation for Web Services Security Interop

The XML Summer School session "Securing and Identity-Enabling Your Web Services" will examine the particular challenges and opportunities of securing XML-encoded web service messages and their exchange, and doing proper authorization of client and service behavior. Which technologies are mature enough to be "safe"? How are the big questions of identity and business trust being answered?

The session will be presented by Eve Maler, who is an XML Summer School track chair, and who also was among those who worked behind the scenes to deliver on the May 15th Microsoft/Sun security interop pact.

The two draft specs from Microsoft/Sun, announced in mid-May, for making web services single sign-on (SSO) more interoperable across Java and .NET platforms is changing the interop equation for the better, Maler said.

The 2 specs - (a) Web Single Sign-On Metadata Exchange (Web SSO MEX) Protocol and (b) Web Single Sign-On Interoperability Profile (Web SSO Interop Profile) - are aimed at enabling browser-based Web SSO between security domains that use main web services security frameworks, including Liberty ID-FF and WS-Federation. Both specs will be among the drill-down topics during the XML Summer School, which sets the table for devs attending to get a running start on interoperable web services security.

"Future products that support the Web SSO MEX Protocol and the Web SSO Interop Profile will enable corporate developers to provide users with an improved Web SSO experience from their Web browsers," according to a joint statement by the Microsoft and Sun teams.

Maler, who attended the event where Microsoft CEO Steve Ballmer and Sun CEO Scott McNealy announced the proposed specs, described it this way in her weblog:

At this event, we did a demo of planned support for Sun-Microsoft interoperability in cross-domain single sign-on, using honest-to-goodness XML-based protocols. Ballmer prefaced it by predicting some people would think it's the most boring demo they'd ever seen because we'd be showing an integrated user experience. Charlie Feld, EDS executive VP and one of the several customers and system integrators offering testimonials that day, commented that with EDS's 100,000 servers and millions of devices and "the complexity that's been built in this 40 years' worth of junk yard that we call the IT era", he was actually excited about the demo. That felt damn good.
[Drafts of the new specifications are available on Microsoft's MSDN and Sun's developer website]

Just how devs can take advantage of these new specs to design and build web services SSO interop will be explored during the XML Summer School session. But, these new proposals will also be put into the context of more well-understood, and widely-available standards, Maler said, including SAML, WS-Security and Best Practices for securing business-critical XML traffic.

XML Summer School Agenda:
Where Devs Get Top Tips
for Web Services Security/Identity

Maler said the XML Summer School event will take developers and architects through a full design-to-build-to-troubleshoot lifecycle for securing web services across Java, .NET and other platforms. Among the topics to be discussed are:

(1) Security Design Patterns:
"There are a ton of security design patterns that people should be using for J2EE," Maler said, "but when it comes to web services there are additional ones, because you need to think about XML protocols and interesting new threats that you need to have counter-measures for."

For coping with these multi-platform threats, Maler said, "the idea is to in your mind outsource security [as a deliverable]. In other words, rather than having to think about building the whole [security] solution end-to-end, you're thinking about just building what piece your code set needs, and so you're not building it all but just thinking about how your piece fits into the entire machinery of a secure web services app, so to speak." .

(2) How to 'Think in XML' -- Not Just in "Objects"
"I have noticed among some programmers there is an anti-protocol model, which is understandable to some degree," Maler said. "And because XML is declarative - not procedural or functional, some developers don't think it's a real language."

But, that said, Maler added that adhering to standards is important to achieving rich interop, especially for security and identity services across platforms. "Anytime you have standards for how to represent something, something you don't get total choice in how you code it. But, those rules enable distributed computing because in effect those rules often times set the [interchange] agreements between partners," Maler said. "There is compromise, but otherwise, you would literally be in a silo and you wouldn't be talking to anyone else."

Maler offers an example: "If you're being handed an XML schema and you don't like it, sometimes you get handed some object models you have no choice about either. And, if it is painful, the Java web services toolkit, for example, takes care of a lot of stuff for you. So, there is bit of a mis-match between the data typing of Java objects and XML. But there need not be friction or any XML-specific pain out there because there are really excellent APIs out there that will take care of that."

(3) Unlocking Interop with Strong Design
Devs will also get insights and Best Practices from real-world use cases about how best to choose XML schema design and usage to get the biggest interoperability bang for their XML efforts.

Even though some developers might consider XML to be limited, there are some upside design payoffs from thinking in XML (i.e. loosely-coupled) terms, Maler said.

"This design payoff is really where the fun is," Maler said, "figuring out how generic do you make your data typing, versus how specific your needs are." Questions like 'When do I worry about the performance/security trade-off?' or 'When communicating with others, how much attention do I need to give to ensuring encryption and authentication for an XML Signature?' There are times when you can make your apps so secure that you're not able to talk to anyone. You're just living on an island," Maler warned. Presentations will detail how devs and designers can tap into Best Practices and XML templates for making the best choices when facing these trade-offs.

(4) Getting Past XML "Angle Brackets":
Tapping into XML's Business Value
Maler suggests that traditional language developers using Java, .NET C++ or other languages stop thinking of XML as just the "angle brackets" inside a code snippet.

"Angle brackets are really besides the point; syntax is the trivial part of XML," Maler continues. "It's in the semantics where all the interesting problems are. And, developers, when they stop to think about interoperable computing will see that this is the case is all kinds of distributed computing."

Maler takes an example from the world of web services security. "When you agree on SAML, for example, you know you're going be a requester (and send a SAML request), and get an assertion or response. You also know some action will then, or can, be taken."

But, to tap into interesting situational problems, Maler said, just add a couple of variables to this simple process. "Now, what if you are doing a role-based access control, and you are asking for some attributes, and you got a roll (as an attribute assertion). Well, you've already solved the simple 'angle bracket' [syntax] problem. But, you still haven't solved the problem [of semantics], where one partner (Company A) means one level of access for its 'manager,' another partner (Company B) means a different level of access for its 'manager' to mean something completely different.

The Maturing of SAML 2.0 -
Consolidating and Interoperating Standards

SAML 2.0 is still "absolutely a hot topic," Maler told Integration Developer News. In fact, SAML 2.0 will get even hotter, she predicted, "now that Microsoft and Sun have stopped not talking." The result of this growing détente will be deeper interop capabilities between SAML, Liberty Alliance Identity Framework and WS-Security.

Maler then put SAML 2.0 into context, both with prior OASIS work and with the Microsoft/Sun future work

"Over the last few years, OASIS has done a lot to reach out to developers, especially in terms of how they handle their intellectual property rights," Maler said. "And, I think that is helping make devs feel comfortable about implementing OASIS specs. So, for instance, SAML was one of OASIS' first big hits because it is based on an open standards, and has elements of Open Source technology."

Maler noted that for some developers SAML 2.0 was "a bit tough…to implement, especially as it was not fully backward compatible with SAML 1.0. " But, that pain came with some very big benefits, she added, as the ultimate goal of SAML 2.0 was to consolidate potentially divergent security approaches for web services. The move, in the long run, has made it much easier for devs and architects, Maler said.

"In SAML 2.0 we were looking to do a major convergence with Liberty Identity Federation Framework, and Shiboleth [a security framework for university environments]. So, we figured if you can deliver a convergence of some major security technologies into one [framework], so people down the road will have fewer head-scratching choices, then it's OK to have a little bit of backwards incompatibility," Maler said. "In fact, in many respects, it was that work toward convergence which will lead to SAML 2.0 being a mainstream tool for many developers looking at designing and building end-to-end interoperable security and identity for web services," she added.

SAML 2.0 Helps Devs Design and Build
Scalable Security Web Services

While many Java and .NET developers may roll their eyes at the thought of having to deal with cross-platform security, Maler says that SAML 2.0 takes a giant step in "enabling a universe where developers can help create robust, but loosely-coupled, security services."

"That's one of the messages I will be giving at XML Summer School: By setting up security services that are themselves web services, you in fact have created a loosely-coupled, distributed-computing kind of machinery with security as just another cog, so to speak.," Maler said. "To the developer, that means you don't have to hand-code lots of different variables or one-on-one security patches. Instead, you have a situation where, when you have the right cogs in place -- and you can get the [cogs'] teeth to mesh up, security should just happen."

In a very real-world way, Maler continues, "SAML is helping to ease the punctuation of security for developers, and it is also easing the grammar of how [devs] ask for things and how you get them."

As an example, she states, "SAML will give devs a host of very important elements that can be used for securing web services, including
(a) an authentication statement assertion;
(b) assurance that some [entity] has authenticated through password protected transport, and
(c) even a means to test interop between different directory attributes."

For its part, WS-Security provides a choice of bindings to different security tokens, all you have to do is agree in the infrastructure to pick whichever token you will use. WS-Trust is merely a token exchanger, a service-based model of getting the token you want.

But, each approach can quickly hit the wall, depending on the complexity of the traffic flow or the need for interop. Maler points out: When it comes to getting Company A [or system A] to share that with Company B [or system b], then devs enter the areas of aligning their directory schema, and in that world "there is quite a lot of room for disagreement and mismatches."

XML Summer School is all about showing developers how to quickly use the assets (patterns, Best Practices, code snippets, etc.) that exist for basic web services security/identity, and how they can leverage this knowledge for more complex projects - including transactions, B2B and granular policy access.

For curriculum and registration information on the week-long developer event, go to the XML Summer School website.