はじめに
前回は、OpenAMとAWS側の設定（手順1〜3）を行いました。
今回は仕上げの設定を行い、いよいよ動かしてみたいと思います。
4. OpenAMにSAMLユーザの作成
OpenAMに戻りSAMLで認証するユーザを作成しましょう。
左側のメニューから「Subjects」を選択し、「新規」からユーザを作成します。
ユーザ名などは適当で大丈夫です。
今回はsamltestとしてみました。
作成したユーザの編集画面に遷移し、社員番号の項目に、前回の最後に控えた「ロールARN」と「信頼されたエンティティ」を以下の通りカンマで区切った値を設定します。
「<ロールARN>,<信頼されたエンティティ>」
ここまで来ればもう一息です。
5. 属性マッパーの設定
左側のメニューから「Applications」→「SAML」を選択します。
トラストサークルの設定が表示されるので、エンティティの設定という段から「urn:amazon:webservices」を選択し、「表明処理」のタブを開きます。
属性マップに新しい値として以下を追加します。
・https://aws.amazon.com/SAML/Attributes/Role=employeeNumber
・https://aws.amazon.com/SAML/Attributes/RoleSessionName=uid
保存をすれば、設定はこれで完了です！
6. 試してみる
それでは実際に動かしていきますが、1点だけ訂正です。
前々回に動作のイメージ図を描いたのですが、OpenAM+AWSでは少し動作が異なるようです。
SAMLでは大きく分けて以下の2つのフローがあります。
・IdP-initiated → IdP（今回でいうOpenAM）側から始まるフロー
・SP-initiated → SP（今回でいうAWS）側から始まるフロー
元の想定では、AWSへのアクセスから始まるということで後者の想定でしたが、OpenAM+AWSでは、前者のフローとなるようです。
そのため、OpenAMで用意されたエンドポイントにアクセスすることでフローが始まります。
認証後は想定通り、ログイン済みの状態でAWSのコンソールへ遷移するはずです。
ということで、以下のエンドポイントにアクセスします。
http://localhost:8080/AM-eval-5.0.0/idpssoinit?metaAlias=/idp&spEntityID=urn:amazon:webservices
OpenAMのログイン画面が表示されるので、4で作成したユーザでログインしましょう。
ログイン後、自動的にAWSへ遷移するかと思います。
右上を確認すると、確かにログイン済みになっていますね。
AWSのログイン画面が表示されることなく、認証済みの画面に遷移することに成功しました。
EC2を開いてみましょう。
前回、ロールを設定した際にEC2の権限を付与していないため、操作ができない状態になっています。
それでは権限を与えたS3の方を見てみましょう。
こちらは意図した通り、操作できる状態になっていますね。
ということで、OpenAMの認証を使ってAWSにログインし、事前に設定した権限を反映することに成功しました！
おわりに
計3回に渡って設定方法をご紹介してきましたが、無事に当初の目標を達成することができました。
特筆すべき点としては、AWSにあらかじめ対応するユーザを作っておく必要がない、ということです。
これにより、SAMLで認証するユーザの権限だけを意識すればよいので、管理がだいぶ楽になるかと思います。
今回はOpenAMというパッケージを利用したこともありますが、設定も簡単にできてしまいました。
機会があれば、Railsの認証などとも組み合わせてみたいと思います。
