當可信實體通過阿里雲控制台、API或CLI扮演RAM角色時，需要執行權限原則的判定流程，根據判定結果決定是否允許扮演RAM角色（AssumeRole）。本文為您介紹扮演RAM角色時的權限原則判定流程。
建立RAM角色時需要為RAM角色添加信任策略，該信任策略用於指定允許扮演RAM角色的可信實體，是一種基於資源的策略。當可信實體扮演某個RAM角色時，又需要擁有扮演RAM角色的相應許可權，這是可信實體的基於身份的策略。
當可信實體扮演RAM角色時，判定程式會按照下圖所示的順序依次進行權限原則判定，此時可信實體是訪問身份，被扮演的RAM角色是訪問資源。
RAM角色扮演請求涉及多種類型的權限原則，每種權限原則內部的判定都遵從最小單元判定流程，完整的判定流程如下：
- 管控策略判定
管控策略（Control Policy）是資來源目錄中對成員帳號訪問定義的許可權邊界。如果請求扮演的RAM角色所屬帳號是資來源目錄的成員帳號，並且管控策略已開啟，判定程式會按照最小單元判定流程執行管控策略判定。否則，判定程式會跳過此步。
根據管控策略的判定結果，作出下一步判定。具體如下：
- 管控策略的判定結果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結束，管控策略的判定結果就是最終的判定結果。
- 管控策略的判定結果是Allow（允許）：繼續進行下一步判定。
- 會話策略判定
會話策略（Session Policy）是在以編程方式扮演RAM角色（調用AssumeRole API）的過程中建立臨時會話時，在參數中傳遞的策略，用於進一步限制會話的許可權。如果發起訪問請求的身份是RAM角色，並且擁有會話策略，判定程式會按照最小單元判定流程執行會話策略判定。否則，判定程式會跳過此步。
说明 進行角色SSO時，沒有會話策略，因此判定程式會跳過此步。根據會話策略的判定結果，作出下一步判定。具體如下：
- 會話策略的判定結果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結束，會話策略的判定結果就是最終的判定結果。
- 會話策略的判定結果是Allow（允許）：繼續進行下一步判定。
- 基於身份的策略判定和基於資源的策略判定
同時進行基於身份的策略（Identity-based Policy）判定和基於資源的策略（Resource-based Policy）判定，並將兩者的判定結果緩衝。
- 基於身份的策略判定
對於RAM使用者，基於身份的策略包括直接授權的策略和從RAM使用者組中繼承的策略。對於RAM角色，基於身份的策略為直接授權的策略。基於身份的策略因授權範圍不同，又分為帳號層級和資源群組層級，帳號層級的策略優先順序高於資源群組層級的策略。
说明 進行角色SSO時，由於使用者還未登入成功，所以沒有基於身份的策略，判定程式會跳過此步，直接以基於資源的策略判定結果作為最終結果。判定流程如下： - 基於資源的策略判定
檢查請求扮演的RAM角色是否擁有信任策略。
- 是：判定程式按照最小單元判定流程執行基於資源的策略判定，並將結果緩衝到判定結果B。
- 否：直接儲存判定結果B為Implicit Deny（隱式拒絕）。
- 基於身份的策略判定
- 合并判定結果
將基於身份策略的判定結果A和基於資源策略的判定結果B進行合并。合并邏輯與通用的權限原則判定流程不同，只有當基於身份的策略判定（判定結果A）和基於資源的策略判定（判定結果B）全部是Allow（允許）時，扮演RAM角色的請求才會被允許，其他情況均會被拒絕。
具體如下：
- 如果判定結果A和判定結果B中存在任意一個Explicit Deny（顯式拒絕）：合并後的最終判定結果為Explicit Deny（顯式拒絕），判定結束。
- 如果判定結果A和判定結果B全部是Allow（允許）：合并後的最終判定結果為Allow（允許），判定結束。
- 除上述兩種外的其他情況：合并後的最終判定結果為Implicit Deny（隱式拒絕），判定結束。