リクエスト認証

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

認証ヘッダー

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

シグネチャの内容

シグネチャ（Signature）の内容を以下に示します。

Authorization = "IIJGIO" + " " + IIJGIOAccessKeyId + ":" + Signature;

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

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

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

CanonicalizedHeaders = <described below>

CanonicalizedHeaders要素

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

実際の生成は以下の手順に従って行います。

全ての”x-iijgio-“または”x-amz-“で始まるヘッダーを小文字化します。
（例：x-IIJgio-MyHeader -> x-iijgio-myheader）
全ての”x-iijgio-“または”x-amz-“で始まるヘッダーを、ヘッダー名でソートします。
複数の同名ヘッダーを1つのヘッダーとして結合します。
（例: “x-iijgio-meta-username: fred”, “x-iijgio-meta-username: barney” -> “x-iijgio-meta-username: fred,barney”）
改行を含む連続した空白を単一の空白で置き換えます。
ヘッダー内のコロン（:）に隣接するスペースを削除します。
（例: “x-iijgio-meta-username: fred,barney” -> “x-iijgio-meta-username:fred,barney”）
結果リストの全てのヘッダーに改行（U+000A）を付加します。
CanonicalizedResource要素の生成は、このリストに含まれる全てのヘッダー文字列として連結して行います。

CanonicalizedResource要素

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

実際の生成は以下の手順に従って行います。

空文字列（”“）で始めます。
リクエストがHTTP Hostヘッダーを用いてバケットを指定してきた場合、”/”とバケット名を付加します。
（例: /BucketName）
復号化されていないHTTPリクエストURIのクエリストリングまで(クエリストリングは含まない)を追加します。
リクエストが[ ?location, ?acl]のようなサブリソースを含む場合、名前と値を加えます。(サブリソースが1つの場合)
サブリソースが複数の場合は辞書順に並べます。各サブリソースは”&”で区切られる必要があります。
（例: ”?acl&versionId=value”）
CanonicalizedResource要素の生成時に含まれるべきサブリソースのリストは以下のとおりです。
- acl
- location
- partNumber
- policy
- uploadId
- uploads
- website
- cors
- delete
- space
- traffic
GET Object で以下のパラメータをリクエストのクエリストリングに加えることで、レスポンスのヘッダを指定できます。
- response-content-type
- response-content-language
- response-expires
- response-cache-control
- response-content-disposition
- response-content-encoding
これらパラメータを指定する場合、CanonicalizedResource要素にパラメータの名前とその値を加える必要があります。他のサブリソースと同様 “&” で区切ります。順番は前述のサブリソースも含めて辞書順に並べます。ここでセットする値は、URLエンコードしないでください。

StringToSign要素

StringToSignの最初のいくつかのヘッダー（Content-Type, Date, Content-MD）は固定引数です。
StringToSignへはリクエストから固定引数の値だけを加えます(ヘッダー名は含みません)。
対照的に、”x-iijgio-“要素はヘッダー名と値がStringToSignに加えられます。
リクエスト内にStringToSign要素の固定引数のヘッダーが含まれていない場合、空文字列が代入されます。
例えば、Content-Type, Content-MD5は PUTリクエストでは任意のオプションで、GETリクエストでは意味を持たないため省略した場合は空文字列となります。

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

有効なタイムスタンプ（HTTPのDateヘッダー、またはx-iijgio-date）は認証リクエストに必須です。
さらに、クライアントのタイムスタンプもリクエストに含まれなければならなりません。
また、そのタイムスタンプは本サービスのシステム時間でリクエストを受け取ってから 15分以内でなければなりません。もしそうでない場合は、リクエストは失敗しRequestTimeTooSkewedエラーとなります。
これらは、第三者にリクエストを傍受され悪用されることを防ぐためです。より強固に傍受を防ぐには、認証後の通信にHTTPSを用いる必要があります。
いくつかのHTTPクライアントライブラリは、リクエストへ明示的にDateヘッダーをセットする事ができません。

CanonicalizedHeadersからDateヘッダーのトラブルに見舞われた際、代わりに”x-iijgio-date”ヘッダーまたは”x-amz-date”ヘッダーを用いてタイムスタンプを設定することができます。
“x-iijgio-date”ヘッダーはRFC2616のフォーマット（http://www.ietf.org/rfc/rfc2616.txt）に準拠します。
“x-iijgio-date”ヘッダーがリクエストに含まれている場合は、リクエストの署名を計算する際にDateヘッダーの要素は無視され、StringToSignのDateにはx-iijgio-dateヘッダーの要素を用います。

公開
マニュアル一覧へ

ご契約者向け
マニュアル一覧へ