Category Archives: Products

We Did It! WSO2 Identity Server is Now OpenID Certified

We thought turning 10 was a reason enough to celebrate, but we’re not done with the celebrations yet. Our Identity Server (IS) team has been working to keep that momentum going. We just became OpenID certified!

Being OpenID certified by the OpenID foundation is a big deal. What is OpenID? OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. “We’ve been compliant with OpenID standards for a long time,” says an ecstatic Prabath Siriwardena, WSO2’s Senior director of security architecture. “Getting the certification puts a stamp on it and gives the assurance users are looking for,” Prabath explains.

WSO2 Identity Server is the most extensible and fully open source IAM provider that can help connect and manage your identities. It’s a key enabler of digital transformation. Our single sign-on bridges protocols such as OpenID, has been a key component offering solutions to enterprises in education, telecommunication, and health among others.

By becoming OpenID certified, we’re joining a list of industry giants who also have this certification including Yahoo! Japan, University of Chicago, Verizon, Salesforce, Paypal, and Google. Now WSO2 Identity Server can provide the assurance to its users that it really conforms to the profiles of OpenID connect protocol.

Kudos to our IS team on this feat and looking forward to many more successes!

WSO2 Stream Processor: Making Real-time Stream Processing Available to the Masses

Today we are thrilled to announce the availability of the WSO2 Stream Processor, our lightweight, open source, high performance, stream processing platform which helps create real-time, intelligent, actionable insights for your digital business.

A significant competitive advantage for any modern businesses is the availability of business insights and information to make real-time decisions. The speed at which we collect, analyse, draw insights from an organization’s data and the time taken to respond to them, determines who ends up being the winners and losers.

The Rise of Real-time Stream Processing

Digital Transformation has seen many businesses opening up systems to others through APIs, supporting multiple ways of authenticating users and integrating multitude of systems together into a single digital platform. As the number of systems and usage goes up, it becomes impossible to keep the systems running and ensuring availability without real-time monitoring. Consumer centric digital businesses too customize experiences based on insights on buying patterns. With increased usage, fraudulent patterns, and security threats need to be monitored and acted upon.

Most systems generate such streams of events that can be transformed into valuable business insights. These events need to be collected, filtered, grouped and pattern matched in the process of transformation. Real-time stream processing technologies enable this transformation of simple event data into useful business insights. It plays the important role of a catalyst for digital transformation of modern businesses.

Adoption Challenges

There are however many challenges that enterprises face when adopting capabilities to quickly capture, analyze and process data, and act in real time.

With first generation stream processing products you had to write code and implement complex operators such as time windows, aggregations and patterns with minimum tooling support. Developing such code as well as adapting it to changing requirements is both complex and expensive. Moreover, they are inherently complex in their deployments, consisting of 5 – 6 nodes even for the simplest use cases. Such large deployments are difficult to manage and they incur high maintenance costs.

The use of streaming analytics is therefore a challenge for most businesses without the highly technical skillset and the cost involved.

The next generation of streaming analytics products solved some of these problems. Most of them support a more business user friendly SQL like language. Deployments though, still continue to be 5 – 6 nodes depending on the levels of throughput required. This makes it challenging for mainstream enterprises to adopt real-time streaming processing.

Taking Real-time Stream Processing to the Masses

WSO2 Stream Processor (WSO2 SP) is packed with features that enable any enterprise to build streaming analytics capabilities and derive meaningful insights out of the organization’s data. It is powered by Siddhi, the leading open source stream processing project that has been used by the likes of Uber, Transport for London (TFL), and Experian. The streaming SQL capabilities and in-built editor have event simulation and debugging support that can help you create real-time streaming applications faster than first generation products.

The high performance and low footprint also leads to more agile deployment: it is the only competing product that can handle 100K events per second in a high-availability deployment with just two commodity servers. This 2 node setup with minimum high availability achieves enough throughput for most of your stream processing needs. We’re talking over 8 billion messages per day!

In addition WSO2 Stream Processor includes new features that makes complex aggregations much simpler to write. The new rule management console, together with React-based dashboards, make rule management and real-time visualisation accessible to any organisation that wants to harness real-time analytics to gain competitive advantage.

WSO2 Stream Processor Reference Architecture

Here’s a snapshot of some other key features of WSO2 Stream Processor:

  • Supports massive scale when deployed in conjunction with Apache Kafka
    • Demonstrated in production at 30 billion messages per day
  • Updated Siddhi Streaming SQL 4.0 language adds incremental processing support for more efficient analytics
  • Simplified time based aggregations – write a single Siddhi statement that aggregates at multiple time intervals
  • Predictive Analytics through traditional and streaming Machine Learning
  • In-built IDE, event simulator and templates for developers
  • Monitor your deployment through a status dashboard
  • Deploy business rules through a graphical UI
  • Multiple data center support
  • Leverage Edge Analytics through small footprint deployment options

Visit our product page to try out the new release yourself, and let us know if you have any feedback.

Ask an Expert: Catching up with IAM Guru, Prabath Siriwardena

Prabath Siriwardena, WSO2’s senior director of security architecture, has a lot to be proud of. He’s an accomplished author, speaks at conferences such as Qcon, ApacheCon, WSO2Con, EIC, IDentity Next, OSCON and OSDC, and has over a decade of experience working with Fortune 100 companies.

We caught up with Prabath recently to get his take on the significance of GDPR, the future of open source IAM solutions, his personal journey at WSO2, and why he believes the world always needs fresh ideas.

1. What has your journey at WSO2 been like, Prabath?

I completed 10 years at WSO2 last year, having joined on the 1st of November 2007. It’s been a great journey with an awesome set of people around me – both the colleagues at work and the customers.

The joy of working at WSO2 is that you always get an opportunity to help someone solve a challenging problem.”

I’ve learned a lot from both these groups. The joy of working at WSO2 is that you always get an opportunity to help someone solve a challenging problem. It can be as simple as building a federated login scenario with a SaaS vendor to more complicated use cases like building an identity architecture to accommodate millions of users. Overall it’s a very satisfying, rewarding journey – looking back, I’ve enjoyed every second of it.

2. What’s the most recent problem you’ve helped solve?

I get the opportunity to talk to and work with many WSO2 customers, each problem is quite interesting. Engaging with customers allows me to understand their pain points. Once you know their pain points, you can work with them to find and build a solution.

Let me give you one example. Recently we worked with a customer based in San Francisco, California, a large company with hundreds of departments. Each department has its own applications and an identity store. The employee records are scattered between those different identity stores – and a given employee has to maintain multiple records under each department if they have to access any of the applications provided by that department. This has been the way the company operated for several years. A real productivity killer – but, convincing 100+ departments to build a unified identity platform across the company was challenging, both technically and politically. We’ve had several long discussions with their technical teams and is now in the process of building a unified identity platform with WSO2 Identity Server, in a phased approach.

3. GDPR has surely caught on and everyone is throwing this term around. But there’s a deadline approaching and we need to act fast. What’s the simplest way an enterprise can get started and what do they need to keep in mind?

GDPR is a historical milestone in all the initiatives brought up so far to protect consumer privacy. Even though it’s more applicable to EU, it has a global impact in the way it’s designed. Becoming GDPR compliant starts with a self-assessment – understand what data you collect from your employees, partners, suppliers, customers, and any other entities you work with. Then you need to see how the data is being stored and processed. If you occupy third parties in the process of data collection – or if you share data with third parties for further processing, then you also need to worry about them being GDPR compliant. Once that’s done, you can come up with a phased approach to be GDPR compliant. It’s always recommended that you consult a lawyer or any GDPR consultancy firm to validate your approach and get their guidelines. GDPR is a law, so you should not mess with it!

There are no all-in-one or tailor-made solutions for GDPR. This is where WSO2 Identity Server has a key role to play. WSO2 Identity Server, as an identity provider, gets directly involved in processing personal data. We have made the product GDPR compliant and also provide a portal for consent management.

4. What’s the future like for open source IAM solutions?

A decade back, the IAM market was mostly dominated by Oracle and IBM. The entry barrier was high and was not justifying the cost over the benefits.

Today the number of companies occupying an IAM solution is much better. Cloud-based IAM solutions and open source IAM solutions increasingly reduce the cost of entry.

There are more than 100 Universities in USA and Canada, using WSO2 Identity Server for free, with no support from WSO2. That’s the beauty of real open source.”

According to Gartner, by 2021 open source IAM components will be used for one or more IAM functions by 30% of organizations, up from 20% at the end of 2016. Apart from open source, there are a large number of companies that use homegrown IAM solutions – around 20%. In the next few years, I would expect these companies using homegrown IAM solutions to select an open source IAM product. Unless you have a dedicated set of engineers, who have expertise on IAM, it’s hard to keep up with the pace in which the IAM industry is evolving.

Another important fact I would like to highlight here is open source licensing. Not all open source licenses give you the same level of freedom. Apache 2.0 is the most business-friendly open source license. You can do anything with a product released under Apache 2.0. All WSO2 products are released under the Apache 2.0 license and WSO2 is the 8th largest open source software company. There are more than 100 Universities in USA and Canada, using WSO2 Identity Server for free, with no support from WSO2. That’s the beauty of real open source.

5. What are the benefits of an open source IAM solution?

There are multiple reasons why someone would pick an open source IAM vendor over commercial off-the-shelf (COTS) software. At one point, COTS had an edge over the features, but no more. Most of the open source IAM products out there can compete with any COTS product, in terms of features, and of course, perform better.

Then the cost. Most of the open source products do not have any licensing cost, but a production support model. This definitely reduces the initial product purchasing cost. One key reason I see why people go for open source IAM products is the ‘freedom’.

Most of the open source IAM products out there have a proven track record. I can speak for WSO2 Identity Server, where we have many large scale deployments around the globe, for millions of users.”

The freedom to examine the source code, freedom to extend the capabilities, and freedom to make business decisions.

That’s about scalability, how about security? Irrespective of a product being open source or not, you need to worry about the security of the product. At WSO2, we put a lot of effort into building all WSO2 products in a secure manner. We use both open source (OWASP ZAP) and commercial code scanning tools (Veracode, IBM AppScan). All these tools are integrated into the build system and no product releases are done without fixing any of the reported issues.

6. How did you start working in IAM?

It just happened. When I joined WSO2 in 2007, I was assigned to the WSO2 Identity Server team. At that time it was called, ‘Identity Solution’ – and we only had 4 members in the team. WSO2 was founded in 2005, where SOAP, SOA, web services were at the top of the hype. We had a strong, solid foundation in that space. Both of our founders are pioneers in the web services domain, and authored many key web services specifications. Axis2, Synapse, Rampart, WSS4J are top open source Apache projects initiated and mostly contributed by WSO2 employees at that time. Apache Rampart is the web services security module for Axis2 – and it has all WS-Security, WS-Security Policy, WS-Trust specifications covered. Around 2006/2007 we were closely working with Microsoft for interop testing, and that was the time Microsoft came up with an open specification called ‘Information Cards’, which is based on WS-Security and WS-Trust. Since we already had them implemented in Rampart, it only needed a little more effort on top of that to build support for Information Cards. That’s how the WSO2 Identity Server was born in 2007 – and it was one of the very first implementations of Information Cards in Java.

7. What is your proudest accomplishment in recent times?

WSO2 Identity Server celebrated its 10th anniversary in December 2017. Looking back, there are many proud moments that were accomplished as a team. Today, WSO2 Identity Server is a globally recognized brand and is one of the top open source IAM products. There are more than 40 million users globally using WSO2 Identity Server for authentication on daily basis. There are more than 100 paying customers, which we are extremely proud of. Just to name a few, Nissan, HP, GE, Verizon, Vodafone, Seagate, Department of Homeland Security (DHS), Verifone, Align Tech, WEST, Nutanix, Trimble and many more. It’s extremely satisfying to see how the product evolved over the last 10 years and is now trusted by many Fortune 100 and Fortune 500 companies to build the most critical parts of their core business on top of WSO2 Identity Server.

8. What advice would you like to give a budding developer or an architect to better their career?

Failing to innovate is the biggest failure in anyone’s life. The world does not lack technical skills, but fresh ideas.”

Failing to innovate is the biggest failure in anyone’s life. The world does not lack technical skills, but fresh ideas. Fresh ideas are born when you start feeling your problems and those of others. You may choose to live with the pain or get rid of it by fixing the problem. The latter leads to innovation. There is always room for improvement, room for innovation. Capitalize on those and enjoy what you do.

You can follow Prabath here and read his blog here.

10 11 12 – WSO2 Identity Server Keeping the Bad Guys Away Since 2007!

WSO2 Identity Server turns 10 today on the 11th day of the 12th month of this year! Over the years the team has grown, research and development efforts have evolved, we’ve procured some big-name customers and various team members have gone on to publish stellar books on identity and access management.

To commemorate this day we thought we’d pick a few cool things (from a long list) about WSO2 Identity Server:

  • WSO2 Identity Server manages more than 40 million identities across the world.
  • Fully open source, WSO2 Identity Server has thousands of FREE users.
  • Mobile Connect support from WSO2 Identity Server is available for more than 900 million users in India.
  • Our first customer, ELM, manages over 4 million user identities and we’re still a part of their digital journey.
  • (Let the name dropping begin) Some of our other customers include Verifone, West Corporation, Verizon, HP, Seagate, Nutanix, T-Systems, and many in the educational industry such as Brigham Young University, New York University and Australian Catholic University.
  • We offer over 40 connectors in our connector store so that you can integrate with any system and enhance your system capabilities.
  • Single sign-on (SSO) and identity federation are our forte. You can ask any of our customers! Here’s a link to the latest version of the WSO2 Identity Server.
  • We were the winner for “Identity as a service” in 2011 at the KuppingerCole European identity awards. We also helped one of our customers to bag an award at EIC 2015 for their Mobile Connect implementation.
  • Prabath Siriwardena, our director of security architectures, is not only a renowned figure in the IAM space, but also the author of Advanced API Security, Maven Essentials and more.
  • Concerned about GDPR or PSD2? Want to know how Customer IAM can help you with digital transformation? We have got your covered for 2018 and beyond!

Congratulations to our IAM team for their amazing feats over the years and special thanks to one of our starting members Ruchith, who has gone off to accomplish amazing things! You can read Prabath’s blog to get the full low down on how we started.

Brigham Young University: Enabling API Discoverability and Data-driven Business Insights with WSO2

Brigham Young University (BYU) began their API Management story 2 years ago when they decided to adopt an API-first architecture that follows a governed process. With over 451 APIs for both external and internal customers, and several development teams working independently of one another, Brayden Winterton (Software Engineer at BYU) likens its management akin to running a small city.

Modernizing their API management was a result of a problematic system that existed at that time. For one, the API manager in existence was closed-sourced and used an old, unsupported third party code. Adding some confusion to the mix, BYU had two versions of their API infrastructure in production – having started with one version, developing a second version along the way and the migration process forever a work in progress. Due to a memory leak, boxes had to be rebooted nightly (if not all API traffic ceased by noon the next day). Furthermore, there was no monitoring of API usage and the documentation support was out of date. In short, BYU was in a “serious situation” to use Brayden’s exact phrase.

Faced with all these scenarios, BYU was looking to implement a new API management solution. A key need was to create a centralized repository for all the APIs at BYU, which enables developers to search for and find all the available APIs, in addition to the respective authorization processes. A seamless transition without drastic changes to their existing developer work was another one of their important requirements. Low latency, up-to-date documentation, integrating with legacy systems and the ability to keep track of all the APIs being utilized completed their wish list.

To implement their requirements, they turned to WSO2 API Manager and WSO2 Identity Server. BYU now has subscriptions that allow consumers to get through to the API and subsequent monitoring; they were able to integrate all legacy systems with message mediation, minimized latency even while mediating quite heavily and of course, it is all open source. The BYU model works on open subscription first, however there are instances where they have needed to block a subscription until further approval was granted. They have been able to do this with an open source platform. Another huge plus has been the ability to utilize industry standards and BYU even got something that was not available to them previously – monitoring and analytics to support their business decision making. Improving discoverability and keeping the documentation up to date were the last pending issues for BYU, ultimately solved by the BYU developer portal in the second stage of their implementation.

“Our developers who have migrated are having a fantastic experience. They’re able to use things in a standard way, able to find the documentation they are looking for, utilize libraries, things aren’t drastically different, all of their old systems are continuing to work and they are getting a lot better reliability out of what they’re trying,” says Brayden. Adding to this success, BYU has seen higher API consumption as of late and with the improvements in place, Brayden is excited about the future.

If you would like to listen to Brayden’s full presentation at WSO2Con USA, click here.

Learn more about the WSO2 API Manager and WSO2 Identity Server if you haven’t tried it out yet.

Cashing in on APIs – Leveraging Technology to Boost Your Business

Even if you’re not an excessively tech-savvy individual, you most likely would have used a mobile application in your mobile device via an internet connection, used a Gmail client, Twitter, Facebook, or mobile apps, or purchased something online. In a tech world, you’re already reaping the benefits of application programming interfaces (APIs). The use of APIs is becoming even more popular today as service providers are scrambling to embrace the Internet of Things. With the availability of new tracking devices, smart homes, smart vehicles, mobile phones and tablets, consumers now have more options on how they consume applications.

Let’s take a step back and try to understand what this all means. An API is a term that’s used to denote a well-defined interface to access certain resources – in other words a service available to an end-user. If you haven’t worked with web APIs before, you may think it’s a type of service exposed over the Internet to perform certain operations. APIs are the foundation of today’s software engineering industry and enterprises are jumping on the bandwagon to reap the benefits of using them to integrate and automate to make their online services more appealing and user-friendly to end-users. Well-designed APIs will enable your business to expose content or services to internal and external audiences in a versatile manner. Today, most organizations use APIs to build their solutions internally and expose these services to the world at large. APIs will immensely benefit both service development teams as well as service consumers.

A good, yet simple example that illustrates this well is a weather update application that’s available on your mobile device. This application that typically runs on a device will not be able to provide weather forecasts of a specific area without connecting to an external service. However, it can call a GPS device on your mobile device or request the user to retrieve location coordinates of a specific area for which you want a forecast. Once you’ve defined your geographical location, the mobile application can simply call a weather service API and request the required information. What’s important to note here is that you don’t need to perform any complicated tasks, do calculations, or run an analysis on the mobile device. You can simply push relevant parameters to an API and obtain the results you want.

If you view this same example from one level up, you’d see that there’s a client application and a service and both of these are connected by an API. That’s essentially what an API does; it can integrate your services, data, content, and processes with external parties in a very effective and efficient manner. So, what’s the difference between services and APIs? Essentially, the functions of both are the same, but a slight differentiator would be that an API would generally have a well-defined interface to its services. That said, there’s a notable difference between managed and normal web APIs/services. Managed APIs are often enriched with additional features on top of a standard API or service. These are referred to quality of services or QoS. Common QoSs include security, access control, throttling, and usage monitoring. Security forms the foundation any API infrastructure across the entire digital value chain. Malicious users can access your systems the same as legitimate users would, therefore it’s important to enable security at all points of engagement. Usage monitoring helps enterprises to improve their APIs, attract the right app developers, troubleshoot problems and, ultimately, translate these to better business decision.

Boosting efficiency to become more competitive

Enterprises too are seeing the potential benefits of APIs to propel business growth, irrespective of the size and nature of the business and the industry they operate in. The key is to get started now to be able to maintain a competitive edge. A typical example is the extensive use of APIs in the hospitality industry; for instance, the owner of a restaurant or a small hotel would operate a simple website and some internal services. But at some point, when the business grows, they cannot maintain the same internal system and work with external parties. At this stage, business owners would need to think about consuming external services and exposing their services to the external world. And that’s when APIs and API management solutions come into play.

Large, global companies in the financial, transportation, logistics, and consumer sectors have already started to expose their systems and services to the outside world as APIs. The real benefit lies with being able to seamlessly integrate internal systems with those external ones to leverage benefits like creating properly structured services that are synced within the company, e.g. human resources department exposing non-sensitive employee data to other departments that need this information. A typical example is an online retail business that would need a payment solution to integrate with its system. Such a solution would not need to be implemented from scratch, rather the business can expose APIs via already available payment solution providers like Stripe, Zuora, or PayPal.

To explain this further, let’s consider a restaurant owner who can expose menus and ordering services via APIs. This will enable external developers to consume these APIs with their apps and incorporate the restaurant’s menus and services into the travel applications they’re building. When exposing APIs, the restaurant owner would need to consider throttling, a process responsible for regulating the rate at which the application is processing, as well as the security aspect of exposing these APIs. On top of these, a service provider may need some insights into the usage of these APIs – for instance, details about service consumers (like which apps have been invoked more), usage patterns (most popular food types), traffic patterns (peak order times), etc in order to make certain business decisions and make the service more efficient. For this, you might need sort of analytics and usage monitoring capabilities as part of your overall API management solution.

How Internal Services Can Expose Services to External World Via APIs

how internal services can expose services via APIs

Ultimately what you achieve in terms of business benefits is brand awareness by becoming a smart business. Moreover, in addition to profits gained from direct API consumption, users can earn additional revenue by charging users for API/service usage. This concept is known as API monetization and most API management solutions already have this feature in-built as an extension, enabling creative users to turn cool ideas into revenue generating APIs within minutes. And open source products have proved to be most useful to meet all your API management requirements as its cost effective and easy to deploy.

What Does WSO2 Identity Cloud Bring To The Table?

One of the things we spoke about at WSO2Con this year was the expansion of our  WSO2 public Cloud offerings. One of those offerings is WSO2 Identity Cloud, which provides the Identity and Access Management (IAM) solution from our well-known WSO2 Identity Server with the ease of use of a cloud service.

Our Initial offering is focused on providing Single Sign-On (SSO) solutions for organizations. Almost all organizations use different applications, either developed in-house or hosted applications like Salesforce and Concur. Having a centralized authentication system with SSO for all the applications increases the efficiency of maintaining systems, centralize monitoring and company security, while also making users’ lives easier.

What are the features offered by WSO2 Identity Cloud?

  • Single Sign-On support with authentication standards – SAML-2.0, OpenID Connect, and WS-Federation.
  • Admin portal provided for organization administrators to log in and configure security for applications. Pre-defined templates of security configurations are available by default for most popular SaaS apps. This list includes Salesforce, Concur, Zuora, GotoMeeting, Netsuite, AWS.
  • On-premise-user-store agent. Organizations can connect local LDAPs with Identity Cloud (without sharing LDAP credentials with Identity Cloud) and let users in the LDAP to access applications with SSO.
  • Identity Gateway.  Act as a simple application proxy that intercepts application requests and applies security checks.
  • User portal. Provides a central location for the users of an organization to log in and discover applications, while applications can be accessed with single sign-on.

Why you should go for a Cloud solution?

If you have following concerns, then a cloud solution is the best fit for you.

  • Facilitating infrastructure – you don’t have to spend money on additional infrastructure with the Cloud solution.
  • System maintenance difficulties – If you do an on-premise deployment, then there should be a dedicated team allocated to ensure the availability of the system and troubleshoot issues; with the Cloud solution, the  WSO2 Cloud team will take care of such things.
  • Timelines – Identity Cloud is tested, stable solution. This will cut down the deployment finalizing and testing times that you should spend on an on-premise deployment.

With all of this comes cost savings, especially because there’s no cost involved for infrastructure or maintenance with the cloud solution.

You can register for WSO2 Identity Cloud and try out for free – http://wso2.com/cloud/ and give us your feedback on bizdev@wso2.com or dev@wso2.org.

Introducing WSO2 Enterprise Integrator 6.0

WSO2 started out as a middleware company. Since then, we’ve realized – and championed the fact that our products enable not just technological infrastructure, but radically change how a company works.

All over the world, enterprises use our products to maximize revenue, create entirely new customer experiences and products, and interact with their employees in radically different ways. We call this digital transformation – the evolution of a company from one age to another, and our role in this has become more a technology partner than a simple software provider.

In this realization, we’ve announced WSO2 Enterprise Integrator (EI) 6.0. Enterprise Integrator brings together all of the products and technologies WSO2’s created for the enterprise integration domain – a single package of digital transformation tools closely connected together for ease of use.

When less is more

Those of you who are familiar with WSO2 products will know that we had more than 20 products across the entire middleware stack.

The rationale behind having such a wide array of products was to enable systems architects and developers to pick and choose the relevant bits that are required to build their solution architecture. These products were categorized into several broad areas such as integration, analytics, Internet of Things (IoT) and so on.

We realized that it was overwhelming for the architects and developers to figure out which products should be chosen. We also realized that digital transformation requires these products to be used in certain common patterns that mirrored five fields: Enterprise Integration, API Management, Internet of Things, Security and Smart Analytics.

In order to make things easier for everyone, we decided to match our offerings to how they’re used best. In Integration, this means we’ve combined the functionality of the WSO2 Enterprise Service Bus, Message Broker, Data Services Server and others; now, rather than including and setting up many many products to implement an enterprise integration solution you can simply download and run Enterprise Integrator 6 (EI 6.0).

What’s it got?

EI 6.0 contains service integration or service bus functionality. It has data integration, service, and app hosting, messaging, business processes, analytic and tooling. It also contains connectors which enable you to connect to external services and systems.



The package contains the following runtimes:

  1. Service Bus

Includes functionality from ESB, WSO2 Data Services Server (DSS) and WSO2 App Server (AS)

  1. Business Processes

Includes functionality of WSO2 Business Process Server (BPS).

  1. Message Broker

Includes the functionality of WSo2 Message Broker (MB). However, this is not to be used for purely message brokering solutions; this runtime is there for guaranteed delivery integration scenarios and Enterprise Integration Patterns (EIPs).

  1. Analytics

The analytics runtime for EI 6.0, useful for tracking performance, tracing mediation flows and more.

In order to provide a unified user experience, we’ve made some changes to the directory structure. This is what it looks like now:

The main runtime is the integrator or service bus runtime and all directories relevant to that runtime are at the top level.

This is very similar to the directory structure we use for other WSO2 products; the main difference is the WSO2 directory, under which the other runtimes are available.

Under the other runtimes, you find the same directory structure as the older releases of those products, as shown below.

One might ask why we’ve included multiple runtimes instead of putting everything in a single runtime. The reason for doing so is the separation of concerns. Short running, stateless integrations will be executed on the service bus runtime while long-running and possibly stateful integrations will be executed on the BPS runtime. We also have optional runtimes such as message broker and analytics which will be required only for certain integration scenarios and when analytics are required, respectively.

By leaving out unnecessary stuff, we can reduce the memory footprint and ensure that only what is required is loaded. In addition, when it comes to configuration files, only files related to a particular runtime will be available under the relevant runtime’s directory.

On the Management Console

There’s also been a change to the port that the management console uses. The 9443 servlet transport port is no longer accessible; we now use the 8243 HTTPS port. Integration services, web apps, data services and the management console are all accessible only on the passthrough transport port, which defaults to 8243.

Tooling

Eclipse-based tooling is available for the main integration and business process runtimes. For data integration, we recommend using the management console itself from the main integration runtime.


Why 6.0?

As the name implies, EI is an integration product. The most widely used product in the integration domain is the WSO2 Enterprise Service Bus (ESB), which in the industry is known to run billions of transactions per day. EI is in effect the evolution of WSO2 ESB 5.0, adding features coming from other products. Thus, it’s natural to dub this product 6.0 – the heart of it is still the same.

However, we’ve ensured that the user experience is largely similar to what it was in terms of the features of the previous generation of products.  The Carbon platform that underlies all of our products made it easy to achieve that goal.

Migration to EI 6.0

The migration cost from the older ESB, BPS, DSS and other related products to EI 6.0 is minimal. The same Synapse and Data Services languages, specifications and standards have been followed in EI 6.0. Minimal changes would be required for deploying automation scripts such as Puppet scripts -the directory structures are still very similar, and the configuration files haven’t changed.

What is new in WSO2 Identity Server 5.3.0?

Since its launch in 2007, WSO2 Identity Server (WSO2 IS) has become an industry leading product in the open source, on-premise IAM space. It’s trusted by both the government and private sectors for large scale deployments ranging up to millions of users.

Apart from the open standard support, WSO2 IS has a solid architecture to build a strong identity ecosystem around it. More than 40 connectors are now available for you to download from WSO2 Connector Store – including SMS OTP, Email OTP, TOTP (Google Authenticator), Duo Security, mePIN, RSA, FIDO U2F  – and many more. All these connectors are released under the same open source Apache 2.0 license, as of the product.

The focus of WSO2 Identity Server 5.3.0 is to build and enhance features around Identity/Account Administration and Access Governance. Here are the new features introduced in WSO2 Identity Server 5.3.0:

  • Identify and suspend user accounts that have been idle for a pre-configured amount of time. Prior to account suspension, the administrator can set up the notification system to notify the user with a warning that the account will be suspended.
    For instance, if a user has not logged in to his/her account for 90 days, the user will be notified that his account will be suspended within the next 7 days if there continues to be no activity, after which the account will be suspended.
  • A new REST API was introduced to recover a lost/forgotten password, i.e., by using email notifications or secret questions. It is also possible to recover the username if forgotten. This extends the functionality of the SOAP service WSO2 IS had before 5.3.0.
  • The administrator can trigger the password reset for a given user. This may be required if the user forgets the credentials and then makes a request to the administration to reset the password — and also in cases where the credentials get exposed to outsiders then the administrator can lock the account and enforce password reset.
  • Support for Google reCAPTCHA as a way of brute-force mitigation. The administrator can configure Google reCAPTCHA in the login, password/account recovery and sign up flows.
  • Maintain the history of the user’s passwords according to a pre-configured count. This prevents a user from using a password he/she has used in the recent past. For example, if you configure a count of 5, the user will be prevented from reusing his/her last 5 passwords as the current password.
  • The administrator can monitor all the login sessions — and can selectively terminate.
  • Enforce policies to control outbound user provisioning operations. For example, you can provision users having the salesteam role to Salesforce and anyone having an email address with the domain name foo.com to Google Apps.
  • Partition users by service providers. WSO2 IS had support for multiple user stores since its version 4.5.0. With this new feature, the administrator can specify against which user store the user should authenticate, by the service provider. For example, only the users in the foo user store will be able to access the foo service provider.
  • Enforce policies during the authentication flow. The administrator can, for example, enforce a policy which states only the users having the salesteam role can access Salesforce, and only during a weekday from 8 AM to 4 PM.
  • Improvements for the JIT provisioning flow. The administrator can now specify mandatory attribute requirements for JIT provisioning and if any of those are missing, WSO2 IS will prompt the user to enter the values for the missing attributes.
  • Improvements for identity analytics. With WSO2 IS 5.3.0 the identity administrator can get alerts for abnormal and suspicious login sessions.

In addition to the above set of features, WSO2 IS 5.3.0 also introduced a set of enhancements for its existing open standards.

  • SAML 2.0 Metadata Profile
  • SAML 2.0 Assertion Query/Request Profile
  • OpenID Connect Dynamic Client Registration
  • OAuth 2.0 Token Introspection
  • OpenID Connect Discovery
  • JSON/REST profile of XACML

WSO2 IS 5.3.0 is now the best it’s ever been. We hope you will find it quite useful to address your enterprise identity management requirements, and we’re more than happy to hear your feedback/suggestions — please feel free to post them to bizdev@wso2.com or dev@wso2.org.

Implementing an Effective Deployment Process for WSO2 Middleware


Image reference: https://www.pexels.com/photo/aerospace-engineering-exploration-launch-34521/

At WSO2, we provide middleware solutions for Integration, API Management, Identity Management, IoT and Analytics. Running our products on a local machine is quite straightforward: one just needs to install Java, download the required WSO2 distribution, extract the zip file and run the executable.

This provides a middleware testbed for the user in no time. If the solution needs multiple WSO2 products, those can be run on the same machine by changing the port-offsets and configuring the integrations accordingly.

This works very well for trying out product features and implementing quick PoCs. However, once the preliminary implementation of the project is done, a proper deployment process is needed for moving the system to production. 

Any software project needs at least three environments for managing development, testing, and the live deployments. More importantly, a software governance model would be needed for delivering new features, improvement, bug fixes and managing the overall development process.

This becomes crucial when the project implements the system on top of a middleware solution. Both middleware and application changes will need to be delivered. There might be considerable amounts of prerequisites, artifacts and configurations. Without having a well-defined process, it would be difficult to manage such projects efficiently.

A High-Level Examination

One would have to consider the following points would need to be considered when implementing an effective deployment process:

  • Infrastructure

WSO2 middleware can be deployed on physical machines, virtual machines and on containers. Up to now most deployments have been done on virtual machines.

Around 2015, WSO2 users started moving towards container-based deployments using Docker, Kubernetes and Mesos DC/OS. As containers do not need a dedicated operating system instance, this cuts down resource requirements for running an application – in contrast to a VM. In addition, the container ecosystem makes the deployment process much easier using lightweight container images and container image registries.

We provide Puppet Modules, Dockerfiles, Docker Compose, Kubernetes and Mesos (DC/OS) artifacts for automating such deployments.

  • Configuration Management

The configuration for any WSO2 product can be found inside the relevant repository/conf folder. This folder contains a collection of configuration files corresponding to the features that the product provides.

The simplest solution is to maintain these files in a version control system (VCS) such as Git. If the deployment has multiple environments and a collection of products, it might be better to consider using a configuration management system such as Ansible, Puppet, Chef or Salt Stack for reducing configuration value duplication.

We ship Puppet modules for all WSO2 products for this purpose.

  • Extension Management

WSO2 middleware provides extension points in all WSO2 products for plugging in required features.

For example, in WSO2 Identity Server a custom user store manager can be implemented for connecting to external user stores. In the WSO2 Integration products, handlers or class mediators can be implemented for executing custom mediation logic.  Almost all of these extensions are written in Java and deployed as JAR files. These files will simply need to be copied to the repository/components/lib folder or the repository/components/dropins folder if they are OSGi compliant.

  • Deployable Artifact Management

Artifacts that can be deployed in repository/deployment/server folder fall under this category. For, example, in the ESB, proxy services, REST APIs, inbound endpoints, sequences, security policies can be deployed in runtime via the above folder.

We recommend that you create these artifacts in WSO2 Developer Studio (DevStudio) and package them into Carbon Archive (CAR) files for deploying them as collections. WSO2 DevStudio provides a collection of project templates for managing deployable files of all WSO2 products. These files can be effectively maintained using a VCS.

These files can be effectively maintained using a Version Control System.

  • Applying Patches/Updates

Patches were applied to a WSO2 product by copying the patch<number> folder which is found inside the patch zip file to the repository/deployment/patches/ folder.

We recently introduced a new way of applying patches for WSO2 products with WSO2 Update Manager (WUM). The main difference of updates, in contrast to the previous patch model, is that fixes/improvements cannot be applied selectively; it applies all the fixes issued up to a given point using a CLI. This is the main intention of this approach.

  • Lifecycle Management

In any software project it is important to have at least three environments – one for managing development, one for testing and one for production deployments.  New features, bug fixes or improvements need to be first done in the development environment and then moved to the testing environment for verification. Once the functionality and performance are verified the changes can be applied in production (as explained in the “Rolling Out Changes”) section.

The performance verification step might need to have resources identical to the production environment for executing load tests. This is vital for deployments where performance is critical.

With our products, changes can be moved from one environment to the other as a delivery.  Deliveries can be numbered and managed via tags in Git.

The key advantage of using this approach is the ability to track, apply and roll back updates at any given time.

  • Rolling Out Changes

Changes to the existing solution can be rolled out in two main methods:

1. Incremental Deployment (also known as Canary Release).

The idea of this approach is to incrementally apply changes to the existing solution without having to completely switch the entire deployment to the new solution version. This gives the ability to verify the delivery in the production environment using a small portion of the users before propagating it to everyone.

2. Blue-Green Deployment

In Blue-Green deployment method, the deployment is switched to the newer version of the solution at once. It would need an identical set of resources for running the newer version of the solution in parallel to the existing deployment until the newer version is verified. In case of failure, the system can be switched back to the previous version via the router. Taking such approach might need a far more thorough testing procedure compared to the first approach.

Deployment Process Approach 1

This illustrates the simplest form of executing a WSO2 deployment effectively.

In this model the configuration files, deployable artifacts and extension source code are maintained in a version control system. WSO2 product distributions are maintained separately in a file server. Patches/updates are directly applied to the product distributions and new distributions are created. The separation of distributions and artifacts allows product distributions to be updated without losing any project content.

As shown by the green box in the middle, a deployable product distribution is created, combining the latest product distributions, configuration files, deployable artifacts and extensions. Deployable distributions can be extracted on physical, virtual machines or containers and run. Depending on the selected deployment pattern, multiple deployable distributions will need to be created for a product.

In a containerized deployment, each deployable product distribution will have a container image. Depending on the containerized platform, a set of orchestration and load balancing artifacts might also be used.

Deployment Process Approach 2

In the second approach, a configuration management system has been used for reducing the duplication of the configuration data and automating the installation process.

Similar to the first approach, deployable artifacts, configuration data and extension source code are managed in a version control system. Configuration data needs to be stored in a format that is supported by the configuration management system.

For an example, in a Puppet configuration, data is either stored in manifest files or Hiera YAML files. Deployable WSO2 product distributions are not created. Rather, that process is executed by the configuration management system inside a physical machine, virtual machine or in a container at the container build time.

In conclusion

Any of the deployment approaches we’ve spoken about above can be followed with any infrastructure. If a configuration management system is used, it can be used for installing and configuring the solution on virtual machines and as well as on containers. The main difference with containers is that configuration management agent will only be triggered at the container image build time. It may not be run in the when the container is running.

If a configuration management system is used, it can be used for installing and configuring the solution on virtual machines and as well as on containers. The main difference with containers is that configuration management agent will only be triggered at the container image build time. It may not be run in the when the container is running.

At the end of the day, a proper deployment process is essential. For more information and support, please reach out to us. We’d be happy to help.