Search code examples
odatasapui5

Tips and what to avoid using OData in a multitenant DB SaaS environment


Looking at data access for a multitenant SaaS database for a UI5 app I have two choices - JSON or OData. OData has some features of interest. However, I have concluded that I cannot use OData because of security issues.

In particular I am concerned that OData is a form of query language. As a very rough comparison this is like a SQL statement being composed at the client and sent to an ODBC server for processing. In a multitenant DB I will separate data between owners using, say, and org_id. If it were a SQL query I would have to include select data from table where org_id=this_tennant and .... If I can discover another tenants org_id then I can use an OData explorer to modify the query and pass into the OData source.

In a JSON data interface I would call a REST method that would mask how the data is accessed, and I would not need to expose secret details such as the org_id token. Granted the JSON / REST approach involves more work.

Or do I misunderstand OData ?

Another similar question was asked some time ago but some time has passed so I shall ask again.


Solution

  • The approach of OData is to define how RESTful APIs can be build. It adds a lot of concepts and conventions (e.g. entity types and sets, URL conventions, common query parameters, request format, batch support...) to plain REST and therefore provides you a standard for building your API.

    However, it does not define where your data is coming from, but in most cases it will be database. Of course it would be possible to expose your database tables via an OData service in a generic way, but I would expect that the provider of the framework clearly describes how to handle and protect different tenants.

    A more specific answer would require more information about the framework you will use.