Single Sign-On Explained/SSO释义
什么是SSO？
SSO是一个缩写为“单点登录”。有各种形式的单点登录与最常见的是企业单点登录（ESSO）和Web单点登录（WSSO）。
每个方法都采用不同的技术，以减少用户必须输入自己的用户名/密码，以获得对受保护资源的访问次数。
注：有不同的分支从WSSO实现的 - 最显着的是利用代理或门户服务器作为身份验证和授权的中心点。
what is SSO ?
SSO is an acronym for “Single Sign-On”. There are various forms of single sign-on with the most common being Enterprise Single Sign-On (ESSO) and Web Single Sign-On (WSSO).
Each method utilizes different technologies to reduce the number of times a user has to enter their username/password in order to gain access to protected resources.
Note: There are various offshoots from WSSO implementations – most notably utilizing proxies or portal servers to act as a central point of authentication and authorization.
Enterprise Single Sign-On
In ESSO deployments, software typically resides on the user’s desktop; the desktop is most commonly Microsoft. The software detects when a user launches an application that contains the username and password fields. The software “grabs” a previously saved username/password from either a local file or remote storage (i.e. a special entry in Active Directory), enters these values into the username and password fields on behalf of the application, and submits the form on behalf of the user. This process is followed for every new application that is launched that contains a username and password field. It can be used for fat clients (i.e. Microsoft Outlook), thin clients (i.e. Citrix), or Web-based applications(i.e. Web Forms) and in most cases the applications themselves are not even aware that the organization has implemented an ESSO solution. There are definite advantages to implementing an ESSO solution in terms of flexibility. The drawback to ESSO solutions, however, is that software needs to be distributed, installed, and maintained on each desktop where applications are launched. Additionally, because the software resides on the desktop, there is no central location in which to determine if the user is allowed access to the application (authorization or AuthZ). As such, each application must maintain its own set of security policies.
The following diagram provides an overview of the steps performed in ESSO environments.
企业单点登录
在ESSO部署，软件通常驻留在用户的桌面上，桌面是最常见的微软。该软件检测，当用户启动一个应用程序，它包含用户名和密码字段。该软件“掠夺”以前保存的用户名/密码，无论是从本地文件或远程存储（即在Active Directory中的一个特殊的条目），代表该应用程序的用户名和密码栏输入这些值，并提交表单代表的用户。这个过程之后的每一个新推出的应用程序，包含一个用户名和密码字段。它可用于胖客户端（例如Microsoft Outlook）中，薄客户端（即思杰），或基于Web的应用程序（如Web窗体），在大多数情况下，甚至不知道自己的应用程序，组织实施ESSO解决方案。实施ESSO解决方案在灵活性方面有一定的优势。 ESSO的解决方案，但是，其缺点是该软件需要在每个桌面上启动应用程序的分布，安装和维护。此外，因为该软件驻留在桌面上，不存在中央的位置，在该位置，以确定是否允许用户访问该应用程序（授权或AuthZ）可。因此，每个应用程序必须维护自己的安全策略。
下图提供了一个概述的步骤在ESSO环境中进行。
A user launches an application on their desktop. An agent running in the background detects a login screen from a previously defined template. If this is the first time the user has attempted to access this application, they are prompted to provide their credentials. Once a successful login has been performed, the credentials are stored in a credentials database. This database can be a locally encrypted database or a remote server (such as Active Directory). Subsequent login attempts do not prompt the user for their credentials. Instead, the data is simply retrieved from the credentials database and submitted on behalf of the user.
Container-Based Single Sign-On
Session information (such as authenticated credentials) can be shared between Web applications deployed to the same application server. This is single sign-on in its most basic and limited fashion as it can only be used across applications in the same container.
The following diagram provides a high level overview of the steps performed in container-based single sign-on environments.
基于容器的单点登录
之间可以共享相同的应用服务器部署到Web应用程序的会话信息（如身份验证的凭据）。这是单点登录在其最基本和最有限的方式，因为它只能用于跨应用程序在同一容器中。
下图提供了一个高层次的概述，基于容器的单点登录的环境中执行的步骤。
A user accesses a Web application through a standard Web browser. They are prompted for their credentials which can be basic (such as username and password) or can utilize other forms of authentication (such as multi-factor, X.509 certificates, or biometric). Once the user has authenticated to the application server, they are able to access other applications installed in the same J2EE container without having to re-authenticate (that is, if the other applications have been configured to permit this).
Traditional Web Single Sign-On
In contrast, WSSO deployments only apply to the Web environment and Web-based applications. They do not work with fat clients or thin clients. Software is not installed on the user’s desktop, but instead resides centrally within the Web container or J2EE container of the Web application being protected. The software is often times called a “policy agent” and its purpose is to manage both authentication and authorization tasks.
The following diagram provides a high level overview of traditional Web Single Sign-On.
传统的Web单点登录
与此相反，WSSO部署仅适用于Web环境下的应用程序和基于Web的应用程序。他们不与胖客户端或瘦客户端。软件未安装在用户的桌面上，而是驻留集中在Web容器或J2EE容器的Web应用程序的保护。软件经常被称为“策略代理”，其目的是管理身份验证和授权任务。
下图提供了一个高层次的概述传统的Web单点登录。
A user first attempts to access a Web resource (such as ADP) through a Web browser. They are not authenticated to the domain so they are directed to the central authentication server where they provide their credentials. Once validated, they receive a cookie indicating that they are authenticated to the domain. They are then redirected back to the original Web resource where they present the cookie. The Web resource consults the authentication server to determine if the cookie is valid and that the session is still active. They also determine if this user is allowed access to the Web resource. If so, they are granted access. If the user were to attempt to access another Web resource in the same domain (i.e. Oracle eBusiness Suite), they would present the cookie as proof that they are authenticated to the domain. The Web resource consults the authentication server to determine the validity of the cookie, session, and access rights. This process continues for any server in the domain that is protected by WSSO.
用户首先尝试通过Web浏览器来访问Web资源（如ADP）。他们没有身份验证的域，以便向他们提供他们的凭据的中央认证服务器。一旦通过验证，他们收到一个cookie，表明它们进行身份验证的域。然后，他们重定向回原来的Web资源，他们提出的cookie。网络资源咨询认证服务器的cookie，以确定是否是有效的，本次会议是仍然活跃。他们还决定，如果该用户被允许访问网络资源。如果是这样，他们被授予访问权限。如果用户试图访问另一个Web资源在同一个域（如Oracle电子商务套件），他们将提出证明他们进行身份验证的域的cookie。网络资源咨询，以确定有效期的cookie，会话和访问权限的认证服务器。这个过程一直持续，受WSSO中的任何服务器的域名。
Portal or Proxy-Based Single Sign-On
Portal and proxy-based single sign-on solutions are similar to Standard Web Single Sign-On except that all traffic is directed through the central server.
Portal Based Single Sign-On
Target-based policy agents can be avoided by using Portal Servers such as LifeRay or SharePoint. In such cases the policy agent is installed in the Portal Server. In turn, the Portal Server acts as a proxy for the target applications and may use technologies such as SAML or auto-form submission. Portal Servers may be customized to dynamically provide access to target systems based on various factors. This includes the user’s role or group, originating IP address, time of day, etc. Portal-based single sign-on (PSSO) serves as the foundation for most vendors who are providing cloud-based WSSO products. When implementing PSSO solutions, direct access to target systems is still permitted. This allows users to bypass the Portal but in so doing, they need to remember their application specific credentials. You can disallow direct access by creating container-specific rules that only allow traffic from the Portal to the application.
Single Sign-On Involving Proxy Servers
Proxy servers are similar to PSSO implementations in that they provide a central point of access. They differ, however, in that they do not provide a graphical user interface. Instead, users are directed to the proxy through various methods (i.e. DNS, load balancers, Portal Servers, etc.). Policy agents are installed in the proxy environment (which may be an appliance) and users are granted or denied access to target resources based on whether they have the appropriate credentials and permission for the target resource.
The following diagram provides a high level overview of centralized single sign-on using Portal or Proxy Servers.
门户网站或基于代理的单点登录
门户和基于代理的单点登录解决方案是类似标准的Web单点登录，除非所有的流量直接通过中央服务器。
基于门户的单点登录
基于目标的策略代理，可避免使用LIFERAY或SharePoint门户服务器，如。在这种情况下，策略代理安装在Portal Server。反过来，门户服务器作为目标应用程序的代理和使用的技术，如SAML或自动提交表单。可以定制门户服务器来动态地访问到目标系统的各种因素的基础上。这包括用户的角色或组，源IP地址，一天的时间，基于门户的单点登录（PSSO）作为大多数供应商提供基于云的WSSO产品的基础。当实施PSSO的解决方案，直接访问目标系统仍是允许的。这使得用户可以绕过门户，但在这样做的，他们需要记住他们的应用程序特定的凭证。您可以通过创建特定于容器的规则，只允许从Portal的应用程序的流量不允许直接访问。
单点登录涉及代理服务器
PSSO实现的，因为它们提供了一个中央接入点，代理服务器是相似的。它们的不同，然而，因为它们不提供一个图形用户界面。相反，用户将被定向到代理服务器，通过各种方式（即DNS，负载均衡，门户服务器等）。策略代理被安装在代理服务器环境（可能是电器）和用户授予或拒绝访问目标资源的基础上是否有相应的凭据为目标的资源和权限。
下图提供了一个高层次的概述集中的单点登录门户网站或代理服务器上使用。
Federation
Federation is designed to enable Single Sign-On and Single Logout between trusted partners across a heterogeneous environment (i.e. different domains). Companies that wish to offer services to their customers or employees enter into a federated agreement with trusted partners who in turn provide the services themselves. Federation enables this partnership by defining a set of open protocols that are used between partners to communicate identity information within a Circle of Trust. Protocols include SAML, Liberty ID-FF, and WS-Federation.
Implementation of federated environments requires coordination between each of its members. Companies have roles to play as some entities act as identity providers (IDP – where users authenticate and credentials are verified) and service providers (SP – where the content and/or service originate). Similar to standard Web Single Sign-On, an unauthenticated user attempting to access content on a SP is redirected to an appropriate IDP where their identity is verified. Once the user has successfully authenticated, the IDP creates an XML document called an assertion in which it asserts certain information about the user. The assertion can contain any information that the IDP wishes to share with the SP, but is typically limited to the context of the authentication. Assertions are presented to SPs but are not taken at face value. The manner in which assertions are validated vary between the type of federation being employed and may range from dereferencing artifacts (which are similar to cookies) or by verifying digital signatures associated with an IDP’s signed assertion.
The interaction between the entities involved in a federated environment (user, SP and IDP) is similar to the Web Single Sign-On environment except that authentication is permitted across different domains.
A major difference between federated and WSSO environments involves the type of information generated by the authenticating entity to vouch for the user and how it is determined that that vouch is valid and had not been altered in any way.
联邦
联邦的目的是使单点登录和单点注销值得信赖的合作伙伴之间跨越异构环境（即不同的域）。希望他们向客户或员工提供服务的公司签订的联合协议，谁又将自己提供的服务与值得信赖的合作伙伴。联邦使这种合作伙伴关系，通过定义一套开放的协议，用于合作伙伴之间的沟通圆信托身份信息。这些协议包括SAML，自由ID-FF和WS-Federation。
实施联合环境要求其成员之间的协调。公司可发挥作用，因为一些实体作为身份提供商（IDP - 在用户进行身份验证和证书验证）和服务提供商（SP - 其中的内容和/或服务的起源）。类似标准的Web单点登录，未经授权的用户试图访问一个SP上的内容将被重定向到一个合适的IDP验证自己的身份。一旦用户成功通过验证，的IDP创建一个XML文件，称为一个断言，它声称用户的某些信息。断言可以包含任何信息的IDP希望共享与SP，但通常被限制到的认证上下文。断言提交给SP，但不信以为真。断言验证的方式各有不同，总会被雇用的类型和范围可以从提领的工件（这是类似的Cookie）或验证数字签名与IDP签署断言。
类似的Web单点登录环境，除了身份验证允许跨不同的域之间的相互作用所涉及的实体（用户，SP和IDP）在联合环境中。
之间的主要区别联邦和WSSO环境涉及的认证实体担保的用户，以及它是如何确定该担保是有效的，并没有被以任何方式改变所产生的信息类型。
The following table provides a feature comparison between Web SSO and Enterprise SSO.
下表提供了一个功能比较Web SSO和企业的SSO。
| Features(特点) |
WSSO / PSSO / Proxy(WSSO / PSSO /代理) |
ESSO |
| Applications Supported: 支持的应用程序 |
Web Only Web应用程序 |
Web Applications and Fat Clients Web应用程序和胖客户端 |
| “Agent” Location: “代理”的位置 |
Target System 目标系统 |
User Desktop 用户桌面 |
| Technologies: 技术 |
SAML, Form Submission, Cookies |
Form Submission 表单提交 |
| Internal Users? 内部用户 |
Yes |
Yes (through portal) |
| External Users? 外部用户 |
Yes |
No |
| Central Authentication? 认证中心 |
Yes |
No |
| Central Authorization? 授权中心 |
Yes |
No |
| Central Session Logoff? 会话注销中心 |
Yes |
No |
| Global Account Deactivation? 全局帐户停用 |
Yes (through password change) |
No |