在阅读本文前，需有一定的统一身份认证的知识，最好阅读或者使用过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编码传输 |
| 内容 |
由请求属性集合，签名组成 |
| 格式 |
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编码传输 |
上述自定义协议其实并不完全安全，你知道问题在哪么？