Pages

2014年6月30日月曜日

クラウドで始まるシングルサインオン(第2回 シングルサインオンの方式)

Be.Cloud通信戌亥です。

ルーズヴェルトゲームの最終回をみましたか?今回は野球のシーンが多かったですね。息子は青島製作所の社歌を歌いながら応援していました。野球には繊細さ(統計)とともに大胆な面(思いっきり)も必要ですが、ビジネスシーンとの比較をうまく描画していたと思います。子供と一緒に楽しんでみせてもらいました。

さて、今回は前回の 〜クラウドで始まるシングルサインオン(第1回 今、何故シングルサインオン?)〜 http://becloudbsp.blogspot.jp/2014/06/becloud.html の続きです。様々なシングルサインオンの方式をみてみましょう。

普通、1つのシステム内では、ログインしてから、ログアウトするまでの1連の流れをプログラムで管理してくれますね。同じ人がそのシステムを利用していることがわかります。なので、違うページに移動しても2回も3回も、ログインを要求してきません。

例えば、単一のシステム内であれば、会計システムとワークフローシステムでそれぞれ別のIDを要求してくることはありません。しかし、会計はERP、ワークフローはグループウェアと別のシステムの場合、そうは行きません。それぞれのシステムを使うときにIDとパスワードを要求してきます。これを解決する方法はシステム同士が会話をしなければなりません。その会話をする方式が3つあります。

1. 業界標準の共通言語を使う場合
 まず、一番多い方法は業界標準の共通言語を使って会話をする方法です。といっても、日本語とか英語とかではないですからね。コンピュータの世界ではプロトコルとよばれています。SSO業界標準のプロトコルとしてSAMLというのがあります。2000年代初頭にサンマイクロシステムズなどが中心となり作った仕様です。マイクロソフトは自分たちもテクノロジーの主導をしたいということで、Passportというのをやっていましたが、今は、業界標準としてはSAMLが圧倒的になりました。

Google AppsMS Office 365Salesforceといった、著名なクラウドサービスもサポートをしている為、幅広く使われています。従って、利用者はGoogle Appsでログインして、Salesforceを利用するなんてのは簡単に出来る様になりました。

この方式の特徴はSAMLをサポートしているサービス同士では、サービス側を修正しなくても使えることです。Google Appsや、Salesforceの様な著名なしくみは、お客様ごとに何かカスタマイズして連携をするということはしません。従って設定を変えるだけで利用できる仕組みが必要となります。

2. 独自の言語でコミュニケーションする
先ほどのSAMLは業界の標準語でした。業界の標準語が広まっていない場合はローカル言語でやりとりしますよね。関西で関西弁を使う様なものです。

サービス側:「この人の認証をお願いします」
認証側:「了解いたしました」
認証側:「終了しました」
サービス側:「ありがとうございました」
(注)SAMLは海外でも通用するので実際は英語かも

という代わりに、

サービス側:「この人の確認たのんますわ」
認証側:「むちゃぶりやなおまえ」
サービス側「そんなこと言わんと頼むで」
認証側:「わかった、わかった、やっとくわ。せやけどほんまむちゃぶりやで」
認証側:「やっといたから、確認しといてや」
サービス側:「おおきに」

という感じです。

「むちゃぶりやなおまえ」

というフレーズはいるのか?という議論もありますが、そこはそれ、あうんの呼吸ってやつですわ。

独自のコミュニケーションを使う場合は、認証側とサービス側でのあうんの呼吸でやりとりをするわけです。従ってこの場合、認証側で取り決められたやり方に従うように、エージェントという小さなプログラムをサービス側に入れる必要があります。SSOの世界ではこれをエージェント型と呼びます。

3. 翻訳をする人が間に入る
3つ目の方法は誰かが翻訳をするという方法です。2つ目の方法でエージェント型は小さなプログラムであると話しましたが、そのプログラムを扱うサービス側はそれなりの仕事が必要です。既存のアプリケーションに入れるのであれば、それなりの改修が必要となります。また、連携したいサービスが多いと、全てのシステムを修正するのは容易ではありません。従って、なるべく修正を少なくする方法がこの翻訳型です。SSOの世界ではこれをリバースプロキシ型と呼びます。

サービスプログラムの前にそのサーバを通過させて、認証側とのやりとりを引き受けます。認証側とはSAMLでやりとりをし、サービス側には、IDとパスワードを埋め込んでそれをポストし、ログインされた状態と同じ状態を作るのです。SSOには、SAML型、エージェント型、リバースプロキシ型の三つがあることを覚えておいて下さい。ちょっと長くなりましたので、本日はここまでにしておきます。

(おまけ)
クラウドではSAML型が一番お客様の要望にあいます。一つ一つカスタマイズする必要がないからです。設定一発で利用することができます。しかし、日本のクラウド業界でSAML対応をしているサービスに出会ったことはほとんどありません。Google, Microsoft, Salesforceがサポートしているにも関わらずです。

この状況はなんとかしたいと思っています。そのため、CBA (Cloud Business Alliance, https://www.cloud-business.jp/)と、NCWG (Nippon Cloud Working Group, http://ncwg.jp/)一緒にフロント連携ワーキンググループという活動をしております。


もしも、この考え方にご賛同をいただけるお客様、ベンダー様がおられましたら、是非ご参加をお願いします。CBAまたはNCWGのホームページの問い合わせコーナーから、Be.Cloud通信の戌亥に紹介されたという話をしていただければわかります。

0 コメント:

コメントを投稿