Is client-side OLAP (e.g. client-side MDX construction plus xmla4js) bad for security?

Question

I'm working on a public-facing web project that will be powered in part by an OLAP server. I wanted to compare a couple ways of doing this from a security perspective:

1. My initial idea was to pass some representation of the user's intent to the web server via AJAX, have the web server do lots of input validation and construct an appropriate MDX expression to pass to the OLAP server, and finally proxy the OLAP results back to the browser. (Tangentially, this seems to be the approach taken by jpivot; e.g. I just clicked to drill down into a table in a jpivot example, and what got sent to the server wasn't MDX but simply the x-www-form-urlencoded string "wcf65768426.x=3&wcf65768426.y=3".)

2. In contrast, the xmla4js project seems premised on opening up a firewall port and exposing your OLAP server to the world (or at least to your particular customers) via XML/A, writing MDX queries in client-side javascript, and having the browser directly hit the OLAP server.

My gut reaction is to be quite suspicious of the second approach. It seems to presume that nothing bad can happen if someone were to execute arbitrary MDX statements against my OLAP server. I'm not yet a student of particularly advanced MDX, but it's not immediately obvious to me that this is a risk-free proposition. At very least someone could kick off some very expensive queries, or download a larger chunk of your dataset than you were hoping to easily make available to people. This isn't the sort of thing people generally do with SQL servers, and I'm initially inclined to think the same reasons suggest you shouldn't do it with OLAP servers either.

But I'd also like to assume that the folks behind xmla4js had some use cases in mind that were not crazy security risks. And I guess potentially I could be thinking about this too cautiously.

Any more experienced OLAP folks want to comment on the wisdom of letting people directly bang on your OLAP server, e.g. via XML/A?

Answer 1

Interesting question. Certainly if you think your users might hack your webpages it's a source of risk offering a direct access to your datamart (here OLAP Server). This being xmla4js option, it's very similar to giving users direct access to a rdbm.

• Yes, certainly it's relatively easy to create an MDX query that is very, very time consuming (e.g. using calculated members).

• Fine grained security is possible in OLAP so users might not have access to the details. Fact and dimension security.

One issue with option 1, is the cost (time and money). You'll need more time to implement and you'll be unable to use existing widgets and libraries (e.g. GVI Library). How important is for you security and hacking versus time to delivery ?

One possible solution is using a http proxy for XMLA allowing only 'known' requests to be executed. But, what is a known query?

Some OLAP Server allow for a better control on the number of threads that are allocated by MDX request and how many requests can be executed in parallel. But this solves only partially the problem.

It's really an interesting problem... not trivial. Bad luck for us you're not one of our customers ;-)

Answer 2

On reflection, this is probably a question that should be asked about individual OLAP server products, rather than about OLAP in general. For example, if an OLAP server was coded with security in mind, has support for read-only, non-admin accounts, and can time out queries that are taking too long, you'd be in a better position to expose that server publicly than in the contrary cases.

Unfortunately, OLAP vendors don't seem to tend to give explicit guidance about this. For example it's relatively easy to find the info you need to set up Sql Server Analysis Services for anonymous access, but it's harder to find an explicit statement from Microsoft about how dangerous it is to open up anonymous SSAS XML/A access to the public internet.