CData Software Blog

クラウド連携のCData Software の技術ブログです。

Amazon Marketplace SP-API でIAMロールを利用してAPIアクセスを行う

こんにちは。CData Software Japanリードエンジニアの杉本です。

これまで3回に分けて、Amazon Marketplace SP-APIの使い方を解説してきました。

www.cdatablog.jp

www.cdatablog.jp

www.cdatablog.jp

初回でIAMユーザーを使ったAPIリクエスト方法を紹介したのですが、本文中でも述べている通り、Amazon Marketplace SP-APIのDeveloper GuideではIAMロールを使ったAPIリクエスト方法が推奨されています。

API連携の検証用途であれば、IAMユーザーで十分ですが、今回はドキュメントに則って、IAMロールによるアクセス方法を解説したいと思います。

事前準備の基本的な流れ

事前準備としてAWS側に必要な手順は以下の通りです。

  1. IAMユーザーの作成
  2. Amazon Marketplace SP-APIにアクセスするためのIAMポリシーの作成
  3. IAMユーザーに紐付いたIAMロールの作成:およびIAMポリシーの付与
  4. IAMユーザーにIAMロールをAssumeRoleするための権限を付与

その後、Amazon Sellar central でアプリクライアントの登録を行うのですが、その際に事前に生成したIAMロールの ARNを紐付けます。

手順

AWSアカウントの取得

最初にAWSアカウントを持っていない場合は、新しく準備しましょう。以下のURLからアカウントを取得できます。

aws.amazon.com

IAMユーザーの作成

AWSアカウントを取得したら、IAMユーザーを作成しましょう。

サービスの一覧から「IAM」に移動し

f:id:sugimomoto:20210511135022p:plain

「ユーザー」→「ユーザーを追加」をクリックします。

f:id:sugimomoto:20210511135028p:plain

任意のユーザー名を入力し、アクセスの種類として「プログラムによるアクセス」を選択して「次のステップ」に移動します。

f:id:sugimomoto:20210511135032p:plain

アクセス許可の設定はインラインポリシーとして後で付与するので、とりあえずそのまま「次のステップ」に移動します。

f:id:sugimomoto:20210511135039p:plain

任意でタグを設定します。

f:id:sugimomoto:20210511135046p:plain

これでユーザー情報の設定はOKです。「このユーザーにはアクセス権限がありません」と表示されますが、そのまま「ユーザーの作成」をクリックしてOKです。

f:id:sugimomoto:20210511135053p:plain

作成が成功すると、IAMユーザーのアクセスキーIDとシークレットアクセスキーが表示されます。APIアクセスの時に使用するので、控えておきましょう。

f:id:sugimomoto:20210519175140p:plain

ユーザーのARNの取得

併せてユーザーのARNという識別子を作成したIAMユーザーの画面から取得します。

f:id:sugimomoto:20210519175145p:plain

ポリシーの作成

続いてポリシーを作成します。

以前の記事でも紹介した通り、APIアクセスには以下のexecute-apiに対するアクセス権限が必要です。この権限を持つポリシーを作成して、ロールに紐付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:*:*:*"
    }
  ]
}

「ポリシー」から「ポリシーの作成」をクリックし

f:id:sugimomoto:20210519175153p:plain

JSON形式で以下の設定を貼り付けて「ポリシーの確認」をクリックします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:*:*:*"
    }
  ]
}

f:id:sugimomoto:20210519175159p:plain

タグは任意で設定してください。

最後にポリシーの名前を設定して、「ポリシーの作成」をクリックします。

f:id:sugimomoto:20210519175205p:plain

IAMロールの作成

ポリシーを作成したらロールも追加します。

「ロール」から「ロールの作成」をクリックし

f:id:sugimomoto:20210519175212p:plain

「別のAWSアカウント」を選択して、事前に作成したIAMユーザーのアカウントID(ARNに含まれている数値12桁)を入力します。

f:id:sugimomoto:20210519175219p:plain

次にアクセス権限ポリシーを指定するので、先程の手順で作成したポリシーを検索して設定します。

f:id:sugimomoto:20210519175224p:plain

タグは任意で指定してください。

あとは任意のロール名を指定して、「ロールの作成」をクリックします。

f:id:sugimomoto:20210519175231p:plain

ユーザーにAssumeRoleのポリシーを追加

IAMロールの作成が完了しましたが、これだけではこのロールをユーザーが利用することはできません。

なぜならそのロールを利用するための権限をユーザーが持っていないためです。そこで対象のIAMユーザーの画面に戻って、ポリシーを追加します。

f:id:sugimomoto:20210519175238p:plain

必要な権限は「sts:AssumeRole」というアクションです。この対象リソースとして先程作成したIAMロールを指定して、ポリシーを作成します。

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect":"Allow",
        "Action":"sts:AssumeRole",
        "Resource":"arn:aws:iam::220139336512:role/AmazonSPAPISampleRole"
    }
}

f:id:sugimomoto:20210519175244p:plain

f:id:sugimomoto:20210519175251p:plain

これでAWS側の準備は完了です。

Amazon Seller Central でアプリクライアントを追加する

続いてAmazon Seller Central 側でAPIアクセス用のアプリクライアントを追加します。

この部分からは基本的に以下の記事で紹介している手順を同じです。ただし、アプリクライアントに入力する「IAM ARN」だけ異なるので注意しましょう。

www.cdatablog.jp

Amazon Seller Central にログインし「アプリの開発」をクリックします。

f:id:sugimomoto:20210511135143p:plain

「新しいアプリクライアントを追加」をクリックし

f:id:sugimomoto:20210511135148p:plain

以下のようにアプリの情報を入力します。

前述したように、IAM ARNにはIAMロールのARNを指定します。

プロパティ名 備考
アプリ名 例)SampleSPAIApp 任意のアプリ名を入力してください。作成したアプリを外部公開する場合は表示名となりますので要注意。
APIタイプ SP API MWS APIと併用する場合は両方付与することができます。
IAM ARN arn:aws:iam::220139336512:role/AmazonSPAPISampleRole 事前に作成したIAMロールのARNを入力します。
サポートされている企業 利用したいパートナータイプにチェックを入れます。 今回は出品者として注文データなどを取得するので、「出品者」にチェックを入れます。
ロール 利用したいAPI機能にチェックを入れます。 今回は注文データを取得しようと思っているので「在庫と注文の追跡」だけ入れればOKです。検証用であれば全部チェックを入れておいて良いでしょう。
OAuthログインURI (空) 前述の通り今回は利用しません。

f:id:sugimomoto:20210519175302p:plain

作成完了後、LWA認証情報と

f:id:sugimomoto:20210519175308p:plain

リフレッシュトークンを生成して控えておきましょう。

f:id:sugimomoto:20210519175314p:plain

APIの使い方

それではPostmanを使って、APIアクセスを行ってみましょう。

基本的な流れは以前紹介した以下の記事に近いですが、間にAssumeRoleを行っています。

www.cdatablog.jp

AccessTokenの取得

最初にAccessTokenを取得します。

ここの手順は以前Blogで紹介したものと変わりないので、下記リンクを参照してみてください。

www.cdatablog.jp

AssumeRoleの実行

続いて、作成したAMIユーザーのAccessKeyとSecretKeyを使って、AssumeRoleを実行し、IAMユーザーにロールを付与します。

AssumeRoleをPostmanから実行する方法は以下のBlog記事で詳しく解説しています。

www.cdatablog.jp

f:id:sugimomoto:20210519175324p:plain

リクエストを行うと、以下のように一時的なAccessKeyとSecretAccessKey、そしてSessionTokenが取得できます。

<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
    <AssumeRoleResult>
        <AssumedRoleUser>
            <AssumedRoleId>XXXXXX:XXXXXXX</AssumedRoleId>
            <Arn>arn:aws:sts::XXXXX:assumed-role/XXXXXX/XXXXX</Arn>
        </AssumedRoleUser>
        <Credentials>
            <AccessKeyId>XXXXXXX</AccessKeyId>
            <SecretAccessKey>XXXXXX</SecretAccessKey>
            <SessionToken>XXXXXXX</SessionToken>
            <Expiration>2021-05-13T01:49:13Z</Expiration>
        </Credentials>
    </AssumeRoleResult>
    <ResponseMetadata>
        <RequestId>XXXX</RequestId>
    </ResponseMetadata>
</AssumeRoleResponse>

注文APIにアクセスする

最後に実際のAmazon SP-APIAPIリクエストを行います。

まず、先程AssumeRoleで取得したAccessKeyとSecretAccessKey、そしてSessionTokenを使って、AWS Signatrueを施します。

f:id:sugimomoto:20210519175331p:plain

あとは、取得しておいたAccessTokenを「x-amz-access-token」に設定することで、リクエストを行うことができます。

f:id:sugimomoto:20210519175338p:plain

最終的に生成されるリクエストは以下のようなイメージです。

GET /orders/v0/orders?MarketplaceIds=A1VC38T7YXB528&CreatedAfter=2020-01-01 HTTP/1.1
Host: sellingpartnerapi-fe.amazon.com
x-amz-access-token: Atza|IwEBXXXXXX
user-agent: My Selling Tool/2.0 (Language=Java/1.8.0.221;Platform=Windows/10)
X-Amz-Security-Token: IQoJb3JpZ2lXXXXXX
X-Amz-Date: 20210519T083949Z
Authorization: AWS4-HMAC-SHA256 Credential=XXXXXXX/20210519/us-west-2/execute-api/aws4_request, SignedHeaders=host;x-amz-access-token;x-amz-date;x-amz-security-token, Signature=XXXXXXX

これで、注文データが無事取得できました。

おわりに

この手順を通して見ていくと、AssumeRoleで生成されるAccessKeyなどと、AccessToken・RefreshTokenの管理がかなり面倒ですよね。

最初の記事のようにIAMユーザーオンリーでAPIリクエストも可能なので、ユースケースに合わせて利用アプローチを検討してみてください。