はじめに

AzureのサービスにEntraID(旧称:Azure Active Directory(AzureAD))と呼ばれるサービスがありますが、EntraIDはIDやアクセス管理が行えるクラウドベースのサービスです。

Azureを使用するユーザーはもちろん、その他のSaaSアプリのユーザー管理も行えます。
また、オンプレミスのADで管理していたユーザーをEntraIDと同期してSaaSアプリケーションのユーザーとしてそのまま使用することもできます。
使用していた情報を流用できるのは、移行コストもユーザー影響も少なくて便利ですね！

※EntraIDの詳細ついては以下公式ドキュメント参照
Microsoft Entra ID のドキュメント

そんなEntraIDですが、SAMLという認証の仕組みを使ってSSO(シングルサインオン)を実現させることができます。
今回はそのSAMLをEntraIDで実現するための設定項目について解説しようと思います。

そもそもSAMLとは

SAML(さむる)とはSecurity Assertion Markup Language という、Webアプリのシングルサインオン(SSO)を実現するXML(HTMLみたいな言語)ベースの規格です。

2002年にOASISによって策定され、2005年にはバージョン2.0がOASIS標準として承認されています。EntraIDでのSAML認証はアプリ側がSAML2.0に対応している必要があります。
SAML認証は異なるドメイン間でのユーザー認証を可能にするため、SSO(一回のユーザー認証)で複数のクラウドサービス等にログインが可能になるという仕組みなわけです。

昨今は色々なアプリやサービスを使って皆さんお仕事をしていると思います。
例えば、
①営業職員が使う説明資料や商品を管理するアプリ
②訪問先の顧客情報を管理しているアプリ
③1日のスケジュールなど予定を管理するクラウドサービス
他にもコミュニケーションツールやOffice製品などですね。

SAMLを使用しない場合はこれらのサービスやアプリごとにユーザー、パスワードを作成する必要があり、どのアプリにどのパスワードを設定していたか忘れたり、パスワードを使いまわしていて仮に漏洩してしまった場合ほとんどのサービスにログインされてしまうなんてことが起きる可能性も0ではありません。
SAMLを使用したSSOはこういった面倒を防止するのに役立ってくれます。

参考記事：https://tech-blog.rakus.co.jp/entry/20230301/saml

SAML認証フローの概要図

SAMLの認証フローは以下のような形になります。

Idp：認証情報を提供する、シングルサインオンのサービス提供側

SP：認証情報を利用するクラウドサービス(SaaS)やアプリケーションサービス側(Office365等)

①SP起点の場合

②Idp起点の場合

上記はいずれもIdpに未ログインの場合の処理で、初回ログイン後はユーザー側で保持しているSAML認証情報(SAMLアサーション)を利用してSPにアクセス可能となります。

EntraIDでSAMLを設定してみる

EntraIDでSAMLを実装する場合、先ほどの説明のIdpの部分にEntraIDが当てはまります。
SAML検証用のアプリがありましたのでそちらを使っていきます。
https://sptest.iamshowcase.com/index#intro

参考：https://idmlab.eidentity.jp/2018/02/samlidpsp.html

※アプリの登録手順は省略します。

①「すべてのアプリケーション」から対象のアプリを選択する

②「シングルサインオン」-「SAML」を選択する

③参考サイトの通りに値を入力する

④フェデレーションメタデータXMLをダウンロードする

フェデレーション：異なるシステムやサービス間でアカウント認証の連携を行うこと

⑤検証用サイトにファイルをアップロードする

フェデレーションメタデータXMLにはIdpとSPで信頼関係を築くために必要な情報が記述されているためSP側にその情報を登録する。

⑥URLが払い出されるのでアクセスする

⑦ログインユーザーを選択する

※SAMLの挙動をわかりやすくするためにユーザー割り当て未実施の状態で検証

⑧アプリケーションにアクセスする権限がないエラーがでる

なのでアプリにユーザーを割り当てます。

⑨ユーザーを割り当てる

⑩先ほど控えたURLに接続する

今回はアカウントの選択なしにログインできました！
検証用アプリなのでイメージしづらいところはあるかもしれませんが
利用するアプリの数が増えるほどSAMLの恩恵を感じられるはずです。

実際の業務だとアプリ側にIdpの情報を登録したり
要件や設計に応じて必要な値が変わってきたりするかと思います。
今回は主要な設定値の説明を記載して終わりにします。

基本的なSAML構成

・識別子(エンティティID)
これは、IdP から見たアプリの識別子です。
多くの場合、サインオン URL 値が識別子に使用されます (そうでない場合もあります)。
アプリ側でこれを "エンティティ ID" と呼ぶこともあります。
※Idp内で一意の値である必要がある

・応答URL
ID プロバイダー (IdP) から見たアプリの URL。
IdP は、ユーザーが IdP にサインインした後、ここでユーザーとトークンを送信します。
これは、SAML アサーションコンシューマーエンドポイントとも呼ばれます。

・サインオンURL
サービスプロバイダー (SP) によって開始された SAML フローでユーザーがアプリにサインインするための URL。
サインオンURLは認証開始のURL、応答URLは認証完了後のレスポンスをアプリ側に送るためのURL
※アプリ側では応答URLからアクセストークンを取得する処理を記述している(はず…)

属性とクレーム

属性：ユーザーに関する情報でアプリケーションの処理で必要に応じて使用される
クレーム：ユーザーに関する情報なのは属性値と同じだが認証認可のプロセスの間で使用され役職や部署などのクレーム情報に応じてアプリ上のアクセス権限を分けることも可能。

どのクレーム名の設定が必要かはアプリ側の要件によります。

SAML証明書

EntraIDがアプリケーションに対してSAMLレスポンスを返す際に使用される。
EntraIDはSAMLレスポンスにSAML署名証明書を利用して署名をします。
アプリは、受け取ったSAMLレスポンスを検証し、
問題がなければ信頼しているIdPであるEntraIDから送られていることが証明され、
アプリへのアクセスを許可する動作となります。
※EntraIDが発行する証明書の有効期限は3年が最大

アプリのセットアップ

・ログインURL
・ログアウトURL
テナントに対するログインURLのこと
アプリ側でIdpに対してアクセスする場合にこのURLに対して繋ぎに行く(はず…)

・Microsoft Entra 識別子
SPからどのIdpに対して認証情報を確認しに行くか判断するための識別子
⇒マルチテナントのSAMLなどを実装する場合はこの辺の情報をアプリ側で使う(はず…)

さいごに

以上がEntraIDを用いたSAML認証についての説明でした。
説明ベースでイメージがしづらい部分もあるかもしれませんが
参考になれば幸いです。