In my country, there’s a saying: “A good horse has a hundred flaws; a bad one has only one.” It’s bad.
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.
Problem
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.
Workaround
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?
Have you tried assigning indirect reading permissions?
Have you tried assigning a security filter to the permission, so the user only has access to the company records he needs?
Just suggestions – haven’t tried either of them…
@Peter: Thanks for the suggestions. Unfortunately – I haven’t tried any of your suggestions. Regarding indirect reading permissions, I don’t think that would help. Security permissions might help (even though I would say I am 99% sure it will not).
The first paragraph of this post gave me a good laugh 🙂 It reminded me of the times passed by.
This saying was (in)famously used by the ruling Croatian party 15 years ago – HDZ (Croatian Democratic Union) in one of their election spots on the TV. In it, one shivery man in his fifties approaches a young, strong, good-looking fisherman on the seafront. While holding a newspaper in his hand, the old man loudly repeats all the affairs that were troubling the society at that time: corruption, criminal privatization of the public companies, unemployment, etc… After he finished his gibbering, the fisherman confidently replied: “A good horse has a hundred flaws; a bad one has only one. It’s bad.”
Since then, I didn’t hear that saying again, until now. 🙂
Not to be misunderstood, I don’t want to push this kind of historical parallels too far. One cannot help but to applaud the commendable way in which Mr. Babic shares his revelations about the new important feature of Dynamics NAV. I hope you will continue to update this blog regularly. I was already concerned that you gave up blogging.
@Vinko: Thanks for the supportive comments, but I don’t know what I did to you to deserve that you “Mr. Babic” me? 😉 Now that you remind me of that TV commercial by HDZ, I remember it as well, but I definitely wouldn’t want to make any correlation between HDZ and Web services in NAV 🙂 NAV Web services are a good horse, a really good one. HDZ, well… this is not a politics blog, so I’ll refrain from making a statement 🙂
@Vjekoslav
i have a question regarding the navision. I have been working with navision for no more than 3 months, however i have a question regarding the programming of tables.
How can you avoid not showing up the rows and columns which do not have a value? let say into a sales report articles which are not sold during a week( even-though they exist into database) not to show up during the report; ( not even BLANK SPACE)?
@Dardan: Create a boolean variable in the report which you assign the true/false value based on criteria that are relevant for you (e.g. sales within the past week), then use this value together with SHOWOUTPUT function in Classic, or table filter in RDLC reports.