Setting up a global authentication policy isn't as challenging as it sounds. User IDs and passwords may come from different languages, but, in the end, they're still different flavors of the same authentication credentials.
The problem with unifying authentication policies around the globe is more of an infrastructure and architecture issue than one of authentication systems. Enterprise authentication systems, by and large, are pretty much the same everywhere, and can scale up to hundreds of thousands of users. In addition, many have support for internationalization and can handle everything from Roman characters for English and European languages to Middle Eastern languages like Hebrew and Arabic -- which are read from right to left -- to Asian languages made up of thousands of characters. Unicode, a universal coding system to uniquely represent any letter or character in any language, makes it possible.
Unicode is an industry standard accepted by the major manufacturers of IT products, such as Microsoft, Sun, Apple, Hewlett Packard and Oracle, and is a part of most key programming languages underpinning authentication systems, such as Java and .NET. The two main authentication directory services -- Active Directory (AD) and lightweight directory access protocol (LDAP) -- both work with Unicode.
Authentication systems using Unicode can adapt login screens and management consoles immediately to the locale of the user. The logon screen will translate and display perfectly with all letters, characters and other diacritical marks in the local language.
The problem is knitting together different authentication systems -- sometimes at different levels of technology -- on different platforms.
Here are some best practices to integrate authentication policies around the globe:
- A global authentication policy requires a global authentication system. Inventory all your company's authentication systems worldwide. Most likely, different countries or regions are using different authentication systems because of international growth through acquisition or just different levels of technology between systems in developed and developing countries. This may be easier said than done in large global organizations spanning dozens of countries on multiple continents.
Of course, in a large enterprise, a new authentication system can't be rolled out over night. It could take years and needs to be done by region or country. Either way, settle on one directory service, such as AD or LDAP, and roll that out globally.
- Choose a standard naming convention for all user IDs around the world. Again, in different countries, the format of user IDs may be different. In one country or region it might be mix of letters and numbers based on some local system. In another, it could be all numbers based on the local human resources database used in that country. Pick a single system, preferably based on a global database of users. Again, AD and LDAP are ideally suited for this purpose.
- Use an access management provisioning tool that supports internationalization and meshes with directory services like AD and LDAP. For example, BMC Identity Management for .NET and AD can enforce authentication policies, and has native support for English, French, German, Italian, Spanish and Traditional Chinese. But it uses Unicode for other languages and, since its management console is Web-based, it adjusts to the locale of the user's browser.
BMC works directly with AD objects for enforcing authentication policies. This is key for making sure authentication policies are following uniformly around the world.
- Make sure your system is Unicode enabled. Just importing character sets, particularly for Middle Eastern and Asian languages, may prevent translation of application code, let alone authentication credentials. Individual character sets not based on Unicode can appear as little boxes if not rendered properly.
- The authentication system should be mirror-aware. Hebrew and Arabic, and some Asian languages, are read from right-to-left. Your authentication policy needs to be able to go the other way too.
Where things gets sticky is in secondary authentication systems used to beef up user IDs and passwords. An example is security questions used to reset passwords. The classic mother's maiden name question doesn't work in Latin America or the Middle East, where many people have two or more last names. The question about the user's high school can be confusing in China and Europe, where the secondary school system is different than its U.S. counterpart. And questions about pet names mystify people in countries where animals are only used for farming and aren't allowed in the house.
If adopting a global set of security questions is a problem, either don't use them, or let each country or region choose its own. This issue aside, with built in internationalization support in existing directory services, your global authentication policy enforcement can parallel your domestic policy.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant and speaks six languages, including two with non-Western alphabets (Hebrew and Arabic). He is a Microsoft MVP, specializing in Web and application security, and is the author of The Little Black Book of Computer Security, available from Amazon.com. He has a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at
 |
