在介绍零信任和SASE相关主题的时候，我们提到一个重要的组件：IAM（Identity and Access Management）。可以说它是整个系统的大门，扼守重要关口，重要性非同一般。
IAM非常的复杂，今天二哥先来聊聊涉及IAM的几个基本的概念。这些概念看似基础，但实际上非常容易搞混淆。
枯燥和生动之间通常只差几个例子或几张图。所以本篇二哥照例通过图和例子来科普一下这几个概念。文末二哥会带大家看下Okta是如何借助IAM成为零信任生态中的执牛耳者的。
1. 先说重点
认证、授权和SSO是三个不同的概念。认证关注访问者身份是否合法，授权用于解决访问内容控制而SSO则用来改善登录多个服务时的用户体验。
认证：authentication，授权：authorization，SSO：Single sign-on。这三个概念的英文我先放着这里，后文就不再标示出来了。
2. 认证
但凡我们搭建一个应用，无论是传统的On-Prem还是现今流行的SaaS，首先需要解决的是用户安全登录问题。这个问题的核心是：二哥想要登录淘宝，淘宝该如何判断这个二哥的确是那个帅气幽默风趣的二哥？
很早之前，应用一般运行在本机，这个时候只要能登录进操作系统，就可以直接使用应用了。这里的“用户安全登录”其实是在OS层面完成的。
Web应用和SaaS的兴起彻底改变了“用户安全登录”的实现方式和使用方式。使用者除了需要登录进操作系统之外，还需要向SaaS服务说明“我是谁”，因为这些后台大多是同时服务多租户的，很显然OS层面的登录无法满足这样的需求。
认证的方式随着软件发布和使用的形态变化也一直在演进。我们来回顾一下在这段不算太长的历史中，那些使用过的、还没有被淘汰的认证方式。
2.1 账号密码方式
这是一个大家熟悉得不行的方式了。虽然这是一个古老的方式，但它也是在不断演进中。比如现在一般用邮箱的方式代替了诸如lancezhang这样的简单账号。系统拿到了邮箱可以用来做后续的推广。
另外系统对于密码的强度要求也在慢慢提高中。之前只要是6位数字即可，现在会要求数字、特殊字母混合，甚至会要求定期更换密码。
2.2 社交网络方式
通过社交网络认证是近几年流行起来的认证方式。对于使用者而言，这是一个比较自然，也比较友好的方式。比如几乎所有的中国网民都用微信，那直接基于微信登录的话，体验就非常的丝滑了。
当点击微信登录后，页面通常会跳转到一个含有二维码的界面。拿起手机成功扫码之后，浏览器再跳转回原先的页面，整个过程一气呵成，流畅无比。
社交网络认证的方式可以让提供服务的企业轻装上阵，省去了认证、授权方面的冗繁工作。通过认证后，服务提供商通常会从微信那里得到一个唯一标识码，用于标识该用户。并基于这个标识码来为用户提供服务。
当然服务提供商不能在一棵树上吊死，万一微信挂了呢？所以再来个“通过微博登录”就很合理。相似地，微博也会给一个标识码，这种情况下，服务提供商就得在后台通过所谓account linking的方式，将多个标识码归属到同一个内部定义的账号上去。这种多对一的关系映射对于码农而言不是个事。
2.3 无密码方式
无密码认证顾名思义就是认证的时候不需要输入密码，取而代之的是以类似短信验证码的方式完成验证。除了短信验证外，常见的认证方式还有电子邮件验证、电话验证、回答预设置问题（比如韦小宝可能会设置这样的问题：你最喜欢的前任女友的名字？）验证。
无密码认证的优势非常明显，系统不需要花费额外的精力来保存、保护密码，所以也就无需担心密码泄露的问题。同时用户也不需要费力去记住密码了。这也是相比用户名密码（Username/Password）方式，无密码认证得以快速流行的原因。看看下面的趋势对比图就知道这样的势头有多迅猛。
2.4 Multifactor Authentication
MFA大家应该也不陌生了。二哥人脸识别进入招商银行APP后，如果转账10万给三哥的话，APP会要求你输入短信验证码；如果转账100万的话，招行还会要求二哥再次进行人脸识别，看看这人是不是疯了。
多重认证严格来说不算是一种认证方式，它是前面提到的几种方式的叠加。2FA就是叠加两次，3FA就是叠加三次，虽然可能会让使用者发疯骂娘，但理论上确实是可以的。
3. SSO
在理解SSO为什么会出现之前，我们来想一个问题：在一个企业中，完成与工作相关的内容通常需要涉及到若干个SaaS服务。比如内部聊天用Zoom，文件共享用Dropbox，办公用Office 365，HR相关的服务有payroll系统，请假系统，员工信息管理系统等等。
每引入的一个新服务都需要认证。那么对于一个员工而言，该如何记住这么多的密码呢？只要有可能，员工就会给所有的服务设置相同的账号或相同的密码。如果每个服务对密码强度要求不同，另一种结果就是大家都非常不乐意使用新的服务，因为惰性是共性和天性，能不记一个新密码就不记一个新密码。
另一方面当一个员工小王刚刚入职的时候，他的角色是资深工程师，他被允许访问若干个系统以便可以完成日常工作。小王能力不错，几年后升任项目经理。这样的角色转变使得IT给他在不同系统中设置了不同的权限。不过到底设置了多少，散落在哪些系统中，除了上帝谁也不知道。再过几年，他被竞争对手挖走了。
苦逼的IT在清理他的账号时遇到一个棘手问题：小王到底在多少个系统中留有账号？这笔糊涂账带来的可能结果是：小王离职后好多月甚至若干年，他在某些系统里面的访问权限还被保留着，虽然是无意地。
对上面谈及的两个问题，完美的解决访问是SSO。用一个集中化的IAM来解决认证、授权、账号管理。小王从入职第一天起到离职那天结束，无论企业使用的服务怎么增多，他始终使用一个账号进行认证，同时无论他的职位如何变化，都在这个Identity Management系统上进行角色的调整以及相应权限的修改。当他离职了，直接在系统上把他的账号一键禁用即可。优雅、巴适得很。
需要强调的一点是：SSO不是一种新认证方式，它只是基于前文提及的现有认证技术，借助中心化的方式来解决分散认证所遇到的诸多痛点。
上图是与SSO相关的示意图。其中Auth Server扮演了IAM的角色，它保存了所有人的账号密码、角色以及相应的权限。当小王访问“二哥.com”时，“二哥.com”后台会做一些处理，再通过HTTP code 302给浏览器返回一个新的重定向链接。这使得浏览器实际访问的链接为：https://sso.auth.com?redirectURL=https://二哥.com/authCallback&scope=abc。可以看到这个链接里面带了许多额外的参数，这些参数如何设置需要阅读Auth Server的集成文档，这里只是做示例展示。
重定向到Auth Server后，在它的界面上，小王会被要求输入账号和密码，并可能会进行短信验证、邮件验证之类的2FA。
上面的链接中，https://二哥.com 其实是需要进行URL编码的。这里为了方便演示，略去此过程。下同。 auth.com是我瞎编的，不要当真，更别去试。这个小王我也不知道是谁。 SSO过程中有若干种广泛使用的协议，如SAML、WS-Federation、OpenID Connect (OIDC)等，但它们都不是本文的重点。
小王成功登录后，Auth Server会再次通过302让浏览器重新访问“https://二哥.com/authCallback?code=ABCD1234&state=1”。不过这次的链接里附有额外的与认证结果相关的参数。借助浏览器的重新访问，所达到的效果是将这些认证相关的数据带到了“二哥.com”服务端。后台通过它们可以到Auth Server那里获得诸如用户名、角色等在内的与此账户相关的详细信息。这些是“二哥.com”后台和Auth Server之间的交互过程，小王对此无感，浏览器在这中间起到了数据引荐的作用。
一切正常的话，这个时候浏览器中保存有两种cookie，一个是关联到“二哥.com”的，而另一个是关于Auth Server（sso.auth.com）的，且这两个cookie对应的session都是登录状态。
类似地，当小王访问“三哥.com”时，实际访问的是https://sso.auth.com?redirectURL=https://三哥.com/authCallback&scope=abc，于是访问再次被重定向到sso.auth.com。Auth Server发现请求中携带的cookie（Auth Server的cookie）所对应的session已是登录状态，那就不需要再次认证了，接下来的过程和刚才一样。此时浏览器中保存有三种cookie了，新加的这个当然是关联到了“三哥.com”。
图中画出来的5.b这一步所对应的场景是：小王在“二哥.com”网站上可以直接点击跳转到“三哥.com”。背后的过程是类似的。
4. 授权
授权用于确保用户不能访问到其它数据，这也叫做访问层级（access level）控制。经过认证后，用户会获取一定的权限列表。RBAC（Role Base Access Control）是常用的基于role来设置权限的机制。
比如对于一个提供工资信息的SaaS服务，小王还是普通员工的时候，只应该能看到他自己的工资单信息。而他升任经理之后，则可以看到他所有的组员薪资详情。
在非SSO场景下，想要实现访问层级控制是非常非常困难的。
授权和认证这两个过程既可以由一个IAM系统提供，如Okta，Azure AD。也可以分作两个单独的过程。
将授权作为单独的过程的一个例子是：云冲印。比如有一个"云冲印"的网站，可以将用户储存在Google的照片冲印出来。
用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。但很显然，用户不可能将自己在Google上的账号和密码告诉"云冲印"网站。怎么办呢？
用户会在Google照片上对"云冲印"网站进行适当的授权，比如允许该网站读取目录“2021年12月洱海之行”。这个授权过程的结束通常会产生一个token，当"云冲印"网站拿到这个token后就可以去Google访问（且只能访问）并打印这些洱海之行的美照了。
上面这个例子中，对"云冲印"网站而言，因为根本就不需要它做任何的登录操作，也就不涉及任何认证，但它涵盖了一个挺重要的使用场景：按需求授权。
其实这样的例子，我们平时经常会遇到，只是我们可能都没有太在意，比如手电筒APP想要访问你的通讯录，你会看到一个弹框请求。虽然这种请求非常无理，不过它的姿势是正确的，这确实是一个授权请求。当然你也需要对这种请求无情地拒绝。
5. IAM和零信任
感谢你耐心看到这个地方，我们先来做个总结吧。IAM有三大最基本的功能：认证、授权、账号管理。前面我们介绍了认证和授权，严格来说SSO不能算认证方式，它只是一种提高用户体验，提高企业安全的解决方法。
如果你读过二哥前两篇文章，你一定会发现在零信任和SASE版图中，有一个概念被反复提起：Identity-based Access。无论访问什么服务，访问者首先必须说明他是谁。零信任和SASE平台先决定他能访问什么，然后才开始扮演Proxy的角色，将请求和服务临时搭建起来。
Okta、DUO、PingID是IAM这个领域重要的玩家，当然也不能忘了Azure AD。这些玩家提供的产品不单单是前面所述的基本功能，还包括activity记录、追踪、分析、数据挖掘等等一些列让人眼花缭乱的功能。
他们重要到什么程度呢？零信任热门选手Zscaler、Palo Alto,、Cisco、Cloudflare、Netskope等公司的产品想要打怪升级，必须得和这些IAM厂商集成。
CrowdStrike、Netskope、Okta和Proofpoint通常以水果拼盘方式组成一个完整的SASE方案。我们可以从下图感知一下Okta的位置和戏份。在IAM细分领域，Okta在Gartner魔力象限里面无可争议地霸占了leader位置很多年。
Okta作为不可或缺的合作伙伴被集成到了SASE大版图中，是非常正常的。我们来看看它的功能吧。它的王牌是基于IAM和Activity分析的Risk Engine，但不止于此，它还把触角伸到了包含Device、IP、位置信息等在内的元数据收集和分析，并将这些数据进一步融入进它的Risk Engine中。
在今年4月份的Oktane'21上，Okta发布了新品Okta Risk Ecosystem。筑构、筑牢生态系统、深挖护城河，在risk management领域可以讲出非常多的故事，勾勒出无限美好的想象，它得到资本的青睐也就非常好理解了。
