作者：刘宾， thomas_liub@hotmail.com
请尊重作者著作权，转载请注明出处，谢谢！
SSO笔记
典型的SSO机制
Kerberos
- 麻省理工大学发明
- 客户端/服务器结构与DES加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证
- 一种应用对称密钥体制进行密钥管理的系统，支持SSO
- 不适应互联网环境
- UNIX 和 Windows 作为默认的安全认证服务集成进操作系统
- 苹果的Mac OS X也使用了Kerberos的客户和服务器版本
- Red Hat Enterprise Linux4 和后续的操作系统使用了Kerberos的客户和服务器版本
OAuth2
- 名词解释
- Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。
- HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。
- Resource Owner：资源所有者，本文中又称"用户"（user）。
- User Agent：用户代理，本文中就是指浏览器。
- Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
- Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
- 授权模式
-
授权码模式（authorization code）
（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token） -
简化模式（implicit）
-
密码模式（resource owner password credentials)
-
客户端模式（client credentials）
-
- 令牌更新
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
OpenID
- OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性
- 没有实现SSO, 没有验证所有party
- 结合OAuth
- 仅web应用
OpenID connect
- 开源项目
- 登陆访问步骤
- 【百度域】，初始访问服务，无授权码，无access token
http://www.baidu.com - 【CAS域】，网关发起重定向浏览器到CAS
http://192.168.1.28:8091/openid/authorize?client_id=717771&redirect_uri=http://www.baidu.com&response_type=code&scope=openid%20email%20profile&state=123123 - 【CAS域】，无session id, CAS重定向授权(浏览器重定向)
http://192.168.1.28:8091/accounts/login/?next=/openid/authorize%3Fclient_id%3D717771%26redirect_uri%3Dhttp%3A//www.baidu.com%26response_type%3Dcode%26scope%3Dopenid%2520email%2520profile%26state%3D123123 - 【CAS域】，用户登陆，登陆成功后设置CAS域session id到cookie
http://192.168.1.28:8091/accounts/login http://192.168.1.28:8091/accounts/logout - 【CAS域】，登陆后，跳回CAS授权
http://192.168.1.28:8091/openid/authorize?client_id=717771&redirect_uri=http://www.baidu.com&response_type=code&scope=openid%20email%20profile&state=123123 - 【百度域】，重定向浏览器到访问服务，带授权码
https://www.baidu.com/?state=123123&code=ed27cf5ee1ac4c8784126bbf825ccb45 - 【百度域】，网关根据授权码，获取token，code -> tokens,设置access token到cookie
返回：curl -X POST \ -H "Cache-Control: no-cache" \ -H "Content-Type: application/x-www-form-urlencoded" \ "http://192.168.1.28:8091/openid/token/" \ -d "client_id=717771" \ -d "client_secret=1ac931638624e5d8ae002aaeaec4302031db92e7451edf36e0d008c9" \ -d "code=ed27cf5ee1ac4c8784126bbf825ccb45" \ -d "redirect_uri=http://www.baidu.com" \ -d "grant_type=authorization_code"{ "access_token": "82b35f3d810f4cf49dd7a52d4b22a594", "token_type": "bearer", "expires_in": 3600, "refresh_token": "0bac2d80d75d46658b0b31d3778039bb", "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc0NTU5ZGE1NTQzMTY4YzFiYTQ3OWJiMWFlMmRjMGRhIn0.eyJzdWIiOiIxIiwiaXNzIjoiaHR0cDovLzE5Mi4xNjguMS4yODo4MDkxL29wZW5pZCIsImF0X2hhc2giOiI2R0tQM1RfS09GcFBmNWh5bFNPMmxnIiwiZXhwIjoxNDkwNzUzODYxLCJhdXRoX3RpbWUiOjE0OTA2ODcxMTQsImlhdCI6MTQ5MDc1MzI2MSwiYXVkIjoiNzE3NzcxIn0.vzFWuo99uM2HK2TWML8zE5sLpEjg5NGSFMzxKbtYUrr_EDRghlZJwh1w8VHEzPDIbNfRfeOwqPC9nhbl2q1yJS1F8vJRrBVtBpyawLGqAr3_SBwA9Xx3AmZR5X8Xid-3SHqGu3n93gD-XbvP_gcvrdsfgmHJK5PWjqj1jA_5zMM" } - 【百度域】,读取用户信息
http://192.168.1.28:8091/openid/userinfo/?access_token=82b35f3d810f4cf49dd7a52d4b22a594 - 【百度域】,刷新token
curl -X POST \ -H "Cache-Control: no-cache" \ -H "Content-Type: application/x-www-form-urlencoded" \ "http://192.168.1.28:8091/openid/token/" \ -d "client_id=717771" \ -d "grant_type=refresh_token" \ -d "refresh_token=0bac2d80d75d46658b0b31d3778039bb" -d "client_secret=1ac931638624e5d8ae002aaeaec4302031db92e7451edf36e0d008c9"
- 【百度域】，初始访问服务，无授权码，无access token
- 登出访问步骤
- 【百度域】，浏览器访问百度域退出
http://www.baidu.com/logout - 【CAS域】，重定向浏览器到CAS域，携带CAS域session id
http://192.168.1.28：8091/acconts/logout
- 【百度域】，浏览器访问百度域退出
webSSO
- 适合本地资源和互联网融合，local， internet and cloud infrastructures
CAS
- CAS协议流程,基础模式
- TGT (ticket granting ticket):user name, TGC...
- TGT 的存活周期默认为 120 分钟
- TGC(ticket granting cookie)
- TGC 是用户持有对自己身份信息的一种凭据
- TGC 是 CAS Server 通过 SSL 方式发送给终端用户
- ST(service ticket)
- 在一段时间内失效，存活周期默认为5分钟
- ST 只能使用一次
- ST 是基于随机数生成的
- TGT (ticket granting ticket):user name, TGC...
- 浏览器访问应用A(CAS client)
- CAS client发现无ST,无session，重定向到CAS server
- 用户完成登陆认证
- 用户登陆
- CAS server生成TGT对象，加入cookie
- 分配ST,加入cookie
- 重定向回应用(CAS client)，带TGC, ST
- 应用CAS client验证(ST,TGC)
- CAS server验证ST,返回username如成功
- CAS client建立用户session
- CAS协议流程，代理模式
- PGT， 是 CAS Client 端持有的对用户身份信息的一种凭据
CAS Vs OpenIDConnect
- CAS不支持OAuth2. Fackbook, Google, Yahoo采用OAuth2做认证, 而且目前85%认证系统采用OAuth2
- 大部分采用OAuth2的系统将来会采用OpenIDConnect
- CAS缺失很多功能，不支持feature
- 动态client注册，发现
- 用户claim, client claim
- Even SAML support is weak
- CAS实现多步骤认证困难，大部分是基于用户名/口令方式
- 结论
如果可能尽量用OpenIDConnect,在过度阶段可以采用SAML方案从CAS到OpenIDConnect。
Conclusion
Like the little ant, OpenID Connect has high hopes. Where possible, use it. Make sure developers understand the roadmap for your organization: your domain, like all the other domains on the Internet, will adopt OpenID Connect. Use SAML to fill in the gaps until all the OpenID Connect libraries and web server plugins are available. SAML is going to be around much longer than CAS, so its a better bridge solution. Use CAS only as a last resort. You should require products and software that supports the identity integration method that align with your roadmap. Be flexible…using CAS is better than the app storing its own passwords. However, realize that this application will probably never support the two factor authentication services available in OAuth2 and SAML. There are many “good” legacy SSO protocols, don’t forget Siteminder in the Enterprise world… however, if you’re faced with the situation… try NOT TO CAS.
