Category Archives: Products

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.

Up Next: Enterprise Integrator 7.0

EI 6.0 is based on several languages – Synapse for mediation, BPMN and BPEL for business processes, DSS language for data integration.

A user who wants to implement an integration scenario involving mediation, business processes, and data integration has to learn several languages with different tooling. While it’s effective, we believe we can do better.

At WSO2Con 2017, we just unveiled Ballerina, an entirely new language for integration. EI 7.0 will be completely based on Ballerina – a single language and tooling experience. Now the integration developer can concentrate on the scenario, and implement it using a single language and tool with first level support for visual tooling using a sequence diagram paradigm to define integration scenarios.

However, 7.0 will come with a high migration cost. Customers who are already using WSO2 products in the integration domain can transition over to EI 6.0 – which we’ll be fully supporting – while planning on their 7.0 migration effort in the long term; the team will be working on tooling which will allow migration of major code to Ballerina.

WSO2 will continue to develop EI 6 and EI 7 in parallel. This means new features and fixes will be released as WUM updates and newer releases of the EI 6.0 family will be available over the next few years so that existing users are not forced to migrate to EI 7.0. This is analogous to how Tomcat continues to release 5.x, 6.x, 7.x and so on.


EI 6.0 is available for download at wso2.com/integration and on github.com/wso2/product-ei/releases. Try it out and let us know what you think – it’s entirely open source, so you can take a look under the hood if that takes your fancy. To report issues and make suggestions, head over to https://github.com/wso2/product-ei/issues.

Need more information? Looking to deploy WSO2 in an enterprise production environment? Contact us and we’ll get in touch with you.

 

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.

How we handle security at WSO2

A Proactive Strategy for Security Management

Any decent software development organization generally has a well-defined set of policies and procedures for security management.

At WSO2, we – as in, the Platform Security Team – constantly collaborate with other product teams, customers and external security researchers to manage overall security of all WSO2 product. In this post, we’d like to talk about how we do this.


Part One: in the realm of code

code-944504_1280

I: Designing for security

The first stage of software design is the gathering of requirements. In open source software, we tend to use third-party code quite a bit – it’s how open source works: we stand on the shoulders of giants.
However, we can’t simply use what code we think is suitable.

The first check comes here. At WSO2, if we identify any kind of third-party code to be used, we need it to be first approved by the Engineering Management group, who are an internal group of seasoned architects who function at a directorial level. For us, security comes as a first priority, not as an afterthought.

The next set of checks come in the design phase. What are the communication protocols being used? How secure are they? Where is the data stored, and how? What endpoints are we exposing to the public? We go through a series of use cases to identify where this design can be broken, and work with the product design team to integrate our security concerns from the start.

II: Review, rinse, repeat

The next part is obvious: every developer is responsible for writing clean code [1, 2, 3].

Code written by each developer goes through a process of code quality reviewing overseen by members of the relevant product team and the Platform Security Team. When submitting the code for reviewing, the developer has to submit the static code analysis reports – generated using tools like FindSecBugs [4]. This is a mandatory security check in the reviewing process. Only upon fixing all issues spotted in the first pass is code is merged to the repository.

III: Testing with the automated grindhouse

At WSO2, we use Jenkins quite a lot for automating the build process. It builds individual components; it packages components together; it constantly builds and re-builds.

A large part of our security testing is integrated right into this process. Jenkins first performs the OWASP Dependency Check [5, 6], which analyzes the project dependencies and produces vulnerability reports. Even after the selection process in the first stage is complete, there can be some vulnerabilities that we haven’t spotted – especially if they’ve only been discovered extremely recently.

Next, Jenkins uses FindSecBugs as a plugin; during each automated build cycle, it checks individual components and generates vulnerability reports, which are in turn submitted to the security team for review.

Jenkins also uses the OWASP Zed Attack Proxy for dynamic code analysis [7, 8]. During the dynamic security analysis, the entire URL tree of the product is scanned and well-known attacks and exploits are automatically performed; the results are reported. These reports, too, are investigated by the respective product team as well as the Platform Security Team.

Once the testing is complete and a product is ready to be released, the respective product team has to receive security clearance from the Platform Security Team. If any known vulnerabilities are still listed in the reports, the product team has to justify to us the existence of the reported vulnerability – a pretty hard job.

We find that developers may write code following all the best security practices, but when the code is merged together, it might still open up a vulnerability because of how everything integrates together.


 Part Two: when humans happen

astronaut-and-robonaut-shake-hands

I: Preparing for the real world

There’s a saying: no battle plan survives contact with the customer. Although security standards and processes are followed to the letter, our products have to run in the real world.

One of the most important things is building awareness. We put together a set of deployment patterns, security recommendations, and best practices to be followed when deploying our products; we also conduct public webinars for making awareness in security related topics for WSO2 users, which are available at wso2.com/library/webinars.

II: Building internal Champions

Sometimes there is a gap between the product team and the security team, since the members of the security team might not be specialists of the product.

In order to bridge this gap, we’ve have someone we call the ‘Security Champion’ in each product team. The Security Champion of the product team is responsible for maintaining the safety of the product and conducting vulnerability assessments.

All Security Champions (from different product teams) directly work with the Platform Security Team and share knowledge and experiences with each other. They also share the knowledge of the Platform Security Team back with the members of the product teams.

III: Patching up 

When a vulnerability is detected in a product, patches are created for all the versions that the issue exists in. If the severity of the vulnerability is catastrophic, these patches will be released to all customers immediately. If the severity is not catastrophic, we aggregate all patches developed during the month and release the lot at the end of the month as a security bulletin.

When a patch is ready, it’s sent out through WSO2 Update Manager (WUM), added to wso2.com/security-patch-releases and publicly announced. Every version of any given product supported by WUM will receive the patches automatically. Note that unless the product is supported by WUM, security patches are publicly released only for the very latest version of the products.

Moving forward, we’ve started recording this in Documentation at docs.wso2.com/display/Security/Security+Advisories for the sake of preserving more patch information. This effort is still recent but will add up over time.

IV: Responding to Vulnerability Reports

Technology gets updated every day and there are always new vulnerabilities and exploits discovered. We welcome contributions from our user community, developers, and security researchers to reinforce our product security. Over the years, a great many people – both customers and from the community -have helped us make our products the best they can be.

When someone reports a vulnerability, we try to verify the issue and respond to the reporter. If the vulnerability is a true positive, the patching process begins.

Generally, we do ask that the reporter refrains from publicly disclosing the vulnerability until we’ve patched it – this is to prevent anyone who might be vulnerable from being targeted.

We’re always looking for ways to make this easier. For example, we’ve set up wso2.com/security to serve as an easy, central point for our community to report issues. As time goes on,


 

References

[1] OWASP Secure Coding Practices https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

[2] Oracle Secure Coding Guidelines for Java http://www.oracle.com/technetwork/java/seccodeguide-139067.html

[3] SANS Secure Coding Guidelines https://www.sans.org/course/secure-coding-java-jee-developing-defensible-applications

[4] Static Code Analysis for Java using FindBugs Plugin and Identifying Security Bugs with FindSecurityBugs Plugin
http://tharindue.blogspot.com/2016/06/static-code-analysis-for-java-using.html

[5] OWASP Dependency Check CLI – Analyzing Vulnerabilities in 3rd Party Libraries http://tharindue.blogspot.com/2016/10/owasp-dependency-check-cli-analyzing.html

[6] Checking vulnerabilities in 3rd party dependencies using OWASP Dependency-Check Plugin in Jenkins https://medium.com/@PrakhashS/checking-vulnerabilities-in-3rd-party-dependencies-using-owasp-dependency-check-plugin-in-jenkins-bedfe8de6ba8#.ipu0b8u4o

[7] Dynamic Scanning with OWASP ZAP for Identifying Security Threats https://medium.com/@PrakhashS/dynamic-scanning-with-owasp-zap-for-identifying-security-threats-complete-guide-52b3643eee04#.nyy1fwiok

[8] Automating the boring stuff in development using ZAP and Jenkins : Continuous Integration
https://medium.com/@PrakhashS/automating-the-boring-stuffs-using-zap-and-jenkins-continues-integration-d4461a6ace1a#.jtknrzajt

Meet WSO2 EMM 2.2.0!

We’re excited to announce yet another landmark of our EMM story:  the latest version WSO2 EMM 2.2.0! WSO2 EMM comes with a host of device management, app management and analytics features that benefit IT admins as well as device owners themselves.

Let’s explore some of the new key features of this release.

Device Management

The latest release comes with improved APIs for better extensibility, advanced WiFi profiles and supports device restrictions available in Android 5.0 – Lollipop upwards.

Advanced WiFi Profiles

Some organizations prefer to configure enrolled devices over-the-air (OTA). The previous WSO2 EMM version supported only WEP (simple profile with only SSID and password input) and with 2.2.0 organizations will be able to configure enrolled devices with advanced WiFi profile types, such as EAP, WPA2 and enabling TLS/TTLS.

Device Restrictions

WSO2 EMM 2.2.0 supports all device restrictions (e.g. network configuration, VPN configuration, volume control) available from Android 5.0 – Lollipop upwards. For the complete list of supported devices restrictions, refer to our official documentation (Note: camera setting was delivered in a previous release).

App Catalog at Your Service

In the previous WSO2 EMM distribution, when a mobile application needs to be installed on a device either the admin will have to push applications to the mobile device via the WSO2 EMM Management Console or the device owner will have to be granted access to the Management Console, which is not a practical scenario.

With 2.2.0, WSO2 EMM will have a standalone mobile app called ‘App Catalog’. The App Catalog lists all mobile apps the device owner is permitted to install. Device owners will be facilitated to install mobile apps with just a click of a button and to uninstall and remove them as well.

Whitelisting and Blacklisting Apps

With this feature admins will able to whitelist and blacklist mobile apps already installed in the App Store, so that a specific set of mobile applications are provisioned to device owners. This will also enable fencing unknown malicious mobile apps from accessing corporate data.

Room to Grow – Let’s OEM

With this release WSO2 EMM unlocks a host of features capable of underpinning OEM efforts for organizations using custom Android devices as part of their business strategy (e.g. medical devices, point-of-sale devices, kiosks). Managing custom devices is two-fold; you can either maintain custom firmware or use custom apps signed by the device vendor (or by the firmware key provided by the device vendor). The 2.2.0 distribution comes with a system service app that can be installed on the device and thereby used to perform root operations on the device.

emm 2.2

Automatic Device Enrollment

With this, admins will be able initiate the device auto-enrollment by entering serial numbers via the Management Console for the required devices. Once corresponding devices are handed over to device owners, device owners will be facilitated to select the relevant serial number from the device and generate a one-time-token (OOT), which expires within a predefined duration. To complete the enrollment, you can either type in the OOT or simply scan the QR code.

This will increase the speed of enrolling a large number of devices with a few steps with less device user intervention.

Over-The-Air Firmware Upgrade

This feature will allow admins to upgrade device firmware (apps written to device ROM) via the WSO2 EMM Management Console to one/more devices in one go (e.g. a firmware upgrade to all COPE devices). Device owners, on the other hand, need not worry about manually obtaining the latest firmware, as upgrades will be auto-installed.

Silent App Installation, Update, and Removal

In the previous WSO2 EMM version, app installations would only take place subsequent to a user confirmation. With 2.2.0, apps can be installed, updated, or even removed from the device without the device owner’s consent.

Device Hard Lock

This enables admins to completely block a device user that can only be revoked by an admin. This will help organizations to screen out device users who breach organizational policies.

Device Reboot

This facilitates admins to remotely reboot Android devices via the Management Console.

How are my Devices Doing?

WSO2 EMM 2.2.0 offers an array of features to keep you up-to-date around your device portfolio.

Analytics Dashboard

The WSO2 EMM Device Monitoring Dashboard provides admins with insights into unmanaged and non-compliant devices, device distribution by platform, and BYOD/COPE ownership and connectivity.

Device Details

Admins can view both dynamic and static device related information via the WSO2 EMM Management Console. Viewable static data include memory, CPU details, and OS version. Viewable dynamic data include CPU/memory utilization, battery level, installed apps, connectivity strength, power status (i.e. on battery or plugged into a power source), and GPS location.

Alerts on Alerts

The previous WSO2 EMM Management Console facilitated admins to send alerts to Android devices; from WSO2 EMM 2.2 onwards, admins will be notified on the alert delivery and the device owner’s response to alerts as well, i.e. be notified on whether the alert was delivered, displayed, or dismissed. In addition, admins will be able to send custom alert types as well.

WSO2 Enterprise Mobility Manager (WSO2 EMM) is a 100% open source comprehensive platform supporting iOS, Android and Windows devices, which help organizations to deal with both corporate-owned, personally-enabled (COPE) devices and employee-owned devices with the bring your own device (BYOD) program.

You can download the product here and try it out for yourself. If you come across any issues please feel free to report them via the public JIRA.

Will Google Leave On-Premise Apigee Customers Behind?

By now you all know that Google intends to buy Apigee. So what does this mean for their customers? All we can make are assumptions, but the future doesn’t seem too bright. Firstly, customers with SaaS services on Amazon Web Services will most likely have to move to Google’s cloud platform. But this isn’t the biggest issue. It seems plausible that their on-premise customers will not be the highest priority because Google doesn’t have an enterprise on-premise solution, nor does it seem they will create one now.

So what will be the fate of on-premise Apigee customers?

We offer an appealing alternative. WSO2 API Manager offers a rich feature set and adaptable architecture encompassing advanced platform capabilities such as real-time analytics, API governance, and complex back-end integration.

Our roots lie deep in open source software, we’re committed to both on-premise and cloud solutions and offer commercial support at a reasonable price. If you are an Apigee customer who’s concerned about what the future might bring, now is a great time to look at WSO2!

We are serious about helping you fulfill the promise of the API economy. Check out our limited-time offer specially crafted for you. With free subscription periods and discounts, this is an opportunity you won’t be able to refuse!