在阅读本文前,需有一定的统一身份认证的知识,最好阅读或者使用过cas或者kerberos
1. 原理和协议
从结构上看,自定义协议包括SP、IDP Server和IDP Engine三部分(UA为浏览器)。其中IDP Server和IDP Engine独立部署,主要负责对用户进行认证,SP负责处理客户端受保护资源的访问请求,需要登录时,重定向到IDP Server。如下图所示:
图1. 协议图
前提:IDP Engine是可信的,SP首先向ID Engine注册(名称以及默认的callbackURL),生成sp编号,该编号代表该sp;票据分为三种:sp票据、UA票据和agent票据
协议交互流程如下:
- 1. UA访问SP,SP判断该用户是否已经登录,如果没有登录,SP产生认证请求;如果用户已经登录,直接响应结果
- 2. SP重定向到IDP Server,URL带有AuthnRequest参数,如果已经登录,跳转到4;如果没有登录,返回登录页面,进行认证操作
- 3. UA产生认证请求,URL带有CredentialsRequest参数。IDP Server接收到认证请求后,首先判断请求的合法性。然后判断该用户是否已经成功单点登录(从cookie去得UA票据,如果票据不存在,则认为该用户未登陆过)。如果用户登录过,则为使用UA票据为该sp申请sp票据和agent票据,根据请求信息查询到响应URL,将sp票据写在url参数并重定向到该url,如果未登录过,则跳转到4
- 4. IDP Server将CredentialsRequest请求参数包装成Credentials向IDP Engine发出认证请求(IDP Server需要向IDP Engine认证自己的身份),如果认证通过,则申请相应票据: sp票据、UA票据和agent票据以及响应的URL
- 5. 将UA票据写cookie
- 6. 将sp票据写在响应URL参数,重定向到响应URL
2. 安全性
- sp票据由IDP Engine用sp的密钥加密,只有sp能解密sp票据,保证了即使在网络传输过程被人截获也能保证用户信息的安全
- agent票据由IDP Engine用IDP Server的密钥加密,只有IDP Server能解密agent票据,agent票据保存在IDP Server中
- UA票据由IDP Engine进行非对称加密,用户的唯一标识,存在客户端
- 单点时IDP Server需要能够获取到该票据进行验证
3. 设计实现
2.1数据交互方式
通过URL传递数据。
2.2参数格式
2.2.1. AuthnRequest
内容 |
由SP属性集合、callbackURL组成 注:CallbackURL不是必须,可以使用IDP Engine注册的默认callbackURL
|
格式 |
Sp属性集合 Sp编号:sp 元素之间以“;”分隔,key与value之间用“:”分隔 比如:sp:12345;authnReqID:abc123;sign:signValue callbackURL:service
请求格式组成 req=请求属性格式&service=callbackURL
|
编码 | Base64,在网络以Base64编码传输 |
2.2.2. CredentialsRequest
内容 | 由请求属性集合,签名组成 |
格式 | l 请求的属性主要有: 1、身份(由用户名和域组成,格式: 用户名@域): principal 2、当前时间:time 3、票据类型:type 4、随机数标识:nonce 5、IDP Server代理:agent 6、引用: reference 7、sp编号:sp 格式:time:x;type:x;principal:x;nonce:x;agent:x;reference:x;sp:x 元素之间以“;”分隔,key与value之间用“:”分隔 l 签名,对请求属性用私有密钥加密生成密文,格式: sign=加密算法:密文 私有密钥由用户名、域和密码 md5而成,格式 域 + ":" + 用户 + ":" + 密码
请求格式组成 req=请求属性格式&sign=签名&service=xxxx |
编码 | Base64,在网络以Base64编码传输 |
上述自定义协议其实并不完全安全,你知道问题在哪么?