Hello,
In DotNetNuke portals are fully segregated from each other i.e. have different users, security roles and content. The primary motivation behind portals was to allow site admins to create distinct sites but still have them use a single codebase and database. By sharing a single database there are obviously cost savings (though there is a marginal impact on performance from running a lot of portals under one database due to certain tables being joined againt during queries - this is typically quite small and there are sites that have hundreds and even thousands of portals under 1 database). Another advantage is that an upgrade can happen for all sites by updating a single code base.
However the big con against portals is if you intend using the same database for different clients and that client then wants faster/better hosting (or to leave your company), as there are no built in tools to extract an individual portal (you can use portal templates but that relies on all modules implementing IPortable which is not always the case). There are of course 3rd party modules which profess to do this (and the obvious hack of duplicating the site and deleleting all the other portals and letting the referential integrity take care of it), but it is a consideration if you plan mixing differnt customers into 1 database.
At present DotNetNuke does not have any form of cross-portal sharing (though if the same user registers on multiple portals with the same username/password combination they are seen as the same user), but there are many 3rd party module which do this - so if this is something you require it is certainly easier to do with multiple portals rather than multiple sites (though you can share the asp.net membership database cross-site if you want). Please note, we are working on some portal sharing (users/profiles) but its going to be in the PE/EE versions, though the underlying hooks will be in the opencore as per usual.
Regarding seperate sites, the main benefits are a lack of single point of failure, the ability to differentiate sites (e.g. perhaps 1 site uses Razor so therefore needs .net 4.0, but another uses the AD provider which at present has some issues with .net 4.0 integrated pipelines - these are resolved in the next release but it serves as a valid example), and the ability to update each independantly. Similarly you may want to only allow certain sites access to certain extensions and whilst this can be controlled via permissions/premium modules (
http://www.dotnetnuke.com/Resources/W...) true granular control would require seperate installs.
On the question of authentication I don't see a big difference between them, except that in an portal situation where child portals are used as the forms auth cookie has the same domain it opens some possibilities that different domains do not because of cookie domain rules/originurl. For both configurations you would typically introduce an approriate authentication provider (or write your own), the wiki has some useful detail on this
http://www.dotnetnuke.com/Resources/W...