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)
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.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8) Then change user-mgt.xml of node2 IS instance so that it uses embedded LDAP of node1 as the user store.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
12) Add a virtual host containing following content. You have to create it inside /etc/apache2/sites-available directory
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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).
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.
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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
