【ご挨拶】
こんにちは、2021年度入社のS.R.と申します。
新年を迎えたかと思えば、早くも3月が始まってしまいました。
花粉の脅威に怯える今日この頃、皆様はいかがお過ごしでしょうか？

【はじめに】
2023年の年末に私が執筆した第一回社内システム開発活動報告が公開されてから約2カ月が経過しました。
また、2024年の2月には別の開発メンバが執筆した第二回社内システム開発活動報告が公開されています。
今回は第三回社内システム開発活動報告ということで、簡単な現状報告と習得した技術について書きたいと思います。
まだ第一回・第二回の活動報告を読んでいない方は今回の活動報告と併せてご確認ください。

社内システム開発を通して習得した技術には、言語、フレームワーク、AWSなど数多くありますが、今回の報告ではSAML認証について紹介したいと思います。
SAML認証って何だろう？という方はこの記事をきっかけに一緒に勉強しましょう。
SAML認証については、勉強しながら社内システム開発を行ったためこの記事の内容に誤りがある可能性があります。
誤りを見つけた場合は、社内システム開発メンバにこっそり教えてください。

【現状報告】
本プロジェクトの現在の状況としては、製造工程が完了し単体テスト工程を実施しているところです。
作業期間としては、1月上旬から2月下旬までの約2カ月で製造工程を実施しました。
そして、2月下旬から3月下旬までの約1カ月で単体テスト工程を実施する予定です。
開発したシステムを社員の皆様に公開できる日は、もう少し先になりそうです。

【SAML認証とSSO】
さて、ここからが今回の本題です。
そもそもSAML認証とは何でしょうか？
SAML（Security Assertion Markup Language）認証とはSSO（Single Sign On）の仕組みの1つです。
Markup Languageと聞いてHTMLやXMLの仲間かな？と感じた方もいるかと思います。
SAML認証では認証情報の通信をする際にアサーションやトークンと呼ばれる（どちらも同じ意味）XML形式のデータをやり取りします。

XMLとは何でしょうか？
XMLとはタグに囲まれたデータの集まりで、SAML認証以外でもシステム間でデータをやり取りする際などに使用されます。
タグは<タグ名>データ</タグ名>のような形式で記載されます。
あまり重要ではないので、XMLの詳細についての説明は省略します。

SSOとは何でしょうか？
SSOとは1度のログインで複数のサービスを利用できるようにする仕組みのことです。
皆様もウェブサービスなどを利用する際に「Googleでログイン」のようなボタンを見たことがあると思いますが、これもSSOの仕組みの1つです。

SSOの利点は何でしょうか？
それは、1つのIDとパスワードで複数のサービスを利用できることです。
利用者はサービス毎にIDやパスワードを作成したり覚えたりログインしたりする必要がなくなります。
そのため複数のサービスでのパスワードの使いまわしを防止することができます。
また、開発者はサービスを開発する際に、ログイン関連の処理を開発する工数を減らすことができます。

では、SSOの欠点は何でしょうか？
それは、1つのIDとパスワードで複数のサービスを利用できることです。
SSOの利点と矛盾していますが、これは利点でもあり欠点でもあります。
攻撃者は1つのIDとパスワードを入手することで、複数のサービスを不正に利用できてしまいます。
そのため利用者はパスワードを複雑で推測困難なもの（パスフレーズなど）にしたり、数分間かつ1度だけ有効な認証コード（ワンタイムパスワード）などの多要素認証を設定したりするなどの対策が必要です。
皆様もメールアドレスや電話番号に、認証コードが送信されてくる形式の多要素認証を利用したことがあると思います。

【SAML認証の仕組み】
SAML認証はどういう仕組みなのでしょうか？
まず、SAML認証には利用者・SP（Service Provider）・IdP（Identity Provider）の3者が登場します。
利用者とはサービスの利用者のことで、皆様のことを指します。
SPとはサービスの提供者のことで、ここでは開発した社内システムのことを指します。
IdPとは利用者のIDを管理するサービスの提供者のことで、社内システムではGoogleを使用しました。

この3者でどのように認証するのでしょうか？
処理の流れとしては以下の通りです。

SAML認証処理の概要

事前準備としてSPにはIdPの情報を設定し、IdPにはSPの情報を設定しておきます。
SPにはIdPのID（Entity ID）・SPが利用者認証をIdPに依頼するページのURL・IdPの証明書（X.509証明書）などを設定します。
IdPにはSPのID（Entity ID）・IdPが認証した利用者情報をSPが受け取るページ（ACS：Assertion Consumer Service）のURLなどを設定します。
これらのお互いに設定すべき情報をまとめたものをメタデータといいます。
この設定を行うことでSPとIdPはお互いを信頼した状態となります。
また、SPとIdPでは利用者を識別する情報（メールアドレスなど）を一致させておく必要があります。

SAML認証ではSPがSAML認証要求（SAML Request）を発行し、IdPがSAML認証応答（SAML Response）を発行することで利用者を認証します。
このSAML認証要求とSAML認証応答が、この記事の冒頭で説明したXML形式のデータです。
これらのデータは証明書を用いて検証することで、信頼している相手から送信されたものであることを確認します。

ここで少しでも処理の流れが想像しやすいように、業務チャット風に簡単にまとめます。
上記のSAML認証処理の概要と照らし合わせながらお読みください。

これらの認証の流れをSAML認証のSP Initiated SSOといいます。
利用者が最初にアクセスするのがSPで、SPからSAML認証を開始（Initiate）するSSOであるためです。
今回は詳細には紹介しませんでしたが、SAML認証にはIdP Initiated SSOというものもあります。
利用者が最初にアクセスするのがIdPで、IdPが提供するメニュー一覧などからSPにアクセスする場合に使用します。

【社内システムとSAML認証】
今回開発した社内システムでは、GoogleをIdPとしたSAML認証を用いたログイン方法を採用しています。
社員の皆様はあらかじめGoogleにログインしておくだけで、社内システムに自動でログインできるようになります。
社内システムが公開されたら、ログイン処理の裏ではこんなやり取りが行われているんだなと思い出してみてください。

【感想】
今回の社内システム開発を行うまでは、SSOの一つにSAML認証というのがあるらしいということしか知りませんでした。
そのため、SAML認証の仕組みを理解して実装するのは非常に困難でした。
この記事を読んだ皆様も、見慣れない略称や用語が多いと感じたのではないでしょうか？
私もSAML認証について調べて本も読みましたが、実際に実装してみるまでは処理の流れはよくわかりませんでした。
第一回の活動報告の際にも感じましたが、やはり勉強するだけではなく実際に手を動かしてみることが理解することへの近道であると思います。
この記事が皆様に少しでもSAML認証を知っていただくきっかけになれば幸いです。

社内システム開発は製造工程が完了し、単体テスト工程が始まりました。
私はウェブアプリの開発はもちろん、AWSの環境構築も担当しました。
初めて操作するAWSはわからないことも多く手探り状態でしたが、無事に起動・通信することができるようになりました。
テスト工程では数多くの不具合が見つかるかもしれませんが、挫けずに作業を進めたいと思います。

【参考資料】
社内システム開発でSAML認証機能を開発するにあたって、インプレスR&D社のSAML入門という本を読みました。
SAML認証について記載されたウェブサイトは数多くありましたが、私個人的には1冊にまとまっている本のほうがわかりやすいと感じました。
今回紹介しきれなかった内容や、具体的なSAML認証データの中身まで記載されています。
電子書籍版もあり、ページ数もそこまで多くはないので移動時間などに読んでみるのはいかがでしょうか？

また、SAML認証機能の開発にはsaml-idpというツールを使用しました。
このsaml-idpを使うことで、簡単に自身の端末でテスト用のIdPを起動することができます。
SAML認証機能を開発する際には、使用するツールの1つとして検討してみてはいかがでしょうか？
saml-idpの使い方はこちらのウェブサイトが参考になりました。

【おわりに】
第三回社内システム開発活動報告はここまでとします。
次回の報告をお待ちください。
ここまで読んでいただきありがとうございました。