本篇文章介绍云联壹云多云账号对立治理性能。本文分三局部，首先介绍为什么要设计多云对立账号治理这个性能。其次，介绍此性能的具体计划和工作原理，最初，介绍如何应用多云账号对立治理性能。

为什么须要Cloud SSO

多云账号对立治理在咱们的平台中又称Cloud SSO，Cloud SSO能够了解为云平台的对立的单点登录。Cloud SSO是多云账号对立治理的其中一部分，然而其中最有特色的性能亮点。

在企业应用多云的场景中，可能会有多个私有云，每个云上可能还会有若干个账号。

在这种状况下，可能会在治理员工的账号方面遇到一些艰难。

多云场景下用户账号治理常见问题

例如局部员工想要应用某个云上的性能，咱们的管理员就得为员工在云上开设相应的账号并设置相应明码。

员工忘记明码之后，管理员须要帮忙员工重置明码。

除此之外，有可能员工本人在平台上设置的明码过于简略，存在被歹意检测并攻破的危险。

同时，在管理员给员工设置权限时，可能设置不合理，例如设置过低，或者设置过高。在权限设置过高时，员工登录到云平台上就可能会做超过其权限的操作，例如员工原本不应该去对主机进行操作，然而因为权限设置范畴过大，极有可能呈现误操作的状况。

一旦呈现员工到职的状况，对于到职员工在若干个云的若干账号里开设的相应的账号和权限，管理员须要一一清理，免得留下后续治理隐患。

多云场景下用户账号治理复杂度剖析

以上都是在多云场景中员工账号治理呈现的一些常见问题，咱们能够对其复杂度进行剖析，首先从管理者角度，也就是从企业的云账号治理的这个角度来看：

第一个维度，企业员工数量泛滥（N），账号管理员可能要为每个员工都要去开设云上账号，其次，该企业可能还会有若干个云账号（M），管理员为了去给员工在账号上开设权限，就必须登录到云账号上一一开设，一一登录并设置这些权限，而且每个云上的权限都非常复杂，有几十上百种权限组合（P）。

因而，整体来看，对于一个管理者而言，它的治理复杂度是NMP的数量级，是几何级数的复杂度。

并且管理员通常须要手动到云的控制台下来开设这些账号，设置明码和权限。整体复杂度较高，容易出错。

从员工角度看也比较复杂，员工若有登录多个账号的需要，则员工须要记住登录账号的账号名和明码。

因而，不管从治理复杂度还是应用复杂度上看，在多云的场景中，用户在云上账号的治理都很繁冗且容易出错。

多云对立账号治理的计划正是为了解决这个问题，其核心思想就是通过云联壹云一个平台，把企业的员工在多个云账号的登录权限，进行对立治理。

员工能够登录到咱们的平台，再通过咱们的平台去取得登录到各个云上的权限，并且可能无明码地跳转，通过 SSO(Single Sign-On)的形式间接跳转过来，这种形式能够大大降低企业的管理者和员工的应用复杂度，晋升效率，避免出现谬误的状况。

多云对立账号治理性能组件

多云对立账号治理性能，次要是两个组件，第一个组件是员工的账号治理，平台从管理员的角度去保护每一个员工在平台上的账号以及这个账号在每个云账号中相应的权限。

第二个组件是对立登录组件，这个组件容许企业员工登录到云联壹云之后可能登录到其余云平台，并且遵循管理员配置好的权限束缚，例如员工在某个云只有只读权限，某个云有某个产品的应用权限等。

如此实现通过一个平台对立实现企业在多个云上的多账号的员工账号治理目标。

多云对立账号治理收益

多云对立账号治理的收益其实非常明显。如果没有这样的工具，企业的多云账号治理复杂度是几何级数的。

通过云联壹云一个平台去做一个对立治理，管理员就不须要到每个云上对每一个员工的权限去做简单的设置，而是在咱们这个平台对立地定义好员工的权限范畴，针对每个员工逐个设置。

这样能够了解为复杂程度升高到员工数量的数量级，对用户而言也非常简单，用户不再须要去牢记每个平台的账号、明码，他只须要晓得登录云联壹云的账号密码。

登录之后，能够看到管理员授予的可能登录的云账号以及相应权限，并且能够一键跳转，登录到相应的云平台去实现在云平台上相应的操作，所以不论是治理复杂度还是应用难度都大大降低。


上面将介绍如何去实现通过咱们平台去其余云平台的对立的登录，无明码的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的计划可能解决好咱们开篇介绍的企业在账号治理方面遇到的问题。