IAM实践指南——OAuth 2.0下的API保卫战(第一部分)
介绍
目前,诸多应用程序通过开放授权框架(OAuth)来安全、可靠、高效地访问各种服务中的资源。InterSystems IRIS目前已兼容OAuth 2.0框架。事实上社区有一篇关于OAuth 2.0和InterSystems IRIS的精彩文章,链接如下。
然而,随着API管理工具的出现,一些组织开始将其用作单点身份验证,从而防止未经授权的请求到达下游服务,并将授权/身份验证复杂性从服务本身分离出来。
您可能知道,InterSystems已经推出了自己的API管理工具,即InterSystems API Management (IAM),以IRIS Enterprise license(IRIS Community版本不含此功能)的形式提供。这里是社区另一篇介绍InterSystems AIM的精华帖。
这是三篇系列文章中的第一篇,该系列文章将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。
第一部分将介绍OAuth 2.0相关背景,以及IRIS和IAM的初始定义和配置,以帮助读者理解确保服务安全的整个过程。
本系列文章的后续部分还将介绍两种使用IAM保护服务的可能的场景。在第一种场景中,IAM只验证传入请求中的访问令牌,如果验证成功,则将请求转发到后端。在第二种场景中,IAM将生成一个访问令牌(充当授权服务器)并对其进行验证。
因此,第二篇将详细讨论和展示场景1中的配置步骤,第三篇将讨论和演示场景2中的配置以及一些最终要考虑的因素。
如果您想试用IAM,请联系InterSystems销售代表。
OAuth 2.0背景
每个OAuth 2.0授权流程基本上都由4个部分组成:
- 用户
- 客户端
- 授权服务器
- 资源所有者
简单起见,本文使用“资源所有者密码凭证”OAuth流(可以在IAM中使用任何OAuth流)。另外,本文将不指定任何使用范围。
通常,资源所有者密码凭证流遵循以下步骤:
- 用户在客户端应用程序中输入凭证(如用户名和密码)
- 客户端应用程序将用户凭证和自身的标识(如客户端ID和客户端密钥)一起发送到授权服务器。授权服务器验证用户凭证和客户端标识,并返回访问令牌
- 客户端使用令牌访问资源服务器上的资源
- 资源服务器首先验证收到的访问令牌,然后再将信息返回给客户端
考虑到这种情况,你可以在两种场景下使用IAM应对OAuth 2.0:
- IAM充当验证器,验证客户端应用程序提供的访问令牌,仅在访问令牌有效时才将请求转发给资源服务器;在这种情况下,访问令牌将由第三方授权服务器生成
- IAM既充当授权服务器(向客户端提供访问令牌),又充当访问令牌验证器,在将请求重定向到资源服务器之前验证访问令牌。
IRIS和IAM初始定义和配置
本文中使用名为“/SampleService”的IRIS Web应用程序。从下面的截屏中可以看到,这是一个在IRIS中部署的未经身份验证的REST服务:
此外,在IAM端配置了一个名为“SampleIRISService”的服务,其包含一个路由,如以下截屏所示:
再者,在IAM中配置了一个名为“ClientApp”的客户端(初始没有任何凭据),用来识别谁在调用IAM中的API:
经上述配置,IAM将发送到以下URL的每个GET请求代理到IRIS:
此时还没有使用身份验证。所以,如果将一个简单的GET请求(未进行身份验证)发送到URL:
我们将获得期望的响应。
本文中,我们使用名为“PostMan”的应用程序发送请求并检查响应。在下面的PostMan截屏中,可以看到简单的GET请求及其响应。
请继续阅读本系列的第2篇,了解如何配置IAM来验证传入请求中的访问令牌。