可以通过两种方法执行此操作:
各用户可以自己指向正确的单一登录服务器。
单一登录服务器的本地计算机管理员可以将 Single Sign-On Users 帐户的所有成员指向此服务器。
使用 MMC 管理单元设置企业单一登录服务器
单击 启动, ,单击 所有程序, ,单击 Microsoft Enterprise 上单一登录, ,然后单击 SSO 管理。
在 MMC 管理单元中下 控制台根节点, ,右键单击 企业单一登录, ,然后单击 选择。
浏览到所需服务器。
根据需要选择 设置 SSO 服务器的所有用户 复选框。
单击 “确定”。
若要为单个用户使用命令行设置企业单一登录服务器
上 启动 菜单上,单击 运行, ,然后键入 cmd。
在命令行提示符下,转至企业单一登录安装目录。 默认安装目录是 <驱动器>: \program Files\Enterprise 单一登录。
类型 ssomanage-服务器 <SSO 服务器名>, ,其中 <SSO 服务器名>是用户想要连接到单一登录服务器的计算机名称。
说明
在支持用户帐户控制 (UAC) 的系统上,可能需要具有管理权限才能运行该工具。
若要使用命令行的所有用户都设置企业单一登录服务器
上 启动 菜单上,单击 运行, ,然后键入 cmd。
在命令行提示符下,转至企业单一登录安装目录。 默认安装目录是 <驱动器>: \program Files\Enterprise 单一登录。
类型 ssomanage-serverall <SSO 服务器名>, ,其中 <SSO 服务器名>是帐户将被指向单一登录在用户的所有成员的单一登录服务器的计算机名称。
说明
在支持用户帐户控制 (UAC) 的系统上,可能需要具有管理权限才能运行该工具。
若要确定企业单一登录到用户所连接的服务器使用命令行
上 启动 菜单上,单击 运行, ,然后键入 cmd。
在命令行提示符下,转至企业单一登录安装目录。 默认安装目录是 <驱动器>: \program Files\Enterprise 单一登录。
类型 ssomanage-showserver。
SSO指的是单点登录(Single Sign On),当用户在身份认证服务器上登录了一次以后,即可获得访问单点登录系统中其他联邦系统和应用软件的权限。
同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的,这意味着在多个应用系统中,用户只需一次登录就可以访问所有相互信任的应用系统。
单点登录是多个相关但独立的软件系统的访问控制的属性。使用此属性,用户使用单个ID和密码登录,以便在不使用不同用户名或密码的情况下访问已连接的系统,或者在某些配置中在每个系统上无缝登录。
单点登录通常使用轻量级目录访问协议(LDAP)和(目录)服务器上存储的LDAP数据库来完成,可以使用cookie在IP网络上实现简单版本的单点登录。
图为一种SSO系统:
扩展资料
实现机制
当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录;根据用户提供的登录信息,认证系统进行身份校验,如果通过校验,应该返回给用户一个认证的凭据--ticket;
用户再访问别的应用的时候就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行校验,检查ticket的合法性。如果通过校验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
SSO的优势
1、降低访问第三方站点的风险(未在外部存储或管理的用户密码)。
2、从不同的用户名和密码组合减少密码疲劳。
3、减少重新输入相同身份的密码所花费的时间。
4、由于关于密码的IT服务台呼叫数量减少,降低了IT成本。
5、SSO共享所有其他应用程序和系统用于身份验证的集中身份验证服务器,并将其与技术相结合,以确保用户不必多次主动输入其凭据。
参考资料来源:百度百科-SSO (Single Sign On)
参考资料来源:百度百科-单一登入
两个站点如果在同域下,那么它们之间是可以共享cookie的。简单的说就是这种同域下不同站点的sso实现可以通过cookie来实现,当用户访问这个域下面的任意站点时,浏览器都会将这个cookie发送给站点对应的系统。举个简单的例子:
站点1: www.ssotest.com/site1
站点2: www.ssotest.com/site2
从上面可以看出,这两个站点是在相同域名( www.ssotest.com )下,那么从站点1登录时,会在浏览器存储一些cookie,当在站点1下做任何操作时都会将这些cookie发送给站点1,同理,当访问站点2时,由于站点2和站点1在同一个域名下面,所以也会将这些cookie发送给站点2,所以这样的话就能够实现SSO了。可参考图1:
指相同父域,但是不同二级域名的单点登录,例如如下有两个站点:
从上面可以看出,它们的父域都是.ssotest.com,但是它们的二级域名不相同,所有如果在subsite1站点直接创建cookie,那么subsite2站点是不能够获取到subsite1的cookie的,所以如果直接在subsite1站点登录,将无法实现单点登录,那么如何才能实现这种情况的SSO呢?
实现它们之间的SSO最关键的一点是:实现cookie共享和session共享,保持二者的sessionId相同。
解决方案如下:
1.如果是使用的spring boot框架的后台应用,只需要在application.properties配置文件中添加上如下配置即可(因为内嵌tomcat):
2.如果使用外部tomcat,那么需要在server.xml文件中添加如下配置:
要实现这种跨域方式的SSO,有两种方式:
1.使用cookie,在各个应用之间重定向
2.使用单独的SSO服务器(更优)
那么下面详细的介绍上面这两种方式,以如下三个站点(应用)来具体描述:
这种方式比较简单,当用户在上面三个站点中的任意一个站点登录成功时,必须在浏览器中同时设置其他站点的cookie信息。
例如:当用户登录site1站点,并且验证通过之后,浏览器会存储一份site1站点的cookie信息,这时,为了实现单点登录(为了在site2站点和site3站点无需登录),那么我们需要在浏览器设置site2站点和site3站点的cookie信息,因此,在用户登录site1站点的请求响应之前,需要从siteId1站点重定向到site2站点和site3站点去设置cookie信息,这样就可以保证,在任意站点登录成功之后,在浏览器也有其他站点的cookie信息。下图2可具体展示其中流程:
这种方式其实过程比较简单,只需要确保登录其中一个站点在浏览器设置cookie其他站点都在浏览器设置对应cookie,就可以实现单点登录了(单点退出是一样的道理,一个退出清除cookie,其他也清除)。
但是这种方式有一个非常明显的缺点是:这里举例是3个站点,如果是几十个上百个站点再使用这种方式将非常影响效率。
这种方式需要借助一个单独的SSOServer,相对于上一种方式,这种方式就不需要将每个站点的cookie信息都保存在浏览器上,浏览器只需要保存SSOServer的cookie信息。将这个cookie信息用于需要做单点登录的所有站点中。
对于这种方式,在浏览器对于任意一个站点的请求都将会先重定向到SSOServer去验证代表当前用户的cookie是否存在,如果存在,那么将验证成功后的跳转页面发送给浏览器,否则将跳转到登录页面提示用户登录。可参考如下图3模型:
由于site1和site2的单点登录与site1、site2、site3之间的单点登录是同样道理的(因为登录site1后去访问site2和site3的流程都是相同的),所以,这里借助site1和site2的单点登录来说明这种方式。
下面分为三部分(三张图)来说明这种方式的单点登录:
第一部分:未在SSOServer登录,浏览器请求site1需要验证的页面,在SSOServer获取不到cookie,被重定向到site1登录界面,提示登录,流程如下图4:
在SSOServer登录的情况下,其他所有站点的登录情况都如site2,图6所示的流程,可见使用SSOServer的方式会方便许多。
以上就是SSO三种情况的实现方式。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)