WSO2 Platform

Finally back to the blog – I can’t believe I did not write any for more than a year, time absolutely flew by – New products, new responsibilities – Exciting times!

To restart blogging, I decided to start with a platform presentation. At WSO2, we often state that we have a platform and not a set of individual products. I explained that months ago when I described Carbon. This is still true (more than ever), but our products also constitute a platform – A platform you can build upon.

So what do we offer ?

Most of the enterprises we talk to have the same necessity : connect applications, people and devices. Let’s take a concrete example: imagine you create your own company. You will most likely need to provision a CRM, on-premise or in the Cloud to manage your clients and day-to-day activities. Rest of information you can manage in local databases or even spreadsheets. In order for your sales employees to be more efficient, you need them to go to customers and have their information available at any time. Best solution: you give a tablet to each of your employees. But how does the CRM data gets there, securely, in a controlled way ?

Let’s progress step by step :

  1. Wrap all the backend functionality as services. This may already be done by the CRM itself – If not, or if you have some custom business logic you want to reuse, r data you want to share, you’ll have to create those services. SOAP/REST/XML/JSON, Java/PHP/Scala, you choose. Once services are created, it won’t really matter, so choose what you’re comfortable with.
  2. Best practices recommend that you decouple the consumers of those services from the producers. In other words, you need a mediation layer between your existing services. This layer may be very simple in the beginning ( i.e. act as a simple reverse proxy) but once this is in place, the transformation, enrichment or guaranteed delivery use cases can be easily handled.
  3. Expose those services as APIs – The APIs are your contract with the consumers. APIs have their own life cycle, are managed ( for security and rate control ). Service is the implementation. If you are not convinced, read this :
  4. All right, now you have APIs – How will people find them ? Think about the all the Apple apps, but without the Apple Store. How would we know which apps are available, what other consumers think about them, how would we interact with the apps authors ? Same applies to your APIs. If they are not socialized through a store, you won’t achieve the reuse level you are targeting, nor will we engage with your clients.
  5. Your APIs are deployed and people use them. But do you know who uses them? Which is APIs is the mostly used, which one is not ? Analytics are a core part of this strategy, but they give you visibility into the system.
  6. And of course security: not only do you need to secure the access to your APIs, but you may also have to support single-sign on to applications, or allow your employees to use their emailID to view CRM data.

The WSO2 platform allows you to address all of these aspects; you may consume the whole platform or just parts of it. You may have existing services deployed on various systems or an existing ESB. As long as all of they use standard approaches ( which most of them do ) , chances are you can plug one of our components into your architecture.

Middleware platform


In subsequent posts, I will detail each of the platform themes: integration, API management, Assets socialization, Analytics and Security.

Custom User Store in our Identity Server

Over the past 3 months, I have been leading a couple QuickStarts (or QSP as we call them) around API Manager and Identity Management (IS). Our API Manager relies on some of the IS components, especially for all OAuth2-based security scenarios ( issuing and validating access tokens).

In both QuickStarts, we had to create custom user stores, both backed by JDBC. We either totally replaced the default user store by a custom one, or leveraged the multiple user store feature. IS turned out very flexible to accomodate to the specific schema requirements of our customers, and my colleague Johann, who works in the IS team, very quickly implemented the custom code that would allow IS to interact with those custom user repositories.

The magic for all this to work is in the user-mgt.xml file. IS is packaged with a default LDAP-based store, based on ApacheDS. All other products are packaged with a JDBC-based store, using H2.

Here is a sample user store definition, which shows how you can externalize the SQL queries used to manage users and roles in the custom DB:

<UserStoreManager class="com.sample.wso2.TestUserStoreManager">
 <Property name="dataSource">jdbc/testuserstore</Property>
 <Property name="DomainName"></Property>
 <Property name="ReadOnly">false</Property>
 <Property name="MaxUserNameListLength">100</Property>
 <Property name="IsEmailUserName">false</Property>
 <Property name="DomainCalculation">default</Property>
 <Property name="PasswordDigest">SHA-256</Property>
 <Property name="StoreSaltedPassword">true</Property>
 <Property name="UserNameUniqueAcrossTenants">false</Property>
 <Property name="PasswordJavaRegEx">^[\S]{5,30}$</Property>
 <Property name="PasswordJavaScriptRegEx">^[\\S]{5,30}$</Property>
 <Property name="UsernameJavaRegEx">^[^~!#$;%^*+={}\\|\\\\&lt;&gt;,\'\"]{3,30}$</Property>
 <Property name="UsernameJavaScriptRegEx">^[\\S]{3,30}$</Property>
 <Property name="RolenameJavaRegEx">^[^~!#$;%^*+={}\\|\\\\&lt;&gt;,\'\"]{3,30}$</Property>
 <Property name="RolenameJavaScriptRegEx">^[\\S]{3,30}$</Property>
 <Property name="UserRolesCacheEnabled">true</Property>
 <Property name="maxFailedLoginAttempt">0</Property>
 <Property name="InternalJDBCRolesOnly">true</Property>
 <Property name="SelectUserID">SELECT USER_ID,PWD_HASH FROM USERS WHERE USER_ID=?</Property>
 <Property name="AddUser">INSERT INTO USERS (USER_ID, PWD_HASH) VALUES (?, ?)</Property>
 <Property name="GetIsUserExisting">SELECT USER_ID FROM USERS WHERE USER_ID=?</Property>

Now, what about coding ? Well, that’s the advantage of OpenSource code : here is the JDBCUserStore we use, which extends the AbstractUserStoreManager class:

A tip : start with overriding the user methods (addUser, getUser, isExistingUser, listUsers) as well as doAuthenticate.