AWS とのシングルサインオンを試してみる – 設定 後編

はじめに

前回、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 の認証などとも組み合わせてみたいですね。

APN Consulting Partner
スーパーソフトウエアはAWSパートナーネットワーク(APN)のコンサルティングパートナーです。