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 Languagedoes 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: http://pzf.fremantle.org/

Good Things Come in Threes

In keeping with our Solutions Architecture focus, we’ve just released three new whitepapers describing reproducibly successful patterns we’ve seen (and helped) our customers achieve.  Complete with architectural diagrams and requirements, I’m sure readers of this blog will find these solutions interesting, and applicable to specific challenges they may be facing.


WSO2 Mobile Gateway Solution: Extend the Boundary of Your Enterprise Through Innovative Mobile Experiences


WSO2 FIX Gateway Solution:Interoperable Connections for the Financial Industry


WSO2 SAP Message Gateway Solution: Cost-Effective SAP NetWeaver Replacement

Naturally, each of these solutions makes effective use of the WSO2 Enterprise Service Bus.  Enjoy!

Jonathan Marsh, VP Business Development and Marketing
Jonathan’s blog: http://jonathanmarsh.net/blog

Defining a Generic API

With a premium placed on loose coupling, a typical SOA deployment displays a high degree of heterogeneity. Different service platforms run in scattered datacenters on a variety of server hardware, operating systems, and development platforms. The services expose different communication and security standards. Individual SOA implementation and maintenance teams will become acclimated to the level of heterogeneity with exposure to the environment, but when an external or internal consumer tries to access the SOA, they will come face to face with this complexity.

image

A common way to simplify and normalize interactions with a heterogeneous environment is to provide a unified API for service consumers — a unified, generic service layer.

One of our commercial bank customers with multiple service platforms began a project of defining a unified services layer, generalizing the the multiple service platforms active in the bank. At first they approached the problem in the traditional way: writing wrapper/proxy services in front of each of the existing services.  As part of an engagement with WSO2 they changed to a “Generic API” solution pattern which dramatically simplified the project by hiding the internal complexity of each service behind a user friendly API, a common URL for service access, and unified security policies.

The “Generic API” pattern installs a common API for the existing service infrastructure, converts traditional applications to services exposed over a normalized set of communication and security protocols, and provides a foundation supporting the easy addition of future service platforms.

image

When implemented with WSO2 products, the Generic API pattern leverages the WSO2 Enterprise Service Bus (ESB) and WSO2 Governance Registry. The WSO2 ESB connects with the back-end service layers and legacy applications, and exposes them through a new service layer.  This is easily accomplished with the proxy service capability of the WSO2 ESB.  Supporting a wide variety of of the transports and message formats, the WSO2 ESB provides a central hub for protocol switching and security mediation between the heterogeneous systems.

With sophisticated transformation capabilities, the WSO2 ESB extends the Generic API pattern to the problem of unifying data models, by converting or mapping messages representing different data models into a common and easily consumed model.

Storing and publishing common metadata such as service descriptions and policies describing the generic API also aids new developers interacting with the system.  In the deployment above, the WSO2 Governance Registry provides a common repository for storing and sharing all the necessary SOA artifacts.

The Generic API pattern provides the foundation for other other solution patterns as well.  In future posts we’ll discuss solution architectures for a Public Services Gateway and an Internal Services Gateway pattern.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/

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 http://wso2.com/contact/ and one of our Account Managers will help kick off the discussion.

Paul Fremantle, WSO2 CTO
Paul’s blog: http://pzf.fremantle.org/

Let’s talk Solutions Architecture

Today WSO2 launches a new Solutions Architecture Blog for Enterprise Architects.  As Paul explains in the inaugural post:

Solution Architecture is one of the areas where our customers are most keen to get best practice.

The new blog will share and provide an opportunity to discuss best practices, patterns, and real-world solutions to enterprise architecture challenges.  It promises to become a valuable resource for Enterprise Architects.

Subscribe and join the conversation here!

Jonathan Marsh, VP Business Development and Marketing
Jonathan’s blog: http://jonathanmarsh.net/blog

Adding the dynamism of events to a Master Data Management solution

The WSO2 platform provides all the capabilities to address two common architecture patterns — Master Data Management (MDM) and Event Driven Architecture (EDA).

The integration of these two powerful ideas allowed a System Integrator (and WSO2 customer) to refactor and modernize their architecture in their latest release, and roll that out smoothly to their customers.  The new architecture centered around the MDM and EDA patterns.  Built-in facilities enabling MDM and EDA patterns played a factor in choosing the WSO2 SOA-based Middleware Platform.

The existing application software includes a number of RDBMS data repositories, exposed through application-level APIs from various systems. Requirements for the new architecture included the reuse of the existing data as well as support for updates to the existing data stores from messages originating in the new architecture. Even though existing data was reused, the existing data model was not proving a good fit with the new architecture. Therefore converting the data to a new data model also became a key requirement. The MDM pattern fulfilled these two requirements by connecting to the data repositories and converting the data into a universal data model.

The WSO2 platform sports a number of features useful for implementing MDM.  The OxygenTank article Implementing MDM Patterns on WSO2 SOA Platform describes a pattern called Service Adapters that applied neatly to this situation, leveraging the legacy APIs for data access.  The adapters were coded in Java and deployed in the WSO2 Application Server.  WS-Transfer facilitated transformation of the data models and exposed the new universal data model through XML Web Services.

image

The message exchange pattern (MEP) used to integrate the application components was pub-sub (publish and subscribe), bringing EDA into the picture. Pub-Sub extends the loose coupling of a SOA, allowing new data sources to be integrated by a simple publish/subscribe operation.  The WSO2 Enterprise Service Bus’s native support for the WS-Eventing standard allows it to act as an event broker, while extending mediation capabilities to any pub-sub interaction as well as providing all the QoS controls available within the ESB.

By introducing a controller into the architecture, more sophisticated event flows are possible, controlled by business processes and rules. In this architecture, the controller was implemented by using WSO2 Application Server and WSO2 Business Process Server, and combined standard JAX-WS based services and rules defined in BPEL.

Dynamic discovery emerged as a key requirement to avoid tightly coupling of service endpoints.  The combination of WS-Discovery support and a compatible service deployer, endpoint availability is published as each service is deployed.

Integration of a Registry/Repository was identified as a key requirement to store service and configuration metadata as well as to enable dynamic metadata look-up. These facilities are provided by the WSO2 Governance Registry, which in addition to a metadata store hosts the topic store for topic-based event subscriptions.

image

The logical architecture solution above maps to a variety of deployment patterns for different clients of the system integrator, meeting their individual demands for scalability, high availability, infrastructure constraints, and so forth.

The application of aspects of Event Driven Architecture to the problem of Master Data Management adds flexibility and increases the advantages of loose coupling so prized in modern SOA solutions.  We hope the pattern described above gives you some ideas of how your current integration challenges can be approached.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/

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: http://pzf.fremantle.org/

Open Conversations on the New Business of Enterprise Software

WSO2