iLife's 博客http://blog.csdn.net/fei1502816
SSO(Single Sign-On)直译为一次登录,用户只使用一个用户名和口令,就可以访问所有的资源,这对系统管理和维护来说是非常重要的。单点登录有效地解决了用户使用网络时的多帐号、多密码、多次登录问题,方便了用户。
SSO理论基础
SSO并不是J2EE(或.Net)中的标准实现,而是各家中间件提供商在提供J2EE(或.Net)应用服务器时提供的一种认证信息共享的机制,所以各家厂商提供的实现方式不一样, 在这些系统中,其实现方法方向分为两种: 一种是建立在PKI,Kerbose和用户名/口令存储的基础上,一种是建立在cookie或session的基础上。IBM的WebSphere是通过cookies记录认证信息,BEA的WebLogic通过session共享技术实现认证信息的共享,国内深圳金蝶的apusic采用的和BEA的技术基本一致。在这两种方式中,各有不足,前者需要安装专门的客户端,因而面向的用户对象是有限的,而后者授权方式只能方便地支持本产品系列的应用,而对第三方的认证和权限系统不能很方便的集成。
SSO的前提条件
1、所有应用系统共享一个身份认证系统
所有服务器必须共享用户注册表(用户数据库),用户注册表可以是LDAP数据库,也可以采用用户自己实现的用户注册表。要注意的是在某些情况下是不能使用自己实现的用户注册表的,例如,Domino不支持用户自己实现的用户注册表,所以WebSphere和Domino之间实现SSO时只能采用LDAP数据库作为公有的用户注册表。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(token),返还给用户。另外,认证系统还应该对token进行效验,判断其有效性。
2、所有应用系统能够识别和提取token信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对token进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
3、单一的用户信息数据库并不是必须的
有许多系统不能将所有的用户信息都集中存储,应该允许用户信息放置在不同的存储中。事实上,只要统一认证系统,统一token的产生和效验,无论用户信息存储在什么地方,都能实现单点登录。
4、统一的认证系统并不是说只有单个的认证服务器
认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。如:当用户在访问应用系统1时,由第一个认证服务器进行认证后,得到由此服务器产生的token。当他访问应用系统2的时候,认证服务器2能够识别此token是由第一个服务器产生的,通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信息,仍然能够完成SSO的功能。
5、对应用系统的修改不可避免
并不是任何系统都能够使用SSO,只有那些符合SSO规范,使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统(在本项目中,已有的业务系统要实现单点登录,如果步具备相应的条件,则必须进行修改),屏蔽已有的应用系统的用户认证模块,使用系统提供的SSO API来验证用户,以及对用户的操作进行授权。
实现单点登录的两种方式
SSO都要有一个单一的登录点,由此登录点将创建的会话(认证标志)token传递给应用系统。SSO需要建立一个统一的认证、权限信息库。根据认证、授权实现的位置可以分为两种实现方式:
1、Agent的方式
即在后端为每个Web应用系统(或者其他系统)都安装一个Agent,由Agent来接管该系统的身份验证和访问控制,目录服务器中会存放自己的用户信息,以及这些用户与其他系统的用户对应信息。这些Agent能够通过配置,轻松的接管了后面的系统的身份验证和访问控制。
对于不同的系统,Agent不同,这些Agent能够通过配置,轻松的接管后面系统的身份验证和访问控制。可以通过一个统一的LDAP,存放企业内部的用户信息,然后通过策略服务器,控制后端所有系统的URL访问权限,这样也实现了单点登录。
使用这种方式,其安全性较高,用户信息都保存在各系统中,但是这种方式需要在各个系统中都安装Agent,降低了系统的灵活性。
2、Proxy的方式
即具有一个Proxy Server,由它来接管对于后端系统的访问,提交请求和读取数据,然后再返回给调用者。同时调用者可以存放用户信息以及用户的对应关系。Proxy Server会通过存储的用户对应关系和用户名和密码,自动完成后端系统的登录,然后就象一个浏览器一样,提取数据,返回数据给后端系统。后台系统不用做任何修改,身份认证和访问控制仍然由各个系统自己管理。
该方法的优点是:后端系统不用做任何改动。即便是没有Portal,其他系统还可以照常使用。缺点是:需要在策略服务器中存储用户名称和密码,密码会多处存放,同步困难;用户可以绕开Portal,直接访问后端系统。Proxy Server可能是单点故障。缺点解决:目前有密码同步产品;Proxy Server也大多支持集群。
由以上两种方式可以看出,哪种方式的编程量都不是很大,大多可以通过配置来实现,而且功能也很强大,可以根据系统实际情况进行选择。
基于Agent方式的单点登录实现流程
在每个Web应用系统都安装一个Agent,由Agent来接管该系统的身份验证和访问控制的方式实现,如下图所示.
图 基于Agent方式的单点登录实现过程
1、用户访问应用系统。由登录点将SSO token(针对不同的C/S,B/S应用可能还需要传递用户名,口令)传递给应用系统,应用系统利用SSO token来进行用户已认证的验证。
2、当用户试图通过浏览器存取受保护的应用资源时,系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求,并检查请求是否存在会话标识符,即token。如果token不存在,即用户没有在自己的服务器登录,请求就被重定向,传递给单点登录服务器(使用重定向就可以处理各服务器跨域的情况)。在单点登录服务器上会话服务负责创建会话token,然后认证服务将提供登陆页面以验证用户。
在用户身份验证之前,会话服务创建了会话token。token为随机产生的会话标识符,该标识符代表了一个确定用户的特定会话。创建会话token后,认证服务把token插入cookie中,在用户的浏览器中设定cookie。在token被设定的同时,该用户将会看到一个登陆页面。
Cookie是由Web服务器创建的信息包,并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在身份服务器的实现中,cookie由会话服务产生,并由认证服务设定。而且,身份服务器的cookie是会话cookie,存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生,并包含系统服务器特有的会话信息。在存取受保护的资源之前,用户由认证服务验证,并创建SSO token。
3、单点登录服务器检查到用户已经单点登录(如果用户没有单点登录则要求用户登录,登录标志存储为客户端浏览器的Cookie),找到该用户在相应应用系统上绑定的账号。这些认证信息就被发给认证提供者(authentication provider)(LDAP服务器,RADIUS服务器等)进行验证。
4、一旦认证提供者成功验证了认证信息,用户就被认为是通过了认证。身份服务器会从用户的token中取出会话信息并将会话状态设为有效。单点登录服务器根据生成的用户token,重定向回应用系统。此后,用户就可以访问这些受保护的资源。
5、应用系统接收统一格式的用户token,取得用户在本系统上的登录账号,将用户在本系统上状态置为登录,返回用户请求访问的页面。
如果用户在访问应用系统之前已经在单点登录服务器上登录过,第二步到第四布对用户来说就是透明的,用户感觉只是向应用系统发出了访问请求,然后得到了页面反馈。
基于Proxy方式的单点登录实现流程
基于proxy的实现方案如novel iChain的实现。这种方案需要通过DNS将多个系统的域名配置在一个承担SSO的Proxy上。当用户输入系统地址打开页面时,会首先链接到这个Proxy,再由Proxy转发到实际系统。原有系统因为用户没有登录,那么会返回登录页面,这时候iChain会截获这个登录页面,用自己的登录页面代替。用户在iChain提供的页面中输入用户名和密码,随后iChain根据LDAP(Novel的LDAP可以说是这行的老大了)中的信息查询出原有系统的用户名和密码,通过一次Http Post将用户账号发送给原有系统。
如果用户打开新系统页面,那么基本不骤不变,只是iChain返回自己登录页面时,因为在同一个域中,可以发现该用户已经登录过,然后就直接Http Post到新系统而不出现登录页面。
其实SSO只是最简单的一个步骤,如何做好多系统之间的账号同步和授权才是大难题。
SSO(Single Sign-On)直译为一次登录,用户只使用一个用户名和口令,就可以访问所有的资源,这对系统管理和维护来说是非常重要的。单点登录有效地解决了用户使用网络时的多帐号、多密码、多次登录问题,方便了用户。
SSO理论基础
SSO并不是J2EE(或.Net)中的标准实现,而是各家中间件提供商在提供J2EE(或.Net)应用服务器时提供的一种认证信息共享的机制,所以各家厂商提供的实现方式不一样, 在这些系统中,其实现方法方向分为两种: 一种是建立在PKI,Kerbose和用户名/口令存储的基础上,一种是建立在cookie或session的基础上。IBM的WebSphere是通过cookies记录认证信息,BEA的WebLogic通过session共享技术实现认证信息的共享,国内深圳金蝶的apusic采用的和BEA的技术基本一致。在这两种方式中,各有不足,前者需要安装专门的客户端,因而面向的用户对象是有限的,而后者授权方式只能方便地支持本产品系列的应用,而对第三方的认证和权限系统不能很方便的集成。
SSO的前提条件
1、所有应用系统共享一个身份认证系统
所有服务器必须共享用户注册表(用户数据库),用户注册表可以是LDAP数据库,也可以采用用户自己实现的用户注册表。要注意的是在某些情况下是不能使用自己实现的用户注册表的,例如,Domino不支持用户自己实现的用户注册表,所以WebSphere和Domino之间实现SSO时只能采用LDAP数据库作为公有的用户注册表。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(token),返还给用户。另外,认证系统还应该对token进行效验,判断其有效性。
2、所有应用系统能够识别和提取token信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对token进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
3、单一的用户信息数据库并不是必须的
有许多系统不能将所有的用户信息都集中存储,应该允许用户信息放置在不同的存储中。事实上,只要统一认证系统,统一token的产生和效验,无论用户信息存储在什么地方,都能实现单点登录。
4、统一的认证系统并不是说只有单个的认证服务器
认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。如:当用户在访问应用系统1时,由第一个认证服务器进行认证后,得到由此服务器产生的token。当他访问应用系统2的时候,认证服务器2能够识别此token是由第一个服务器产生的,通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信息,仍然能够完成SSO的功能。
5、对应用系统的修改不可避免
并不是任何系统都能够使用SSO,只有那些符合SSO规范,使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统(在本项目中,已有的业务系统要实现单点登录,如果步具备相应的条件,则必须进行修改),屏蔽已有的应用系统的用户认证模块,使用系统提供的SSO API来验证用户,以及对用户的操作进行授权。
实现单点登录的两种方式
SSO都要有一个单一的登录点,由此登录点将创建的会话(认证标志)token传递给应用系统。SSO需要建立一个统一的认证、权限信息库。根据认证、授权实现的位置可以分为两种实现方式:
1、Agent的方式
即在后端为每个Web应用系统(或者其他系统)都安装一个Agent,由Agent来接管该系统的身份验证和访问控制,目录服务器中会存放自己的用户信息,以及这些用户与其他系统的用户对应信息。这些Agent能够通过配置,轻松的接管了后面的系统的身份验证和访问控制。
对于不同的系统,Agent不同,这些Agent能够通过配置,轻松的接管后面系统的身份验证和访问控制。可以通过一个统一的LDAP,存放企业内部的用户信息,然后通过策略服务器,控制后端所有系统的URL访问权限,这样也实现了单点登录。
使用这种方式,其安全性较高,用户信息都保存在各系统中,但是这种方式需要在各个系统中都安装Agent,降低了系统的灵活性。
2、Proxy的方式
即具有一个Proxy Server,由它来接管对于后端系统的访问,提交请求和读取数据,然后再返回给调用者。同时调用者可以存放用户信息以及用户的对应关系。Proxy Server会通过存储的用户对应关系和用户名和密码,自动完成后端系统的登录,然后就象一个浏览器一样,提取数据,返回数据给后端系统。后台系统不用做任何修改,身份认证和访问控制仍然由各个系统自己管理。
该方法的优点是:后端系统不用做任何改动。即便是没有Portal,其他系统还可以照常使用。缺点是:需要在策略服务器中存储用户名称和密码,密码会多处存放,同步困难;用户可以绕开Portal,直接访问后端系统。Proxy Server可能是单点故障。缺点解决:目前有密码同步产品;Proxy Server也大多支持集群。
由以上两种方式可以看出,哪种方式的编程量都不是很大,大多可以通过配置来实现,而且功能也很强大,可以根据系统实际情况进行选择。
基于Agent方式的单点登录实现流程
在每个Web应用系统都安装一个Agent,由Agent来接管该系统的身份验证和访问控制的方式实现,如下图所示.
图 基于Agent方式的单点登录实现过程
1、用户访问应用系统。由登录点将SSO token(针对不同的C/S,B/S应用可能还需要传递用户名,口令)传递给应用系统,应用系统利用SSO token来进行用户已认证的验证。
2、当用户试图通过浏览器存取受保护的应用资源时,系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求,并检查请求是否存在会话标识符,即token。如果token不存在,即用户没有在自己的服务器登录,请求就被重定向,传递给单点登录服务器(使用重定向就可以处理各服务器跨域的情况)。在单点登录服务器上会话服务负责创建会话token,然后认证服务将提供登陆页面以验证用户。
在用户身份验证之前,会话服务创建了会话token。token为随机产生的会话标识符,该标识符代表了一个确定用户的特定会话。创建会话token后,认证服务把token插入cookie中,在用户的浏览器中设定cookie。在token被设定的同时,该用户将会看到一个登陆页面。
Cookie是由Web服务器创建的信息包,并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在身份服务器的实现中,cookie由会话服务产生,并由认证服务设定。而且,身份服务器的cookie是会话cookie,存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生,并包含系统服务器特有的会话信息。在存取受保护的资源之前,用户由认证服务验证,并创建SSO token。
3、单点登录服务器检查到用户已经单点登录(如果用户没有单点登录则要求用户登录,登录标志存储为客户端浏览器的Cookie),找到该用户在相应应用系统上绑定的账号。这些认证信息就被发给认证提供者(authentication provider)(LDAP服务器,RADIUS服务器等)进行验证。
4、一旦认证提供者成功验证了认证信息,用户就被认为是通过了认证。身份服务器会从用户的token中取出会话信息并将会话状态设为有效。单点登录服务器根据生成的用户token,重定向回应用系统。此后,用户就可以访问这些受保护的资源。
5、应用系统接收统一格式的用户token,取得用户在本系统上的登录账号,将用户在本系统上状态置为登录,返回用户请求访问的页面。
如果用户在访问应用系统之前已经在单点登录服务器上登录过,第二步到第四布对用户来说就是透明的,用户感觉只是向应用系统发出了访问请求,然后得到了页面反馈。
基于Proxy方式的单点登录实现流程
基于proxy的实现方案如novel iChain的实现。这种方案需要通过DNS将多个系统的域名配置在一个承担SSO的Proxy上。当用户输入系统地址打开页面时,会首先链接到这个Proxy,再由Proxy转发到实际系统。原有系统因为用户没有登录,那么会返回登录页面,这时候iChain会截获这个登录页面,用自己的登录页面代替。用户在iChain提供的页面中输入用户名和密码,随后iChain根据LDAP(Novel的LDAP可以说是这行的老大了)中的信息查询出原有系统的用户名和密码,通过一次Http Post将用户账号发送给原有系统。
如果用户打开新系统页面,那么基本不骤不变,只是iChain返回自己登录页面时,因为在同一个域中,可以发现该用户已经登录过,然后就直接Http Post到新系统而不出现登录页面。
其实SSO只是最简单的一个步骤,如何做好多系统之间的账号同步和授权才是大难题。