People have asked me why I am doing this, and if I hate Web services because I’m blogging about their flaws. In fact, I love Web services, and as I said in the first post in this series – they are great. They are a good horse. A winner.
The reason why I am doing this is because I want to share the problems I encountered over months of working with Web services intensively, as well as the solutions or workarounds I identified.
Today, on the repertoire we have another security-related glitch, which has been confirmed to me by Microsoft, but as far as I know there has not yet been a hotfix for this.
Bug #4: accessing Web services in multi-company scenarios.
This problem might seem similar to the one I blogged about last time, but it’s not the same thing.
Take a database with multiple companies in it, then add a Windows login which only has company-level access. It may have access to one company, or to all companies (explicitly). It may be SUPER in those companies it has access to, doesn’t matter. What matters is that it must not have database-wide access in any role (meaning no role without company name specified).
Okay, now that you have that user in place, try accessing a Web service. Any Web service.
You’ll get this error: “You do not have permission to read the Company table.”
To make it short: a user without database-wide access cannot use Web services.
You might believe you can work around this problem with simple trial and error approach. The error message is pretty useful at this, and you will quickly realize that the only thing you need to do to “fix” the issue is to create a new security role with the following permissions:
- Table: Company, with Execute permission.
- TableData: Company with Read permission.
You then assign this role to every user, without specifying which company the role belongs to, and all users will now be able to access all Web services to which they have proper security access through their roles.
However, as Eric Sevareid said: The chief cause of problems is solutions.
So, if you apply this solution, you’ve created another problem: now every user in the company can see all other companies in the database. Big deal. Or?
In a multi-company database, this might be a real big deal. And it’s twofold:
- When users try to open another company, they will see all the companies, not only those that they truly have access to. And if they actually try entering one of those that they don’t have any access other than thru this new workaround role, they will get funny “you don’t have permission to this or that” errors.
- When you want to hide which other companies are there in the database from users who don’t really need to know this (because this may easily be a privacy issue in multi-tenant scenarios), then you will have a big issue.
Okay, let’s be honest: scenarios when there are multiple companies in the same database, and the users must not know which other companies there are apart from their own, are rare.
But still, if it happens that you have one of those rare scenarios, then there is absolutely nothing you can do, but wait for a hotfix.
Does anybody know if it was released yet?