James, thanks for this argument. Perhaps I should have given some more specific info about the project.
We are at approximately version 0.2 - months or perhaps a year from having a beta. Nothing is cast in stone. It's important to us to implement access control at database level for a couple of reasons: 1. RDBMSs like PostgreSQL, Oracle, perhaps even MySQL although it's still a fledgling in this regard (to name but 3), were designed to (or have subsequently been revamped to) handle the kind of business logic that large organisations demand. Web frameworks like Django invariably are not designed to handle such business logic. This is not a criticism. I accept that my application is not in the sweet spot of Django's target audience. Nonetheless, there are so many similarities between our development requirements and the framework that most days it feels like we're reinventing the wheel. This is why I want to use Django. Unfortunately, pushing access control up the stack means I have to rewrite all the functionality has been carefully and comprehensively facilitated by my RDBMS. Also it means that access control logic has to be written into every app that connects to the database - instead of just having it in the database itself. 2. When my app gets installed in an organisation, developers outside my control will be modifying and maintaining that instance. It would be easy for them to write an incorrect script that gave too much power to a user, and nothing would stop it from corrupting the database because of course with these "modern applications" the database connection is always made by a super-like-user that can do anything inside the application's database. Putting access control at the database level gives me some protection against stupid or malicious developers - not in my organisation, but out there in the world, where my app is used. If you still think I'm barking up the wrong tree, that's fine. I don't want to waste your time. I still think I have a valid reason to suggest these enhancements, and as I said before, I may be able to support my suggestions with resources. Foob PS. I'm still interested in reading more about the security flaws of web to database pass-through authentication. If anyone has any good links, don't hang back. On May 10, 1:35 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > It's a tightly modelled, configurable, business administration tool. > > If used in a business of significant size, I would expect and hope > > that a DBA was employed to administer the database. Many of the tables > > will contain information that is restricted (sometimes with different > > scope for readability and editablility) to various roles which are > > mapped to individuals or groups in the organisation. > > While I'm not saying that multiple DB-level users and DB-level access > controls are the wrong solution, I would ask up-front what specific > real-world problem is being solved by this, and whether it really is > the best solution. > > Rambling historical anecdote: > > Many large organizations have IT policies which require users to > change their passwords every so often, usually once every 30 or 90 > days. This is touted as a security requirement for sensitive data, and > it's rare that anyone asks what actual security problem the password > changes solve. As it turns out, the origin of this recommendation was > an analysis of how long it would take to brute-force a password on a > 1970s-era mainframe -- the recommended period for changing passwords > was set to be shorter than the time it would take to try every > possible password. > > Modern systems are far faster, and brute-forcing a password can now be > a matter of hours or even minutes. Newer, stronger methods -- such as > better physical and network security controlling access to the system, > and "locking out" a user after a relatively low number of failed login > attempts -- now mitigate this risk far more effectively than any > "change your password every X days" policy. Additionally, such a > policy actually increases the risk of a breach -- frequent password > changes encourage users to choose weaker passwords, or to write down > their passwords and leave the information in easily-accessible places. > > But most companies still have a mandatory password-change policy, > because the organizational inertia of "we've always done it that way, > and everybody else does it that way" discourages questioning. > > Similarly, I have a feeling that segregation of databases and the sort > of access controls you're proposing have their roots in much older > systems where users had more or less direct access to the database > server and this was the most effective way to manage the users. > > But modern applications almost invariably introduce a mediating layer > between the user and the database, effectively moving access controls > to another layer of the stack. For example, in a web application a > user can only access data through the interface exposed by the > application; there's no way to "drop down" and avoid that layer. This > means that the application can control access and hide implementation > details in much the same way as database-level views and stored > procedures. > > This is why so many web applications use only a single logical > database, and access it through a single database-level user; the > application logic should already be taking some access controls into > account (for example, if the user isn't allowed to view records from a > particular table, the application should never even display an option > to do so) anyway, so moving more access-control logic to the > application layer becomes a more attractive option. > > Moving access-control logic "up the stack" into the application layer > also increases the flexibility you have when designing and optimizing > the database (since you're not bound to a particular design from the > start), and allows easier modification of the application; with > pass-through authentication and DB-level segregated access, any change > to the authentication scheme must occur in two places: first, the > change must be made in the database layer, then corresponding changes > must be made in the application layer. By contrast, keeping as much > access-control logic as possible at the application layer means that > you have a single place where changes can be made (and remember that > application-level changes are often easier to manage than > database-level changes); this is the DRY principle at work. > > Given that, it's worth asking whether the solutions you're proposing > are still the most effective, or whether they've reached the > organizational-inertia stage of "we've always done it this way". > Relying heavily on database-level access controls and segregated > databases may be a good fit for a particular application, of course, > but the best thing to do is determine that up-front before making an > architectural decision; committing to it will significantly increase > the complexity -- and, by extension, the cost both for development and > maintenance -- of the application, and if you can avoid that > complexity you should. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
