Single Sign On

What is single sign on?

Single Sign On (SSO) (also known as Enterprise Single Sign On or "ESSO") is the ability
for a user to enter the same id and password to logon to multiple applications within an
enterprise. As passwords are the least secure authentication mechanism, single sign on
has now become known as reduced sign on (RSO) since more than one type of
authentication mechanism is used according to enterprise risk models.

For example, in an enterprise using SSO software, the user logs on with their id and
password. This gains them access to low risk information and multiple applications such
as the enterprise portal. However, when the user tries to access higher risk applications
and information, like a payroll system, the single sign on software requires them to use a
stronger form of authentication. This may include digital certificates, security tokens,
smart cards, biometrics or combinations thereof.

Single sign on can also take place between enterprises using federated authentication. For
example, a business partner's employee may successfully log on to their enterprise
system. When they click on a link to your enterprise's application, the business partner's
single sign on system will provide a security assertion token to your enterprise using a
protocol like SAML, Liberty Alliance, WS Federation or Shibboleth. Your enterprise's
SSO software receives the token, checks it, and then allows the business partner's
employee to access your enterprise application without having to sign on.

Single sign on federated authentication also works with your employees. For example, an
employee who is trying to access your outsourced benefits supplier to update their
benefits information would click on the benefits link on your intranet. Your enterprise's
single sign on software would then send a security assertion token to the benefits
supplier. The benefits supplier's SSO system would then take the token, check it and
grant access to your employee without making them sign on.

Single Sign On Benefits

Single sign on benefits are:

 • Ability to enforce uniform enterprise authentication and/or authorization policies
across the enterprise
• End to end user audit sessions to improve security reporting and auditing
• Removes application developers from having to understand and implement
identity security in their applications
• Usually results in significant password help desk cost savings

Since the internet is stateless, this means that the single sign on software must check
every request by the user's browser to see if there is an authentication policy pertaining to
the resource or application the user is trying to access. In a medium to large enterprise,
this means that every time the user clicks on a different URL, there is traffic between the
user's browser, the web or application servers and the security server. This traffic can
become large and cumbersome from a performance perspective. Therefore, most modern
single sign on systems use LDAP (Lightweight Directory Access Protocol) directories to
store the authentication and authorization policies. The LDAP directories are made for
high performance lookups thus addressing the high traffic load. Further, the LDAP
directories are often the source for the single sign on system to authenticate against.

Single sign on systems in medium to large enterprises can become a single point of
enterprise failure if not properly designed. If the single sign on system goes down but the
applications remain up, no user can access any resource or application protected by the
SSO system. Many enterprises have experienced this painful condition resulting in
productivity loss. Therefore, it is essential that your enterprise single sign on system have
a good and well tested failover and disaster recovery design.

Finally, single sign on systems in medium to large enterprises requires good identity data
governance. Enterprise security features being offered by the single sign on system is
only as good as the underlying identity data. Thus it is critical that all enterprise identity
data have good, quick business processes that pick up on any change to the identity such
as new identity creation, identity termination or role changes. Without this, enterprise
SSO systems are vulnerable to creating enterprise security holes.

Password Authentication

In most enterprises, the use of passwords is the primary means of authenticating a user.
Unfortunately, it is also the weakest form of authentication. In today's digital world, the
ways to bypass this form of security are trivial. While many enterprises focus on
strengthening passwords, these efforts are by and large meaningless in the face of the
tools that attackers can use. The tools provide criminals with easy ability to hack, trap, or
crack most passwords easily.

The first attack tool against password authentication is a hardware keyboard logger.
Legally available online for $40, these devices plug into the connection between the
keyboard and the computer. They record every keystroke, with some models able to do
time and date stamps against the data. A hardware keyboard logger looks like a small
hardware piece of computer connections, takes only 10 seconds to install and is not
detectable by any means of commercially available software.

Organized crime uses hardware keyboard loggers frequently. In 2005 a group of

criminals out of Israel hired some janitors in the UK to place these devices on the
computers in a bank. The soon captured the password authentication for key bank
officials. They were only caught when they were in the process of transferring $250
million pounds to their bank account.

High school students use these too. Last year in the US there were several reported cases
where students had used hardware keyboard loggers to obtain their teachers and
administrators' password authentication. They were only caught after selling exam papers
and in one instance, having changed final marks over two years to enable students to get
into university.

The use of password authentication is further weakened by software attacks. This year
alone, it is estimated that there will be several thousand different malware password
logging attack programs will be created. Some of these are very sophisticated and can be
ordered by the internet to attack certain types of firewalls. These password authentication
logging software programs are embedded in email that are activated by clicking on the
links in the email or by visiting a fake site that looks like the normal commercial site
(phishing attack).

Today, authorities believe that there are betwen 20-40 million infected computers in the
United States alone. Some of the password authentication attacks are so sophisticated that
there embed themselves on the core root operating systems kernel (rootkit attacks).
Rootkit attacks are now acknowledged by Microsoft to be so insidious that the only way
to remove them is to re-image every computer on the infected enterprise network!

Large commercial organized crime web gangs have developed keyboard logging software
such that it will recognize the user's bank id and authentication passwords you enter when
you logon to your bank's website to conduct a transaction. The id and password
information is then sent within seconds to the organized crime servers somewhere in the
world. They are then auctioned off, via the internet, to other organized criminals. The use
of the id and password is then quickly used to begin emptying your bank account.

Finally, the use of passwords to protect Word, Excel, Outlook, Adobe and other types of
documents can also be very easily broken. There are a number of legally free online
services that provide decryption services in less than three minutes for most types of
document encryption for $29 per document. If this won't work, then you can spend $40-
150 and download good decryption methods. This includes dictionary attacks, in multiple
languages that can try to decrypt the document at over 75 million passwords per minute.
Most low level password encryption schemes can be broken in 24-76 hours.

I hope that this point in the article that I have scared you enough to realize that protecting
your enterprise's most sensitive high risk information and/or applications via passwords
as the prime authentication method is foolish. The password attack methods (hardware,
software and social engineering) mean that your enterprise applications are highly
vulnerable to attack when using passwords.

Does this mean that passwords shouldn't be used in your enterprise?

No. The use of passwords can be used in a layered identity defense strategy. What this
means is that your enterprise will allow the use of user id and password to gain general
access to low risk enterprise applications and information e.g. the enterprise portal.
However, when the user tries to access applications or information that is higher risk, the
enterprise single sign on system will require stronger authentication. This may include
the use of security tokens, digital certificates, biometrics, smartcards or combinations
thereof in addition to the password

SSO and LDAP Authentication

Why use LDAP Directories for LDAP Authentication?

Lightweight Directory Access Protocol (LDAP) directories and LDAP authentication

have become one of the enterprise user infrastructure cornerstones. As the enterprise has
digitized and opened itself up to customer, business partner, vendor and wide-spread
employee access to pieces of most enterprise applications, the need to know who the user
is has significantly increased from a security perspective. Who is the user trying to access
an application? What is the strength of authentication by which the application can trust
the user trying to access the application? What are the user's authorization privileges?

The frequency with which to authenticate who a user is has also increased. Thus in
medium to large enterprise it is not uncommon to have several thousand to several
hundred of thousand identity look-ups per second.

The above are the reasons why LDAP directories and authentication have taken on such a
dominant role in enterprise authentication. LDAP directories offer the following features:

• They are very quick for doing identity reads against as compared to traditional
databases
• They are low cost - in fact some LDAP directories are available for free
• Virtual LDAP directories enable quick linkage between multiple databases and
multiple LDAP directories
• LDAP directories are excellent for doing rapid LDAP authentication against for
any digitized authentication
• LDAP directories have a universal protocol enabling quick interaction and
exchange of identity information between enterprises
• LDAP directories can be easily partitioned to place the directory close to the end
user, thus improving performance and reducing network load
 Underlying Key Points in LDAP Authentication

Authoritative Identity Sources

In most medium to large enterprises, the authoritative source for employee information is
usually the Human Resource Management System (HRMS). Figuring out what system is
authoritative for customers, contractors, temps, business partners and vendors is usally
much more complicated.

It is very important before LDAP authentication is implemented the enterprise first

determines which system or application will be authoritative for the identity data. This
also means cleaning up the associated business processes dealing with identity creation,
role changes and terminations. Often the authoritative identity source will have many
identities in their data stores listed as active who are no longer active. This can create
security holes in any LDAP authentication.

Unique Enterprise ID

Next it's important that in cases where multiple data sources have the same identity
information that a universal identity id be deployed. For example, if a user named John
Jones is in the HRMS as J Jones, in the payroll system as John Jones, in the shipping
system as JJONES etc, then it becomes important to know at the enterprise level a
common id for John Jones. This usually means creation of a unique alphanumeric id for
each user. Without this, the enterprise LDAP authentication won't work since John Jones
won't know which id to use in authentication. Further, the handoff to the applications
after LDAP authentication won't work since the LDAP directory has to communicate
with the application that John Jones has successfully authenticated.

Linkage of Authoritative Sources with the LDAP Directory

LDAP authentication relies upon the LDAP directory having the most up to date identity
information with which to do an authentication against. This requires that the
authoritative source be linked, at a minimum, on a nightly batch basis, and in many cases,
on a identity event basis. In the old days, of a few years ago, interfacing LDAP
directories with authoritative source data bases was expensive and time consuming to do.
The synchronization of the LDAP directories with the databases was critical and costly.

Today however, LDAP virtual directories are now mainstream tools. A LDAP virtual
directory is one which sits in a virtual environment and has its sources of identity
information derived from pointers to specific tables in data stores or, in other LDAP
directories. LDAP virtual directories can usually be created in several hours or a few days
and put into operation very quickly.

Authentication Strength
There are many ways of authenticating a user. These range from the id and password
(commonly referred to as "basic authentication"), digital certificates, security tokens,
smart cards and biometrics. There are different reasons to use each type of authentication
(refer to the authentication strength portion of this website).

Once you have determined the type or types of authentication your enterprise is going to
use, then you are ready to begin doing LDAP Authentication.

LDAP Authentication in Practice

LDAP authentication is now very common in network operating systems. Microsoft uses
this in Win2003 with it's Active Directory. All network operating systems today support
the integration of LDAP Authentication including Solaris, Novell, AIX, Linux and
HPUX.

In each of these cases, the user usually enters in their id and password. The information
may be presented as an online form or simply have an entry point for the id and
password. This information is then sent to the LDAP directory (make sure the
information is sent encrypted and not in open text).

The directory takes this information and compares it to the id and password stored in the
LDAP directory. If it is the same, the LDAP authentication is successful.

In network operating systems, the network then takes over and proceeds with user
authorization and allows them to use the network.

LDAP Authentication and Single Sign On

Single Sign On (SSO) systems mostly use LDAP authentication. The enterprise user logs
on in the morning and sees normally a form based enterprise login screen. The user enters
in their id and password. The SSO software then takes the information and sends it to the
security server using an encrypted connection. The security server in turn then logs on to
the LDAP server on behalf of the user by providing the LDAP server with the user's id
and password. If successful, the security server then proceeds with any authorization
and/or lets the user proceed to the application or resource they require.

LDAP Authentication Implementation

Often times a simple LDAP directory authentication project hits trouble. These can be
because of:

• Poor authoritative sources

• Poor identity data
• No unique global id's
• Poor synchronization between the authoritative source and the LDAP directory
• Poor design of the LDAP and SSO authentication strength
 • Poor design of the LDAP and SSO failover and disaster recovery

Having a good knowledgeable consultant early on in the design process can save your
enterprise significant money and time while guiding you to avoid creating security holes
with your SSO LDAP implementation.

SSO Strategy and Policies

Before beginning implementation of a enterprise single sign on project, a lot of thinking

and planning must go on. This requires a cohesive SSO strategy and a set of governing
SSO policies. Many projects don't do this and drift into unexpected security holes, SSO
system and enterprise failures and frequently go over project budget. A good SSO
consultant can help you avoid this.

Here are the areas a single sign on strategy must address:

Identity management

• Which systems are authoritative for each identity type i.e. employees, contractors,
consultants, temps, customers, business partners, research partners, vendors and
others?
• Identity data quality for each identity type - How good or bad is the data quality?
Do you want to have the SSO system allowing users to access applications and/or
resources when they shouldn't?
• Enterprise global id for each identity type - is there a unique enterprise global id
in place? The SSO system requires this.
• Identity data update - how long does it take for a change to user data to make its
way to the enterprise LDAP directory or directories? Is there a risk to SSO
decisions?
• Authoritative source synchronization with enterprise LDAP directories - how
frequent is the change and is this acceptable to enterprise SSO security?
• User provisioning processes- What are the costs, time and security implications
for creating, modifying role changes and terminating of the user? Is there a risk to
single sign on systems as a result of existing processes?
• Regulatory compliance - What are the regulatory laws and reports required by the
enterprise pertaining to the user e.g. Sarbanes-Oxley, HIPPA, European Safe
Harbor, etc.
• How are regulatory identity reports generated and what is the expense?

Authentication schemes

• Is there an enterprise risk assessment done?

• Does the enterprise have a set of authentication strength policies in place?
• What is the security rating for each type of authentication?
 • Is there an enterprise risk analysis done for each application and resource used by
users?
• Is the enterprise risk then mapped to the authentication strength required by the
user?
• How is the authentication strength linked to the single sign on system?

Post Authentication Actions

• What action is required after a successful authentication?

• Is the SSO system required to supply different identity attributes from the
enterprise LDAP directory to the application, portal or resource?
• What are the SSO actions for an unsuccessful authentication?

Authorization

What are the authorization actions, if any, required by the enterprise SSO system after a
successful authentication?

If you are contemplating role based access control then:

• What is the number of roles the enterprise has?

• What is the frequency of change to user roles?
• What is the human resource business processes for picking up the role changes
and populating these into the HRMS and then the enterprise LDAP directory?
• What is the time lag between a role change and the update into the enterprise
LDAP?
• What are the privileges assigned to the roles?
• What is the management system that maps the privileges to the roles?
• How frequently do privileges change for a given role?
• How fast do role privilege changes make there way into the role based
management system?
• How is all of this going to be mapped into the single sign on system?

Post Authorization Actions

What actions do you want the single sign on system to take after a successful
authorization?

• Is there any enterprise LDAP directory user data that needs to be sent to the
application, portal or resource by the SSO system?
• What does the SSO system do with an unsuccessful authorization?

System Integration
 • Do you have in place a factory model for rapidly integrating applications to your
SSO system?
• Are there any policies in place for exception management for applications?
• Are there environment policies set up for each environment such that the
application owner understands what is acceptable and what isn't?

LDAP Directory Strategies

• Is there one enterprise LDAP directory for the SSO or are there multiple
authoritative sources?
• What is the synchronization strategy between the directory (directories) and the
authoritative source
• What is the time lag in changes in an authoritative source and the enterprise
directory feeding the SSO system?
• Are virtual directories required?

Auditing

• What are the enterprise audit requirements for the single sign on system?
• What kind of retention data is required?
• How is the auditing system connected to the monitoring system to report real time
incidents of a security or reporting concern?

Operational Risk

• What is the SSO fail over strategy for the security servers?
• What is the SSO fail over strategy for the directory servers?
• What are the monitoring systems in place at web servers, application servers,
security servers and directory servers?
• How fast can you see a performance problem occurring and react before the SSO
system goes down?
• How are you going to do operational maintenance on a SSO server?
• Will the SSO maintenance affect enterprise availability?
• Is the availability acceptable to the enterprise?
• Are the support people for web servers, application servers, load balancers,
security servers, directory servers, network performance and help desks support
cross trained to keep the SSO system from going down?
• What is the existing SSO disaster recovery plan?
• Is the SSO disaster recovery plan acceptable to the enterprise?

Single Sign On Business Case

Preparing a business case in single sign on is best done by an experienced SSO consultant
since they can quickly do a cost benefit analysis for you and include in the costs realistic
implementation costs versus those told to you by the vendors. There are a number of
areas where the SSO business case can be made.

Help Desk Password Reset Costs

Oftentimes, most of the costs associated with a single sign on project can be recovered by
hard dollar savings involving the reduction of help desk employees. In many enterprises
password reset and password related calls occupy 40-70% of the help desk's work. By
implementing a single sign on system the following can usually be achieved:

• Significantly reduce the number of id's and password's a user has to remember
• Implement automated user password reset

SSO eliminates most of the help desk work and costs related to password resets and
management.

Regulatory Compliance

Part of the Sarbanes-Oxley regulations has to do with ensuring that senior executives
know who is on their financial systems. Additionally, many industries, such as financial,
have regulators wanting to ensure that users are quickly taken off financial systems when
their role changes or the user is terminated.

A single sign on system can help enforce the user role changes and automatically prepare
regulatory reports. The business case is made by showing how a SSO system can reduce
regulatory reporting costs and demonstrate compliance.

Federated Authentication

Cost savings can be delivered for the management of external users coming into the
enterprise systems. Thus if your enterprise has many external contractors, business
partners, vendors, customers, etc, accessing your applications, there is a cost associated
with:

• creating the user identities

• assigning them privileges
• creating ids and passwords for the users
• making user role changes
• terminating the user

A business case can be made by showing how enterprises can offload these costs to
trusted partners. The enterprise will therefore accept certain users whose identities are
created by the partner, their roles assigned by the partner and the authentication at the
partner's own site will be trusted by the federated authentication and single sign on
system.
Improved Enterprise Security

Many enterprise use only ids and passwords to authenticate their users. By deploying an
enterprise single sign on system the following enterprise security benefits can be
obtained:

• Uniform application of enterprise risk policies as it pertains to authentication

• Deploy and enforce stronger authentication where security risk and costs warrant
it
• Remover application developers from the coding of authentication
• Provide user end to end session audits
• Quickly remover user access to applications and resources when their role
changes or they're terminated
• Provide same day user provisioning

Single Sign On Software

There is a wide variety of single sign on software to choose from.

Open Source

In the open source environment, the leading single sign on software is CAS (Central
Authentication Service) developed out of Yale university. However, be warned that this
software lacks the flexibility to deal with a wide variety of authentication devices, which
has been common in commercial software vendors for the past three to four years. It only
accepts id and password and digital certificates.

Further, this software has no built in user provisioning or federated authentication. The
ability to do this requires interfaces with other open source software. This is again a
divergent point from commercial identity management software where identity
management, provisioning, single sign on, federation and regulatory audit reporting are
now integrated packages.

Therefore, if you're on a very limited budget, with lots of development resources

available and, the limitations as expressed above are not a problem, then use CAS.

Hardware/Software Plug and Play SSO

The next step up the ladder are hardware/softare servers which can be rapidly deployed
"plug and play" to provide single sign on. the best example of this is Imprivata. Their
devices can work with legacy systems, be rapidly installed and provide single sign on.
Their product also works with mutliple authentication devices to enable stronger
authentication. Theire product does not however provide provisioning and federated
identiifcation services. As a quick fix to existing single sign on issues it is very good but
limited in providing an integrated suite required to address the enterprise identity
management problems.

SSO Identity Management Suite Vendors

Then there are the top tier identity management vendors, all of which have single sign on
included in their product suite. These include Oracle, Sun, Computer Associates, HP,
IBM, Novell, Entrust and RSA amongst others.

The product suites usually incude the ability ot do delgated identity administration,
identity provisioning and deprovisioning, single sign on, federated identities, regulatory
compliance reporting and various role based access control. Not all packages are equal.
Caveat emptor. Hiring a knowledgable identity management and single sign on
consultant can avoid unnecessary expense, years of frustration and the creaiton of
security holes through poor deployment of the product.

Finally, there is one company that focusses on federated identities and authentication,
Ping Identity. Ping focuses on creating an external identity bridge between disparate
identity management systems. It is an excellent choice for doing identity federation either
internally between different business units or between your enterprise and others.

Single Sign On Management

Getting the single sign on system operational is only the beginning of the challenges. I
can guarantee that no vendor sales agent will be focusing on this when they are trying to
sell you the software. Their adage usually is "the SSO software will take care of it".

Unfortunately, the SSO software won't take care of many essential things that the
enterprise must address. These include:

• How to move applications between the single sign on environments (usually

Development, Test, QA, Pre-production and Production)
• When you have hundred or several hundred applications in SSO how do you find
the security rules pertaining to each application?
• What are the environment policies pertaining to each SSO environment?
• What can the application owner do and not do in each SSO environment?
• What is the migration business and technical processes for SSO migration?
• What are the processes to create a "Single Sign On Factory"?
• How long is it going to take to integrate several hundred or thousand applications
into the environment?
• What is the business approvals required?
• How much of the process can be automated?
• What is the labor cost per application to be integrated?
• What is the governing body for the SSO system?
 • Who approves what type of authentication strength the enterprise will support in
SSO?
• What are the change management processes for implementing routine
maintenance?
• How are application owners informed of upcoming SSO feature enhancements?
• What is the management approval process for implementing a SSO hotfix?
• What is the governing body for enterprise user data?
o An enterprise identity data governance body needs to regulate how
changes are made by the authoritative sources to those attributes used by
enterprise systems
o You need to avoid having systems come crashing down when an
authoritative source makes an unannounced change to an identity attribute
resulting in other systems, like SSO, crashing when a new unexpected
value shows up in the user attributes
• What are the SSO monitoring systems deployed?
o This must include dashboard real time reporting for web and application
servers, load balancers used in front of security and directory servers,
security servers and directory servers.
• What is your uptime allowance for SSO?
o If it is very high, then how will your failover strategy keep it up?
o Has it been tested?
• What is your strategy for doing routine maintenance on the SSO and directory
servers?
o Will this impede availability?
• What are your disaster recovery processes for the SSO system?
o Will this provide for real time disaster recovery or, will it take 24-96
hours?
o Does the CEO realize the implications to their enterprise if the SSO
system goes down?

A knowledgeable SSO consultant can help address and plan for the above in the early
stages, thus avoiding addressing these problems after the deployment team has left and
significant problems have occurred

SSO Federation

SSO Federation has come of age the last four years. The emergence of widely adopted
federation protocols such as Security Assertion Mark-up Language (SAML), Liberty
Alliance, WS Federation and Shibboleth has see wide spread enterprise adoption. The
adoption has been spurned on by the inter-operability of these protocols with each other.

Therefore, today it is possible to federate identities and single sign on with some degree
of technical ease. This assumes that you have in place a single sign on system capable of
supporting these protocols.
Slowing down adoption has been the legal contracts that must be created to use federated
identities. Liberty Alliance has published guides to doing this. As the years progress, the
legal contract issues for each enterprise will lessen as enterprise adopt this in their
existing contracts with customers, business partners, suppliers, vendors, contractors,
consultants, temporary agencies and research partners.

Example of SSO Federation

Large enterprise with several separate business units

It is quite common to have several separate business units in large enterprise each
running their own single sign on systems. It is quite easy, using a product link Ping, to
quickly accept levels of trust for authentication from one business unit and pass the user
on to applications and/or information managed by another business unit without requiring
re-authentication and/or the need for additional ids and passwords. This achieves single
or reduced sign on for the user while reducing enterprise user management costs. This
requires little additional hardware and software and can be done quite quickly.

Between your enterprise and business partners or customers

Often times your enterprise will have many customers or business partners who are
accessing one or many of your internal applications. Depending on the degree of trust
you have with these other enterprises, you can use federated authentication with them.

For example, Susan, a business partner's employee will logon to the business partner's
systems. When she clicks on a link to an application in your enterprise, the business
partner's single sign on system creates a security assertion and passes this to your
enterprise. Your enterprise's single sign on system then takes the assertion, reviews it,
and if accepted grants Susan access to the application without requiring her to logon.

This reduces your overall user management costs by not having to grant Susan with a id
and password. It makes Susan's work life easier by not having to remember another id
and password.

Further, the single sign on system can be used to require stronger authentication. For
example, Susan may be granted access to low risk applications. However, when she
clicks on a high risk application, the SSO system may require her to re-authenticate using
a stronger authentication mechanism such as a digital certificate, security token, smart
card, biometric or combinations thereof.

Between your enterprise and outsourced providers

It is quite common for enterprises today to have outsourced portions

of their internal processes. Examples include inventory
management, benefits, 401k management, training etc.

When your employee clicks on a link to one of these functions, say

their benefits plan, your enterprise SSO system prepares a security
assertion and sends this to your benefits supplier. Their internal
SSO system reviews the assertion and if accepted grants your
employee immediate access to their information without having to
login in using a id and password issued from the benefits supplier.

This provides your employees with ease of use. It also reduces the
benefits supplier's management costs in issuing ids and passwords.

Ping Identity federation is an excellent product to use to quickly

build federated authentication trust between disparate SSO and
identity systems. Other identity product vendors also have identity
federation products in their product suites.

A more detailed discussion about federation protocls can be in

Authentication Federation.

Enterprise Single Sign On (ESSO)

Most enterprises begin their single sign on projects focussing on Web Based Single Sign
On (WSSO). This addresses all applications that use a web browser to logon to the
applications and are normally LDAP enabledWhy not do all applications in the beginning
(called "Enterprise Single Sign On" or "ESSO")?

The reasons are normally cost. Web based single sign on systems are relatively cheaper
to install. They're less expensive because it only requires a small piece of code to be
installed on each web or application server that intercepts all traffic to the web or
application server and redirects the url enquiries to the security server. The security
server then determines whether the resource is protected or not and if so, what is the
authentication and authorization policy pertaining to it. As a result, WSSO systems can
be relatively easily designed to scale. Security and LDAP servers can be easily placed in
the network to handle the workload.

Enterprise Single Sign On (ESSO) has been until recently, relatively more expensive to
deploy. In ESSO the applications are usually mainframes where there is no web based
LDAP authentication. This normally involves the deployment of proxy servers and more
complicated code in the network. These systems are more expensive to scale since the
proxy servers always need to be added.

There are some new ways emerging to deal with ESSO. It's what I call "fudged" single
sign on. Today, you can buy XML based SSO appliances, that quickly install in the
enterprise racks. These devices monitor what the user accesses and the id and passwords
used to access the applications. It then maintains a centralized list of the ids and
passwords and uses these to authenticate on the user's behalf. A small amount of code is
deployed on the user's computer that in turn communicates with the hardware appliance
in the enterprise rack. From an end user's perspective, they have achieved single sign on.

Recommended ESSO vendors are Passlogix and Imprivata.

Access Control Authentication