[AWS] SSO: Single sign-on

由单点登陆到aws的http服务。

 

---

 

From: https://www.jianshu.com/p/613e44d4a464

单点登陆SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登陆后，就不用在其余系统中登陆，也就是用户的一次登陆能获得其余全部系统的信任。

单点登陆在大型网站里使用得很是频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操做或交易可能涉及到几十个子系统的协做，若是每一个子系统都须要用户认证，不只用户会疯掉，各子系统也会为这种重复认证受权的逻辑搞疯掉。

实现单点登陆说到底就是要解决如何产生和存储那个信任，再就是其余系统如何验证这个信任的有效性，所以要点也就如下两个：

• 存储信任
• 验证信任

 

以Cookie做为凭证媒介【安全有风险】

最简单的单点登陆实现方式，是使用cookie做为媒介，存放用户凭证。
用户登陆父应用以后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，受权应用解密cookie并进行校验，校验经过则登陆当前用户。

 

经过JSONP实现【有安全风险】

对于跨域问题，可使用JSONP实现。

 

经过页面重定向的方式

最后一种介绍的方式，是经过父应用和子应用来回重定向中进行通讯，实现信息的安全传递。
父应用提供一个GET方式的登陆接口，

用户经过子应用重定向链接的方式访问这个接口，

 * 若是用户尚未登陆，则返回一个的登陆页面，用户输入帐号密码进行登陆。

 * 若是用户已经登陆了，则生成加密的Token，而且重定向到子应用提供的验证Token的接口，经过解密和校验以后，子应用登陆当前用户。

Figure 01, Auth via redirect

这种方式较前面两种方式，接解决了上面两种方法暴露出来的安全性问题和跨域的问题，可是并无前面两种方式方便。
安全与方便，原本就是一对矛盾。

 

随之而来的问题

 

上图中Figure 01, 我拿什么来做为重定向的请求？

 

 

 

 

单点登陆系统(SSO)-总结

利用公司现有的SSO服务器来配置客户端开发用户登陆接口从而和别的公司对接。

 

SSO服务器的处理大体流程就是：

 

用户在A客户端登陆---->

SSO服务器验证用户信息---->

 

验证成功后在SSO服务器端会记下一个 TGC(Ticket Granted Cookie)票据 ，并且返回到A客户端时还带有一个 ticket参数 (它是惟一，不可伪造的参数),

在A客户端拿到 Service 和新产生的 Ticket 事后，与 SSO服务器进行身份核实，以确保 Service和Ticket 的合法性---->

 

退出登录时,会向SSO服务器发送logout请求（清除Session），以后SSO服务器会广播到其余应用服务器的logout（清除Session）。

 

 

下面拿我作过的案例来讲：

例如原始应用的网址是http://localhost:8080/cas-client/，在这个客户端登陆页面里form表单包含登陆用户名和密码，一开始有以下语句，转向CAS服务器的单点登陆页面 https://sso.nubb.com/login?service=http://localhost:8080/cas-client/。

SSO服务器完成主体认证后，会使用下面URL进行重定向 http://localhost:8080/cas-client/?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。 收到ticket以后，应用程序须要验证ticket。这是经过将ticket 传递给一个校验URL来实现的。校验URL也是SSO服务器提供的。

SSO服务器经过校验路径得到了ticket以后，经过内部的数据库对其进行判断。若是判断是有效性，则返回一个NetID给应用程序。 随后CAS将ticket做废，而且在客户端留下一个cookie。

之后其余应用程序就使用这个cookie进行认证（固然经过CAS的客户端），而再也不须要输入用户名和密码。 

 

 

 

SSO单点登陆三种状况的实现方式详解

相见原文

 

---

 

本文涉及到：http服务负载均衡等任务，例如经过Nginx [ Nginx is a web server which can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.]

如何利用aws将网站各个功能作成微服务的形式，这是往后的重点。