任务背景
之前的项目已经上线了,对于客户有点数控制要求,因此要接入公司的授权服务,进行客户端登录点数的控制。
公司的授权服务主要是针对客户端应用程序的,针对Web应用程序的授权控制需要在服务器端进行操作,与客户端的控制还是有一些区别的。
方案概述
- 授权服务器端进行具体的授权管理,按照应用进行区分,各个应用分配一定的点数进行控制(点数达到上限后则不许登录或者不许启动);
- 按照一定的时间向授权服务器发送心跳,超时之后该用户对应的点数将被释放;
- 用户登出的时候释放所占用的点数;
- 应用与授权服务器需要约定好应用标识符,用以唯一标识该应用;
- 应用(包括Web应用的服务器)与授权服务器之间的交互信息需要加密;
相关技术实现细节
Web端使用的用户标识符
不同于单机的exe产品,可以方便地读取PC的硬件信息,然后使用硬件标识作为用户的唯一标识,以确定该用户(或者该PC)占用了一个点数。
对于Web端产品来讲,JS无法方便地读取硬件信息(好像仅有IE可以通过ActiveX插件来进行读取),所以需要考虑一个替代方案。
此时就想到了利用Cookie:
- 用户登录到服务器的时候,随机生成一个UUID作为该用户的标识符;
- 将该UUID写入到用户的浏览器Cookie中;
- 之后的每次请求以及心跳都携带该Cookie信息上传到服务器,就可以标识该用户了;
这样做会有一个弊端:
同一个用户在同一台电脑上使用多个浏览器的时候,该用户将占用多个点数。不过这样也是合理的。
应用服务器与授权服务器交互的加密秘钥
应用服务器与授权服务器之间的交互需要进行加密处理。
采用的加密算法是AES对称加密,即加密/解密的秘钥是一致的。而这个秘钥并没有提前约定,而是每次通讯的时候临时约定(也就是秘钥信息会包含在请求中)。
由于应用服务器与授权服务器之间的通讯是由应用服务器主动请求,授权服务器被动响应的,即典型的请求/响应模式。所以对于一次请求/响应,应用服务器需要记住秘钥,而授权服务器可以用完就扔。
而出于安全考虑,秘钥确定采用了一个小技巧:
- 授权服务器提前生成一个UUID,执行MD5处理后将该UUID的前16位截取出来,与应用服务器提前约定好作为秘钥的前16位;
- 应用服务器每次请求的时候,随机生成一个UUID并做MD5处理后