All posts by Paul Fremantle

WSO2, a Visionary in Comprehensive Application Infrastructure

Many IT leaders prefer to buy their application infrastructure software from a single vendor. In a recent report, Gartner helps teams understand the trade-offs associated with this strategy, and summarizes the strengths and cautions of comprehensive application infrastructure vendors.

Providing a who’s who in the vendor market, this research offers basic profiles for vendors that qualify to provide a comprehensive set of application infrastructure supporting an organization’s projects in the next three to five years.

Gartner cites WSO2 as a visionary in all three Magic Quadrants for Application Infrastructure including SOA Application Projects, Systematic Application Integration Projects, and Systematic SOA Infrastructure Projects. Of the vendors listed as options in the Comprehensive Application Infrastructure report, WSO2 is the only open source vendor included.

gartner-tabeSource: Gartner (January 2013)*

At WSO2, we are committed to working closely with our customers and the open source community to deliver a lean and highly adaptive middleware platform that addresses the demands of modern enterprises, whether their applications reside on-premises or in the cloud.

Click here to read the complimentary Comparing Vendors of Comprehensive Application Infrastructure Suites Report and see what Gartner has to say about WSO2.

– Paul Fremantle, CTO and Founder of WSO2

*This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from WSO2.

**Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.


Why Governance isn’t just for SOA – but Identity too!

People often think of security in terms of barriers. But anyone who looks after a barrier knows that its an ongoing process. And managing processes is what we call governance. A few years ago, I would talk to people who had put in place a firewall. They were convinced they were now “secure”. But then I’d ask what process they had to monitor the firewall and its logs. Unfortunately too often a look of “do I have to do that?” crept onto their faces. Without governance, a firewall is no good: if you don’t know someone is making a concerted effort to attack you, they will eventually get through.

It is not just firewalls that require governance. Increasingly I see examples of security issues that also are linked to governance. I think Wikileaks is a good example: whoever did it had too much access (not policy based but simply yes/no) and there was no “alert” that perhaps an unusual access pattern was in operation. Similarly I recently heard of a situation where an employee kept their online work log in for six months after they left the company.

Too many keys, copyright 2011 Jonathan MarshThere are two prime causes for this:

  • Firstly, there are too many identities. Each of us knows we have tens if not hundreds of identities on different systems. And there is no overall control of those identities.
  • Secondly, there are too many places that permissions are checked, or not checked. On the whole we rely on each application to implement permissions and there is a huge lack of consistency between these systems.

Its possible to fix some of these problems with manual governance processes. But even better is to automate them: the least human effort giving the most security.

We believe that there are two key technologies that can help:

1. Federated Identity Tokens

For example – SAML2 – the Security Assertion Markup Language v2 is a standard for XML-based identity tokens. These tokens give us two big benefits: single-sign on and federated identity. SAML2 can help unify as many systems as possible around a single identity. You can configure Salesforce or Google Apps to accept SAML2 tokens from a system driven by your internal LDAP. When an employee leaves, all you need to do is to remove them from your LDAP system and they are automatically shut out of all SAML2 based systems. This is an example of federating the identity from your internal model into Salesforce or Google. Amazingly, unlike most security systems that make life harder, SAML2 actually helps your users, because it gives them single-sign on onto many different websites.

How does SAML2 do this? The key benefit of SAML2 is that the user authenticates to a single “identity server”. Then this server creates a token which is trusted for a limited time by the target. The token can contain a variety of information (“claims”). These claims can be used as part of any authorization process. For example, a claim could assert that the user is logging in from a secure network.

2. Policy-based authorization and entitlement

For example: XACML – the XML Access Control Markup Language – does for authorization what SAML2 does for authentication. It allows a single policy based model for who can access which resources. XACML is very powerful too. It can work in conjunction with SAML2 to create very rich security models. For example, you can allow different access to users who are logged into a secure computer on a secure network as opposed to users coming via their laptop from Starbucks.

XACML does this by being able to capture complex “entitlement” logic into the Policy. The Policy is an XML file that can be stored in a smart registry. For example a policy might state that user Paul may access a salary update process between 9AM and 5PM GMT if Paul is in Role Manager.


The title of this blog is that governance is not just for SOA. SOA Governance has been — in our view — an area where the architecture community has learnt a lot of useful lessons. Let’s try to apply the SOA Governance lessons to Identity and Security Governance.

In the SOA world a common pattern for governance is the combination of a Registry and an ESB. The secret to this is:

  • Using policy and metadata instead of code, and managing the metadata in a Registry.
  • Moving towards a canonical model and transforming legacy systems into the canonical model.
  • Putting in place central logs and monitoring.

It turns out we can learn exactly the same lessons for Identity:

  • Using XACML to have a consistent model and way of defining authorization and entitlement using policy instead of hard-coding it into apps and storing these policies in a Registry.
  • Audit Log, Copyright 2011 Paul FremantleUsing SAML2 as a canonical model for Identity and bridging that into legacy systems as much as possible.
  • Using common auditing across your Policy Enforcement Points (PEPs) to ensure a single central audit log.

With this kind of model the governance becomes much more simple and automated. Removing a user’s login permission can remove login from everything. Authorization can be based on policies, which can be managed using processes. Even remote systems like Salesforce will still be included in the audit, because when a user signs in via SAML2, the SAML2 token server will create an audit event.

OpenID and OAuth are alternatives that perform similar and complementary functions to SAML2 and XACML, and are supported by a number of websites and web-based systems.

Good governance is tricky, and an ongoing process. The best way to get good governance is to automate it around simple straightforward approaches. The trio of metadata, canonicalization and log/audit is a great start and putting in place a solution around that architecture is an effective way to improve your Identity Governance.



Portions of this post have previously appeared in an article written by the author for Enterprise Features

Paul Fremantle, WSO2 CTO
Paul’s blog:

How much should you care?

A couple of weeks ago, I recorded a podcast with Paul O’Connor and Dana Gardner. Paul O is someone I’ve worked with on and off for about four years now, first as he helped customers Podcast iconnavigate SOA and now as he leads their thinking in Cloud. It was immense fun recording the podcast with Paul, but, if anything, we only scratched the surface of Paul’s thinking. He is one of the real visionaries of how Cloud is going to affect large businesses IT and completely rewire it.

Paul O believes that the end-game of true cloud computing is the ability for a business to completely focus on the business and have the IT from infrastructure to development completely available as a Service. Paul calls this the Grand Unified Theory of Cloud: consuming IT entirely as a service.

I personally don’t agree: I think that there needs to be a sliding line that divides IT from the pieces I have to care about to the pieces I don’t. Twenty years ago I cared about processor instruction sets and assembly code. Today I don’t. Today, I don’t care what actual hardware my Amazon images run under — there is a rough measure and the details don’t bother me. On the other hand, if I was doing algorithmic trading, I care even about the clock frequency I can rack the machine up to. I don’t believe that we will ever get to a line where the business doesn’t care about any of the details — that simply opens up an opportunity for another business to find competitive advantage by finding something to care about. But I do agree with Paul: at the moment we are forced to care about too many aspects.

Here at WSO2 we are trying to create a platform where you can stop caring about 99% of the middleware issues and we can provide a platform that just takes care of that for you. The real Grand Unified Theory of Cloud for me is being able to choose exactly what to care and focus on in your IT, and have the other parts just work — as a service.

Find the full podcast and transcript here.

Paul Fremantle, WSO2 CTO

Paul’s blog:

WSO2 in Banking and Finance

We have had a number of recent engagements using the WSO2 Carbon platform in the banking and finance industries, and I thought it would be useful to talk about some of them and highlight the ways in which we are working with financial institutions.

Our platform has currently been used by a number of financial institutions, in both retail and wholesale banking. For example, one financial institution uses our ESB in Asset imageManagement, several others use us for FIX support in various areas (e.g. Bond Trading, FX Trading) and meanwhile we have several retail banks that are using a variety of components from Carbon for full SOA enablement including Governance, ESB, distributed Identity Management and Data Services – for example two institutions in the mortgage and lending space.

The deployments include several in the US (both East and West Coast), Switzerland, Germany, Mexico and the Ukraine.

One of the factors here is the strong uptake of SOA in the Banking and Finance sector and the unique position WSO2 has as a leading Open Source SOA Platform provider. Another key factor is the fact we are pretty much the only ESB that comes with out-of-the-box support for FIX (with no additional cost either). But I also like to think that one of the success factors is simply success: we are very good at helping our customers succeed in their endeavors.

If you want further information, we published a nice case study this week.  Or come along to to and one of our Account Managers will help kick off the discussion.

Paul Fremantle, WSO2 CTO
Paul’s blog:

Welcome to the WSO2 Solution Architecture Blog!

It is a privileged part of my job to work closely with companies of all sizes who are using the WSO2 platform as part of their overall Enterprise Architecture. I work with Reflected towersthe team of architects here at WSO2 who collaborate, guide and learn from our interactions with other architects from some of the best companies in the business.

One of the things that we’ve really learnt is that architects love to have a set of modular components available to hand. And we are constantly learning from engagements and customers how the building blocks from Carbon and Stratos can be used to create amazing solutions. Whether its small startups, midsized companies or Fortune 500 enterprises, architects are finding value in lean open source middleware.

Solution architecture issues range widely:

  • Should I build a shared-nothing model?
  • Do I need to separate my data services layer from my integration layer?
  • What is the value of policy-based entitlement?
  • What cloud architectures are being adopted for large scale high-volume systems?

Solution Architecture is one of the areas where our customers are most keen to get best practice. Hence welcome to this new blog. We aim to ask – and answer – these sort of questions and more.  And we look forward to your contributions: whether its a comment, a trackback, a link to your thoughts or even a guest blog.

Paul Fremantle, WSO2 CTO
Paul’s blog:

New: WSO2 Named a Leader in New ESB Analyst Report

In the latest Forrester Wave on ESBs, they declared that WSO2 was a “Leader” and scored WSO2 a 4.47 out of a possible 5.0 for “Current Offering.”

This follows two recent Gartner SOA Magic Quadrants that listed WSO2 as a Visionary. Whether or not you follow Gartner, Forrester, or more specialized analysts such as Redmonk imageor the 451 Group, this is a great sign for WSO2 – we are gaining not just customer traction but also visibility from the wider industry. I often think that we are one of the IT world’s best kept secrets: a 120 person company that competes head on with Oracle, IBM and Tibco in the middleware space; that is used by one of the world’s biggest e-tailers to do more than 800m transactions a day; that has a complete multi-tenant, elastic Platform-as-a-Service; and that does this all completely as a Modular, Open Source, and Lean codebase.

Focusing just on the ESB I recently heard from a customer that they have run their WSO2 ESB cluster with zero downtime for more than 2 years. What does that mean? They run a cluster for continuous availability: even during updates the cluster remains up and active – using a graceful restart model they can push configuration updates through the system without affecting any clients or losing any messages. So despite multiple updates and even hardware changes the cluster has been live continuously for more than two years with not a single second of downtime.

Our ESB is strongly based on Apache Synapse, and generally analysts do not evaluate Apache projects, because their clients are looking for a complete supported commercial solution. That is ok, but I think that Apache Synapse deserves a strong mention at this point. I submitted the proposal for Apache Synapse to Apache in August 2005. Some of the initial discussion around Synapse avoided the use of the word ESB – but the reality of the development from the very first line of code is that we were (and are) building an ESB. WSO2 has had a strong commitment to Synapse from day one, but there are other excellent contributors and I want to thank the whole Apache Synapse team – in my mind this rating by Forrester is not just a rating for WSO2 but for the underlying Apache Synapse ESB as well.

Here is hoping that this wider exposure helps turn WSO2 from the best kept secret to the best known alternative to bloated, costly and proprietary platforms!

Paul Fremantle, WSO2 CTO
Paul’s blog: