How WSO2 StratosLive meets security challenges in Cloud

WSO2 StratosLive is the public and open platform as a service (PaaS) operated by WSO2. In other words, it is the open source cloud middleware platform developed by WSO2, readily available as a service (PaaS) in the cloud. It includes the whole enterprise middleware products stack developed by WSO2, as different services in cloud.

It provides cloud consumer with comprehensive set of cloud native features such as self provisioning, multi tenancy, elasticity, billing and metering etc. You can read more on Core Features of Stratos.

In this post, I will go through how WSO2 StratosLive meets some of the common security challenges found in the PaaS layer of Cloud computing stack. This is related with my previous blog on "Security Challenges in Cloud". You may refer it to get an understanding about some of the security challenges encountered in the cloud computing stack.

I have extracted out the security challenges that I described in the above post and discuss how StratosLive has overcome them as follows.

Availability: To withstand the load and function with minimum or no downtime in the face of high loads ensuring the availability, StratosLive incorporates load balancers, clustering and auto-scaling.

Data isolation: Data isolation in registry is achieved with the tenant domain id, in a shared schema, shared database pattern, while the registry data storage is hosted in a DMZ. And if a tenant wants to store data related to an application that he has hosted, then he can create his own storage instance in the Data PaaS offerings provided with SLive such as RDS (Relational Databse as a Service) or Apache Cassandra as a service.

Data protection (during transport, processing and storage): Data communication from the browser to back end Admin Services happens over https (encrypted) which provides transport level protection. Custom code deployed by tenants (webapps, web services) does not have access to data processing code  which is protected by java security manager. The data storage is hosted in a DMZ (De Militarized Zone) which ensures that incoming connections from only a set of trusted hosts are granted access to the data storage. Also, the RDS instances that tenants can create are protected with username/password authentication.

Tenant isolation: Each tenant is given a separate security domain such that each domain is isolated and does not have access to other domains. 

For an example, when a tenant is created, a separate realm is created for that tenant which includes its own UserStoreManager, RealmConfiguration and AuthorizationManager so that user management and permission management happens without interfering with other tenants.

Logic/Execution isolation: From architecture, design and code level of all most all the carbon components which are the building blocks of cloud middleware platform, are  developed in a manner that supports multi-tenancy.  (Multi-tenancy is serving multiple client organizations with multiple virtual instances isolated from one another, while there is a single instance of the software running on the server).

Also, different Axis2 contexts are created for each tenant where all the tenant specific states are kept which facilitates execution isolation for each tenant. (Apache Axis2 is the underlying web services engine used in WSO2 Carbon platform).

Protection form malicious code: Since the middleware platform allows tenants to host their own code, privileged actions in the platform are being protected such that those operations can not be invoked by tenants' code deployed in the platform. This is achieved by restricting access to critical code through Java Security Manager. Access is allowed only from code that is signed properly.

Identity Management: This is the most widely discussed topic in cloud security.

• Authentication : In addition to basic username, password based authentication, number of industry standard authentication mechanisms are supported.
• XMPP based Multifactor Authentication for stronger authentication
• Federated authentication mechanisms such as OpenID provider and SAML2.
• SAML2 based Single Sign On among all the services in SLive.
• Authentication delegations mechanisms such as OAuth.
• Cloud users are provided with the ability of securing communication to their services hosted in SLive with WS-Security mechanisms powered by Apache Rampart which is the security module of Axis2.
• Further, tenants can integrate their custom webapps deployed SLive, with their user store in SLive in order to authenticate users into those webapps.

• Authorization: Role based permission model as well as powerful, fine grained and flexible Policy Based Access Control with XACML are supported.
• Auditing: Tenants' logs are isolated and each tenant admin can download logs related to its tenant from the Manager service. Distributed auditing mechanism is under development.
• Administration: Currently two different user provisioning mechanisms are supported: Bulk User import and provisioning users from google app domain into SLive.

Cloud Service Gateway: This can be introduced as a Private-Public Cloud bridge which facilitates the cloud consumers with a mechanism of securely connecting to public cloud from their internal network/private cloud.

Above are some mechanisms how SLive meets some of the common security challenges found in PaaS space. If you are interested more, you can listen to the following two webinars conducted during WSO2 Summer School 2011.

1. Identity Management in the Cloud

2. Platform as a Service