本篇文章介绍云联壹云多云账号统一管理功能。本文分三部分，首先介绍为什么要设计多云统一账号管理这个功能。其次，介绍此功能的详细方案和工作原理，最后，介绍如何使用多云账号统一管理功能。
为什么需要Cloud SSO
多云账号统一管理在我们的平台中又称Cloud SSO，Cloud SSO可以理解为云平台的统一的单点登录。Cloud SSO是多云账号统一管理的其中一部分，但是其中最有特色的功能亮点。
在企业使用多云的场景中，可能会有多个公有云，每个云上可能还会有若干个账号。
在这种情况下，可能会在管理员工的账号方面遇到一些困难。
1、多云场景下用户账号管理常见问题
例如部分员工想要使用某个云上的功能，我们的管理员就得为员工在云上开设相应的账号并设置相应密码。
员工遗忘密码之后，管理员需要帮助员工重置密码。
除此之外，有可能员工自己在平台上设置的密码过于简单，存在被恶意检测并攻破的风险。
同时，在管理员给员工设置权限时，可能设置不合理，例如设置过低，或者设置过高。在权限设置过高时，员工登录到云平台上就可能会做超过其权限的操作，例如员工本来不应该去对主机进行操作，但是因为权限设置范围过大，极有可能出现误操作的情况。
一旦出现员工离职的情况，对于离职员工在若干个云的若干账号里开设的相应的账号和权限，管理员需要逐个清理，以免留下后续管理隐患。
2、多云场景下用户账号管理复杂度分析
以上都是在多云场景中员工账号管理出现的一些常见问题，我们可以对其复杂度进行分析，首先从管理者角度，也就是从企业的云账号管理的这个角度来看：
第一个维度，企业员工数量众多（N），账号管理员可能要为每个员工都要去开设云上账号，其次，该企业可能还会有若干个云账号（M），管理员为了去给员工在账号上开设权限，就必须登录到云账号上逐个开设，逐个登录并设置这些权限，而且每个云上的权限都非常复杂，有几十上百种权限组合（P）。
因此，整体来看，对于一个管理者而言，它的管理复杂度是N*M*P的数量级，是几何级数的复杂度。
并且管理员通常需要手动到云的控制台上去开设这些账号，设置密码和权限。整体复杂度较高，容易出错。
从员工角度看也比较复杂，员工若有登录多个账号的需求，则员工需要记住登录账号的账号名和密码。
因此，不论从管理复杂度还是使用复杂度上看，在多云的场景中，用户在云上账号的管理都很繁杂且容易出错。
多云统一账号管理的方案正是为了解决这个问题，其核心思想就是通过云联壹云一个平台，把企业的员工在多个云账号的登录权限，进行统一管理。
员工可以登录到我们的平台，再通过我们的平台去获得登录到各个云上的权限，并且能够无密码地跳转，通过 SSO(Single Sign-On)的方式直接跳转过去，这种方式可以大大降低企业的管理者和员工的使用复杂度，提升效率，避免出现错误的情况。
1、多云统一账号管理功能组件
多云统一账号管理功能，主要是两个组件，第一个组件是员工的账号管理，平台从管理员的角度去维护每一个员工在平台上的账号以及这个账号在每个云账号中相应的权限。
第二个组件是统一登录组件，这个组件允许企业员工登录到云联壹云之后能够登录到其他云平台，并且遵循管理员配置好的权限约束，例如员工在某个云只有只读权限，某个云有某个产品的使用权限等。
如此实现通过一个平台统一实现企业在多个云上的多账号的员工账号管理目的。
2、多云统一账号管理收益
多云统一账号管理的收益其实非常明显。如果没有这样的工具，企业的多云账号管理复杂度是几何级数的。
通过云联壹云一个平台去做一个统一管理，管理员就不需要到每个云上对每一个员工的权限去做复杂的设置，而是在我们这个平台统一地定义好员工的权限范围，针对每个员工逐一设置。
这样可以理解为复杂程度降低到员工数量的数量级，对用户而言也非常简单，用户不再需要去牢记每个平台的账号、密码，他只需要知道登录云联壹云的账号密码。
登录之后，可以看到管理员授予的能够登录的云账号以及相应权限，并且可以一键跳转，登录到相应的云平台去实现在云平台上相应的操作，所以不论是管理复杂度还是使用难度都大大降低。
下面将介绍如何去实现通过我们平台去其他云平台的统一的登录，无密码的Single Sign On 的体验。
3、SAML2.0简介
这背后的技术称为SAML2.0（Security Assertion Markup Language），这是OASIS（Organization for the Advancement of Structured Information Standards）标准组织定义的一套在不同的实体之间交换用户认证信息的标准。这个标准的2.0版本早在2005年便已经发布。
为什么所有的云平台都统一采用了SAML2.0这个标准SSO的协议去实现到这些平台的一个统一登录呢？下面我们就对此进行详细介绍：
在SSO的技术领域中，通常有三个实体，一个实体称为IDP，英文名称是identity provider，中文翻译为认证提供者。
这个实体用来提供用户的身份信息，它会告诉别的实体这个用户是谁，有什么属性。
第二个实体的名称为SP（service Provider），中文翻译是服务提供者。
服务提供者是IDP的消费者，可以接收用户的认证信息，然后通过认证信息去确定用户是否有权限去访问相应的服务。
在我们这个多云的场景中，IDP就是类似云联壹云的第三方的多云统一管理的平台。
SP是各个云的云平台，例如腾讯云就是一个SP，我们的平台云联壹云就是IDP。
第三个是UA，其实就是浏览器，所以典型场景就是用户使用浏览器去访问Service provider，例如腾讯云的平台，然后需要有相应的认证信息，浏览器就会跳转到IDP，也就是云联壹云去认证用户，让认证用户认证通过之后再去跳转到相应的云平台去访问相应的服务。
为什么这些云平台都会选用SAML2.0这个SSO协议实现SSO登录呢？
下面我们一起了解一下SSO工作的流程：
在多云SSO的场景中，首先用户浏览器会主动访问云平台控制台的URL。
这时云平台就会发现浏览器还没有认证过，云平台访问URL时清晰地标识了用户的IDP是谁，这时腾讯云就会返回一个叫做AuthnRequest的表单返回浏览器,这个表单里面就携带了希望IDP能够认证的请求，并且会携带这个请求定向到IDP。
浏览器收到表单之后，就会跳转到IDP，也就是云联壹云认证的URL。
假设此时浏览器其实没有返回过云联壹云，还没有在云联壹云认证过，这时云联壹云就会返回那个浏览器，让用户去对云联壹云进行认证。
用户认证成功并登录之后，云联壹云就会再会返回一个表单给浏览器。
其中就包含了针对刚才腾讯请求AuthnRequest的响应，里面包含这个用户是谁，有什么样的属性，比如说他的角色、权限。
这些信息返回给腾讯云之后，腾讯云就会根据这些信息决定用户的角色和权限，能不能去访问这些平台。
然后会返回登录，如果是登录成功，就会返回登录成功的信息。
整个的流程为浏览器访问SP，然后SP跳转IDP，用户在IDP的信息就会就会返回给SP。返回给腾讯云，腾讯云会允许用户浏览器去登录腾讯云。
可以看到在SP和IDP之间，信息都是通过浏览器的表单去进行交换的，腾讯云把信息放到一个表单中反馈给浏览器，浏览器再把这个表单的内容提交给IDP，IDP把相应信息通过认证之后，把相应信息通过表单返回给浏览器，浏览器再把这个表单又提交给SP，提交给腾讯云， 腾讯云便可以实现用户登录。
在这过程中腾讯云和云联壹云之间没有直接的网络通信，腾讯云不需要直接访问云联壹云，云联壹云也不需要访问腾讯云，就实现了IDP和SP之间的信息交换，这个交换完全基于浏览器来进行。
对比其他SSO认证协议，例如OpenID Connect或者OAuth2，他们其实比SAML2.0要简单很多，没有如此复杂的交互流程。
但是其中有一个要求是SP需要能够主动地去访问IDP，用户访问SP时携带了IDP给用户的相应认证信息时， SP需要去直接去访问IDP去验证用户携带的这个信息是否正确。
但是SAML2.0没有这个直接交互的要求，SP和IDP不需要直接交互。
所以SAML2.0这种特性非常适合云的认证要求。因为通常情况下，在多云统一登录的场景中，IDP通常是部署在企业的私有环境中的。
而SP就是公有云，是放在互联网上，在公共的internet上。
他们之间对SP通常是无法穿透企业的内网去访问部署到企业内网的IDP。
所以在这种场景中，OAuth2和OpenID Connect这样的协议都是无法工作的，因此这些所有的云都会统一采用SAML2.0这样的方式去做统一登录。
虽然SAML2.0实现和交互都比较复杂，但是因为有这个独特的特性，SP和IDP不需要直接互访，所以大家都会采用SAML2.0去允许公有云采用部署在私有环境IDP进行认证。
如何使用
下面继续了解平台用户如何使用云联壹云实现多云统一账号管理和统一登录。
首先是从管理员角度，他需要维护用户在各个云账号上的权限，第一步就是在云联壹云维护各个云上的权限组合，这个权限组合定义在我们的多云管理云用户组中。
在云用户组中，用户可以针对每一个平台，当把它相应的权限定义成一个权限组，就可以把权限组赋予相应的用户，清晰地定义好用户在某个特定的云上的权限。
对于为什么会去针对每个云去定义不同的云的用户组，因为各个云的权限定义是非常不一样的。
与阿里云的主机相关的权限是AliyunECSReadOnly权限；但是到腾讯云又换成称为QCloudCVMReadOnly的权限。
因此，我们会为每一个云的平台去定义相应的云用户组的定义，这个定义就定义好了用户在云上的权限的组合。
定义好权限组合之后，第二步就需要去为每一个云账号开通免密登录的功能。
对于需要此功能的原因，是如果一个云平台需要能够实现SAML2.0 SSO登录，则需要在这个云平台上将IDP的信息，也就是当前企业使用的云联壹云提供的IDP的相应的信息在云平台上提前注册。
这个注册就是在平台开启免密登录这个操作时，平台就会自动调用相应API把相应的IDP信息在相应的云账号的认证员那里注册起来，这样后续的SSO跳转才能工作。
在每个定义好的权限组，并且把相应的云账号的免密登录开启之后，我们就可以去定义刚才说的用户在这个账号里面的权限的映射表，这个映射表在云账号的免密登录用户的页签里面去进行定义。
一般选择本地的用户，然后再选择一个相应的针对这个账号的云用户组，选择之后进行保存，保存之后就定义好了用户在云账号的权限。
前面三步即为管理员需要的操作，第四步是用户的使用方法，用户需要登录到我们的平台，在右上角的个人信息的菜单中选择多云统一登录菜单。
用户能够在这个页面中看到被管理员配置好的允许在相应平台上登录的账号以及相应权限。
当然还有免密登录的链接，用户只需要点击免密登录就能跳转到云平台实现免密登录。
下面介绍一下Cloud SSO — 多云统一账号管理功能在云联壹云支持的情况。
目前对于六大公有云都做了相应的支持，除了谷歌云因为一些技术原因暂不支持外，对阿里、腾讯、华为、AWS、Azure都支持Cloud SSO的功能。
但这些功能因为各个平台的差异，功能有一些细微的差异，下面介绍一下如何开启Cloud SSO的功能。
对于阿里、腾讯、华为、AWS这些平台，他们都已经提供了IDP在其平台去开启免密登录，打开设置IDP相应的API，所以我们可以通过API去自动设置。
所以只要针对这些平台在云联壹云里面，在云账号开启SSO，我们平台就会自动去开启相应的SSO功能。
但对于Azure，目前暂时还未开放设置IDP信息的API，所以我们平台针对Azure账号开启了SSO，其实还是不够，需要管理员登录到Azure的控制台，手动地去做相应的设置，开启统一账号登录的功能。
针对每个平台通过云联壹云登录过去的用户，它的载体也不太一样。比如像阿里、腾讯、华为、AWS， 他的载体都是一个角色，云联壹云平台要告诉各个公有云，这个用户登录到你这个平台里面是什么角色就可以。
这样的话，我们就不需要在下一个平台创建很多用户，只需要明确地告诉他这个用户在平台的角色，让用户登录过去。 这个平台会为这个用户创建一个临时用户，然后赋予相应的角色，用户就可以临时去操控这个平台上的相应功能。
但对于Azure，Azure的载体是一个来宾用户，需要我们去调用API在Azure里面创建，为每个登录过去的用户创建一个来宾用户的账号。
再赋予这个来宾用户相应的权限，这样从我们平台跳转过去的用户在Azure那里看到的其实是一个来宾用户。
另外还有一些限制条件，比如说目前Azure只有国际区才支持Cloud SSO登录。
以上基本把多云的统一账号管理和CloudSSO的登录介绍介绍完毕，下面我们了解一下典型的应用场景。
应用场景
这个场景中，在企业内网环境，企业的员工都是在内网中访问公有云以及内部的一些资源，员工的账号都是统一在企业内部的LDAP（例如微软的Active Directory域控制器）账号服务器进行管理。
云联壹云也是部署在企业的内网里面，这时管理员可以把云联壹云的认证源，也就是用户来源配置为企业的LDAP，这样员工就可以用企业内部LDAP的账号密码登录云联壹云。
同时管理员又开启了Cloud SSO功能，企业员工登录到云联壹云之后就可以让管理员在云联壹云去配置好具体的每个员工访问某个云平台以及相应的权限。
当员工登录进来就自然在云联壹云看到他在云平台上的权限，通过云联壹云能够直接登录各个云平台。
这样的好处是企业的管理员不用再为每个用户在每个云上去开设相应的账号，设置相应密码。
同时如果有员工加入，能自动通过LDAP登录到平台，管理员也能帮新员工设置在各个云上的权限。
并且员工一旦离职也就无法通过LDAP去登录云联壹云，管理员也不用担忧帮这个用户在各个云上删除相应的账号。
用户也只需要去记忆自己的LDAP的账号和密码，企业通常都会对LDAP的账号密码做严格要求，也就不存在密码丢失或者密码复杂度过低的安全问题。
综上，通过Cloud SSO的方案能够解决好我们开篇介绍的企业在账号管理方面遇到的问题。
