Category: Mobile Services*


AWS AppSyncの紹介 – リアルタイムおよびオフライン機能を備えたデータ駆動型アプリケーションの構築

現在、モバイルデバイスや便利なアプリケーションは私達の生活にとって欠かせないものになっています。モバイルデバイスへの依存が高まるにつれ、私たちの注目を集めて何百万ものアプリケーションが爆発的に増加しています。これはモバイルデベロッパーにとって、高品質かつリアルタイムなユーザーが求めるアプリケーションを構築する必要があることを意味します。これにより、モバイルアプリケーションは、ユーザー間でのデータ同期、オフラインサポート、データディスカバリーなどの機能が実装されていることが必須になってきています。いくつかの記事、(InfoQDZone、モバイル開発ブログAlleviateTech)によると前述の機能を提供するうえで重要な要素の1つはクラウド型モバイルアプリケーションと言われています。 モバイルデータの同期やデータストレージなどに関しては特にこれが言えるようです。

このような背景から、クラウド上のデータ集約サービスを使って革新的なモバイルアプリケーションを開発するための新サービスを発表するのに最適なタイミングだと考え、AWS AppSync を紹介します。AWS AppSync は、フルマネージドなサーバーレスGraphQL サービスで、リアルタイムデータクエリ、同期、通信、およびオフラインプログラミングの機能を提供します。使い慣れていない人たちのために、GraphQL 仕様に関する情報を簡単に紹介しましょう。 (more…)

AWS Mobile Hub で JavaScript 開発を改善する

はじめに

JavaScript エコシステムが成長していくなかで、私達はモバイルおよびハイブリットアプリを構築するお客様を支援する取り組みを続けています。本日、 AWS Mobile Hub に Hosting and Streaming 機能をリリースしました。この機能は、Amazon S3 と Amazon CloudFront を使用するモバイル Web サイトのテスト及びプロダクション環境へのデプロイを自動化します。また、標準設定ファイルと SDK を使用する際の設定ワークフローを簡略化します。

この新しい機能によって、 JavaScript 開発者は事前設定された AWS アーキテクチャを起動したり、 Mobile Hub プロジェクトをビルドできます。また、集中管理された設定と事前ダウンロードされた SDK を使用して、ワンクリックでグローバル Web サイトを作成できます。

(more…)

Amazon Cognito ユーザープールが SAML フェデレーションをサポート [パブリックベータ]

昨年、Amazon Cognito Identity に SAML フェデレーションのサポートを追加しました。この機能は SAML レスポンスから一時的な AWS クレデンシャル情報を取得できます。 Amazon Cognito Identity は API ベースのアプローチをサポートしており、AWS クレデンシャル情報を取得するためには、SAML IdP (Identity Provider) の SAML 応答を解析し、Amazon Cognito Identity API をコールします。

Amazon Cognito ユーザープールは、あなたのモバイルおよび Web アプリに、セキュアでスケーラブルなユーザーディレクトリを使用したサインアップおよびサインイン機能を追加します。本日、Amazon Cognito ユーザープールの SAML IdP (Identity Provider) フェデレーションをアナウンスできることを嬉しく思います。本機能はユーザーディレクトリに SAML IdP のユーザーをマッピングし、 SAML IdP でユーザーを認証後にユーザープールから標準認証トークンを取得します。ユーザープールは SAML 2.0 POST Binding エンドポイントをサポートします。これにより、クライアントは SAML アサーションレスポンスの解析が不要になり、ユーザープールはユーザーエージェント (訳注: Web ブラウザ等) を介して IdP から直接 SAML レスポンスを受信します。

SAML フェデレーション機能の一つとして、ユーザープールはアプリの代わりに service provider (SP) として機能します。ユーザープールはアプリの単一のアイデンティティ管理ポイントになります。そのため、アプリは複数の SAML IdP を統合する必要はなくなります。 Amazon Cognito コンソールを利用して複数の SAML IdP を追加し、属性のマッピングを定義することで、すぐに利用を開始できます。

(more…)

サーバレス JavaScript アプリケーションで SAML: Part I

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。

このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。


SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。

エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。

この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito のユーザプールと認証連携させ、独自のマネージドユーザディレクトリを作成することもできます。

例えば、ユーザが Active Directory Federation Services (ADFS) で認証する事ができる JavaScript アプリケーションを構築したいかもしれません。ユーザは AWS 認証情報で許可された範囲で API を呼び出して得た情報をアプリケーションに表示させたり、DynamoDB テーブルに書き込むことができます。AWS Mobileブログの記事「Announcing SAML Support for Amazon Cognito」では、新しい SAML 機能について Java、Android、iOS のサンプルコード付きで紹介しました。この記事では、ADFS フローのカスタマイズについて JavaScript のサンプルを交えて詳細に紹介します。

シナリオ

この記事では、クライアント側のフローを紹介します。SAML アサーションは Amazon API Gateway 経由で渡され、ブラウザ上のコードは Amazon Cognito Identity から直接認証情報を受け取ります。次回のブログ記事では、バックエンド側の処理を紹介します。SAML アサーションと認証情報は、AWS Lambda ファンクション内で処理でき、ビジネスロジックを実現するようカスタマイズしたり監査履歴を取ったりする事ができます。

このシナリオの全コードは SAM テンプレート含め、GitHub の samljs-serverless-sample レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。

サーバレスのアーキテクチャとなっていますが、ADFS との連携は従来のコンピュート サービスである EC2 インスタンスのようなコンポーネントで置き換えることもできます。ADFS の用語や定義については「Claims-based identity term definitions」を参考にして下さい。

前提条件

このブログ記事では、ADFS が動作している環境が必要です。以下の事を実施して下さい。:

  1. AWS コンソールで ADFS との認証連携を設定。「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」を AWS CloudFormation テンプレートと共に参考にしてください。
  2. サインインページ(https://localhost/adfs/IdpInitiatedSignOn.aspx)からユーザ example\bob が ADFS-Dev と ADFS-Production の両方のグループとして認証出来ることを確認します。
  3. Amazon Cognito Identity のプールを作成します。

ADFS 設定の概要

チュートリアルを始める前に、幾つか AWS と SAML の設定を確認しましょう。まず、前提条件にある通り IAM ロールが作成されているかから確認して下さい。アプリケーション用に新しく IAM ロールと AD グループを作成してもかまいません。この記事では、「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」の記事の通り ADFS-Dev と ADFS-Production を利用します。

  1. IAM コンソールで、ロールを選択し ADFS-Ddev を選択し、信頼関係 (Trust Relationships) のタブを開き、以下のコードのようになっている事を確認します。:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::YOURACCOUNTNUMBER:saml-provider/ADFS"
          },
          "Action": "sts:AssumeRoleWithSAML",
          "Condition": {
            "StringEquals": {
              "SAML:aud": "https://signin.aws.amazon.com/saml"
            }
          }
        }
      ]
    }

このポリシーは “ADFS” という SAML IdP で認証されたユーザがロールを引き受ける事を許可しています。また、ポリシーには条件が含まれており、SAML アサーション内の AudienceRestriction が https://signin.aws.amazon.com/ である事となっています。SAML アサーションは ADFS から AWS に HTTP POST で SAMLResponse というヘッダとして送られて来ます。前提条件に記載されている設定が実施済みであれば、ADFS コンソールでは以下のように設定されており、利用者(Ralying Party)の URL として AWS メタデータ URL が指定されています。詳細については、「認証レスポンスの SAML アサーションを設定する」を確認して下さい。



認証後、ADFS は利用者のアプリケーションに自動的にリダイレクトします。

上記のスクリーンショットでは、認証後の SAMLResponse の値を見るために Chrome を利用しました。「トラブルシューティングのためにブラウザで SAML レスポンスを表示する方法」に記載されているとおり、他のブラウザでも同様のことを行えます。SAMLResponse を貼り付ければ、Audience、Roles や Destination などの値を見ることができる “SAML Decoder” がインターネット上にあります。パート 2 のブロク記事では、これをプログラムで行う方法を紹介します。

ADFS からサーバレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

この1つ目のブログのシナリオの方が難しくありません。多くの組織での要件にベストな流れとなっています。ユーザは ADFS で認証して Amazon Cognito から AWS 認証情報を受け取り、アプリの中でアクションを行えます。このサンプルアプリケーションは:

  1. ADFS で認証するログイン メカニズムを変更して取り出すことで、SAMLResponse ヘッダを取り出します。ユーザが S3 上に配置されたウェブサイトを訪問した際に、自動的にこの仕組みが行われます。
  2. ADFS-Dev ロールの信頼ポリシーを変更し、Active Directory の AWS-gDev グループのメンバであれば Amazon Cognio から一時的な認証情報を受け取れるようにします。
  3. ユーザのロールを選択するコードをアプリケーションの中に組み込みます。このブログ記事では、ADFS-Dev ロールを選択します。

参考までに、AWS Console への認証連携の場合 #3 と同様の内容は、ADFS のウェブページ IdpInitiatedSignOn.aspx からリダイレクトされた後にラジオボタンでロールをクリックして選択する事で実現されます。より詳しい内容については、セキュリティブログの「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」をご覧下さい。もしユーザが 1 つの Active Directory グループのメンバだけであれば、SAMLResponse には複数のロールが含まれておらず、その場合は #3 は省略されます。構成は以下の図のとおりとなります。

チュートリアル: ADDFS からサーバーレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

まず、サーバレス Web サイトをセットアップし、認証情報を取得するログインフローを開始させます。シングル Web アプリを配置するのには S3 を使用します。

S3 バケットの作成

  1. S3 のコンソールで、「バケットを作成」を選択して一意なバケット名を入力します。以下の例では “serverlessweb” としますが、皆様は何か他の名前として下さい。
  2. バケットを作成後、詳細設定のページで「プロパティ」を選び、「バケットポリシーの編集」をクリックします。
  3. 以下のポリシーを設定して下さい。YOURBUCKETNAMEGOESHERE は置き換えて下さい。このポリシーは、バケットに入っている HTML や JavaScript などのファイルを誰でも GET リクエストを行えるようにします。Web サイトにアクセスすると Web ブラウザは GET リクエストを発行し、このポリシーがリソースの読み込みをユーザに許可します。
    {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "PublicReadForGetBucketObjects",
              "Effect": "Allow",
              "Principal": "*",
              "Action": "s3:GetObject",
              "Resource": "arn:aws:s3:::YOURBUCKETNAMEGOESHERE/*"
          }
      ]
    }
  4. 「静的ウェブサイトホスティング」を選択し、「ウェブサイトのホスティングを有効にする」とします。フォームに「index.html」と「error.html」を入力します。

  5. 次に、HTML ファイルをバケットに追加して、https://YOURBUCKETNAME.s3-website-REGION.amazonaws.com をブラウザで開きページが見れるか確認します(YOURBUCKETNAME と REGION は読み替えて下さい。)。まずは以下の HTML をテンプレートとして使って下さい。
    <!DOCTYPE html>
    <html>
     <head>
      <title>
       Amazon Cognito SAML Example
      </title>
      <script src="aws-sdk.min.js">
      </script>
     </head>
     <body>
      <h1>
       Testing SAMLResponse
      </h1>
     </body>
    </html>
      
  6. JavaScript SDK から圧縮(Minify)されたバージョン aws-sdk.min.js をダウンロードして、HTML ファイルと同様にバケットに保存し、エラー無くロードできることを確認します。

(オプション) CloudFront ディストリビューションのセットアップ

次に進める前に、さらにもう1つセットアップしたいと思います。CloudFront ディストリビューションです。S3 静的 Web ホスティングに CloudFront やその他の CDN を使用することで、独自ドメイン名で SSL を使用することができるようになります。

API Gateway から HTTP サイトにリダイレクトする事もできるため強制ではありませんが、Web サイトや認証や認可のシステムはエンドツーエンドで HTTPS を使うべきです。以下がセットアップで行う内容です。

  1. CloudFront コンソールで、Web タイプのディストリビューションを作成します。
  2. 「Viewer Protocol Policy」には、「HTTPS Only」を選択します。
  3. 「Origin Domain Name」には S3 バケットを選択します。
  4. ベストプラクティス通り、「Restrict Bucket Access」を選択します。こうすることで、バケットが直接アクセスされることから守ることができます。これで CloudFront ディストリビューションのドメイン名で、サイトにアクセスできるようになると思います。

ログイン メカニズム

次に、ログイン メカニズムを構築します。

ウェブサイトではログインさせるために、ボタンを押させることも出来ますし、自動的に認証情報が有効かどうか確認してからログインのフローにリダイレクトをさせる事もできます。

この例では、2 つ目のアプローチを取ります。ユーザがページを訪れると JavaScript を使ってすぐに状態を確認し、初回の訪問であれば認証情報を入手するためにリダイレクトさせます。このページにはログインの流れの中で API Gateway から再度リダイレクトされても来るため、ログインの進捗に合わせ ADFS のログインページにリダイレクトさせるのと同様に、届いた SAMLResponse のデータをキャプチャする事も必要です。今回の例では、以下のような流れになります。:

function loginWorkflow(){
    var activelogin = sessionStorage.getItem('activelogin');
    if (activelogin=='inProgress'){                                   //ADFS login redirect from API Gateway
        var samlResponse = getParameterByName('SAMLResponse');
        sessionStorage.removeItem(‘activelogin’);
        if (samlResponse != null){
            getSamlCredentials(samlResponse.replace(/\s/g, ''));
        }
    }
    else if (activelogin === null) {                                 //First page visit. Redirect to ADFS login.
        var RPID = encodeURIComponent('urn:amazon:webservices');
        var result = 'https://localhost/adfs/ls/IdpInitiatedSignOn.aspx' + "?loginToRp=" + RPID;
        sessionStorage.setItem('activelogin', 'inProgress');
        window.location = result;
    }
    else {//Credentials exist, page refresh, etc.
        console.log('activelogin already exists in session and the value is ' + activelogin);
    }
}

上記では、ADFS IdP への呼び出しを始める時にセッション変数を設定し、SAMLResponse (getParameterByName() で取り出せる)と一緒にWeb サイトに戻って来た時には getSamlCredentials() 関数を呼び出します。

AWS が必要とする SAMLResponse 値は POST binding のみがサポートされていますが、S3 の静的ウェブサイトは、GET リクエストしか受け取ることができません。このため、JavaScript アプリケーションが ADFS からの SAMLResponse を受け取るために API Gateway を利用します。Lambda をプロキシとして利用し、SAMLResponse をクエリ文字列に入れて静的ウェブサイトにリダイレクトで戻ってこさせます。

Lambda 関数の設定

  1. Lambda のコンソールで、GitHub レポジトリにある /Scenario1/lambda/redirect/index.js を使って samlRedirect という名前の関数をランタイムは Node.js 4.3 で作成します。実行ロールにはログ保存のために CloudWatch Logs の権限だけが必要です。
  2. 基本的な実行ロールが既になければ、関数作成時に新しいロールを Lambda のコンソール上で作成する事ができます。
  3. LOG_LEVELREDIRECT_URL という名前の環境変数を作成し、LOG_LEVEL には info を REDIRECT_URL には S3 の静的ウェブサイトの URL(静的ウェブホスティングを有効にしている場合にはバケットのプロパティに表示されているエンドポイント、あるいは先程記載したオプションの CloudFront ディストリビューション設定をした場合はドメイン名)を設定します。

API Gateway 設定

  1. API Gateway のコンソールで、SAMLAuth あるいは何か似た名前を付けた API を作成します。
  2. リソース」 を選択し、「SAML」という名前の子リソースを作成します。
    lambdasamlone_7.png
  3. POST」メソッドを作成します。「統合タイプ」には「Lambda」を選択し、「samlRedirect」関数を指定します。「メソッドリクエスト」の「HTTP リクエストヘッダー」に「SAMLResponse」を設定します。
    lambdasamlone_8.png

先ほど作成した samlRedirect 関数では、クエリ文字列に SAMLResponse を付けた静的ウェブサイトの URL を location プロパティに設定します。リダイレクトが実行されるように、API Gateway が 302 ステータスコードを返すように設定します。

  1. メソッドレスポンス」でステータスコード 200 を削除し、302 を追加します。「レスポンスヘッダ」に「Location」を設定し、「レスポンス本文」には「コンテンツタイプ」に「application/json」、「モデル」に「Empty」と設定します。
    lambdasamlone_9.png
  2. 「統合レスポンス」で「メソッドレスポンス」のステータスが 200 のものを削除し、302 のものを追加します。レスポンスヘッダ「Location」の「マッピングの値」には「integration.response.body.location」を設定します。
    lambdasamlone_10.png
  3. Lambda 関数が SAMLResponse と RelayState を受け取れるように、「統合リクエスト」で「コンテンツタイプ」が 「application/x-www-form-urlencoded」の「本文マッピングテンプレート」を以下のように追加します。:

    {
    "SAMLResponse" :"$input.params('SAMLResponse')",
    "formparams" : $input.json('$')
    }
  4. 変更を保存します。
  5. /saml リソースで「アクション」から「CORS の有効化」を選択します。「CORS を有効にして既存の CORS ヘッダを置換」を行いします。

  6. アクション」から「API のデプロイ」を選択します。「ステージ」には「Prod」や似た名前を使用します。「ステージエディター」で、「SDK 生成」を選択します。「プラットフォーム」には「JavaScript」を選択し、「SDK の生成」を行い、どこかのフォルダに保存します。ADFS の設定に必要になるため、トップに表示されている「URL の呼び出し」をメモします。

ADFS リダイレクト設定

  1. ADFS のコンソールで、「利用信頼関係」にある Amazon Web Services のプロパティを開き、「利用者を自動的に更新する」の項目を無効(チェックしない)にします。
    lambdasamlone_11.png
  2. エンドポイント」のタブを開き、既にあるエンドポイントを編集します。「バインディング」は「POST」のままで、「URL」には API Gateway でデプロイした API の「URL の呼び出し」を入力します。URL の最後に 「/saml」を追加します。
    lambdasamlone_12.png
    これまで構築してきたことを復習します。:

    • Web ページはユーザが認証情報を持っていなければ、ADFS のログインページにリダイレクトします。
    • 認証に成功したら、ADFS は SAMLResponse を付けて Web ページにユーザを戻します(API Gateway 経由)。
    • SAMLResponse は元の Web ページにクエリ文字列の一部として渡されます。

    Amazon Cognito から認証情報を取得するには、JavaScript コードでこのクエリ文字列を取り出し getCredentialsForIdentity 呼び出しのパラメータの一部として渡す必要があります。

  3. Amazon Cognito の Federated Identities のコンソールで、前提条件でセットアップした認証プールを開きます。認証プールの ID を確認し、以下の JavaScript コードの先頭に利用するリージョン名と同様に記載します。
    const identityPool = 'YOURCOGNITOPOOLID';
    AWS.config.region = 'COGNITOREGION'; // Region
    
    AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: identityPool
    });
    
    var identityId = localStorage.getItem('cognitoid');
    if (identityId != null){
        console.log('Identity ID: ' + identityId);
        loginWorkflow();
    } else {
        console.log('Calling GetID');
        AWS.config.credentials.get(function(){
            console.log('Identity ID: ' + AWS.config.credentials.identityId);
            localStorage.setItem('cognitoid', AWS.config.credentials.identityId);
            identityId = localStorage.getItem('cognitoid');
            loginWorkflow();
        });
    }

このコードは、アプリケーションでユーザに Amazon Cognito で生成した一意の ID を付与する最初の部分です。その上で、クエリ文字列に SAMLResponse の値を入れて返させるために loginWorkflow() を呼び出します。

以下は Stack Overflow で紹介されているサンプルのユーティリティ関数で、クエリ文字列から特定の項目を取り出すためのものです。

function getParameterByName(name, url) {
    if (!url) {
      url = window.location.href;
    }
    name = name.replace(/[\[\]]/g, "\\$&amp;");
    var regex = new RegExp("[?&amp;]" + name + "(=([^&amp;#]*)|&amp;|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));
}

これで Web ページは ADFS から BASE64 エンコードされた SAMLResponse を取得しました。これを Amazon Cognito に渡せば AWS 認証情報を取得することが出来ます。Cognito の getSamlCredentials() 関数は以下のコードで、loginWorkflow() から呼び出されます。:

function getSamlCredentials(samlResponse) {
    var role = 'arn:aws:iam::ACCOUNTNUMBER:role/ADFS-Dev';
    var params = {
        IdentityId: identityId,
        CustomRoleArn: role,
        Logins: {
            'arn:aws:iam::ACCOUNTNUMBER:saml-provider/ADFS' : samlResponse,
        }
    };

    cognitoidentity.getCredentialsForIdentity(params, function(err, data) {
        if (err) console.log(err, err.stack);
        else {
            console.log('Credentials from Cognito: ');
            console.log(data.Credentials);
        }
    });
}

ARN にある ACCOUNTNUMBER は2つとも書き換える必要がある事に注意して下さい。今回は使用するロールがソースに直書きされています。もし、SAML クレームに複数のロールが入って返されないのであれば、このパラメータは省略することもできます。引き受けるロールを何かしらのロジックで選択するようにしたい場合もあると思います。このブログ記事のパート II ではクライアント側ではなくバックエンドでこれをできるようにする内容を含める予定です。

また、logins map にあるキーは IAM コンソールで作成した ADFS の IdP 登録の ARN で、値は samlResponse です。これもアカウント番号に書き換える必要があります。この情報により Amazon Cognito は SAMLResponse の値が信頼している対象の ADFS からのものであるか検証できます。

この時点でこのコードを試しても動作しません。Amazon Cognito の認証プールで、認証プロバイダとして SAML IdP を有効にする必要があります。

  1. Amazon Cognito の Federated Identities のコンソールで、プールを選択し、Authentication Providers までスクロールし、SAML を選択します。ADFS の IdP を示すチェックボックスを選択します。
  2. Save Changes をクリックします。
    lambdasamlone_13.png

次に、Amazon Cognito が有効な SAMLResponse アサーションを受け取った時に、ユーザがロールを引き受けられるように信頼ポリシーを変更します。Amazon Cognito は STSAssumeRoleWithWebIdentity API を呼び出してこれを実現します。

IAM のコンソールで、ADFS-Dev ロールの信頼ポリシーを以下のポリシーに編集します。(JavaScript コードのように適切な位置に Amazon Cognito のプール ID を挿入します。):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "YOURCOGNITOPOOLID"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

これで Amazon Cognito の信頼ポリシーは設定できました。Web ページをテストして下さい。AWS サービスのリクエストへの署名に使える認証情報はコンソールログに (AccessKey, SecretKey, Token) の 3 つが含まれる形で “data” オブジェクトで出力されます。アプリケーションの共通のシナリオは、AWS_IAM 認証に設定された API Gateway のメソッド呼び出しを行うことです。認証情報は SDK のリクエストを使うことで渡す事ができます。上記の呼び出して指定したロールにその API を呼び出す権限があれば、メソッド呼び出しは成功します。

例えば、API Gateway で API を作成した場合、メソッドに AWS_IAM 認証を有効にできます。上記で指定されたロール(logins mapで指定)に、メソッド呼び出しの権限があることを確認して下さい。より詳しいことは、「API Gateway へのアクセスを IAM アクセス権限で制御する」をご覧下さい。API をデプロイした場合、SDK の生成を使ってそのステージの JavaScript SDK を生成してダウンロードできます。これからのメソッド呼び出しを Web ページに組み込む事ができます。より詳しいことは、「API Gateway で生成した JavaScript SDK を使用する」をご覧下さい。トピックの最後に、apigClientFactory.newClient コンストラクタにアクセスキーシークレットキーをどうやって渡すことができるか確認しましょう。

Amazon Cognito Identity は短期間だけ有効な認証情報(1 時間で無効になる)を利用するため、一時的なアクセスキー、シークレットキー、セッショントークンを、apigClientFactory.newClient コンストラクタに渡します。:

        var apigwClient = apigClientFactory.newClient({
        accessKey: data.Credentials.AccessKeyId,
        secretKey: data.Credentials.SecretKey,
        sessionToken: data.Credentials.SessionToken
    });

機能の動作確認ができる Web ページのコードは、GitHub レポジトリ内の /scenario1/website/index.html にあります。同じディレクトリにある configs.js ファイルを更新します。リージョン、Cognito Identity のプール ID、SAML IdP の ARN、ADFS-Dev ロールの ARN を変更します。SAM テンプレートを使って API Gateway に AWS_IAM 認証の MOCK エンドポイントを作成する事もでき、連携された認証情報が機能するか Web ページ上のテストボタンで確認する事ができます。

lambdasamlone_14.png

最後に

チュートリアルを通じて SAML 認証や Amazon Cognito を使った AWS 認証について深いレベルで理解する手助けになる事を願っています。まだ完了していなければ、少し時間をかけて頂き、GitHub レポジトリの samljs-serverless-sample にあるコードを実際に動かし確認して下さい。また感想についても教えてください。

このシナリオは最初のステップとして十分かもしれませんが、組織によってはより多くのことをする必要があるかもしれません。例えば、ロールの選択をユーザに任せたいやビジネスロジックに基づき独自の IAM 範囲を実装したい事もあるかと思います。このシリーズのパート 2 ではこれらをどのようにしたら実現できるかを見ていきたいと思います。

[訳注] このブログで紹介している方法では、ADFS におけるデフォルトの AWS の証明書利用者設定を変更します。そのため、同じ ADFS 環境で AWS のマネージメントコンソールへ認証連携してアクセスさせる事とは同時に実現できません。

原文: SAML for Your Serverless JavaScript Application: Part I (翻訳: SA 辻 義一)

新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御

アプリケーションの構築における課題の 1 つは、ユーザー認証と管理に関する事柄です。この課題に直面しても、多くの開発者はアプリケーション用の別のユーザー ID と認証システムを構築したいとは考えていませんし、必要な場合を除いてユーザーにさらに別のアカウントを作成させたいとも思っていません。Amazon Cognito では、アプリケーションのデータとバックエンドシステムにアクセスするために、開発者がユーザーの ID、認証、および権限を簡単に管理できるようになっています。それに加えて、開発者がアプリケーションの異なるユーザーに異なる権限を割り当てるのを簡単にするサービス機能があればどんなによいでしょう。本日、Cognito ユーザープールがグループをサポートし、Cognito フェデレーション識別がきめ細かなロールベースのアクセス制御 (RBAC) をサポートするようになったことが発表されました。Cognito でのグループのサポートにより、開発者は異なるユーザータイプとアプリケーションの使用権限を表すグループを作成して、ユーザーのアプリケーションエクスペリエンスを簡単にカスタマイズできます。開発者は、グループからのユーザーの追加や削除、およびユーザーのセットに対してグループで権限を管理できます。権限に関しては、Cognito フェデレーション識別でのきめ細かなロールベースのアクセス制御 (RBAC) のサポートにより、開発者は異なる認証をされたユーザーに異なる IAM ロールを割り当てられます。これまで、Amazon Cognito ではすべての認証されたユーザーに対して 1 つの IAM ロールのみをサポートしていました。きめ細かな RBAC を使用すると、開発者はフェデレーティッドユーザーに異なる IAM ロールをマッピングすることができます。この機能は Facebook や Active Directory などの既存の ID プロバイダーと Cognito ユーザープールを使用したユーザー認証の両方で利用できます。

Cognito ユーザープールのグループ
新しい Cognito のグループの機能について調べる最善の方法は、Amazon Cognito コンソールで新しいグループを作成して、さまざまなグループタイプにユーザーを追加してみることです。Cognito - UserPoolCreateGroup   [my user pool]、[TestAppPool] を選択すると、[Users and groups] という更新されたメニュー項目があります。メニューオプションを選択すると、パネルに [Users] と [groups] の両方のタブが表示されます。新しいグループを作成するには、[Create Group] をクリックします。グループを作成するダイアログボックスが開きます。ここでは、AdminGroup という管理者ユーザー用のグループを作成します。グループの名前とグループの説明を記入し、優先順位を設定してグループを作成する準備ができました。優先順位の数値をグループに設定すると、複数のグループに割り当てられているユーザーに対して、どのグループの権限が優先して使用されるかが決定されます。優先順位の数字が低いほど、ユーザーが使用するグループの優先順位が高くなります。自分の [AdminGroup] の場合、このグループにゼロ (0) の優先順位を付けます。[Create group] ボタンをクリックして、自分のユーザープールグループを作成します。Cognito - CreateGroupDialog-s あとは、自分のユーザーをグループに追加するだけです。このテストアプリケーションプールでは、以下の図のように [TestAdminUser] と [TestUnregisteredUser] の 2 人のユーザーがいます。[TestAdminUser] を、新しく作成したグループに追加します。Cognito - Users ユーザーを AdminGroup ユーザープールグループに追加するには、[Groups] タブで自分の [AdminGroup] を選択します。AdminGroup の詳細画面の表示後、[Add users] ボタンをクリックすると、ユーザープール内のユーザーを表示するダイアログボックスが表示されます。このグループにユーザーを追加するには、追加するユーザー名の横にあるプラスのマークをクリックするだけです。ユーザーがグループに追加されたという確認を受け取ると、このプロセスは完了です。ウォークスルーからお分かりのように、開発者がユーザープール内にグループを作成することは簡単です。AWS マネジメントコンソール、API、および CLI を使用して、ユーザープール内のグループを作成および管理できます。開発者として、AWS 認証情報を使用してユーザープールのグループを作成、読み込み、更新、削除、およびリストすることができます。各ユーザープールには、最大 25 個のグループを含めることができます。さらに、ユーザープール内のグループからユーザーを追加または削除できます。また、グループに AWS IAM ロールを割り当てることによって、グループを使用して AWS のリソースへのアクセス許可をコントロールすることができます。Amazon API Gateway と組み合わせて Amazon Cognito を使用することによって、自分のバックエンドリソースへのアクセス許可をコントロールすることもできます。

Cognito - AddUsersAdminGroup - small

Cognito フェデレーション識別でのきめ細かなロールベースのアクセス制御
Cognito フェデレーション識別機能の、きめ細かなロールベースのアクセス制御 (Role-Based Access Control) を詳しく調べましょう。以降、これを RBAC と呼びます。RBAC について見てみる前に、Cognito フェデレーション識別機能の概要を確認しましょう。Cognito ID は、AWS アカウント認証情報を使用せずにアプリケーションから AWS リソースにアクセスするための、権限が制限されている一時的な認証情報のセットをユーザーに割り当てます。各ユーザーの権限は、お客様が作成する AWS IAM ロールを介して制御されます。この時点で、マネジメントコンソールの別のウォークスルーで RBAC について見ていきましょう。コンソールで [Cognito] サービスを選択したら、[Federated Identities] を選択します。RBAC を確認している間に稼働中の Cognito ユーザープールとフェデレーション識別を示すのが最善であると思うので、認証プロバイダーとして Cognito ユーザープールを使用する新しい ID プールを作成します。新しいユーザープールを作成するために、最初に ID プールの名前を入力し、認証されていない ID へのアクセスを有効にするチェックボックスをオンにします。次に、[Authentication Providers] の [Cognito] タブを選択して、TestAppPool ユーザープール ID とアプリケーションのクライアント ID を入力します。アプリケーションのクライアント ID を取得し、アプリケーションが Cognito ID プールを利用して関連付けられたユーザープールにアクセスするために、Cognito ユーザープール内にアプリケーション (アプリケーションクライアント) が作成済みである必要がある点に注意してください。Cognito - CreateIdentityPool ID プールの作成が済んだところで、Cognito ユーザープールの認証方法にロールベースのアクセスを割り当てましょう。異なるロールを割り当てる最も簡単な方法は、Cognito ID プールでルールを定義することです。各ルールは、ユーザー属性を指定するか、コンソールに表示されるようにクレームを指定します。クレームは、ルールによって一致し、特定の IAM ロールに関連付けられる、その属性のトークンの値です。RBAC の利点を真に示すためには、エンジニアリング部門のユーザーがオブジェクトを S3 に配置し、DynamoDB にアクセスできるテストアプリケーションの役割が必要になります。このロールを作成するために、まず S3、GetItem、クエリ、スキャンへの PutObject アクセスおよび DynamoDB への BatchGetItem アクセスが含まれるポリシーを作成する必要があります。このポリシーを TestAppEngineerPolicy と呼ぶことにします。前述のポリシーを作成した後で、このポリシーを活用する EngineersRole という名前の IAM ロールを作成します。この時点で、AWS リソースへのきめ細かなアクセスのできるロールがあるので、Cognito ID プールにもどります。[Edit identity pool] をクリックし、[Authentication providers] セクションをドロップダウンします。ID プールの認証プロバイダが Cognito ユーザープールであるため、[Cognito] タブを選択します。フェデレーティッド認証のきめ細かな RBAC を確立しているので、[Authentication provider] の [Authenticated role selection] セクションに注意を集中して、ルールを定義します。このセクションでは、ドロップダウンをクリックして、オプションの [Choose role with rules] を選択します。Cognito - AuthenticationProviderここで、クレーム (属性)、一致する値、特定の IAM ロール、EngineersRole のルールを設定します。たとえば、作成しているルールが特定の IAM ロール (例: EngineersRole) を、部門属性が「Engineering」として設定された Cognito ユーザープールで認証済みのユーザーに割り当てます。ルールに基づいている部門属性は、下の図に示すように、ユーザープール TestAppPool で作成したカスタム属性であることに注意してください。Cognito - CustomAttributes - smallこれで、この問題はクリアしたので、ルールの作成にもう一度注目します。クレームに関しては、前述のカスタム属性、部門を入力します。部門の値が、文字列「Engineering」と等しい場合にこのルールが適用されます。したがって、[Match Type] フィールドで [Equals match type] を選択します。最後に、ルールで一致する属性値に対する、実際の文字列値「Engineering」を入力します。ユーザーが部門属性に対して一致する値を持っている場合、認証情報を取得したときに EngineersRole IAM ロールを引き受けることができます。これを完了して、[Save Changes] ボタンをクリックすると、Cognito ユーザープールで認証済みの、エンジニアリング部門のユーザーがアプリケーションを使用している他の認証されたユーザーとは異なる権限を持てるルールが正常に作成されました。Cognito - AuthenticationRoleSelection Cognito ID プールで異なるロールに割り当てるルールの設定のウォークスルーを完了したので、きめ細かな RBAC について覚えておきたい重要なポイントをいくつか説明します。まず、最初に一致するルールが適用されるために、ルールはオーダーと IAM ロールで定義されます。次に RBAC を設定するには、ユーザープールにより割り当てられる ID トークンを介してルールを定義し、ロールを活用することができます。ID プールで設定された各認証プロバイダーに対して、最大合計 25 個のルールを作成できます。さらに、ユーザーアクセス権限は作成した AWS IAM ロールによって制御されます。

料金と提供地域
開発者はこれらの新機能をすぐに活用できます。新機能と Amazon Cognito サービスを活用することの他の利点については開発者用リソースページを参照してください。ユーザープール内のグループを使用しても追加コストが発生しないというのは大きなニュースです。無料利用枠の後は、料金は、Monthly Active Users (MAU) に対してのみ発生します。また、Amazon Cognito では、ユーザーのアクセス権限を制御、また一意の識別子の生成のために Cognito フェデレーション識別機能を常時無料で使用できることを覚えておいてください。詳細については、Amazon Cognito 料金表ページを参照してください。

Tara

AWS Lambda と Amazon API Gateway で Express アプリケーションを実行

ExpressNode.js のウェブフレームワークです。これを使用すると、「サーバーレス」ウェブサイトやウェブアプリケーション、API を簡単にデプロイできます。サーバーレス環境では、大方またはすべてのバックエンドロジックがステートレスのオンデマンドで実行します (詳細情報については Mike Roberts によるブログ「Serverless Architectures」をご覧ください)。今月初旬に公開したブログ (「API Gateway の更新 – API 開発を簡素化する新機能」) で紹介した新しい Amazon API Gateway 機能と AWS Lambda を併せて使用した場合、既存の Express アプリケーションをサーバーレスで実行することができます。API Gateway を使用すると API を中心に開発者のエコシステム構築を可能にする使用量プランなど追加機能を利用したり、キャッシュにより応答性と費用対効果に優れたアプリケーション構築を行うこともできます。

AWS は aws-serverless-express パッケージを提供することで Express アプリケーションから LambdaAPI Gateway への移行をお手伝いしています。このパッケージには実例が含まれています、ぜひご活用ください。

Express コードとアプリケーションを API GatewayLambda に移行する場合に利用できる 2 つのリソースをご紹介します。

Jeff;

API Gateway のアップデート – API 開発を簡素化する新機能

Amazon API Gateway で、堅牢でスケーラブルなアプリケーションバックエンドの構築と実行を簡単に素早く最近追加された使用プランで、API に関与するパートナー開発者のエコシステムを作成することができます。では、いくつかの用語を確認しながら始めましょう。

エンドポイント – HTTP リクエストに応答する URL (API Gateway によって提供される) です。これらのリクエストは、GET、PUT、POST などの HTTP メソッドを使用します。

リソース – エンドポイント内にある名前の付いたエンティティで、階層パスと呼ばれます。

動作 – 特定のリソース上で、HTTP リクエストに対応してコードが HTTP メソッドを使用して実行するアクションです。

統合 – エンドポイント、リソース、および HTTP メソッドと実際のアクションとの間でやり取りされる API Gateway マッピングです。

現在、API Gateway が提供する統合モデルを拡張して、新しい API エンドポイントの構築と既存のアプリケーションの移植を容易にするための複数の新しい機能をサポートしています。

greedy パス変数 – 一般的なパス ( /store/ など) に分類されるリクエストのグループのパスと動作を個別に指定する代わりに、パスへのすべてのリクエストを傍受してそれらを同じ機能にルーティングする、「greedy」ルートを指定できるようになりました。たとえば、単一の greedy パス (/store/{proxy+}) は、 /store/list-products, /store/add-product、および /store/delete-product) に対するリクエストを傍受します

ANY メソッド – それぞれの HTTP メソッド (GET、POST、PUT など) に個別の動作を指定する代わりに、catch-all ANY メソッドを使用して、すべてのリクエストに対して同じ統合動作を定義できるようになりました。

Lambda 関数統合 – 新しいデフォルトのマッピングテンプレートで、すべてのリクエストを Lambda 関数に送信し、戻り値を HTTP 応答に変換します。

HTTP エンドポイント統合 – もう 1 つの新しいデフォルトマッピングテンプレートで、すべてのリクエストを HTTP エンドポイントに送信し、その応答を変更せずに返します。これにより、わずかのセットアップ作業を行うだけで API Gateway を HTTP プロキシとして使用できます。

詳しい内容を見てみましょう。

Greedy パス変数
新しい e-コマース API を作成しているところだとしましょう。次のように開始します。

次に、 /store リソースを作成します。

次に、greedy パス変数を使用して、 /store 内のリソースに対するすべてのリクエストを傍受します (プロキシリソースとして設定されていることも確認する必要があります)。

なぜなら、 {proxy+} がサブリソースのリクエストを実際のリソースにルーティングするため、リソースパスの最終要素として使用される必要があるからです。これ以外の場所で使用するのは無意味です。 {proxy+} はあらゆる深さのパスに一致させることができます。上記の例は、 /store/us/clothing, /store/us/clothing/children などにも一致します。

プロキシは Lambda 関数または HTTP エンドポイントに接続できます。

ANY メソッド
HTTP メソッドでリソースとメソッドを定義するときに、それぞれの HTTP メソッドに対して個別の動作を指定する必要はなくなりました。

代わりに、ANY を選択して、リソース上のすべてのメソッドに対して同じ統合動作を使用することができます。

これにより、セットアップがより明確でシンプルかつ容易なものになります。お使いのコード (リソース上のすべてのメソッドに対する統合ポイント) は、メソッド名を調べて適切なアクションを実行します。

ANY メソッドは、上記のように greedy パス変数を使用すると自動的に作成されます。これは個別のリソースにも使用できます。メソッドを作成してその設定を変更するだけで、個別のメソッドの設定を上書きすることができます (DELETE を別の方法で使用するなど)。

Lambda 関数統合
Lambda 関数を使用して動作を実装するのがこれまでになく簡単になりました。新しい組み込みの Lambda 統合テンプレートは、HTTP リクエスト要素 (ヘッダー、クエリーパラメーター、ペイロード) を関数が直接使用できる形式にマップします。テンプレートは、関数の戻り値 (ステータスコード、ヘッダー、本文要素) を適切に構造化された HTTP 応答にマップします。

ドキュメントからコピーしたシンプルな関数を次に示します (「プロキシ統合のための Lambda 関数」を参照)。

この関数を次のように /store に接続します。

次に、それをデプロイして (デプロイに関する説明は示しません)、次のようにテストします。

関数が予想通りに実行され、コンソールに応答の本文、ヘッダーが表示され、ログファイルが作成されます。これが最初の部分です。

次に Lambda コンソールに移動して、使用した関数の CloudWatch ログを調べます。

ここにあるとおり、関数の 10 行目に黄色で強調表示したメッセージがあります。

このように、マッピングや変換の設定に時間をかけずに、API リソースで HTTP リクエストに応答する Lambda 関数を作成することができるようになります。事実、Lambda コンソールに新機能を追加したことで、このプロセスがいっそう簡単になりました。新しい Lambda 関数作成の最初のステップの 1 つとして、API Gateway エンドポイントを設定できるようになりました。

HTTP 関数統合
また、EC2 インスタンスまたはオンプレミスで実行されている HTTP エンドポイントに API リクエストを送信できるようにもなりました。もう一度繰り返しますが、マッピングや変換を設定する手間はもう必要なくなりました。代わりに、統合タイプHTTP を選択して HTTP プロキシ統合をクリックし、エンドポイントの名前を入力するだけです。

HTTP メソッドANY を選択すると、受信されたリクエストのメソッドがエンドポイントにそのまま送信されます。ANY を選択しなかった場合は、呼び出しの一部として示される値にメソッドが設定されます。

今すぐ利用可能
上記の機能は今すぐご利用いただけます。無料で今日からお使いいただけます。

Jeff;

Amazon API Gatewayのための利用プラン

昨年、開発者がモバイル、web、エンタープライズそしてIoTアプリケーション向けバックエンドWebサービスを構築できるようにするため、 Amazon API Gateway を紹介しました( Amazon API Gateway – Build and Run Scalable Application Backend to learn more を参照)。そのときから、AWSの顧客は  AWS LambdaAmazon Elastic Compute Cloud (EC2)、そしてAWSの外で稼働するサーバ上で実行されるAPIの実装を行ってきました。多くの場合、我々の顧客は彼らのAPIの上でアプリケーションを開発するパートナー開発者のエコシステムを作ることを計画しています。API Gateway を利用することで、我々の顧客は彼らの顧客それぞれにAPIキーを作成することが可能です。
これらのキーはAPIの各ユーザを特定し、キーの所有者がアクセス可能なサービスのセットとサービスのステージ(テスト、ベータそして本番といった環境)をAPI開発者がコントロールすることが可能です。APIはしばしばビジネス価値の代わりとして提供されるため、我々の顧客はAPIを構築し、それらへのアクセスを規制し、使用量に基づいて課金することによって、それらを収益化したいと我々に教えてくれました。
新しい利用プラン
このユースケースをサポートするため、API GatewayのUsage Planをご紹介します。この新機能により、開発者はAPIを構築、収益化することと、彼らの周りでエコシステムを作ることが可能になります。異なるレベルのアクセス(Bronze、Silver、Gold)、異なるカテゴリのユーザ(学生、個人、プロフェッショナルもしくはエンタープライズ)などに対して利用プランを作成することができます。プランは名前が付けられ、APIに対するアクセスの以下の面をコントロールします。

  • スロットリング – リクエストレート全体(平均秒間リクエスト)とバーストキャパシティ
  • クオータ – 一日あたり、週あたり、もしくは月あたりに可能なリクエストの数
  • API / ステージ – アクセス可能なAPIとAPIのステージ

仮に利用プランを使うことを選択するならば、あなたのAPIそれぞれがプランと紐付けられなければなりません。幸い、API Gatewayはデフォルトプランを作成し、それらにAPIを紐付けることができます。あなたがやろうとすることを確認するだけです。

デフォルトプランはスロットリングもクオータもありませんし、APIの挙動を変更しません。

利用プランの作成
Let’s step through the process of creating a Usage Plan.  利用プランの作成プロセスを一つずつ見ていきましょう。API Gatewayのコンソールを開き、Usage Plans、に移動しCreateをクリックしてください。 名前、説明を入力し、それからスロットリングとクオータのオプションを必要に応じて設定します。

スロットリングはToken Bucket モデルを使って実装されています。バケットはバースト値により示されるトークン数を保持するのに十分な大きさで、指定レートで新規トークンを取得します。各APIリクエストはバケットから1つのトークンを削除します。Token Bucketを使うことで、時折のバーストに対応するケイパビリティを持った安定したリクエストのストリームをサポートするAPIを持つことが可能になります。 2つの異なる方法でスロットリングを利用したり考えたりできます。ビジネス的な観点からは、それにより各顧客が生成可能なリクエストがどの程度かコントロールするために利用プランを使うことができます。技術的な観点からは、APIとして実装するために使われているサービスを過度なリクエストから遮断することができます。もし、それらのサービスがAWSの外で実装されていて、要求に合うようスケールできないならば、これは特に重要なことです。

Nextをクリックし、そしてそれから利用プランを通じてアクセスされるAPIとAPIステージを選択します。

プラン作成のために Next をクリックし、それからいくつかのAPIキーを追加します。既存のキーを追加する、もしくは新しいものを作成することが可能です。

料金プランを既存のAPIキーにアタッチすることを計画しているならば、キーは同じステージに関連する複数のプランを参照できないので最初にキーからデフォルトプランを削除しなければなりません。2つ目のブラウザタブ内でAPIキーを開き、デフォルトプランの右にある”x”をクリックすることでこれができます。

(プランにキーを追加しているタブ上で)1つもしくは複数のAPIキー(APIのサブスクライバを示す)を選択し、Doneをクリックします。

あなたのユーザ(サブスクライバ)がAPIキーを使ってAPIコールを開始したら間もなく、プランで指定された通りに彼らの利用量はスロットルされ、制限されます。Usageをクリックすることでいつでも彼らの利用量を見ることができます。

クオータはリアルタイムに適用され守られます。利用量のデータは最大30分遅れます。

Export Usage Dataをクリックすることで利用量のデータはダウンロード可能です。

その後、望み通りにデータを処理し、分析することが可能です。例えば、コールごとベースでサブスクライバに請求書発行することが可能です。

サブスクライバの一つがAPIを非常によく利用していて、期間内のクオータに近づきつつある場合、利用プランを変更することなく彼らに利用を増やすことを許可することができます。Extensionをクリックして、期間内の残りを用意するために許可するリクエスト数を入力するだけです。

利用プランを使用する
先だって言及したように、利用量に対する請求書発行やAPIを中心としたエコシステムを作るのに利用プランを使えます。

アクセスをコントロールしたり、監視することができ、必要に応じて選択的に特別なアクセスを個別のサブスクライバに許可することができます。例えば、特定のAPIステージに対するアクセスを許可するAPIキーと利用プランを作成することができます。多くのサブスクライバは本番ステージへのアクセスが必要です。少しのサブスクライバは開発もしくはベータテストのステージへのアクセスが必要です。

まとめの前に、APIキーは識別のためであり、認証のためではないことを指摘しておきます。キーはリクエストの署名のためには使われず、セキュリティ機構として使うべきではありません(これは完全に Cognito Your User Poolsのユースケースです)。

今すぐ利用可能
この機能は今すぐ利用可能で、本日より使う始められます。


Jeff;(翻訳はSA西谷が担当しました。原文:New – Usage Plans for Amazon API Gateway

Amazon Cognito Your User Pools - 一般提供を開始

数か月前公開したブログ Amazon Cognito の新しい Your User Pools 機能についてご紹介しました。その時点では、ユーザーのモバイルアプリやウェブアプリでサインアップやサインインに同機能を使用することをご説明しました。完全マネージド型のユーザーディレクトリでは、ユーザー数億人の拡大を可能にしたり、各 AWS アカウントで複数のディレクトリを使用することができます。ユーザープールは数分で作成でき、新規ユーザーがお客様のアプリまたはサービスにサインアップする時に、どの属性 (アドレス、メール、性別、電話番号やカスタム属性など) に入力の必要があるか指定することができます。セキュリティの面では、お好みに合わせたパスワード強度を特定したり、Multi-Factor Authentication (MFA) の使用の強制やユーザーの電話番号またはメールアドレスでの確認を求めることができます。

一般提供を開始
Your User Pools のパブリックベータ版を開始したところ、数多くの素晴らしいフィードバックをいただきました。そして本日、Your User Pools の一般公開を開始した他、このリリースに伴い、いくつかの新機能も追加しました。

  • Device Remembering – Cognito は各ユーザーがどのデバイスからサインインしたか記憶することができます。
  • User Search – 属性に基づきユーザープールでユーザーを検索できます。
  • Customizable Email Addresses – ユーザープール内でユーザーのメールアドレスを管理できます。
  • Attribute Permissions – 各ユーザーの属性を細かく設定することができます。
  • Custom Authentication Flow – 新たな API や Lambda トリガーを使用してサインインフローをカスタマイズできます。
  • Admin Sign-in – バックエンドサーバーや Lambda 関数からユーザーをアプリにサインインさせることができます。
  • Global Sign-out – サインインしているすべてのデバイスやブラウザからユーザーがサインアウトできるようにします。
  • Custom Expiration Period – トークン更新に有効期間を設定できます。
  • API Gateway Integration – ユーザープールを使用して Amazon API Gateway リクエストを承認できます。
  • New Regions – 追加した AWS リージョンでも Cognito Your User Pools をご利用いただけます。

次に各新機能の詳細についてご説明します。

Device Remembering
Cognito で各ユーザーがサインインに使用したデバイス一連を記録できるようになりました。ユーザープールの作成者には、この操作のリクエストをユーザーに許可するオプションがあります。ユーザープールで MFA を有効にしている場合は、記録されたデバイスで MFA コード入力の必要を取り消すこともできます。これにより、認識されていないデバイスには MFA コードの入力を要求し、記録されたデバイスのログインプロセスを簡素化かつ合理化することが可能になりました。また、ユーザーのデバイスをリストにし、リモートからデバイスよりサインアウトできるようにします。ユーザープールの作成時に、この機能を有効にしたりカスタマイズすることができます。新しいユーザープールの作成時に同機能を有効にし、カスタマイズする方法については次をご覧ください。まず、[Always] または [User Opt-in] をクリックして同機能を有効にします。

次に、記憶したデバイスで MFA を非表示にするか決定します。

AWS Mobile SDK for iOS、Android、JavaScript には、デバイスを記憶するためにアプリから呼び出すことができる新な方法が備わっています。

User Search
Your User Pool の作成者は、次のような属性に基づきユーザーを検索することができます。 username, given_name, family_name, name, preferred_user_name, email, phone_number, status または user_status.

完全一致またはプレフィックス一致を行うには AWS Management Console ListUsers API 関数または list-users コマンドラインツールを使用します。コンソールで検索する場合

Customizable Email Addresses
ユーザーとのコミュニケーションに使用するメールアドレスの差出人や返信先を特定することができます。新しいプールの作成時にアドレスを特定する場合

使用前に Amazon Simple Email Service (SES) で差出人のアドレスを確認する必要があります (詳しくは Verifying Email Addresses in Amazon SES をご覧ください)。

Attribute Permissions
各ユーザー属性で、アプリごとの読み取りや書き込み権限を設定することができます。これにより、どのアプリケーションがユーザー用に保管されているどの属性を閲覧したり変更できるか管理することが可能になります。例えばユーザーが潜在顧客であるか否かを示すように属性をカスタマイズすることができます。アプリがこの属性を見ることはできますが、直接変更することはできません。代わりに管理ツールまたはバックグラウンドプロセスを使用して属性を更新してください。Console、API、CLI でユーザー属性の権限を設定することができます。

Custom Authentication Flow
次の新しい API 関数をご利用いただけます (InitiateAuthRespondToAuthChallenge)。その他にも、3 つの新たな Lambda トリガーを使用して独自のサインインフローや既存のプロセスをカスタマイズすることができます。例えば経験レベルが異なるユーザー、ロケーション別、セキュリティ条件別などを対象に、ユーザーフローをカスタマイズすることができます。必要に応じて特定のユーザーまたはユーザー全員に CAPTCHA の使用を要求することもできます。Lambda トリガーの種類

Define Auth Challenge – カスタム認証フローの開始を呼び出します。Create Auth Challenge – カスタム認証チャレンジが規定された場合に呼び出されます。Verify Auth Challenge Response – カスタム認証チャレンジの有効性を確認する場合に呼び出されます。次のように Console からトリガーを設定することができます。

Global Sign-out
ログイン済みのデバイスすべてからサインアウトするオプションをユーザーに提供できるようになりました。有効、期限切れではなく、呼び出されていないアクセストークンを使用して [GlobalSignOut] 関数を呼び出すことができます。開発者は Pool ID と username を使用して [AdminUserGlobalSignOut] 関数を呼び出し、どのユーザーもリモートからサインアウトさせることができます。

Custom Expiration Period
Cognito サインインは、「更新」トークンを使用してアプリケーションを開くたびにサインインする必要を省きます。デフォルトでトークンは 30 日が経過すると無効になります。セキュリティと利便性のバランスをほどよく維持するため、各ユーザープールが生成する更新トークンの有効期間をカスタマイズ設定できるようになりました。

API Gateway Integration
API リクエストを認証するため、Cognito ユーザープールが Amazon API Gateway と密接に連携して対処できるようになりました。ID トークンを受け入れるように API Gateway を設定し、ユーザープールにおけるユーザー状況を認証できます。その場合は、まずユーザープールを参考にしてアイデンティティトークンを含むリクエストヘッダーをを選び、Cognito User Pool Authorizer を作成します。

希望する方法にアクセスし新しい認証を選択します。

New Regions
今回のリリースに伴い、US West (Oregon) リージョンでも Cognito をご利用いただけるようになりました。すでにご利用可能な US East (Northern Virginia) リージョンの他に Europe (Ireland)、US West (Oregon)、 Asia Pacific (Tokyo) リージョンでも Your User Pools をお使いいただけます。

今すぐ利用可能
今すぐ新機能をご利用いただけます。詳細は Getting Started with Your User Pools in Amazon Cognito をご覧ください。

Jeff