开发者学堂课程【IDaaS 企业身份管理：【视频】甩开密码，SSO ！】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/980/detail/14906
【视频】甩开密码，SSO ！
内容介绍
一． 什么是SSO？以微信登陆为例
二． 为什么要SSO?三个原因
三． 为什么要SSO?之前v.s.之后
四． 典型SSO流程 简化版
五． SAML 2.0 协议认证流程
六． OIDC授权码模式认证流程
实际演示配置单点登录的过程
在整个企业身份管理过程中，最为关键的一个环节就是甩开密码进行单点登录。单点登录是承载企业身份收口的这个环节非常重要的一个步骤。
因为在整个的控制和登录流程中，单点登录可以把所有的这些企业的访问行为全部收到一个单点进行统一的管理，从而带来一系列的好处。
上一节课描述了整个企业一般情况下会面临的身份挑战，那这节课会更加注重于在单点登录这个环节的细节上面，经常会遇到的一些名词以及他的逻辑是什么样的一些问题。
一．什么是 SSO？以微信登陆为例
首先来看一下什么是单点登录。这里以微信登录优酷这个网站为例。当然，这并不是一个企业级的或者企业软件的登录，但是这是大家喜闻乐见的一种登录方式。
用这个和整个的企业级单点登录的流程去进行对比，大家可以很快理解到实际这个IDaaS这个产品到底在做的是一个什么样的事情。整个IDaaS提供的能力肯定要比微信登录这个很简单的一个单点功能要复杂的很多，所以这本身只是一个为了让大家能够很快理解IDaaS的功能。下面来看一下优酷微信登录的视频。
视频内容：首先在优酷上面尝试进行登录，登录的时候会提示有一系列登录方式，点击微信的话会打开微信的页面，在用微信扫码之后，就直接回跳回了优酷并且处于登录状态。
对标
1.优酷->业务系统
2.微信->IDaaS
3.协议->OAuth
这是一个非常常见的日常用微信来扫码登录的一个流程。这个流程放到整个企业的单点登录流程中，优酷指的就是业务系统。客户实际想要登录和访问的永远是某一个业务系统或者应用，或者某一个特定的资源访问某个特定的网址，这个网址是受到身份保护的，需要登录才能去访问。这个时候业务系统就会触发一次需要进行身份验证，就像刚才优酷打开了非常多的登录页面，从而用户在选择需要用微信去登录的时跳到了微信的页面。微信在这个流程中的这个地位其实就是IDaaS的地位，叫做身份提供方Identity provider，英文简称缩写叫IDP。
这个过程其实是把在手机上已经登录好的微信这个可信身份的信息，通过扫码这个行为告诉这个网站的用户，优酷这边相当于之前提前就已经绑定过一次。如果现在登录进去，在优酷的安全管理的一个界面上是可以看到使用者的个人账号是已经绑定了这个对应的微信的，优酷已经知道这个微信对应的优酷账号是哪一个账号。
在整个流程中，优酷本身作为一个应用系统，需要进行登录的时候，它将它自己的登录能力托管给了微信这个身份提供方，微信进行了扫码的这种认证方式之后，又回跳回到优酷并且携带着微信的身份信息。优酷自己知道微信的信息和优酷的账号之间的对应关系，也就是知道当前要把哪个账号去进行登录。
视频里刚才一闪而过的一个细节是，在扫完码之后从微信跳转回优酷的时候，它的很长的一段链接地址一闪而过。这个协议本身使用的是OAuth协议，走的是授权码模式。这是单点登录非常直观的体验。
二．为什么要 SSO? 三个原因
如果把单点登录的行为搬到企业的范畴内，很多事情一下子都会变得更加复杂。因为企业本身是一个整体，而且更加强调管控，这其中的账号可能有非常多个，所以就会导致一系列的问题。
1、用户:一堆密码真麻烦
-用户经常忘记、重置
从用户的角度看，假设现在不用单点登录这个行为的话，如果要访问十个不同的应用，那么就需要去管理十个不同的应用。它对应的账号和密码，有可能密码都不一样，因为每一个应用对应的密码复杂度策略可能是不一样的。现在的绝大多数浏览器都可以帮助记住它对应的网址，对应的这个密码是什么，可以非常方便的代填填写进去。
问题在于，企业级的应用往往它的密码都有重置功能，密码是有有效期的，过一段时间就得重置，而且重置了之后不能和过去的几次密码相同，因为它是有历史密码记录的。
这一系列的问题本身是密码其实是非常薄弱的一个身份安全的环节。所以不同的业务系统根据他们各自的安全策略，会在密码的安全性上叠加各种各样的更复杂的逻辑，而且每个叠加的方式都不一样。
这样就导致整个密码的管理如果就依托于浏览器记录，或者依赖于写张小条，存到某一个文件夹里，这些方式毫无质疑都是非常不安全的。但是在这种不安全下给用户本身造成的影响就是可能用户希望能够找到一种更简单的便捷的好记的方式，而这种方式大概率是不安全的。
如果他要能够确保安全的话，整个的登录流程就会变得非常麻烦。他可能不一定能够非常成功的记得每一个应用不同的密码，然后成功的去登录和访问，这是一个视角。
2、管理员:企业集中管理的诉求
-多密码传递易泄露
-老系统登录安全无保障 -无统一审计、统一授权
第二个视角是管理视角，因为企业本身是有集中管理这样一个非常清晰的诉求的，他希望知道每个人到底都在干什么，希望分配给每个员工需要能够访问的应用系统。同时，一个企业内的IT管理人员（不一定是专职的IT，有可能就是研发的leader）或者说是老板，在很多情况下，这个某些特定业务系统的管理权限就是在这些人的手中。当用户忘记密码需要重置的时候，这些重置请求可能只有找到这些leader，他们那边才有权限去进行管理，而每次这种过程都会浪费一定的时间，而且这个沟通过程并不是说“我现在要重置”然后就重置了，而是“我现在重置”老板或者leader一时半会没看到，员工可能就只能干等，没有办法进行后续的工作。
老旧系统登录安全也会有一定的问题。这种登录的流程和安全性，在整个的应用层面或者整个企业层面，不同应用并没有统一，所以会导致用户在实际登录的时候，每一个应用所经历的流程可能都不一样，而最关键的所有东西收数下来，管理员就相当于假设是分散了很多。
不用去单独管理这个账号体系的话，没有统一的审计，没有统一的授权，没有一个权限的收口，也没有一个宏观的可以查看所有的人的当前现状，谁有什么权限，以及他们进展的一个收口，这是非常非常关键的企业级的这个管理上的诉求也是我们最常见的使用IDaaS的最根本原因。
3、安全:安全问题
-定期改密?首次改密?密码复杂度? -多密码传递易泄露
-如何允许员工拿一把钥匙，开所有门?
第三个问题也是非常核心的安全问题。刚才提到密码这个环节是非常的薄弱的一个环节，所以不同的业务系统就会往上叠加一系列的跟密码相关的一些安全策略，包括IDaaS在内，持续不断的在密码层面上有更大的灵活性，更多的成熟度去支持不同企业不同级别的客户对密码安全性的保障的要求。常见的有定期改密，首次改密，密码复杂度等等。
假设要避开这些比较麻烦的事情，一客一个用户，十个应用都同一套用户名和密码，直接给到那个员工。这个行为是极度不安全的，因为并不知道每个应用本身的安全性，数据存储安全性是否能够得到保障。
假设在使用的一个应用过程中出现了一定的网络安全或者数据安全问题的话，拿到对应的密码就可以在所有体系内的其他的应用中畅行无阻，这是非常可怕的一种情况，所以所有的业务系统的薄弱点就成了整个企业的身份安全的薄弱点。
所有的这些问题，从用户的角度，也就是员工的角度，从管理者的角度，从安全审计的角度看，如果缺乏一套统一的身份体系，缺乏这种单点登录作为一个联合，就会出现一系列的问题。如何允许员工拿一把可信的钥匙就能够开所有的门，这是企业需要解决的一个比较偏底层架构，但是又必不可少的一个非常关键的问题。
三、为什么要 SSO? 之前 v.s. 之后
1、使用 IDaaS 前
需要用不同的身份系统中不同的账号和密码，或者用不同的登录方式 去访问对应的一系列应用，例如：JIRA应用是个项目管理应用，允许外部通过类似于ad外部身份管理体系去做代理认证，可能通过ad账号密码登录JIRA，可用短信登录SaaS CRM,使用钉钉扫码登录自研运营平台，通过自研的账号和密码登录自研BPM系统，最后通过打开钉钉工作台里的应用进入到钉钉内的报销软件。
可以看到这是一个用户视角，它在使用过程中是分散的。我们可以想象到，假设转换到管理视角的话，如果每一个用户都是种行为，那么整个局面都将是非常混乱的。例如有100个用户，这100个用户和应用之间就会产生迷宫一样的交叉，这套身份体系，管理和权限管控体系就变得基本上是失控的。
2、使用 IDaaS 后
用户和IDaaS之间有一个一一对应关系。IDaaS中间会有一个完整的组织架构，每个用户只需要在IDaaS里面出现一遍就可以了。在IDaaS中可以通过管理员统一去分配。这些分散的应用把自己身份验证的环节通过单点登录的方式，全部统一交由IDaaS进行处理。这样一来，整个的架构上面的清晰度就变得非常的高，在IDaaS这个环节，如果要增强安全性，就变得相对而言轻松很多。
刚才提到整个的身份安全体系，其实是取决于最薄弱的那一点到底有多强。IDaaS接入之后，后边的这些应用体系如果要访问就全部要经过IDaaS，事情就变得很简单了。只要IDaaS上面叠加的身份验证机制足够强，足够满足要求，满足行业标准，理论上它的安全性就是可以得到保障的。无论是多么老旧的系统，支不支持二次认证，支不支持扫码登录，甚至证书登录等等，都可以在IDaaS这一个环节上进行解决，模型就会简化很多。这是我们想要使用单点登录非常重要的一个原因。
四．典型 SSO 流程 简化版
单点登录流程对于行业内的人或者有经验的人来讲，不是一个很难理解的流程。整个身份的登录流程并不是一个非常麻烦的流程，但是对于如果没有接触企业级身份管理的客户人员可能在理解单点登录的流程上会遇到一些问题。我们会发现市场上其实没有一个特别好的能够针对单点登录，能够把它讲清楚的这么一个流程，所以这次做了以下的这几个分解，希望能够帮大家更清晰的理解到底单点登录是在做什么。
这个是一个简化版的非常典型的单点登录流程，这个流程里面不牵扯任何实际的协议，只是大概说一下到底单点登录是在做什么样的事情。
一共分五步。第一步用户需要访问某个应用，第二步应用判断不知道你是谁，所以需要先登录。但是因为登录已经代理给IDaaS了，所以现在自己的登录页一般是不再去继续使用了。所以在要判断登录的时候，会直接跳到IDaaS的登录页。
IDaaS登录页会展示给用户，然后用户直接去IDaaS登录页里,登录支持一系列的初级或者高级的认证方式，可以扫码，可以短信。在这个环节中会叠加人机识别，多因素认证，整个风控体系，我着重叠加确保IDaaS本身、登陆页本身。在登录了之后，IDaaS已经知道是谁了，把这个信息告诉给应用，应用就可以告诉用户你已登录成功，可以访问你要访问的应用了。
核心在于中间的234，相当于把原本在应用中的登录的步骤直接拉到了外部的IDaaS中去完成。全局看的话，这是一个应用，相当于如果有10个100个应用，IDaaS这个环节就成了10个或者100个应用统一集中的登录的管理中心。
回顾一下刚才微信的流程。为了帮助大家更好地理解，微信的流程如果往这个模式里面去套那就是：
用户现在要访问优酷，优酷说你现在要先登录，所以就跳到了微信，用户进行微信的扫码去登录了，登录了之后微信回跳到优酷登录微信的身份信息，然后优酷知道对的人是谁之后，就可以登录成功了。所以这是完全一样的流程，当然本身这个过程是一个逻辑上的简化的流程。
五．SAML 2.0 协议认证流程
接下来看一个非常典型的单点登录的协议，特别是在企业级的应用非常实用，而且是全世界最通用的登录协议，叫做SAML2.0协议，有时候也叫身份联邦协议。联邦协议的这个边界并不是特别清晰，它的定义和理解程度，到底身份联邦是什么。
这个图复杂点在于浏览器。可以看到所有的这个左、中、右所有的这三方交互全部都是通过浏览器跳转的，所以有一些可能本来比较简单的流程，我们不得不画出很多条线出来。
SAML这个协议有1.0和2.0两个版本。1.0现在应该是没有人去用，所以我们一般去说SAML的时候指代的就是2.0这个版本。
SAML的一系列特点：它只支持网页端，相对而言比较陈旧，它依赖于一整套的这个XML，作为载体的传递方式，信息传递方式就是这里写到的SAML response和SAML request，这两套东西是基于XML去传递身份鉴别信息的两套体系。这里的内容会比较多。
全球的通用性SAML协议是最佳的，就是支持SAML协议的应用，在全球而言，数量是最多的。
另一个特点是网络不互通的时候也可以使用，就是IDP和应用资源。假设IDP使用公共云的IDaaS,应用资源在客户的内网的时候也不会妨碍我们去进行单点登录属于这个流程。因为所有的东西所有的请求全部是通过浏览器的，他们两个之间并没有直接去连线，所以只要浏览器和IDaaS和应用之间可以进行互通就没问题了。
这里还有一个概念也是SAML比较特殊的一个概念，就是IDP和SP的概念，这两个词到现在已经变成了相对而言比较通用的单点登录流程里面去指代，身份提供方IDP指代去签发身份信息，去进行身份校验的这个统一身份管理的这一方和应用方，应用方指的就是SP。
这两个词一开始的时候其实是就是SAML协议专职宣布SAML协议中交互的两方的，IDP这方就是，比如我是一个身份提供方，我提供身份校验，我提供身份鉴别，全线鉴别，然后我发出这个身份之后，给一个业务系统，让他去知道这个人是谁，这是统一的那一方，另一方就是应用方，就是service provider 。SP这方是服务提供方。只要理解它就是应用那一方去验证由IDP这边发过来的身份信息的那一方就可以了。
