現在のクラウド時代において、多くのアプリケーションがWeb上で動作し、シングルサインオン（SSO）にも対応しています。しかし、自社で開発したアプリケーションにSSOを実装しようとすると本格的な改修が必要となり、それに伴う相応のコストが発生します。
本連載では、Entra IDとSAML認証を使用して、アプリケーションを改修せずにSSOを実装する方法について説明します。これは、既存のアプリケーションを手早くSSO対応させたい場合に役立つ手法です。
初回となる今回は、最低限抑えておきたいSAMLの基本要素について確認をしたいと思います。
SAMLとは
SAMLは、異なる組織間でユーザー認証情報を交換するための標準規格で、SSOに利用されています。その最新バージョンである2.0は2005年3月に制定されており、非常に歴史のある認証プロトコルです。
SAMLでは、Assertion(アサーション)と呼ばれるXML文書を通じてユーザーの認証情報や属性、認可情報を交換します。このAssertionの内容は、Entra ID側で追加や変更を行うことができます。
SAMLに関する用語は以下となります。
| 用語 | 説明 |
|---|---|
| IdP | ユーザーの認証を行い、認証情報をSPに提供します。 今回はEntra IDがIdPとなります。 |
| SP | IdPから認証情報を受け取り、ユーザーにサービスを提供します。 今回はアプリがSPとなります。 |
| IdP Initiated SSO | SAML通信の方式の1つとなり、最初にIdPにアクセスして 認証を行い、その結果をもってSPにアクセスします。 |
| SP Initiated SSO | 最初にSPへアクセスし、そこからIdPに認証要求がリダイレクトされ、認証を行った後にSPにアクセスします。(今回の動作確認はこちらの方式を使用します) |
| entityID | SAMLのデータ内でIdPやSPを識別する識別子です。 |
| ACS (AssertionConsumerService) |
IdPから送られるSAML情報を受け取るSP側のURLです。 ユーザー認証が成功した後にリダイレクトされる場所となります。 |
Entra IDとSAMLのAssertion
Entra IDを用いたAssertionでは、Entra IDで扱う属性値をアプリケーションに連携することができます。これら連携する情報をSAMLでは「クレーム」と呼びます。
動作としては、「IdPで認証を行い、IdPから得られるAssertionの情報をクレームとしてSPに連携してアプリを利用する」という流れになります。
テストサイトでSAMLをテストする
実際にSAMLによるAssertionで情報が連携されるかテストをしてみたいと思います。
事前に必要な環境はEntra IDだけです。
SPはRSAが提供しているTest Service Providerを利用します。以後こちらのTest Service Providerを本記事では「テストAP」と呼称します。
テストAPにてテストに必要な情報を取得する
1.Test Service Providerのページに接続し、「Instructions」>「SP Initiated SSO」をクリックします。
2.表示された画面の上部に「DOWNLOAD METADATA」という項目があるので、クリックします。
3.表示された画面にて「entityID」の値と「ACS」の値をメモに残しておきます。
※ これらは後続の手順にて使用します。
Entra IDにテストAPの情報を登録する
1.Entra IDの管理センターに接続し、「ホーム」>「ID」>「アプリケーション」と進み「新しいアプリケーション」をクリックします。
2.「独自のアプリケーションの作成」をクリックします。
3.アプリの名前を入力して「作成」をクリックします。(名前は任意でOKです)
※ 入力後、画面下部に「エントリと一致する可能性がある次のアプリケーションが見つかりました」と表示される事がありますが、これは名前から類推された登録済みアプリが表示されたものとなりますので表示されても無視してください。
4.成功すると、画面右側に「正常に追加されました」とポップアップが表示され、アプリケーションが登録されます。
5.検証用の設定として一部設定を変更します。「管理」の「プロパティ」にある「割り当てが必要ですか？」を「いいえ」に設定して「保存」をクリックします。
IdP(Entra ID)とSP(テストAP)の関連付けを行う
1.「管理」>「シングル サインオン」から「SAML」を選択します。
2.「基本的な SAML 構成」の「編集」をクリックします。
3.「識別子の追加」と「応答 URL の追加」をクリックし、表示された入力欄にSPで取得したentityIDとACSの値を入力してから保存をクリックします。
4.「保存」後に✕等で画面を抜けると以下の画面が表示されますが、「いいえ、後でtestします」をクリックします。
5.元の画面の「3 SAML証明書」内の「フェデレーション メタデータ XML」をダウンロードします。
6.「属性とクレーム」の「編集」をクリックします。
7. 後続の確認で利用するために「属性とクレーム」の画面を表示し、控えておきます。
8.RSAのテストAPに戻り、「DOWNLOAD METADATA」で使用したページで「SUBMIT FILE」が表示されるまで下にスクロールします。
8.「CHOOSE FILE」をクリックし、先程ダウンロードしたフェデレーション メタデータ XMLファイルを選択し、「SUBMIT FILE」をクリックします。
9.以下の画面が表示されますので、「COPY URL TO CLIPBOARD」をクリックしてから「CLOSE」をクリックします。
このアドレスがWebアプリに相当するアドレスとなります。ブラウザからこのアドレスに接続する事で、SSOの動作確認を行う事が出来るようになります。
テストAPでAssertionの内容を確認する
ここからは実際にブラウザからアクセスして操作を行いますが、SSOの動作を確認するため、Entra IDとは別のブラウザの使用やブラウザの再起動を行ってから接続する事をお勧めします。
本記事では、Chromeのシークレット ウインドウを使用して確認を進めます。
1.先ほど「COPY URL TO CLIPBOARD」で控えたアドレスをブラウザに入力してアクセスし、認証画面が表示されたら認証を行います。
2.認証が成功すると以下の画面が表示されます。
3. そのまま下に画面をスクロールさせ、「Attribute Details」まで進みます。
4.「Attribute Details」にはAssertionに含まれる属性が表示されています。
5. 「Attribute Details」で表示されてた属性に、3-7.で表示させた「属性とクレーム」にある「クレーム名」の項目と同一のものが含まれている事を確認します。(Entra IDに記載のない属性についてはSAMLやEntra IDの仕様に基づく既定のものとなります。)
5.RSAのサイトの最下部にある「SHOW SAML ASSERTION」をクリックします。
6.クリックすると、Assertion全体を確認する事ができます。
7. 3-7.で表示させた「属性とクレーム」が含まれている事をここでも確認しておきます。
Assertionの内容を変更する
1.「属性とクレーム」にて「新しいクレームの追加」をクリックします。
2.「名前」と「名前空間」に任意の文字を入力し、「ソース属性」を設定してから「保存」をクリックします。
3.属性が追加された事を確認します。
4.再びRSAサイトへ接続し、追加した項目が反映されていることを確認します。
※ 反映されていない場合はブラウザを一旦終了し、再度認証を行って接続してください。
おわりに
今回はSAMLによる情報連携内容を確認する事を中心に記載しました。
次回は、Linux上で動作するアプリケーションを想定したSSO実装を記載したいと思います。
