Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the ultimate-addons-for-gutenberg domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /opt/bitnami/wordpress/wp-includes/functions.php on line 6114
AWS – Identity Center – 分配組織帳戶與 Single Sign On - 八寶周的研究小屋

AWS – Identity Center – 分配組織帳戶與 Single Sign On

0. 前言


在組織間需要確保其應用程式和資源的訪問既簡便又安全。為解決過往 IAM 的管控問題與 AWS 本身沒有專案設計的問題,Identity Centre 提供了一個集中化的平台,簡化了身份和存取管理。

1. 重點


能夠邀請非 AWS 用戶使用組織的 AWS 帳戶
除允許用戶登入到主控台外,還能夠綁定 SaaS 應用
登入用戶擁有 Session 連線時長限制,並會刷新一組 Access Key

2. 內容


2.1. 關於 Identity Centre

AWS IAM Identity Center(前稱 AWS SSO)是一項由 AWS 提供的身份和存取管理服務,幫助企業管理雲端和企業應用程式的用戶訪問並確保安全和合規。其支援並可自由替換 SAML 2.0 之 SSO 驗證商,也不用擔心系統轉嫁的議題。

而 SSO (Single Sing-On) 的是讓使用者一次性針對多個應用程式和服務進行驗證的方法。其概念在於使用者只需在單個登入介面驗證就可以使用多個應用程式。

生活案例

現今越來越多的餐飲店引入 LINE 掃碼點餐,此時用戶的資料收錄在平台提供商的資料庫,此時可以依靠你的 LINE 帳號進到同供應商底下的其他餐廳進行訂餐,不用另外註冊新的帳戶。

IAM Identity Centre 接手管理 Organization,在組織中不同於 IAM 直接將權限配給 Group / User,反而是在分配帳戶時才綁定權限,以此來避免管理員忘記過往的群組配套權限而造成失誤。透過該方式允許的用戶能透過 Portal 登入後進行多支子帳戶的管理。

2.2. 建立組織與成員

雖然說組織除了配與權限外還能透過 Applications 給予 SaaS 的服務權限,但設定上有不少步驟,我們今天就專注在權限的設置。

2.2.1. 建立組織

我們首先在搜尋欄中查詢 IAM 並找到 Identity Centre 並進到其介面之中。

在 Identity Centre 中首先會需要建立一個 Organization,而此時選擇的地區也就是之後的總部位置,那為了降低網路上的連線延遲,請確保所在地區為日本東京(2025 年後者可考慮 Asia Pacific (Taipei) 臺北地區),因為建立之後我們是沒法輕易改變組織區域的。

此時會跳出一個視窗要你選擇模式,我們維持預設即可,右側的主要是給企業做為體驗,可以看到許多功能都沒法使用。

再來稍等他介面生成一段時間,完成之後就會導到主控介面了。

此時若我切換到其他 Region 就會跳出錯誤的訊息並無法進入管理介面。這邊表示很清楚組織只能存在於一個地區,若要遷移的話我們必須先「刪除」再「重建」。

2.2.1.1. 更換 Portal URL

在預設情況下 Portal URL 由一組亂數的 sub-domain 組成,那我們實際上是可以自行修改 sub-domain 的分支名稱的,在 Settings Summary 中找到 Portal URL 並按下 Edit 。

這時會跳出一個視窗,我們只要將想要的名稱輸入格內並重複確認即可。但這邊很重要!一旦修改過後就無法變動了,只能整個 Organization 重建或透過自己的 DNS 做 CNAME 轉接,各位請好好考慮。

2.2.1.2. 替換 Identity Provider

我們講到該服務系統本身支援 SAML 2.0 的 SSO 提供商,有需求的就這邊來看下怎麼替換。

那當然事後若你相信或想整合在 AWS 的系統也是可以換回的。

2.2.2. 建立成員

我們有了組織之後總要新增些成員,我們進到 Users 分頁並於右上方壓下 Add user 新增 User 。

基本每次避不開的就是先取資源的名稱,而這邊將會是我們未來慣用的登入帳戶,就交給各位自行命名了。接著填寫受邀請者的 eMail 信箱,這邊不論是否有註冊過 AWS 都可以使用進行使用。

這邊的屬性除 Username 之外後續都可進行修改,還能透過該方法進行帳戶轉交。

接著繼續填寫的是受邀請人的名與姓,這邊的 Display Name 是管理員在管理 Organization 時能看到的樣貌,但該用戶登入介面後只會看到 First Name,若想設定為暱稱的話要注意一下。

這邊提醒下若組織有透過前面提到的 Applications 發配 Office 365,記得需要在 Additional Attributes 中給予該用戶一組用於登入的序號。其餘部分基本就是完善用戶資訊的設定,這邊我們就先跳過,直接點擊 Next 進下個步驟。

我們後續按階段慢慢來,這邊我們直接先按 Next 進下一步驟。

接著檢查自己的帳戶設定是否有誤,若完成後就到最底層按下 Add user 新增 User 吧。

完成之後就能看到新的 User 在介面之中囉,我們在這邊可以看到所擁有的所有 Username,並透過 Display Name 去方便管理人員看說是誰或做啥用的帳戶。那 Status 有 Enabled 自然也有 Disable,我們先接著點選 Username 進入管理介面。

在最頂端的 General information 區塊就能看到有個按鈕能夠 Disable 用戶狀態,那過程中我們還沒去驗證信箱因此會有回色區塊的提醒,接著就去收下認證信唄。

來到信箱應該有收到一封來自 no-reply 的 AWS IAM Identity Centre 邀請信件,那我們不疾不徐的原因就在於其效期長達 7 日,那這這信上還會附有帳號資訊與登入連結。接著我們就按下 Accept invitation 接受組織邀請並設置我們的密碼吧。

那由於我們在建立過程中沒有調整設定,使用預設情境讓收到邀請的用戶自己去設置喜歡的密碼。

當我們首次為 User 註冊密碼後就會顯示以下建立完成的通知,接著導回到 portal 登入介面。

我們先嘗試登入這個新的用戶,此時我們會被強迫要幫該帳戶綁定 MFA 設備。

完成綁定之後我們若登入帳戶進到資源介面,但由於並沒有賦予任何權力給該帳戶因此會是空的。

2.2.3. 建立 Group

群組的概念在於其底下的用戶能被快速概括選取以及調整設定。接著在左側的選單中找到 Groups 並在其頁面右上方壓下 Create group 進行建置。

那在下方的範例我就取作 Admin 作為示範,該群組名稱代表擁有 AWS 所有資源之管理權限。但在過程中各位應該知道我們並沒有配發權限,關於這部分則是 Permission Set 進行處理。

那後續有需要變更的情況下我們能點擊群組名稱進入管理介面。

並在這邊進行用戶的補登。

2.3. 賦予用戶權限

再來我們就要真正的賦予用戶權限並給予到指定帳戶的管理權限。

2.3.1. Permission Set

同樣在左側選單中找到 Permission Sets 並透過右上角的按鈕進行建置。

在設定過程中我們有兩種配套方法,第一種是使用官方預設的權限組,雖然可以快速建置但會缺乏細粒度調整,我們待會就來體驗另一種。

我們在頁面的上方選擇 Custom 後進到下一步。

在這邊怎麼樣?我們又來配置 IAM Policy 啦!這邊有三種方式,包括直接書寫,用戶客製化的以及官方預設的。我們這邊使用預設的並選擇最大的 AdministratorAccess 後進下步驟。另外一樣我們是能設置 Boundary,但我們先跳過並進下一步。

在這邊我們同樣簡單命名我們的資源為 Admin,那這邊要注意的是 Session duration 代表每次用戶的連線時間,這邊建議各位設久一點,不然操作資源到一半被強制登出肯定滿肚子火。

而上述的 Replay state 則是用戶登入後該自動跳轉到什麼介面,比如我們使用該網址的話則會自動導引到 US – Ohio 地區並在 EC2 的管理介面上。

HTML
https://us-east-2.console.aws.amazon.com/ec2/

我們接著到下一步驟進行檢查,確認完成後就可以建置了。

2.3.2. 分派權限

我們接著就來配與組織用戶到指定帳戶下進行權限的操控吧,首先在左側選單看到 AWS Accounts,這邊彙總覽所有組織擁有的帳戶,但因為我只是一般個人我就只示範操作單個帳戶。

這邊我們先選取我們要配給用戶(群組)權限的帳號後壓下右上角的按鈕。

那範例這邊我們就授權給所有在 Admin 群組的用戶,這樣未來我們只用把新的 User 加到群組即可。

再來勾選我們的 Permission Set,可以看到直到這個步驟我們才配與權限給用戶使用。

再來下一步就是確認設定,瀏覽無誤後就可以完成設定了。這時會跳出一個提示框說明正在建立,並請用戶不要離開本頁面。稍等一下就會完成建立了。

完成之後我們回到我們的 SSO 介面並嘗試 F5 刷新,此時是部會有任何結果出現的,因為我們的 Session 仍保持再更新前的狀態。必須登出後再重新登入,此時應該會多出一條資源。

點選開來之後,左側的按鈕能進入網頁主控台,其名稱由 Permission Set 來決定。而右側按鈕則是生成 “本次 Session” 的 Access Key,相對於 IAM 固定的更加安全。

進到網頁控制台後我們留意下右上角,應該會是 Permission Set 搭配 Username 的樣式。這樣就代表我們成功的分派 Identity Centre 之帳戶給用戶,完成本次的實作。

3. 後話


我們成功分出 SSO 的組織帳戶了,但目前有個嚴重的問題在於預設情況下 Billings 是不公開給子用戶的。那麼我們又要如何啟用呢?順道來設置我們的預算警報吧!

4. 參考


[1] What is SAML – Cloudflare Learning
https://www.cloudflare.com/learning/access-management/what-is-saml/

[2] Customizing the AWS access portal URL – AWS Doc
https://docs.aws.amazon.com/singlesignon/latest/userguide/howtochangeURL.html

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.