【新機能】AWS Single Sign-On サービスを早速使ってみました！これを待ってた！

はじめに

こんにちは植木和樹＠上越妙高オフィスです。本日AWSの新機能 AWS Single Sign-On（以下 AWS SSO）が発表されました！

• AWS Single Sign-On – Cloud SSO Service - AWS

AWS Organizations, AWS Directory Service (AWS Microsoft AD)と連携し、社内Active Directoryのユーザーで複数のAWSコンソールにログインしたり、SAML対応のSaaSサービスにシングルサインオンできる機能になります。

前提条件

利用にあたってはいくつかの条件があります。

AWS SSO Prerequisites - AWS Single Sign-On

• AWS Organizations のマスターアカウントの管理権限をもっていること。
• AWS Organizations の ALL FEATURESが有効になっていること。（ONLY CONSOLIDATED BILLINGだけでは使えません）
• Virginia (us-east-1) でAWS Directory Serviceが設定されていること。（SimpleADは非対応です）

設定方法

1. AWS OrganizationsでALL FEATURESを有効にする

AWS OrganizationsでENABLE ALL FEATURESが有効になっていない場合は、事前にこの手順が必要です。

AWS Organizationsのコンソールを開いてBegin process to enable all featuresをクリックします。

ALL FEATURESを有効にするとONLY CONSOLIDATE BILLING に戻すことはできません というメッセージがでます。もし本番アカウントで行う場合には関連ドキュメントをよく読んで先に進んでください。

再度 Begin process to enable all featuresをクリックします。

Organizationのすべての子アカウントに承認リクエストが送信されます。現在の状況をみるにはView all feature request approval statusのリンクをクリックします。

もしOrganizationに子アカウントがある場合には、すべての子アカウントでリクエストの承認作業が必要です。

今回作業したOrganizationはマスターアカウントのみ（子アカウントなし）のため承認プロセスはありません。Finalize process to enable all featuresをクリックします。

再度Finalize process to enable all featuresをクリックします。

ENABLE ALL FEATURESが有効になりました。

これでAWS SSOを利用するための前提条件の1つが完了です。

2. AWS Organizationsで子アカウントをもうひとつ作ってみる

子アカウントの作成はAWS SSOを利用するにあたり必須作業ではありません。今回は試しに入れるか確認したかったので新規アカウントを作成しています。

AWS Organizationsの画面で、必要事項を記入してアカウントを作成します。

今回はSSOTest1というアカウントを作成してみました。

作成が完了しました。

子アカウントの準備ができたので次に進みましょう。

3. AWS Microsoft ADを作成する

AWS SSOを利用するためにはActive DirectoryがVirginiaリージョンで必要です。今回はMicrosoft ADサービスを利用することにします。

AWS Directory Serviceのコンソールを開いて、リージョンをVirginiaにしたらディレクトリのセットアップを開始します。

（今回の環境ではVirginiaにデフォルトVPCがないためこの後に作成していますが割愛します）

Microsoft ADを作成するために必要な情報を入力します。

入力した内容を確認したらMicrosoft ADの作成をします。

20〜30分ほどすると、Microsoft ADが作成されました。

AWS SSOを利用するためにはMicrosoft ADへのユーザー作成が必要です。管理者ユーザー（admin）ではSSOにサインインできないのでご注意ください。

今回はこの作業の後、Windows EC2を起動してActiveDirectory管理センターをインストールしてユーザー（ueki.kazuki）を作成しています。

4. AWS SSOでAWS Microsoft ADと接続する

ここまででAWS SSOを利用するための準備が整いました。

AWS SSOのコンソールを開いてEnable AWS SSOをクリックします。

まず作成したMicrosoft ADとの接続を行います。Connect your directoryをクリックします。

プルダウンメニューから作成したディレクトリ（corp.example.com）を選択します。

またSSOサインインする際のURLを決定します。このURLは後から変更できないのでご注意ください！

ディレクトリとの接続設定が完了しました。

5. AWS SSOでログイン先のAWSアカウント／ADユーザー／権限（Permission sets）を紐付ける

次にAWSマネージメントコンソールにサインインするための設定を行います。

AWS SSOのトップページに戻って Configure SSO access your AWS accounts をクリックします。

サインインしたいAWSアカウントをチェックします。

AWSアカウントにADユーザーを紐付けますのでAssign usersをクリックします。

次の画面では紐付けたいADユーザーまたはグループを選択することができます。

Usersを選択して、ユーザーを検索するとみつかったユーザーが表示されます。チェックをつけてNext: Perission setsをクリックします。

Permission setは、選択したADユーザーがAWSコンソールにサインインする際にどの権限を持つかを設定できます。

まだPermission sets（以降 権限セット）が作成されていないので、Create new permission setをクリックします。

今回はデフォルトでいくつか用意されている権限セットの中からAdministratorAccessを選択します。

権限セットを選択したらCreateをクリックします。

ADユーザーにAdministratorAccessを紐付けたらFinishをクリックすれば設定完了です。

選択したAWSアカウントに対して、ueki.kazukiユーザーがAdministratorAccess権限でサインインするための設定が行われます。

これでSSO設定は完了です！

SSOでのログイン

それでは早速SSOでマネージメントコンソールにサインしてみましょう。

4. AWS SSOでAWS Microsoft ADと接続するで設定した、SSOサインイン用のURLにブラウザでアクセスします。

サインイン画面が表示されるので、ADユーザー名とパスワードを入力してサインインしましょう。

サインインするとユーザーポータルが表示されます。今回はマネージメントコンソールにサインインするための設定を行ったのでアイコンが表示されていますね。

AWS Management Consoleのアイコンをクリックすると、ueki.kazuki ユーザーがサインインできるAWSアカウント候補がリストアップされます。

今回はSSOTest1アカウントにサインインしてみましょう。

AWSアカウントにサインインする時に、どの権限セットでサインインするか選択することができます。今回はAdministratorAccessのみ設定したので1つしか表示されませんが、たとえばViewOnlyAccessのように読み取り専用でサインインすることも可能です。

AdministratorAccessをクリックするとサインイン処理が開始されます。

マネージメントコンソールにサインインすることができました！！

アカウント情報をみてみると、確かにSSOTest1アカウントに AdministratorAccess Roleでサインインしていることが確認できました。

まとめ

AWS SSOを利用して、ADユーザーでAWSマネージメントコンソールへのサインインを試してみました。

なお、これまでもAWS Directory Serviceを使って、ADユーザーでAWSマネージメントコンソールにサインインはできました。しかし今回のSSOで 複数の AWSアカウントを利用することができるようになったわけです。

AD Connectorを利用して既存のActive Directoryとの連携もできるようなので、開発用・本番用など複数アカウントを利用している方には便利ではないでしょうか。

またSAMLに対応しているため、各種SaaSへもシングルサインオンが可能です。すでにいくつかのサービスとの連携が用意されています！

ちょうどID統合化作業を進めていたので、今回のリリースはとてもうれしいです :)

ぜひ早くTokyoリージョンにも！ そして複雑な組織に対応するために、マスターアカウントだけでなく Organizational Unit 単位でSSO設定ができればうれしいと思いました！