- 1.シングルサインオンとは
- 2.SAML(Security Assertion Markup Language)
- 3.OAuth
- 4.SAMLとOAuthの共通点
- 5.Kerberos認証によるシングルサインオン
1.シングルサインオンとは
(1)シングルサインオンとは
シングルサインオンとは、一つの認証情報（ID/パスワードなど）で、複数のシステムにログインできるようにすることです。
過去問（H20SW午後1）に、シングルサインオンの目的に関する記述があるので、紹介します。
| 業務活動の統制の観点から,各社内システムのセキュリティ確保の問題が重要視されており,全社的に統一された認証情報の管理,統一されたアクセス制御の実施が望まれている。また,利用者である社員からも,個々のシステムを利用する際に,その都度IDとパスワードの入力を求められることの不便さを訴えられている。 情報システム部門では,こうした要求に応じるためにシングルサインオンの導入によって,利用者の利便性向上と統一的なセキュリティ管理を図ることにした。 |
ここにありますように、シングルサインオンの目的は、次の2つと考えられます。
①統一的なセキュリティ管理
②利用者の利便性の向上
(2)シングルサインオンのデメリット
こちらも、過去問（H20SUPM2問1）から引用します。
| シングルサインオンの機能を導入することにした。この機能を導入することで、利用者の利便性は向上するが、万が一、利用者IDとパスワードが流出したり破られたりしてしまうと、シングルサインオンできるすべての業務アプリを簡単に不正利用されてしまうというリスクが伴う。 |
これは、シングルサインオンに限ったことではなく、IDパスワードを使いまわしている場合にも、同じことが言えます。
(3)シングルサインオンの２つの方式
シングルサインオンには、２つの方式があります。
❶エージェント方式（クッキーを使ったシングルサインオン）
SSOを利用したいサーバに、エージェントと呼ばれるソフトウェアをインストールして行う。
また、過去問では、クッキーを使ったシングルサインオンは、「サーバごとの認証情報を含んだクッキーをサーバで作成し、各クライアント上で保存・管理する。（H18NW問47を一部修正）」方式であると記載されています。
エージェントがやってくれるので、この後に記載するリバースプロキシ型のような新しい機器を設置したり構成を変更する必要がありません。ただ、システムにエージェントを入れることはすごく嫌がられる傾向にあり、その理由で、この方式は採用されないこともあります。
過去問（H27秋NW午後Ⅰ問1）に、エージェント方式の詳しい解説があるので紹介します。
| C氏はHTTPを用いたSSOの方式と認証処理シーケンスについて検討した。SSOの方式を分類すると，SSOで利用したいサーバにエージェントと呼ばれるソフトウェアモジュールをインストールして実現するエージェント方式と, SSOサーバにおいて全ての通信の中継を行う〔 ア：リバースプロキシ 〕方式がある。C氏は，エージェント方式の検討を行い，エージェント方式を採用することにした。 エージェント方式におけるSSO認証処理のシーケンスは，次のとおりである。 ① PCからWebアプリケーションサーバに，サービス要求を行う。 ② Webアプリケーションサーバ内のエージェントは，サービス要求中のCookieに認証済資格情報（以下，アクセスチケットという）が含まれているか確認する。含まれていなければ，サービス要求はSSOサーバヘ〔 イ：リダイレクト 〕される。 ③ SSOサーバからPCに，認証画面を送る。 ④ PCからSSOサーバに，UserIDとPasswordを送出する。 ⑤ SSOサーバは，UserIDとPasswordから利用者のアクセスの正当性を確認したら，アクセスチケットを発行して，Cookieに含めて応答を返す。サービス要求は，Webアプリケーションサーバヘ〔 イ：リダイレクト 〕される。 ⑥ Webアプリケーションサーバ内のエージェントは，SSOサーバにアクセスチケット確認要求を送り，SSOサーバは，確認して応答を返す。 ⑦ Webアプリケーションサーバは，⑥の応答によって利用者のアクセスの正当性が確認できた場合，Webアプリケーション画面を送出する。 エージェント方式におけるSSO認証処理のシーケンスの①～⑦を図示すると，図2のようになる。  |
❷リバースプロキシを使ったシングルサインオン
リバースプロキシを使ったシングルサインオンは、シングルサインオン用に別途リバースプロキシサーバを立て、このサーバが代理で認証を行う方式である。情報処理安全確保支援士試験の対策としては、こちらの方式を基軸にしておきましょう。
情報処理安全確保支援士試験の過去問（H22SC秋AM2問1）では、「リバースプロキシを使ったシングルサインオンの場合、利用者認証においてパスワードの代わりにディジタル証明書を用いることができる」と述べられている。
2.SAML(Security Assertion Markup Language)
(1)SAMLとは
SAMLは、「認証情報に加え、属性情報とアクセス制御情報を異なるドメインに伝達するためのWebサービスプロトコル（H20SW午前 問79）」「標準化団体OASISが, Webサイトなどを運営するオンラインビジネスパートナ間で認証，属性及び認可の情報を安全に交換するために策定したもの（H31春SC午前2問3）」である。
例えば、通販の申し込みサイトと決済サイトが別会社で運営されている場合、ドメインが異なるので、クッキーによるシングルサインオンはできない。そこで、利便性を目的としたSSOの技術の一つに、SAML(Security Assertion Markup Language)がある。
各WebサイトがSAMLプロトコルに対応していれば、サイト間で認証情報を引き継ぐことができる。つまり、異なるドメイン（= 異なるWebサイト）でのシングルサインオンが可能になる。正解はSAML。
異なるドメインの場合のみに使うのですか？
いや、そう考えない方がいい。
SAMLについて、別の情報処理安全確保支援士試験の過去問では、「標準化団体OASISが, Webサイト間で認証，属性及び認可の情報を安全に交換するために策定したフレームワーク（H24SC秋午前2問11）」、「SAMLは、認証、許可などの情報を安全に交換するためのフレームワークである（H29SC春午後1問2）」と述べている。
つまり、認証のフレームワークである。ただ、同じ社内であれば、一つの認証の仕組み（たとえばADサーバ）で完結できる。他の連携するには、異なるメーカの認証サーバとも連携する必要があり、その標準規格がSAMLである。
(2)登場人物
SAMLを用いた認証の登場人物を紹介します。
| 項番 | 登場人物 | 解説 |
|---|---|---|
| ❶ | SP（サービスプロバイダ） | 利用者にサービスを提供するシステム。Office365などのクラウドサービスと考えてください。 |
| ❷ | IdP（IDプロバイダ） | SPや認証サーバと連携して、利用者の認証結果などを安全に受け渡します。 |
| ❸ | 認証サーバ | （一般的には社内に設置される）認証サーバです。Microsoft社のADサーバや、LDAPサーバと考えてください。 |
| ❹ | Webブラウザ | SPのサービスを利用するPCのブラウザです。 |
ふつうのシステムは、利用者（❹）とアプリケーション（❶）と認証サーバ（❸）だけですよね。なぜIdP（❷）が必要ですか？
もちろん、認証サーバ1台で実現してくれれば理想です。しかし、認証サーバは、ユーザIDとPWを管理する程度の単純な機能しかありません。今から詳しく仕組みを説明しますが、SPやブラウザおよび認証サーバの仲介役として必要です。
(3)構成例
SAMLを使って認証連携をする様子を、以下に示します。
クラウドサービスB，クラウドサービスCなどがSPです。IdPは、Microsoft社のAD FS(Active Directoryフェデレーションサービス)などをイメージしてもらうといいと思います。フェデレーション（Federation）は「連携」と考えてください。
PCからは複数のクラウドサービスを利用しますが、この仕組みにより、クラウドサービスごとにID管理をする必要がなく、A社の認証サーバで一元管理ができます。IDやパスワードを一元管理は、社内サーバを含みます。便利ですね。
(4)SAMLのフロー①
情報処理安全確保支援士試験の過去問に詳しい解説がある。
| 過去問 |
|---|
| Ｆ氏：私は,SAML (Security Assertion Markup Language)2.0という標準技術を使ったID連携のシステム構築の経験があります。SAML 2.0では,異なる製品間の相互運用性について,技術標準を策定する団体が主導して試験を行い,検証結果を公表しています。 Ｅ君：相互運用性が高い技術であれば,X社の技術標準として採用しやすいですね。 Ｆ氏：そうですね。仕組みについてご説明します。図5が,SAML 2.0を使ってSSOを実現する場合のメッセージフローです。この図にあるSP (サーピスプロバイダ)は,認証された利用者に対して業務アプリケーションなどのサービスを提供する側の機能で,IDP(IDプロバイダ)は,利用者認証の結果をSPに提供する機能です。利用者がSP上のWebアプリケーションを利用する場合に,SPが利用者に対してWebアプリケーションのサービスを提供してよいかを判定する必要がありますが,この判定のためにSPは[ a ]をプラウザ経由でIDPから受け取ります。  図5 SAML 2.0によるSSOのメッセージフロー Ｅ君：なるほど,分かりました。 Ｆ氏：Y社にもSAML 2.0のSPを導入したとします。この場合,X社の利用者が,X社情報システム群の認証サーバ,つまり,IDPで一度認証を受ければ,[ b ]するまでは,X社とY社のWebアプリケーションは,利用者が個別にサインオンしなくても利用可能となります。 設問1 ID連携技術について,本文中及び図5中の[ a ],[ b ]に入れる適切な字句を,それぞれ10字以内で答えよ。また,図5中の[ c ]には,ブラウザにおける動作を示す適切な字句を8字以内で答えよ。 |
↓
↓
↓
↓
↓
試験センターの解答例は以下だ。
設問1
a 認証アサーション（または認証トークン）
b サインオフ
c リダイレクト
(5)SAMLのフロー②
もう一問、情報処理安全確保支援士試験の過去問（H22秋SC午後Ⅱ問2）を解いてみよう。
| 過去問（H22秋SC午後Ⅱ問2） |
|---|
SAMLとは,記述言語として[ d ]を用いて,認証及び[ e ]に関する情報を交換するための標準規格である。今回, A社で採用したSAML型SSOシステムにおける認証及び[ e ]を実現するプロトコルは,図9のとおりである。 Webアプリ上には,SP(サービスプロバイダ)と呼ばれるモジュールが稼働しており,IdP(Idプロバイダ)と呼ばれるWebアプリと連携して,利用者認証を行う。IdPにおいては,様々な認証方式を採用できるが,A社では,入力フォームを活用した,利用者IDとパスワードを用いる方式を採用し,図8の統合認証システムにおけるLDAPサーバと連携させることにした。 次は,A社で採用したSAML型SSOシステムのプロトコルの動作概要である。ここで,各主体は,ほかの主体の公開鍵証明書を保持しているとする。 (a)利用者のブラウザは, Webアプリにサービスを要求する際,SP用のクッキーがあれば,それを提示する。提示したクッキーが有効であることが検証された場合は(f)に進む。 (b)SPは, SAMLRequestメッセージをエンコーディングした上でURIに含め,サービス要求をldPにリダイレクトする。 (c)利用者は,利用者IDとパスワードを入力し,認証を受ける。 (d)ldPは,利用者IDなどの属性を暗号化及びディジタル署名したSAMLResponseメッセージを発行し,ブラウザ上のJavaScriptを用いて,それをSPに転送する。 (e)SPは,SAMLResponseメッセージのディジタル署名などを検証し,有効であれば,SP用のクッキーを発行する。 (f)SPが稼働するWebアプリは,該当するサービスを提供する。 |
↓
↓
↓
↓
↓
あれ、さっきとはSPとIdPの位置が逆だ。
これでいいのかな？
図の上での配置は逆だが、内容は一緒だよ。よく見てみよう。
試験センターの解答例は以下だ。
d XML
e 認可
SPやIdpがどれかは必須のように問われているので、理屈を理解しておきましょう。
(6)SAMLのフロー③
情報処理安全確保支援士試験の過去問（H29春SC午後1問3）をもう一問見てみましょう。このように何度も問われていることから、SAMLの理解は情報処理安全確保支援士の試験対策として重要です。
過去問（H29春SC午後1問3）
----- 問題文ここから -----
〔SAMLを用いた認証連携と接続元制限方式の概要]
SAMLは，認証，認可などの情報を安全に交換するためのフレームワークである。SAMLを用いることによって，利用者にサービスを提供するサービスプロバイダ（以下，SPという）と，IDプロバイダ（以下, IdPという）との間で利用者の認証結果などの情報を安全に連携することができる。SAMLには複数の処理方式が存在する。今回F社で導入を検討している方式のシーケンスを図1に示す。図1中の各通信のプロトコルは, IdPとLDAPサーバ間はLDAPであり，それ以外はHTTP over TLSである。
SAMLを用いた認証連携を行うためには，事前にldPとSPとの間で様々な情報を共有することによって，信頼関係を構築しておく必要がある。事前に共有する情報としては，通信の方式や連携する属性情報などが記述されたメタデータ，[ e：処理１ ]で生成して送出するURL，[ f:処理４ ]において必要なIdPのディジタル証明書などがある。
図1中の処理1～4の処理内容を表1に示す。
| 処理番号 | 処理内容 |
|---|---|
| 処理1 | ・IdPに認証を要求するSAML Request を生成する。 ・SAML Request をエンコードする。 ・エンコード結果をIdPのログイン画面のURLと組み合わせて，リダイレクト先URLを生成する。 |
| 処理2 | ・URL内の[ g：ウ：クエリ文字列 ]からSAML Request を取得する。 ・信頼関係が構築されたSPからの認証要求であることを検証する。 |
| 処理3 | ・利用者の認証が成功した場合，認証結果やSPとの間で連携する属性情報，有効期間，それらの情報に対するディジタル署名を含めたSAML Response を生成する。 |
| 処理4 | ・SAML Response に含まれるディジタル署名を検証することによって，ディジタル署名が[ h：IdP ]によって署名されたものであること，及びデータの[ i：改ざん ]がないことを確認する。 ・SAML Response 内の属性情報も検証することによって，サービスを提供すべきか決定する。 |
----- 問題文ここまで -----
↓
↓
↓
↓
↓
まず、先に正解を言うと、
a：SP
b：利用者端末のブラウザ
c:IdP
d：LDAPサーバ
問題文の3つで、すべて違うじゃないですかー
そうですね。ブラウザからSPに「サービス要求」が通信の始まり。
これだけ覚えておけば、間違えないでしょう。
実際、たとえば、ZOOMというSPにアクセスするときは、ZOOMにアクセスしますよね。そこでSSO（というかIdP）を選んで、Idpで認証情報を入れる。IdPは本当に認証サーバで認証を行い、成功すれば、ZOOMというSPに接続できる。このとき、ZOOMにもアカウントは追加されるはず。（認証情報を完全に持たないのではなく、PWだけ（？）を持たないと思っていいかと思う）
また、この問題の場合、表1などを読めば、答えがわかるようにもなっていますので、知らなくても問題文から解答できます。
[参考】SAMLの事例（学術認証フェデレーション）
複数の大学で、共同のe-Learningシステムを利用する場合、IDの管理をどうするか。これが課題となる。
共同のe-Learningシステム用にIDを作成すると、学生はIDが増えて煩雑だ。かといって、自分の大学のID情報を、他大学に教えることもできない。
そこで、SAML。以下がイメージ図だ。
少し補足する。
(1)SPについて
提供するサービス（メールや学内システム、eラーニングなど）のサーバがあるだろう。当然だ。
そこに、SPのモジュールを組み込むことで、認証画面をつける。このモジュール、多くはShibboleth（シボレスと読む）だ。
設定は以下。
https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158264
(2)IDPについて
認証の窓口となるサーバ。ADサーバやLDAPサーバそのものではない。SAMLの仕組みを使って、SPと認証サーバをつなぐための仕組みだ。
構築としては、WindowsやLinuxのサーバを立てて、IdPをインストールする。こちらも、多くはShibboleth(IdP)だ。
設定は以下
https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158257
(3)認証サーバ
従来の、大学にある認証サーバ。ActiveDirectoryやLDAPなどのサーバが多いだろう。IdPからの問い合わせ（LADPかKerberos）に対して、認証結果や属性（学部など）を返す。
この仕組み、便利ですね。
でも、便利すぎて、セキュリティ面で色々と疑問があります。
話が変わるが、大学での無線LANのローミング基盤はeduroam。
3.OAuth
RFC6749で規定されているOAuth 2.0の仕組みについて解説します。H30年NW午後Ⅱ問１の図6は、まさにOAuth2.0の流れそのものです。また、支援士では、R5春午後Ⅱ問2で問われました。
(1)OAuth 2.0とは
・OAuth（Open Authorization）とは、複数のシステム（Webサービス）で、APIを使って認証を連携させる仕組みです。
・オープンな（Open）な許可（Authorization）という言葉が意味する通りで、企業に閉じた仕組みというよりは、複数のSNSで連携するなど、インターネットでの認証連携で利用されます。
・たとえば、FacebookとTwitterの連携です。Facebookでの投稿した記事を、Twitterにも投稿させたり、Twitterのプロフィールを更新したりできるのです。
・以下は、FacebookとTwitterの連携の設定画面です。
これは一例ですが、このように、複数のWebサービスで利用者認証を連携するときに、OAuthが必要になってきます。
(2)OAuth 2.0の具体例
・具体的に見ていきましょう。まずは以下の過去問（H27秋SC午前2）を見てください。
| 問17 OAuth 2.0において, WebサービスAの利用者Cが, WebサービスBにリソースDを所有している。利用者Cの承認の下, WebサービスAが，リソースDへの限定的なアクセス権限を取得するときのプロトコルOAuth 2.0の動作はどれか。 ア WebサービスAが，アクセストークンを発行する。 イ WebサービスAが，利用者Cのディジタル証明書をWebサービスBに送信する。 ウ WebサービスBが，アクセストークンを発行する。 エ WebサービスBが，利用者Cのディジタル証明書をWebサービスAに送信する。 |
先に答えだけお伝えすると、ウが正解です。
さて、この問題文の登場人物は以下です。わかりやすいように、具体例を入れています。
| 利用者C | あなた |
|---|---|
| WebサービスA | どこかのWebサイト |
| WebサービスB | （Facebookなどの）SNS |
| リソースD | SNSで公開しているあなたのプロフィール |
図にすると以下のようになります。
問題文にあるようにWebサービスAが、リソースD（SNSのプロフィール）へのアクセス権限を取得し（下図➀）、WebサービスAにプロフィールを掲載します（下図②）。
WebサービスAがWebサービスBにアクセスするのですね。
はい、そうです。では、WebサービスAはどうしてWebサービスBにアクセスできるのでしょうか？WebサービスA側に、WebサービスBのIDとパスワードを教えていると思いますか？
それはセキュリティ的に適切ではないと思います。
ですよね。パスワードは利用者本人以外が知るべきではありません。そこで、ID/パスワードの代わりに、トークン（アクセストークン）という許可証をWebサービスA に渡します。WebサービスA は、このトークンを使ってWebサービスBにアクセスするのです。また、トークンを使えば、リソースD以外の例えば「Cさんの友達リストアクセスするための権限を付与したトークン、など、許可する資源（や情報）を細かく制御できます。
このように、ユーザ認証をしてアクセストークンを発行するやりとりを標準化したものがOAuthです。2.0はバージョンを意味します。Oauth1.0はセキュリティ上の欠陥がありましたが、Oauth2.0ではその点などを含めて改良されています。現在の主流は2.0です。
参考ですが、OAuthは、「認証」ではなく「認可」の仕組みと言われます。ユーザがAさんなのかBさんなのかを識別（＝認証）するのではなく、どの資源や情報を使ってよいかを許可（＝認可）するという意味です。以下は、OAuthの仕組み丸分かり体験サイト（https://contents.saitolab.org/oauth/）を利用させていただき、Facebook連携をした様子です。図にあるように、「受け取る情報」として「氏名」と「プロフィール写真」とあります。単にFacebookの情報を全て渡すのではなく、資源単位で認可をしている様子がわかると思います。
とはいえ、厳密に分けるとややこしくなるので、この解説では両者の区別を意識していません。
(3)OAuth 2.0の登場人物
では、OAuth 2.0の登場人物を紹介します。
| 登場人物 | 解説 | 先の過去問の場合 | |
|---|---|---|---|
| ➀ | Resource Owner | クライアントPC(実際にはブラウザ）。情報資産（写真やメール、ファイルなど）へのアクセス権限を持っているのでオーナ（Owner）と言える。 | 利用者C |
| ② | OAuth Client | 利用者が使用するシステムやサービス | WebサービスA |
| ③ | Authorization Server | 認可サーバ。ユーザ認証をしてアクセストークンを発行する。 | WebサービスB |
| ④ | Resource Server | Resource（プロフィールなどの情報）を持つサーバ。他のWebサービスから接続するためのAPIを用意する。 | WebサービスB |
また、トークンにも2種類があります。
| トークンの名称 | 説明 | 有効期間 | |
|---|---|---|---|
| ➀ | アクセストークン | 通常のトークン | 短い（10分）※注 |
| ② | リフレッシュトークン | アクセストークンの有効期間が切れた場合に利用する | 長い（60分）※注 |
※注：有効期間は、過去問（H30午後Ⅱ問１）に記載があったものを使用。
トークンについて少し補足します。アクセストークンは、すでに説明したように、Webサービスを利用する際の許可証です。リフレッシュトークンは、アクセストークンの有効期間が切れた場合の延長申請で利用します。アクセストークンの有効期間はわずか10分です。有効期間が終わる都度、利用者にユーザID/パスワードを再入力してもらうのは不便です。利用者に再認証してもらう代わりに、リフレッシュトークンで新しいアクセストークンを発行してもらいます（利用者は何もする必要がありません）。
何点か、QAで補足説明します。
| Q1.リフレッシュトークンは、いつ発行されるのですか？ |
A1.認証成功時にアクセストークンと同時に発行されます。
| Q2.アクセストークンの有効期間を長くすればいいのでは？ |
A2.アクセストークンはサービスを利用する際に何度も流れます。盗聴のリスクがあります。不正利用されないためにも、有効期間は短くすべきです。
| Q3.でも、リフレッシュトークンも盗聴される可能性がありませんか？ |
A3.もちろんあります。しかし、アクセストークンに比べてネットワークを流れる機会は多くありません。盗聴されるリスクは少ないのです。
(4)OAuth 2.0のフロー
では、過去問（H30午後Ⅱ問１）をもとに、OAuth2.0のフローを確認しましょう。
先ほど挙げた、WebサービスAにプロフィールを載せる事例でシーケンスを説明します。
ⅰ)利用者がWebサービスAにアクセス（図の「情報要求」）します（❶）。
ⅱ)WebサービスBのリソースを使うので、WebサービスBにリダイレクト応答を行い、認可要求をします（❷）。ここで、「(a)認可要求」の内容は以下です。
HOSTが「認可サーバ」になっているので、接続先は「認可サーバ」です。
なぜ、顧客サーバ（WebAP）が「認可サーバ」の情報を知っているのですか？
当然ですよ。顧客サーバ（WebAP）は、連携する認可サーバを事前に選定しているでしょうし、その情報を事前に登録しています。だから、リダイレクトのHOSTに「認可サーバ」を指定できます。
説明に戻りますが、GET/authorize?redirect_url=【WebAPのURL】とあります。よって、このHTTPヘッダが意味することは、http://認可サーバ/authorize?redirect_uri=【WebAPのURI】へ通信することと同じです。http://認可サーバ/authorizeに接続し、引数としてredirect_uri=【WebAPのURI】を渡すという意味です。引数を付与しているので、認可サーバは「(b)認可応答」にてリダイレクト先のURIを指定することができます。
ⅲ)認可サーバにて、ID/パスワードを入力します。図の「アクセスの確認（省略）」の部分です。
ⅳ)認証が成功すると、認可応答として「認可コード」が発行されます。（❸）
問題文には認可応答の中身も記載されています。code=の部分に認可コードが確認できます。
ⅴ)WebサービスAが受け取った認可コードを用いて、WebサービスBにアクセスできるようにトークン（＝許可証）を要求します。（❹）
ⅵ）トークンがWebサービスAに発行され（❺）、アクセストークンを使って、WebサービスBにアクセスします（❻）
❸の「（ｂ）認可応答」ですが、「認可コード」ではなく、いきなりトークンを受け取ってはいけないのですか？
技術的にはできそうですが、そうしない理由があるはずです。パッとは思いつきませんが、PC経由でアクセスさせることで、認証面やセキュリティ面で高まることでしょう。
それと、単純な理由として、たとえば、顧客サーバへの通信は、どこからでもアクセスできるのではなく、送信元やポートを絞っている可能性があります。つまり、認可サーバから顧客サーバ（WebAP）への直接的な通信が行えない可能性があるのです。だから、PC経由で接続させます。
それと、PCが保持しているものと顧客サーバが保持しているものは別物です。シーケンスをよく見てみましょう。PCが受け取るのは認可コードで、顧客サーバ（WebAP）が受け取るのはアクセストークンです。認可コードはPC（というかユーザ）を許可し、アクセストークンはシステムを許可します。なので、処理としては分けられています。
4.SAMLとOAuthの共通点
OAuthは複数のシステム（Webサービス）間で、APIを使って認可を連携させる仕組みです。インターネットでの認証連携にはSAMLがありますが、SAMLは、基本的に「認証」の機能しかありません。OAuthでは、「認可」の機能を実現します。とはいえ、認可をするためには「誰であるか」という識別が必要なので、OAuth2.0は認可の仕組みですが，認証もしていると考えてください。
以下、SAMLとOAuthのシーケンスを並べましたが、基本的には同じことをしています。SSOの仕組みで、認証サーバに問い合わせて許可をもらっている点が共通しているからです。
(1)SAMLのシーケンス
(2)OAuthのシーケンス
以下、共通点がわかりやすいように図にしました。上の2つを1つにまとめた感じです。
再確認ですが、上記の②と④でWebサービスと認証系システムが直接やりとりをせずにPCを経由しています。
PCから通信させることでなりすましの防止ができますし、直接やり取りさせないことで、一時的なチケットではなく、恒久的なIDパスワードなどの認証情報をWebサービスに渡さなくて済みます。
5.Kerberos認証によるシングルサインオン
ケルベロスって、ギリシャ神話の門番でしたっけ。
門番が許可した人だけを中に入れた、つまりケルベロスによる認証だったわけですね。
Kerberos認証というのはシングルサインオンに限った仕組みではないが、結果的にシングルサインオンと同様の機能を持つ。
私が解説するよりも、情報処理安全確保支援士試験の過去問（H22SC秋午後2問2）にてきれいに整理されているので、紹介する。
前半の図が、Kerberosを使わない場合で、後半の図が使った場合。あきらかに、認証が便利になっている。また、問題文に記載があるように「C-CR認証の場合,クライアントはサーバヘの接続のたびにDCにおいて認証を行う必要があるが, Kerberos認証の場合,有効期限内であればチケットをサーバに提示するだけでサービスを受けられる。」という点も利点である。
| A社は, PC端末,ファイルサーバ及び一部のWebアプリにおける認証の仕組み,並びにディレクトリとして,c社製ディレクトリシステム(以下,C-DIRという)を,導入している。C-DIRでは,利用者. PC端末,プリンタ及びサーバから構成されるドメインという管理単位を定め,ドメインコントローラ(以下,DCという)によって管理する。また, DCでは, C-DIRのディレクトリに保持されるアカウント情報を用いて認証を行う。認証には,C社独自仕様のチャレンジレスポンス認証(以下, C-CR認証という),又はKerberos認証を利用することが可能である。 C-CR認証では,図3に示すプロトコルの(b)-1~(b)-4において,DCが生成した疑似乱数をチャレンジとし,それを受信したクライアントで,利用者ID,パスワード及びチャレンジの連結をハッシュ化したレスポンスをDCに返信し,アクセス許可を受ける。  他方, Kerberos認証では,図4に示すように,クライアントが, DCにおける認証後,有効期限付のチケットが発行され,それをサーバに提示し,アクセス許可を受ける。  C-CR認証の場合,クライアントはサーバヘの接続のたびにDCにおいて認証を行う必要があるが, Kerberos認証の場合,有効期限内であればチケットをサーバに提示するだけでサービスを受けられる。A社では,トラフィックが少なくなるなどのメリットが多いKerberos認証だけを利用している。また, Kerberos認証において、②有効期限切れのチケットが悪用されないように,DCとサーバを[ a ]させて運用している。 設問2 (2)本文中の下線②を実現するために,[ a ]に入れる適切な字句を10字以内で答えよ。 |
↓
↓
↓
↓
↓
これは、Windowsにて、AD（AcriveDirecory）の認証が終わると、AD配下の各サーバにアクセスする際に、再認証が不要という仕組みだ。日頃利用されている人が多いだろうから、理解がしやすいだろう。
aに入るのは、「時刻同期」だ。
参考ですが、WindowsのADの認証には、Kerberos以外にNTLMv2がある。しかし、Windows 2000以降は、Active DirectoryではNTLMは脆弱性が発見されていることもあって非推奨で、Kerberos認証が使われる
