The Network as a Service

I watched an excellent presentation by James Aitken today here at the OASIS "SOA for Telecoms Workshop" at picturesque Ditton Park in Buckinghamshire.

James works for Aepona, a well-regarded vendor of Parlay-X Gateway products which put a Web Services interface in front of telecoms systems, allowing developers to "drive" the telecoms systems using Web Services. Essentially, they put an API in front of telecoms systems.

What I liked about James' presentation was that it used simple, practical examples. Up-front, he said that most telecoms usage is for voice (obviously true, but it is amazing how often people hype up the data portion, without realising the power of voice). He talked about Parlay-X's "MakeACall" operation. I sometimes use this as an example to show how you can setup a telephone call by calling a Web Service, but I never explain why you are setting up the call. But James provided a neat example which put it into context: Imagine a dating site where two people exchange messages and then want to go to the next stage, actually talking to each other on the phone. Using "MakeACall", a developer can write a simple application which will call both parties anonymously and put them together in a phone call, without revealing their real phone numbers to each other (in case the call doesn't work out!).

This is a neat example. It also made me think about (a) how Ebay may have bought Skype for something similar (the ability to setup calls between bidders and vendors in an auction), and (b) BT's acquisition of Ribbit, which allows you to programmaticall setup a call within a Web Browser. In the Ebay case, you're using Skype to make the calls. In the Ribbit case, the phone call happens within the browser. But in the case of Parlay-X, it just uses your regular phone.

He mentioned that calling telecoms operations like this is an example of "the network as a service". A neat term, a new take on "The network as the computer".

I wonder is the provider of these services logically the operator, or is it a third-party aggregrator like CDYNE, who provide Web Services for placing phone calls (for 9c a pop) even though they themselves are not a phone company.

And also, echoing something James said, why aren't more people using these Web Services to develop applications?

Service Virtualization in a Web Services world

Service Virtualization is made possible by XML Gateways. But how? To answer this question, I've written an article on Service Virtualization in a Web Services World for SOA World magazine. Check it out at http://soa.sys-con.com/node/676154.

If you want to Service Virtualization in action, view this screencast I made on Service Virtualization.

Vortex 2008

Vortex continues today, here at the Guinness Storehouse in Dublin, with VCSE (Vordel Certified Systems Engineer) training.

In the meantime, here are some photos from yesterday:

Our CEO, Vic Morris gave the opening keynote:



Don Adams from TIBCO spoke about SOA Security as a "modern shilleligh":



David Yates from EBS spoke about governance:



Shashank Rajvanshi spoke about end-to-end security:



Theo Dimitrakos from BT spoke on policy:



Eddie English from Dell updated everyone on Dell's energy-conscious products



More to come!

It's all happening today

At 5.30pm today, Vordel's Vortex 2008 conference kicks off with a welcome reception at Berry Brothers and Rudd wine shop in Dublin [by the way, check out their wine blog]. The conference sessions begin tomorrow morning at the Guinness Storehouse conference center.


[images from bbr.com]

Over in New York, John Wilander is blogging (in Swedish) the Web Services Security training course at OWASP AppSec 2008.

And, in the virtual world, the SOA Governance conference takes place today at 11:00 today (though its website doesn't say which timezone that "11:00" is, or even if it is AM or PM! What timezone do you use for a virtual conference?).

Needless to say, I'll be at the decidedly non-virtual Vortex reception, with its non-virtual food and wine.

CSI 2008 in Washington DC in November

I'm speaking at CSI 2008 near Washington DC on November 17. My talk will go into more detail on vulnerability assessment of Web Services, including techniques like CDATA Smuggling.

OASIS Open Standards Forum 2008

I'm speaking as part of a panel on "Securing your Enterprise: Real World Scenarios for Vertical Industries" at the OASIS Open Standards Forum 2008 in London next week. I'm joined on the panel by Ludwig Seitz from Axiomatics, Anil Saldhana from Red Hat, and Sampo Kellomäki from Symlabs. I'll also be giving a short presentation about four case studies of secure, managed SOA (One fixed-line telecoms, one mobile telecoms, one government, and one banking/insurance).

SOAP Faults - Too much information

I gave a presentation at the RSA Conference back in April about "Case Notes from a Vulnerability Assessment of a Bank's Web Services". A thread running through the presentation was that SOAP Faults present "Too Much Information". Every time we sent an XML message which broke the bank's Web Services, we would get a SOAP Fault message which included information that is helpful for an attacker. For example, one message showed a Hibernate stack trace, indicating to us that Hibernate was being used. Another message, prompted by an External Entity attack, gave us back information about the local file system path. Check out the presentation for all the information (anonymized though, so you don't know the identity of the bank, which is still in business :-) ).

Most users of the Vordel XML Gateway know that you can assign a SOAP Fault as a fault handler, and customize what goes back to the client in the SOAP Fault. Also, most users know that you can create a reusable sub-policy which is called by another policy (like a subroutine in a programming language, and, indeed, like a reusable Web Service). But did you know you can combine the two capabilities? You can create a reusable policy and assign it as the fault handler.

In the example below, I have dragged in a "Policy Shortcut" onto the canvas. I right-click on it and say "Set as Fault Handler". So, if the XML Gateway finds any problem with the XML message, or with the back-end Web Service, then it runs this sub-policy. The sub-policy I'm using ships as standard in the "Policy Library", and it simply returns a HTTP 403 "Forbidden" message to the client. This gives no information to the client about why exactly their message was blocked. As part of that sub-policy, you could also send a notification to an administrator, return back a cached response from the Web Service, strip out part of the message which is harmful, quarantine the message, or redirect the request to a back-up Web Service.

Another free analyst report: Policy Management for SOA

This ZapThink ZapNote is written by David Linthicum and provides recommendations for policy management in SOA. It covers Vordel's products for policy management (including Policy Director).

Get the report from the Vordel Website (registration needed). Or from Amazon

Quote:

"policies are as important to SOA as Services themselves, and they should be managed throughout their lifecycles as such".

XML Gateway Integration Guides

If you are a Vordel customer or partner with access to our Extranet, then you should check out the Integration Guides section. There you will find integration guides for connecting the XML Gateway to WebSphere MQ, TIBCO, CA SiteMinder, Sonic MQ, and many more third-party systems. Each integration guide is a PDF document, including screenshots, which you can print off and use.

Check them out...

EBS Session on SOA Governance at the Vordel Conference

When I posted the Vordel Conference agenda last week, I left a "details to follow" for the EBS talk. Well, here are the details.

Firstly, some background on EBS (website: www.ebs.ie): EBS is Ireland's largest building society. It is owned by its members and is not a bank (therefore, no current accounts). It provides mortgages (commercial and residential), personal loans, and savings accounts, as well as other financial products.

On the Vordel site there is some background about EBS's deployment of Vordel's products. Here are some snippits from that:

The Vordel solution provided a governance framework for an IBM infrastructure to enable EBS roll out new services and products to its channel partners in a controlled manner.

...

Overlaying a security framework on the IBM WebSphere SOA platform, Vordel provided the ability to enforce policies at all application endpoints.

...

allows policies for governance and compliance to be applied to XML applications throughout their networks, with centralized policy management and monitoring of traffic to centralized log files.

...

These policies covered access management, encryption, digital signature and XML threat analysis, as well as Service Level Agreement monitoring and maintenance of searchable audit logs.

[More details at: http://www.vordel.com/news/press/6_06_07.html]

The presenter is David Yeates, Senior Manager IT Architecture at EBS.

Here is the abstract for the session, taking place at 11.40am on Thursday September 25 at the Vordel "Vortex 2008" conference at the Guinness Storehouse in Dublin:

"An end-user organization's perspective on what SOA Governance really means"
A case study exploration of how a leading financial house has managed the roll out of Web Services as part of an entire SOA Governance process. This presentation explores the distinct lifecycle stages between design time, testing and staging, runtime enforcement, versioning and change control.
Mr. David Yeates, Senior IT Architecture Manager, EBS

Google SAML Vulnerability

A team from AVANTSSAR (Automated Validation of Trust and Security of Service-oriented Architectures) recently publicized a vulnerability in Google's SAML implementation. The best way to learn about the implications of the vulnerability is to view the video which they produced to demonstrate it.

The AVANTSSAR team informed Google of the vulnerability before they publicized it, and Google has already implemented a fix, and changed their online documentation.

The flaw involves the way in which Google used SAML for single sign-on (SSO). It doesn't mean SAML itself is flawed. However, Google implemented it in such a way that if a user was granted access to a Service Provider (e.g. a Website), then that Service Provider could use the SAML Assertion (a kind of security token) to access Google applications (such as GMail) as that user. If that sounds complex, go and look at the video from the AVI link above, since the AVANTSSAR people use a concrete healthcare example which makes it simple to understand.

Now, the vulnerability involves a rogue Service Provider. And, as Kim Cameron from Microsoft points out, "The problem is that if you have a huge site like Google, which brings together many hundreds (thousands?) of services, then with this approach, if even ONE of them “goes bad”, the penetrated service can use any tokens it gets to impersonate those users at any other Google relying party service. It is a red carpet for insider attacks. "

An interesting reaction to this story, from Jackson Shaw (also from Microsoft) is that the youth of Google's SAML engineers may have contributed to the problem. He asks "Could Google's predilection for those who have just emerged from the fountain of youth have contributed to this SSO "disaster"? " He may be on to something there. The "more mature, industry (and customer) schooled professional who has been around the block more than once" (as Jackson Shaw puts it) may have thought "back during Project Athena in MIT, I remember that Kerberos was designed so that session tickets are only valid for a particular resource", and thought about whether a rogue Service Provider could impersonate the user to access different services.

Google has always published all the information about their usage of SAML, including sample code. This is good. It meant that the AVANTSSAR people were able to use this public information to analyze the Google SSO implementation. Because, believe me, there are many organizations using home-made implementations of SAML that are not publicized and which are vulnerable to replay attacks, do not used signed assertions, and (as in this case) allow assertions to be "hijacked" to impersonate a user. That is the truly scary part of this story. XML Gateway vendors can help, by ensuring that their customers are using policies which ensure that SAML assertions include the appropriate Recipient attribute in the SubjectConfirmationData element, which indicate that the SAML Assertion is in fact intended for their service (and not hijacked by another service provider).

Here is an example policy I've set up on a Vordel XML Gateway which performs a series of steps to validate and verify SAML assertions. This includes validating the signature over the SAML assertion, validating its structure, ensuring it has not expired, etc.



In the Policy Studio, if you double-click on the policy element called "Validate that the recipient specified in the SAML Assertion is appropriate", you see the configuration which is ensuring that the Service Provider mentioned in the SAML assertion is appropriate (i.e. that the SAML assertion is not a hijacked assertion which was intended for a different service provider):

Free analyst report on XML Gateways

The Butler Group has performed an independent analysis of Vordel's XML Gateways and associated Vordel products (policy management, monitoring, XML acceleration).

You can get the report now, free of charge, from the Vordel Website.

Vordel Video

The Vordel site has a video screencasts section behind the new "Vordel Video" logo. Here you can see videos of XML Gateways in action (and, I mean videos of the configuration and real-time monitoring, the actual gateways are usually boxes sitting in a rack which are not so exciting to watch in action!).

The need for speed

It seems like a truism to say that XML Appliances are particularly suited to processing XML Signature and XML Encryption. But, let's look at exactly why they are suited to this job...

SSL Acceleration

For SSL, a whole industry of SSL Acceleration Cards grew up (e.g. nCipher, who are speaking at the Vordel Conference on Thursday 25th). These cards accelerate the handshaking part of the SSL transaction, the part which uses asymmetric (public and private key) cryptography. The cards are particularly useful where a large number of browsers hit an ecommerce website at the same time (e.g. following a television commercial advertising the site). For each one of the browsers, handshaking must occur. If this occurs on the main CPU, it goes slowly and the site becomes slow. If it uses a cryptographic acceleration card, then delays are minimized. Once the handshaking happens, a secure session is established, and the session includes a symmetric encryption key. Subsequent traffic from that browser goes over that session, with the symmetric encryption using the main CPU not the acceleration card. i.e. The hardware acceleration is used for the assymetric (public and private key) operations.

XML Security

With XML Signature and XML Encryption, public and private cryptography is used (as well as a digest algorithm in the case of XML Signature, and a symmetric algorithm in the case of XML Encryption). This is accelerated by the use of cryptographic acceleration cards. Just as important, the cryptographic processing is taken off the core CPU, so it does not slow down the application.

Don't forget about XML Acceleration too

XML Gateways, such a Vordel's, go a step further by taking the both the cryptographic processing and the associated XML processing off the application and putting it onto the network. Remember, processing XML Signature or XML Encryption includes a significant amount of XML processing as well as the actual cryptography, and that is accelerated by an XML Acceleration subsystem.

A CPU hit for every single message

So, putting this into context, let's say a client sends 100 XML messages to an application. Here are two scenarios:

Scenario One: SSL only
If SSL alone is used, with no XML Encryption or XML Signature, then the CPU is only taxed for the initial handshake. The 100 message then sail through on the symmetric session which is then created, without acceleration being required at that point.

Scenario Two: The XML messages are signed and encrypted
In this case, each XML message is signed with XML Signature and encrypted with XML Encryption. If hardware acceleration is not used, then the application will slow noticably as the CPU is taxed with the task of processing the assymetric cryptography for every one of the 100 messages.

In fact, the most likely scenario is:

Scenario Three: The XML messages are signed and encrypted, and sent over SSL
This will tax the CPU for the initial SSL handshake, and then for the asymmetric cryptographic operations for every single one of the 100 messages.


Scenario 2 and Scenario 3 are the reasons why the addition of an XML Gateway can have a dramatic performance benefit on an application which must perform XML Signature and XML Encryption. XML security is arguably more of a sweet spot for cryptographic acceleration than ecommerce ever was.


Footnote:
There are specifications such as WS-SX which allow for an SSL-like session to occur over multiple XML messages. That would mean that if a client sends 100 messages, then the signing and encryption can make use of negotiated keys (much like in case of an SSL handshake). However, WS-SX is not widely used yet, by any means.

Oracle and BEA come together

The Register reported last month that BEA WebLogic is now Oracle's strategic Java container, and that it is getting an infusion of features from the Oracle Application Server.

This gives an opportunity to look at some Oracle and BEA deployments of Vordel's XML Gateways. So, let's look at an example of each...

In the scenario below, deployed for a mobile telecoms operator, WebLogic is used. The Vordel XML Gateways sit in front of WebLogic and dynamically populate the XML messages with mobile phone subscriber information gleaned from an array of Oracle databases, as well as authenticating the senders of XML traffic. The on-the-fly "enrichment" of XML with client data is an example of XML Performance Offload, since this takes that processing task off the application server, and makes use of caching, XML Acceleration, and cryptographic acceleration (when the information "injected" into the XML is signed).



In the following example, for a solution spanning VoIP and mobile telecoms, we see Vordel XML Gateways being deployed in front of the Oracle Application Server. In this case, they implement key XML processing which have been offloaded from the application server. Effectively, combined with the load-balancer, the XML Gateways are acting as an Application Delivery Platform for the Web Services.



Note that in both diagrams above, the XML Gateways are acting not only on the traffic going into the Oracle and BEA Web Services, but on the response traffic also. It is important not to forget to process Web Service responses.

The claim bridge

Gunnar Peterson writes a must-read post which follows up on another must-read post by Ian Grigg about how banking systems tend to be based on a "series of claims" which "meet together in a holy ring of righteous architecture. Each of the proponents claim loudly that their part is strong, but the ring has no strength. Eventually, one of the claims in the links is broken."

In his post, Gunnar points out that banks often "build a web silo and then they hook it up the legacy silo and put a wide open messaging system in between. There is no end to end security design, just silos". There is a series of claims, but each can be broken.

Often, as Gunnar has pointed out before, the messaging system front-ending a mainframe is the point of weakness in the system. These systems tend to run on a "if a message has gotten this far, then it must be trusted" basis. And, rather than thinking in terms of the overall security context (tying the end-user right back to the mainframe transaction, with an audit trail all the way), the security context tends to collapse down to a single "MQ User" at the mainframe. This is often why, perhaps the case of the account siphoning example in Ian Grigg's post, information about the user identity (withdrawing $300,000 unnoticed over the course of 15 months) was not tied back through the system [and it was left to the user, analysing their statements, to figure out that the money was being withdrawn fraudently].

One way to address this is to think about the security context over the whole transaction (i.e. across the "series of claims") and not just thinking about each step on a claim-by-claim basis. For example, this is why Vordel has worked with Risaris to map X.509 certificates to a RACF/ACF2 or Top Secret User ID. So, rather than accessing the mainframe as a "MQ User", meaningless in an audit trail and unable to benefit from the native mainframe security, access to the mainframe happens in the context of a particular user.

Freud wrote that dreams are the "Royal Road" to the unconscious. Messaging Systems and mainframes can be the Royal Road for a malicious user to attack a banking system, unless the security thinking moves from a "claim by claim" thinking to thinking about the full transaction.

Vordel Conference - Look who's talking

The Vordel "Vortex" Conference in Dublin later this month features (in order of appearance) speakers from TIBCO, Washington Mutual bank, BT, EBS (an Irish bank), CA, CSC, Dell, and nCipher.

It promises to be a great event, with a nice mix of end-users and technology vendors. The second day (Friday 26th) is devoted to VCSE (Vordel Certified Systems Engineer) training. And if you are up for it, immediately after the Vordel conference is the Podcamp Ireland social media "unconference" down in Kilkenny.

Here is the Vortex schedule:

Wednesday 24th September 2008

7.30 - 19.30

Conference Registration and Welcome Reception The pre-event drinks reception will take place at Berry Bros. & Rudd wine shop on 4 Harry Street a stone's throw from Grafton Street and across the road from the Westbury Hotel. Berry Bros. & Rudd is one of the oldest wine merchants in the world and can trace its origins back to 1698.

Thursday 25th September 2008

08.00 - 09.00	Conference Registration and Refreshments
09.00 - 11.20	Opening Address Vic Morris, CEO, Vordel Service Oriented Architecture, Security and a Modern Shillelagh An SOA cannot be deployed without usage monitoring, traffic control, and protection from attack. XML Gateways provide this functionality, by allowing identity and security to be overlaid onto an SOA. In this way, crucial business services can be exposed in an SOA with confidence. This presentation explains how identity and security apply to SOA, allowing the benefits of SOA to be realized, without the pitfalls. Don Adams, CTO, TIBCO Top Ten Security Lessons Learned from implementation of SOA for a Large Enterprise Since 2004, Tom has been implementing a services oriented approach at Washington Mutual Bank as its SOA Security Architect. In that timeframe the company has successfully rolled out numerous internal/external services across its Credit Card, Commercial and Retail business units, enabling secure banking in and across each. In this session Tom will share with us some of the key insights and experiences gained by the business along the way and shed some light on the critical technologies involved. Tom Ray, SOA Security Architect, Washington Mutual Bank Security and Governance in Service Oriented Infrastructures BT Group will highlight its Research Service Oriented Infrastructures programme and provide examples of SOA solutions that facilitate secure end-to-end service integration within enterprises and across business partners. This is achieved by securely virtualising enterprise applications and resources, by securing their exposure to customers and by enforcing content- and context-sensitive policies about service presentation, end-to-end transactions, federated identity, usage and access control, intelligent routing and QoS obligations. Finally we will refer to external collaborations examples where these concepts are being trialled, including the BEinGRID research and innovation initiative that has 96 partners and coordinates 25 business pilots of Web Services and Grid technology in different business sectors. Theo Dimitrakos, Head of Security Architectures Research, BT Group CTO
11.20 - 11.40	Break
11.40 - 13.30	EBS Case study - more details to follow. Mr. David Yeates, Senior IT Architecture Manager, EBS 5 Industry Use cases of XML gateways in Telecoms, Government and Insurance This presentation sets out the practical ways enterprises are using XML gateways to accelerate manage and protect XML applications on the network. Mark O'Neill, CTO, Vordel CA In this session CA will explore the SOA Security landscape, challenges and how to address those challenges. This session also includes a case study. Shashank Rajvanshi,Principal Product Manager, CA
13.30 - 14.30	Lunch
14.30 - 15.50	Policy Driven SOA For SOA to reach its fullest potential, it is critical that the next generation SOA initiatives aim beyond reusability and interoperability, which, while not trivial, are nevertheless now being taken for granted. In such endeavors, policies become as critical as services themselves. As such, they need to be understood in the broadest context of the role they can play in mainstream business through the many stages of the application life-cycle, from planning to run-time and beyond. Such an approach will not only help in improving business-alignment of SOA, but also it enables the resulting systems to be self-diagnostic and self-corrective. In this session, Mark and Sreedhar present the case for moving towards such an infrastructure, after first explaining what policies are and how they are currently being used. Co presented by Mark O'Neill, CTO, Vordel and Sreedhar Kajeepeta, SVP and CTO, CSC Covansys Corporation Trends in the Data Centre and Managing the Challenges This session examines key data centre issues such as capacity challenges, deployment, costs ecalations and the regulatory impact of Green IT and will set out how the industry is confronting these challenges head on. Eddie English, Enterprise Marketing Program Manager, Dell.
15.50 - 16.10	Break
16.00 - 17.30	nCipher Mark Balsom, Sales Engineering Manager EMEA, CISSP, nCipher Vordel Product Roadmap A step into the future with Vordel's product management team. We take you into a preview of where the next generation of product is going in order to meet your requirements and the ever evolving market needs. Roundtable Panel Session Join speakers and other panelists in this highly interactive session, as they discuss the hot topics of the day from SOA Governance, through Web 2.0, WOA, ESBs, Policy Management, organic SOA vs. enterprise wide SOA and a plethora of other themes. MC Vic Morris, Vordel CEO
17.30 - 20.00	Networking and Drinks Reception in Guinness Source Bar

Thursday 25th September 2008 (VCSE: Vordel Certified Systems Engineer training )

14.00 - 15.30	Vordel Certified Systems Engineer Training - certification for attendees. Technical sessions with hands on lab environment and training.
15.30 - 16.00	Break
16.00 - 17.30	VCSE training with lab environment
17.30 - 20.00	Networking and Drinks Reception in Guinness Source Bar

Friday 26th September 2008 (Workshop)

09.00 - 11.00	VCSE Training - certification for attendees. Technical sessions with hands on lab environment and training.
11.30 - 12.00	Break
12.00 - 13.00	VCSE training with lab environment
13.00 - 14.00	Lunch
12.00 - 13.00	VCSE training with lab environment

OWASP NYC Training

Gunnar Peterson is teaching a training course on Web Services Security at OWASP NYC later this month. Gunnar's course is on the 22 and 23 September in New York City, right before Vordel's Vortex Conference in Dublin. So you could attend Gunnar's training on the 22 and 23, then on the 24th fly from JFK to Dublin, in time to catch the opening Vortex keynote which is Don Adams's (TIBCO CTO) talk on "Service Oriented Architecture, Security and a Modern Shillelagh".

Gunnar's training is highly recommended. If you don't believe me, check out his testimonials.

The last mile

Fidel Santiago asked a great question in a comment on a previous blog post about XML Decryption.

The answer deserves a blog post of its own. So here it is!

Basically, the question is: When you do XML Decryption on an XML Gateway, what about the last mile?

It is a very good question. Taking a step back, let's remember that the advantages of doing XML Decryption on the XML Gateway are that:

(1) You are storing the private key in hardware (and not in a keystore on the file system as is the usual practice at a Web Service host),

(2) you get better performance than you would at the Web Service host, and:

(3) You can configure the XML Decryption based on a centralized policy, independent of the Web Service host.

But, you still have to think about the end-to-end security. Because you have to answer the question: "What about the connection from the XML Gateway to the Web Service host?".

You have a number of options for this. You can:

(a) Setup a mutually authenticated (and encrypted) SSL connection between the XML Gateway and the Web Service host. This has the advantage of being fast, even for an app server back-end which has no crypto acceleration card (hardware acceleration is only required for the session negotiation part of SSL, and once the session is established, it's fast). In this way, no attacker can connect directly to the Web Service, and the only client which can connect to the Web Service is the XML Gateway itself (which has the private key to authenticate, and it stores its private keys on hardware, so nobody can impersonate it). This is simple to configure on all Web Services platforms, and you have only one "user" (the XML Gateway) to manage. For example, I have set this architecture up myself in customers where the Vordel XML Gateway sits in front of SAP Netweaver.

Or you can:

(b) Run a software XML Gateway right on the Web Service host itself [i.e. at the "Last Mile"]. you still have to make sure that clients cannot just trivially connect to the Web Service directly.

Or, similarly:

(c) deploy an agent embedded into the Web Service endpoint host itself, at the last mile (such as the agents provided by Vordel's partners CA and Oracle). Agents are the classic solution for the last mile, and an alternative to using the host-based security in option (a) above.


It may be tempting to re-encrypt the XML at the data level at the XML Gateway and then decrypt it at the Web Service host. If you do this, you're falling into the traps of key management at the Web Service host (most app servers will just store the keys in a keystore file on the file system) and performance. The reason for re-encrypting at the XML Gateway would be to selectively encrypt part of the XML so that certain Web Services cannot see that data (e.g. "de-identitication" of medical records by removing patient IDs).

Another kind of Identity Federation

Looks like Ping Identity's identity has been, um, "federated" here

Security Token Service (STS) Video Screencast

There is a new Security Token Service (STS) screencast up on the Vordel website. This screencast is about 8 minutes long and walks the viewer through the process of deploying an STS on the Vordel platform. Examples of the WS-Trust messages (RST - RequestSecurityToken and RSTR - RequestSecurityTokenRespose) are shown.

Vordel's STS runs on the same VX Platform as our XML Gateway and XML Firewall, so it benefits from the same underlying XML acceleration subsystem, and the same array of connections into identity management infrastructure.

STS's have several advantages, such as the fact that they put a standards-based interface in front of underlying identity management infrastructure which is not always as standards-based as architects would like. Also, they act as a point of control for the issuance of identity and attribute information, which is preferable to simply hooking applications up to identity management infrastructure directly (a potental privacy and data loss prevention nightmare).

So, if you've wondered "What is an STS and why should I care?", check out the WS-Trust Security Token Service (STS) screencast

Playing with XAML

"Expression Blend 2" sounds like an upscale coffee beverage, but is in fact a Microsoft tool for creating user interfaces. It is described well in the screencast video here on the Microsoft site [Click on "Play / See it in action"].

The interfaces created by Expression Blend 2 are defined in XAML. XAML (pronounced "Zammol") itself sounds like it might be an XML dialect for describing Zammo from Grange Hill, but in fact it is (as Microsoft explain in the MSDN "XAML Overview") an "XML-based declarative language" for the representation of interface data used across Microsoft products. XAML-supporting Microsoft products include Visual Studio and Silverlight. So, XAML basically allows application interfaces to be described and created declaratively. Indeed, in Expression Blend 2, you can "View XAML", if you want to drop down to that level. A designer can also use XAML as a way to pass interface information over to a developer who uses Visual Studio.

But wait... what does "XML-based declarative language" mean? Is it actual XML, or just "XML-Like"? The Register today has a good intro piece on XAML. Look at this example from that Register piece, it's a standard use of an XML attribute to assign a "Fill" to a rectangle, right?

<Rectangle Height="20" Width="50" Fill="Gold" />

But as well as supporting this standard XML usage, XAML also supports a "dot" notation to add an "attribute" to an element. Here's an example:

<rectangle height="20" width="50">
<rectangle.fill>
<solidcolorbrush color="Gold">
</solidcolorbrush>
</rectangle.fill>

</rectangle>

And that's not all. Here is another example from The Register:

<rectangle height="20" width="50" fill="{StaticResource MyGradientBrush}">
</rectangle>

It's still well-formed XML, but what are those curly braces in the "Fill" attribute for? Well, this MSDN article informs us that "curly braces ({ and }) have significance in XAML because these characters inform a XAML processor that a character sequence enclosed within the braces must be interpreted as a markup extension".

So, although XAML is XML, in order to validate it, a validator has to be aware of the significance of the "dot-notation" and the curly-braces within attributes. So, it's "XML based", as Microsoft say, but in some ways it goes beyond XML.

Now that we've seen what XAML is, let's apply some XML Networking ideas to it. Let's see an example where we use XML Signature to selectively sign information in XAML. In the example screengrab below, I have signed data within an XAML document using a Vordel XML Gateway, then viewed it in SOAPbox so that you can see where the XML Gateway has put an XML Signature block into the XAML. You can see by looking at the XPath highlighted in blue that the XML Signature points at the signed portion (in this example, the book information which is to be displayed to the user).



Once the data has been signed, the XML Signature over the XAML data can then be validated, either at the .NET application itself or by another XML Gateway, to ensure that the data has not been tampered with. It is easy to think of applications in the healthcare (showing patient records in a .NET application) or government areas. It also applies to the classic "What you see is what you sign" requirement for electronic signatures because, in this case, the XML Signature can apply to the user interface as well as to the data. Additionally, the use of XML Acceleration means that the addition of XML Signature does not slow down the application using XAML.

Similarly, XML Encryption may be used with XAML, for example to selectively encrypt patient records which may be displayed in a .NET healthcare application.

XAML has started to be used in anger in projects now, and will, by definition, take off in the .NET world. XML Gateways have a place to play in this. I will be writing more about XAML on this blog, and showing more practical examples.