[Date Prev][Date Next]
Re: Single Sign On
The short answer to your question is 'not very well'. In general there are
several ways to implement Single Sign-On, and I'll discuss three of the more
common ones here.
The first implementation uses a centralized authentication system like
Kerberos or DCE and a client-side API that provides an interface to the
authentication services. The idea here is that a user logs into a central
authentication system and obtains a general use "ticket" for authentication
purposes. Each application that needs to identify the user will use this
ticket in conjunction with a local authentication API to obtain a credential
that lets it identify the user. Every application must be engineered to
obtain an authentication token using this API, something that is usually
impractical. There are several variations on this scheme, but they all work
in the same basic manner. As security goes, Kerberos and DCE are pretty
good, but they are invasive and difficult to manage and maintain.
The second implementation is a bit more pragmatic and takes into account the
fact that one is not going to reengineer existing applications that already
make use of username and password pairs. Typically a client is installed on
the same system as the client software. Today most client software runs on
MS-Windows platforms, and so the largest number of commercially available
Single Sign-On clients run in a Windows environment. The client software
identifies the user somehow, often against some centralized database, and
then sits in the background and watches for window opens. Here's a common
rub: each application has different authentication windows and so SSO
clients need to know what windows to look for and which fields in those
windows to populate with username and password information. This is usually
configured manually by the system administrator and can get fairly involved.
When the SSO client recognizes a window it looks up the user's username and
password for that application, usually from a centralized database but
sometimes from a local store, and enters it in the correct fields. It then
simulates pressing the OK key and the visual effect is often as though no
sign-in took place at all.
There is a new breed of SSO client that is capable of attaching to web
browsers and parsing HTML forms. The idea is to look for username and
password fields in web site logins. These clients generally operate along
the lines of the second implementation described above, but they keep the
username and password cache on the client. The Web-SSO clients that are in
wide release today are not appealing to businesses because IT organizations
often prefer to keep usernames and passwords in places where they can be
better protected from loss (i.e., centralized stores).
Enterprise single sign-on solutions require good control of the user
population because most often they are operated by the IT staff. Good
control means that there is a good password synchronization mechanism to
keep passwords synchronized between the SSO store and the security systems
that use them, and the best solution is to deploy an integrated user
management package that shares its information with the SSO system.
Finally, it is important that any of these types of systems have good, solid
security. Many of the packages on the market today give only a passing nod
to security and make the mistake of assuming that the intranet is a safe
enough environment. These packages often do things like putting passwords on
the network without encryption. The result is a set of limited products that
cannot leverage the Internet as a communication medium due to security
With appropriate additions, OpenLDAP provides an excellent foundation for
distributed enterprise user management and single sign-on. We have combined
OpenLDAP, OpenSSL, and other open technologies with purpose-built management
software and LDAP technology to produce a world-class Resource Access
Management system with integrated Single Sign-On. The Connexitor e-Business
Management Suite helps enterprises ensure that their employees and
e-business partners have a clear path to corporate computing resources
(applications, computer systems, etc.), as well as physical resources that
are controlled by computer systems (cardkey-type locks, phone systems, etc.)
in a way never before possible.
Connexitor consists of a set of linked LDAP directories that each perform a
specific function. Some LDAP directories, called agents, use the actual
managed security systems as their data stores, so any LDAP transactions
directed at them result in changes to the security systems themselves.
Conversely, anytime one is searched the information returned reflects the
actual state of the security system. LDAP modify operations actually change
the underlying security objects, and some objects, like accounts and groups,
can be added and deleted. A specialized directory ties all of the LDAP
agents together into a coherent whole, and adds correlation and automation
capabilities to the product. Finally, command-line and web-based tools
provide easy access to Connexitor's functions.
Single Sign-On is implemented using a window-watching client that
authenticates itself using Connexitor's public key system and makes queries
to the correlation directory whenever it recognizes a window and a set of
text input fields. If the right object is found, its attributes are used to
populate the inout fields and the authentication is complete without any
Communication between all Connexitor components is authenticated and
encrypted using public key technology, making it extremely difficult, if not
impossible for hackers to eavesdrop and use it as an entry point to other
systems. Careful attention has been given to security in general, to provide
the maximum amount of protection possible in a given environment.
As you can see there are a number of ways of doing Single Sign-On, and you
can see from our experience that the Open Source software certainly has a
place in all of this. We found OpenLDAP to be extremely useful in developing
Connexitor, but we had to do a lot of development to make it into a
commercial-strength solution. I am also not aware of any other LDAP-based
single sign-on clients, open source or otherwise.
I hope this helps...
Vice President and Chief Technology Officer
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Praveen
> Sent: Wednesday, July 19, 2000 11:05 AM
> To: openldap-software@OpenLDAP.org
> Subject: Single Sign On
> Hello Sirs,
> I wanted to know how Single Sign On is implemented in a corporate
> environment.What are the opensource software available to
> implement such a system.
> Praveen Khurjekar