如何用 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):RoleSession 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 登入,一小時就過期了,可以延長?

~在 IAM Role 的 Summary,找到 Maximum CLI/API session duration 調整即可,最大 12 小時。或者透過 AWS CLI 的 aws iam update-role --max-session-duration 更新,參閱 iam update-role~

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

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

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

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

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


結論

最後整理 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