Azure AD以及其的验证机制是怎样的

这期内容当中小编将会给大家带来有关Azure AD以及其的验证机制是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

什么是Azure AD？ 

Azure AD（简称AAD）是在云端提供验证与授权的服务，随着功能日趋完善，提供的功能也越来越丰富。通过使用AAD，IT以及应用程序开发人员可以把验证和授权全权交给AAD来管理，同时也可以轻而易举得实现跨平台的认证，以及实现单点登录的场景。

但是有一点必须澄清，Azure AD与我们熟悉的企业的AD是完全不同的，前者是云服务，只管验证与授权, AAD更像是传统AD像云端的扩展，用以满足更多的是用场景与验证需求。

Windows Azure AD (独立模式或联邦模式)支持不同的验证和授权场景：
1.Web 应用程序、设备应用、后台进程/服务访问一组 Web 服务
2.Web 应用程序、Web 服务、设备应用、后台进程/服务需要对用户进行验证 和授权用户

Azure AD的验证机制

Azure AD是Claim Based的验证与授权，所以在理解Azure AD的验证机制前，我们有必要理解几个Claim Based Identity的重要概念。

1. Identity

Identity是我们经常会提到的一个词，主要涉及于授权与验证相关的内容。但是简单从开发人员的角度来看，Identity其实就是从安全角度出发，能够描述一个用户或者对象一系列属性，如名字，邮件地址，电话，部门等。

2. Claim(声明)

直观的看，Claim就是Identity的一个子集。Claim包含的属性越多，应用程序拿到这个Claim的时候也就越了解这个用户。为什么要叫Claim，这个主要是从应用程序处理它角度来看的。当一个应用程序收到一个Claim，他是不会去活动目录去验证这个Claim的内容是否属实，他只会从Claim里找一个叫做颁发者的属性，只要颁发者是应用程序信任的，那么应用程序就自动信任这个Claim。

3. Security Token (安全令牌)

在传递一系列Claim的时候，在Web Service里，Claim是放在SOAP的包头里的，在浏览器的Web应用里，Claim是放在HTTP POST里的，然后再cache在cookie中。但是不管哪一种方式，这些Claim必须以序列化的方式传递过来并存放。

Security Token就是指序列化过的经过颁发机构数字签名过的一系列Claim。这个数字签名很重要，这保证了Security Token不会被伪装。

4. Security Token Service(STS)

STS是付则创建、签名和颁发Security Token的服务。比较常见就是微软的ADFS，目前最新版本是Server 2012 R2里的ADFS3.0。

5. Relying Party(RP)

当你创建一个依赖于Claim方式进行验证的应用程序，这个应用程序就称作RP。比较通俗的叫法可以是Claims aware app或者claim-based app。

基本的验证流程

一个客户端,要访问一个Web Service（RP），它会首先1. 访问时获取基本的Policy，如需要哪些Claim，需要到哪一个STS获取， 2. 然后客户端会到STS获取它的Claim，STS会让客户端提供验证自己的基本信息（如用户名密码），验证后，STS会返回给客户端包含它所需要的所有Claim的Security Token。 3. 然后客户端就会把它的Security Token放在他之后所有的SOAP请求里一起提交给Web Service（RP）。 RP只要看到请求里有信任的STS签名过的Token，就放行，如果没有，就直接Deny掉。

如果客户端是一个Browser，请求的是一个Web网站（RP）的场景下，它从STS拿回来的Security Token则会Cache到本地的Cookie中，这样就能实现SSO，多个Web的RP都可以收到Cache在Cookie中的Token。

注：获取的Token都是有有效期的，这个有效期都是在STS里设置的，有效期过期后必须重新去STS获取Token。

联合身份验证

Claim Based 验证的另一大优势就是可以实现联合身份认证。

举一个例子，Fabrikam是一家很大的生产自行车的公司，它有自己的进销存系统网站，可以给所有的加盟店访问。Bob是一个加盟店的老板，为了能让Bob能访问系统，传统情况下，Fabrikam会给Bob创建一个他们的账号，然后按照Bob的加盟店店长角色，给他对应的权限。如果Bob生意越走越大，员工越来越多，每一个员工都要使用Fabrikam的系统，那么Bob就必须让Fabrikam给他创建不同的账号来访问系统。

那么，如果有Bob有员工要转换角色，或者要离职，这些都是要Bob告诉Fabrikam，然后来回收账号或者修改账号权限。这明显非常麻烦，而且用户需要有多个账号，BOB公司的一个账号，Fabrikam系统的一个账号，如果Bob还买其他公司的产品，账号可能就更多了，如果员工角色有改动或者离职了，光回收账号和修改信息，就有得头疼的了。

所以，我们要让Bob的工作自动化，Bob和Fabrikam之间有一个信任关系，也就是Fabrikam信任Bob告诉他的信息。Bob说这个是他的员工，有哪些属性，Fabrikam就会相信他提供的信息，不需要额外再给他分配Fabrikam的账号了，这就是联合身份认证的基础。

Fabrikam的应用就是一个RP，Fabrikam有自己的STS，RP是基于这个STS。此时BoB的公司也提供自己的STS服务，这两个公司之间有信任关系。Bob新入职的一个员工Alice要使用Fabrikam的应用系统，她会1.首先在Bob的STS上验证并拿到Token，2. 然后会把Token发送给Fabrikam的STS，Fabrikam的STS看到了由它信任的Bob颁发的Token，拿到里面的Claims，重新颁发给Alice第二个由Fabrikam签名的Token。3.此时Alice拿着第二个Token发给系统网站（RP），RP只需要看到有Fabrikam签名的Token，就可以放行了。

所以在这里作为应用程序，不需要有任何权限上的修改，也不需要关心验证用户，只需要看到是Fabrikam颁发的Token即可。这个应用程序和用户来讲，都是非常高效的。

Azure AD 的验证

上面讲了这么多，我们来看一下Azure AD具体是如何操作的。Azure AD的验证分为两种场景，一种是启用了单点登录模式的，另一种是仅目录同步模式。下图，Fabrikam利用Azure AD，启用了单点登录模式，而Bob的公司利用Azure AD仅启用目录同步，但是他们都使用同一个Azure AD进行验证与授权，同时他们都要访问对应的应用(RP)。

Fabrikam首先在Azure上创建了Azure AD，Fabrikam设定好了单点登录模式，在自己企业环境内有STS服务，Fabrikam也将Bob的域加入到Azure AD中，但启用的是目录同步模式，Bob自己企业内无STS服务。

Fabrikam的用户使用客户端访问RP的流程：

1.客户端首先访问RP，获得Policy，包括STS服务器，需要的Claim信息

2.客户端被重定向到Azure AD进行验证，单用户提供用户名后，Azure AD自动检测域为单点登录模式，需要联合认证

3.客户端被重定向到企业的STS，STS验证身份后，颁发Token给客户端

4. 客户端被自动重定向回到Azure AD，Azure AD检验企业STS颁发的Token通过后，再颁发第二个由Azure AD颁发的有时效（TTL）的Token

注： Azure AD在这里还可以启用多因素验证，也就是通过手机或短信再验证一次用户，然后再颁发证书。这可以让Azure AD保护更重要的应用。

5. 客户端拿着Token在Token有效期内可以正常访问RP了。所以RP真正信任的仅仅是Azure AD颁发的Token。

Bob的用户使用客户端访问RP的流程：

1. 客户端首先访问RP，获得Policy，包括STS服务器，需要的Claim信息

2. 客户端被重定向到Azure AD进行验证，单用户提供用户名后，Azure AD自动检测域为目录同步模式，由于已经将用户名以及密码哈希，以及各种用户属性同步到Azure AD中，Azure AD直接验证通过后，颁发Token。

3. 客户端拿着Token访问RP。

由于RP都是只信任Azure AD颁发的Token，所以不管是Fabrikam还是Bob的用户，RP都是通过的。因此只要把不同的目录集成到Azure AD中，就可以实现跨域、跨组织的身份验证和同步，从用户角度，只需要一个用户名和密码，从开发人员角度，只需要使用Azure AD进行验证和授权即可，而不会因为组织或用户更改而修改代码。从IT角度，身份和权限管理，会变得直观和简单，如权限回收，在上图中，如果要移除一个用户的权限，只需要在Azure AD中操作，那么就能收回该用户对所有的基于Azure AD的RP的访问权限。

上述就是小编为大家分享的Azure AD以及其的验证机制是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。