Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ONTAPにおけるOAuth 2.0認可サーバーとアクセストークン

共同作成者 dmp-netapp netapp-bhouser netapp-aaron-holt netapp-dbagwell netapp-aherbin
PDF

許可サーバは、OAuth 2.0許可フレームワークの中心的なコンポーネントとして、いくつかの重要な機能を担っています。

OAuth 2.0許可サーバ

許可サーバは、主にアクセス トークンの作成と署名を行います。このアクセス トークンには、クライアント アプリケーションが保護されたリソースに選択的にアクセスするためのIDと許可情報が格納されます。許可サーバは通常、相互に隔離されています。また、スタンドアロンの専用サーバとして導入したり、IDおよびアクセス管理製品の一部として導入したりと、その導入形式はさまざまです。

メモ 認可サーバーには、特にOAuth 2.0の機能がより大規模なIDおよびアクセス管理製品やソリューションに組み込まれている場合、異なる用語が使用されることがあります。例えば、*アイデンティティプロバイダー（IdP）*という用語は、*認可サーバー*と同義語として使用されることがよくあります。

管理

アクセス トークンの発行に加えて、許可サーバは、関連する管理サービスも提供します。これは通常、Webユーザ インターフェイスを介して行われます。たとえば、次のようなことを定義したり管理したりできます。

  • ユーザとユーザ認証

  • スコープ

  • テナントとRealmを通じた管理分離

  • ポリシーの適用

  • さまざまな外部サービスへの接続

  • その他のIDプロトコル（SAMLなど）のサポート

ONTAPは、OAuth 2.0標準に準拠した許可サーバと互換性があります。

ONTAPへの定義

1台以上の許可サーバをONTAPに定義する必要があります。ONTAPは、各サーバとのセキュアな通信を通じてトークンを検証したり、その他の関連タスクを実行したりして、クライアント アプリケーションを支援します。

ONTAPの設定の主な側面を以下に示します。詳細については、"OAuth 2.0の導入シナリオ"も参照してください。

アクセス トークンの検証方法と検証場所

アクセス トークンの検証には、2つのオプションがあります。

  • ローカル検証

    ONTAPは、トークンを発行した許可サーバから提供された情報に基づいて、アクセス トークンをローカルで検証できます。許可サーバから取得した情報は、ONTAPによってキャッシュされ、定期的に更新されます。

  • リモート イントロスペクション

    リモート イントロスペクションを使用して、許可サーバでトークンを検証することもできます。イントロスペクションは、許可された当事者がアクセス トークンについて許可サーバに問い合わせることを可能にするプロトコルです。イントロスペクションを使えば、ONTAPでアクセス トークンから特定のメタデータを抽出し、トークンを検証することができます。ONTAPは、パフォーマンス上の理由から一部のデータをキャッシュします。

ネットワークの位置

ONTAPは、ファイアウォールの内側にある可能性があります。この場合は、設定の際にプロキシを指定する必要があります。

許可サーバを定義する方法

CLI、System Manager、REST API などの管理インターフェイスを使用して、ONTAP に認証サーバーを定義できます。例えば、CLI ではコマンド `security oauth2 client create`を使用します。

`security oauth2 client create`の詳細については、link:https://docs.netapp.com/us-en/ontap-cli/security-oauth2-client-create.html["ONTAPコマンド リファレンス"^]をご覧ください。
許可サーバの数

1つのONTAPクラスタに対して、最大8台の許可サーバを定義できます。発行者または発行者 / オーディエンスのクレームが一意である限り、同じ許可サーバを同じONTAPクラスタに複数回定義できます。たとえば、Keycloakで異なるRealmを使用する場合は、常にこれが該当します。

ONTAPでサポートされるOAuth 2.0の機能

OAuth 2.0のサポートは、最初にONTAP 9.14.1で利用可能になりましたが、その後のリリースで引き続き強化されています。ONTAPでサポートされているOAuth 2.0の機能を以下に説明します。

メモ 特定のONTAPリリースで導入された機能は、以降のリリースでも引き継がれます。

ONTAP 9.16.1

ONTAP 9.16.1では、OAuth 2.0の標準機能が拡張され、ネイティブのEntra IDグループ用のEntra ID固有の拡張機能が追加されています。これにより、アクセス トークンで名前の代わりにGUIDを使用できます。さらに、このリリースでは、アクセス トークンの「roles」フィールドを使用してネイティブ アイデンティティ プロバイダのロールをONTAPのロールにマッピングできる外部ロール マッピングのサポートが追加されています。

ONTAP 9.14.1

ONTAP 9.14.1以降では、次のOAuth 2.0の標準機能を通じて、以下を使用しているアプリケーションに対して許可サーバがサポートされます。

  • "RFC6749：OAuth 2.0 認可フレームワーク"および "RFC 7519: JSON Web Token（JWT）"に記載されている「iss」、「aud」、「exp」などの標準フィールドを備えたOAuth 2.0。これには、アクセストークン内の「upn」、「appid」、「sub」、「username」、「preferred_username」などのフィールドを通じてユーザーを一意に識別する機能も含まれています。

  • 「group」フィールドを使用したグループ名用のADFSベンダー固有の拡張機能。

  • 「group」フィールドを使用したグループUUID用のAzureベンダー固有の拡張機能。

  • OAuth 2.0のアクセス トークン スコープ内の自己完結型および指定ロールを使用して許可をサポートするONTAPの拡張機能。これには、「scope」フィールドと「scp」フィールド、およびスコープ内のグループ名が含まれます。

OAuth 2.0アクセス トークンの用途

許可サーバによって発行されたOAuth 2.0アクセス トークンは、ONTAPによって検証され、REST APIクライアント要求のロールベースのアクセス制御に使用されます。

アクセス トークンを取得する

アクセス トークンは、REST APIを使用するONTAPクラスタに定義されている許可サーバから取得する必要があります。トークンを取得するには、許可サーバと直接やり取りする必要があります。

注意 ONTAPがアクセス トークンを発行したり、クライアントからの要求を許可サーバにリダイレクトしたりすることはありません。

トークンを要求する方法は、次のようないくつかの要因によって異なります。

  • 許可サーバとその設定オプション

  • OAuth 2.0のグラント タイプ

  • 要求の発行に使用するクライアントやソフトウェア ツール

グラント タイプ

grant とは、OAuth 2.0 アクセストークンをリクエストおよび取得するために用いられる、ネットワークフローのセットを含む明確に定義されたプロセスです。クライアント、環境、セキュリティ要件に応じて、複数の異なるタイプの grant を使用できます。一般的な grant タイプのリストを下の表に示します。

グラント タイプ 概要

クライアント クレデンシャル

一般的なグラント タイプで、クレデンシャル（IDや共有秘密鍵など）のみを使用します。クライアントがリソースのオーナーと密接な信頼関係にあることが想定されています。

パスワード

リソース オーナー パスワード クレデンシャルは、リソース オーナーがクライアントとの信頼関係を確立している場合に使用できるグラント タイプです。また、レガシーHTTPクライアントからOAuth 2.0に移行する場合にも役立ちます。

許可コード

機密クライアントに最適なグラント タイプで、リダイレクトベースのフローに基づいています。アクセス トークンとリフレッシュ トークンのどちらを取得するためにも使用できます。

JWTのコンテンツ

OAuth 2.0アクセス トークンは、JWT形式です。そのコンテンツは、設定に基づいて許可サーバによって作成されます。ただし、クライアント アプリケーションはトークンを解読できません。クライアントには、トークンを検査したり、そのコンテンツを認識したりする理由がありません。

各JWTアクセス トークンには、一連のクレームが格納されています。クレームには、許可サーバの管理定義に基づいて発行者と許可の特性が記述されています。次の表は、標準に登録されているクレームの一部をまとめたものです。すべての文字列で、大文字と小文字が区別されます。

クレーム キーワード 概要

Issuer

iss

トークンを発行したプリンシパルを特定します。クレームの処理はアプリケーションにより異なります。

Subject

sub

トークンのサブジェクトまたはユーザです。クレーム名は、グローバルまたはローカルで一意のものに限定されます。

Audience

aud

目的とするトークンの受信者です。文字列の配列として記述されます。

Expiration

exp

トークンが期限切れになり、拒否されるまでの期間です。

詳細については、 "RFC 7519：JSON Web Tokens"を参照してください。