搜索
SSOSSOSSOSSO（SingleSingleSingleSingleSign-OnSign-OnSign-OnSign-On，单点登录）一，SSOSSOSSOSSO技术简介：SSO（SingleSign-On，单点登录）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证二，SSOSSOSSOSSO的优势使用SSO的好处主要有：(1)方便用户用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。单点登录平台能够改善用户使用应用系统的体验。(2)方便管理员系统管理员只需要维护一套统一的用户账号，方便、简单。相比之下，系统管理员以前需要管理很多套的用户账号。每一个应用系统就有一套用户账号，不仅给管理上带来不方便，而且，也容易出现管理漏洞。(3)简化应用系统开发开发新的应用系统时，可以直接使用单点登录平台的用户认证服务，简化开发流程。单点登录平台通过提供统一的认证平台，实现单点登录。因此，应用系统并不需要开发用户认证程序。三，实现SSOSSOSSOSSO的技术主要有：(1)基于cookies实现，需要注意如下几点：如果是基于两个域名之间传递sessionid的方法可能在windows中成立，在unix&linux中可能会出现问题；可以基于数据库实现；在安全性方面可能会作更多的考虑。另外，关于跨域问题，虽然cookies本身不跨域，但可以利用它实现跨域的SSO。(2)Broker-based(基于经纪人)，例如Kerberos等；这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的第三方。例如Kerberos、Sesame、IBMKryptoKnight（凭证库思想）等。(3)Agent-based(基于代理人)在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如,它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个翻译。例如SSH等。(4)Token-based，例如SecurID、WebID、现在被广泛使用的口令认证，比如FTP，邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。(5)基于网关AgentandBroker-based，这里不作介绍。(6)基于安全断言标记语言(SAML)实现，SAML（SecurityAssertionMarkupLanguage，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML实现了SAML规范，可参考。四、SSOSSOSSOSSO实现原理1、概念：SSO的一种偏向技术的说法：用户只需登陆一次，就可使用多个SSOenable的应用系统。（1）、单一的登陆点。理想的情况是用户通过任何应用系统都能进行SSO，这对于基于Web的系统是可行的。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方，由登陆点将SSOtoken（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSOtoken来进行用户已认证的验证。我们将这个单一的登陆点称为SSOEntry。（2）、SSOenable意味着对应用系统的修改不可避免。并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSOAPAPAPAPI的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统，屏蔽已有的应用系统的用户认证模块，使用系统提供的SSOAPI来验证用户，以及对用户的操作进行授权。（3）、需要统一的认证，权限信息库。通常，认证与授权管理模块以一种应用专有的方式实现，系统的授权模型、认证，授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种设计与实现方式的缺点是显而易见的：由于认证、授权模块与应用逻辑之间的紧耦合使得认证、授权模块很难进行扩展与维护；认证、授权模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。这也是越来越多企业应用需要SSO的原因之一。SSO要求有统一的认证，权限存放库。但现实中，有的系统无法使用外部的认证，授权信息库，所以就需要在应用系统和PortalServer之间进行认证，同时进行授权信息的数据同步。2、实现描述：在用户成功登录weblogicPortal之后，系统提供的LoginDelegate机制来为用户登录到其有权可以使用的应用系统。系统提供LogoutDelegate机制实现用户的注销功能（即SSOlogout）。用户存取由PortalSSO保护的若干资源，SSO会话服务（Session/SSOService）提供了授权的证明，这样就不再需要用户重新进行身份验证了。在这种方式下，即使用户要访问不同的域（weblogicdomain）的应用，我们提供的PortalSSOService为其保持会话服务。同时，SSO还包括的与登录恰恰相反的，统一的注销点，即用户一旦从Portal注销，则亦当从所有参与PortalSSO的应用注销。此处有一个例外，就是当用户从Portal登录并转向一个应用后，经过一段时间后可能会出现用户的该应用的会话还有效时用户的Portal会话过期时，此时用户将只能使用该应用，直到该用户再次登录Portal。3、通过SSOAgent：当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSOAgent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，请求就被传递给PortalSSO，在PortalSSO上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。4、创建会话Token：在用户身份验证之前，会话服务就创建了会话token。token为随机产生的PortalServer会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中在用户的浏览器中设定cookie。在token被设定的同时，该用户将会看到一个登陆页面。5、用户认证：用户收到登陆页面和会话token后，填入合适的认证信息。当用户提交登陆页面后，这些认证信息就被发给认证提供者（authenticationproproproprovider）（LDAP服务器，RADIUS服务器等）进行验证。一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。IdentityServer会从用户的token中取出会话信息并将会话状态设为有效。此后，用户就可以访问这些受保护的资源。6、cookie和会话token：Cookie是由Web服务器创建的信息包，并传递给浏览器。Cookie保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在IdentityServer的实现中，cookie由会话服务产生，并由认证服务设定。而且，IdentityServer的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生，并包含PortalServer特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSOtoken。7，要实现SSO，需要以下主要的功能：（1）所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。（2）所有应用系统能够识别和提取ticketticketticketticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。8，WEBSSO与桌面SSOWEBSSOWeb协议（也就是HTTP）是一个无状态的协议。一个Web应用由很多个Web页面组成，每个页面都有唯一的URL来定义。用户在浏览器的地址栏输入页面的URL，浏览器就会向WebServer去发送请求。如下图，浏览器向Web服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里，浏览器和Web服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新建立连接。Web服务器并不区分哪个请求来自哪个客户端，对所有的请求都一视同仁，都是单独的连接。这样的方式大大区别于传统的（Client/Server）C/S结构,在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台Web服务器才能够同时服务于成千上万的客户端。但是我们通常的应用是有状态的。先不用提不同应用之间的SSO，在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。为了完成一个简单的SSOSSOSSOSSO的功能，需要两个部分的合作：1,1,1,1,统一的身份认证服务。2,2,2,2,修改WebWebWebWeb应用，使得每个应用都通过这个统一的认证服务来进行身份效验。桌面SSOSSOSSOSSO的实现从WEB-SSO的概念延伸开，我们可以把SSO的技术拓展到整个桌面的应用，不仅仅局限在浏览器。SSO的概念和原则都没有改变，只需要再做一点点的工作，就可以完成桌面SSO的应用。桌面SSO和WEB-SSO一样，关键的技术也在于如何在用户登录过后保存登录的凭据。在WEB-SSO中，登录的凭据是靠浏览器的cookie机制来完成的；在桌面应用中，可以将登录的凭证保存到任何地方，只要所有SSO的桌面应用都共享这个凭证。桌面样例的部署1,运行此桌面SSO需要三个前提条件：a)WEB-SSO的身份认证应用应该正在运行，因为我们在桌面SSO当中需要用到统一的认证服务b)当前桌面需要运行Mozilla或Netscape浏览器，因为我们将ticket保存到mozilla的cookie文件中c)必须在JDK1.4以上运行。（WEB-SSO需要JDK1.5以上）2,解开desktopsso.zip文件，里面有两个目录bin和lib。3,bin目录下有一些脚本文件和配置文件，其中config.properties包含了三个需要配置的参数：a)SSOServiceURL要指向WebSSO部署的身份认证的URLb)SSOLoginPage要指向WebSSO部署的身