The ideal scenario is to have one login. This has been discussed over and over, and is even a management directive for LAN/WAN access which involves multiple domains.

There is a caveat though, because with applications and some databases, I have been unable to make them into a "one size fits all"

Doing applications for the intelligence community involves compartmented information, and the most expedient way to control this is by setting up fairly elaborate security within my application, which is on top of the secure network login, and/or even a departmental login. The security regulations detail elaborate controls over who can see what, and who can alter or edit/update records. The application can even test for the userid that was used to login to the network and prevent that userid from being used for the particular application. Much of this has been flowing over to the corporate side as well, and there is still the requirement that the application control the disemmination of classified data (classified at several levels) regardless of the clearance level or discretion of the system admin or DBA. In some cases the actual data in each field is strongly encrypted and is decrypted only to certain users.
In this scenario, the data cannot be browsed directly outside of the application.

I am also starting to see a trend by public corporations toward protecting their HR and other sensitive proprietary data in a similar, if not yet as elaborate manner; as the demand grows to make everything,everywhere available to the executive's desktop..

Of course, it is much easier and faster to develop applications that have little or no built-in security other than user level (i.e data entry/admin/read-only, etc.) relying instead on the network security. Personally I would prefer developing this way, and could spend more time and effort on the design and usability of my application. But in the end requirements differ from application to application, thus 'one size fits all" will not necessarily apply.