Adding virtual IP in Ubuntu

Following are the steps I followed to add new virtual IP in Ubuntu

- Edit interfaces file and add following entry to add a second ip

Command to be used: $ vi /etc/network/interfaces


auto eth0:1
iface eth0:1 inet static
        address 192.168.1.50
        netmask 255.255.255.0

The new ip should be in the same network as currently using IP and it shouldn't be in use already.

Note : To check the ethernet device name, you can use following command

$ ifconfig | grep eth


- Now restart the network

$ /etc/init.d/networking restart


- If everything goes smoothly, you'll see following printed in console for above command


* Reconfiguring network interfaces...                                        
 ssh stop/waiting
ssh start/running, process 5436
start: Job failed to start
ssh stop/waiting
ssh start/running, process 5558
start: Job failed to start                                                                         [ OK ]

- Verify the change using one of the following commands

$ ifconfig | grep eth
$ ifconfig

Tips : For /etc/init.d/networking restart, sometimes you may come across following error


 * Reconfiguring network interfaces...                                        
SIOCSIFADDR: No such device
etho:1: ERROR while getting interface flags: No such device
etho:1: ERROR while getting interface flags: No such device
Failed to bring up etho:1

To solve this go to interface file ($ vi /etc/network/interfaces)


There your entry will look like........

auto eth0:1

iface eth0:1 inet static

address 192.168.1.50

netmask 255.255.255.0

Just enter tab before 3rd and 4th  lines....

auto eth0:1

iface eth0:1 inet static

        address 192.168.1.50

        netmask 255.255.255.0

And it will solve your issue....

Load balancing WSO2 IS cluster using Apache HTTP Server

First let's create IS cluster. WSO2 IS 3.2.3 can be downloaded from here.

1) Create two directories named node1 and node2.

2) Unzip wso2is-­‐3.2.3.zip distribution in to each of the node directories created above.


In this scenario, I'm going to change the host name of the servers. Let's first consider node1.


3) Change the host name to abc.com. This blog explains all the necessary steps.

Note: While creating the keystore, make sure to provide the new host name as the Common Name (CN).

What is your first and last name?
[Unknown]: abc.com

And the public certificate will look like


Owner: CN=abc.com, OU=qa, O=wso2, L=colombo, ST=western, C=sl
Issuer: CN=abc.com, OU=qa, O=wso2, L=colombo, ST=western, C=sl
Serial number: 4f788014
Valid from: Sun Apr 01 21:49:32 IST 2012 until: Sat Jun 30 21:49:32 IST 2012
Certificate fingerprints:
MD5: B3:B7:F0:73:8E:21:0C:FE:75:5C:9E:4C:5E:51:57:6E
SHA1: 7E:05:40:3C:07:89:CD:AC:3F:5B:F2:7E:E6:D5:A8:8E:85:6D:7D:C9
Signature algorithm name: SHA1withRSA
Version: 3


4) Enable clustering in axis2.xml and change domain name as "wso2.is.domain". After all the modifications, cluster related configuration in axis2.xml should look like this.



5) Apache HTTP server is going to be used as the load balancer. To enable Apache2 mod_proxy, uncomment following properties in mgt-transports.xml



With above changes, configuration of one of the instances is complete. Now let's change node2 IS instances.

6) To change the host name, enable clustering and apache mod_proxy please follow steps 3), 4) and 5). I'm using xyz. com as the host name of second IS instance. Therefore change carbon.xml, identity.xml and axis2.xml accordingly to reflect this new host name.

For this setup, a central user store is needed. The embedded LDAP shipped with WSO2 IS will be used in this scenario.

7) To disable the default LDAP of node2 change following property in embedded-ldap.xml



8) Then change user-mgt.xml of node2 IS instance so that it uses embedded LDAP of node1 as the user store.



9) Change the ports of the server by changing the off-set value in carbon.xml. I've changed offset value from 0 to 1. Now https port will be 9444 and http port will be 9764.

Now let's consider about configuring Apache http server as a load balancer.

10) If you've not already installed Apache server, install it using following command. (you have to be root to perform following actions)

apt-get install apache2

11) To enable necessary modules, go to /etc/apache2/mods-available directory and run following commands.

a2enmod proxy_http
a2enmod ssl
a2enmod proxy_balancer

a2enmod headers

12) Add following entry in httpd.conf (/etc/apach2)


LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule status_module modules/mod_status.so

12) Add a virtual host containing following content. You have to create it inside /etc/apache2/sites-available directory

Note : Since ssl is enabled you have to specify location of the certificates.

Load balancing configuration is done to be session aware.

13) Add above created virtual host to sites-enabled directory using following command.

a2dissite default-ssl

a2ensite wso2.com

Note : "wso2.com" is the name of the virtual host.

14) After all these configuration start apache server

sudo /etc/init.d/apach2 start

15) I've changed the host name of the server/load balancer to wso2.com. Therefore add following entry to /etc/hosts file

127.0.0.1 wso2.com

I've created load balancer certificates with Common name matching the server host name (wso2.com)

Final step is to import this certificate into the keystore and trust-store of two IS instances. For that use following commands.

16) keytool -import -alias servercert -file servercert.pem -keystore iskeystore.jks -storepass ispassword

Note : ispassword is the password of new keystore used by IS

17) keytool -import -alias servercert -file servercert.pem -keystore client-truststore.jks -storepass wso2carbon

18) Now start two IS instances.

19) If you type https://wso2.com/carbon or https://wso2.com:443/carbon you'll be redirected to one of the IS instances. If one server is down, you can observe that the traffic is routed to other server.

Configuring OpenID based SSO when host name is changed in WSO2 Carbon based products

The default host name of WSO2 Carbon based products is "localhost" which can be configured through "HostName" property in CARBON_HOME/repository/conf/carbon.xml. If this value is "localhost" the management console url looks like https://lcoalhost:9443/carbon/ (You can observe this value at server startup).

But most of the time, it's preferred to use some other suggestive value for host name rather than using default value.

e.g. wso2.com so that managment console url will look like https://wso2.com:9443/carbon/

In this blog post I'm going to use WSO2 Identity server as the Carbon based product since by default WSO2 IS supports SSO via OpenID. But same steps are applicable to all other WSO2 products.

In order to change the host name and management console url, you have to change the host name value in CARBON_HOME/repository/conf/carbon.xml to wso2.com as I've done below.

Change identity.xml as follows.

If you are a Ubuntu user, then you have to add following entry in /etc/hosts file

127.0.0.1 wso2.com

If you are a windows user, then above file is located at c:\windows\system32\drivers\etc\hosts

Now if you start the server, you'll see that it starts without any errors. After the server successfully starts, sign in as admin user and go to My Identitys -> InfoCard/OpenID and copy the OpenID url provided by WSO2 Identity Server which will look like "https://wso2.com:9443/openid/admin"

If you use this url to sign in to an external SSO client or internal client provided by WSO2 IS, you'll encounter following error.

[2012-03-30 10:37:52,427] ERROR {org.wso2.carbon.identity.relyingparty.ui.openid.OpenIDConsumer} - 0x704: I/O transport error: hostname in certificate didn't match: !=

org.openid4java.discovery.yadis.YadisException: 0x704: I/O transport error: hostname in certificate didn't match: !=

To overcome this, relevant certificate should be imported to keystore used by WSO2 IS or you can specify a new keystore which has a matching public certificate.

The steps needed to create a keystore with matching certificate and configure IS to use that keystore can be found in this blog post written by Hasini.

In creating the new keystore, you should keep in mind to provide the host name of your new carbon server as the Common Name (CN).

e.g. :

keytool -genkey -alias iscert -keyalg RSA -keysize 1024 -keypass password -keystore iskeystore.jks -storepass password

What is your first and last name?

[Unknown]: wso2.com

What is the name of your organizational unit?

[Unknown]: qa

What is the name of your organization?

[Unknown]: wso2

What is the name of your City or Locality?

[Unknown]: Colombo

What is the name of your State or Province?

[Unknown]: Western

What is the two-letter country code for this unit?

[Unknown]: SL

Is CN=wso2.com, OU=qa, O=wso2, L=Colombo, ST=Western, C=SL correct?

[no]: yes

After you successful configure IS to use new key store start the server and access management console. You can verify your configuration by viewing the browser certificate.

Now if you try to login with openid url, the login will be successful.

How to configure WSO2 Identity Server to act as a Key Distribution Center?

From WSO2 Carbon version 3.2.0 onward, all the products are embedded with LDAP server.  This embedded LDAP has a KDC (Key Distribution Center) running which is capable of issuing Kerberos tickets to clients and services who are in the LDAP server. By default this KDC is disabled. Let's see what are the steps that we should follow to enable this KDC.

In this blog post I'm going to explain how to enable KDC in WSO2 IS 3.2.3

You have to change following configuration files in order to enable KDC

1) embedded-ldap.xml (CARBON_HOME/repository/conf)



2) user-mgt.xml (CARBON_HOME/repository/conf)




If KDC is sucessfully enabled, you'll see followng log printed when server is starting

INFO {org.apache.directory.server.kerberos.kdc.KdcServer} - Kerberos service started. Kerberos service started.


In addition to acting as a KDC,  WSO2 IS supports adding Service Principals through UI. To achieve this  login through management console and go to Configure -> Kerberos KDC -> Service Principals. You can see that "Add new service principals" option is now enabled and you'll be able to add service principals through that option as shown in following image.

Rule combining algorithms explained using WSO2 Identity Server 3.2.3

In this blog post I'm going to explain how overall response of a XACML policy changes with different rule combining algorithms. We are going to use WSO2 Identity Server 3.2.3  as XACML engine.

Let's consider following policy.

1. The first rule's effect is deny. According to this rule, anyone who belongs to "dev" group is NOT allowed to read the personal information record of Jerry.

2. The second rule says that a person who is at least 5 years scenior to Jerry can read Jerry's personal information record.




So what will be the final outcome of policy evaluation if Tom (who belongs to "dev" group) is 7 years senior to Jerry ? Should we totally ban Tom from reading those records or should we allow him to read them considering about his experience and seniority ?

This is a decision which can be handled/changed through policy based on the actual requirement.

1st scenario :

Regardless of their experience, we want to prohibit people belonging to "dev" group from reading Jerry's personal information. In this situation we need to use above policy with "deny-overrides" as rule combining algorithm.

For following request, XACML engine will return "Deny" as the result.



2nd scenario :


We need to allow read permission to anyone who is at least 5 years senior to Jerry.

In this case role should be neglected if above requirement is fulfilled.

We can use the same policy after changing the rule combining algorithm to permit-overrides.

To change the rule combining algorithm, click "Edit"  in Home -> Entitlement -> Administration. Then change the rule in " Edit Policy Element" page and save the policy.

Note : You have to enable the policy every time you edit it.

Now send the same request (given in 1st scenario) again. "Permit" will be returned as the result.

3rd scenario :

 Now let's see about the next rule combining algorithm. i.e. first-applicable. Here the first applicable rule will be picked up from the set of rules defined in the policy.

To change the rule combining algorithm, go to "Edit Policy Element" page by following the instruction I've given above and change the algorithm to first-applicable.

In our sample policy, there are two rules. First rule evaluates to deny and second one evaluates to permit decision.





















Keep the policy as it is (only change the rule combining algorithm) and send the request given in scenario 2.  You'll receive "Deny" as the result because the first applicable rule (for the request) evaluates to deny.

Now go to "Edit Rule Elements" page (Entitlement -> Administration -> Edit -> Next -> Next) and change the order of rules as shown below.




















If you send the same request again, the result will be "Permit".

You can see that by changing the order of the rules in policy, you'll be able to change the final decision.

In this blog post, I tried to explain the behavior of different rule combining algorithms using one policy. In the next post, let's see how policy combining algorithms can affect the policy decisions.