Enterprise Single Sign On


Single Sign-On (SSO) 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.

Types of SSO

Enterprise Single Sign-On

Although few, if any, of the more modern computing solutions being developed today use the client/server model, many existing legacy client/server applications can still benefit from Desktop SSO. While many companies successfully addressed the SSO problem for Web applications, end users still must log into their Windows desktop, log into their mail client, log into corporate chat applications, log into human resources systems, and the list goes on. A complete SSO solution must address desktop SSO.

Web Single Sign-On

The predominant computing model today is the Web model, involving HTTP/HTTPS transactions with applications on Web servers, application servers, or both. Many legacy client-server applications are being converted over to the Web model and virtually all new applications are Web-based. With the rapid introduction of new Web applications, each requiring user authentication, companies must adopt a login management strategy or risk overwhelming their user population and consequently reducing security.

Federated Single Sign-On

Many businesses are moving toward federated configurations to cost-effectively introduce partner-hosted capabilities into their customers' Web experiences. These environments typically involve a business that has partner relationships, where the partner is not necessarily using the same software as the business itself. Consequently, it is essential that federated software supports the latest interoperability standards used in SOA-based environments: SAML, Liberty Alliance, and WS-Federation. Federated Single Sign-On protocols like SAML define methods for securely transferring a user's identity between security domains over the Internet. This typically involves a pair of companies who have formed a business relationship in which one company is consuming a service from the other. This transferring of the identity means that a service provider need not manage passwords and the user can access external services without having to authenticate again. This is what is known as federated Single Sign-On.

With employees accessing many different resources over the Internet to do their daily jobs, organizations need to maintain a secure working environment while ensuring users remain productive. Single Sign-On (SSO) is ideal for achieving both objectives. However, traditional SSO products were never designed to be used over the Internet with one organization managing user's identities and a different, independent organizations providing the user's applications.

Internet SSO, as the name implies, is Single Sign-On that works across the Internet. It allows users with Web browsers to securely and easily access multiple Web applications while only logging in once, even though the applications are most likely managed by different organizations. The key to implementing Internet SSO is a technology and a set of industry standards called "federated identity". Federated identity allows identities to be shared securely across disparate networks and applications. It is the "glue" that enables Internet SSO to occur at scale.

Federated identity is the glue that enables Internet SSO to occur at scale across numerous identity providers and service providers.

In order for identity federation to work, a few prerequisites must be met. First, users must be authenticated by an organization such as their employer or a hosted authenticator such as Google Apps. The organization that "owns" the users' identity is known as the Identity Provider or IdP. Identity federation also assumes that another group or organization owns the data and applications that IdP users need to access via Internet SSO. These organizations are known as Service Providers (SPs). Both the IdP and the SP need to be running federated identity software that supports the same federation protocol so the IdP and SP can communicate.

When a user wants to use federated identity to SSO into an application, all they have to do is click on a hyperlink or a shortcut to get directly into their application. If they are not already logged in to their IdP, they are prompted to do so before they are automatically redirected into their application.

The underlying system that makes this secure Internet SSO operation possible is completely invisible to the end user. Under the covers, when the user clicks on the link, the IdP securely communicates a predefined set of facts about the user called attributes to the SP so the SP can set up a Web session for the user.

Several different federated identity standards have been created over the years to address different use cases. By far the most widely deployed and popular federated identity standards is OASIS Security Assertion Marketing Language (SAML). SAML has emerged as the predominant standard for most businesses, government organizations and their service providers.

A similar and related standard, WS-Federation, continues to be found in Microsoft-centric environments. Newer protocols including OpenID, OAuth and CardSpace are attracting some interest for so-called user-centric use cases. Without these federated identity standards, each Internet SSO connection would have to be individually negotiated and engineered—think of the days before TCP/IP became the common protocol for networking.

Enterprise Single Sign-On System

Enterprise Single Sign-On provides services to store and transmit encrypted user credentials across local and network boundaries, including domain boundaries. SSO stores the credentials in the Credential database. Because SSO provides a generic Single Sign-On solution, middleware applications and custom adapters can take advantage of SSO to securely store and transmit user credentials across the environment. End users do not have to remember different credentials for different applications.

These services enable you to integrate multiple heterogeneous applications and systems in the enterprise environment. These applications and systems might not use common authentication. Each application has its own user directory store. For example, in an organization, Windows uses Active Directory directory service to authenticate users, and mainframes use IBM's Resource Access Control Facility (RACF) to authenticate the same users. Within the enterprise, middleware applications integrate the front-end and back-end applications. Enterprise Single Sign-On enables users in the enterprise to connect to both the front end and back end while using only one set of credentials.

Password security management can be a major headache for users and enterprise IT departments alike as password policy can cause frustration for users when they have multiple passwords to remember. End-users often write their passwords down and leave them by their workstation - a serious enterprise security issue. Or they forget their passwords and have to put productivity on hold while they make costly calls to the IT help desk to perform a password reset.

Enterprise Single Sign-On (SSO) solutions can potentially resolve these issues by enabling users to sign in just once to the network and have access to all the applications they are authorized to access - eliminating password headaches and enabling productivity. But some enterprise Single Sign-On solutions raise as many issues as they promise to solve - the cost of purchase can be quite high, and the complexity of implementation and management can overwhelm IT departments. When savvy organizations want to deploy an enterprise Single Sign-On solution that offers all the benefits of Single Sign-On and is affordable and easy to manage as well, they turn to intiGrow.

Web Single Sign-On

The Web is made up of portals which act as gateways to many layers of web sites. Some portals have a unique focus, while others try to be all things to all people. A portal is often the front-end to a lot of different enterprise applications that converge in one Web based user interface creating an organizational single point of presence. When the Web first evolved, Secure Sockets Layer (SSL) was sufficient for passing encrypted passwords via a browser because Web security was based on protecting URLs, not applications. As applications and databases started being attached to the backend of URLs, it became clear that SSL had limitations.

SSL is CPU intensive and, for the most part, a server can support only a limited number of SSL handshakes. In some cases, SSL accelerators can resolve this performance problem. However, SSL cannot create a user experience, where on a front-end portal, the user puts in one password, and all the other applications on the backend of the portal receive authentication information about that user. A properly implemented Single Sign-On solution will write the front-end authentication through to a central management console on the backend, and share this information between applications for the extent of the user session. Also, SSL only can work between two endpoints, so if a transaction involves three parties such as a customer, a merchant, and a card issuer, you cannot use SSL.