Amazon Cognito ID ソースの使用 OIDC ID ソースの使用クライアントとオーディエンスの検証のクライアント側の認可 JWTs

ID プロバイダでの Amazon Verified Permissions の使用

ID ソースは、Amazon Verified Permissions の外部 ID プロバイダー (IdP) を表します。ID ソースは、ポリシーストアとの信頼関係を持つ IdP で認証されたユーザーからの情報を提供します。アプリケーションが ID ソースからのトークンを使用して認可リクエストを行うと、ポリシーストアはユーザープロパティとアクセス許可から認可を決定できます。Amazon Cognito ユーザープールまたはカスタム OpenID Connect (OIDC) IdP を ID ソースとして追加できます。

Verified Permissions で OpenID Connect (OIDC） ID プロバイダー (IdPs) を使用できます。アプリケーションは、 OIDC準拠の ID プロバイダーによって生成されたJSONウェブトークン (JWTs) を使用して認可リクエストを生成できます。トークンのユーザー ID はプリンシパル ID にマッピングされます。ID トークンを使用すると、Verified Permissions は属性クレームをプリンシパル属性にマッピングします。アクセストークンでは、これらのクレームはコンテキストにマッピングされます。どちらのトークンタイプでも、のようなクレームgroupsをプリンシパルグループにマッピングし、ロールベースのアクセスコントロール () を評価するポリシーを構築できますRBAC。

注記

Verified Permissions は、IdP トークンからの情報に基づいて認可の決定を行いますが、IdP と直接やり取りすることはありません。

Amazon Cognito ユーザープールまたは OIDC ID step-by-stepプロバイダーRESTAPIsを使用して Amazon API Gateway の認可ロジックを構築するチュートリアルについては、 AWS セキュリティブログのAmazon Cognito で Amazon Verified Permissions APIsを使用してAPIゲートウェイを承認する」または「独自の ID プロバイダーを使用する」を参照してください。

トピック

Amazon Cognito ID ソースの使用

Verified Permissions は Amazon Cognito ユーザープールと密接に連携します。Amazon Cognito には予測可能な構造JWTsがあります。Verified Permissions はこの構造を認識し、含まれる情報から最大限のメリットを得ます。例えば、ID トークンまたはアクセストークンを使用して、ロールベースのアクセスコントロール (RBAC) 認可モデルを実装できます。

新しい Amazon Cognito ユーザープール ID ソースには、次の情報が必要です。

AWS リージョン。
ユーザープール ID。
ID ソースに関連付けるプリンシパルエンティティタイプ。例: MyCorp::User。
ID ソースに関連付けるプリンシパルグループエンティティタイプ。例: MyCorp::UserGroup。
ポリシーストアへのリクエストを許可するユーザープールIDsのクライアント。

Verified Permissions は同じ内の Amazon Cognito ユーザープールでのみ機能するため AWS アカウント、別のアカウントで ID ソースを指定することはできません。Verified Permissions は、ユーザープールプリンシパルで動作するポリシーで参照する必要があるアイデンティティソース識別子であるエンティティプレフィックスを、などのユーザープールの ID に設定しますus-west-2_EXAMPLE。この場合、ID がのユーザープール内のユーザーを参照a1b2c3d4-5678-90ab-cdef-EXAMPLE22222します。 us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222

ユーザープールトークンクレームには、属性、スコープ、グループ、クライアント IDs、カスタムデータを含めることができます。Amazon Cognito JWTs には、Verified Permissions の承認決定に役立つさまざまな情報を含める機能があります。具体的には次のとおりです。

cognito: プレフィックスが付いたユーザー名およびグループクレーム
を使用したカスタムユーザー属性 custom: prefix
実行時に追加されたカスタムクレーム
OIDC subやなどの標準クレーム email

これらのクレームの詳細と、それらをの Verified Permissions ポリシーで管理する方法について説明しますID プロバイダートークンをスキーマにマッピングする。

重要

有効期限が切れる前に Amazon Cognito トークンを取り消すことはできますが、 JWTs は署名と有効性が自己完結したステートレスリソースと見なされます。JSON Web Token 7519 RFC に準拠するサービスは、トークンをリモートで検証することが想定されており、発行者とトークンを検証する必要はありません。つまり、Verified Permissions は、後で削除されたユーザーに対して取り消されたトークンまたは発行されたトークンに基づいてアクセスを許可できます。このリスクを軽減するために、有効期間をできるだけ短くしてトークンを作成し、ユーザーのセッションを継続する権限を削除したい場合は更新トークンを取り消すことをお勧めします。詳細については、「トークン失効によるユーザーセッションの終了」を参照してください。

次の例は、プリンシパルに関連付けられた Amazon Cognito ユーザープールクレームの一部を参照するポリシーを作成する方法を示しています。


permit(
     principal, 
     action, 
     resource == ExampleCo::Photo::"VacationPhoto94.jpg" 
)
when { 
     principal["cognito:username"]) == "alice" &&
     principal["custom:department"]) == "Finance"
};

次の例は、Cognito ユーザープール内のユーザーであるプリンシパルを参照するポリシーを作成する方法を示しています。プリンシパル ID はの形式であることに注意してください"<userpool-id>|<sub>"。


permit(
     principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", 
     action, 
     resource == ExampleCo::Photo::"VacationPhoto94.jpg" 
);

Verified Permissions のユーザープール ID ソースの Cedar ポリシーは、英数字とアンダースコア () 以外の文字を含むクレーム名に特別な構文を使用します_。これには、 cognito:usernameやなどの:文字を含むユーザープールプレフィックスクレームが含まれますcustom:department。cognito:username または custom:departmentクレームを参照するポリシー条件を記述するには、principal["custom:department"]それぞれ principal["cognito:username"]およびとして記述します。

注記

トークンに cognito:または custom:プレフィックスを持つクレームと、リテラル値 cognitoまたはを持つクレーム名が含まれている場合custom、を使用した認可リクエストIsAuthorizedWithTokenはで失敗しますValidationException。

クレームのマッピングの詳細については、「」を参照してくださいID トークンをスキーマにマッピングする。Amazon Cognito ユーザーの認可の詳細については、「Amazon Amazon Cognitoデベロッパーガイド」の「Amazon Verified Permissions による認可」を参照してください。

OIDC ID ソースの使用

また、準拠している OpenID Connect (OIDC) IdP をポリシーストアの ID ソースとして設定することもできます。 OIDCプロバイダーは Amazon Cognito ユーザープールに似ています。これらは認証の積JWTsとして生成されます。OIDC プロバイダーを追加するには、発行者を指定する必要があります。 URL

新しい OIDC ID ソースには、次の情報が必要です。

発行者 URL。Verified Permissions は、こので.well-known/openid-configurationエンドポイントを検出できる必要がありますURL。
CNAME ワイルドカードを含まないレコード。たとえば、はにマッピングa.example.comできません*.example.net。逆に、 *.example.com をにマッピングすることはできませんa.example.net。
認可リクエストで使用するトークンタイプ。この場合、ID トークンを選択します。
ID ソースに関連付けるユーザーエンティティタイプ。例: MyCorp::User。
ID ソースに関連付けるグループエンティティタイプ。例: MyCorp::UserGroup。
ID トークンの例、または ID トークン内のクレームの定義。
ユーザーおよびグループエンティティに適用するプレフィックスIDs。CLI およびではAPI、このプレフィックスを選択できます。API ゲートウェイでのセットアップ、ID プロバイダー、またはガイド付きセットアップオプションを使用して作成したポリシーストアでは、Verified Permissions は発行者名からを引いたプレフィックスを割り当てます。たとえばhttps://、ですMyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"。

API オペレーションを使用してOIDCソースからのリクエストを承認する方法の詳細については、「」を参照してください認可に使用できるAPIオペレーション。

次の例は、会計部門の従業員、機密分類を持つ従業員、および衛星オフィスにいない従業員に対して、年次レポートへのアクセスを許可するポリシーを作成する方法を示しています。Verified Permissions は、プリンシパルの ID トークンのクレームからこれらの属性を取得します。


permit(
     principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", 
     action, 
     resource in MyCorp::Folder::"YearEnd2024" 
) when { 
     principal.jobClassification == "Confidential" &&
     !(principal.location like "SatelliteOffice*")
};

クライアントとオーディエンスの検証

ID ソースをポリシーストアに追加すると、Verified Permissions には、ID トークンとアクセストークンが意図したとおりに使用されていることを確認する設定オプションがあります。この検証は、 IsAuthorizedWithTokenおよび BatchIsAuthorizedWithTokenAPIリクエストの処理中に行われます。この動作は、ID トークンとアクセストークン、および Amazon Cognito と OIDC ID ソースによって異なります。Amazon Cognito ユーザープールプロバイダーを使用すると、Verified Permissions は ID トークンとアクセストークンの両方でクライアント ID を検証できます。OIDC プロバイダーを使用すると、Verified Permissions は ID トークンのクライアント ID とアクセストークンの対象者を検証できます。

クライアント ID は、アプリケーションが使用する ID プロバイダーインスタンスに関連付けられた識別子です。たとえば、です1example23456789。対象者とは、などのアクセストークンの意図された証明書利用者または送信先に関連付けられたURLパスですhttps://mytoken.example.com。アクセストークンを使用する場合、audクレームは常に対象者に関連付けられます。

Verified Permissions は、次のように ID ソースオーディエンスとクライアント検証を実行します。

Amazon Cognito

Amazon Cognito ID トークンには、アプリクライアント ID を含む audクレームがあります。アクセストークンには、アプリクライアント ID も含まれるclient_idクレームがあります。

ID ソースにクライアントアプリケーションの検証に 1 つ以上の値を入力すると、Verified Permissions はこのアプリケーションクライアントのリストIDsを ID トークンaudクレームまたはアクセストークンclient_idクレームと比較します。Verified Permissions は、Amazon Cognito ID ソースURLの依存関係の対象者を検証しません。

OIDC

OIDC ID トークンには、 IDsなどのクライアントを含む audクレームがあります1example23456789。

OIDC アクセストークンには、などのトークンURLの対象者を含む aud クレームとhttps://myapplication.example.com、 IDsなどのクライアントを含む client_idクレームがあります1example23456789。

ポリシーストアを設定するときは、でトークンのオーディエンスを検証するためにポリシーストアが使用するオーディエンス検証の値を 1 つ以上入力します。

ID トークン – Verified Permissions は、audクレームIDs内のクライアントの少なくとも 1 つのメンバーがオーディエンス検証値と一致することを確認して、クライアント ID を検証します。
アクセストークン – Verified Permissions は、audクレームURL内のがオーディエンス検証値と一致することを確認して、オーディエンスを検証します。aud クレームが存在しない場合、対象者は cidまたは client_idクレームを使用して検証できます。ID プロバイダーに正しい対象者のクレームと形式を確認してください。

のクライアント側の認可 JWTs

アプリケーションでJSONウェブトークンを処理し、ポリシーストアの ID ソースを使用せずに Verified Permissions にクレームを渡すことができます。JSON ウェブトークン (JWT) からエンティティ属性を抽出し、Verified Permissions に解析できます。

この例では、.1 を使用してアプリケーションから Verified Permissions を呼び出す方法を示しますJWT。


async function authorizeUsingJwtToken(jwtToken) {
  
    const payload = await verifier.verify(jwtToken);
   
    let principalEntity = {
        entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
        entityId: payload["sub"], // the application need to use the claim that represents the user-id
    };
    let resourceEntity = {
        entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
        entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
    };
    let action = {
        actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
        actionId: "GetPhoto", //the application needs to fill in the relevant action type
    };
    let entities = {
        entityList: [],
    };
    entities.entityList.push(...getUserEntitiesFromToken(payload));
    let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
    
    const authResult = await client
        .isAuthorized({
        policyStoreId: policyStoreId,
        principal: principalEntity,
        resource: resourceEntity,
        action: action,
        entities,
        })
        .promise();
        
    return authResult; 
  
}

function getUserEntitiesFromToken(payload) {
  let attributes = {};
  let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
  Object.entries(payload).forEach(([key, value]) => {
    if (claimsNotPassedInEntities.includes(key)) {
        return;
    }
    if (Array.isArray(value)) {
      var attibuteItem = [];
      value.forEach((item) => {
        attibuteItem.push({
          string: item,
        });
      });
      attributes[key] = {
        set: attibuteItem,
      };
    } else if (typeof value === 'string') {
      attributes[key] = {
        string: value,
      } 
    } else if (typeof value === 'bigint' || typeof value ==='number') {
        attributes[key] = {
            long: value,
          } 
    } else if (typeof value === 'boolean') {
        attributes[key] = {
            boolean: value,
       } 
    }

  });

  let entityItem = {
    attributes: attributes,
    identifier: {
      entityType: "PhotoFlash::User",
      entityId: payload["sub"], // the application needs to use the claim that represents the user-id
    }
  };
  return [entityItem];
}

1 このコード例では、 aws-jwt-verifyライブラリを使用して、 OIDC互換でJWTs署名されたを検証します IdPs。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

テンプレートにリンクされたポリシーの例

ID ソースの作成