`
fengpeng
  • 浏览: 99094 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

[原创]S3O:一个简单的单点认证系统(一)

阅读更多
关键字: 企业应用   SSO    

最近写了一个简单的单点认证系统(更喜欢称它为组件)
由于刚涉及sso不久,对他还不是很了解(不了解也敢写组件? 呵呵 见笑了)

所以问题再所难免,系统大家能够给予指正和帮助,先谢谢了.
下面贴一下简单的说明文档, 里面不牵涉技术细节,只是我对它的一个简单的描述

看看设计上有什么地方需要改进没

在过几天,根据大家对它的建议和意见 做些改善后 再把代码和详细的使用配制方法贴上来.
(比较长 不好意思了)

==========================================
组件名称:S3O
一套轻量级的、简单易用的、高效的单点认证系统。
当然同样具有一定的安全性,也支持跨域。
S3O: Simple Single Sign-On ----> SSSOS
一个简简单单的单点认证组件,
既然 WWWC 叫做 W3C ,那自然SSSO也可以叫S3O了

=====================================
系统特性:
=====================================
1 基于http协议
2 支持跨域认证
3 各个子应用采用自己的登录入口,并且拥有独立的授权模块
4 支持子应用间的同步
5 重要信息加密后,通过hessian传递,并使用一次性ticketKey,安全性可以得到一定的保障。
6 绝对轻量级
7 基本原理应该(因为我没读过CAS的源代码,只看过一些相关文章,所以不敢肯定)类似CAS的基本模式(而不是它的代理模式).
( 当然要比CAS简单while(true){很多}了。 )
8 基于spring 和 hessian技术构建。缓存采用ehcache。

=====================================
术语解释:
=====================================
子应用:
就是需要提供单点登录的各个应用。

认证中心:
单点登录的认证中心。它也是个web应用。
可以把它理解为一个存放用户名和密码的公共空间,
各个子应用可以从它这里取用户名和密码,然后调用各自的授权模块对用户进行授权。
在该单点登录系统中,认证中心并不提供授权服务。

认证中心在客户端的cookie:
用于存放ticket的cookie。各个子应用的cookie不能在跨域的子应用之间共享,所以需要认证中心的cookie存放数据。

ticket:
认证中心生成的一个具有唯一性的标识,作为键,用来在认证中心缓存中保存登录用户的信息
同时ticket还将存放在认证中心在浏览器端的 cookie内

ticketKey:
认证中心生成的一个具有唯一性的标识,作为键,用来在认证中心缓存中保存ticket。
它是一次性的,当以ticketKey为键,从认证中心缓存中读取一次ticket后,该键将失效。
ticketKey会通过http在子应用与认证中心之间传递。

service:
通常指的是hessian service。
通过开源组件hessian发布的一种类似web service的远程服务。

serverMethod:
也是一种发布的远程服务,但调用方法是通过url调用。
可以理解为类似struts的dispatch action的实现。

就好像用下面的url访问dispatch action, 会自动执行action中的query方法一样
http://www.aaa.com/example.do?actionMethod=query

客户端浏览器、子应用、认证中心之间 就是通过各种service和serverMethod进行通讯的。

=====================================
单点登录主要流程概述:

=====================================
判断用户是否已经登录:

当前子应用的session中有用户的基本信息,同时当前子应用的全局缓存中也有该用户的基本信息。
则认为该用户已经在当前系统中登录。两个条件缺一不可。

==================================================
系统初始化流程:

1 启动认证中心(一个web应用)并进行相关的初始化(初始化filter、缓存、发布service等)
2 启动各个子应用(初始化filter、缓存、发布service等)
3 子应用通过hessian 向 认证中心 注册自己的信息(包括 子应用的url 子应用中发布的service等信息)
4 认证中心验证子应用是否有合法的key,没有合法的key,则不允许注册。
5 成功注册的子应用的信息会加入 认证中心的子应用信息列表内(一个全局缓存)
这个列表可以帮助认证中心向各个子应用来发广播,也可以用来在各个子应用间进行通讯和同步.

=====================================
登录流程
(假设登录A应用 登录的用户为 tom )

1 通过A应用的登录页面输入用户名tom 以及 密码
2 调用A应用的授权模块进行授权,授权失败返回登录页面。
3 授权成功,则将用户名 密码(加密后)通过hessian 发往 认证中心。
4 认证中心对其进行缓存,并产生ticket,将ticket和用户基本信息放入认证中心的缓存
5 同时还将生成ticketKey,以ticketKey做为键,把ticket放入认证中心端的一个临时的缓存内。
6 将ticketKey通过hessian返回给A应用。
7 A应用得到ticketKey后,通过内部redirect访问认证中心的指定url,该url用于产生cookiet
(该cookie为认证中心在客户端产生,cookiet内存放ticket)。
8 完成写cookie操作后 ,清楚临时缓存中的ticketKey和ticket。
9 以上步骤成功完成后,将在A应用session和全局缓存中放置用户的基本信息(用户名 ticket)。
此时,对于a应用来说,用户tom的状态为已登录.

=====================================
登出流程
(假设登出A应用,登出的用户为 tom )

点击登出按钮,或进行重新登录的时候,会对先前登录时产生的信息进行销毁。
1 清空A应用的session和全局缓存中放置的tom的基本信息
2 向认证中心发出tom登出的通知。
3 认证中心接收到通知后,会把该通知通过hessian广播给所有子应用(利用子应用启动时向认证中心注册的信息来实现广播)。
4 接到通知的各个子应用会清空应用的全局缓存中放置的tom的基本信息。
因为“已经登录”的前提条件是 session中和应用的全局缓存中也有该用户的基本信息,
所以这时,在所有的子应用中,tom的状态都是为登出,这样做到了各个子应用间的同步。
对于登出的处理,和cas完全不同,cas是通过消灭cookie.

=====================================
访问流程:
(登录后,在各个子应用间切换的流程比较复杂,所以最后讲.)
假设tom已经通过A应用的入口 成功登录了A应用,并且认证中心正常工作。
此时访问B应用

1 判断tom是否已经登录了B应用
(通过判断B应用的session和全局缓存中是否有该用户的基本信息)
2 如果有 说明已经登录过(访问过)B应用,则进行正常访问。
3 如果没有,即tom没有登录过B应用,则尝试去认证中心 取用户的相关信息。
过程如下:
4 redirect到认证中心的指定url(同时发送当前用户请求的地址给认证中心),并从cookie中取ticket。
(cookie不能跨域,不redirect到认证中心是取不到ticket的)。
5 如果没有取到合法的ticket,则通知B应用跳转到登录页面(或出错页面)。
6 如果取到了ticket 则生成一个一次性的ticketKey,把ticket放入一个临时缓存,并返回B应用,同时把ticketKey返回给客户端。
7 B应用根据ticketKey从认证中心取用户名 密码.
过程如下:通过hessian 把 ticketKey 传递给认证中心,认证中心根据ticketKey去取ticket。
如果取到合法的ticket,则根据 ticket 通过hessian ,从认证中心的全局缓存中取得加密的 用户名 密码。
8 完成以上操作后 ,清除临时缓存中的ticketKey和ticket。
9 使用取得的用户名 密码,调用B应用的授权模块进行授权... 过程类似登录过程,但不需要认证中心重新产生ticket。
10 授权成功则 在B应用的session和全局缓存中放置用户基本信息,然后进行正常访问。
11 授权失败返回登录页面,并通知认证中心注销该ticket和用户基本信息(可以理解为,那个ticket失效了),
注销ticket时,认证中心会根据认证中心端的子应用列表,来通知各个子应用这个ticket失效了
各个子应用会从自己的全局缓存中清楚该ticket和其对应的用户基本信息(如果存在的话),过程类似登出过程。

=====================================
关于安全问题的一些探讨:

在这个系统中最需要保护的是用户名 密码 和 ticket。由于ticketKey具有瞬时性,被盗用的意义不大。
用户名 密码 和 ticket 始终通过 hessian传递,并且加密,即使被拦截,被盗用和破解的几率也极低.
ticketKey大多数情况下是通过hessian传递,但某应用第一次去认证中心取ticketKey时,
ticketKey是通过http的url传送的(这是不能避免的,即使强大的cas也是使用的这种方式,不同的是他使用了https,
其实,此处也是CAS坚持要使用HTTPS的一个主要原因)
减少"通过http协议,由URL传递ticket"的弊端的方式有三种:
1 使用HTTPS
2 使用一次性ticketKey
3 给ticketKey提供较短的失效时间
在这里我使用了 第2种方法。基本上可以避免ticketKey被盗用。

也许有人会想,如果可以生成一个和浏览器所在机器或用户IP绑定的ticketKey是不是可以解决这个问题,
即ticketKey被盗后,如果在其他机器使用,则无效。
这种思路看起来似乎可以,但其实不然。
原因很简单,web应用不能清晰准确的识别哪些访问来自同一台机器,从而可能导致合法的用户也无法对系统进行正常的访问。

http vs. https
单点登录系统中 保护用户名 密码 用户信息的唯一标识(ticket)是首要任务。
而坏人(在这里先这么称呼吧 因为我真的不想玷污黑客这个词)最想得到的就是这三者。
为了防止用户名 密码 ticket被盗,于是大多数sso系统采用了https。
在此处 https 比 http最主要最明显的优势就是传输的数据经过加密。
使得数据封包被拦截后,也几乎不可能从中破解出传输的数据。
但是,现在的坏人,主要的窃取用户信息的手段是什么?
在网内拦截封包,然后自己破解??错了,是用最简单的木马程序。
侵入用户的机器,直接记录键盘、拦截页面表单提交....
如果一个坏人,有能力侵入网络,来拦截各个机器之间的数据封包和http请求,那么他肯定也有能力直接在客户端的机器里做些手脚。

说的可能有些凌乱,重新总结一下吧:
如果想拥有可靠的安全性,要具备下面的几点:
1 整个网络系统 有完善的防火墙(使坏人不能随意的拦截网络数据封包)
2 认证中心、子应用所在机器要拥有完善的防火墙、完善的杀毒、防毒软件。
3 客户浏览器所在机器上,要有完善的防火墙、完善的杀毒、防毒软件。(这点最难保证)
4 机器之间的数据传输使用安全的传输协议(例如https)
以上4条,如果前3条得不到保证,那么安全性就无从谈起,第4条也就无足轻重了。
而如果前3条都满足了,那么第4条即使不满足,整个系统也同样安全,第4条同样无足轻重。
只有在 第2 3 条都满足,且第1条不满足的情况下,https才有用武之地。

所以,我的观点就是,对于"非公网"的单点认证系统,https不是必须的。
它在安全性方面起到的作用,和它带来的弊端想比,往往是弊大与利。
(其实,单点登录的系统,几乎都是企业内部的、非公网的系统)

注意:以上所言,都是针对传输的数据是 登录用户名 登录用户名 和 ticket的情况,如果传输是其他数据,则另当别论。

=====================================
目前已知不足:
1 不支持https协议。(虽然不是必须的,但毕竟很多时候还是需要用到https的,所以暂且算做一个不足吧)
2 不支持"同一用户在不同子应用中使用不同口令"的情况。
3 不支持同一台计算机上用多个账号同时登录。
4 和acegi结合的接口程序还没有编写完毕。
5 没有经历过绝对严格的测试。
6 整个系统完全没有任何的日志功能(我认为目前这不是必须的,而且我还不会用log4j common-logging这类组件)
7 认证中心端的管理模块还没有编写(同样,我认为目前这也不是必须的,完善基本功能是首要任务)
8 不支持类似CAS的业务代理模式。
9 不支持认证中心端的授权(本sso组件在设计的时候就没打算实现这个功能,呵呵)
10 虽然hessian支持多种语言,但是本sso组件没有提供非java的客户端版本。

=====================================
下一步工作:
1 完成与acegi的接口编码。
2 将 加密模块、唯一标识生成模块从主体中分离出来,可以通过配置来实现不同的加密、生成算法(类似acegi的做法)。
3 将 用户信息模型从主体中分离出来,做到更好的解藕,可以根据不同的需要配置不同的用户信息模型。(但核心仍然是Map来装载数据)
4 做一个稍微好点的S3OClient,但不会太好,因为计划将acegi作为client的主要承载者
5 提供从认证中心处统一登录(也就是提供统一的登录入口)。
6 支持认证中心端的统一授权。
7 认证中心端的简单的管理程序(查看认证中心中各种缓存中的数据)

分享到:
评论

相关推荐

    s3cp:Amazon S3命令行工具(例如cp,ls,cat等)

    只需几个简单的命令行实用程序即可列出,复制和查看S3文件,例如s3cp , s3ls , s3cat , s3rm等。 正在安装 确保在系统上安装了Rubygems,然后运行: # gem install s3cp 例子 export AWS_ACCESS_KEY_ID=... ...

    iOS-S3Connection:一个简单的连接类,用于将文件上传到Amazon S3

    S3Connection是一个简单的连接类,用于将文件和数据上传到Amazon S3存储桶。 S3连接参考 完成处理程序 typedef void (^S3CompletionHandler)(NSError *) 上传成功完成或失败后,将调用完成处理程序。 NSError将在...

    s3backer:通过 Amazon S3 基于 FUSE 的单个文件后备存储

    s3backer是一个文件系统,其中包含由 (Amazon S3) 支持的单个文件。 作为一个文件系统,它非常简单:它提供了一个固定大小的普通文件。 在下面,文件被分成块,每个块的内容存储在一个唯一的 Amazon S3 对象中。 ...

    s3img:s3img 是一个 Amazon S3 图像处理和上传工具

    s3img - Amazon S3 图像处理和上传工具目的s3img是一个基于 Node.JS 的 CLI 工具。 其最初目的是使用 ImageMagick 转换和处理图像并将这些图像上传到 Amazon S3。 这背后的意图是为在线商店系统提供不同的图像结果...

    S3C44B0公板 最小系统

    S3C44B0公板 最小系统 S3C44B0公板 最小系统 S3C44B0公板 最小系统 S3C44B0公板 最小系统

    GitToS3:将文件部署到s3

    GitToS3 将文件部署到s3。注意: 如果文件名包含utf-8字符,请添加quotepath = false 到您的项目/.git/config 在[核心]部分要求: s3用法: 设置config.json(请参阅config.json.example)deploy.rb -v详细--dryrun ...

    Python-s3cmd一个用来管理AmazonS3和CloudFront服务的命令行工具

    s3cmd:一个用来管理Amazon S3 和 CloudFront服务的命令行工具

    s3multiframesink:一个gstreamer插件,可将单个视频帧上传到S3

    S3MultiFrameSink-一个Gstreamer插件,用于将视频帧上传到S3存储桶目的这是一个使用和库提供的绑定编写的插件。 该插件旨在与其他现有的gstreamer插件一起使用,这些插件可从视频流中提取帧。 插件使用将插件接收的...

    S3C2440平台操作系统内核设计与实现

    毕设的时候做的一个简单的OS内核。ARM体系结构的,在s3c2440开发板上跑过。开发环境是RealView。...文件系统:模仿yaffs写的一个nand flash 文件系统,依然简单粗暴。 附上了设计文档与PPT。希望分享给愿意学习的人。

    s3cmd:公开s3cmd实用程序

    此操作是的简单包装。 目前仅在linode上进行过测试。 尽管它与所有环境息息相关,但这仅仅是设置正确的标签的问题。 输入项 cluster 不需要桶所在的群集。默认为"ap-south-1" 。 acces_key 必需桶访问密钥。 ...

    upload-s3-action:github动作上传到S3:cloud:

    上传S3 :cloud: 此操作通过生成的和输出密钥将目录上传到AWS S3 注意-最后一个source_dir名称( foo/bar/will-be-replace )将替换为作为shortid生成的密钥。 原因是每次都上传一个新文件,而我想使用一个新的键值...

    s3fs:使用 Amazon Simple Storage Service (S3) 实现 NodeJS FS 接口

    S3FS 为 Node.JS 提供的文件系统 (FS) 实现提供了直接替代,允许 Node.JS 应用程序通过 Node.JS 使用的众所周知的使用分布式文件系统。 最低 IAM 政策 以下是 AWS Identity and Access Management的策略,它提供了...

    bucketstore, 一个与 Amazon S3交互的简单.zip

    bucketstore, 一个与 Amazon S3交互的简单 BucketStore: 一个简单的AmazonS3客户端,用于 python 。BucketStore 是一个非常简单的Amazon S3客户端,在。 它的目的是要比boto3更直接使用,并且专门在 Amazon S3中,...

    s3-bucket:简单的AWS S3包装器:fire:

    简单的AWS S3包装器 :fire: 安装 $ npm install s3-bucket 环境变量 S3_BUCKET_ACCESS_KEY_ID=value S3_BUCKET_SECRET_ACCESS_KEY=value S3_BUCKET_NAME=value S3_BUCKET_REGION=value 用法 // Don't forgot to ...

    s3monkey:一个Python库,可让您与Amazon S3存储桶进行交互,就好像它们是您的本地文件系统一样

    s3monkey:像访问本地文件一样访问S3存储桶像这样的平台不允许使用FUSE文件系统,因此我不得不变得有点创意。 引入s3monkey ,它是模拟所有标准Python库系统文件操作的库,允许您使用已编写的代码与Amazon S3交互。 ...

    django-s3direct:使用Django直接将文件上传到S3兼容服务

    如果使用Amazon S3,您还需要创建一个IAM策略,该策略授予权限以将您新创建的凭证上传到存储桶。 { " Version " : " 2012-10-17 " , " Statement " : [ { " Effect " : " Allow " , " Action " : [ " s3:...

    s3proxy:通过S3 API访问其他存储后端

    开发人员可以通过运行mvn package来构建项目,该mvn package在target/s3proxy生成一个二进制文件。 S3Proxy需要Java 7才能运行。 通过属性文件配置S3Proxy。 使用本地文件系统作为具有匿名访问权限的存储后端的示例...

    s3query:从AWS S3读取(分开)文件

    S3Query以文本文件的形式打开s3文件系统中的一个或多个文件,如有必要,将执行解压缩。 它还处理喜欢hadoop的part- *文件,并将目录中的所有文件视为一个文件。 安装 pip install s3query 例子 >>> from s3query ...

    certbot-s3front:用于S3CloudFront验证和安装的Certbot CLI插件

    注意:如果您同时设置了顶点和www. 域中,它们每个都有一个各自的S3存储桶。 您需要更新IAM策略,以包括对两个存储桶的访问。设置安装certbot客户端和certbot-s3front插件的最简单方法是: pip install certbot-s3...

    s3rver:用NodeJs编写的假S3服务器

    S3rver S3rver是一种轻量级服务器,可响应响应的某些相同调用。 对于在沙盒环境中测试S3而不实际致电Amazon而言,这非常有用。... 现在,您的路径上将有一个名为s3rver的命令 对各种选项执行此命令: $ s3rver --

Global site tag (gtag.js) - Google Analytics