太久没写过博客了,用户名密码甚至连用哪个邮箱注册的都不记得了,如果不是最近面试官要看的话实在是不想翻出来(如果面试官看到请不要在意)。
面试过程中被问了一些刁钻的问题(当然,也不是故意刁难),其中有两个问题值得记录一下——不是因为问题本身,虽然问题本身也有点意思,但更主要还是趁自己还没忘的时候记一下当时没考虑到的情况。
1、SSO的吊销机制
SSO通常有因为种种原因需要对token/ticket进行吊销的情况,在此之前我的设计思路是认证服务通过与业务服务连接的可靠信道发送吊销指令,这部分本身没什么问题,但是考虑到这是个安全机制,假如设计上只考虑了对有效期内的token/ticket进行吊销的话,可能会遭遇对服务器时间差的exploit,比方说很多人听说过有些机器运行了几天时钟就慢下去了,假如遇到这种情况的话在token/ticket吊销后业务服务器比认证服务器的时间慢了多少攻击者就有多少时间继续用token/ticket胡作非为。
解决这个问题有几种思路:
最死板的做法是吊销指令保存时间比被吊销的token/ticket还要长一些,只要它超过了业务服务与认证服务之间可能产生的时间误差就没事;
不那么死板的做法是所有服务都通过统一的授时中心进行时间校准,如果服务器一段时间无法联系到授时中心就发出警告并准备暂停运作;
还有一种情况是假如业务服务器存在某种可以直接前后调整时间的小漏洞的话,以上两种做法都无法彻底解决问题,所以针对这种情况进行防御需要在一个相对可靠的持久位置记录最后一次对吊销指令本身进行清理掉时业务服务器的本地时间,并且一旦在解码token/ticket时发现本地时间早(慢)于已记录的时间则中止鉴权过程并报警。
当然,由于我对SSO实施的经验并不多,以上思路难免有考虑不周的地方,请任何读到本文的人不要以此作为实施标准。
2、docker的实现原理
被问到这个问题时我的第一反应是也许需要像在Windows上一样通过所谓的APIHOOK技术来劫持系统调用;后来仔细一琢磨其实结合*nix万物皆文件的哲学,可能overlayfs就把一切全包了吧?
短期内没有深入研究docker原理的想法,如果我猜得不对欢迎指正;同前一个问题,依旧不要把我的思考当作答案。
标签:第一篇,SSO,问题,面试,token,思考,服务器,ticket,吊销 From: https://www.cnblogs.com/NanaLich/p/17121386.html