CN104394172A - 单点登录装置和方法 - Google Patents

Abstract

本发明提供了一种单点登录装置，包括：凭证制作单元，在Portal中打开第三方系统，完成凭证制作；收集单元，用HttpClient模拟登录第三方系统，进行Cookie的收集；加密签名单元，对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；验证解密单元，第三方系统的通用SSO组件对接收到的数据进行签名验证。本发明还提供了一种单点登录方法。通过本发明的技术方案，可以在现有的单点登录方式基础上，充分利用单对象类型完成多对象类型的单点登录，建立多对象类型参与的单点登录的通用、统一登录思路。

Description

单点登录装置和方法

 

技术领域

本发明涉及数据处理技术领域，具体地，涉及一种单点登录装置和一种单点登录方法。

 

背景技术

在企业中，一般有很多的应用系统为其提供管理和IT服务，随着企业的成长和信息的技术的发展，会有更多的系统加入。在传统的分散用户认证管理中，每个业务系统独立做用户的认证工作，用户就需要记住大量的用户名和密码，每进入一个系统都要进行登录，给用户带来了麻烦，同时也加大了系统管理员的认证管理和维护工作。单点登录（SSO）提供一种机制让不同的应用系统迅速得统一的认证功能 , 实现全局、安全的软件环境。在实现 SSO的系统中，用户只需进行一次主动的登录操作即可获得所需访问的应用系统和资源的授权，不必多次输入用户名和密码来确定用户身份。

但是，单点登录的实施也带来了许多的问题。首先，为了实施单点登录方案，需要对各个应用系统进行改造。对于应用系统繁多和有很多老旧系统的企业来说，这种改造无疑意味着很大的成本和风险。其次是安全问题。无论是用哪种单点登录的方案，都需要将用户的登录信息在网络传递，这种传递会带来很大的安全隐患。

现在的SSO方案，主要采用两种方案，一种是基于经纪人的单点登录方案，在这种方案中，有一个统一的中心服务器来提供集中认证和用户信息管理功能。这种方案需要对其源代码进行修改，使其能够完成与认证中心的交互，另外需要完成应用系统和认证中心用户信息的同步，实施起来比较困难。参见图7。

第二种方案是代理登录，就是通过表单提交的方式模拟应用系统的登录操作，实现SSO。代理登录的优点就是无需对原有系统做任何改造，适用于无法改造的旧系统。但是，这种方案会把第三方系统的密码通过网络暴露出来，是一种不安全的方案。参见图8。

这两种方案各有优缺点，基于此，需要提出一种保证安全、不改变原来应用系统源码、方便实施的单点登录方案。

因此，需要一种新的单点登录技术，可以在现有的单点登录方式基础上，充分利用单对象类型完成多对象类型的单点登录，建立多对象类型参与的单点登录的通用、统一登录思路。

 

发明内容

本发明正是基于上述问题，提出了一种新的单点登录技术，可以在现有的单点登录方式基础上，充分利用单对象类型完成多对象类型的单点登录，建立多对象类型参与的单点登录的通用、统一登录思路。

有鉴于此，本发明提出了一种单点登录装置，包括：凭证制作单元，用于在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码存是经过AES加密后的密文；收集单元，用于用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回凭证制作单元，重新进行凭证制作；加密签名单元，用于对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；验证解密单元，用于第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。在该技术方案中，可以在增强了单点登录的安全性后，对于实施过程基本上没有增加工作，只需把通用标准的SSO组件放入支持单点登录的第三方系统。

在上述技术方案中，优选地，所述凭证制作单元，具体包括：凭证取得模块，用于用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；跳转至收集模块，用于如果成功取得凭证，则跳转至收集的操作；凭证制作及加密模块，用于如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。在该技术方案中，为保证安全性，用户凭证表中的用户密码存是经过AES加密后的密文。

在上述技术方案中，优选地，所述收集单元，具体包括：Cookie收集模块，用于基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；跳转至加密签名模块，用于如果成功收集到Cookie，则跳转至加密签名的操作；凭证重新制作模块，用于如果没有成功收集到Cookie，则返回凭证制作及加密模块，重新进行凭证制作。在该技术方案中，让用户的浏览器也与第三方系统也拥有这个Session，要达到这个目的就要将此收集的Cookie转移到用户浏览器中，可以提高可靠性。

在上述技术方案中，优选地，所述加密签名单元，具体包括：加密和签名模块，用于对收集到的Cookie进行加密和签名；加密文件提交模块，用于利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。在该技术方案中，收集到的Cookie需要传送给第三方系统的通用SSO组件，然后通用SSO组件再传递给浏览器，可以提高处理效率。

在上述技术方案中，优选地，所述验证解密单元，具体包括：签名验证模块，用于第三方系统的通用SSO组件对接收到的数据进行签名验证；解密及展示模块，用于验证通过则对Cookie解密后设置到用户的浏览器中；消息反馈模块，用于如果验证不通过，返回给用户不安全的提示。在该技术方案中，Cookie传送给第三方系统的通用SSO组件过程中是要通过公共网络的，就需要首先对Cookie进行加密，可以提高安全性。

根据本发明的又一个方面，还提出了一种单点登录方法，包括：步骤202：在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码存是经过AES加密后的密文；步骤204：用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回步骤202，重新进行凭证制作；步骤206：对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；步骤208：第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。在该技术方案中，可以在增强了单点登录的安全性后，对于实施过程基本上没有增加工作，只需把通用标准的SSO组件放入支持单点登录的第三方系统。

在上述技术方案中，优选地，所述步骤202，具体包括：步骤302：用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；步骤304：如果成功取得凭证，则跳转至收集的操作；步骤306：如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。在该技术方案中，为保证安全性，用户凭证表中的用户密码存是经过AES加密后的密文。

在上述技术方案中，优选地，所述步骤204，具体包括：步骤402：基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；步骤404：如果成功收集到Cookie，则跳转至加密签名的操作；步骤406：如果没有成功收集到Cookie，则返回步骤306，重新进行凭证制作。在该技术方案中，让用户的浏览器也与第三方系统也拥有这个Session，要达到这个目的就要将此收集的Cookie转移到用户浏览器中，可以提高可靠性。

在上述技术方案中，优选地，所述步骤206，具体包括：步骤502：对收集到的Cookie进行加密和签名；步骤504：利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。在该技术方案中，收集到的Cookie需要传送给第三方系统的通用SSO组件，然后通用SSO组件再传递给浏览器，可以提高处理效率。

在上述技术方案中，优选地，所述步骤208，具体包括：步骤602：第三方系统的通用SSO组件对接收到的数据进行签名验证；步骤604：验证通过则对Cookie解密后设置到用户的浏览器中；步骤606：如果验证不通过，返回给用户不安全的提示。在该技术方案中，Cookie传送给第三方系统的通用SSO组件过程中是要通过公共网络的，就需要首先对Cookie进行加密，可以提高安全性。

通过以上技术方案，可以在现有的单点登录方式基础上，充分利用单对象类型完成多对象类型的单点登录，建立多对象类型参与的单点登录的通用、统一登录思路。

 

附图说明

图1示出了根据本发明的实施例的单点登录装置的框图；

图2示出了根据本发明的实施例的单点登录方法的流程图；

图3示出了根据本发明的实施例的凭证制作单元的流程图；

图4示出了根据本发明的实施例的收集单元的流程图；

图5示出了根据本发明的实施例的加密签名单元的流程；

图6示出了根据本发明的实施例的验证解密单元的流程图；

图7示出了现有技术中基于经纪人的单点登录方案的安全性高、实施困难的方案的原理图；

图8示出了现有技术中代理登录的易实施，安全性差的方案的原理图；

图9示出了根据本发明的实施例的会话漂移过程的流程图；

图10示出了根据本发明的实施例的单点登录的主要过程的流程图；

图11示出了根据本发明的实施例的Cookie收集的流程图；

图12示出了根据本发明的实施例的Cookie加密传输即会话漂移的全过程的流程图；

图13和图14分别示出了根据本发明的实施例的Portal中添加第三方系统及其配置信息的截图一和截图二。

 

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的实施例的单点登录装置的框图。

如图1所示，根据本发明的实施例的单点登录装置100，包括：凭证制作单元102，用于在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码存是经过AES加密后的密文；收集单元104，用于用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回凭证制作单元102，重新进行凭证制作；加密签名单元106，用于对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；验证解密单元108，用于第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。在该技术方案中，可以在增强了单点登录的安全性后，对于实施过程基本上没有增加工作，只需把通用标准的SSO组件放入支持单点登录的第三方系统。

在上述技术方案中，优选地，凭证制作单元102，具体包括：凭证取得模块1022，用于用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；跳转至收集模块1024，用于如果成功取得凭证，则跳转至收集的操作；凭证制作及加密模块1026，用于如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。在该技术方案中，为保证安全性，用户凭证表中的用户密码存是经过AES加密后的密文。

在上述技术方案中，优选地，收集单元104，具体包括：Cookie收集模块1042，用于基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；跳转至加密签名模块1044，用于如果成功收集到Cookie，则跳转至加密签名的操作；凭证重新制作模块1046，用于如果没有成功收集到Cookie，则返回凭证制作及加密模块1026，重新进行凭证制作。在该技术方案中，让用户的浏览器也与第三方系统也拥有这个Session，要达到这个目的就要将此收集的Cookie转移到用户浏览器中，可以提高可靠性。

在上述技术方案中，优选地，加密签名单元106，具体包括：加密和签名模块1062，用于对收集到的Cookie进行加密和签名；加密文件提交模块1064，用于利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。在该技术方案中，收集到的Cookie需要传送给第三方系统的通用SSO组件，然后通用SSO组件再传递给浏览器，可以提高处理效率。

在上述技术方案中，优选地，验证解密单元108，具体包括：签名验证模块1082，用于第三方系统的通用SSO组件对接收到的数据进行签名验证；解密及展示模块1084，用于验证通过则对Cookie解密后设置到用户的浏览器中；消息反馈模块1086，用于如果验证不通过，返回给用户不安全的提示。在该技术方案中，Cookie传送给第三方系统的通用SSO组件过程中是要通过公共网络的，就需要首先对Cookie进行加密，可以提高安全性。

图2示出了根据本发明的实施例的单点登录方法的流程图。

如图2所示，根据本发明的实施例的单点登录方法，包括：步骤202：在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码存是经过AES加密后的密文；步骤204：用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回步骤202，重新进行凭证制作；步骤206：对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；步骤208：第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。在该技术方案中，可以在增强了单点登录的安全性后，对于实施过程基本上没有增加工作，只需把通用标准的SSO组件放入支持单点登录的第三方系统。

在上述技术方案中，优选地，如图3所示，步骤202，具体包括：步骤302：用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；步骤304：如果成功取得凭证，则跳转至收集的操作；步骤306：如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。在该技术方案中，为保证安全性，用户凭证表中的用户密码存是经过AES加密后的密文。

在上述技术方案中，优选地，如图4所示，步骤204，具体包括：步骤402：基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；步骤404：如果成功收集到Cookie，则跳转至加密签名的操作；步骤406：如果没有成功收集到Cookie，则返回步骤306，重新进行凭证制作。在该技术方案中，让用户的浏览器也与第三方系统也拥有这个Session，要达到这个目的就要将此收集的Cookie转移到用户浏览器中，可以提高可靠性。

在上述技术方案中，优选地，如图5所示，步骤206，具体包括：步骤502：对收集到的Cookie进行加密和签名；步骤504：利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。在该技术方案中，收集到的Cookie需要传送给第三方系统的通用SSO组件，然后通用SSO组件再传递给浏览器，可以提高处理效率。

在上述技术方案中，优选地，如图6所示，步骤208，具体包括：步骤602：第三方系统的通用SSO组件对接收到的数据进行签名验证；步骤604：验证通过则对Cookie解密后设置到用户的浏览器中；步骤606：如果验证不通过，返回给用户不安全的提示。在该技术方案中，Cookie传送给第三方系统的通用SSO组件过程中是要通过公共网络的，就需要首先对Cookie进行加密，可以提高安全性。

本发明的技术方案，提供了一种基于会话漂移的安全、易实施的单点登录方案，是一种门户单点登录（SSO）的方案。

本发明的技术方案，旨在提出一种单点登录解决方案，这种方案能够不仅能够不破坏和修改原来应用系统的代码，快速方便的实施，还可以保证实施之后的安全性。

本发明解决技术问题的技术方案如下：

概念和组件

首先介绍下本发明技术方案的涉及的一些概念和组件。

第三方系统：指需要接入SSO的业务系统。

门户：打开第三方系统的入口。

用户凭证表：Portal数据库的一张表，保存门户用户和第三方系统用户的映射关系和第三方系统的登录名、密码等。

凭证收集页：Portal提供的，在用户首次打开第三方系统或者第三方系统的密码有修改时，即Portal的用户凭证表与第三方的数据库中存储用户名密码的表不对应时，显示出来给用户输入用户密码的页面。

HttpClient：Apache提供的开源的支持 HTTP 协议的客户端编程工具包。

AES：一个用于保护电子数据的对称加密算法，汇聚了强安全性、高性能、高效率、易用和灵活等优点。

SHA：安全哈希算法（Secure Hash Algorithm）主要用做数字签名。该算法是把一串输入码（称为预映射或信息）转化为长度较短、位数固定的输出序列即散列值（也称为信息摘要或信息认证代码）。

RSA：目前最有影响力的非对称密码算法，它能够抵抗到目前为止已知的绝大多数密码攻击，RSA算法是第一个能同时用于加密和数字签名的算法，也易于理解和操作，本发明技术方案用RSA进行数字签名。

Cookie：网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据，分为会话Cookie和永久Cookie，本发明技术方案所指的Cookie都是只得会话Cookie。

通用SSO组件：放入到第三方系统中的、使得第三方系统获得SSO能力的、通用的JSP、PHP或ASP文件。

原理

对于方案一，由于其实施过程需要对第三方系统做源码级别的改动，风险较大、实施困难，我们不采用这种方案。本发明技术方案主要在方案二的基础上，在不影响其实施的快捷性基础上，对其安全性能进行改进。

在WEB开发中，服务器会为每个用户浏览器创建一个会话对象（session对象），session创建出来后，会把session的id号，以cookie的形式回写给客户端浏览器，以后用户每访问服务器的时候都会将这个cookie带上，这样就通过这个Cookie保持了客户端和服务器之间的会话。

本发明技术方案采用“Portal端模拟登录建立会话”+“Cookie漂移”的方式来进行会话漂移，从而达到单点登录和安全性的目标。首先Portal的HttpClient和第三方应用系统建立起会话，得到Cookie之后将其加密传给第三方应用系统，然后再解密Cookie并设置给浏览器。这样就达到了浏览器和第三方应用系统之间安全的建立会话的目的。

对于第三方应用系统来说，它做的事情就是解密接收到的Cookie和设置给浏览器，这对于所有的第三方系统没有区别，只需根据其技术选型提供一个通用的SSO组件文件放到其服务器即可，对于它来说没有做代码级别的修改。参见图9。

主要过程

下面是本发明技术方案的单点登录的主要过程。

⑴用户在Portal中打开第三方系统。

⑵Portal去用户凭证表中根据当前Portal用户、第三方系统编码取对应的凭证。

⑶如果成功取得凭证，则到步骤⑸，否则在Portal中打开凭证制作页面。

⑷用户在凭证制作页面输入第三方系统的用户名和密码。⑴至⑷为凭证制作的操作过程。

⑸Cookie收集：用HttpClient模拟登录第三方系统，进行Cookie的收集，如果收集到，则到下一步，否则到步骤⑶重新进行凭证制作。

⑹Cookie加密签名：对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。

⑺Cookie验证解密：第三方系统的通用SSO组件对接收到的数据进行签名验证，验证通过则对Cookie解密后设置到用户的浏览器中，如果验证不通过，返回给用户不安全的提示。参见图10。

凭证制作、Cookie收集、Cookie加密签名、Cookie验证解密是本发明技术方案的关键步骤，下面详细介绍这三个方面。

凭证制作

凭证制作过程和背景中的方案二的过程是一样的，不是本发明技术方案关注的重点，不在赘述。需要注意的是，为保证安全性，用户凭证表中的用户密码存是经过AES加密后的密文。

Cookie收集

在此阶段首先取得用户凭证库第三方系统的用户名、密码和第三方系统的配置表里的用户名字段名、密码字段名、登录地址等配置信息，并对其密码进行AES解密，然后用HttpClient模拟登录到取得的登录地址，如果收到了成功信息，则获得当卡你的会话Cookie。

在此阶段，在收集到Cookie的同时，实质上是建立了HttpClient对象和第三方系统之间的Session。下面的工作就是让用户的浏览器也与第三方系统也拥有这个Session，要达到这个目的就要将此收集的Cookie转移到用户浏览器中。参见图11。

Cookie加密、签名

收集到的Cookie需要传送给第三方系统的通用SSO组件，然后通用SSO组件再传递给浏览器。

Cookie传送给第三方系统的通用SSO组件过程中是要通过公共网络的，就需要首先对Cookie进行加密，本发明技术方案采用AES作为Cookie的加密算法，加密后的密文enc=AES(Cookie)。

将Cookie进行AES加密后，还需要进行签名。签名之后能有效防止截获加密Cookie的之后的伪装登录。首先用SHA算法生成加密密文的摘要，digest1=SHA(enc)，然后用得到的摘要和当前时间戳的前八位用RSA进行签名，签名sign1=RSA（digest1+当前时间戳t1的前八位），签名之后就将密文和签名打包发送给第三方系统。

Cookie验证、解密

这个阶段是在第三方的通用SSO组件中进行的工作。

首先将接收宝解包，获得密文和签名，然后计算密文的摘要digest2=SHA(enc)，用发送方的公钥对接收的数字签名进行RSA解密，判断这个生成值是否等于digest2+时间戳前八位，若相等，则表示此次接收到的Cookie是安全的，之后将此解密后的Cookie设置到浏览器中。因为之前在Cookie收集阶段HttpClient已经在第三方系统中建立起了会话，此时浏览器和第三方系统就建立起了会话。

图12是Cookie加密传输即会话漂移的全过程。

以上的阶段，如果用户之前曾登录过第三方系统，也就是已经制作过了凭证，当在Portal中打开第三方系统后是直接进入的，整个过程对用户来说是透明、无感知的，这就达到了单点登录的效果。

此单点登录方案实施过程

由上面的步骤可以看出，在增强了单点登录的安全性后，对于实施过程基本上没有增加工作，只需把通用标准的SSO组件放入支持单点登录的第三方系统中即可，下面是实施的完整过程。

⑴Portal中添加第三方系统及其配置信息。在Portal中添加支持单点登录（SSO）的第三方系统，然后配置登录第三方系统时需提供的信息，如用户名、密码、登录提交地址、成功返回标志、通用SSO组件的地址等。如图13和图14所示。

⑵根据第三方系统的技术选型（JSP、PHP或ASP）给要进行第三方系统添加相应的通用SSO文件。

与本发明技术方案的相关专利： 一种单点登录的方法（201110150774.9），是需要修改第三方系统原来的密码验证机制，是一种源代码级别的修改。本发明技术方案没有代码级的修改，与此相比，更易实施。一种单点登录向导实现方法、装置和单点登录系统（200910189793.5），保证了实施的方便性，但是是一种不安全的方案，本发明技术方案更具安全特性。

与上述相关专利相比，本发明的技术方案，至少可以达到的有益效果包括：安全的单点登录方案；实施方便快捷。

以上结合附图详细说明了本发明的技术方案，考虑到相关技术中没有简便的、统一的针对复杂类型元数据登录的解决办法。现有的单点登录无法完成有复杂类型参与的单点登录过程。因此，本发明提出了一种单点登录装置和一种单点登录方法，可以在现有的单点登录方式基础上，充分利用单对象类型完成多对象类型的单点登录，建立多对象类型参与的单点登录的通用、统一登录思路。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种单点登录装置，其特征在于，包括：

凭证制作单元，用于在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码是经过AES加密后的密文；

收集单元，用于用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回凭证制作单元，重新进行凭证制作；

加密签名单元，用于对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；

验证解密单元，用于第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。

2.根据权利要求1所述的单点登录装置，其特征在于，所述凭证制作单元，具体包括：

凭证取得模块，用于用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；

跳转至收集模块，用于如果成功取得凭证，则跳转至收集的操作；

凭证制作及加密模块，用于如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。

3.根据权利要求1或2所述的单点登录装置，其特征在于，所述收集单元，具体包括：

Cookie收集模块，用于基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；

跳转至加密签名模块，用于如果成功收集到Cookie，则跳转至加密签名的操作；

凭证重新制作模块，用于如果没有成功收集到Cookie，则返回凭证制作及加密模块，重新进行凭证制作。

4.根据权利要求3所述的单点登录装置，其特征在于，所述加密签名单元，具体包括：

加密和签名模块，用于对收集到的Cookie进行加密和签名；

加密文件提交模块，用于利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。

5.根据权利要求4所述的单点登录装置，其特征在于，所述验证解密单元，具体包括：

签名验证模块，用于第三方系统的通用SSO组件对接收到的数据进行签名验证；

解密及展示模块，用于验证通过则对Cookie解密后设置到用户的浏览器中；

消息反馈模块，用于如果验证不通过，返回给用户不安全的提示。

6.一种单点登录方法，其特征在于，包括：

步骤202：在Portal中打开第三方系统，通过用户凭证表，完成凭证制作；用户凭证表中的用户密码是经过AES加密后的密文；

步骤204：用HttpClient模拟登录第三方系统，进行Cookie的收集；如果收集到，则进行Cookie加密签名处理；否则，则返回步骤202，重新进行凭证制作；

步骤206：对收集到的Cookie进行加密和签名，并利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件；

步骤208：第三方系统的通用SSO组件对接收到的数据进行签名验证：验证通过，则对Cookie解密后设置到用户的浏览器中；如果验证不通过，则返回给用户不安全的提示。

7.根据权利要求6所述的单点登录方法，其特征在于，所述步骤202，具体包括：

步骤302：用户在Portal中打开第三方系统；Portal去用户凭证表中，根据当前Portal用户、第三方系统编码取得对应的凭证；

步骤304：如果成功取得凭证，则跳转至收集的操作；

步骤306：如果没有成功取得凭证，则在Portal中打开凭证制作页面；用户在凭证制作页面输入第三方系统的用户名和密码。

8.根据权利要求6或7所述的单点登录方法，其特征在于，所述步骤204，具体包括：

步骤402：基于取得或制作的凭证，用HttpClient模拟登录第三方系统，进行Cookie的收集；

步骤404：如果成功收集到Cookie，则跳转至加密签名的操作；

步骤406：如果没有成功收集到Cookie，则返回步骤306，重新进行凭证制作。

9.根据权利要求8所述的单点登录方法，其特征在于，所述步骤206，具体包括：

步骤502：对收集到的Cookie进行加密和签名；

步骤504：利用HttpClient将加密后的Cookie提交传送到第三方系统的通用SSO组件。

10.根据权利要求9所述的单点登录方法，其特征在于，所述步骤208，具体包括：

步骤602：第三方系统的通用SSO组件对接收到的数据进行签名验证；

步骤604：验证通过则对Cookie解密后设置到用户的浏览器中；

步骤606：如果验证不通过，返回给用户不安全的提示。