Single Identity Provider: 認可

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

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

• ID トークン は、カスタムクレームを通じてユーザーの認可情報をアプリケーションに伝えるためによく使われます。これらのクレームは、ルール の拡張機能を使って追加できます。クレームを追加することで、ユーザーが権限のない操作を試せないようなユーザー インターフェースを提供できます。ID トークン に含まれる認可情報は、従来型の web app において、ユーザーがフロントエンドの制御を回避することを防ぐための手段を、アプリケーションのバックエンドにも提供します。

ベストプラクティス

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

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

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

ベストプラクティス

Auth0 Organizations は、ユーザーの認証時に参照できる organization 中心の情報を Auth0 ルールに提供します。この情報は、ルール の context object に含まれる organization object から利用できます。organization object では、Auth0 の Organization 定義に対してプロビジョニングされた任意のメタデータにもアクセスできます。詳しくは、Custom Development for Organizations を参照してください。

​

ID トークンのクレーム

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

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

注: tenant を Authentication API で organization名をサポートするように設定している場合、org_name claim は ID トークンに自動的に含まれます。詳しくは、Use Organization Names in Authentication API を参照してください。

​

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"
}

この例では、各フィールドには Action 内の user オブジェクトで値が割り当てられ、その値は ID トークン内の標準クレームにマッピングされるか、カスタムクレームを使用してマッピングできます。SAML マッピングのカスタマイズについて詳しくは、アプリをSAML IDプロバイダーに接続する: マッピングを設定するを参照してください。

アプリケーションで SAML を使用し、Auth0 が IdP として機能する場合は、organization クエリパラメータを使用して、SAML サインインリクエストに 組織 を含めることができます。

https://{YOUR_AUTH0_DOMAIN}/samlp/{YOUR_APP_CLIENT_ID}?organization={YOUR_ORGANIZATION_ID}

Auth0 は、SAML レスポンス内で organization をカスタム属性として返します。

http://schemas.auth0.com/org_id

Action で設定されたカスタムクレームなど、OIDC トークンに含まれる非標準クレームも、http://schemas.auth0.com/ をプレフィックスとして SAML レスポンスに含まれます。

​

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

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

ID トークンと同様に、Auth0 Organizations 機能を使用する場合、organization のメンバーシップを持つユーザー向けに発行されるすべてのアクセストークンには、org_id クレームが自動的に追加されます (例については、Tokens と Organizations を扱うを参照してください) 。また、アクセストークンにカスタムクレームを追加することで、Auth0 Organization に関連付けられた追加情報を含めることもできます。

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

注: テナントを Authentication API で organization名をサポートするように設定している場合、org_name クレームはアクセストークンに自動的に含まれます。詳しくは、Use Organization Names in Authentication APIを参照してください。

または、organization ごとに一意の API audience を作成することもできます。これにより、Auth0 で一意の API 定義が作成されます。この方法では、カスタム ルール による拡張の必要性を抑えられますが、その一方で複雑さが増し、扱いが難しくなることがあります。簡単に比較すると次のとおりです。

Approach	Pros	Cons
Unique API Audience	単一の organization に対する machine-to-machine access を標準でサポートします。 audience はアクセストークンの標準クレームです。 リフレッシュトークンの処理に追加の organization ロジックは必要ありません。	organization ごとに API を作成する処理を自動化する必要があります。 ロールベースのアクセス制御を使用する場合は、個別の Roles を作成する必要が生じることがあります。 Roles からメンバーシップへのプロビジョニングを自動化する必要があります。 API 実装では複数の audience を処理しなければなりません。
Custom Claim	Auth0 テナントの設定を簡素化できます。	organization をアクセストークンに追加するには、ルール内でカスタムコードが必要です。

​

ロール

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

API で Auth0 Authorization Core RBAC を有効にすることができます。これにより、アクセストークン内のデフォルトの scope クレームが自動的に変更され、デフォルトで permission クレームも追加されます (例については、Tokens と Organizations を扱うを参照してください) 。また、ルール の context オブジェクトで使用できる authorization オブジェクトにアクセスして、ロール情報をカスタムクレームとして ID トークンに追加することもできます。詳しくは、Authorization を使用するルールのサンプルユースケース: トークンにユーザー ロールを追加するを参照してください。

​

アクセス制御

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

一方で、より大枠のポリシー適用の一部は、集中型で処理することもできます。たとえば、Auth0 テナントのコンテキストを使用している場合、すべてのアプリケーションおよび/または API が同じ制限を適用しなくても済むようにする ルール を実装できるケースがあります。具体的には、次のようなものです。

• 特定の IP アドレスからのユーザーアクセスをブロックする
• コンテキストに応じた要件や Adaptive MFA に関する特定の要件を実装する
• メールアドレスを確認済みのユーザーのみにログインを制限する
• 特定の API audience へのアクセスを制限し、ユーザーがほかの API audience 用のアクセストークンを取得できないようにする、または特定の状況ではその audience 用のアクセストークンを取得できないようにする。この場合、各 organization ごとにカスタム API Audience を作成しているなら、対応する API audience に一致する organization に認証中のユーザーが所属していることも、ルール で保証する必要があります。

Auth0 Management API へのアクセスは organization によって制限されません。Auth0 Management API へのアクセスは machine-to-machine コンテキストで使用するために割り当てられたアクセストークンを介して行われ、Auth0 Organization によって制約することはできません。したがって、お客様に Auth0 Management API のインスタンスへの直接アクセスを提供しないでください。お客様がユーザーアカウントなど organization の一部を管理する必要がある場合 (プロファイル管理 を参照) 、この目的のために独自のアプリケーションおよび/または API を構築する必要があります。