亚马逊AWS官方博客
如何在 ADFS 与 AWS 之间建立信任,并通过 Active Directory 凭证配合 ODBC 驱动程序接入 Amazon Athena
Amazon Athena是一项无服务器交互式查询服务,旨在帮助用户通过标准SQL轻松分析存储在Amazon Simple Storage Service(Amazon S3)当中的原始数据与经过处理的数据集。Athena提供的JDBC与ODBC驱动程序还可帮助用户轻松将各类数据分析工具(包括微软Power BI、Tableau或者SQLWorkBench)与Athena无缝集成,在几分钟之内快速获取关于数据的分析洞见。
2018年11月之前,用户必须使用IAM用户或者角色凭证通过ODBC或者JDBC驱动程序接入Athena。但随着2018年11月20日Athena ODBC/JDBC驱动程序对于微软Active Directory Federation Services (ADFS 3.0)以及安全断言标记语言(SAML 2.0)的正式支持,现在大家已经可以使用微软Active Directory(AD)凭证直接接入Athena。
微软ADFS 3.0属于Windows Server中的一种组件,能够支持SAML 2.0并与AWS身份与验证管理(AWS Identity and Authentication Management ,简称IAM)相集成。以此为基础,Active Directory(AD)用户可以使用公司目录凭证(例如来自微软Active Directory的用户名与密码)与AWS实现联动。
本文将引导大家逐步在Windows Server 2012 R2 Amazon Elastic Compute Cloud(Amazon EC2)实例上配置ADFS 3.0,并通过SAML 2.0在ADFS 3.0 IdP与AWS之间建立信任。接下来,文章还将演示如何在Amazon Linux EC2实例(RHEL实例)上安装Athena ODBC驱动程序,并通过配置使其利用ADFS进行身份验证。
解决方案概述
下图所示,为在Athena ODBC/JDBC驱动程序当中对组织内AD用户进行身份验证的实施架构:
整个流程包含以下具体步骤:
- 组织中的用户将客户端应用程序与JDBC或ODBC驱动程序共同使用,以请求组织的IdP进行身份验证。这里使用的IdP为ADFS 3.0。
- IdP通过AD(组织内的身份存储机制)对用户进行身份验证。
- IdP使用用户相关信息构造SAML断言而后通过JDBC或ODBC驱动程序将该断言发送至客户端应用程序。
- JDBC或ODBC驱动程序调用AWS安全令牌服务AssumeRoleWithSAML API操作,并将其传递以下参数:
- SAML提供商的ARN
- 所采用角色的ARN
- 来自IdP的SAML断言
- 该API通过JDBC或ODBC驱动程序对客户端应用程序做出响应并提供临时安全凭证。
- 客户端应用程序使用临时安全凭证调用Athena API操作,如此一来,用户即可正常访问Athena API操作。
本文将指导大家通过SAML配置ADFS-AWS信任,并借此在Athena JDBC/ODBC驱动程序中实现受信AD用户联动。
在实现上述解决方案,我们需要完成以下操作步骤:
- 在Windows Server 2012 R2 Amazon EC2实例上配置ADFS(3.0)。
- 在AWS与ADFS(3.0)之间通过SAML 2.0规则设置信任。
- 在RHEL EC2实例上安装Athena ODBC驱动程序1.0.5,并通过配置引导其使用ADFS。
先决条件
要完成本次演练,大家需要满足以下先决条件:
- 了解Active Directory的概念。本文将不赘述在Windows实例上配置Active Directory的具体步骤。
- 了解IAM角色及相关概念。
- 了解如何在Active Directory服务器以及安装有Athena ODBC或JDBC驱动程序的实例之间建立DNS与网络。本文将在Windows Amazon EC2实例上安装Active Directory(运行ADFS),并在同一AWS VPC及子网中的另一个EC2实例上安装ODBC驱动程序。但结合实际用例需求,您可能需要在ADFS服务器与ODBC/JDBC实例之间提供连接。
在Windows Server 2012 R2 Amazon EC2实例上配置ADFS(3.0)
通过以下步骤,我们将在Windows Server 2012 R2 Amazon EC2实例上安装ADFS 3.0。根据先决条件部分的要求,我们已经在该Windows Server 2012 R2 Amazon EC2实例上安装有Active Directory,而且在本次演练中其域名为arunad.local
。关于在EC2实例上设置Active Directory域控制器的说明,请参阅微软TechNet网站上的在2012 R2上构建您的首个域控制器。
安装ADFS 3.0的先决条件
要在Windows域控制器上配置ADFS 3.0,我们需要满足以下先决条件:
- SSL证书——在本文的演练中,大家可以通过安装IIS(互联网信息服务器)创建自签名证书。
- 配置服务账户——使用Domain Admin组创建一个Active Directory用户。
- 在Windows Server 2012 R2 Amazon EC2实例上安装IIS。关于具体操作说明,请参阅The Solving网站上的如何在Windows Server 2012 R2上安装及配置IIS。在本文中,大家可以直接跳过上述说明中的步骤2部分。
- 在IIS安装完成后,创建一个自签名证书。关于具体操作说明,请参阅Sophos Community网站上的如何使用Windows Server创建自签名SSL证书。在本文中,大家可以直接跳过上述说明中关于绑定自签名证书的步骤。
要在域控制器中配置服务账户,大家首先需要在Active Directory中创建一个名称为ADFSSVC的用户,并将该用户添加到域管理员(Domain Admin)组当中。
- 打开Server Manager。
- 选择Tools。
- 选择Active Directory Users and Computers。
- 展开您的域 (
arunad.local
)。 - 选择 User (右击)。
- 选择New。
- 选择 User。
- 创建一个用户,名称为
ADFSSVC
。 - 将密码设置为永不过期。
现在,大家可以将用户ADFSSVC
添加至域管理员组当中了。
这时我们会收到一条消息,通知该用户已被添加至该组,但仍需进行验证。
安装与配置ADFS 3.0
现在,我们已经为ADFS 3.0的安装做好了充分准备,接下来即可在Windows Server 2012 R2 EC2实例上安装并配置ADFS 3.0了。
- 打开Server Manager。
- 选择Roles and Features。
- 选定 Role-based or feature-based installation。
- 连续点击Next 直至看到Select server roles。
- 在Roles当中选择Active Directory Federation Services。
- 连续点击 Next直至看到 Confirmation installation selections。
- 选择 Install。
- 选择Configure the Federation Service for this server。
- 选择Create the first federation server in a federation server farm。
- 选择 Next。
- 连续点击Next 直至看到 Specify Service Properties。
- 在SSL Certificate当中,选择您之前安装完成的自签名证书。
- 在Federation Service Display Name部分,输入
ArunADFS
。 - 选择Next。
- 在Specify Service Account页面中,选择Use an existing domain user account or group Managed Service Account。
- 选择Select。
- 在文本框中,输入
ADFSSVC
。 - 选择Check names。
- 在名称填充完成后,选择OK。
- 输入您的密码并选择 Next。
- 选择Create a database on this server using Windows Internal Database。
- 选择Next。
- 连续点击Next直至看到 Pre-requisite Checks。
- 选择Configure。
在服务器成功配置之后,您可能会看到以下警告信息:
An error occurred during an attempt to set the SPN for the specified service account. Set the SPN for the service account manually. For more information about setting the SPN of the service account manually, see the AD FS Deployment Guide. Error message: The SPN required for this Federation Service is already set on another Active Directory account. Choose a different Federation Service name and try again.
(尝试为指定的用户账户设置SPN时发生错误。请手动设置服务账户的SPN。关于手动设置服务账户SPN的更多详细信息,请参阅《AD FS部署指南》。错误信息:此联动身份验证服务所需的SPN已被设置在另一Active Directory账户上。请选择其他联动身份验证服务名称,而后重试。)
要解决这个问题,请以管理员身份打开PowerShell并运行以下命令:
setspn -a host/localhost adfssvc
以下代码为输出结果。
到这里,ADFS 3.0的配置工作即告完成。
- 要下载ADFS服务器的联动身份验证XML文件,请在Windows Server上打开浏览器,而后输入以下地址:
https://<yourservername>/FederationMetadata/2007-06/FederationMetadata.xml
。
此文件将被用于在ADFS与AWS之间建立信任。
另外,大家也可以在PowerShell 3.0+中以管理员身份运行以下命令来下载ADFS服务器的联动身份验证XML文件:
wget https://<your-server-name>/FederationMetadata/2007-06/FederationMetadata.xml -OutFile FederationMetadata.xml
您可以通过点击Start button(Windows图标)>右键单击My Computer>单击Properties>查看Full Computer Name的方式获取服务器名称。
将下载完成的XML文件复制到本地计算机上,我们下一步在IAM中创建基于SAML的角色时将要用到。
通过SAML 2.0在Windows AD (使用ADFS IDP)与AWS之间建立信任
现在,我们已经在Windows Server上配置了ADFS 3.0,现在可以通过SAML断言声明规则在AWS与IdP(ADFS)之间建立信任了。通过建立信任,AD中的用户即可使用IAM角色实现与AWS的联动,进而访问Athena或者AWS Glue数据目录等AWS资源。
要建立此信任,我们需要在AWS与Active Directory当中完成配置。在AWS方面,我们可以设置IAM角色并建立SAML提供程序。在Active Directory这边,我们需要编写SAML断言与声明规则。
在IAM中设置您的SAML提供程序
要设置SAML提供程序,我们需要完成以下操作步骤:
- 在IAM控制台上,选择Identity provider。
- 选择Create provider。
- 在Provider Type部分,选择SAML。
- 在Provider Name部分,输入
MytestADFS
。 - 在Metadata Document部分,选择我们之前下载完成的XML文件。
- 在IAM中创建一个新角色,并将受信实体选定为 SAML 2.0 federation。
- 在SAML provider部分,输入我们之前创建完成的提供程序(MytestADFS)。
- 在Attribute部分,选择SAML:aud。
- 向该角色添加必要的IAM权限,而后创建IAM角色。
在本文中,我们将添加AthenaFullAccess托管策略并将角色命名为ArunADFSTest
。
我们在这一步中指定的角色名称非常重要,因为在后续建立信任的各个步骤中,我们在Active Directory中创建的一切用户和组都将以该名称为基础。
在ADFS 3.0 IdP中配置SAML断言规则
在此步骤中,我们将在ADFS中配置SAML断言规则,以便用户使用我们创建的IAM角色与AWS进行联动。
首先,我们需要确定如何在AWS中创建并划分AD组以及IAM角色,这里的划分方式也将对后续账户访问以及资源管理产生深远的影响。这里我们一般会按照通行的命名约定创建AD组,并将其与IAM角色映射匹配起来。
在本文中,我们将在Active Directory中使用AWS-<AccountID>-<IAMRolename>
的命名方式;例如AWS-123456789012-ArunADFSTest
。
这种命名约定也将在后续步骤中发挥重要作用。这是因为我们编写的SAML断言声明规则所提取的全部AD用户与AD组当中,都将包含字符串AWS-<AccountID>-
,且每次提取都将涉及组名称中的最后一部分以保证与AWS中的IAM角色映射起来。例如,如果大家要面向AWS进行身份验证的AD用户属于AD组AWS-123456789012-ArunADFSTest
中的成员,那么我们后续编写的声明规则将查找所有与字符串AWS-123456789012-
相匹配的AD用户,提取组名称中的最后一部分(ArunADFSTest
),并将其以aws:arn::iam::<AccountID>: role/ArunADFSTest
的格式作为角色名称发送至AWS SAML端口。
以下截屏所示,为使用AWS-123456789012-ArunADFSTest
名称创建的AD组:
- 在使用名称完成
AWS-123456789012-ArunADFSTest
组创建之后,即可在该组中创建一个新用户。在本文中,用户名称为myldapuser1
。 - 确保用户在E-mail字段中填写符合正常语法要求的电子邮件地址,在构造SAML令牌时,此电子邮件字段将作为
RolesessionName
被传递至AWS。 - 在用户创建完成之后,将该用户添加至AD组
AWS-123456789012-ArunADFSTest
当中。
现在我们已经创建了AD组、AD用户与IAM角色,接下来就是在ADFS当中创建依赖方信任并编写声明规则。ADFS IdP需要在SAML断言中构造以下值,并将这些值发送至AWS进行身份验证:
-
NameID
RoleSessionName
Roles
(其中包含我们在AWS中的SAML IdP以及角色名称)
关于在ADFS当中设置依赖信任以及声明规则的更多说明,请参阅配合Active Directory联动服务(AD FS)实现AWS联动身份验证。结合本次演练中,大家可以直接参考文中的“Active Directory联动服务配置”部分。
在配置完成之后,我们的声明规则应该如以下截屏所示。
以下截屏所示,为NameID
规则。
以下截屏所示,为RoleSessionName
规则。
以下截屏所示,为Get AD Groups
规则。
以下截屏所示,为Roles规则。IAM中的SAML提供程序使用MyTestADFS (arn arn:aws:iam::123456789012:saml-provider/MytestADFS
)名称创建而成,因此我们需要在声明脚本当中使用相同的值(MyTestADFS
)。如果您使用的是其他名称,请使用IdP ARN名称进行替换。
在四项规则创建完成之后,ADFS依赖信任设置即告完成。
验证您的IdP
要验证当前IdP是否设置成功,请完成以下操作步骤:
- 在ADFS服务器Windows实例(使用您自己的Windows Server主机名称)上的浏览器中导航至以下URL:
https://<windows-hostname>/adfs/ls/IdpInitiatedSignOn.aspx
。 - 选择您的ADFS显示名称 (My Amazon Portal)。
- 输入您之前为用户
myldapuser1
创建的AD凭证。
本次演练中使用的域名为arunad.local
,因此大家需要将用户名称指定为ARUNAD\myldapuser1
,或者将其指定为myldapuser1@arunad.local
。
如果一切顺利,现在大家应该能够登录至AWS管理控制台了。
如果遇到任何错误,请参考之前的步骤。关于SAML常见错误的更多详细信息,请参阅对AWS上的SAML 2.0联动机制进行故障排查。关于故障排查的更多详细信息,请参阅如何在浏览器中查看SAML响应以实现故障排查。
在初始化指向ADFS服务器的连接时,Athena ODBC/JDBC驱动程序也会使用同样的联动URL(https://<windows-hostname>/adfs/ls/IdpInitiatedSignOn.aspx
)检索SAML断言AWS属性。
在Amazon EC2 Linux实例上安装Athena ODBC驱动程序1.0.5,并通过配置引导其使用ADFS
现在,我们已经完成了ADFS 3.0配置并建立起与AWS间的信任,最后一步是配置Athena ODBC驱动程序并使用ADFS作为其身份验证机制。
如先决条件部分所提到,我们已经在同一VPC及子网当中启动了Active Directory Windows EC2实例以及Athena ODBC驱动程序Linux(RHEL)EC2实例,并在两个实例之间建立起通信通道。但在这套环境中,我们还需要保证ADFS服务器能够与安装有Athena JDBC/ODBC的计算机进行通信。
在本文中,请将VPC(即启动Linux EC2所使用的VPC)中DHCP选项集内的域名服务器修改为172.31.X.X, AmazonProvidedDNS
,其中172.31.X.X
代表EC2 Windows实例的IP地址,安装在其上的ADFS则使用arunad.local
域名进行配置。
在EC2实例上设置环境
要完成环境设置,请完成以下操作步骤:
- 配合支持Red Hat Enterprise发行版的AMI启动一个Linux EC2实例 (例如,AMI 为
RHEL-7.6_HVM_GA-20181017-x86_64-0-Hourly2-GP2
)。 - 使用SSH接入实例并输入以下命令:
- 使用您选定的网络工具验证ADFS服务器与RHEL EC2实例之间的连接是否正常。
- 安装
open-ldap
客户端,并测试我们能否通过此Linux实例搜索到AD组中的用户(请将具体值替换为您的用户与域名):
如果命令运行成功,则代表RHEL EC2实例可以与AD服务器通信并检索凭证。
安装并配置UnixODBC Driver Manager 2.3.4
Athena ODBC驱动程序的Linux版本要求我们安装以下ODBC驱动程序管理器,而后方可建立连接:
- iODBC 3.52.9, 3.52.10, 3.52.11, or 3.52.12
- unixODBC 2.3.2,2.3.3, or 2.3.4
- 在您的RHEL EC2实例实例上安装UnixODBC driver manager 2.3.4。关于具体操作说明,请参阅Beyond Linux From Scratch网站上的unixODBC-2.3.4部分。
在EC2实例上安装这款驱动程序管理器的命令,应如下所示:
- 切换至root用户以安装ODBC Driver Manager,详见以下代码:
- 在ODBC Driver Manager安装完成之后,请确保以下文件正确存在。这些文件证明我们已经在RHEL EC2实例上成功安装了ODBC Driver Manager:
-
/etc/unixODBC/odbcinst.ini
/etc/unixODBC/odbc.ini
- ODBC Driver Manager库文件将被创建在路径
/usr/lib
当中。请通过以下命令(使用非root用户)设定共享库路径以指向您的ODBC Driver Manager库:export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
- 通过输入代码
odbcinst -j
验证ODBC Driver Manager环境配置是否正确加载完成。
安装并配置Simba Athena ODBC Driver Manager (64位)
现在,ODBC Driver Manager已经配置完成,最后一步是在Linux实例上安装Athena ODBC驱动程序1.0.5,并通过配置引导其使用ADFS作为身份验证机制。
- 要在EC2实例上安装Athena ODBC Driver,请输入以下代码:
下载完成的示例ODBC配置文件位于/opt/simba/athenaodbc/Setup/odbc.ini
路径之下。
- 要配置ODBC驱动程序以使用ADFS作为身份验证机制,请使用
ec2-user
登录并输入以下代码:vim .odbc.ini
- 输入以下配置指令:
替换IdP_Host
与IdP_Port
的值以指向您的ADFS服务器。在本文中,对应的值分别为win-qikm653mpj9.arunad.local
与443
。同样的,使用我们之前创建的LDAP用户名与密码替换UID
与PWD
。本文使用的是ARUNAD\myldapuser1
。另外,根据当前环境替换AwsRegion
与S3OutputLocation
的值。对于生产工作负载,请确保将SSL_Insecure
设定为false以保证驱动程序能够验证服务器证书。
我们可以通过在Windows AD服务器实例的PowerShell上输入以下代码,来检索ADFS服务器的HTTPS端口号:
Get-AdfsProperties
- 要在Athena ODBC驱动程序上启用DEBUG级日志记录,请编辑
/opt/simba/athenaodbc/lib/64/simba.athenaodbc.ini
文件并设置以下值: - 现在,Athena ODBC驱动程序已经配置完成,接下来使用以下代码进行测试:
isql -v "Simba Athena 64-bit"
在以上代码中,Simba Athena 64-bit
代表的是接入至ODBC驱动程序时我们在/home/ec2-user/.odbc.ini
当中指定的DSN名称。
如果连接正常,则意味着我们已经通过对用户进行ADFS身份验证成功接入Athena ODBC Driver Manager。
大家也可以检查连接日志,验证驱动程序所使用的连接URI以及ADFS返回给Athena ODBC驱动程序的值。
连接日志代码段中的对应条目如下所示:
总结
本文展示了如何在Active Directory当中配置ADFS 3.0,并将其作为IdP以使用SAML实现与AWS的身份验证联动。本文还探讨了如何将Athena ODBC驱动程序集成至ADFS,以及如何直接使用Active Directory凭证接入Athena。通过将Active Directory与Athena ODBC驱动程序集成起来,我们可以更灵活地通过各类熟悉的商务智能工具访问Athena,使用SQL分析Amazon S3中的数据且完全无需创建单独的IAM用户。
如果您的组织已经通过OKTA提供指向AWS的单点登录(SSO)机制,大家也可以使用Athena JDBC驱动程序的最新版本(2.0.9)将OKTA指定为身份验证机制。关于更多详细信息,请参阅在Athena JDBC中使用OKTA。
如果大家还有任何疑问或者建议,也请在评论区中留下您的反馈。