単一IDプロバイダー: 認可

マルチテナントアーキテクチャにおける組織のユーザー認可について学びます。

認可を検討する際は、通常、ユーザーに許可する操作をどのように判定するか、また、その情報をアプリケーションや API にどのように伝えるかを考慮する必要があります。使用しているアプリケーションによっては、これらの一方または両方が関係する場合があります。アーキテクチャシナリオでは、汎用的なガイダンスとして B2B Authorization を提供しています。ここでのガイダンスとあわせて確認することをお勧めします。

• IDトークン は、カスタムクレームを通じてユーザーの認可情報をアプリケーションに渡すためによく使用されます。カスタムクレームは、Rules 拡張機能を使用して追加できます。クレームを追加することで、ユーザーが権限のない操作を試行できないユーザーインターフェースを実現できます。IDトークン 内の認可情報は、従来の Web アプリケーションにおいて、フロントエンドの制御を迂回しようとするユーザーをアプリケーションのバックエンドで制限する手段にもなります。

ベストプラクティス

Auth0 Authorization Core 機能を通じて Auth0 ロールベースアクセス制御 (RBAC) を利用すると、アクセス許可を定義し、それらをアクセストークンに自動的に適用できます。詳細については、API のロールベースアクセス制御を有効にする を参照してください。

Auth0 RBAC 機能では、IDトークン (必要に応じてアクセストークンにも手動で適用可能) にカスタムクレームとして追加できる情報も提供できます。Auth0 Organizations では、1 つ以上のメンバーシップに割り当てられたロールを通じて Auth0 RBAC 機能を活用できます。詳しくは、組織メンバーにロールを追加する を参照してください。

• 共有リソースサービスへの公開アクセスを提供する API は、通常、アクセス制御メカニズムで保護されます。このため Auth0 では、認可ベアラートークン、つまり OAuth 2 の アクセストークン を作成する機能を提供しています。これにより通常は、Auth0 の ロールベースアクセス制御 (RBAC) を使用して 1 つ以上の メンバーシップに割り当てられたロール を適用するか、Rules 拡張機能でカスタムクレームを追加することで、ユーザーの認可情報を API に伝えることができます。また、Auth0 RBAC 機能を利用して、アクセストークン の scope クレームを自動的に調整することもできます。これにより API は、この情報を使用して適切なレベルのアクセス制御を適用でき、ユーザー情報を取得するための追加のルックアップを行わずにポリシールールを適用できます。
• 場合によっては、アプリケーションレベルのポリシーを Auth0 テナントで実装したいこともあります。これにより、各アプリケーションやリソースサービス (API) を個別に変更しなくても、広範な対象にポリシーを適用できます。通常、これは Rules 拡張機能を使用して実装します。

ベストプラクティス

Auth0 Organizations では、ユーザーの認証時に利用できる組織関連情報に Auth0 Rules からアクセスできます。この情報は、Rules の context オブジェクトに含まれる organization オブジェクトから利用できます。organization オブジェクトでは、Auth0 の組織定義に対してプロビジョニングされたメタデータにもアクセスできます。詳しくは、Organizations のカスタム開発 を参照してください。

​

IDトークンのクレーム

通常、クレームは IDトークンのクレーム のベストプラクティス ガイダンスで説明しているように、IDトークンに追加できます。Auth0 の Organizations 機能を使用すると、組織に所属するユーザー向けに発行されるすべての IDトークンに、org_id クレームが自動的に追加されます (例については、トークンと組織の使用 を参照してください) 。このパラメーターは Auth0 SDK によって検証されます。また、IDトークンにカスタムクレームを追加することで、Auth0 の組織に関連付けられた追加情報を含めることもできます。

context.idToken['http://travel0.net/multifactor'] = context.multifactor;

注記: テナントで Authentication API における組織名のサポートを有効にしている場合、org_name クレームは IDトークンに自動的に含まれます。詳しくは、Authentication API で組織名を使用するを参照してください。

​

SAML アサーション

Auth0 の組織機能は SAML 対応アプリケーションをサポートしていませんが、上流の IDプロバイダー (IdP) によって生成された SAML アサーションを構成して、下流で利用される IDトークンに標準クレームまたはカスタムクレームを設定できます。たとえば、SAML エンタープライズ接続の mappings セクションは次のように定義できます。

{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}

この例では、各フィールドに Rule 内の user オブジェクトの値が割り当てられます。これらの値は、IDトークン内の標準クレームにマッピングされるか、カスタムクレームを使用してマッピングできます。SAML マッピングのカスタマイズの詳細については、Connect Your App to SAML Identity Providers: Set up mappings を参照してください。

​

アクセストークンのクレーム

アクセス制御の判断のためにアクセストークンに追加する他のクレーム (一般的なAccess Token Claimsのベストプラクティスのガイダンスを参照) に加えて、通常は、ユーザーが所属する組織も伝える必要があります。

IDトークンと同様に、Auth0 Organizations 機能を使用している場合、組織に所属するユーザー向けに発行されるすべてのアクセストークンには、org_id クレームが自動的に追加されます (例については、Work with Tokens and Organizationsを参照) 。また、アクセストークンにカスタムクレームを追加することで、Auth0 の組織に関連する追加情報を含めることもできます。

context.accessToken['http://travel0.net/multifactor'] = context.multifactor;

注: テナントで Authentication API の組織名サポートを有効にしている場合、org_name クレームはアクセストークンに自動的に含まれます。詳しくは、Authentication API で組織名を使用する を参照してください。

または、組織ごとに一意の API オーディエンスを作成することもできます。この方法では、Auth0 で組織ごとに一意の API 定義を作成することになります。この仕組みにより、カスタム Rule 拡張機能の必要性を減らせますが、その分複雑さが増し、扱いが難しくなる場合があります。簡単に比較すると、次のとおりです。

アプローチ	メリット	デメリット
一意の API オーディエンス	単一の組織に対するマシン間アクセスを標準でサポートします。 オーディエンスはアクセストークンの標準クレームです。 リフレッシュトークンの処理に追加の組織ロジックは必要ありません。	組織ごとに API を作成する処理を自動化する必要があります。 RBAC を使用する場合は、個別のロールを作成する必要が生じることがあります。 メンバーシップへのロールのプロビジョニングを自動化する必要があります。 API 実装では複数のオーディエンスを処理しなければなりません。
カスタムクレーム	Auth0 テナントの構成を簡素化できます。	アクセストークンに組織を追加するには、Rule でカスタムコードが必要です。

​

ロール

Auth0の組織機能では、Auth0テナントに関連付けられた Authorization Core 機能を通じて、ロールベースアクセス制御 (RBAC) もサポートしています。RBAC は、Auth0の組織メンバーシップレベルで適用されます。

API で Auth0 Authorization Core RBAC を有効にすると、アクセストークン内のデフォルトの scope クレームが自動的に変更され、デフォルトで permission クレームが追加されます (例については、Work with Tokens and Organizations を参照してください) 。また、Rules の context オブジェクトで利用できる authorization オブジェクトにアクセスすることで、ロール情報をカスタムクレームとして IDトークンに追加することもできます。詳しくは、Rules with Authorization Sample Use Cases: Add User Roles to Tokens を参照してください。

​

アクセス制御

リソース レベルでのポリシー適用は、システム内のアプリケーションや API の責任です。Auth0 テナント のような集中型の認可サーバーでポリシーを適用しようとすると、すぐに保守も理解も難しい複雑な制御システムに行き着きます。代わりに、集中型の認可サーバーは、ユーザーに関する適切な情報がトークンに含まれるようにすることで、アプリケーションや API がポリシー適用の判断に必要な情報を得られるようにできます。少なくとも、1 つのトークンに収めるには情報量が多すぎる場合 (たとえば、リソース レベルの権限) や、情報の変化が頻繁でトークンから直接参照すると古くなってしまう場合には、アプリケーションや API が正しい情報を参照できるようにする必要があります。

一方で、より高レベルのポリシー適用は集中管理で扱える場合もあります。たとえば、Auth0 テナント コンテキストを使用している場合、すべてのアプリケーションや API が同じ制限を適用しなくても済むようにする Rule を実装できるケースがあります。これには次のようなものがあります。

• 特定の IP アドレスからのユーザーによるアクセスをブロックする
• Contextual またはAdaptive MFAに関する特定の要件を実装する
• メールアドレスの確認が完了しているユーザーだけにログインを制限する
• 特定の API オーディエンスへのアクセスを制限し、ユーザーが他の API オーディエンス用のアクセストークンを取得できないようにする、または特定の状況ではそのオーディエンス用のアクセストークンを取得できないようにする。この場合、各組織に対してカスタム API Audience を作成しているなら、認証中のユーザーが対応する API オーディエンスに一致する組織に属していることも、Rule で保証する必要があります。

Auth0 Management API へのアクセスは組織によって制限されません。Auth0 Management API へのアクセスは、マシン間コンテキストで使用するために割り当てられたアクセストークンを介して行われるため、Auth0 組織 で制限することはできません。したがって、顧客に Auth0 Management API インスタンスへの直接アクセスを提供しないでください。顧客がユーザーアカウントなど自分たちの組織の一部を管理する必要がある場合 (Profile Management を参照) は、この目的のために独自のアプリケーションや API を構築する必要があります。