リクエスト認証¶
本サービスへのアクセスは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リクエストでは意味を持たないため省略した場合は空文字列となります。
リクエストのタイムスタンプ¶
クエリ文字列認証¶
クエリ文字列認証は、上記のAuthorizationヘッダーを使用する代わりに認証するための「署名」をURLのクエリパラメータに含めて認証する方法です。
この認証方法を利用することで、ウェブブラウザなどから本サービスのストレージに格納しているリソースに直接アクセスすることができます。
署名の作成方法¶
以下のリクエストを例に署名を作成する方法を説明します。
GET /sample.zip
Host: mybucket.storage-dag.iijgio.com
クエリ文字列認証には以下のクエリパラメータを使用します。
| パラメータ名 | 説明 |
|---|---|
| IIJGIOAccessKeyId | 認証するアカウントのアクセスキーID |
| Expires |
|
| Signature |
|
- 署名の作成のステップは以下の通りです。
以下に示す署名元となる文字列を作ります。
StringToSign = HTTP-VERB + "\n" + Content-MD5 + "\n" + Content-Type + "\n" + Expires + "\n" + CanonicalizedAmzHeaders + CanonicalizedResource;
例のリクエストの有効期限を2014年10月1日(2014-10-01T00:00:00)として作成すると以下のようになります。
GET\n \n \n 1412168119\n /mybucket/sample.zip
1で作成した文字列をUTF-8にエンコードし、アクセスキーIDに対応するシークレットアクセスキーを秘密鍵としてHMAC-SHA1ハッシュ値を取ります。
SignatureRaw = HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKey ), UTF-8-Encoding-Of( StringToSign ) )
2で生成された値をBase64方式でエンコードし、その値をさらにURLエンコードします。
Signature = URL-Encode( Base64( SignatureRaw ) );
- 例えば、
- アクセスキーIDが EXAMPLE0000000000000シークレットアクセスキーが ExampleSecretAccessKey000000000000000000の場合は Signature は以下の文字列になります。
37N5r3U0ZBr4Avh6B/rqZL7bftE%3D
作成した署名をURLに配置します。
https://mybucket.storage-dag.iijgio.com/sample.zip?Expires=1412168119&IIJGIOAccessKeyId=EXAMPLE0000000000000&Signature=37N5r3U0ZBr4Avh6B/rqZL7bftE%3D
