Sunday, December 18, 2011

"Entitlement Service" - XACML PDP as a web service

Being part of WSO2 middleware platform, XACML PDP (Policy Decision Point) functionality in Identity Server is exposed as a web service called 'Entitlement Service' whose implementation can be found here.

Describing XACML reference architecture and XACML policy language is out of the scope of this post and you can refer to my previous post to get an overall idea about an example solution based on XACML.

A PEP (Policy Enforcement Point) can consume the EntitlementService through a SOAP based client and invoke its "getDecision" method to obtain the authorization decision for a given XACML authorization request. Such a PEP exists in WSO2 ESB as a mediator called EntitlementMediator.

In this post, I will take you through a simple java client which acts as a PEP.

1) First of all, lets look at the communication flow between a PEP and PDP of IS with SOAP based implementation:

In the above diagram, in addition to the Entitlement Service, there is also AuthenticationAdmin service comes into play in between client and the EntitlementService.

What does it do?
It authenticates the clients against the user store before the client is capable of invoking an AdminService. Any request coming to the back end server is hit by the Authentication Handler (which is an axis2 handler) and if that request is for an AdminService, handler checks whether the request is authenticated.

Now comes the question, what is an AdminService?
Well.. In WSO2 Carbon, we have a concept called AdminService whose charaterisitcs are as follows:
  • Can only be invoked by an authenticated user in the system.
  • Exposed over secure transport.
Entitlement Service is exposed as an AdminService since it exposes the functionality of obtaining authorization decision and since it communicates security sensitive information.

You can read more about carbon authentication framework from here.

2) Before looking at the PEP client code, lets setup the PDP of IS with a sample XACML policy.

Start the identity server->login to management console->access Entitlement -> Administration -> Add New Entitlement Policy

WSO2 Identity Server has a rich XACML UI editor through which you can configure XACML policies easily.

Our XACML policy will enforce following rule: Read access to the resource called 'ABCResource' is only allowed to users belonged to admin role and all the other request to this rersource will be denied.

Please follow the following screen shots to compose the policy through UI editor (If the images are not clear, please click on them to view the enlarged version).

i). Here we define policy name, rule combining algorithm and the policy target.

ii). Next we define the two rules with 'Permit' effect for admin users and 'Deny' effect for all other requests.

iii) We can evaluate the XACML policy by sending a mock XACML request from the 'TryIt' tool provided by the Identity Server as shown below.

In the above request, a user in role 'eng' is trying to read the resource 'ABCResource' which should result in deny effect when evalated against the defined XACML policy.

iv). You can also obtain the exact XACML request created by the above 'TryIt' tool by selecting "Create Request" which you can observe as below.

3) Java client as PEP
You can download the source code of the SOAP based client which can act as a PEP and consume Entitlement Service - PDP of IS, to obtain the authorization decisions.
(Here I have only illustrated how to consume PDP, you can continue implementing a complete PEP who tracks access requests from users, composes XACML requests for those resource access requests, gets them authorized by PDP and responds to users accordingly.)

Lets go through the important code segments of the client code.
(Please note that I have trimmed off some of the code segments for the sake of brevity. Please use full source code in the above link.)
public class EntitlementClient {

    private static String serverUrl = "https://localhost:9443/services/";
    //some code goes here

    //sample XACML request captured from TryIt tool of IdentityServer. 
    private static String sampleRequest = "
                                            //actual request is removed for brevity

    public static void main(String[] args) {

        try {

            //set trust store properties required in SSL communication.
            System.setProperty("", "wso2carbon");
            //initialize authentication admin stub
            EntitlementClient remoteEntitlementClient = new EntitlementClient();

            //login using authentication admin stub providing valid credentials
            remoteEntitlementClient.login("admin", "admin");

            //initialize entitlement service stub with obtained auth cookie

            //invoke EntitlementService by passing the XACML request and obtain the authorization decision
            String decision = entitlementServiceClient.getDecision(sampleRequest);
            //print the authorization decision

line07: hard coded XACML request which will be given as input when invoking Entitlement Service. This can be obtained from TryIt tool as described in section 2.iv

line16,18: Being AdminServices, AuthenticationAdmin and Entitlement Service are exposed over HTTPS. So here we need to set SSL system properties. Please change them to suit your environment.

line21-30: You can understand by relating the comments in the code with the communication flow illustrated in secion 1.

Setting up and running the client:
In order to run the client, please make sure you have included the two paths: "[IS_home]/lib/api" and "[IS_home]/repository/components/plugins" into your classpath.

So what?
I hope you got an idea about how PDP in IS is exposed and how to write a custom PEP to consume it and about the communication flow between the two.
In fact this is written to build up the foundation for another post I am going to write in the near future. Stay tuned.. and Have a nice day..!!

Saturday, December 10, 2011

Installing a new keystore into WSO2 Carbon based products.

Applies to: WSO2 Carbon 3.2.0 based products.

WSO2 carbon products are shipped with a default keystore named wso2carbon.jks which resides in [CARBON_HOME]/repository/resources/security directory. This is the keystore with private/public key pair which is used for encrypting sensitive information, encryption/signature purposes in WS-Security and also for communication over SSL.

It is recommended to replace this with a keystore with self signed or CA signed certificates when the products are deployed in production environments. Because wso2carbon.jks is available with open source WSO2 products and anyone can have access to the private key of the default keystore.

Following is a step by step guide to achieve the $subject.

1). Create a new keystore with a private and public key pair using keytool utility that ships with JDK installation.

Make sure you have installed Java and set your PATH env variable to [i.e : JAVA_HOME\bin]
Go to [CARBON_HOME]/repository/resources/security directory and execute the following command:
keytool -genkey -alias mycert -keyalg RSA -keysize 1024 -keypass mypkpassword -keystore mykeystore.jks -storepass mypkpassword

Note: With tomcat SSL configuration, we need to have both keystore password and private key password the same.

You will be prompted to provide necessary information to construct the DN of the certificate.
Once you provide the information, a keystore file will be generated inside the same directory above, with:
keystore name=mykeystore.jks
alias of the public certificate=mycert
private key password & keystore password=mypkpassword

You can view the contents of the generated keystore from the following command:
keytool -list -v -keystore mykeystore.jks -storepass mypkpassword

2). Get the public certificate signed: You can either get your public certificate signed by a CA(recommended for production environment) or continue using the above generated self signed certificate (for local testing purposes).

Please refer to:
for a step by step guide on how to get your public certificate signed by a CA and importing CA certs into your keystore. Here, in this guide I will continue to use the self signed certificate.

3). Export your public certificate from the keystore and import it into the trust store.

In SSL handshake, client side needs to verify the certificate presented by the server side. For that, client usually stores the certificates it trusts, in a trust store.
Related to SSL communication of WSO2 Carbon products, this trust store is set as client-truststore.jks which resides in the same above directory as the keystore.
Therefore we need to import the new public certificate into this trust store for Front End and Back End communication of WSO2 products to be properly happened over SSL.

Export the new public certificate with following command:
keytool -export -alias mycert -keystore mykeystore.jks -storepass mypkpassword -file mycert.pem
Above will export the public certificate into a file called mycert.pem in the same directory.

Now import it into client-truststore.jks with following command:
keytool -import -alias mynewcert -file mycert.pem -keystore client-truststore.jks -storepass wso2carbon
(Password of client-truststore.jks keystore is: wso2carbon)

4). Change the configuration files:

You need to locate and change the entries in the below elements of following configuration files which resides in [carbon_home]/repository/conf to point to the new keystore as highlighted below:

i. carbon.xml (Here we specify the keystore which is used by default for encrypting sensitive information to be stored and also for encryption/signature purposes in WS-Security)

ii. mgt-transports.xml (Here we specify the keystore which contains the public certificate to be fetched when accessing Management Console over SSL for all the WSO2 products and it is the same keystore which contains the certificate used when accessing services exposed over HTTPS as well, except for WSO2 ESB.)

iii. axis2.xml (Only for WSO2 ESB) (WSO2 ESB uses different HTTPS transport sender and receiver for accessing the services exposed over HTTPS as below, and the keystore used for this purpose is specified in the following configuration)


Thursday, September 29, 2011

Integration of Oracle Directory Server as the User Store of WSO2 Identity Server

WSO2 products stack supports heterogeneous user stores ranging from JDBC based databases such as MySQL, Oracle, MS-SQL to LDAP based directory servers such as Active Directory, OpenLDAP, ApacheDS...

This post explains how to setup Oracle Directory Server (or Sun Directory Server earlier) as the user store of WSO2 Identity Server.

1. Download Oracle Directory Server Enterprise Edition that suits your Operating System from here. (I am installing on Linux.. hence selected the Zip distribution)

2. Download Identity Server from here.

3. Extract the "" distribution and locate "/ODSEE_ZIP_Distribution/" inside and copy it to a separate location which would be the installation directory (say install_dir).

4. Extract "" there and go to "dsee7/bin"

Now we are ready to create and start a Directory Server instance. I am going to follow the installation through command line .
(You can find the official installation guide from here and there are two ways of creating an instance -through directory server controller and through command line. Directory server controller way didn't work for me since it failed at registering the DCCC agent. If anyone passed that step, please share with us.)

5. Go to [install_dir]/dsee7/bin from command line and execute:
./dsadm create -p 1389 -P 1636 ../local/dsInst
Select a password for Directory Manager which we need for future operations.
You will observer following in the command line:
Choose the Directory Manager password:secret12
Confirm the Directory Manager password:secret12
Use 'dsadm start '../local/dsInst'' to start the instance

6. Start the instance:
./dsadm start /local/dsInst
Console output: Directory Server instance '/home/hasini/install_dir/dsee7/local/dsInst' started: pid=6806

7. Now we have a directory server instance running in port 1389. We need to create a root context and populate it with some sub contexts and entries for our use.
  • Let's create root as "dc=wso2,dc=org"..
    ./dsconf create-suffix -p 1389 -e dc=wso2,dc=org
 It will prompt for directory manager password which you gave at the beginning.
  • We can populate sub contexts and entries under this root, by importing a ldif file. I have created a WSO2.ldif which defines a user base, group base, admin user and admin group under the root "dc=wso2,dc=org". Download and place the file in "/dsee7/resources/ldif" directory.
  • Import the ldif file:
       ./dsconf import -p 1389 /home/hasini/install_dir/dsee7/resources/ldif/WSO2.ldif dc=wso2,dc=org
        You will be prompted to accept server certificate and for directory manager password.
        End of console output upon successful import:
        ## Import complete.  Processed 5 entries in 4 seconds. (1.25 entries/sec)
Task completed (slapd exit code: 0).

Now the directory server instance is ready for our usage and you can browse the directory tree by connecting to it through a LDAP browser such as Apache Directory Studio.

8. Provide host (localhost), port (1389) and bind DN (cn=Directory Manager), bind password (secret12) and connect Apache Directory Studio to the Oracle Directory Server instance.

9. Connecting Identity Server with Oracle Directory Server.
  • Extract the downloaded Identity Server distribution and locate the user-mgt.xml inside [IS_home]/respository/conf/user-mgt.xml
  • Comment out the existing UserStoreManager entry.
  • Uncomment the following UserStoremanager entry and edit the parameters as below:

            cn=Directory Manager
Please note edited lines: 04, 05, 06,10, 16, 17 above to integrate IS with Oracle Directory Server.
This directory server allows to create groups without an existing user. Hence line 16 parameter was set to "true".

Please note that I have connected to the directory server from IS, in read/write mode, if you want to connect in read-only mode, uncomment and change the read only LDAPUserStoreManager configuration element found in the user-mgt.xml of Identity Server.

10. Create some user entries and roles through Identity Server management console and you can browse the directory server through Apache Directory Studio and observe that they are created in directory server as below:

Thanks Prabath aiya for the request to integrating this and writing a post on it...

Tuesday, September 27, 2011

Securing request and response messages with different security policies...

One of the advantages with message level security is that it provides the granularity that we need. One example is the ability to apply different security policies to request and response messages in Web service communication, which the today's discussion is based on.

Example use case:
Let's say we have a web service called 'StudentService' which exposes the method: 'getStudent'. It gets input parameters as student id and student user name. And returns a student object with information: student age, grade and full name. 

Coming to the security requirements, let's say we need to send  the request- which contains student id and user name, confidentially and obtain the student information signed by the service to ensure integrity and non-repudiation.

Yes, we can apply a sign and encrypt policy to the service and achieve this. But wait... then we are unnecessarily encrypting the response message as well. Since encryption comes at a cost, it is good if we can apply encryption only when it is required.

How to achieve:
To achieve the above hypothetical requirement, we can use the ability to apply policies to different policy subjects in the binding hierarchy as described in this article by Nandana.

With that, we can apply Encrypt Only policy to the request message and Sign Only policy to the response message of 'getStudent' operation.

For this, we can use WSO2 AppServer which is powered by Web Services/SOAP/WSDL engine: Axis2 and Rampart -the security module of Axis2, as described below..

Walk through:
I will demonstrate how to achieve the above with a sample. 

Resources: You can find all the resources we will use in this sample -including source code of service & client, policies, wsdl, captured request and response and service archive in the resources directory uploaded.

1. Service
Following is the simple logic of our hypothetical StudentService's get student method:
public class StudentService {

    public Student getStudent(String studentName, String studentId){
        Student student = null;
            student = new Student();
            student.setFullName("Alice Power");
        return student;
2. Policy
Following is the services.xml of the web service where we have embedded the security policies for in and out messages. 
I have shorten the services.xml for the brevity but you can find the full version in the resources directory.




Please note the following important lines wrt above services.xml
line 03: Rampart module is engaged to the service to process security in the in and out flows of the service.
line 05-line22: defines the first policy attachment -with message-in security policy.
line 07 & 08: defines policy subjects as operation:getStudent/in of soap11  and soap 12 binding.
line 10-21: defines the security policy applies to those policy subjects, which is Encrypt Only security policy.
line 16-19: defines the rampart configuration as a policy assertion in the security policy. Note that I have used the default keystore shipped with AppServer for cryptographic configurations.
line 23-line 40: defines the second policy attachment -with message-out security policy.
Same as above you will notice the same structure where Sign Only security policy is applied to policy subjects -operation:getStudent/out of soap11 and soap12 bindings.
line 43-47: defines service specific stuff like service class, operation name and message receiver.

Ok... we are done with the service now.

I have provided a build.xml from which you can create the axis2 service archive of the 'Student Service'. Make sure you have installed apache ant and run ant command from the directory where build.xml resides in the provided resources.

Download and run WSO2 AppServer and host this service archive.

Note that, though I'va used WSO2 AppServer for the convenience, you can also host this service in Apache Axis2 server with rampart configurations properly set in the policy above, according to your custom keystore information.

3. Generated WSDL
Now try to access the service wsdl and you will notice that security policies are attached to the relevant points that we defined in the services.xml above.

Here I will include only the parts of the wsdl, and you can find the complete wsdl in the resources directory.

At the beginning of the wsdl, security policies are defined inside "wsdl:definitions" as shown below. Each policy definition contains "wsu:Id" attribute which is used to reference policy inside the wsdl.

In the "wsdl:binding" section, correct policy is attached to the corresponding policy attachment point (as we defined in the services.xml), using "wsp:PolicyReference" element with "wsu:Id" attribute defined above. Following listing extracted from the wsdl shows this.


4. Client
We are done analyzing the server side... Let's see how to write a client who understands and supports the security requirements communicated by the service.
Following is the code listing for the client.. too long, yes I know. Let me take you through the important steps of it as below:

import org.apache.axis2.AxisFault;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.neethi.Policy;
import org.apache.neethi.PolicyEngine;
import org.apache.rampart.RampartMessageData;
import org.apache.rampart.policy.model.CryptoConfig;
import org.apache.rampart.policy.model.RampartConfig;

import java.util.Properties;

public class Client {
    private static final String RESOURCES_DIR = "src" + File.separator + "main" + File.separator +
                                                "resources" + File.separator;
    private static final String MODULES_DIR = RESOURCES_DIR + "modules";
    private static final String KEYSTORE_PATH = RESOURCES_DIR + "keystore" + File.separator + "wso2carbon.jks";
    private static final String POLICY_DIR_PATH = RESOURCES_DIR + "policy" + File.separator;
    private static final String IN_POLICY_PATH = POLICY_DIR_PATH + "in_sec_policy.xml";
    private static final String OUT_POLICY_PATH = POLICY_DIR_PATH + "out_sec_policy.xml";
    private static final String END_POINT_ADDR = "";

    public static void main(String[] args) {

        try {
            //create configuration context
            ConfigurationContext ctx =
                    ConfigurationContextFactory.createConfigurationContextFromFileSystem(MODULES_DIR, null);

            //create service client
            ServiceClient serClient = new ServiceClient(ctx, null);

            //engage modules

            //load in/out policies
            Policy in_sec_policy = loadPolicy(IN_POLICY_PATH);
            Policy out_sec_policy = loadPolicy(OUT_POLICY_PATH);

            //add rampart config assertion to the ws-sec policies
            RampartConfig rampartConfigAssretion = buildRampartConfig();

            //set in/out security policies in client opts
            serClient.getOptions().setProperty(RampartMessageData.KEY_RAMPART_IN_POLICY, in_sec_policy);
            serClient.getOptions().setProperty(RampartMessageData.KEY_RAMPART_OUT_POLICY, out_sec_policy);

            //set action
            serClient.getOptions().setTo(new EndpointReference(END_POINT_ADDR));

            //invoke the service
            OMElement response = serClient.sendReceive(getPayLoad());

        } catch (AxisFault axisFault) {
            axisFault.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
        } catch (FileNotFoundException e) {
            e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
        } catch (XMLStreamException e) {
            e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.


    private static Policy loadPolicy(String filePath)
            throws XMLStreamException, FileNotFoundException {
        StAXOMBuilder builder = new StAXOMBuilder(filePath);
        return PolicyEngine.getPolicy(builder.getDocumentElement());


    private static RampartConfig buildRampartConfig() {
        RampartConfig rampartConfig = new RampartConfig();
        Properties cryptoProperties = new Properties();
        cryptoProperties.put("", "JKS");
        cryptoProperties.put("", KEYSTORE_PATH);
        cryptoProperties.put("", "wso2carbon");

        CryptoConfig cryptoConfig = new CryptoConfig();


        return rampartConfig;


     * This is the request we need to send
     * * 
     * alice* 
     * 123ABC* *
     * @return
    private static OMElement getPayLoad() {
        OMFactory omFactory = OMAbstractFactory.getOMFactory();
        OMNamespace namespace = omFactory.createOMNamespace("", "p");
        OMElement parentElement = omFactory.createOMElement("getStudent", namespace);
        OMElement child1 = omFactory.createOMElement("studentName", namespace);
        OMElement child2 = omFactory.createOMElement("studentId", namespace);

        return parentElement;


line 46: engages rampart to service client which processes security of the in-coming and out-going messages.
line 49 & 50: loads in-policy and out-policy from file. Note that in-policy of server side applies to out-policy of client side and out-policy of server side applies to in-policy of client side. I have included client side policy files in the resources directory.
line 53-55: programetically inserts rampart configurations as policy assertions to both in-policy and out-policy.
line 58 & 59: attaches client side in-security policy and out-security policy to the axis2 service client, through client options.
line 62-66: creates the request and invokes the 'StudentService'.

How to run the client:
  • To run the client from the provided client source, you need to set necessary axis2 and rampart libraries in your classpath.
  • If you use WSO2 AppServer to host the service, you can easily run ant command inside [AppServer_home]/bin which will copy necessary libraries into [AppServer_home]/repository/lib.
  • Add [AppServer_home]/repository/lib & [AppServer_home]/lib/endorsed folders into the classpath.
  • You can point to the necessary libraries shipped with Axis2 and Rampart distributions as well -not necessarily need AppServer.
  • Run the client -et VoilĂ , if your client prints the received response correctly, you have invokes the secured service successfully :).
But we can't be happy until we confirm that the messages exchanged between client and the server are secured in the way we expected.

5. Request & Response Messages
We can monitor request and response messages using tcpmon -how to use tcpmon is out of the scope of this post...
Following are SOAP Body of 1. request and 2. response messages that I captured during client-service communication. Entire messages are included inside resources directory.

1. Request SOAP Body:

Entire SOAP body is encrypted adhering to the in-security policy of the service.

2. Response SOAP Body:

                Alice Power
Here the response SOAP body is in plain text, yet the message is signed. You can gain more information about message signature by referring to the SOAP header of the response message which is included in the resources.

Alright.. So I hope you got an understanding about achieving message level security with WS-Security & Rampart by going through this end to end sample of applying different security policies to in,out messages of a web service.

I would like to thank Manjula & Nandana from whom I initially got to know about the $subject.
Thanks to you for patience reading and have a good day....!!!

Sunday, September 18, 2011

How to use pre-compiled JSPs in a webapp with tomcat 7

Recently I had the following requirement:

I had a webapp that has some jsp files which directly call some methods in some libraries. But those libraries are in a sandbox environment secured by Java Security Manager. Therefore only the calls that come from classes that are signed by a particular key, are allowed to be executed.

My webapp was not working until I guarantee the sandbox environment that the method calls are coming from a signed source.

The solution for the above problem is consisted with following steps:
1. Pre-compile jsp files.
2. Package the pre compiled jsp files into a jar file.
3. Sign the jar file using the appropriate key.
4. Package the signed jar file in the WEB-INF/lib folder of the webapp
5. Remove all the jsp files from the webapp.

Walk through:
jspc-maven-plugin comes to the rescue in this occasion.

I will walk you through how to pre-compile jsp files of the example webapp of WSO2 AppServer by integrating pre-compiling step into the maven pom.xml.

Following is the complete pom.xml file with modifications to include the steps of pre-compiling and packaging the jsp files.


    WSO2 AS - Example webapp






Following is what is done... please follow with the line numbers:

1. line 73 introduces jspc-maven-plugin to the pom.xml file.
This will compile jsp files to servlets and then into .class files which include the byte code. These can be found under "target/jsp-source" once the maven build succeeds.

2. Note the 'Configuration' element from line 83 to 93:
    - inputwebxml: specify where the original web.xml file of the webapp resides. jspc-maven-plugin will detect that and update the servlet mappings according to the compiled jsp files and create a new file called "jspweb.xml" in the target folder, which you need to package with the webapp instead of the original web.xml.
    - sources: specify where the jsp files resides in your webapp .

3. Then comes the trick: there is no jspc-maven-compiler plugin for tomcat 7 yet. So we need to use tomcat 6 version of it by removing the incompatibilities. This is what is done from line 97 to line 147.

4. As in line 190, you need to specify the new web.xml created by this plugin, to be included in the .war file of the webapp.

5. Now the step 1 mentioned in the above 'solution' section is achieved and the files obtained by pre-compiling jsp files are available in 'target/jsp-source' folder.

Now, in order to complete steps from 2-4 in the above 'solution', you may need to write a ant build.xml file or can integrate those steps into the pom.xml file itself. I did it through a ant build.xml file.

You can use jarsigner tool that comes with JDK installation  to sign the jar file containing the compiled jsps, as described here.

Once you include the compiled jsps in a jar file in the webapp, you need to remove the original jsp files from the webapp or avoid packaging them in the .war file because if they are included, those will be compiled and used by the servlet container instead of the already pre-compiled ones.

In my case, I had to remove the jsp files packaged inside web-inf/classes/carbon
and web-inf/classes/jsp/carbon of the webapp.

Hope this helps...

Saturday, September 17, 2011

3rd & the last day...

Just like every good thing comes to an end, WSO2Con 2011 also ended up in style and with a big success story on 15th Sept.
Here are the highlights of the day...
1) We were privileged to listen to Gregor Hohpe on "Enterprise Integration Patterns: Past, Present and Future". He is the author of the book: 'Enterprise Integration Patterns' which has become the De facto standard for EIP and ESB.
-  Messaging has been evolving from export-->import to centralized database to RPC to asynchronous messaging
-  Good side of asynchronous model:
  • Asynchrony
  • reliable - can resend messages
  • can introduce intermediaries independently
  • throughput over latency
  • throttling
- A broader view of messaging patterns with Messaging Patterns Language
  • transport messages ==> channel patterns
  • designing messages ==> message patterns
  • route messages ==> routing patterns
  • transform messages ==> transformation patterns
  • produce & consume messages ==> endpoint patterns
  • and more...
- How integration patterns expanded:
  •  by going deep on thinking about and having room for family of patterns and projecting on the platform
  • by going broad on considering other patterns such as message patterns
- Enterprise integration aspects: messaging, messages, conversations, processes, events

- Gregor also unveiled the fact that open model really works & help carving a good book where you can get lot of input from the community -good tip for authors. He also mentioned that he is working on a Conversation pattern language book which will be a good news for enterprise integration architects.

2) Maria Belkina did a very interesting session on how WSO2 products stack is being used to realize the goal of Electronic Russia -in the project "Integration Infrastructure Middleware (IIM)". It was amazing to see how well the products have being integrated in the project.
- Currently WSO2 ESB, Governance Registry & BAM are in action.. planning to use Identity Server for Single Sign On
- Reasons to select: flexible, robust, admin UI can be easily localized, easy to configure etc..

3) Last but not least, an interesting and inspiring talk has been scheduled towards the end of the conference by Samisa Abeysinghe on "Engineering to take over the world". He very nicely presented the home grown wisdom of leadership, operational model of WSO2 which has made its way to take over the world, competeing head on with leaders in the industry with in 5 years. There is a nice post written by one of my friends dedicated to this talk which you can refer for more details..

With above and many more interesting sessions, I would say One amazing team marked the successful  end of a wonderful conference WSO2Con 2011 which was a great source of knowledge and inspiration...

Friday, September 16, 2011

Brain storming day on SOA and Clouds

WSO2Con2011 marked its second day with greater success..

I got the chance to witness some great keynotes, tech talks and case studies on WSO2 products from different corners of the world that helped me to enhance and expand the boundaries of my knowledge and thinking.

Here I am going to note down highlights of some of the sessions that I attended...

1) Distinguished architect of eBay -Sastri Malladi discussed how/why SOA is good for your business taking an example on how eBay adopted SOA.

- Fun facts about eBay: 97 million active users, 2 billion photos, $2000 worth of goods exchanged per second, 40 billion API calls per month, > 100 billion SQL transactions executions per day..
Above implies Sastry has more than enough credibility to talk on how/why SOA for your business..

- Important note on perception about services is.. services is not just technology, it is also includes processes and people

- SOA enables following and more:
  • business agility - faster time to market, quicker responses to changes & easy integration with partners..
  • innovation - internal and external innovation
  • operational excellence -reduced cost of new feature development, reduced cost failure etc..
- According to him, typical steps on service orienting a business:
  1. do domain modelling
  2. decompose domains into components -(intersection between domains should be zero)
  3. owners and architects to domains
  4. central vs. decentral governance
  5. business, technical alignment
  6. pick correct tools
- One important note he added for solution architects/designers "..need to have the bigger picture from the beginning..."

- Continuing with the case study about eBay SOA adaption..
  • eBay exposed service API from early days of 2001
  • technology stack is a combination of home grown, commercial & open source software
  • No proprietary.. everything used are open standards..
  • evaluated many products & selected WSO2 ESB ("it rocks" in Sastry's own words..)
If you are more interested, you can read complete eBay case study

2) Interesting and rich tech talk on cloud & WSO2 Stratos followed by an attention grabbing live demo on WSO2 StratosLive were conducted by Afkham Azeez and Shankar (who are the Master architect and Master builder of Stratos, StratosLive respectively according to Samisa's blog...).

- Audience was mesmerized and entertained when the Facebook app hosted on StratosLive App Server was demoed by Shankar. (You can also try it now from the given link :-) )

3) Two interesting user/customer stories or rather case studies were presented by Nelson Raimond -Open Source Adoption in a Mexican Bank and Dmitry Lukyanov -WSO2 in Action in Alfa Bank. Rather than me blogging with my memory, let me quote some of the live tweets made by the audience in the middle of these two sessions.

If you are interested, refer to Alfa Bank case study for more details.

4) Then came the much awaited session, "Security in Practice" by Prabath Siriwardena. Many were excited about his session, knowing he is a master presenter and an expert in security.
Fulfilling everyone's expectations, he delivered a great tech talk on Security in a way that everyone understands.
One of the messages conveyed is: in-spite of all the jargon in Security space like OAuth,OpenID,SSO,STS,XACML etc.. which scare away people, if you get the security concepts right, it is easy to apply security in practice selecting the right technology at the right place.

Following is the slide deck that he presented, which he has shared on slide share.
The second day of WSO2Con 2011 was really a success with lots of brain storming sessions on SOA, Clouds and case studies.
Going in her own way, WSO2 organized a musical jam session at the end of the day to entertain the participants which also demonstrated that WSO2ers are not only techies or geeks but they are singers and artists as well..

Tuesday, September 13, 2011

September 13th..

September 13th - yes, yesterday was a day to remember for couple of reasons.. First, I completed one year in the industry after graduating. Time has flied so fast and looking back, I consider myself to be lucky to have joined one amazing company for my first job and have worked with an amazing set of people while learning and contributing to the open source community.

Second - it was the opening day of one remarkable event - yes, it is WSO2Con2011. It was my first experience in attending an international IT conference.  I am sure it was a very fruitful & memorable one for all the attendees with priceless knowledge and experience gained. 

Here I will sketch some notes on three of the sessions that I attended.

After the grand opening of the event owing to Sri Lankan traditions, we listened to founder & CEO-Dr. Sanjiva Weerawarana's welcome speech which was inspiring.

Titling it as - 'Causing troubles!', he gave a complete overview of WSO2 with related to history, technology, business, culture, people and Sri Lanka. Being a hard core technology company which was started with the vision of rethinking what middleware is, it has got its own unique features which powered it to compete head on with many leaders in the industry.

Self questioning & reinventing always, open model of operating, being driven by meritocracy, respecting to personal vision of self driven people, dedication and everyday learning are few out of the many that he mentioned - which has made WSO2 to go a long way with in 5 years.

He concluded the session with a nice quote from Mahathma Gandhi - "First they ignore you, then they laugh at you, then they fight you, then you win."

1st tech talk of track 1 after lunch was on ESB. Hiranya Jayathilake has titled it as - Swiss Army Knife of SOA.
EAI (Enterprise Application Integration) is one of the toughest problem that an architect would face. He explained how ESB comes to rescue in EAI and how to distinguish a good ESB from just ESB by looking for the support for various transports, QoS features and integration patterns. 

Although it is true that ESB is the swiss army knife of SOA- by providing various set of tools for different purposes, architects should avoid the myths regarding the ESB - such as ESB is the silver bullet that solves all the problems, it is the shortcut for achieving SOA etc. Rather, ESB is only a key enabler for SOA and the architects should select the right tool for the right task.

Then WSO2 ESB was explained in detail with regard to its functional components, messaging model with pipe/filter pattern achieved through mediators and sequences, features and sample use cases.

I attended track 2 for the second tech talk since the abstract of that case study was of interest to me. 
This case study was presented by Andreas Wichmann of T-Systems on how WSO2 product stack is integrated in Connected-Car project.

Among the many reasons-that he explained in detail for integrating the project with WSO2 products, following were of main focus...
-Middleware stack not only consisted of ESB, but also provides support for governance, identity management and security solutions,
-high availability, scalability and load balancing,
-ease of configuring, installing, integration and patching,
-support for content based routing and fault handling,
-support for SAML, XACML and X.509,
-Stratos for Connected Car as a service
Above I mentioned about only three sessions out of many that I attended.
I stop for the moment, looking forward for another day full of brain storming sessions on SOA & Cloud.

Saturday, September 10, 2011

WSO2Con2011 - Educational Value

As promised in my previous introductory blog post about WSO2Con-2011, here I am writing the follow up blog on the specialty of WSO2Con-2011 in the aspect of its educational value, in my views - as an attendee who is excited about this event that is going to happen within less than just two days.
Conference agenda is carefully organized to deliver a great value addition to your knowledge. 

Three days of key notes and tech talks are proceeded by pre-conference tutorial sessions where you will have the opportunity to get yourself equipped with the necessary knowledge in the area of SOA and on WSO2 product platform, in order to attend the conference with better preparation and understanding.

Conference is also followed by post-conference tutorial sessions on advanced concepts and topics on WSO2 products themselves and on SOA and Cloud computing to help you to dig deep into the topics of interest.

All these 3-4hrs tutorials are conducted by technology experts in WSO2 who involve in the architecture, design and development of award winning WSO2 middleware products and cloud platform.

Tutorials sessions are conducted in three tracks in parallel and the conference is conducted in two tracks in parallel, giving you the opportunity to have a wider range of selections to match your fields of interests.

Following are the tutorials sessions that I am planning to attend:
1. Practical SOA for the Solution Architect
2. Introduction to Web and SOA Security
3. Advanced Concepts in WS-BPEL
4. Introduction to WSO2 ESB for Administrators
At a glance you can get an idea about the range of topics that are going to be covered during the conference and how they are organized in different tracks from the following diagram.

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.