统一身份证自定义协议(1)

在阅读本文前，需有一定的统一身份认证的知识，最好阅读或者使用过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编码传输

 上述自定义协议其实并不完全安全，你知道问题在哪么？