このブログサイトはAstro + WordPressの技術構成でAWS上に構築しており、記事の投稿は各ユーザーがWordpressへログインし、Wordpressの管理画面から記事を執筆しています。
この時、Wordpress側のユーザーアカウントをAWSで管理できればアカウントを一元管理できるし、セキュリティ面も強固になって良いのでは？という話になり、AWSで管理しているIAM Identity CenterのユーザーでWordpressにログインできるように構築しました。
その時の作業の備忘録と、作業するにあたって必要となった知識を整理してまとめます。
AWS側のユーザーでWordpressへログインを実現するために必要となるキーワードは、「SSO」「SAML」です。
まずは基本的な知識の概要から。
SSOとは
SSOはシングルサインオンの略で、１つのサービスへのログインで他のサービスのログインを実現するための仕組みです。
皆さんも、新しくWebサービスのアカウントを作成する際に、「Googleアカウントでログインする」とか「Xのアカウントでログイン」「Facebookアカウントでログイン」のようなボタンを見たことがある人は多いかと思います。
以下のようなボタン（こちらはQiitaのログインページにあるSSO）
このように、他のサービスのアカウント情報を利用する形で別のサービスにログインできるようにする仕組みがSSO。
SSOのメリット
SSOを利用することのメリットは、利便性の向上とセキュリティの向上です。
サービスのアカウントを新たに作成する場合、ユーザーのIDとパスワードが必要になります。ユーザーにとっては管理するアカウントのIDとパスワードが増えるのは手間になります。
また、同じパスワードを使いまわしてしまった場合、パスワードが流出してしまった場合のリスクが大きくなってしまいます。
SSOを利用することで、パスワードを一元管理し、サービスごとに毎回IDとパスワードを入力する手間も省くことができるようになるため、利便性が向上します。一元管理されているパスワードが流出してしまうと、様々なサービスを不正利用されるリスクが高まってしまいますが、多要素認証を追加するなどして、認証を強化することで、全体として安全性を高めることが期待できます。
SAMLとは
一口にSSOと言っても、実現方法にはいくつかの種類があり、代表的な仕様に「OAuth」や「SAML」があります。
今回対象となっている、AWSのユーザーでWordpressにログインする方法は、SAMLを用いています。
SAMLは、Security Assertion Markup Languageの略でXMLベースのプロトコルによって、SSOを実現する仕組みです。
SAMLの仕組みを説明するためには、３つのキーワードが必要になります。
- IdP(Identity Provider)
- ユーザーの認証を行う機関
- SP(Service Provider)
- ユーザーが利用するサービス
- SAMLアサーション
- 認証情報などが記載されたXML
- IdPがSPに発行
今回の例ではAWSがIdPにWordpressがSPに該当します。
認証の流れは以下です。
- ユーザーがSPにアクセス（Wordpressにアクセス）
- SPがIdPにリダイレクトし、認証依頼を出す（WordpressがAWSに認証依頼を出す）
- IdPが認証し、SAMLアサーションをSPへ返す（AWSが認証し、WordpressにSAMLアサーションを返す）
- SPがアサーションを検証して、正しければログイン済みにする（Wordpressが検証をしてログイン済みにする）
実現までの手順
ここからは、具体的な構築手順になります。
WordPressにSAMLのプラグインを導入
WordPressのいいところはプラグインが充実しているので、自前で実装せずともプラグインで補える部分が多いところ。SAMLもプラグインを使って実現しました。
今回導入したプラグインは、「miniOrange SSO SAML 2.0」というプラグイン
WordPress シングル サインオン プラグインは、SAML 経由の IDP 認証情報を使用して WordPress (WP) サイトへのシームレスなアクセスを提供します。 SAML を使用した WordPress SSO ログインでは、マルチサイトおよび複数の IDP のサポートも提供されます。
https://plugins.miniorange.com/ja/wordpress-single-sign-on-sso後で設定画面を色々操作しますが、一旦導入が完了したらAWS側へ。
AWS(IAM Identity Center)でアプリケーションを追加する
AWS側の設定は全てIAM Identity Centerで行います。
ということで、マネジメントコンソールからIAM Identity Centerを開きます。サイドメニューに「アプリケーション」があるので、選択し、「アプリケーションを追加」ボタンをクリック。
「設定するアプリケーションがある」を選択し、「SAML2.0」を選択して次へ。
表示名を適当に入力。（ここではwordpressとした）
ここで、IAM Identity Centerのメタデータファイルをダウンロードできるので、ダウンローとしておく。
ダウンロードが完了したら、一度Wordpressの画面に戻る
WordPressでメタデータをアップロードとダウンロード
プラグインの設定画面から、「サービスプロバイダーの設定」タブを開くと、IDPのメタデータをアップロードできる箇所があるので、ここで先ほどダウンロードしたメタデータをアップロードする。
続いて、「サービスプロバイダのメタデータ」タブき、メタデータXMLをダウンロードする。
ダウンロードが完了したら再びIAM Identity Centerに戻る。
IAM Identity Centerにメタデータをアップロード
先ほどのアプリケーション設定画面の下の方に、アプリケーションメタデータを設定する箇所があるので、SAMLメタデータファイルを選択し、Wordpress側でダウンロードしたメタデータを選択して送信します。
アプリケーションの追加が完了すると、カスタマー管理のタブに追加したアプリケーション表示されます。
属性マッピングを編集
続いては、属性マッピングを編集します。
アプリケーションの詳細を開き、アクションから「属性マッピングを編集」を選択
以下の内容で保存する。
この設定により、Wordpress側のユーザーの属性と、IAM Identity Centerのユーザー属性がマッピングされるようになります。
ユーザーまたはグループの割り当て
あとは、どのユーザーがこのアプリケーションを利用するかを割り当てます。アプリケーションにユーザーを１人ずつ割り当てることも可能ですが、ここでは、グループを作成して、グループを割り当てることにしました。
- IAM Identity Centerでグループを作成
- アプリケーションで、作成したグループを割り当てる
- アプリケーションを利用したいユーザーを、作成したグループに割り当てる
WordPressでの権限の設定
最後に、IAM Identity CenterのユーザーでWordpressにログインした際のデフォルトの権限を設定します。
WordPressのSAMLの設定から、「属性/権限グループのマッピング」を選択し、適切な権限に設定します。ここでは、投稿者をデフォルトの権限としました。
ここまでで設定は終わりです。
ログインできるか確かめる
AWSから一度ログアウトし、アプリケーションと紐づいているIAM Identity Centerでログインし直します。
すると、アクセスポータルのアプリケーションタブで、設定したアプリケーションが追加されていることが分かります。
クリックして、Wordpressのサイトでログイン済みの状態になっていれば、設定は成功です。
設定がどこかで漏れていたり、間違っている場合、以下のようなエラーが出ます。エラーが出る場合は、設定で漏れているところや間違っているところがないかを改めて確認してみてください。
まとめ
- SSOは一つのアカウントで他のサービスにログインする仕組み
- SAMLはXMLを使ってSSOを実現する仕様の一つ
- IAM Identity Centerのユーザーを使って他のアプリケーションへのSSOが実現可能
- IDPとSP間でメタデータを設定し、属性マッピングを設定することでSAMLによるSSOが実現できる
AWSのユーザーでSSOやSAMLを実現したい人の参考になれば幸いです。