如何用 G Guite 整合 AWS Single Sign-On

整理如何設定 AWS SSO 的流程，主要參考： How to Set Up Federated Single Sign-On to AWS Using Google Apps 這篇文章，用 SAML 2.0 (Security Assertion Markup Language) 協議做使用者的 認證管理 (Authentication)，並且延伸管理上實際遇到的問題。

需求背景

  • 集中 Authenticaion，使用單一來源
    • Authoriziation 則是使用 AWS IAM Policy
  • 多個 AWS 帳號 (十多個) 在使用，拆分主要是跟帳務有關係
  • 使用人員，有多個身份，通常是因為必須參與多個專案
  • 要減少 IAM User 帳號的發放，避免人員異動時疏漏
    • 簡化權限發放流程
  • 需要滿足 AWS Console and Programmatic User 的需求
    • 部分需要 IAM Credential 的應用程式，還是使用既定流程

前提與主要流程

設定之前，先要有以下的條件：

  • 有 G Guite Admin 的權限
    • 準備幾個可使用帳號 (非群組)，像是 rick@abc.com, jack@abc.com
    • 這些帳號模擬不同角色，像是團隊、Tech leader、Read Only … etc.
  • 有 AWS IAM Admin 的權限

設定步驟

主要的設定步驟大約如下：

  1. 在 G Suite Admin Console 取得 IdP metadata 與 customer ID
  2. 在 AWS IAM 新增 Identity Providers
  3. 在 AWS 建立登入的角色 Role 與權限
  4. 在 G Suite 設定 user profile
  5. 在 G Suite 設定 SAML app

SMAL 相關名詞

  • IdP: Identity Provider, 身分提供者
  • SP: Service Provider, 即服務提供者

一、取得 IdP metadata

  • 使用 Admin 權限身份，登入 admin.google.com
  • 安全性 -> 設定單一登入 (SSO)
    • 下載 IdP Meta，這是個 XML 檔，保存好。

  1. 紀錄 idpid (截圖中紅色消掉部分) 後面會使用
  2. 注意這張憑證的時效性，可以先 renew 一張取的最長的時效性

二、在 AWS IAM 新增 Identity Providers

  • 使用有 Admin 權限的使用者登入 AWS Console
  • 到 IAM -> Identity providers -> Create Provider
    • Provider Type 選 SAML
    • Provider Name: 輸入一個可以識別的名稱
      • 建議以 DNS 名稱命名，多個 Provider 時容易識別
      • 這個名稱會當作 ARN 名稱，不能有空白、特殊字元
    • 選擇 Metadata Document，上傳上個步驟的下載的 IdP Meta

如下圖：

完成此動作後，記錄 Provider ARN，後面會使用。

三、在 AWS 建立登入的角色 Role 與權限

與以往不一樣的是 trusted entity 類型的選擇，本文的主角是：SAML 2.0 federation。

另外要注意的是 Role Naming，名稱是以使用者面向命名，以便未來使用者方便知道現在在哪個 AWS Account。下圖中的範例，我的命名規則是這樣：

SSO-{AWS_ACCOUNT_NAME}-{ROLE_NAME}

  • 以 SSO- 做命名的前置詞，識別是哪一種登入方式。其他像是跨帳號 (Cross Account) 則使用 CA- 開頭
  • AWS_ACCOUNT_NAME: 每個 AWS Account 我都會取一個唯一的是別名字，例如 Abc-Dev, Abc-QA, Abc-QA，下圖的範例是 GTCafe-Dev
  • ROLE_NAME: 最後則是實際的角色名稱

完成此動作後，記錄 Role ARN，後面會使用。

四、在 G Suite Admin 設定 Custom Schema for User profile

這個步驟是為了對 G Suite 的使用者目錄服務 (Directory API, 類似微軟的 AD) 增加額外的使用者屬性，稱為 Custom Schema。這個步驟主要是用 Google Admin API 執行，步驟如下：

建立 schema，點 Schema:Insert 開啟 Google Admin API。在畫面右邊的 Try this API 填入以下參數：

  • customerId: 填入第一步取得的 idpid
  • Request Body 填入以下範例。
    • schemaName 是參考名稱，後面會使用。建議標記上時間以及用途，以便未來識別。
    • displayName 是 field 的顯示名稱，沒填後面步驟會選不到。
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      {
        "displayName": "SSO for AWS v2019/08/19",
        "schemaName": "SSO-AWS-20190819",
        "fields": [
          {
            "fieldName": "role",
            "fieldType": "STRING",
            "readAccessType": "ADMINS_AND_SELF",
            "multiValued": true,
            "displayName": "Role"
          },
          {
            "fieldName": "SessionDuration",
            "fieldType": "INT64",
            "readAccessType": "ADMINS_AND_SELF",
            "multiValued": false,
            "displayName": "Session Duration"
          }
        ]
      }

這個動作增加了兩個字定義的欄位 (Field)：Role、Session Duration

  • Role：用來關聯 AWS IAM Role / Id Provider 的欄位，允許多個。
  • Session Duration：用來定義 SSO 登入後的 Session Duration，單位是秒，預設只有一個小時，最大 12 小時。

五、在 G Suite 設定 SAML app

用 Admin 帳號到 G Guite Admin Console，到 應用程式 -> SMAL App，新增 APP 選擇 Amazon Web Services，大部分步驟都是先是預設值即可，如下：


步驟五的 Attribute Mapping 設定如下：

  • Mapping 1: Basic Information -> Primary Email
  • Mapping 2: SSO for AWS v2019/08/19 -> Role
    • 這是在前面步驟四在 Google Admin API 所增加的 schema 名稱
  • Mapping 3:

完成後，開放讓所有人可以存取此 APP。

六、使用者與 AWS Role 的綁定

接下來就是設定 G Suite 使用者與 AWS Role 的認證關聯，設定介面有兩種：

  • G Suite Admin Console
  • Google Admin API

G Suite Admin Console

在 G Suite Admin Console -> Directory -> Users 畫面，點選右上角的 More -> Manage custom attributes，如下圖：

畫面最下面 Custom attributes 應該會出現步驟四建立的 Schema：SSO for AWS v2019/08/19，確認 Custom Fields 是否正確，如下圖：

步驟四的動作，也可以從這個界面修改。

確認有自定義屬性後，回到使用者清單，隨意找一個使用者 -> User Information -> 找到 SchameName，如下圖：

上圖中 Role 格式如下：

  • 格式：<IAM_ROLE_ARN>,<PROVIDER_ARN>
  • 範例：arn:aws:iam::123456789012:role/SSO-Admin,arn:aws:iam::123456789012:saml-provider/GSuite_ABC

這兩個格式就是在定義 哪一個 AWS Account 裡的 IdP，關聯到哪一個 IAM Role 裡，可以填多個，讓同一個人可以同時擁有多個身份。

不過如果要大量設定很多人，Admin Console 就很不方便了，所以下一個介紹用 API 來管理關聯。

Google Admin API

除了在 G Suite Admin Console 點選，另外對系統管理人員，比較實用的應該是透過 API，可以大量、快速的綁定使用者關聯，步驟如下。

點 Users:Patch 開啟 Google Admin API。

  • userKey: 填入 G Guite 上的使用者帳號，像是 rick@abc.com
  • Request Body: 這裡會關聯到前步驟建立的 schema，同時關聯使用者對應到 AWS 哪一個 SSO Provider 與 IAM Role，基本的格式如下：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    {
      "customSchemas": {
        "SSO-AWS-20190819": {
          "role": [
            {
              "value": "<IAM_ROLE_ARN>,<PROVIDER_ARN>",
              "customType": "work"
            }
          ],
          "SessionDuration": "<SessionDurationBySec>"
        }
      }
    }

注意：

  • SchemaName 要填步驟一個名字，範例是 SSO-AWS-20190819
  • 兩個欄位 role, SessionDuration 注意大小寫，是步驟一宣告的 fieldName

實際上，一個人可能會需要登入多個 AWS 帳號，然後有多個身份（團隊、部門）等，底下的範例是有兩個 AWS 帳號，然後有三種角色：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "customSchemas": {
    "SSO-AWS-20190819": {
      "role": [
        {
          "value": "arn:aws:iam::123456789012:role/SSO-Admin,arn:aws:iam::123456789012:saml-provider/GSuite_ABC",
          "customType": "work"
        },
        {
          "value": "arn:aws:iam::012123456789:role/SSO-Admin,arn:aws:iam::012123456789:saml-provider/GSuite_ABC",
          "customType": "work"
        },
        {
          "value": "arn:aws:iam::123456789012:role/SSO-EC2-ReadOnly,arn:aws:iam::123456789012:saml-provider/GSuite_ABC",
          "customType": "work"
        }
      ],
      "SessionDuration": "43200"
    }
  }
}

實際的管理流程，主要 Authentication 就是控制一段，另外 Authorization 則是在 IAM Policy 控制。

七、使用 SSO 登入 AWS Console

開啟 Chrome ，確認已經是登入的狀態，可以從右上角的使用者狀態，或者上面中間的選單 People 登入，確認登入後，開啟空白選單 (Ctrl + Tab)，會看到右上角的 G Guite App 選項，如下圖：

登入後，如果是有多帳號、多角色，那麼會看到類似底下的選項：

Debug 筆記

設定過程，如果要 Debug，或者有些 Payload 不知道要填什麼，可以透過 Google Admin API 取得相關資訊。

例如一開始我不知道 CustomSchema 裡的 Custom Fields 設定後，使用 User.Patch 不知道要塞怎樣的資料結構，官方文件也沒詳細說明細節，所以在 Admin Console 設定後，反過去 Admin API 用 User.Get 取得完整的 Payload。SessionDuration 就是這樣反推出來的。

另外是設定過程，需要有 G Suite 最大權限 SuperAdmin，不然 SSO / SAML 都會看不到資訊。

問答

Q: 使用 G Suite 登入 AWS，那麼需要先有 AWS IAM User？

不需要，只要有 G Suite 上的帳號，以及 AWS IAM Role 即可

Q: 可以用 Browser 同時登入多個身份嗎？

不可以，如果要同時使用多個身份同時登入，只能用不同的瀏覽器，然後都登入 google 之後才能可以直接登入。

Q: IAM Programmitc User 可以使用此方法？

目前我沒找到方法，所以還是需要開 IAM 帳號。

Q: Federated SSO 與 Cross Account Role 的做法比較，哪個好？

Cross Account Role (Switch Role) 好處是可以在同一個 Browser 快速切換帳號，動作是直接點選右上角的歷史選項。缺點：

  • AWS Console 只會記住五個 Role，Federated SSO 沒此問題。
  • 如果 Role Name 有調整，那麼 Admin 要通知很多人去修改，Federated SSO 沒此問題，使用者只要看得懂就可以了。

Federated SSO 也有缺點：切換帳號的動作比較多。

Q: 透過 Federated SSO 登入，一小時就過期了，可以延長？


Updated 2019/08/20: 上述方法實際驗證過後不行，一定要透過 SAML 定義的 SessionDuration 這個 Attribute 才可以。注意時間最大只有 12 小時。

Q: 針對 Programmatic User 的部分的做法是？

目前尚沒找到適當的做法。

Q: 管理 Authentication 的部分，需要一定的 G Suite 權限？

在 G Suite -> Admin Roles -> User Management Admin 指定人員即可。

Q: 登入時出現 Response signature invalid 的處理方式？ (Updated 2022/10/29)

最近登入出現這樣的訊息：Error: Response signature invalid (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)，後來查了官方文件 Troubleshooting SAML 2.0 federation with AWS，只要去 G Suite 重新下載 SMAL Meta，在 IAM IdP 重新上傳即可。

結論

最後整理 Federated SSO 與 Cross Account Role 的比較表：

項目 Switch Role Federated SSO
登入 從統一帳號 IAM 登入, MFA，較麻煩 登入 Google，直接使用
切換 Role 較直接, 但只有五個 動作多, 可以多個
認證管理：離職 關閉 IAM 權限 G Suite 統一管理
認證管理：增加 建立 IAM 帳號 G Suite 統一管理
— —- ——–

Federated SSO 的重點在於 認證管理 (Authentication) 都可以擺在 G Suite 統一管理，人員的離職與異動都可以一次性的回收權限，不會造成資安漏洞。但是 授權 (Authorization) 還是在應用程式本身，也就是 AWS 的 IAM Role 要自行透過 Policy 管控。

延伸閱讀

站內資料

參考資料

更新紀錄

  • 2019/05/30: 初稿
  • 2019/08/20: 更新設定流程，增加 SessionDuration 設定說明

Comments

2019/05/30 13:30:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲