Quick Links
Helpful Links
Single Sign On and Cross-Domain Authentication
ChallengeSingle Sign On (SSO) is a common requirement in many environments, and is a powerful security tool that minimizes the transmission of important credentials across a network. Many applications can take advantage of the Kerberos framework built into Microsoft Windows and Active Directory, allowing users to make use of their domain login to control their level of access to various infrastructure components and to handle authentication on their behalf. But, while Kerberos is useful in a single domain or in a forest where many trust relationships have already been established between Active Directory instances, it is very easy to think of a variety of scenarios where handling authentication using the traditional Kerberos approach used in Active Directory is just not going to measure up.
There are some applications that just aren't Kerberos ready. And, of course, there are many LDAP servers that haven't been configured to make use of Kerberos for authentication, and with that there are applications that are only designed to authenticate using Kerberos. Even with a fully Kerberos enabled environment, there are situations where users from separate domains need access to a service, but the trust relationships do not exist across all of the domains to allow for a simple Single Sign On implementation. With the rise of applications that facilitate the sharing of data, such as Microsoft Sharepoint, these situations are becoming increasingly common.
Solution
Symlabs Virtual Directory Server is fully capable of integrating with both Kerberos enabled clients and Kerberos enabled servers, using its built-in GSSAPI functionality. By creating SASL/GSSAPI enabled listeners, the proxy engine is capable of fully integrating with Kerberos enabled client applications. And equally, the proxy is able to authenticate using Kerberos on any backend that supports it.
This means that Virtual Directory Server, is capable of handling cross-domain authentication, even if there are no trust relationships between domains. This provides the perfect solution for applications that need to be authenticated across a variety of domains. By simply adding the Virtual Directory Server instance into the Kerberos realm for each domain, you create a trusted bridge that users from each domain can use to gain access to resources that you wish to share across domains.
Due to the Virtual Directory Server's built-in Kerberos support, you can easily integrate client applications that expect to be able to authenticate using Kerberos with directory servers that may not have kerberos enabled. Equally, where a directory server will only facilitate particular access rights to users that have been authenticated using Kerberos, it is possible to use Virtual Directory Server to provide this level of access to client applications that may not support Kerberos.
With Virtual Directory Server's versatile scripting language that allows for custom development within the staged processing model, it is very easy to develop Single Sign On solutions for nearly any situation you can envisage, even if you are unable to take advantage of the built-in Kerberos functionality that is provided out-of-the box.
The product also includes a detailed guide to Kerberos, GSSAPI and SASL to help you get your head around the complexities of these technologies, and to better understand the configuration options that are available to you.