SSO场景系列：实现Microsoft AD到阿里云的单点登录
【更新：隨著RAM 2.0的上線，阿里云官網提供了對SAML Federation的官方技術文檔，讀者可以參考：https://help.aliyun.com/document_detail/96239.html ，同時推薦用戶使用RAM控制臺進行配置，原企業控制臺（公測）將逐步下線】
在文章合規與安全：阿里云與企業身份系統的集成中，我們介紹了阿里云與企業身份系統的集成，可以配置云賬號下的子賬號通過企業身份系統登陸。配置要點是
其中第二點在不同的身份系統中有不同的配置方法。本文以Windows Server 2012 R2為例，介紹如何配置Microsoft AD作為阿里云的單點登錄IdP。
前置條件
本文假定用戶對Microsoft AD做了合理正確的配置，在Windows Server 2012 R2上配置了以下Server Role
- DNS服務器：DNS服務器用來將身份認證請求解析到正確的Federation Service上
- Active Directory域服務 (AD DS)：域服務提供對域用戶和域設備等對象的創建，查詢和修改等功能
- Active Directory Federation Service (AD FS)：Federation Service提供配置聯合身份認證依賴方的功能，并對配置好的依賴方提供單點登錄認證。
針對配置Active Directory的疑問，用戶可以參考微軟官方文檔或者搜索相關的第三方博客。
示例配置
示例中用到相關配置如下
在阿里云目錄中配置可信外部SAML IdP
在瀏覽器中輸入如下地址
https://adserver.testdomain.com/FederationMetadata/2007-06/FederationMetadata.xml將元數據XML文件下載存儲到本地，并按照合規與安全：阿里云與企業身份系統的集成中介紹的流程，將下載好的IdP元數據文檔配置到阿里云目錄中。
完成這一步之后，阿里云目錄則對示例中的AD FS產生了單向信任。如果用戶在阿里云子用戶登陸頁面輸入junpu.chen@junpu.onaliyun.com，阿里云則會向AD FS發出SAML認證請求，但是AD FS此時并不信任阿里云，因此AD FS會報出如下錯誤
在AD FS中配置阿里云為可信SP
在Microsoft的AD FS語境中，SAML SP被稱作Relying Party（依賴方，信賴方），這是因為AD FS支持OAuth/OIDC/WS-Federation，而這三個協議中的單點登錄消費方都被稱作Relying Party，因此AD FS在對SAML協議支持中并沒有采用SAML特有的術語Service Provider，而是統一采用Relying Party來指定不同協議中的單點登錄消費方。
創建阿里云作為AD FS的可信SP步驟如下
第一步：在服務器管理器中的工具菜單中打開AD FS管理
第二步：在AD FS管理工具中添加信賴方信任（Relying Party Trust）
第三步：為新創建的信賴方設置阿里云的SAML元數據
信賴方可以直接配置元數據的URL，或者將阿里云SAML元數據下載之后，為信賴方配置下載好的XML文件。阿里云SAML元數據的URL可以通過以下方式獲取：
完成配置信賴方之后，阿里云和AD FS就產生了互信，阿里云會將junpu.onaliyun.com目錄內的用戶認證請求轉發到AD FS adserver.testdomain.com上，AD FS也會接受來自于阿里云的認證請求并向阿里云轉發認證響應。
接下來需要對信賴方配置SAML斷言中需要頒發的屬性。
為阿里云SP配置SAML斷言屬性
為了讓阿里云能使用SAML響應定位到云目錄中的子用戶，我們需要SAML斷言中的NameID字段取值為云目錄中子用戶的UPN。
配置Active Directory中的UPN為SAML斷言中的NameID
在這里，微軟用了Claim（聲明）這一術語來指代SAML斷言中的屬性。這是因為AD FS支持的其他協議（OAuth，WS-Fed等）也都使用Claim來表達Token中的字段。
第一步：為信賴方編輯聲明規則
所謂聲明規則，指的是Claims Rule，也就是SAML斷言中的聲明（屬性）是怎樣從Active Directory的用戶屬性中生成的。
第二步：添加頒發轉換規則
所謂頒發轉換規則，指的是Issuance Transformation Rule，指的是如何將一個已知的用戶屬性，經過轉換之后，頒發為SAML斷言中的屬性。由于我們要將用戶在AD中的UPN頒發為NameID，因此需要添加一個新的規則
規則的模版為轉換傳入聲明
到這里，由于我們示例中的云賬號里的UPN域名為junpu.onaliyun.com，而AD中的UPN域名為testdomain.com，顯然如果直接將AD中的User Principal Name映射為NameID會讓阿里云無法匹配到正確的子賬號用戶。
我們提供兩個路徑來填補這一空白。
路徑一：在阿里云目錄中驗證AD域名
如果域名testdomain.com是一個在公網DNS中注冊的域名，那么用戶可以在阿里云目錄中驗證自己對域名的所有權。進入企業控制臺的人員目錄>域名設置>創建域別名。
驗證通過之后，阿里云目錄的默認域junpu.onaliyun.com則有了一個域別名testdomain.com。子用戶junpu.chen的UPN為junpu.chen@testdomain.com。
驗證域名之后的云目錄則可以在域名上與自建AD DS保持一致：云目錄子用戶的UPN與AD中用戶的UPN都使用testdomain.com這個域名。
完成這個設置后，我們回到上面的聲明轉換規則編輯中，將UPN映射為NameID（名稱ID）。
路徑二：將AD中的User Principal Name的域名轉換后頒發為NameID
如果域名testdomain.com是企業的內網域名，那么阿里云將無法驗證企業對域名的所有權。云目錄就只能采用onaliyun.com下的子域名。在這種情況下，在AD FS給阿里云頒發的SAML斷言中就必須將UPN的域名后綴從testdomain.com替換為junpu.onaliyun.com（假定用戶名一一對應）
最后
在筆者的示例中，自建ADtestdomain.com這一域名是內網域名，通過上述路徑二對斷言屬性進行映射之后，從自建AD的內網訪問阿里云，在子賬號登陸中輸入junpu.chen@junpu.onaliyun.com
阿里云將認證請求轉發給adserver.testdomain.com
輸入AD內的用戶名junpu.chen@testdomain.com和密碼之后，就完成了登陸回到阿里云控制臺
常見問題
由于企業自建AD配置上可能有所不同，因此可能需要編輯略有不同的聲明規則。但是最終的目標都是讓SAML響應中能夠返回阿里云目錄可以識別的子賬號UPN。
這里列出一些常見的問題
- 如果沒有配置聲明規則，導致SAML斷言中缺失NameID字段
- 如果SAML斷言中的NameID域名與云目錄并不一致
總結
以上是生活随笔為你收集整理的SSO场景系列：实现Microsoft AD到阿里云的单点登录的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 邓紫棋歌曲计算机音乐数字,邓紫棋播放量最
- 下一篇： 学习是一份苦差事