I wish I was smart enough to pick a winner or tell you when a dominate approach will emerge. What I can tell you is the new efforts have learned from past mistakes. Vendor centric, heavy computational and policy unaware solutions were not deployable.

What I know for sure is the new approaches are XML centric and rely heavily on WS-SecurityPolicy, WS-MetadataExchange and WS-Trust. For these "new" approaches to be successful they will require simple APIs to create client components and high performance server components to allow large volumes on secure transactions.

Hmm, fast and easy XML processing! Where have I heard that before? ;-)

The recent announcements:

June 23rd, Liberty Alliance Releases Identity Assurance Framework. http://www.projectliberty.org/liberty/news_events/press_releases/liberty_alliance_releases_identity_assurance_framework

June 24th, Technology Community Forms Information Card Foundation to Simplify Secure On-Line Digital Identity. http://xml.coverpages.org/ICF-DigitalIdentity.html

June 25th, IETF released an updated vCard Format Specification. http://www.ietf.org/html.charters/vcarddav-charter.html

June 25th, Eclipse released Ganymede with its "Higgins" or user-centric identity framework. http://www.eclipse.org/

There are a number of XML appliance vendors (http://en.wikipedia.org/wiki/XML_appliance) all provide security to some degree but some bill themselves as XML security gateways.  These products implement various standards including WS-Security.  But today we will focus on defending against malicious XML traffic.

Malicious XML can be classified in three categories: Malformed Requests, Denial of Service and Content attacks.

Malformed Requests: May not be XML at all, but typically malformed requests have bad encodings, incomplete nodes or don’t adhere to a given schema.  Early, fast and complete validation is the best way to eliminate bad requests, but keep in mind if this processing is done on the perimeter it often means having to reparse the XML for all good requests when it finally reaches the application server.

Denial of Service:  Large payload requests, “billion laughs attack” and missing or broken URI references are some examples of requests were the sole intent is to consume processing time and create a denial of service.  Like malformed requests these attacks are most effectively handled with proper validation.  Again this if this is done on the perimeter the XML will need to be reparsed when it reaches the application machine.

Content Attacks: Are normally valid for a known schema.  These are attacks that use the data or XML elements to carry the attack payload.  SQL injection, Trojans and various application specific attacks are possible.  These application centric attacks can not be defended on the perimeter by a firewall.  It is the application that must properly process the data to prevent these attacks.

What is my advice?  Parse once, validate once.  The application server is the best place to do this, as it knows the schema and data rules that need to be applied.  Just because the perimeter can identify a bad request doesn’t mean it should.  Use a fast XML validator that makes use of multi-core in you application.  And when your app sees a bad request; allow it to notify the network layer to ignore all future requests from that source.  Bad requests are just that, bad requests.

What I am surprised about is the number of “security experts” that profess the way to stop SQL injections is to prevent the user from using characters like *, “, ‘, and #.  It seems to me not using SQL in the first place is the best way for an application to stop SQL injections.   Using a web service or SAML would eliminate the need for ODBC calls and the required SQL injection screening.

For those that think SSL answers all security problems.  There was a nice long debate on using usernames and passwords with SSL on http://webappsec.org/lists/websecurity/

Personally, I think it time security experts to stop spreading the misperception that all problems can be solved with a network device and time for application developers to step up and use the right not just the easiest security solution.

The herd had thinned by the last session, but those that stayed to the bitter end were treated to an interesting presentation by Ben Alex of Spring Source http://www.springframework.org/  (TS-6348).  What I found interesting was the response to his poll of the audience when he started his talk.  Ben asked what the audience was using for security: 1) The JDK default jars.  2) 3rd party security offerings  3) Roll your own.  A lot of hands went up for all 3 approaches and Ben declared it an even split.

What I found interesting is how many are still rolling their own security!  Have Bruce Scheider’s muses about broken implementations gone unheard?   I understand that some of the Java security pieces JSR105, JAAS, WSS4J can be hard to implement correctly, but Ben and others during JavaOne showed how their 3^rd party offerings put web service security just a mouse click away.  What makes security special to trump ease of use?

My guess is we have a hard delegating application security; we want the control.  How does some generic framework know that it is ok for my wife to change my airline reservation?   We know the everyday work-around is giving her my password.  Will the market continue to roll its own web service security?  And if so; why?  I would be interested in what you think.

If you could define new CPU instructions to improve XML validation, what would they be?

Well Yongnian Le from the XET team has ideas to share.  Does “Parallel TRIE with Intel® SSE4.2/STTNI” sound more interesting than a morning coffee?  For me yes, but please don’t tell my wife, she’s already has enough Ken’s so nerdy ammo.

A quick read that is a great introduction into yet another use of SIMD instructions.  http://softwarecommunity.intel.com/isn/downloads/intelavx/Schema%20Validation%20w%20Intel%20SSE4_WP.pdf

Ken.

We've already established you're a pioneer, looking for new ideas to make part of your vision.  I took this job at Intel because it was a chance to build fun new products, and part of that fun is working with true pioneers.  I spent a week in Shanghai this month with Dr. Michael Kay of Saxon fame. (www.saxonica.com)   Dr. Kay, along with Intel’s Frank Lu, presented at IDF to a room full of bright XML engineers from across China, (idf link).  Yes, for those of you outside PRC, pioneering XML work is being done in China by Intel and others.   Dr. Kay and I also spent time with Intel's XML engineering team in Zizhu.  Tremendous stuff I will share with you in a future post.

The topic of Dr. Kay's IDF presentation was declarative languages.  He commented that declarative languages are easiest to use when you attack the entire problem with declarative thinking.  Focus on the goal and let the machine, browser, or XSL transformer handle the implementation.  Easy enough, but as an old timer I have a hard time letting go of the control.  Maybe you do too?  We have all seen the ugly HTML caused by someone trying to control "centering" in HTML by defining it to be exactly 512 pixels from the left, rather than using CSS styles to center text and let the browser do its job and handle the implementation.  Or using JAXB to generate Java class from a schema, only to break everything when the schema changes, rather than letting the data drive the implementation.  This type of thinking is taking declarative half way, It's hard to understand, hard to maintain and is very ugly.

You're a pioneer; take declarative thinking all the way!  I would like to hear how you are making use of declarative languages.  So, go forth and make use of XProc, XQuery and user defined functions in XSL.  You will be glad you did.  Be rewarded with code that is adaptable, easy to maintain and an inspiration to others.  There are great tools from Intel, Saxon and others that will work for you today.  They are fast, compliant and ready for you to download now. I’d love to hear from the pioneers that read this.

Thanks, Ken.