+972 52-548-6969
The pitfalls of transparent security
A long time ago, I needed to implement a security subsystem for an application. I figured that it was best to make the entire security subsystem transparent to the developer, under the assumption that if the infrastructure would take care of security, it would make a lot more sense than relying on the developer to remember to add the security calls.
It took me a long while to realize how wrong that decision was. Security is certainly important, but security doesn’t apply to the system itself. In other words, while a specific user may not be allowed to read/write to the audit log, actions that the user made should be written to that log. That is probably the simplest case, but that are a lot of similar ones.
Ever since then, I favored using an explicit approach:
var books = session.CreateQuery("from Books")
.ThatUserIsAllowedToRead(CurrentUser)
.List<Book>();
This also help you implement more interesting features, such as “on behalf of”. And yes, it does put the onus of security on the developer, but considering the alternative, that is a plus.
Comments
Sure, that' easier to handle. And I'm sure for some systems, that's the way to go. But make one critical mistake in a multi-tenant system hosting mutual competitors, and you're done.
Transparent security works, you just need to be able to opt out. Sometimes you forget to opt out, this will result in an exception and will hopefully be caught during testing. If not, an unhandled security exception in production is still better than information disclosure.
Another potential advantage: You might want to control who's able to opt out.
Transparently adding a default deny at least might be a good idea
I see what you're saying, and it can sometimes be misleading that if the developer queries for books it only returns a subset of the books. This method is most obvious to the programmer. However, I usually use transparent security with the ability to opt out for the reasons Stefan stated.
Comment preview