認証サーバとアクセストークン
変更を提案
PDF
認可サーバーは、OAuth 2.0 Authorizationフレームワーク内の中心的なコンポーネントとしていくつかの重要な機能を実行します。
OAuth 2.0認可サーバ
認証サーバは、主にアクセストークンの作成と署名を行います。これらのトークンには、クライアントアプリケーションが保護されたリソースに選択的にアクセスできるように、IDおよび承認情報が含まれています。これらのサーバは通常、相互に分離されており、スタンドアロンの専用サーバとして、またはより大きなIDおよびアクセス管理製品の一部として、いくつかの異なる方法で実装できます。
|
OAuth 2.0の機能がより大きなIDおよびアクセス管理製品またはソリューション内にパッケージ化されている場合は特に、認可サーバーに異なる用語が使用されることがあります。たとえば、*アイデンティティプロバイダ（IdP）*という用語は、*認証サーバ*と同じ意味でよく使用されます。 |
管理
アクセストークンの発行に加えて、認可サーバーは一般的にWebユーザーインターフェイスを介して関連する管理サービスも提供します。たとえば、次の項目を定義および管理できます。
-
ユーザおよびユーザ認証
-
スコープ
-
テナントとレルムによる管理の分離
-
ポリシーの適用
-
さまざまな外部サービスへの接続
-
その他のIDプロトコル（SAMLなど）のサポート
ONTAPは、OAuth 2.0標準に準拠した認可サーバーと互換性があります。
ONTAPニテイキ
1つ以上の認可サーバをONTAPに定義する必要があります。ONTAPは、各サーバとセキュアに通信してトークンを検証し、クライアントアプリケーションをサポートするその他の関連タスクを実行します。
ONTAP構成の主な側面を以下に示します。詳細については、も参照してください"OAuth 2.0の導入シナリオ"。
アクセストークンを検証するには、2つのオプションがあります。
-
ローカル検証
ONTAPは、トークンを発行した認可サーバーから提供された情報に基づいて、アクセストークンをローカルで検証できます。認証サーバから取得された情報はONTAPによってキャッシュされ、定期的に更新されます。
-
リモートイントロスペクション
リモートイントロスペクションを使用して、認証サーバーでトークンを検証することもできます。イントロスペクションは、許可された当事者がアクセストークンについて認可サーバーに問い合わせることを可能にするプロトコルです。ONTAPは、アクセストークンから特定のメタデータを抽出し、トークンを検証する方法を提供します。ONTAPは、パフォーマンス上の理由から一部のデータをキャッシュします。
ONTAPはファイアウォールの背後にある可能性があります。この場合は、設定の一部としてプロキシを指定する必要があります。
ONTAPに対する認証サーバは、CLI、System Manager、REST APIなどの任意の管理インターフェイスを使用して定義できます。たとえば、CLIではコマンドを使用し `security oauth2 client create`ます。
1つのONTAPクラスタに対して最大8つの許可サーバを定義できます。発行者または発行者/オーディエンスの要求が一意である限り、同じ認証サーバを同じONTAPクラスタに複数回定義できます。たとえば、Keycloakでは、異なるレルムを使用する場合は常にこのようになります。
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機能が拡張され、ネイティブのエントラIDグループ用のエントラID固有の拡張機能が含まれるようになりました。これには、名前の代わりにアクセストークンでGUIDを使用する必要があります。さらに、このリリースでは、アクセストークンの「roles」フィールドを使用してネイティブアイデンティティプロバイダのロールをONTAPのロールにマッピングするための外部ロールマッピングのサポートが追加されています。
ONTAP 9 .14.1
ONTAP 9 .14.1以降では、を使用するアプリケーションの次の標準OAuth 2.0機能を通じて、認証サーバがサポートされています。
-
およびで説明されているように、「ISS」、「AUD」、および "RFC 7519：JSON Webトークン（JWT）"「exp」を含む標準フィールドを持つOAuth 2.0 "RFC6749: 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認可タイプ
-
要求の発行に使用するクライアントまたはソフトウェアツール
付与タイプ
a_grant_は、OAuth 2.0アクセストークンの要求と受信に使用される、ネットワークフローのセットを含む明確に定義されたプロセスです。クライアント、環境、およびセキュリティの要件に応じて、いくつかの異なる権限付与タイプを使用できます。一般的な付与タイプの一覧を以下の表に示します。
| 付与タイプ | 説明 |
|---|---|
クライアントクレデンシャル |
クレデンシャル（IDや共有シークレットなど）のみを使用する一般的な付与タイプ。クライアントは、リソース所有者と密接な信頼関係を持っていると想定されます。 |
パスワード |
リソース所有者パスワード資格情報付与タイプは、リソース所有者がクライアントとの信頼関係を確立している場合に使用できます。また、レガシーHTTPクライアントをOAuth 2.0に移行する場合にも役立ちます。 |
認証コード |
これは機密クライアントにとって理想的な認可タイプであり、リダイレクトベースのフローに基づいています。アクセストークンとリフレッシュトークンの両方を取得するために使用できます。 |
JWTの内容
OAuth 2.0アクセストークンはJWT形式です。コンテンツは、設定に基づいて認可サーバによって作成されます。ただし、トークンはクライアントアプリケーションには不透明です。クライアントには、トークンを検査したり、コンテンツを認識したりする理由はありません。
各JWTアクセストークンには、クレームのセットが含まれています。クレームは、発行者の特性と認可サーバーでの管理定義に基づいた認可を記述します。この規格に登録されている請求の一部は、次の表に記載されています。すべての文字列で大文字と小文字が区別されます。
| 請求 | キーワード | 説明 |
|---|---|---|
発行者 |
ISS |
トークンを発行したプリンシパルを識別します。請求処理はアプリケーション固有です。 |
件名 |
サブ |
トークンのサブジェクトまたはユーザ。名前のスコープは、グローバルまたはローカルで一意になります。 |
対象読者 |
豪ドル |
トークンの対象となる受信者。文字列の配列として実装されます。 |
有効期限 |
有効期限 |
トークンが期限切れになり、拒否されるまでの時間。 |
詳細については、を参照してください "RFC 7519：JSON Webトークン" 。