重庆分公司,新征程启航

为企业提供网站建设、域名注册、服务器等服务

AzureAD以及其的验证机制是怎样的

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

10年积累的网站建设、成都网站制作经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计后付款的网站建设流程,更有庄河免费网站建设让你可以放心的选择与我们合作。

什么是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以及其的验证机制是怎样的了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注创新互联行业资讯频道。


分享题目:AzureAD以及其的验证机制是怎样的
文章源于:http://cqcxhl.cn/article/pdhjio.html

其他资讯

在线咨询
服务热线
服务热线:028-86922220
TOP