Wednesday, August 31, 2011

Remarkable IT Event - Great Source of Knowledge - taking place in Sri Lanka

A remarkable IT Conference in the IT history of Sri Lanka is going to happen with in less than two weeks..

Yes.. it is none other than WSO2Con-2011..

Why do I say so? Is it ONLY because I am an employee of WSO2? Not really...

If you have participated in WSO2Con-2010 or if you have viewed the sessions conducted in WSO2Con-2010, which are available to download, you would also second my statement... 
WSO2Con-2011 agenda has been carefully designed to cover a lot more featured sessions that will be delivered by industry experts around the world..

WSO2 has a proven history of delivering valuable, unique and quality stuff  to the community with consistency and maturity, which you might already have witnessed through WSO2 Oxygen Tank library, webinars and summer school sessions.. 

Her grand annual event-WSO2Con is the zenith of all that where she goes beyond the expectations intending to deliver an amazing experience and unique value addition to your knowledge, whether you are an expert in the IT industry, an amateur IT professional or a university student in IT...

I will talk about specialty of WSO2Con-2011 on following four aspects in my future posts:
These are the aspects that I (and anyone) would look for, in general in an international IT conference...
  • Educational value - where I can expand the boundaries of my knowledge in a field of interest..
  • Industrial value - which addresses the industrial aspects focusing the practical usage of that knowledge in new innovations..
  • Speakers - where I can listen to the speakers who are scholars and experts in the field..
  • Place of the conference - additionally if the conference location is in a fascinating environment and if there are interesting events that I could attend after the conference, that will be greater...
Stay tuned...

Related Links:
1. Are you attending WSO2Con 2011
2. The SMALL miracle, ready for her BIGGEST IT event forever
3. WSO2Con 2011 - 10 top reasons to attend

Thursday, August 18, 2011

Carbon Authentication Framework

Authentication is a key aspect when it comes to security and identity management. As well as any platform should incorporate  a stronger authentication mechanism, it would be good to have it pluggable and extensible so that custom authentication mechanisms can be developed and plugged-in as required.

WSO2 Carbon platform has an extensible authentication framework which supports custom authenticators to be plugged-in as required. 
Carbon middleware platform has two main separations as front-end and back-end. Carbon Authentication framework has two extension points to plugin front-end and back-end authenticators.

BE Authentication
Following is the architecture diagram of extension point for back end authenticators.

                                               Image 1: Extension for Carbon back end authentication
  • To implement a BE authenticator, you need to implement CarbonServerAuthenticator interface.
  • Implementation needs to be registered as an OSGi service.
  • Default carbon BE authenticator implementation is AuthenticationAdmin.
  • Authenticator checks whether the httpsession of the incoming request is authenticated.
  • It is the login() method of an AuthenticationAdmin service, which sets whether a particular session is authenticated or not by validating the credentials provided at login.
  • If we need to customize login() method then our custom authenticator should also be an AdminService exposing the login() method.
  • Hence the login() request is bypassed at the AuthenticationHandler (which is hit at the invocation of any AdminService operation) and sent directly to the corresponding AdminService.
  • AuthenticationHandler picks up the correct authenticator from the AuthenticatorServerRegistry based on the priority and whether a particular authenticator can handle the current request.
FE Authentication
If you want to customize the authentication logic from front-end itself, you can write a corresponding FE authenticator as well.
It is the FE custom authenticator which is associated with the BE custom authenticator that calls the login() method of the relevant BE custom authenticator.
Following is the architecture diagram extension point for front end authenticators.

Image 2: Extension for Carbon front end authentication
  • You need to implement CarbonUIAuthenticator interface for a custom FE Authenticator.
  • DefaultCarbonAuthenticator is the default implementation of FE authenticator.
  • It is the CarbonSecuredHttpContext that looks for FE authenticators in AuthenticatorRegistry and picks up the correct authenticator.
Existing Authenticators
In addition to the default authenticators, there are several custom authenticator implementations in Carbon code base which are used at different occasions. They are:
  1. saml2-sso-authenticator
  2. sso-authenticator
  3. token authenticator
  4. webseal-authenticator
Configuring Custom Authenticators
As I mentioned earlier, one aspect on which the correct authenticator is picked, is the priority. Either we can set the priotity in code level or in configuration. If you later need to change the priority of your custom authenticator in [carbon_home]/reository/conf/advanced/authenticator.xml (in Carbon 3.2.0 or higher) or [carbon_home]/repository/conf/carbon.xml (in earlier versions).

Sample configuration is given below:


I have attached here a sample back-end authenticator written for Carbon 3.1.0. The implementation will be same for 3.2.0 as well.
It customizes the login method for creating a role per each user at the user log in.
Drop the bundle found in the target (org.wso2.carbon.sample.authenticator) into [carbon_home]/repository/components/dropins folder and start the server. 
Try to log into the management console, you will notice that custom lines are printed on the backend server log which indicates that our custom authenticator has been picked.

You will need to write a FE custom authenticator also in the same way in order to fully customize the authentication logic.

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.

Wednesday, August 17, 2011

Security Challenges in Cloud

What is Cloud Computing..

Cloud computing is an evolving paradigm that provides hardware infrastructure, platform and software as services readily available on demand over the Internet which users can consume pay-per-use basis.

It is also called Utility-Oriented computing where computer resources are made available for consumption like other utilities such as electricity and telephone. This cuts the initial costs and maintenance overhead of IT infrastructure resources to a greater extent and facilitates businesses to go on production in the market in less time.

Hence more and more businesses are moving into cloud for accommodating high load during peak times in order to meet the QoS of their customers.

Why Security in Cloud Computing..

As described above, cloud computing  model encourages businesses/e-science to rely on third party services  for their computing infrastructure and software requirements. Hence trust towards cloud service providers is fundamental  when moving into the cloud.

Privacy and security are major concerns of cloud consumers when hosting their important data, applications and performing critical operations/transactions  in  the cloud. On the other hand, it is a major challenge for cloud providers to meet security, trust and privacy requirements of their clients.

Cloud is like a double edged sward because in the same way it provides as much resources as required by businesses/e-sciences on demand, it is also available for attackers to launch large scale attacks on data and applications hosted on cloud. Therefore it is important to have paid attention to security, trust and privacy challenges from the design level itself of the cloud services.

What are the security challenges in Cloud..

We can identify three main layers as follows in the cloud computing stack each having their own security challenges.
  • Infrastructure as a service - provides network, hardware and storage as a service
  • Platform as a service - provides both system level middleware such as hypervisors, virtual machines, guest OS's and user level middleware such as Mashups, workflows, web services stacks implementations and application servers to host cloud apps.
  • Software as a service - provides cloud applications such as social computing, e-mail services etc.
Following can be identified as some of the main security challenges among many others, which are encountered in above mentioned cloud computing stack:

Physical security - Data centers where important/sensitive data of millions of users is hosted, need to be protected with strong security mechanisms such as multi-factor authentications before accessing data center floors, system and network control and security monitoring. Rules and regulations in the region/country where the data centers are hosted, also play a key role and has major impact on this aspect.

Availability - this is important in security because the trusted service being not available, opens doors to launch phishing attacks. Since cloud services are utilized by thousands of consumers with various loads, it is critical to ensure minimum downtime by the means of load balancing and auto-scaling in the face of high loads.

Data isolation and protection - in a multi-tenanted environment where large number of tenants host their important data in cloud providers' site, it is important to provide the expected level of data isolation and also expected level of encryption (whether it is at disk level, directory level, file level or application level) to avoid data breaches.

Execution isolation, logic isolation - specially in multi-tenanted PaaS environments where number of applications from different cloud consumers/SaaS providers are hosted, execution and logic isolation is a required aspect which should be facilitated from the architecture/design level in order to prevent vulnerabilities of one tenant's application affecting other tenants' application/data. 

Malicious code - Once again in PaaS (user level middleware) environments, where custom code of different tenants are allowed to be executed, it is important to prevent access to privileged operations in the user level middleware in order to protect entire system from malicious code and security breaches.

Identity Management - this is a challenge spread across four main areas as:
  • Authentication - cloud users need to be authenticated using strong identity factors to avoid brute force attacks and also needs to support federated identity management to avoid same user identity being stored in multiple cloud environments.
  • Authorization - needs to have centrally governed,  flexible, scalable and fine grained access management solutions.
  • Auditing - all security related events needs to be recorded and securely archived while ensuring integrity and confidentiality of the logs in order to track accountability and detect security policy violations.
  • Administration - standard and secured user account provisioning mechanism should be supported to cater the identity management requirements when moving from enterprise-to-cloud and cloud-to-cloud.
Cloud providers at any layer of the cloud computing stack needs to identify the security challenges/requirements and take necessary measures to overcome/facilitate them in order to meet the consumers' QoS expectations and establish trust with their consumers.

Tuesday, August 16, 2011

Fine grained authorization to RESTful services with XACML - Part II

We are going to look into the XACML policy and the XACML requests involved in the sample that I described in Part I, and analyze how the authorization decisions we observed in Part I were derived.

Let me state in english the authorization policy that we needed to enforce...
Allow access to perform all - POST, PUT ,GET and DELETE operations of the service only to admin users (since three methods do modifications in the system) and allow access to GET method to all the users in 'admin' and 'everyone' roles..

XACML Policy
Following is how XACML defines above mentioned authorization policy: (you can obtain it from here as well)

Well.. it might not be convincing in the first glance. Let us look at it step by step.

  1.  Policy is consisted of a target and a set of rules. Information in the target element is used by the PDP to pick a matching policy for an incoming authorization request, out of many policies available in the PDP. Then the request is evaluated against the set of rules defined in the policy.
In our case, above policy will be picked for any request whose "Subject" element matches the regexp : http://localhost:9766/services/RestService

  2.  Above XACML policy has three rules defined: 
      • "admin_allow_rule": defines which operations to resources are allowed to users in admin role.
      • "everyone_allow_rule": defines which operations to resources are allowed to users in everyone role (In carbon products, all the users are belonged to everyone role by default.).
      • "deny-rule": defines that requests come in any other criteria should be denied.
       2.  Rule combining algorithm used in the above policy is "first-applicable" which means that the first rule that evaluates to true will take effect and others will be ignored.

       3.  A rule is consisted of a target and a set of conditions. Rule element has two parameters: rule-id and effect-which specifies the outcome of the rule if given conditions are met and the target is matched.
    Rule conditions are useful when the target can not express the constraints adequately.
    In our policy, the two rules have targets specifying for which subject type the rule should be evaluated for. In the first rule, its the subject of role type 'admin' and for the second rule, it is the subject of role type 'everyone'.

    There is a series of blog posts by Prabath which will help you to master on writting XACML policies.

    XACML requests
    Now let us have a look at the XACML requests sent by PEP (ESB) to the PDP (IS)
    for the three requests sent by the client to access the back-end service.
    (You can observe the XACML request at the Idenetity Server back-end if you enable debug level logs for the Entitlement Service in IS.)

    A XACML request is consisted of:
    • Subject - defines attributes of the entity who tries to access the resource
    • Resource - defines the resource that is being accessed 
    • Action - the action that is being performed on the resource.

    You will be able to get a good understanding about XAML requests from the post: Anatomy of the XACML request

    1. When admin tries to add a student:
    The above request will be evaluated to true by the first rule in the above XACML policy since it matches the target and the conditions.

    2. When non-admin user tries to get student:
    Above request will be evaluated to by the second rule defined in the policy which allows all the users in admin and everyone role to allow access to GET operation.

    3. When non-admin user tries to update student:
    Above request will be denied since there is no any rule defined with the effect of 'permit' that matches it. Hence it will be denied by the default deny rule.

    Well..from the series of these two blog posts, I hope you got an understanding about how to build up an access management solution with XACML using WSO2 product stack and also about how the XACML policies, requests involve in taking authorization decisions.

    I would like to thank Prabath, Thilina, Asela and Amila Suriarachchi for the help in gaining knowledge in the area and getting the end to end sample working.

    Monday, August 15, 2011

    Fine grained authorization to RESTful services with XACML - Part I

    XACML - extensible access control markup language, provides an flexible, fine grained and scalable way of achieving policy based access control.

    WSO2 carbon product platform provides a fine grained access management solution with Policy Based Access Control (PBAC) based on XACML.

    In this post, I will walk you through a sample scenario on how to build up a solution to control access to a RESTful service with XACML using WSO2 product stack. 
    You can find an article on access management with XACML for a SOAP based service from here. We have some additional steps to perform in order to get XACML authorization working for RESTful services.

    We have a RESTful back-end service which exposes methods to manage student entries with HTTP verbs: GET,  POST, PUT and DELETE. We need to allow access to perform POST, PUT and DELETE operations of the service only to admin users (since those methods do modifications in the system) and allow access to GET method to all the other users.

    One key aspect of PBAC solutions based on XACML is the reference architecture which defines key components involve in access management according to their responsibility. Following are the logical components present in our setup:

    1.PAP - Policy Administration Point - WSO2 Identity Server - this is where XACML authorization policies are governed.

    2.PEP - (Policy Enforcement Point) - WSO2 ESB - this is where users' requests to services are intercepted and the access is allowed or denied according to the decision given by the PDP.

    3.PDP - (Policy Decision Point) - WSO2 Identity Server - this is where authorization decision is taken by evaluating the XACML authorization request sent by PEP, against a matching  XACML policy found in PAP.

    4. PIP - Policy Information Point - User store of WSO2 Identity Server - this is from where required attributes of the user who is trying to access the resource will be read by PDP in order to take the authorization decision.

    Although there are four logical components listed above, we will have only two physical components in our access management solution since WSO2 Identity Server will play the roles of PAP, PDP and PIP as shown below.
                                           Image 1: Solution Architecture

    Setting up the scenario & the solution:

    1. Hosting the back-end service: 
    • You can obtain the source and archive of the REST service from here. If you want to learn more about RESTful services in Axis2, this article is a good reference.
    • We will host this back-end service in WSO2 App Server. (You can also host it in axis2 webapp deployed in Apache Tomcat as well.) Download and run the App Server.
    • Upload RestService.aar to the app server by logging into its management console through the browser (https://localhost:9443/carbon/). You may need to wait for few minutes to see the service in the services list after uploading. 
    • Click on the RestService and obtain its url. e.g: http://localhost:9766/services/RestService
                            Image 2: Hosting the service in Application Server.

    2. Setting up WSO2 Identity Server (IS):
    This plays the roles of PAP,PDP and PIP in our solution as mentioned above.
    • Download Identity Server, change its Ports.Offset to 1 in carbon.xml found in [IS_HOME]/repository/conf and run the server.
    • Login to management console (https://localhost:9444/carbon/) as admin.
    • Create a user called 'hasini' who will be belonged to 'everyone' role by default. And give 'login' permission to 'everyone' role.
    • Now download and import this XACML policy into IS through Entitlement->Administration->Import New Entitlement Policy as shown below. Once imported, 'enable' the policy from the icon in front of the policy name.
                                    Image 3: Policy administration in Identity Server

    3. Setting up WSO2 ESB as PEP:
    • Download ESB and change its port offset to 2, as we did with IS above.
    • We need to use the user store of IS, as the central user store of ESB as well. Therefore change user-mgt.xml of ESB which is found in [ESB_HOME] /repository/conf to point to the user store of IS by setting the following property:
    • Give 'login' permission to 'everyone' role.
    • Now we need to configure a secured proxy service with entitlement mediator in its 'in sequence' in order to intercept and authorize REST requests sent to our back-end service.
    • Obtain the proxy service configuration from here and add it to the ESB configuration through Manage->Service Bus->Source View as shown below.
                                       Image 4: Configuring ESB proxy service

    Remarks On Proxy Service:
    Please note the following configuration of the proxy service as shown abovev which authenticates the user, obtains the authorization decision by communicating with IS and allows/denies the access to back end service.
    1. Proxy service is secured with User Name Token so that only the authenticated users will be able to access it.
    2. Endpoint is set to the back-end RESTful service.
    3. In sequence has three property mediators which are configured to specifically handle RESTful invocations.
    4. There is an entitlement mediator which communicates with EntitlementService in IS for obtaining authorization decisions.
    5. Header mediator removes the security header before sending the request to back-end service.
    Running the client:
    Let us have a look at our sample client code  (which you can download from here) which invokes the RESTful back end service which is secured by ESB proxy service. 
    Here I need to highlight the REST way of invoking the proxy service when it is secured with User Name Token security policy.
    //login as admin
                HttpTransportProperties.Authenticator authenticator = new HttpTransportProperties.Authenticator();
                //enable REST when invoking the service
                stub._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, authenticator);
                stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE);

    Following is how we perform the subsequent operations on the service stub.
    //create student by admin
                System.out.println("Creating student by admin...");
                Student student = new Student();
                student.setSubjects(new String[]{"maths", "science"});
                //login as non admin user.
                stub._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, authenticator);
                stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE);
                //get student by non admin user
                System.out.println("Getting student by non admin user..");
                StudentName studentName = new StudentName();
                Student result = stub.get(studentName);
                System.out.println("Student's age="+result.getAge()+" successfully read by non admin user..");
                //update student by non admin user
                System.out.println("Updating student by non admin user..");
                result.setSubjects(new String[]{"english", "history"});

    As you can see, we perform add student operation as admin user and get student and update student operations as a non admin user. According to the scenario we mentioned at the very beginning, only the first two operations should be successful and the third operations should be denied.
    Since the first and the third operation are asynchronous, we can not observer whether operation was allowed or denied from client side. To observe that, you need to enable debug level log for entitlement mediator in ESB.

    Steps for running the client:
    • Add the following folders to the class path of the sample: [ESB_HOME]/repository/components/plugins, [ESB_HOME]/lib/api
    • Change the keystore path in line 40 of TestRestServiceStub to the wso2carbon.jks keystore of ESB which is in [ESB_HOME]/repository/resources/security
    When you run the client, you will observe that add student operation and get student operation will pass and the update student operation will be denied (please refer to ESB logs) based on  the user who invokes the operation and the defined XACML policy.

    In this way, you can achieve fine grained access control with PBAC solutions with XACML. Although this sample incorporates users' role as the attribute to define access control rules, you can use other attributes as well and manage access to your enterprise resources in a fine grained manner.

    I believe you got an overall idea of how to build up an access management solution with XACML using WSO2 products stack.

    What's Next...
    In Pat-II of this, I will take you through the XACML policy used in this sample and the XACML requests sent to PDP in order to discuss how authorization decisions are taken.

    Thanks for reading this post and have a good day...!