Thursday, January 15, 2015

WSO2 Identity Server 5.0.0 - Service Pack 1 is now is publicly available

You can now download the WSO2 Identity Server 5.0.0 - Service Pack 1 from

This Service Pack(SP) contains all the fixes issued for WSO2 Identity Server 5.0.0 up to now.

Installing the service pack into a fresh WSO2 Identity Server 5.0.0 release, prior to the first start up. 

1. Download WSO2 Identity Server 5.0.0 ( and extract it to a desired location.

2. Download, extract it and copy the WSO2-IS-5.0.0-SP01 directory to the same location, where you have wso2is-5.0.0.

3. The directory structure, from the parent directory will look like following.


4. In the command line, from the 'WSO2-IS-5.0.0-SP01' directory run the following command.

   On Microsoft Windows: \> install_sp.bat
   On Linux/Unix: $ sh

5. Start the Identity Server.

   Linux/Unix : $ sh -Dsetup
   Windows : \> wso2server.bat -Dsetup

 6. Open the file, wso2is-5.0.0/repository/logs/patches.log and look for the following line. If you find it, that means the service pack has been applied successfully.

INFO {org.wso2.carbon.server.util.PatchUtils} - Applying - patch1016 Installing the service pack into a WSO2 Identity Server 5.0.0 release, in production already.

If you have an Identity Server instance running already in your production environment - and want to update it with the service pack, please refer the README file which comes with the service pack itself.

Thursday, December 4, 2014

LDAP vs Database

1. LDAP is mostly picked over Database if the read/write ratio is more than 10,000/1 (this number is bit arguable) - since its more optimized for read operations. So in general LDAP is more preferred for static data.

2. LDAP has scalability concerns - even Microsoft recommends MS SQL server over Active Directory - if the user base is more than 1.5 million. In most of the large scale deployments I am aware of Database is preferred over LDAP. There are some cases where people use MySQL to handle 60 million users. Some US state governments use MS SQL server to manage citizens. So, the rule-of-thumb is if the user base is less than 1 million then LDAP should fine. But, if it exceeds that then better to go ahead with a proven Database. Also  note that more than 90% of Fortune 500 companies use Microsoft Active Directory.

3. LDAP implementations provide more in-built functionalities like, password update/rotation policies, fine-grained access control via ACLs, account locking, groups and etc. If you are using a Database as the user store, then either you need to implement all those by yourself or use a third-party identity management system on top of the Database.

4. LDAP has inbuilt support to manage hierarchical relationships between user entities. If this is a requirement, and go for a Database - has to be implemented from the scratch.

5. Transactional data related to the user should not be stored in the LDAP. Those have to be maintained in the Database and linked to the LDAP user via entryUUID.

6. LDAP has inbuilt support for multi-valued attributes. Say someone can have multiple email addresses - phone numbers - LDAP by design supports keeping multiple values against the same attribute. If this is a requirement and go for a Database - has to be implemented from scratch.

7. LDAP has an inbuilt security model over the data it stores. You can define ACLs over attributes and sub-trees. We don't find this in a Database and has to be implemented from scratch.

 8. Both in LDAP and JDBC, the schema can be extended.

9. Integration with third-party applications is much flexible with LDAP - since its a standard

Wednesday, December 3, 2014

OpenID to OpenID Connect

Saturday, November 1, 2014

Securing the Insecure - WSO2Con USA 2014