开发者学堂课程【IDaaS 企业身份管理：【视频】甩开密码，SSO ！】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/980/detail/14906
【视频】甩开密码，SSO ！
流程：
首先用户去打开一个应用地址，通过浏览器打开对应资源，我不知道你是谁，我需要你去登录。发出一个SAML request基于SAML协议的request请求，然后302跳转到IDaaS的登录页。IDaaS会把这个登录页通过浏览器返回给用户,用户这边再去IDaaS的登录页进行登录流程，这里的登录可以是IDaaS所提供的任何一种登录方式。包括钉钉扫码，微信扫码，短信登录，也包括IDaaS 二次认证等等一系列安全认证方式。
这种方式通过浏览器输入给IDaaS的这个服务,IDaaS会去校验他当前登录身份身份信息和他的用户名密码是否是正确。如果是正确的话，IDaaS这边会签发一个SAML response，代表已经登录成功。SAML response把这个信息通过浏览器再次跳转回应用那边，应用那边会验证SAML response返回的请求是真实有效的，最后登录成功，并且把这个登录成功的信息反馈给用户。用户在这个时候就可以直接去访问一系列的应用资源。
可以看出，这里跟SAML最核心相关的一共是三个步骤：
第一个是应用需要登录SAML发起SAML request这一步是应用发起整个的由IDP去托管登录流程的那一步。
第二步是SAML response，这一步指的是IDaaS验证用户身份之后，告诉“我“对应的应用资源，”我”已经验证通过了，这个用户是没问题的，然后”我”告诉”你”，这个用户就是 SAML response。
最后一步是验签的这一步，SAML协议就是依赖于这一套体系去进行运转的。但是SAML协议本身因为它年代比较长，有很多的历史的兼容性的挑战，所以他在整个设计它的参数的时候会变的相对而言比较复杂，此处有一个链接:
https://help.aliyun.com/document detail/408949.html 《SAML2.0SSO配置)
下面打开链接看一下：
在这里会描述一系列的IDaaS,这边去配置单点登录的时候，它需要填写的一系列的这个字段，这些字段名称:
有的人不知道这些是做什么的，这个文档里有一些简单说明，网上也会有一些对应的资料，去看，去理解，到底SAML协议里边的细节是什么样的，比如说它的变迁机制是什么样的，加解密机制是什么样。这里可以展开去说。但是作为一个通用性质的说明,我们了解到这个地步已经足够了。这就是SAML 2.0协议。
六．OIDC授权码模式认证流程
IDaaS支持的另外一个标准协议是OIDC协议。这个协议也非常典型，非常有象征性价值。因为全世界范围内，除了SAML协议使用面最广以外，所有的新兴的应用基本上全部会走OIDC协议去进行对接。
特点：
1. 基于Oauth协议
2. 是把这个就有Open ID协议和Oauth两个协议叠加在一块，所以他的很多流程跟Oauth是完全重复和通用的。比如说OIDC的授权码模式，其实完全是Oauth的授权码模式。OIDC协议的授权码是可以完全覆盖Oauth的场景的，所以IDaaS现在也可以完全说我们是支持Oauth的一个协议的。只要用OIDC去配置就可以。
3. 基于jwt （json web token）
这是一套json的格式的信息传递的方式，相比于刚才SAML协议的XML信息传递方式，它会轻量级非常多，而且看起来易读性也会强很多。
更现代，性能更高
这是更现代的一种方式，由于JWP token可以把很多东西压缩在一起，所以它的体积一般会比SAML协议的XML要小非常多，所以它在性能表现上也会更高。
下面看一下流程：
OIDC协议和Oauth协议一样，它也分为很多个不同模式，以适用于不同的授权类型。举个例子OIDC授权码模式或者Oauth的授权码模式适用于网页的资源应用的资源需要经由一个外部的授权才能够访问的这种场景。
而OIDC的设备流模式，在设备的这个device for这个模式里，我能做到的就是在一些特定的硬件或者设备的这个界面上，可能不适用于展示出过多比较花哨的登录页，他可能屏幕会非常的小，甚至就是一个命令行。
在这个情况下，设备流模式允许那个命令行里可以用一种比较绕一点的方式，能够让用户在别的浏览器里完成对这个只有命令行的设备终端的最终的登录。它的每个不同模式都是有不同的使用场景，授权码模式是我们最常见的适用于这个模式，它的安全性也是没有问题的。
这个图中把和刚才SAML协议完全一样的置灰，所以现在直接就可以看到有哪些流程跟刚才SAML协议是不同的。
SAML发起了一次SAML REQUEST请求，请求到IDaaS发起这次单点登录。在这个OIDC的模式下，IDaaS在OIDC模式下提供了几个端点，其中一个就是authorization授权端点。它的作用和刚才的SAML request相对而言是比较像的，所以它直接应用通过授权端点这样的url结尾，去请求IDaaS进行登录。登录完成之后，刚才的SAML是返回了一个SAML response，但是在IDP这边，这次OIDC协议返回的是一个授权码authorization code。这是授权码模式的名字的来源。返回了code之后，再返回到应用。
另一个非常大的不同是它的用户下一步的信息的校验。对于SAML而言，刚才其实直接验签就足够了，因为在他的SAML response里，就是这一步返回的信息里给到应用的时候，应用这边是直接可以拿到相对应的结果，比如用户是谁等信息。但是在授权码模式的时候，在这一步还不够。
它只是把一个授权码给到，现在还需要拿这个授权码去IDaaS这边去换一个token。然后token里包含一系列对应的信息。在对应信息里它就可以验签，然后拿到用户信息继续去进行完成登录的流程。可以看到绝大部分的流程体系，SAML或者OIDC是通用的也是基于刚才分享的五个步骤去进行的流程。但是会有一些不同的术语，比如需要指出来IDP和SP应用之间，在SAML环节中是不需要直联的，但是OIDC的环节中是需要直连去进行一次互动的。
这也就导致我们IDaas本身如果使用一个公网IP的话，应用一定需要能够访问到一个公网IP，它所在的网络环境不能是一个完全隔绝的内网环境，整个OIDC的协议，授权码模式协议才能够走通。所以OIDC和SAML各有各自比较适应的共通的协议的部分，也有他们各自适应的不同的流程。
对于既有协议，已经在使用的那些应用已经支持SAML了，因为SAML是最通用的，都会推荐走SAML。假设现在这个应用支持OIDC或者Oauth，或者现在什么应用都不支持，都建议统一走OIDC的模式去进行统一的支持。
七．实际演示配置单点登录的过程
实际演示一下到底配置单点登录的这个过程以及单点登录的体验是什么样的。
接下来会配置一个应用，叫做sonar cube，这是一个非常常用的代码质量检测的工具。并没有任何的这个特殊含义选择这款应用，只是这款应用正好有我们需要的一个测试环境，可以工序这个对接测试的链条。
下面来看一下到底在IDaaS里面怎么去配置，来到IDaaS的商品详情页，点击前往控制台，使用其中一个已经创建好的实例：
把他禁用掉，不会产生影响。再创建一个新的：
选择添加应用，进入到配置页面，需要把服务地址填写上，自己部署的服务地址，注意服务地址最后不要添加斜线，配置之后，点击保存。为了测试的便捷性，在这里直接选择全员可访问。在IDaaS中的配置就完成了。
现在前往送到Sonar Qube那边，开启这个单点登录的流程：
首先作为管理员登录Sonar Qube的后台，到他的这个管控页面，它的安全配置中，有一个SAML相关的配置，开启保存：
配置中心的内容之前配过一次，所以有好多内容是之前已经配好的，比如说application ID，我们需要给他写成sonar Qube，因为到时候IDaaS会把字段传过来，两边需要保持一致。Provider Name指的名称，会显示在sonar Qube登陆页上，可随便填写，这里写的是阿里云IDaaS。Provider ID、SAML login url、Provider certificate这些需要在IDaaS复制过来，回到应用配置信息，把IdP唯一标识复制到Provider ID中进行保存，把IdP SSO地址复制到SAML login url中进行保存，把证书内容复制到Provider certificate中进行保存。
SAML user login attribute中写username,SAML user name attribute中写displayName，SAML user email attribute中写email。
这样就完成了所有SAML需要的配置。
确保处于启用状态：
下面就可以直接登录了。再退出的时候会显示出：
这里的字是使用阿里云，后边是实际刚才配置的IDP的名称，使用IDP进行登录，但是空间有限没能显示完。点击登录的话：
它会提示当前提交的信息并不安全，本身是因为在访问的时候，推荐所有的部署的这些应用至少都要支持HTTPS，但是当前因为是我们自己内部的一个测试环境所以直接用的HTTP头文件，因此浏览器会提示提交的信息不安全。
点击仍然发送，作为michael这个账户就登录进来了。在这个浏览器已经登录过了，现在换一个浏览器试一下，打开无痕模式的浏览器，重新尝试进行登录，会跳到对应的登录页中：
输入已知的用户名和密码，点击登录以后，显示需要二次认证：
输入短信验证码，点击确认，
仍然会提示。点击仍然发送，就在Sonar Cube的管理后台登录成功了。可以看到拥有的权限和刚才是不一样的。作为子级管理员登录是看不到部分信息的。
这样就完成了单点登录整个的流程。
假设同一个账户希望能访问到用户的门户，回到实例，点击用户门户的链接,会出现登录页，点击登录，还是一样需要二次认证，等待短信验证码，进行登录进入，
进来会看到Sonar Qube2这个应用已经显示出来了。之后点击仍然发送，就进入到了代理登录到Sonar Qube这个流程中。从IDP这边登录到门户后点击发起的流程称为代理IDP发起的单点登录流程。
把刚才在应用侧在这里log out推出之后，从应用侧发起的单点登录流程称为SP，就是应用发起的单点登录流程。
这两个术语在一些情况下可能大家会看到，通过很直观的一个配置作为管理员的配置是相对而言非常简单的。配置成功之后，作为用户就可以通过一套阿IDaaS的账号体系去登录，可能会出现的无穷多个不同的应用的组合。这也就是单点登录在身份统一的层面上能够做到的防控（统一的收口），以及单点登录的去密码化和便捷性带来的一些变化。
下一次想要去登录应用的时候，会发现不需要输入用户名和密码就可以直接访问了，访问其他应用的时候也是如此。这就是单点登录本身对于企业用户而言带来的便捷性。一次验证之后只要在当前会话范围内，所有其他的应用只要是他们的登录体系也托管到IDaaS这边来，都不需要再登录了。
通过这样的方式把整个登录收口到IDaaS这边来，同时也把所有的恶意进攻，恶意访问的请求全部收束过来，这样IDaaS就成为了可以不断加强整个体系安全性的堡垒。
