エフサステクノロジーズ株式会社

本ページの製品は2024年4月1日より、エフサステクノロジーズ株式会社に統合となり、順次、切り替えを実施してまいります。一部、富士通表記が混在することがありますので、ご了承ください。

ONTAP 9.14

to English version

許可サーバーとアクセス トークン

許可サーバーは、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は、ファイアウォールの内側にある可能性があります。この場合は、設定の際にプロキシを指定する必要があります。

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

ONTAPに許可サーバーを定義する際には、CLI、ONTAP System Manager、REST APIなど任意の管理インターフェイスを使用できます。たとえば、CLIではsecurity oauth2 client createコマンドを使用します。

許可サーバーの数

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

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

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

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

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

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

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

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

  • OAuth 2.0のグラント タイプ

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

グラント タイプ

グラントとは、OAuth 2.0アクセス トークンの要求と受領に使用される明確に定義されたプロセスです。一連のネットワーク フローもこれに含まれます。クライアント、環境、セキュリティの要件に応じて、さまざまなグラント タイプを使用できます。次の表は、よく利用されるグラント タイプをまとめたものです。

グラント タイプ 説明

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

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

パスワード

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

許可コード

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

JWTのコンテンツ

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

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

クレーム キーワード 説明

Issuer

iss

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

Subject

sub

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

Audience

aud

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

Expiration

exp

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

詳細については、RFC 7519:『JSON Web Token』を参照してください。

Top of Page