跳至主要內容

SSO的集成

senvon2021/10/28大约 5 分钟内管示例外部SSO集成同源产品SSO集成

SSO的集成

应用集成外部SSO

这种场景主要是指,产品部署到客户方,客户方已经有自己的SSO系统了,客户希望将当前应用的登录功能,和自己的SSO完成集成,这样使用当前应用的人,就只要记一套用户名密码.

注意

集成外部SSO,登录token的存储模式请设置为Cookie模式,请勿使用page模式

#将登录标识(token)存储在什么地方,可选值,cookie:page,需要使用js,写入到当前页面
#如果需要同一个浏览器使用多个用户同时登录,需要使用page
sso.token.storeType=cookie

一般的SSO集成,都会要求去除当前系统的SSOFilter.请按照下面的步骤进行操作.

  1. 引入外部SSO-client的jar包,对SSO-client进行配置.
  2. 登录页面的跳转,请首先遵守外部SSO-Client的规则
  3. 查看外部SSO-client的回调方式,一般有java回调和页面回调2种
  4. 不管是那种回调,最终需要调用到loginByPasswdController.tokenApply()申请token和loginSuccess()进行登录后页面跳转.

注意

应用的登录信息存储在threadLocal里面,如果外部的SSO-client只负责登一次登录的跳转,我方技术人员在集成的时候,需要单独写一个Filter,需要每次调用都调用SSOClientUtils.getInstance().setCurrent()进行设置.

其他系统集成本系统的SSO

  1. 其他系统需要集成user-api.jar,并去除自己的SSO登录机制.
  2. 参考spring-security-ssoClient.xml的配置,配置SSO.
  3. 在SSOFilter中配置实现callback,每次页面请求都会回调callback,设置当前系统的登录标识
  4. 如果当前系统可以修改,可以直接使用SSOClientUtils的方式,获得当前登录用户.
<bean name="tokenService" class="TokenService的远程实现/本地实现,主要是验证token">
</bean>
<!-- 登录信息使用baseCache进行存储,baseCache支持ehcache,redis,memcached -->
<bean name="storageService" class="StorageService的本地实现">
</bean>

提示

  1. 集成当前系统的登录界面,需要实现tokenService接口,远程向SSO去验证token
  2. StorageService是token的存储机制,可以使用和SSO一样的缓存,直接读取缓存的内容.

外部系统打开本系统页面

本系统内,最终拦截请求的是SSOFilter,SSOFilter在拦截请求是,会按照顺序检查三个位置是否含有token信息

  1. http的cookie
  2. http的header
  3. request.getParameter()

只要上面三个位置,都含有sso.token.name配置的token,就会那着值去检查token的有效性.

外部系统打开本系统的页面,最简单的方式就是在url后面加上token的值,比如,原本打开的url是/app1/s/index.do,现在转换为/app1/s/index.do?tokenName=有效的token,这个页面就可以正常的被打开.

请使用loginByPasswd.tokenApply方法去获得token.可能需要把tokenApply方法暴露成接口.tokenApply接口也可以看成信任登录的接口,可以不校验用户名密码,通过用户名直接获得token,谨慎使用

集成同源产品

这边的场景指代的是,客户采购了我们多套产品或平台,然后针对这些产品和平台,客户希望能不能内部通过同一套的用户名密码进行登录操作.

请一定要使用下面的方式进行部署. 同源产品部署

使用cookie作为token传递介质

#将登录标识(token)存储在什么地方,可选值,cookie:page,需要使用js,写入到当前页面
#如果需要同一个浏览器使用多个用户同时登录,需要使用page
sso.token.storeType=cookie

请一定使用缓存服务器来进行存储操作,不能使用默认的ehcache

<!-- 登录信息使用baseCache进行存储,baseCache支持ehcache,redis,memcached -->
<bean name="storageService" class="com.istock.union.user.service.impl.BaseCacheStorageService">
    <property name="defaultExpireTime" value="${sso.token.expireTime:1800}"></property>
</bean>

选择一个应用作为主要登录应用,假设我们选择app1,那么我们需要修改app2的配置文件

sso.login.url=/app1/pre/toLogin.do
sso.login.success.url=/app1/s/index.do

在本身配置为pre/toLogin.do的情况下,修改为/app1/pre/toLogin.do

其他的token.name,token.expire请和app1保持一致.

提示

上述配置,实际上是把产品内部token的验证换成了统一个缓存,而token的传输统一使用cookie,当通过同一个NGINX/F5转发的时候,cookie可以无缝的传递.

在app1的SYS_MENU_INFO表中,插入app2的个性化的菜单资源,需要把原本的资源url,增加/app2/的前缀.比如,原本的url为"s/xxx/aa.do" 需要修改为/app2/s/xxx/aa.do

警告

系统菜单有3种类型

  1. 外部资源,使用http(s)开头,生成的菜单url就是配置的url,例如,配置为http://www.baidu.com/a.do , 生成的url为http://www.baidu.com/a.do,请求的url为http://www.baidu.com/a.do
  2. 同源url,使用/开头,默认已经携带contextPath,生成的url就是配置的url,浏览器会帮请求拼上协议,域名,端口号.例如,配置=/app1/s/a.do,生成的url=/app1/s/a.do,请求的url为http://浏览器ip/app1/s/a.do
  3. 内部资源,其他开头,生成菜单url会自动拼接上当前系统的contextPath,浏览器会帮请求拼上协议,域名,端口号,例如,配置的url=s/a.do 生成的url=/contextPath/s/a.do,请求的url为http://浏览器ip/contextPath/s/a.do

最后修改app2的数据源,将SYS_开头的表全部删除,把app1表的SYS_开头的表,在app2的数据库里面创建同名的物理view.