リクエスト認証

本サービスへのアクセスはRESTベースのリクエストとして行なわれ、HTTPリクエストヘッダーに記述した認証ヘッダーにより正当性の検査が行なわれます。

認証ヘッダー

認証は、Authorizationヘッダーの内容により行なわれます。Authorizationヘッダーには、リクエスト内容の正当性を示すシグネチャを設定します。

シグネチャの内容

シグネチャ（Signature）の内容を以下に示します。
Authorization = "IIJGIO" + " " + IIJGIOAccessKeyId + ":" + Signature;

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );

StringToSign = HTTP-Verb + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;

CanonicalizedResource = [ "/" + Resource ] +
<HTTP-Request-URI, from the protocol name up to the query string> + [ sub-resource, if present. ];

CanonicalizedHeaders = <described below>

CanonicalizedHeaders要素

CanonicalizedHeaders要素は、リクエストに含まれる全てのヘッダーのうち、x-iijgio-から始まるもの全てから生成されます。

CanonicalizedHeaders要素の生成の手順は以下の通りです。

  1. 全ての”x-iijgio-“で始まるヘッダーを小文字化します。
    （例：x-IIJgio-MyHeader -> x-iijgio-myheader）

  2. 全ての”x-iijgio-“で始まるヘッダーを、ヘッダー名でソートします。

  3. 複数の同名ヘッダーを1つのヘッダーとして結合します。
    （例: “x-iijgio-meta-username: fred”, “x-iijgio-meta-username: barney” -> “x-iijgio-meta-username: fred,barney”）

  4. 改行を含む連続した空白を単一の空白で置き換えます。

  5. ヘッダー内のコロン : に隣接するスペースを削除します。
    （例: “x-iijgio-meta-username: fred,barney” -> “x-iijgio-meta-username:fred,barney”）
  6. 結果リストの全てのヘッダーに改行（ U+000A ）を付加します。
    CanonicalizedResource要素の生成は、このリストに含まれる全てのヘッダー文字列として連結して行います。

CanonicalizedResource要素

CanonicalizedResource要素は、リクエストの対象となる本サービスのリソースを表します。

CanonicalizedResource要素の生成の手順は以下の通りです。

  1. 空文字列（”“）で始めます。

  2. リクエストURLのパス部分を追加します。
  3. リクエストに含まれるサブリソースを追加します。

    • URLのクエリストリングと同様に、パス部分と?で区切ります。

    • サブリソースの値と名前は = で区切ります。
      • 値が無い（空白）の場合は=は含めません。

    • サブリソースが複数ある場合は辞書順（ABC順）でソートし、区切り文字に&を使用して列挙します。

    • 例:

      /SampleCluster/sampledb/sampletbl?table

CanonicalizedResource要素の生成時に含めるサブリソースのリストは以下のとおりです。
  • clusterManagement
  • database
  • table
  • query
  • select
  • split

StringToSign要素

StringToSign要素は、シグネチャを生成するためのソースとなる文字列です。

このStringToSign要素の生成にはCanonicalizedHeaders要素とCanonicalizedResource要素を使用しますので事前に生成しておく必要があります。

StringToSign要素の生成の手順は以下の通りです。

  1. HTTPのメソッド名、Content-Typeヘッダー、Dateヘッダーを改行それぞれの末尾に改行（ U+000A ）を付加し、連結します。
    • リクエストにContent-Typeヘッダーを含まない場合は空文字列が代入されます。

  2. CanonicalizedHeaders要素を追加します。

  3. CanonicalizedResource要素を追加します。

例として、以下のリクエストの場合に生成されるStringToSignを示します。

POST /v1/?select HTTP1.1
Host: analysis-dag.iijgio.com
Content-Type: application/json
Content-Length: 233
Date: Wed, 25 Nov 2009 12:00:00 GMT

StringToSign:

POST
application/json
Wed, 25 Nov 2009 12:00:00 GMT
/v1/?select

リクエストのタイムスタンプ

有効なタイムスタンプ（HTTPのDateヘッダー、またはx-iijgio-dateヘッダー）は認証リクエストに必須です。
さらに、クライアントのタイムスタンプもリクエストに含まれなければならなりません。
また、そのタイムスタンプは本サービスのシステム時間でリクエストを受け取ってから 15分以内 でなければなりません。もしそうでない場合は、リクエストは失敗しRequestTimeTooSkewedエラーとなります。
これらは、第三者にリクエストを傍受され悪用されることを防ぐためです。より強固に傍受を防ぐには、認証後の通信にHTTPSを用いる必要があります。
いくつかのHTTPクライアントライブラリは、リクエストへ明示的にDateヘッダーをセットする事ができません。
CanonicalizedHeadersからDateヘッダーのトラブルに見舞われた際、代わりに”x-iijgio-date”ヘッダーを用いてタイムスタンプを設定することができます。
“x-iijgio-date”ヘッダーはRFC2616のフォーマット（http://www.ietf.org/rfc/rfc2616.txt）に準拠します。
“x-iijgio-date”ヘッダーがリクエストに含まれている場合は、リクエストの署名を計算する際にDateヘッダーは無視されます。
もし”x-iijgio-date”ヘッダーを用いた場合、StringToSignのDateには空文字列を用います。

ページ先頭へ