ADFSを利用してAWSにシングルサインオンする方法

みなさんこんにちは、国井です。

ADFSを使ってシングルサインオンを実現する方法として、ADFS+Office 365というのが有名ですが、ADFSサーバーを利用して実現できるシングルサインオンは何もOffice 365だけではありません。

ということで、今日は国井が担当しているADFSトレーニングでも扱っている、ID連携の手法のひとつである、ADFSとAmazon Web Services(AWS)を組み合わせて、Active DirectoryでサインインしたユーザーがADFSから発行されたトークンを利用してAWSにシングルサインオンする設定というのを見てみたいと思います。
(ちょっとだけ宣伝させてもらうと、ADFSトレーニングではOffice 365に限らず、お客様の要望に合わせて様々なクラウドサービスとのシングルサインオンの実装方法とその運用(デバイス認証/2要素認証、トラブルシューティングなど)を紹介しているので、ご興味があれば気軽にご参加ください。)

■ADFS+AWSの処理フロー
AWSのシングルサインオンにはSAMLプロトコルのIdp Initiatedプロファイルを使うため、Office 365のシングルサインオンのように、Office 365のサイトにアクセスしてからシングルサインオンを始めるのではなく、ADFSのサイトにアクセスしてからAWSにアクセスするという処理フローになります。
(そういえば、SalesforceのシングルサインオンもIdp Initiatedでしたね)

フロー図を書こうと思ったのですが、AWSのWebサイトの中で既に図が書かれていたので、
そちらを参考にしていただくとよいでしょう。

・オフィシャルアナウンスメント
http://aws.typepad.com/aws/2013/11/aws-identity-and-access-management-using-saml.html

なお、今回参考にさせてもらったWebサイトはAWSのWebサイトになります。こちらのサイトにも手順が掲載されているのだけれど、英語だったこと、ADFS2.0を使っていること、そして何よりも手順の中で何をしているかを自分自身がより深く知りたかったから、ということがあって今回の投稿を書いてみました。

■作業全体のながれ
1.ADFS→AWSへのフェデレーションメタデータのアップロード
2.AWSにグループを作成
3.Active Directoryにグループを作成
4.証明書利用者信頼とクレームルールの作成

さあ、早速始めましょう。

■フェデレーションメタデータの取得とアップロード
AWSとADFSの間で信頼関係を設定するにはフェデレーションメタデータの交換が必要ですので、最初にADFSサーバーのフェデレーションメタデータをAWSにアップロードします。

ADFSサーバーのフェデレーションメタデータ(https://<ADFSサーバー名>/federationmetadata/2007-06/federationmetadata.xml)にアクセスし、表示されたXMLファイルを名前を付けて保存します。(ちなみにIE11だと表示の関係上、無意味な文字列のように見えますが、互換表示設定でADFSサーバー名を追加すれば、ちゃんとXMLファイルの中身が確認できます)

image

image

そして保存したフェデレーションメタデータをAWSに登録します。

AWS Management ConsoleからIdentity & Access Managementを開き、Identity ProvidersからCreate SAML Providerでプロバイダを作成します。

image

プロバイダの作成画面で、プロバイダタイプにSAML、プロバイダ名にADFSと設定し、Metadata Documentの欄でメタデータをアップロードします。

image

ここまでで、SAMLプロバイダの作成とメタデータのアップロードが完了しました。

image

作成したSAMLプロバイダを開くと、Provider ARNという文字列が入っていますが、これはSAMLプロバイダの識別子であり、後で必要になるので、控えておきましょう。

image

■AWSのグループ作成
続いてAWSに権限が割り当てられたグループを作ります。
通常、ADFSによるID連携ではユーザー名で2つのシステムを連携させますが、AWSではグループを連携させます。ここでは画面のように、ADFS-DevとADFS-Productionsという2つのグループを作成しました。名前は何でもよいのですが、後ほどの手順の関係上、必ずADFS-で始まる名前にしてください。

image

グループのプロパティを開き、Trust RelationshipでTruested Entitiesに先ほど控えておいた識別子を登録しておきます。(ここの関係性がうまく説明できないのですが、ご存知の方がいたら、ご連絡いただけるとありがたいです)
2014年12月5日追記 Amazonの方からコメント欄でご説明をいただきました(感謝!)。ぜひご一読ください。

image

また、必要に応じてグループにはAWS内での操作権限を割り当てておいてください。

■Active DirectoryにAWS用のグループを作成
Active DirectoryにAWS用のグループを作成します。グループは必ずAWS-で始まる名前であること、それから、-(ハイフン)の後ろがAWSで作ったグループの名前と同じであることが必要です。
そこで、私はAWS-DevとAWS-Productionという名前のグループを作成しました。
また、グループにはAWSを利用するユーザーを追加しておくことも忘れずに。

■証明書利用者信頼の作成
操作はADFSサーバーに移って、証明書利用者信頼を作成し、AWSのフェデレーションメタデータの登録とAWSに渡すトークンに含まれるクレームの定義を行います。

ADFS管理ツールから証明書利用者信頼を右クリックし、[証明書利用者信頼への追加]をクリック。

image

[証明書利用者信頼の追加ウィザードの開始]画面で、開始をクリック

image

[データソースの選択]画面で、[フェデレーションメタデータのアドレス]欄に
https://signin.aws.amazon.com/static/saml-metadata.xml」と入力します。
残りの画面はすべて次へをクリックして完了します。
(AWSのフェデレーションメタデータは公開されているので、URLを登録するだけでADFSサーバーが自動的に取りに行ってくれます。)

AWS003

証明書利用者信頼の追加ウィザードの最後で、チェックが付いたままの状態で完了すると、

AWS008

要求規則の編集画面が登場します。発行変換規則を追加します。

AWS009

要求規則テンプレートには[入力方向の要求を変換]を選択して、

AWS011

入力方向:Windowsアカウント名
出力方向:名前ID
出力方向の名前IDの形式:永続ID
となるようにクレームの設定をし、適当な要求規則名を入力して、完了をクリックします。

AWS012

再び、規則を追加します。

AWS013

要求規則テンプレートに[LDAP属性を要求として送信]を選択し、

AWS010

属性名:Active Directory
LDAP属性:E-Mail-Addresses
出力方向の属性の種類:https://aws.amazon.com/SAML/Attributes/RoleSessionName
となるようにクレームの設定をし、適当な要求規則名を入力して、完了をクリックします。

AWS014

再び、規則を追加します。

AWS015

要求規則テンプレートに[カスタム規則を使用して要求を送信]を選択し、

AWS017

クレームルールとして、次の内容を記述します。

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => add(store = “Active Directory”, types = (“http://temp/variable”), query = “;tokenGroups;{0}”, param = c.Value);

また、適当な要求規則名を入力して、完了をクリックします。

再び、規則を追加します。

AWS019

要求規則テンプレートに[カスタム規則を使用して要求を送信]を選択し、

AWS017

クレームルールとして、次の内容を記述します。

c:[Type == “http://temp/variable”, Value =~ “(?i)^AWS-“] => issue(Type = “https://aws.amazon.com/SAML/Attributes/Role”, Value = RegExReplace(c.Value, “AWS-“, “arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/ADFS-“));

このルールにより、AWSに作ったAWS-で始まるグループとActive Directoryに作ったADFS-で始まるグループのマッピングがなされます。それから、arn:aws:iam::123456789012:saml-provider/ADFSの部分ですが、必ずAWS Management Consoleで確認した識別子に置き換えておいてください

また、適当な要求規則名を入力して、完了をクリックします。

AWS020

すべての画面を閉じて設定は完了です。

■アクセスの確認

ここまでできたら、アクセスを確認してみましょう。
SAML Idp Initiated用のURLである
https://<ADFSサーバー名>/adfs/ls/IdpInitiatedSignOn.aspx
にアクセスして、サインインすると、

image

自動的にAWS Management Consoleにリダイレクトされます。
ADFS-DevとADFS-Productionの両方のグループに所属しているユーザーの場合には、
どちらのグループとしてAWSに入るか、選択する画面が表示されます。

image

image

以上です。
AWSのシングルサインオンの場合、ユーザーを連携させるのではなく、
グループを連携させるという連携方法を採用しています。
このことは、ユーザーアカウントを同期させる手間が不要という意味で非常に便利なものだと思います。

また、ADFS経由でAWSにアクセスさせることで、ADFSお得意のデバイス認証や2要素認証などと組み合わせて利用できるということですので、この点も組織での効果的なシングルサインオンの実装を検討している方は見逃せないポイントですね。

スポンサーリンク

コメント

  1. 千葉悠貴 より:

    国井様

    いつもブログを拝見させていただいおります。
    AmazonDataServiceJapanでAWSコンサルタントをしている千葉と申します。

    IAMRoleとIdentityProviderの関係性ですが、SAMLを使ったSSOを行う場合、AssumeRoleWithSAMLというIAMの機能を利用することになります。
    ご記載の手順はAssumeRoleWithSAMLを設定する手順で、IAMRoleにIdentityProviderの信頼ポリシーを設定しています。
    信頼されたProviderで認証されたリクエストに対して、IAMRoleはAWSサービス(ここではマネージメントコンソール経由のAPI利用)の一時的な認証トークンを発行します。

    詳細については以下のドキュメントが参考になるかと思います。
    http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html
    http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/create-role-saml.html

    よろしくお願いいたします。

    • sophiakunii より:

      千葉様
      ご連絡ありがとうございます。
      (しかも投稿間もなくご連絡をいただき、本当に感謝しております)
      SAMLプロバイダからIAMRoleにリクエストが投げられるようにするためにIAMRole内で登録をしているのですね。
      ご連絡いただいた内容でよく理解できました!

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*