The Basics
Drupal is set up to do role-based permissions. This means that every user (logged in or not) is assigned to a role. If you take a look at your Access Control settings, you’ll see that you can add new roles and set module permissions on each role. For example, if you set the “Authenticated user” role to “create page content”, every user in the “authenticated user” role can create page nodes anywhere on the site. Again, this is MODULE LEVEL.

The Problem
I get this question all the time: “Can I make this page secured so that only myself and 3 others can see it?” The short answer is NO! The problem here lies in the Module-level roles. If you can view “Page” nodes, you can view ALL page nodes! This can be very problematic.

A Solution
One possible solution is to install Organic Groups (OG). OG allows you to place pages in a group that only group members can access. The obvious problem is that in order to secure ONE page in a different way than all other content, you would need to create a group, create a page assigned to the group, and add users to the group. That can be a pain.

Another little caveat: If a user has a Role which allows for “create page content”, they will be able to create pages in ANY group they are a member of. If you need to restrict THAT, you’ll need yet another module: og_user_roles. This allows the group manager/admin to set user roles per group. However, if the user has a site-wide role permission (as defined in the Users->Access Control), they will have that role in your group no matter what. Meaning that you must remove them from the global role as well.

Conclusion
While the Drupal authentication scheme probably works for 80% of the users, it is limited at the functional level, not the node level. There are quite a few access control modules that attempt to correct this (like OG) but they are all additional modules. A couple others to look at are Taxonomy Access Control (TAC), Simple Access, and any of the other 174 Options.

Drupal is great at what it does…I suppose. The problem is that you can never really define what Drupal actually does without both short-changing and overstating its capabilities. The concept behind a fully generic CMS is GREAT! This means that I can arbitrarily add data, create different types of data, and so on…and Drupal allows for this! So what, then, is the problem?

The problem is … who wants to mess with code just to set up a blog? Who wants to download 38 different access control modules to find the one you’re comfortable with? Who wants partially implemented and partially working modules? No one! As a self-proclaimed Drupal Ninja, I can tell you the shortcomming: A lack of a strong identity with a robust integrated featureset. That’s not to say that Drupal core isnt stable and robust…but for WHAT PURPOSE?

So we go back to the previous question…what is Drupal? Is it a Weblog? No. Is it a Program management/Groupware suite? No. Is it a tool for document management? No. Could it be ALL THE ABOVE AND MORE? CERTIANLY! But that costs time and money…

Long story short…I make a living off of developing and “selling” Drupal sites…and when I wanted a Blog, I chose a Blog package: WordPress.  Some food for thought.