Single sign-on, or integrated authentication, is easily overlooked by people doing IT. Here are some common and unnecessary scenes:
- the Intranet has a different logon from the desktop. Why??
- The xyz web service has a different logon. Again, why??
- The mail system and finance system have different logons.
On top of that they run different password policies: some require at least 6 characters, some at least 8, some even exactly 8!
The result is that people forget, they write it down, they share or they just don’t bother to use the service at all. Technically there is no excuse for it. It is easy enough to integrate the logons.
Basically passwords for all resources of any degree of importance should have a minimum complexity. That should be the start. A more secure environment might require more. If a user has to have at least password of this complexity, they may as well use this as the starting point for all. It isn’t really easier to have a secure password for your desktop, then a different less secure password for the intranet. You may as well use the same. And it isn’t any good exempting the chief exec from a password expiry or a required complexity. He’s the one whose account the bad guys would like to get into.
There are a few cases where you may need to handle logons differently.
- For remote access, you don’t have the same physical control of who is trying to log on. Someone in North Korea might be trying continuously to break in. So you must have auditing, maximum retries, SSL encryption of course. And you MAY choose to add a two-factor authentication. That means that as well as the usual logon details, you require an additional proof that you are who you say you are. There are plenty of ways to do this, but importantly they are on top of the usual logon, not instead of.
- For financial systems you may as a matter of policy choose not to integrate the logons. This means that if a clerk discloses their Windows password to someone, they don’t immediately have access to the Accounts Payable system. It also means that the IT helpdesk can’t reset a Windows password and get into the finance system, because the accounts are handled by different people. I am not really convinced by this. The kind of people who would disclose their password like that would also disclose their finance logon. They probably should not have access to any important functions anyway.
- At security boundaries you are bound to have different logons. At some point a user is a home user of their own systems, and an external user of someone else’s system. This means that in a large organization you are bound to have systems run by different groups, and some will be too far apart to be integrated. But at least the systems that are intended to be used widely should share the same authentication methods.
The main motivation for having different logons for different systems is not that it is necessary, but that it is easier and quicker to implement. Here’s how it should work.
- Any organization should have a single main directory service. If it has an e-mail system then it already has a directory, so it is certainly possible to do.
- The directory service should handle a range of logon types, mainly by supporting standard Kerberos authentication and LDAP directory structure. If the organization is principally a Windows type of organization, then it will be Active Directory. If UNIX, then something like Sun Directory Server. If MAC, then Open Directory.
- All other services should refer to the directory for authentication, if they are capable of doing it. They can do this, for example, with a secure lookup over LDAPS.
- You need to have a method of delegating administration of the directory, so that other departments or parts of the company can administer their own users. And ideally it should work over the web. The Dot Net Factory does this for Active Directory.
- If the system can’t technically use the directory for authentication, then at least you can integrate the administration. M-Tech PSynch enables you to change passwords for different systems in one web interface, and to set whether the passwords are automatically synchronized or not.
- If your intranet is hosted off site by another company, you need to insist that they use your authentication. This means running the intranet on a secure network that is logically part of your network, not part of the vendor’s. You can do this on their premises or on yours, but really, if it’s your intranet, it does not make a lot of sense for it to be running on someone else’s premises unless they run all your services.
This should not be a dogma. There will be situations where the logons can’t be integrated or the administration has to be separate. But you should be able to get the number of different logons for a user down to no more than two, at least for most people.