So, you want to have many websites with many different content sets but a shared set of users, roles and sessions? Not a problem. There are many ways to skin the Drupal multi-site cat.
The "standard" approach is to have different prefixes on tables in the database. Drupal natively handles this, because you can define in settings.php for each site, which table prefixes refer to which tables. This is the simplest way to handle single-user-base multi-site installations, and it works fine. You have one set of tables prefixed with something obvious like 'shared_' and make them common to all sites. The rest of the tables vary from site to site, e.g. become 'site1_node', 'site2_node', etc.
But what if you want many, many sites? I mean hundreds! That's thousands of tables. What a mess - a DBA's worst nightmare. And scaling? You'll have to start replicating your monolithic database across other nodes or dicing with MySQL clusters.
But there is another way, to quote one particular British high street bank. What if each site had it's *own* database. Again, this is perfectly normal for Drupal. The settings.php file lets you point each site at a different database from the same core codebase. Nice!
The million dollar question is how to share users between these databases? I originally thought (as is commonly believed, since the approach was not documented until I revised my article on the matter) that Drupal was not capable of selecting different databases according to settings.php.
With that in mind, MySQL 5 provided a possible answer in the form of table views. However, I subsequently discovered, having pitched it in as a feature request for Drupal 7, that Drupal already silently supports selecting different databases from the settings file, which is awesome! No MySQL views required.
I revised my original HOWTO on the matter: