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 -~----------~----~----~----~------~----~------~--~---
