You could be forgiven for thinking, given
Veil2's capability and sophistication, that it
would be difficult to set-up and use. But this is not the case.
It is not trivial and it does require you to develop a deeper
understanding of your data than you might choose, but the process
is well documented and each individual step is simple enough.
The best way to get a grip on the complexity and amount of effort that would be required is to look at the demo apps.
In the spirit of expecting resistance, what follows is a list of
imagined criticisms of Veil2 with appropriate
responses. This is in place of a FAQ since, at the time of
writing, no-one has asked any questions.
It’s easy to criticize relational security systems and
implementations as they are not widely used and are worryingly
novel. Here are a few criticisms that have been directed at
Veil2-like implementations.
It’s too difficult for our application developers to understand.
Actually, it’s easier for them than having to implement application security for themselves. For the most part, they don’t need to understand the details. Also, they may be smarter than you think.
The users won’t understand.
They don’t need to. The security implementation is almost entirely hidden. But they should be able to understand that assigning a role to a user in a given context, gives that user the ability to perform tasks appropriate to that role.
We’ll need a database specialist to do this.
Yes, you will. And they had better be good at what they do.
But the time that your database specialist spends on setting
up your security system with Veil2 should
be matched by the amount of time saved by your application
developers who will no longer have to implement security
mechanisms themselves.
Furthermore, with a good database specialist available you should end up with a better overall database design as well as one that is well secured.
If you’re not prepared to employ a database specialist then relational security is not for you.
No-one else does it this way.
And how is that working out for them? The track record of everyone else does not look too good when you start looking closely.
It’s going to be expensive.
Not necessarily. Your application developers should have an easier time of things. You should end up with a higher-quality, and easier-to-maintain application. There will be a need to do some careful thinking about access controls, and you will need to document your security model, but that is a good thing to do anyway.
We will be held hostage by our database/security expert.
Only if you let them. Documenting your security model is essential. Documenting your administration processes is essential. You should be doing this anyway.
If you have the documentation, and you have access to good developers who are prepared to read, then you should have no problems. You will need quality control but you have that anyway.
How do we know it’s going to work?
Perhaps you could run some tests.
Won’t performance be a problem?
Not in the author's experience but you may find otherwise. You may need to perform some data denormalizations and you will want to analyze some of your queries but there should be little performance impact.
If you are concerned, and you should be, try modelling your
use-case and test it. Find your biggest tables and
implement a minimal test database that you aim to secure
using Veil2. If the big tables perform
adequately, then the rest should be a breeze.
There is no expertise available.
Any Postgres specialist who can read this documentation should be able to cope and quickly become an expert. The underlying principles are all documented. The code is all documented. There are documented examples. There are even contact links.