前回までのあらすじ

とあるスタートアップの会社で、システム開発の片手間、社内の情シス担当としての業務も任されている二人の社員の話。外部クラウドサービスのユーザー管理で大変な苦労を強いられており、何とかならないものかと悩んでいるところ、たまたま挨拶回りに来たAWS請求代行サービスの営業担当（※突然ですが、今回から女性という設定にしました）から耳寄りな情報を得る。彼女が言うところによると、Oktaという製品を使えば、彼らの悩みが一気に解決されるというのだ。彼らにとって、これはまさしく救世主の登場に他ならなかった。興味を持った二人の情シス担当は、営業担当の女性から製品に関する詳しい説明を受ける。

Oktaがあるとすごく助かる人たちってどんな人たち？

第三話：専用テンプレートとSAML

――「社内でお使いの、外部クラウドサービスは何をお使いですか」
「えっと、今のところは、Microsoft 365、Google Workspace、Slack、Zoom、AWS、Sansan、奉行クラウド、Mail dealer … ですかね。でも、これからどんどん増えていく気配がビシビシしてます」
――「なるほど、多いですね。それだけ多いと、サービスごとにユーザー管理するのは大変だと思います」
「そうなんですよ。で、そのOktaを使えば、随分と楽になる、とか。でも、設定は、やっぱりメンドウなんですかね」
――「いえ、例えば、今、使っていらっしゃる、Google Workspace、AWS、Slack、Zoom に関しては、Oktaの Application catalogに専用テンプレートがあるので、それを使えば、最初の設定は、比較的簡単ですよ」
「テンプレートというのは、どんな感じのやつなんですかね」
――「はい、こんな感じです。これは、Slackのテンプレートです」

アプリケーション・カタログからslackを検索：

一般設定：

サインオンオプション：

「お、これは簡単そうだ。必要事項を入力していけば、そのまま使える、ってことですね」
――「はい、その通りです」
「ところで、残りの、Sansan、奉行クラウド、Mail dealer はどうなんでしょう？」
――「SAML連携できれば、使えますよ」
「え、サムギョプサル？ 今夜、韓国料理でも行きますか」
――「いえいえ、SAML [sæməl] です（笑）。Security Assertion Markup Languageの、それぞれの頭文字を取った略語です」
「何ですか、それ」
「アイデンティティプロバイダーとサービスプロバイダーの間で認証および認可データを交換するための標準規格です。簡単に言えば、Okta側、クラウドサービス側、それぞれの設定画面で、お互いのURL等、必要事項を入力すれば、連携させることができるのです」
「ん～～～。ちょっと、わからないなぁ」
――「簡単に言うと、こんな画面です」

SAML2.0を選択：

SAMLの構成画面：

――「Okta側の上記の画面で、シングルサインオンURL（SSO URL）、及びオーディエンスURIを入力します」
「えっと、それって、いったい何ですか？」
――「たいていの場合は、連携先のクラウドサービス側のSSO設定画面で確認できますね。ちなみに、SSO URLは、ACS URL (Assertion Consumer Service URL)と呼ばれることがあります」
「なるほど、そうなんですね。先ずはそこを確認、と」
――「次に、Okta側の SSO URLや証明書が表示されるので、これを取得します」

――「そして、今度は、連携先のクラウドサービス側の、SAML設定のような画面があるので、そこにOktaで取得した情報を設定すれば、完了です」
「あ、なるほど、何か、わかったような気がします！」
――「良かったですぅ！ より詳しい話は以下のURLを参考にして、勉強して下さい～」

Okta Help Center 初心者向けSAMLガイド

話のポイント

• Okta側にアプリケーションカタログとして専用テンプレートが用意されていれば、スムーズに導入が可能。
• テンプレートがないサービスでも、SAMLが使えれば、Oktaと連携することができます（その他、OpenID Connect等）。

あとがき。あるいは、こぼれ話：オーディエンスURIとは何ぞや

今回、SAMLについて書いた。もちろん、私は、Oktaを扱うまでは、この言葉は聞いたことすらなかった。

SAML連携と言っても、IdP（アイデンティティプロバイダー。ここでは、Oktaを指す）とSP（サービスプロバイダー。つまり、利用するアプリケーション）の二者間で何か直接やり取りが行われるというわけではなく、二者の間には常にユーザー（が使うwebブラウザ）が介在し、一方から他方へ情報を中継している。この点を先ず押さえておかねばならない。

そして、SAML設定のキモは、Okta側に最初に設定すべき、連携先のアプリケーション側の2つの情報、即ち、「シングルサインオンURL」と「オーディエンスURI（SPエンティティID）」を事前に用意しておくことにある。これらは、利用するアプリケーション側のSSO設定画面、またはドキュメントの中にさほど苦労することなく見つかるだろう。
前者の「シングルサインオンURL」というのは、まぁ、わかる。利用するアプリケーションのログインURLと考えれば良い。流れとしてはこうだ。ユーザーはOktaにログインする。ログインすると、Oktaの画面には、アプリケーションのアイコンの一覧が表示されており、その中から一つ選んでクリックすると、Oktaはユーザーに対しSAML認証情報を発行する。ユーザーの使うWebブラウザは、SAML認証情報を受け取ると、今度は、その中に”Destination”として書いてあるURL先に対し、このSAML認証情報を提出（POST）するのである。このときのURLが「シングルサインオンURL」だ。
なお、「SAML認証情報」というのは実は厳密な用語ではない。これは、SAML Assertion と SAML Response の2つに分けられるからである。と言っても、前者は後者の中に含まれている。SAML Assertionは、ユーザーの認証情報や属性に関する情報を含んだXML文書、そして、SAML Response は、それを包むようなXML文書で、ちょうど、手紙の中身と封筒の関係のようなものだ。Oktaから受け取ったユーザーはこれを「シングルサインオンURL」先に提出し、アプリケーション側にてレスポンスが解析され、ユーザー認証が行われる、といった流れである。

さて、問題は、SAML連携をする上で、Okta側に最初に設定すべき、2つの情報のうちの「オーディエンスURI（SPエンティティID）」の方だ。最初、これが私にはいったい何なのかわからなかった。もちろん、それを理解しなくても、利用するアプリケーション側のSSO設定画面に表示される”エンティティID”をコピペしておけば、ちゃんと期待通り動くだろう。しかし、ここでは、それが何なのか、少し深堀りして探っていこうと思う。

Oktaの「SAML統合を​作成」の「②SAMLを構成」画面にある、オーディエンスURI（SPエンティティID）のところに？マークがあって、そこに徐にマウスオーバーしてみる。すると、以下のような説明が表示される：

 

SAMLアサーションの​対象となる、​アプリケーションで​定義された​一意の​識別子。​ほとんどの​場合、​これは​アプリケーションの​SPエンティティIDとなります。

いったい何のこっちゃ。

こういう日本語に出くわすと、ドキュメントを読む気が失せるのであるが、出典は恐らくここだろう。日本語の翻訳もあるようなので、上記とさほど変わらないが、念の為、引用しておく：

Audience URI: The application-defined unique identifier that is the intended audience of the SAML assertion. This is often referred to as the SP Entity ID of your application.

オーディエンスURI：SAMLアサーションの対象オーディエンスとなる、アプリケーションで定義された一意の識別子。多くの場合、これはアプリケーションのSPエンティティIDと呼ばれます。

Okta Docs: Add an Okta SAML application

なるほど。どうやら、”application-defined” のところに誤訳があるらしい。これは、本当であれば、「アプリケーションを限定する」と訳されるべきだろう。原文は過去分詞形であるが、ここは現在分詞のように訳してみた。ちなみに、defineという英語は「境をつける」を意味するラテン語 definire に由来し、「はっきり境界（限界）を定める」という意味を持つ。

要は、ここでいう「オーディエンスURI」というのは、「アプリケーションを識別する」ためのもの、ということになる。しかし、アプリケーションを識別するって？ これは、つまり、別種のアプリケーションから識別する、ということではなく、同種のアプリケーションの中から特定のもの（＝エンティティ）を識別する、ということだろう。
逆に、「SPエンティティID」という用語の方から探れば、ここでいう”エンティティ”（実体）とは、アプリケーションごとの実体、つまり、ライセンス料を支払ってアプリケーションの利用契約をしている組織の主体（例えば、会社）ごとに割り当てられたもの（＝個々のアプリケーション）を指すに違いない。
話をまとめると、オーディエンスURIというのは、同じアプリケーションの中でもどの組織が契約しているアプリケーションなのかを特定するためのものであって、SAML認証の対象のユーザーはそのアプリケーションの利用が許可される、というわけだ。

これだけ長く引っ張っておいて、最後にこんなことを書くのは非常に恐縮なのだが、実は、多くの場合、「シングルサインオンURL」の中には「アプリケーションの識別子」が含まれていて（例えば、サブドメインの部分やクエリ文字列の形で）、従って、「シングルサインオンURL」と「オーディエンスURI」には同じURLを設定するなんてことは、けっこうザラのようである。そんなに深く考えることもなかったわけだ。