當可信實體通過阿里云控制臺、API或CLI扮演RAM角色時，需要執(zhí)行權(quán)限策略的判定流程，根據(jù)判定結(jié)果決定是否允許扮演RAM角色（AssumeRole）。本文為您介紹扮演RAM角色時的權(quán)限策略判定流程。

創(chuàng)建RAM角色時需要為RAM角色添加信任策略，該信任策略用于指定允許扮演RAM角色的可信實體，是一種基于資源的策略。當可信實體扮演某個RAM角色時，又需要擁有扮演RAM角色的相應權(quán)限，這是可信實體的基于身份的策略。

當可信實體扮演RAM角色時，判定程序會按照下圖所示的順序依次進行權(quán)限策略判定，此時可信實體是訪問身份，被扮演的RAM角色是訪問資源。

RAM角色扮演請求涉及多種類型的權(quán)限策略，每種權(quán)限策略內(nèi)部的判定都遵從最小單元判定流程，完整的判定流程如下：

1. 管控策略判定

   管控策略（Control Policy）是資源目錄中對成員賬號訪問定義的權(quán)限邊界。如果請求扮演的RAM角色所屬賬號是資源目錄的成員賬號，并且管控策略已開啟，判定程序會按照最小單元判定流程執(zhí)行管控策略判定。否則，判定程序會跳過此步。

   根據(jù)管控策略的判定結(jié)果，作出下一步判定。具體如下：

   • 管控策略的判定結(jié)果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結(jié)束，管控策略的判定結(jié)果就是最終的判定結(jié)果。
   • 管控策略的判定結(jié)果是Allow（允許）：繼續(xù)進行下一步判定。
2. 會話策略判定

   會話策略（Session Policy）是在以編程方式扮演RAM角色（調(diào)用AssumeRole API）的過程中創(chuàng)建臨時會話時，在參數(shù)中傳遞的策略，用于進一步限制會話的權(quán)限。如果發(fā)起訪問請求的身份是RAM角色，并且擁有會話策略，判定程序會按照最小單元判定流程執(zhí)行會話策略判定。否則，判定程序會跳過此步。

   說明 進行角色SSO時，沒有會話策略，因此判定程序會跳過此步。

   根據(jù)會話策略的判定結(jié)果，作出下一步判定。具體如下：

   • 會話策略的判定結(jié)果是Explicit Deny（顯式拒絕）或Implicit Deny（隱式拒絕）：判定結(jié)束，會話策略的判定結(jié)果就是最終的判定結(jié)果。
   • 會話策略的判定結(jié)果是Allow（允許）：繼續(xù)進行下一步判定。
3. 基于身份的策略判定和基于資源的策略判定

   同時進行基于身份的策略（Identity-based Policy）判定和基于資源的策略（Resource-based Policy）判定，并將兩者的判定結(jié)果緩存。

   • 基于身份的策略判定

     對于RAM用戶，基于身份的策略包括直接授權(quán)的策略和從RAM用戶組中繼承的策略。對于RAM角色，基于身份的策略為直接授權(quán)的策略。基于身份的策略因授權(quán)范圍不同，又分為賬號級別和資源組級別，賬號級別的策略優(yōu)先級高于資源組級別的策略。

     說明 進行角色SSO時，由于用戶還未登錄成功，所以沒有基于身份的策略，判定程序會跳過此步，直接以基于資源的策略判定結(jié)果作為最終結(jié)果。
     判定流程如下：

     1. 檢查發(fā)起請求的RAM身份是否擁有賬號級別的基于身份的策略。
        • 是：判定程序按照最小單元判定流程執(zhí)行賬號級別的身份策略判定。判定結(jié)果說明如下：
          • 如果判定結(jié)果是Explicit Deny（顯式拒絕）或Allow（允許）：基于身份策略的判定結(jié)束，將結(jié)果緩存到判定結(jié)果A。
          • 如果判定結(jié)果是Implicit Deny（隱式拒絕）：繼續(xù)進行下一步判定。
        • 否：繼續(xù)進行下一步判定。
     2. 檢查發(fā)起請求的RAM身份是否擁有資源組級別的基于身份的策略。
        • 是：判定程序按照最小單元判定流程執(zhí)行資源組級別的身份策略判定，并將結(jié)果緩存到判定結(jié)果A。
        • 否：直接保存判定結(jié)果A為Implicit Deny（隱式拒絕）。
   • 基于資源的策略判定

     檢查請求扮演的RAM角色是否擁有信任策略。

     • 是：判定程序按照最小單元判定流程執(zhí)行基于資源的策略判定，并將結(jié)果緩存到判定結(jié)果B。
     • 否：直接保存判定結(jié)果B為Implicit Deny（隱式拒絕）。
4. 合并判定結(jié)果

   將基于身份策略的判定結(jié)果A和基于資源策略的判定結(jié)果B進行合并。合并邏輯與通用的權(quán)限策略判定流程不同，只有當基于身份的策略判定（判定結(jié)果A）和基于資源的策略判定（判定結(jié)果B）全部是Allow（允許）時，扮演RAM角色的請求才會被允許，其他情況均會被拒絕。

   具體如下：

   • 如果判定結(jié)果A和判定結(jié)果B中存在任意一個Explicit Deny（顯式拒絕）：合并后的最終判定結(jié)果為Explicit Deny（顯式拒絕），判定結(jié)束。
   • 如果判定結(jié)果A和判定結(jié)果B全部是Allow（允許）：合并后的最終判定結(jié)果為Allow（允許），判定結(jié)束。
   • 除上述兩種外的其他情況：合并后的最終判定結(jié)果為Implicit Deny（隱式拒絕），判定結(jié)束。