Tag Archives: WSO2 Governance Registry

WSO2Con Insights – AlmavivA Adopts Lean Approach to Public Administration with WSO2

The Italian Ministry of Economy was looking for a complete transformation in data management by redefining and organizing its own data, so that information of millions of employees of the Italian Public Administration would be unique and certified.

The proposed system spelt the integration of two main IT systems in the Ministry; one that handles personal data, and a second that handles economic data, so that the system would have one single point of management, and serve applications regarding salaries and personal data as a self-service for the Italian public sector employees.

The Ministry approached AlmavivA Group, Italy’s number one Information and Communication Technology provider, for a solution. Guiseppe Bertone, Solution Architect at AlmavivA S.p.A. said during his session at WSO2Con 2014 EU, in Barcelona, Spain that AlmavivA designed and proposed an ad hoc master data management (MDM) solution for the Ministry, based on WSO2 products to manage the data of 2.6 million employees.

Picking the Best Product Solution

He said that there was a set criteria that AlmavivA and their client listed out prior to choosing the right products and platform for the project. Some of the critical features were interoperability with existing IT components, high modularity, optimized for performance, and most importantly, open source. Comparing pre-built product solutions available in the market, Bertone and his team made a decision to use WSO2 products for the entire solution.

“WSO2 products fit the requirement. You can enable only the components that you need, and leave the rest of it out, unlike in pre-built solutions,” he said.  almaviv1

He added that there were many redundant repositories within the Ministry IT systems; datasets needed to be optimized and integrated with external systems, and a migration workflow for the existing data had to be defined.

The reference architecture for the MDM solution included interface, events, security, and data quality components, as well as the repository layer, which consists of four databases; master data, meta data, historical data and reference data.  

The AlmavivA project ‘Anagrafca Unica’, roughly translating to ‘Unique Repository’, was initiated in March 2012.

The WSO2 Advantage

The mapped reference architecture was a total solution platform based on a set of WSO2 products;   almaviv2

WSO2 Enterprise Service Bus (ESB) for interface services, the WSO2 Data Services Server (DSS) to access the repository layer and manage all life cycle services, WSO2 Identity Server (IS) as the security and identity component, WSO2 Message Broker (MB) for communication between applications, WSO2 Governance Registry (G-REG) to store configurations of all components, and the WSO2 Business Activity Monitor (BAM) to monitor services across the entire MDM solution. OracleDB is used as the repository layer.

With BAM being easily integrated to other WSO2 products, AlmavivA simply had to install only a specific BAM load inside each component, so that the statistics and real-time performance could be monitored. An additional console was added as an UI for the system’s custom procedures.

Another advantage of using WSO2 products was brought to light during the development stage; “Many aspects of WSO2 products can be simply configured from the web UI, or the developer studio for all WSO2 components. It’s really useful and easy to use,” explained Bertone.

In a covalent situation such as this, WSO2 deploys Carbon Apps. By creating a carbon app, a single file consisting of all components is created, so that once the file is deployed, the server knows which components to take, according to Bertone. “This is useful because once you have a system like this you can integrate it with an application cycle management solution already present in the customer environment, like we did,” he says. “We have now created a console where with a single click, the customer can pass from staging to production.”

AlmavivA is looking to expand Anagrafica Unica across the country to include all employees of the Italian Public Administration sector in the system, bringing the total user count to 3.5 million. Bertone and his team are also looking to serve data to external systems, such as the Ministry of Health, with more government institutions being added along the way.

For more information on AlmavivA’s development of the Master Data Management System, view the recording of Bertone’s WSO2Con EU presentation.

giuseppe-bertone-hover

API Registry and Service Registry

[Based on a post originally appearing at http://asanka.abeysinghe.org/2014/07/api-registry-and-service-registry.html.]

Registry acts as a core component in Service Oriented Architecture (SOA). Early SOA reference architecture named the registry as a service broker for service providers to publish service definitions, allowing service consumers to look up and directly consume the services.

Figure-1 SOA triangle

With the evolution of SOA, Registry started to provide more value, such as lifecycle management, discovery, dependency management, and impact analysis. The Registry became the main management, control and governance point in such architecture. It also became a vital component within the SOA Governance layer of the overall architecture. As a product, the Registry started providing three distinct functionalities – repository, registry and governance framework.

Repository functions to store content such as service artifacts, configuration and policies, the Registry to advertise them for the consumers to access, governance to build management control and policy based access over the stored artifacts and to connect people, policies and data.

image

Figure-2 SOA 2.0

Changing Role of Registry

With changes and challenges taking place in businesses as well as the technical architecture of the enterprise, the role of the registry has changed. Even while the technical definition of a service is based a standard (e.g. WSDL, WADL), the business definition of a service can vary from organization to organization. Therefore, a customizable definition for a registry artifact became a requirement. For example WSO2 Governance Registry contains RXT (Registry ExTensions) to define services. RXT provides a customizable service definition as well as sets the behavior of an artifact when an artifact is imported and operated in the governance runtime.

When it comes to governance, registry became the core design-time governance controller in the enterprise. Features such as Discovery and UDDi compatibility became more nice to have features than the practical usage of them. Having said that, runtime wiring based on environment metadata has emerged as a practical replacement for discovery.

In the modern architecture, Services implement business functionalities of an organization, APIs are interfaces for services that allow consumers to consume business capabilities.

During the last decade Services were developed using various service development standards, programming languages and frameworks. Services were designed and developed – and funded – in silos in each business/organization unit. This led to duplicate services in the same organization which violates the core SOA concept of reusable shared services. Services are more technically driven, designed and implemented by enterprise developers. If we look at a service catalog, more than 80% of the services perform some kind of a CRUD (Create/Read/Update/Delete) operation. Data Services is another common industry term used to describe the CRUD services. The remaining services implement business logic with the help of business rules and CRUD services. A small remaining portion of utility services exist to provide functionalities such as computations and validations.

Figure-3 service types

The technically driven nature of the services lead to unhappy consumers. As a result, new service implementations were introduced to the market by duplicating as well as avoiding reusability. Some enterprises started implementing wrapper services in front of the actual services and added an additional burden of maintaining a new service layer.

Emerence of APIs

Complex, rapidly changing business requirements for consumer apps have changed the expectations of the services. Consumers increasingly look at APIs to be:

  • RESTful
  • JSON based
  • Secured with OAuth
  • Follow WEB API design

Unfortunately most of the existing services are not compliant with these expectations leaving a huge gap between the implementation and demand. In a consumer driven market, APIs that do not meet the demand will not have value and will not survive for long. To meet the demand, technical teams started to write wrapper services in front of the actual services. But this created a huge maintenance issue as well as slowing down the time to go-to-market.

Using APIs as the service interfaces for consumers to invoke service functionality, resolves the issues we identified above, mainly converting technical driven services into business friendly APIs as well as implementing the common reusable services for the enterprise and meet the demand/expectation of the service consumers. There is much more value proposition from APIs to the enterprise. Lets now look at them in-detail.

Figure-4 service and APIs

A pure API layer might be not enough to cater the demand. A mediation layer might be required based on the gap between the services and API. As I explained earlier APIs are light-weight interfaces that do not represent any implementations. Traditional Facade patterns came to the API architecture as API Facades, providing a solution to this problem. Introducing a mediation layer with the API Facade will take care of protocol switching (transports/message formats) as well as security bridging. In addition, it helps to convert the traditional backend services into modern web-api designs by using techniques such as service chaining (light-weight orchestration). More information can be found in this blog. Having said that, API-ready backend services can be directly exposed through the API management layer as an API without going through any additional mediation layer.

There are two main usages of APIs, internal and external. External APIs create an eco system for a business to expose their functionality to their customers and partners in a consumer friendly, secured and governed manner. Internal APIs again help to resolve the broken SOA pattern and provide reusable common functionalities across business units. This allows business units to promote and “sell” their services across the enterprise and maintain and manage by the business unit itself.

Design-time Implications on the Registry

I hope the information provided above is insightful and has helped you identify the usage of the registry and a clear differentiation between services and APIs. Lets now look at the key discussion points of the service registry/API registry. Looking at a reference architecture will be more helpful to identify the concept.

Figure-5 service and API registry reference architecture

Service definitions will be defined in the service registry, the service registry will maintain the additional metadata about the services and catalog detailed technical definition of the services. Usually service definitions is defined automatically when services are deployed to the service containers, but in some enterprises this happen as a manual process by importing the service definition from various catalogues or service containers. Once the services are defined the registry will create the dependencies, associations and versions of these services and metadata.

We spoke about having a mediation layer to bring non-API ready services into API ready, proxy services defined in the mediation layer. This will also go as service definition in the service registry.

While technical definitions of the services and proxy services are defined in the service registry, consumers of the APIs require a place to lookup the services. This is where the API registry will come in to the picture as the consumer facing API catalogue.

Target audience of the APIs are application developers, hence an API registry requires and supports publishers to cater to their expectations such as social features and the ability to subscribe and get an access token.

From an API governance point of view, API publishers should be able to secure the APIs by providing access control to the APIs and resources inside the APIs. Some APIs might require additional control with entitlement and workflow support to get approval for subscriptions before providing an access token.

Runtime Implications

We already discussed the functional requirements of the two registries, lets now look at the runtime view. Deployment will depend on the nature of the APIs. There are three categories.

  • Internal only APIs
  • External only APIs
  • Internal and external APIs

To facilitate the first category deployment can combine the service registry and API registry to run in the secured network (LAN). But this will provide two different views for the API consumer and the Service developer. External only APIs require the API Registry to expose externally (in DMZ) and service registry to run in the secured network. Internal and external APIs require an external (public) API registry as well as an internal (private) API registry. The internal API registry can combined with the service registry.

Figure-6 deployment patterns

Conclusion

I hope the information described above helps you identify the difference between services and APIs as well as the benefits of separately architecting a service registry and a API registry. Having two registries helps fulfill the requirements of the API consumer as well as service developers, in addition, this allows you to decouple services and APIs by having an individual life cycle and versions for each of them.

Asanka Abeysinghe
Vice President of Solutions Architecture
Blog: http://asanka.abeysinghe.org

WSO2 product’s; summer release round-up

Couple of weeks ago, CTO Paul Fremantle and Tech Evangelist Chris Haddad, conducted a webinar on the innovative advancements of the WSO2 Carbon middleware and WSO2 Stratos cloud platforms. Here are some highlights from their presentation

  • WSO2 Carbon core 4.0 released with many improvement and new features
    • Enhanced Deployment Synchronizer
    • Deployment performance improvements
    • Managements and worker node separation
    • JDK 1.7 support
    • Better integration with Tomcat 7
    • Upgrading Equinox SDK (OSGI Runtime) to v3.7
    • P2 Repository: Features grouped by product
    • Multi Tenancy in Carbon
“The Carbon platform is your reconfigurable modular middleware. Recently we’ve seen lots more customers actually wanting to de-couple different parts of a product to vertically scale while at the same time horizontally scaling. This capability is proving to be a major benefit of the Carbon platform.”
– Paul Fremantle  
“We are rapidly evolving all of our products simultaneously on top of single cohesive code base. This is unparalleled in the industry to have such coordinated releases on a single platform.”
– Chris Haddad
  • WSO2 Stratos 2.0 Platform as a Service will include
    • Support for multiple languages and runtimes
    • Support for more IaaS providers (vmWare, EC2, OpenStack, CloudStack, Rackspace etc.) via Jcloud
    • Enhanced manageability
“We are embracing a heterogeneous environment were you can run PHP in the cloud environment and take advantage of the rich set of PaaS foundation services that Stratos offers. Also you can plug-in any application server or asynchronous  server and cloud-ify  the application environment by having an mechanism that ties back into the pass foundation and Startos controller services.”
– Chris Haddad
“The key differentiator for Startos is its inherent multi-tenancy. There are other PaaS offering that have the polyglot language support but what they don’t have is the concept and modeling of multi-tenancy. That plus the richness of the set of Stratos services that the cartridges have available to you make us really stand out.”
– Paul Fremantle

You can watch the full recording of the webinar here: http://wso2.org/library/webinars/2012/09/wso2-carbon-wso2-stratos-summer-release-roundup

 – Hasmin AbdulCader, Director, Communications

Hot summer releases to watch out for!

From an all new API Manager and a software development lifecycle management product (WSO2 AppFactory), to supporting new cloud technologies, totally new versions of WSO2 BAM and WSO2 Message Broker, you won’t want to miss what’s coming up this summer at WSO2.

As the team constantly looks at ways to stay ahead of the game, they’ve also made significant enhancements to the WSO2 Carbon framework and products such as the ESB, Governance Registry, Application Server, and Stratos.

We managed to get a hold of CTO, Paul Fremantle, to give you an overview of what’s in store on this technical update video:

Hasmin AbdulCader, Director, Communications
http://www.twitter.com/hasmina

After Sonic ESB pioneered, WSO2 ESB continuously innovated

After Sonic ESB pioneered the Enterprise Service Bus market and created technology to more readily integrate applications using Enterprise Integration Patterns, WSO2 continually added innovations to the core ESB pattern and created the highest performance, lowest footprint, fully interoperable and flexible ESB, WSO2 ESB.

Progress Software recently lowered their sights on supporting enterprise integration developers, and Progress is has publicly announced intent to sell Progress Sonic ESB, Actional services management, and FuseSource. Progress’ recent strategy shift places Sonic ESB, Sonic MQ, Actional, and FuseSource customers at risk of further obsolescence.

Where did Progress’ corporate strategy fail? By growing through ad-hoc acquisition and superficial integration instead of organic platform development. Progress played a failing game espoused by IBM, Oracle, and Software AG. Progress acquired competitive threats and then invested the minimal amount required to create a ‘SOA Suite’. As often the case, the strategy led to multiple overlapping products, competing business units, lost internal talent,
and a disjointed customer experience.

At WSO2, we have consistently taken a different approach. Our complete, composable, and cohesive platform was built through organic development, which continually enhances our core platform, incorporates market-leading innovations, and delivers a seamless customer experience. Our WSO2 Enterprise Platform enables complete data to screen enterprise integration, SOA, BPM, API management, web application development, and Cloud.

Our WSO2 ESB, WSO2 Governance Registry, WSO2 Business Activity Monitor, and WSO2 Identity Server provide a production proven, high performance SOA middleware foundation. We welcome you review our case studies and learn how WSO2 ESB processes more than 1 billion transactions per day for eBay, streamlines the development and maintenance of smart power grids, supports T24 core banking systems, and enables consolidated reporting across
enterprise applications.

Our Offer to Progress Sonic ESB and Progress FuseSource Customers

WSO2 desires to assist Progress Sonic ESB and Progress FuseSource customers choose a viable, stable, and supported middleware platform. We are offering free Evaluation Support to current Progress Sonic ESB and Progress FuseSource customers, and would be pleased to demonstrate how our market leading WSO2 Enterprise Service Bus and WSO2 SOA Platform meets your evaluation criteria. Feel free to contact us via our Progress customer offer landing page, our contact form or send us an email note.

Chris Haddad, VP Technology Evangelism Chris’s blog: http://blog.cobia.net/cobiacomm/

Gartner’s and Cobiacomm’s analysis of WSO2 SOA Governance

image[First published at http://blog.cobia.net/cobiacomm/2011/10/25/wso2-soa-governance/]

WSO2, the lean enterprise middleware provider, announced that it has been positioned by Gartner, Inc. in the “Visionaries” quadrant of a new report, Magic Quadrant for SOA Governance Technologies [1].

My analysis (from an ex-Gartner research team leader), the placement demonstrates WSO2 team leadership in defining a vision for policy based service governance. When publishing a service API for consumption, tracking published cloud-based service versions, monitoring service consumer connections, and delivering service-consumer interoperability, governance keeps the environment from devolving into chaos. Cloud based services, mobile devices, and multi-enterprise B2B interactions increase the environments where SOA governance technology must be applied. WSO2?s multi-tenant SOA governance infrastructure facilitates configuring models and policies associated with each participant’s business requirements. Many vendors have not yet modified their registries, repositories, and policy management systems to support multi-tenancy. As a result, organizations using single-tenant SOA governance tools are challenged to apply policies across diverse partners, customers, consumers, and internal corporate groups.

The WSO2 Carbon Governance and WSO2 Stratos Governance as a Service supports configuring a wide variety of design-time, development-time, and run-time policies. Built-in run-time policies include security access controls, authorization (via XACML), throttling, alerting, and caching, each of which accesses defined parts of the service message. The governance stack is also used to enforce software development policies when promoting applications and services across lifecycle stages (e.g. development to quality assurance, quality assurance to production). Granular cloud metering and billing is facilitated by collecting performance, faults, and business activity information in conjunction with the WSO2 Stratos Business Activity Management Service. WSO2 has posted good drill-down presentation describing how to use the governance registry.

The WSO2 Governance Registry not only interoperates and integrates with the WSO2 Carbon and WSO2 Stratos stack, but also with Cloud services hosted on other vendor stacks. Integration can occur at the network protocol level (i.e. HTTP, SOAP, FTP, AMQP, WebSphere MQ, POP3/SMTP, FIX, HL7, SAP iDoc/BAPI, and vendor-specific JMS variants), across multiple message formats (i.e. SOAP, XML, JSON, CSV, EDI, FIX, HL7, and REST), and multiple security and identity protocols (i.e. LDAP, SAML2, Kerberos, OpenID, OAuth, and XACMLA).

For more information, visit the WSO2 Governance Registry product page. To try out WSO2 Governance Registry as a Service for free, visit the StratosLive registration page.

[1] Gartner, “Magic Quadrant for SOA Governance Technologies,” by Paolo Malinverno and Daryl C. Plummer, October 17, 2011.

Chris Haddad, Vice President of Technical Evangelism
Chris’ blog: http://blog.cobia.net/cobiacomm

Loosen Up with WS-Discovery

At the foundation of Service Oriented Architecture (SOA) lies the concept of loose coupling. Modeling a complex system as a web of interacting services each of which are independent in their implementation, hardware, environment, physical location, and qualities of service, provides many advantages for internet-scale application development. Such as: the ability for parts of the system to scale independently. The ability of each service to be implemented and operated in the best environment, based on it’s own criteria analysis be it weighted towards leveraging established legacy to adopting the latest trend or even outsourcing to the best service provider. The ability to evolve and change internally without adverse affect on the system.

In a good SOA design, a Web service is typically coupled to others over a very small surface — the actual message formats (typically a neutral standards such as XML, SOAP, WS-*), the communication protocol (such as HTTP), and the network address. The items comprising the minimal coupling details constitute the “service contract” — everything a consumer needs to know to interact successfully with the service. The service contract details are often captured in a WSDL description.

One of the key unavoidable items of coupling is the endpoint address to which the service responds. This information is often part of the WSDL — but hard wiring addresses also fixes a service to a particular address and thus limits its options for movement to a new location. If for instance a service moves from one server to another (perhaps in another data center) even though the service itself hasn’t changed all the clients have to be updated with the new address.

A common pattern for addressing the mobility of services is with proxy services, a simple-to-configure feature of the WSO2 ESB. Basically, instead of communicating directly with a service, one can route requests through a stable endpoint provided and maintained by the ESB. If a service moves to a new address, only the ESB needs to be reconfigured — all the clients send their requests to the ESB itself.

Discovery mechanisms make this even easier, allowing the ESB to automatically reconfigure itself when a service moves or comes online. Discovery mechanisms also typically can help choose among several appropriate services to send the message to.

WS-Discovery is a standard for many SOA-based systems to look-up endpoints dynamically. The standard uses multi-casting and UDP to find and notify endpoints within a local network. More information about WS-Discovery can be found in the 2004-05 specification.

Scenarios where automated discovery is valuable include: a datacenter where a cluster of well-known production services are undergoing regular creation and destruction (for elasticity or other operational reasons), a local subnet which includes mobile resources (leaving and joining the subnet frequently), or a cloud where the creation and destruction of services is automated by the cloud management system.

WS-Discovery has a well-defined scope and thus doesn’t address all the desirable scenarios of automated discovery of services. It’s designed to locate services in a local network, not across the global network. It has some ability to match services based on properties, but one must be careful that services are stable and well-defined. If for instance WS-Discovery is used to dispatch messages to a set of services, and a new service comes on board that has a different API version, is a development version, or other discrepancy, it must be clearly marked as different from the other services to prevent clients from using it in the same service pool as the production services.

ws-discovery-default

The WSO2 Platform supports WS-Discovery using the following model. The WSO2 Governance Registry includes a WS-Discovery proxy which periodically both broadcasts to and listens for services that have joined the local network. Once found, they endpoint information is collected in the registry so routing systems (such as the WSO2 ESB) can use this endpoint to route messages. Services deployed using WSO2 Carbon products such as the WSO2 Application Server respond to the WS-Discovery messages to advertise their availability. Other services such as Microsoft Windows Communication Foundation also support the WS-Discovery standard and participate in the system.

Thanks to Asanka and his Smart Endpoint Registry post for planting the seed for this post, and his review and creation of the nice diagram!

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

Smart Endpoint Registry finds the best service for a particular client

Architects at WSO2 recently built a Smart Endpoint Registry solution for a large electronic media distributor. The driving force was the efficient routing of requests to the service best suited for that particular request.  To provide the lowest latency the request should be routed to the closest geographical data center.  Based on the processing requirements a particular message might be routed to a specialized service.  Or requests from premium customers can be routed to higher-capability servers.  In addition, services also move regularly between data centers for operational reasons.  The solution developed routes requests based on logic matching the message to a list of registered services using metadata such as the type of service requested, the geographical location of the service, the business group the service belongs to, the API version, and so forth.

In this solution, the service definitions and endpoint addresses are stored as resources in a centralized WSO2 Governance Registry. Properties can be associated with each service resource to indicate the geography etc.  Routing logic examines these property values to determine the address of the optimum endpoint.

The WSO2 ESB does the actual message routing, picking up message headers (such as the source IP) and comparing it with information in the registry to locate the most appropriate service and determine it’s endpoint address. With endpoint lookup complete, the message can be successfully routed to the optimum service for processing.

As services come online, each service registers itself with the WSO2 Governance Registry by writing it’s details directly to the registry during it’s initialization (in WSO2 Application Server, the “init” method).  When they go offline (the “destruct” method) they remove their entries from the Registry. There are two available APIs that can be used to create the appropriate entries and to register the service metadata as properties – a Web services API or the RESTful ATOM-based API. Setting properties is an easy and flexible way to associate structured metadata with a resource as name-value pairs.

A housekeeping task periodically checks that registered services remain online and removes service entries for those that may have gone down without proper destruction.

Composite services (in this case BPEL-based services executed in the WSO2 Business Process Server) can also route their dependent services through the ESB to find the most appropriate match – or they can look up service endpoints directly from the Governance Registry in cases where the full matching logic isn’t necessary.

ws-discovery-extended
The Smart Endpoint Registry scenario has similarities with other discovery mechanisms such as WS-Discovery. In both the Smart Endpoint Registry pattern and in WS-Discovery, services coming online are automatically made available to the system. But beyond the surface similarities lie significant differences. This scenario goes beyond WS-Discovery with more sophisticated property matching and searching logic to match services and clients. WS-Discovery also is appropriate for a subnet that supports multi-cast IP, providing standard “hello” and “goodbye” messages to register. But in this case the data centers are widely dispersed and a multi-cast-based discovery mechanism can’t span the network range, and so a customized init/destruct process had to be used.

The WSO2 Carbon platform is an excellent platform for implementing this pattern. The ease and flexibility of adding look-up logic in the ESB using logic control and look-up mediators, the convenient APIs for writing to the Governance Registry and structured properties on each resource, and support for init/destruct in the WSO2 Application Server all combine to offer a straightforward implementation of the solution.

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

WSO2 Platform for API Management

One of the niceties of mainframes was the simplicity of a single API for the users.  After years of evolution towards a decentralized model we still find this pattern appearing, even among SOA implementations that span many subsystems and service platforms.

I discussed the need for unified APIs in my previous blog posts [1],[2], and explained how you can build using the WSO2 middleware platform.

Presenting entire subsystems, which may include legacy systems, databases, and internal and external services as a single unified API makes integration easier for a partner (further decoupling detailed knowledge of the subsystems), and is increasingly used for internal users such as business processes, business rules and mashups. A unified API hides a variety of transports and systems behind a single, consistent, API.

With the introduction of unified API, API management and monitoring becomes an important factor.  Different formats and protocols like SOAP/HTTP, JSON, XML/HTTP, JMS can be exposed across the range of services. A centralized configuration change at the ESB layer enables different protocols or enables QoS features across the API.  Features such as usability, the security, governance can be managed in a single location, as can enterprise features like scalability and high-availability.  Monitoring provides a single point for assessing the usage and health of the system.

api-management

As I described in my previous posts, the WSO2 Enterprise Service Bus (ESB) provides the a simple yet powerful and highly performant system upon which to implement a unified API and select the various QoS characteristics. WSO2 ESB supports all the popular security standards required for integration and leverages WSO2 Carbon clustering features for scalability and high-availability out of the box.

The WSO2 Governance Registry builds the required governance framework for the unified API by providing a repository for policies and API metadata – even for API documentation – and adds the ability to share, version, analyze dependencies and policy conformance, and manage lifecycles of this metadata.  The WSO2 Governance Registry helps you define the and manage the QoS of your API, and works in conjunction with the ESB to assess and enforce the defined policies.

Monitoring – a key part of runtime governance – is accomplished by deploying the WSO2 Business Activity Monitor (BAM) to collect, summarize, and report on the API usage.  Or you can use the JMX support in the WSO2 ESB and other WSO2 Carbon products to tie into third-party monitoring tools.

api-management-wso2-products

Certain services need to go beyond simple monitoring. When we looked at the business requirements of our API management customers, billing and metering, isolated runtimes for specific consumers/consumer groups, as well as customization or overriding of the API for specific consumers emerged. We have found multi-tenancy to be a powerful answer for those requirements, and is available in the WSO2 cloud platform, WSO2 Stratos. With WSO2 Stratos you can easily expose your API in the cloud or as part of the SaaS offerings you provide.

In summary, both essential and extended features for API implementation and management are provided by WSO2 middleware platform, making it a great choice for meeting both your business and technical requirements.

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

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