Understand the core concepts of extending single sign-on from Enterprise to cloud

Single sign-on (SSO) allows companies to implement access control policies across multiple applications in a consistent manner. In this article, the author describes the core concepts of extending SSO from Enterprise to cloud. explores several different mechanisms for implementing SSO between traditional and SaaS applications running in your datacenter.

Single sign-on (SSO) is an important service that most large enterprises provide to their users (employees, partners, customers, and contractors). In an era of increasingly stringent IT security systems, the use of SSO technology enables companies to implement access control policies across multiple applications in a consistent way, reducing the overall cost of implementation. These policies may include password length, password complexity, long password usage, and reuse of previous passwords. No matter what rules or policies an application must adhere to, you need to implement it once and reuse it later. Authentication and auditing are also simplified for systems leveraging this SSO infrastructure.

In addition to IT compliance, significant risks can be avoided. How many times have you passed the distribution room (cubicle Isles) and seen a note with a password? What is your personal choice for remembering hundreds of passwords per enterprise system? Having SSO throughout the enterprise allows your users to remember only one password, which reduces the risk of pasting passwords into the wall of the distribution room and reducing the risk of password sharing. If your e-mail, human resources benefits system, and other systems use the same password, it is not possible for a user to share that password with his or her colleagues.

In terms of cost savings, it has been proven that SSO can get a direct return on investment by reducing the number of help desk calls. Fewer different passwords means that someone calls the help desk less often because they forget their passwords. Several Internet articles and reports from companies such as Gartner and Forrester Studies say the number of calls can be reduced by 40% to 70%.

Components of SSO

Let's first look at some of the basic technical components needed to support SSO:

users. A user Web application that is trying to log on. An application that the user is trying to log on to

For this article, think of the application as any Java™, microsoft®.net, PHP Web application, or software as a service (SaaS) application, such as Salesforce.com, Google Apps, Microsoft Office 365, Concur, ServiceNow or Workday.

WEB application Proxy. Non-SaaS applications running in enterprise data centers are typically installed on the WEB or application server hosting the application. The policy server/sso the server. Provides a partial directory of software that implements all the features and features required for SSO. The underlying repository that stores user names, passwords, and other properties of users

In most organizations, you will see Active directory®domain Services or other directory software that implements Lightweight Directory Access Protocol (LDAP). Although not a best practice, you can also use relational database tables.

Figure 1 shows the actual application of these components.

Figure 1. Advanced components of SSO

This article focuses on SSO (not desktop SSO or Enterprise SSO) for web-based applications. At a basic level, the web-based SSO principle follows the schema shown in Figure 1. Let's use an example to more specifically analyze the diagram below.

Two important components required for SSO: Policy/sso Server and WEB application proxy. A policy server/sso server is often called an identity decision Point (IDP). IDP determines whether the user credentials (username/password) are correct and whether the user can log on. Each large enterprise software vendor may provide some technology or product in this area. Top-level solutions in this area include ibm®security access Manager for Enterprise single Sign-On, CA SiteMinder, and Oracle access Management. In addition, many open source and SaaS products are emerging in the marketplace, and they are becoming important competitors for these products (Openam, Okta, Directaxs and Ping Identity).

Each of the products mentioned above comes with its own agents that must be installed on the WEB server and application server of the application that you are trying to protect and enable SSO for. In general, you will have agents for most of the major operating systems, Web Server software, and application Server software. The role of an agent is to intercept a logon request to an application and then pass the request to the SSO server for decision making. Therefore, this component is often called the identity execution point.