[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将网站各个功能做成微服务的形式，这是日后的重点。