METRICS（メトリクス）監視と収集におけるOAuth設定と認証設定について

ホーム
LogStare Collector リファレンス
METRICS（メトリクス）監視と収集におけるOAuth設定と認証設定について

2021.01.19

この記事は投稿日から2年以上経過しています。

当記事では、METRICS（メトリクス）監視と収集におけるOAuth設定と認証設定について記載します。

更新履歴

2022/12/28　OAuthのBasic認証設定とOAuth2.0のclient-credentials認証設定例を掲載しました。
タイトルを「METRICS（メトリクス）監視と収集におけるOAuth設定と認証設定について」に変更しました。

対象バージョン

LogStare Collector v2.1.0build210215以降のバージョン

LSCにおけるOAuth認証とは…

OAuthは、クライアントとサーバー間で特定の通信処理を行う際に予めサーバーから受け取った「アクセストークン」をクライアントが通信処理の度にサーバーへ渡す仕組みです。「アクセストークン」は、クライアントが通信処理を行う前にパスワード等の情報(クレデンシャル)を使って認証された後にサーバー（又はトークンを発行する専用のサーバー）からクライアントへ発行されます。

また「アクセストークン」には有効期限があり、一般的には1時間や24時間など短く設定しています。有効期限が切れた後はトークンの再発行（リフレッシュ）を受けるための要求を行います。

LSCでは基本的にOAuth2.0(「アクセストークン」の要求方法とその応答方法を標準化したもの)をベースに「アクセストークン」の発行を受けて、それを利用した通信処理を行います。

LSCにおける「アクセストークン」の発行時に利用する認証方式には、「Basic認証(基本認証)」または「Client-Credentialsによる認証(利用するREST APIで決められたパスワードやユーザー名などの認証情報をJSON形式にしてサーバーへ通知し認証を受ける認証方式)」を選択することができます。

どちらが使えるかについては、監視対象デバイス側のマニュアルやREST API仕様をご確認ください。REST APIがOAuth2.0に対応している場合は基本的にBasic認証を利用することが可能です。

LSCにおけるOAuthのBasic認証設定例と動作概要

例えば、利用する予定のREST APIの仕様として、OAuth2.0のBasic認証がサポートされている場合は下記のようにLSCの設定画面で設定を行うことができます。

例：【METRICS（メトリクス）収集の設定 Basic Auth】認証使用：「Basic Auth」
REST API：https://xxxxxxxxxxxx/dna/intent/api/v1/issues
Access Token URL： https://xxxxxxxxxxxxxx/api/system/v1/auth/token
Key「ログインID」：Value「admin」
Key「パスワード」：Value「**********」

この例では、認証使用に「Basic Auth」、REST APIに今回利用するREST APIのURLを入力しています。Access Token URLは認証処理と「アクセストークン」を発行するURLを入力しています。
Key「ログインID」とKey「パスワード」に予め監視対象デバイス側に設定しておいた値を入力しています。

また、Basic認証では「OAuth2.0 client-credentials」を選択して下記のように設定することも可能です。
上記の内容を踏まえたLSC側の設定は下記の通りとなります。

例：【METRICS（メトリクス）収集の設定 OAuth2.0 client-credentials】認証使用：「OAuth2.0 client-credentials」
REST API：https://xxxxxxxxxxxx/dna/intent/api/v1/issues
Access Token URL： https://xxxxxxxxxxxxxx/api/system/v1/auth/token
「Authorization Header(opt)」：　Key「ログインID」：Value「admin」
Key「パスワード」：Value「**********」
application/x-www-form-urlencoded：空白（値無し）

上記２つのように設定をした場合、LSCの設定画面下にあるテストボタン又は実際の通信処理を行う初回の要求時にヘッダー情報として、Key「Authorization」Value「 Basic 設定頂いたログインID「admin」パスワード「**********」を組み合わせてBase64エンコードした値」が入ります。

LSC側におけるREST API POST時は下記のようなPOST例となります。

dataType:'json',
headers: {
Authorization: "Basic dGVzdDpwYXNzd2Q="

その後、Basic Auth認証で承認後、次回のアクセス時にはLSC側でヘッダー情報としてKey「Authorization」Value「Bearer 承認時に受け取ったアクセストークン」が入ります。LSC側におけるREST API POST時は下記のようなPOST例となります。

dataType:'json',
headers: {
Authorization: 'Bearer eyJhbGciOiJIUzI1NiJ9.yJpYXQiOjE1MDI4MzU5OTEsInN1YiI6ImFq'
}

テストボタンを押した後、うまく認証が通らない場合は、監視対象デバイス側でBasic認証の設定がされていること、ユーザーID・パスワード等をご確認ください。その状態でもうまく行かない場合は、対象機器側でBasic Authでは無く、クレデンシャルを用いた認証方式（OAuth2.0 client-credentials）での設定を行っていただき、その情報を設定してください。

LSCにおけるOAuthのOAuth2.0 client-credentials設定例と動作概要

例えば、利用する予定のREST APIの仕様として、クレデンシャルを用いた認証方式がサポートされている場合は下記のようにLSCの設定画面で設定を行うことができます。

例：【METRICS（メトリクス）収集の設定 OAuth2.0 client-credentials】

認証使用：「OAuth2.0 client-credentials」
REST API：https://xxxxxxxxxxxx/dna/intent/api/v1/issues
Access Token URL： https://xxxxxxxxxxxxxx/api/system/v1/auth/token
「Authorization Header(opt)」：　Key「ログインID」：Value「空白（値無し）」
Key「パスワード」：Value「空白（値無し）」
application/x-www-form-urlencoded：Key「grant_type」: Value「password」,
　　　　　　　　　　　　　　　　　　 Key「username」: Value「admin（ユーザー名などクレデンシャル情報）」,
　　　　　　　　　　　　　　　　　　 Key「password」: Value「Admin123（パスワードなどクレデンシャル情報）」

この例では、認証使用に「OAuth2.0 client-credentials」、REST APIに今回利用するREST APIのURLを入力しています。Access Token URLは認証処理と「アクセストークン」を発行するURLを入力しています。

「Authorization Header(opt)」は空白（値無し）、「Content-type:application/x-www-form-urlencoded」にチェックを入れて、Key「grant_type」、Key「username」、Key「password」にそれぞれ予め監視対象デバイス側に設定しておいた値を入力しています。

このKeyの名前については、利用する予定のREST APIの仕様にあわせて入力します。OAuth2.0ではこのクレデンシャルを用いた認証におけるKeyの名前は定義していないため、各REST API仕様を参照頂く必要があります。

設定例のイメージとしては下記のようなKeyとValueになります。これらのKey・Value値の詳細についてはCiscoのマニュアル等をご覧ください。

上記のように設定をした場合、LSCの設定画面下にあるテストボタン又は実際の通信処理を行う初回の要求時にヘッダー情報としてこれらの情報がサーバーに送られます。

LSC側におけるREST API POST時は下記のようなPOST(URLエンコードされた文字)例となります。

password%3Dadmin%26username%3Dadmin%26password%3DAdmin123

その後、クレデンシャルを用いた認証で承認後、次回のアクセス時にはBasic認証と同様にLSC側でヘッダー情報としてKey「Authorization」Value「Bearer 承認時に受け取ったアクセストークン」が入ります。LSC側におけるREST API POST時は下記のようなPOST例となります。

dataType:'json',
headers: {
Authorization: 'Bearer eyJhbGciOiJIUzI1NiJ9.yJpYXQiOjE1MDI4MzU5OTEsInN1YiI6ImFq'
}

※Basic認証と同じです

また、「Content-type:application/x-www-form-urlencoded」では無く、「Content-type:application/json」を指定するケースがあり、その際は下記のように設定します。

例：【METRICS（メトリクス）収集の設定 OAuth2.0 client-credentials】

application/json：
{
"grant_type": "password",
"username": "admin",
"password": "Admin123"
}

上記のように設定した場合は、LSC側におけるREST API POST時は下記のようなPOST例となります。

dataType:'json',
{
"grant_type": "password",
"username": "admin",
"password": "Admin123"
}

※これらの値はURLエンコードされずに、POSTデータとして送信されます。

このヘッダー「Authorization」に対する値として、「Bearer」のあとに「アクセストークン」をつけて通信処理を行う方式（Bearer認証）は、OAuth2.0の仕様内で参照されている方式となります。

利用する予定のREST API仕様において、例えば「アクセストークン」が「X-Auth-Token」のような独自のヘッダーの後ろに付けて通信処理を行う必要がある場合があります。このように独自のヘッダーに対して「アクセストークン」を付ける機能については、今のところLSC側には無く、基本的にはMicrosoft社やGoogle社などで広く一般的に用いられているRFC6749(OAuth2.0)及びRFC6750(Bearer Token)にて既定された仕様を利用した通信となります。

OAuth2.0認証を利用した一例としてAzureVMのステータス監視があります。
詳しい設定方法については以下の記事をご参照ください。
メトリクス監視を利用した特定のAzureVMのステータス監視について

使用方法

「認証仕様」から「OAuth2.0 client-credentials」を選択します。
認証情報を設定します。
① アクセストークンを取得する認可サーバのURLを指定します。
② 「ClientID」「ClientSecret」「GrantType」等を設定します。
※②については①へリクエストする際に利用する「Content-Type」に合わせて以下を設定します。
- 「Content-Type: application/x-www-form-urlencoded」
  左のテキストボックスにKey名を右のテキストボックスに対応する値を設定します。
  必要な個数の認証情報を設定します。
- 「Content-Type: application/json」
  json形式で認証情報を設定します。