ホーム

認証のことを、何となく周辺の話題もからめて書いてみる(3)

前回のつづき。思ったより長くなってきた。くどいようですが、すごく正確に書いているという自信はないので、なんとなく分かるといいなあ、くらいの気持ちでお読みください。

サービス側とサービス利用者側の両方を仲介する「認証屋」が現れることで、ことによるとシングルサインオンってやつが出来るのかも知れないなーという所までが前回の話でした。あと、いくつかの技術的要素(リダイレクト、パラメータ、セッション、云々)ってのも所々で説明してきました。

ここまで準備ができていれば、大体、具体的な技術についても無理なく説明できるんじゃないかな、ということで、いきなりCASという仕組みの説明をしてみます。

CAS(Central Authentication Service)

CASは、Jasigっていうグループが開発しているオープンソースのシングルサインオンの枠組みです。組織内での複数ウェブシステムのシングルサインオンを実現するのに向いています。

これは、ほぼそのまま、さっきの話の「認証屋」の役割をこなします。ユーザーは、どこかのサービスにログインを試みる前に、あらかじめ「認証屋」であるところの、自分の機関のCASシステムにログインしておきます。(指定されたCASシステムじゃないとダメですよ。)まあ、どうせ、各々のサービスからCASのログイン画面にリダイレクトされてしまうんだから、CASに先にアクセスしても、サービスに先にアクセスしても、順番はどっちでもいいんですけどね。

CASシステムは、前もって、下にあるような情報をすべて知らされています。(もちろん、管理者が、あらかじめ設定・登録しておくってことですよ)

各々のサービスは、最初にログインを申し込んできたユーザーが、CASから「チケット」をもらってきているかをチェックします。チケットってのは、前の話でいうチケットコードに相当します。最初はそんなの持ってないわけで、そうするとサービスは「まずCASでチケットもらってこいよ」っていうわけで、ユーザーを(自機関の)CASのログイン画面にリダイレクトします。リダイレクトするときに、「パラメータ」も一緒に持たせます。サービスからCASに引き渡すこのパラメータは、CASから戻ってくるときのサービス側URL、つまりサービスにとっては現在位置にあたるURLです。ここは図にしないとわかりにくいでしょうから、下に図示します。

CAS側は、ユーザーが持ってきたパラメータを見て、「こいつの認証と利用承認が終わったら、ここにリダイレクトし直してやればいいんだな」と覚えておくことができるってわけです。

で、CASはその場でユーザーにIDとかパスワードとかを打ち込ませて、本人認証を求めます。別の言い方をすると、CASへのログインを求めます。または、同じユーザーが最近CASにログインしたことがあって、セッションがまだ成立しているときは、いちいちもう一度パスワードなんかを打ち込ませたりはしません。この場合は顔パス状態ですね。

ユーザーがCASへのログインに成功した、またはもともとログイン済だったなら、CASはこのユーザーに「チケット」を持たせて、もとのサービスのURL(さっき持ってきたやつです)にリダイレクトし直してやります。チケットは、他のやつとかぶらない、ちょっと長めの記号です。チケットはパラメータとして持たせるんですよ。

するとサービス側では、さっきと違って、ユーザーは「チケット」を持っていることに気づきます。なるほど、チケットを持っているからには、裏で、認証屋であるCASシステムにこの詳細を問い合わせてみよう。そんな感じにサービス側は判断します。

CAS側のほうでは、どんなユーザーにチケットを与えたのかを、そのチケット記号と一緒にしてしばらく覚えていますから、サービス側から電話がかかってきて、「このチケットの詳細が知りたいんですけどー」と言われたときは、確かに○○ユーザーのものであるぞ、と答えてあげることができるというわけです。

もうちょっと正確には、CAS側は、チケットを与えたユーザーID、チケット番号、そして(リダイレクトさせた)サービスのURLをすべて一揃いで覚えています。で、サービス側からは、「私、ABCというサービスですけど、このチケットを誰かに発行しましたか?」という感じの問い合わせを受けます。どのサービスに対してCASが使用許可を与えたのかまでが、これでよりはっきりしますね。

CASシステムは、ABCならABCサービスの利用許可をしていいのかどうか、あらかじめ知っているというところに注意してください。CASに登録されているユーザーだとしても、その人の属性によっては、Aサービスにはログインできても、Bサービスにはログインできない決まりになっているかもしれません。例えば学校なんかの例なら、先生にはログインできて、生徒にはログインできないようなシステムってのもあるかも知れませんからね。CASはそういったシステムごとの判断基準もすべて知っている必要があるのです。CASがシングルサインオンの大部分を仕切っているといえますね。その分、それぞれのサービス側では、「CAS様が利用許可をしたユーザーなら間違いないな」と信用してよいことになります。CASの責任は重大だ。

さっき、CASはユーザーについてのその他の情報も持っているかもしれないと言いました。ユーザーのIDだけでない、本名とか所属とか、そんな情報のことですね。CASは、サービス側からチケット情報の問い合わせを受けたときに、許可したユーザーのIDといっしょに、こういった付随情報も伝えてあげることが可能です。なので、サービス側では、ユーザーからチケットだけを受け取ったのに、裏ではCASからこのユーザーについてのいろいろな情報を知らされる、ということが可能になります。

いったんこのチケット確認(バリデーションって呼ぶことがあります)が終わってしまえば、あとはこのサービスが利用ユーザーとセッションを始めるなり何なりするので、ここでCASの役割は終了です。何回か繰り返してこのストーリーを確かめてみると、だんだん呑み込めてくると思いますよ。

次に、ユーザーが別のサービスを使い始めるときに何が起こるかも見てみます。さっきCASにログインしていて、CASとのセッションはまだ成立しているものとします。今回は会話式で認証の流れを追ってみます。

この一連の流れはすべてリダイレクトのみで成り立っているので、実際には利用者はなにもしないうちに、XYZサービスへのアクセス→ログイン完了まで、見ている分には一気に進んで完了します。これはとても楽な話です。まさにシングルサインオンのご利益をフルに受けていると言えますね。

今までの話から、あるウェブサービスがCASによるシングルサインオンに対応するには、下の条件を満たしていることが必要になります。

この程度。既存のシステムをCAS対応にすることは、そんなに難しいことでもないですよ。具体的にどういうプログラミングが必要か、とかそういうのは、ここで述べるつもりはありません。ストーリーだけ分かってくれれば大体OKと思います。

ユーザーがCASにログインするための認証手段は、IDとパスワードでなきゃダメという決まりはありません。(もちろん、それが一番普通でしょうけどね。)CASへの認証が「なんとでもして」なされていれば、原理上シングルサインオンができることは押さえておいてよいでしょう。

TODO:アレ

はてな認証API

筆者がたまたまこの「はてな認証API」を使ったプログラムをしたことがあって、この仕組みがCASの理解とそれほど変わらないので、ついでにこれの説明もしてみようと思います。

はてな認証APIは、株式会社はてなが提供している、はてなアカウントを持っている人が任意のウェブサービスにシングルサインオンできるような仕組みです。はてなダイアリーとか、はてなブックマークとか、そんなサービスを使うためにここのアカウントを持っている人は多いんじゃないでしょうか。そもそも、はてなダイアリーとかはてなブックマークにログインしていれば、はてなの他のサービスにも自動でログインできるようになっていますよね。はてな社の各サービスでシングルサインオンはすでに実現しているんです。このノリで、私たちが適当に作ったサービスもこのシングルサインオンの輪に参入できるというわけです。

とはいえ、ログインしたい人が全員はてなのアカウントを持っている必要があるわけですから、職場なんかでのシングルサインオンを実現するためには使いにくいでしょうけどね。はてなのIDが知られると、こっそり書いてるはてなダイアリーなんかもバレちゃうし。

さっきまでの、いわゆる「認証屋」の役割を、はてな社がやってくれるというのが、大体この仕組みの理解です。また会話式でこの認証の流れを追ってみましょう。

CASでいう「チケット」ってのが、ここでは「cert」っていう呼び名になってます。あとの理屈はそんなに変わりがありません。

もっとも、上には書き入れませんでしたが、ABCサービスがはてな社に自分の素性を示すために、実際はもうちょっとだけ込み入ったことをしています。CASのときは大体みんな同じ機関の中でやってますからいいんですが、はてな認証APIの場合は、はてな社は、例えば僕がこしらえたような、いわば「得体のしれない」サービスとつき合わなくてはいけないわけですから、そこらへんをもう少しキッチリさせている、というわけです。多分。

もうひとつ、はてな認証APIのほうでは、認証したユーザーがABCサービスの利用をしていいのか悪いのかなんて知りませんから、CASシステムと違って、認証されているユーザーはみんな利用許可とみなします。

はてな認証APIの話は、こんなもんにします。簡単に使えて楽しいものですよ、認証API。

今書いてて思いついたんですが、はてな認証APIを使うサービスが、はてな側に「素性を示す」ときのやり方について、「ID+PASS式」でない、もうひとつの認証方法(デジタル署名っていいます)として説明しておいてもいいかなあ、と思うので、ちょっと脱線かも知れないんですが、次にこの話を少しだけしてみます。

予告だけすると、「その人にしか作りえないデータ」っていうのがもとになる考え方です。あるデータを受け取った人が「おお、このデータを作ることができるのは、まさしくA氏のみ」と確信できるなら、そのデータをくれた人はA氏に違いありません。(正確には、このデータを作った人は、ですけどね。)もうひとつ進んで、ある文書と、その文書にくっついたおまけデータがあって、「おお、この文書をもとにしてこのおまけデータを作ることができるのは、まさしくA氏のみ」と思えたとしたら、もとのこの文書に対してA氏が何らかの意思表示をしたに違いないってことになります。これが大体、デジタル署名というやつです。

(2012.11.20追記)…と思ってたんだけど、デジタル署名の話は、サーバー証明書のことをこれを別にどこかに書こうと思ったので、この話の流れからは外しちゃおう。

(つづく)

2012.11.7

クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 3.0 非移植 ライセンスの下に提供されています。