ＳＳＯ（シングルサインオン）のまとめ

　土曜日、ＬＤＡＰの話をしていた人がいて、そこでふと思ったことがあるんだけど、そのまえに、ＬＤＡＰとか、ＳＳＯについて、まとめておこうと思う（そうしないと、ふと思ったことが通じないので）

---

■ＳＳＯとは

ここ
なぜ「シングル・サインオン」が必要なのか？
http://www.atmarkit.co.jp/fnetwork/rensai/dirt01/01.html
に書かれているように（以下斜体は上記サイトより引用）

ＳＳＯ（シングルサインオン）とは

1回の認証手続きで、複数のOSやアプリケーションなどにアクセスできること（またはそれを実現するための機能）を「シングル・サインオン（Single Sign-On）」と呼びます。


こうすると

ユーザーは複数のIDやパスワードを覚えておく負担から解放されます。パスワードを1つ覚えておくだけで、厳格なパスワード管理も現実的なものとなり、より高いセキュリティを実現することが可能になります。


実装方法としては、共通の認証サーバーをたてて、

１．ユーザーは認証サーバーにアクセスして、認証を行おうとする
２．認証サーバーから複数のアプリがよびだされ
３．アプリと認証サーバー間で認証情報を渡しあう

こんなかんじ

この認証サーバー、アプリ間のやり取りの方法はいろいろ。
仮名でサーバーからアプリにアクセスしたり、認証情報をＰＯＳＴでブラウザに送り返し、そのデータをもとにアプリに入ったりなどなど・・・

---

■ＳＳＯ関連技術

こんなかんじ

・社内レベルでの実現
　　OpenＬＤＡＰ
　　ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ

・Ｗｅｂサービス、サイト間など
　　ＯｐｅｎＩＤ、OAuth
　　ＳＡＭＬ，Liberty Alliance
　　（Microsoft Passport)

もっとも、それぞれ、ＳＳＯだけじゃなくって、ほかの部分も含んでいるけど・・・

ActiveDirectoryとOpenＬＤＡＰ間では、連携できるが、どのように情報をマッピングするかなどなど、いろいろ考える点がある。

Linuxで利用できるファイルシステムの現在と未来。

いそがしいので、後で見るので、メモメモ

超訳：Linuxで利用できるファイルシステムの現在と未来
http://slashdot.jp/~hylom/journal/459982

元ネタ
On File Systems
http://www.kev009.com/wp/2008/11/on-file-systems/

アスペクト指向が必要なわけ

　アスペクト指向の「横断的関心事」って、オブジェクトとして、独立させてはじくべきで、そうすると、わざわざ、この「横断的関心事」をもとに論理を展開させるのって・・・って、思っていたけど、意味的共通化とか、形式的共通化とか、書いていたとき、ふと、「あ、そうか、必要だ ^^;）」と気づいたので、メモメモ・・・（っていうことで、アスペクト指向の専門の人から見ると、的をはずしてるかもしれないが・・・）

---

■業務の共通化は、オブジェクトレベルで行うべきだが、
　これは、要求仕様レベルである。

　たしかに、業務部分で共通処理があるなら、その処理を切り出し、オブジェクトを作るべきだといえる。ただ、これは、「業務の共通化」の話なので、主に要求仕様、せいぜい、外部設計レベルまでの話である。
　内部詳細設計の段階では、詳細化されているので、もはや業務の共通部分は、見えなくなっている。

---

■ところが、実装レベルで共通化しないといけないことがある。

　ところが、実装レベルでも、共通化すべき処理がある。
　データ入出力とか、テスト用処理とかなどなど・・・

　とくに、要求仕様→外部設計の流れは、機能要件に関しては考慮するが、非機能要件に関しては、吟味されない（できない。実装方法（ＲＤＢとかマシンとか言語とか）が決まらなければ、何秒以内に返ってくるかなど、分かるわけがない）。なので、非機能要件のようなセキュリティ、外部入出力の高速化などなど・・・

---

■実装の共通化はフレームワークでやるはずだけど・・

　たしかに、その部分の共通化はフレームワークがやるはずだけど、フレームワークでは、すべてをカバーしきれない。たとえば、Strutsで、画面データを取ってくる部分までの部分の面倒は見れるが、その画面データをログに書き出したりとか、そんな細かいことはしない。

　それは、フレームワークの手落ちではない。フレームワークでこまかいことをやると、処理が重くなる上、設定が複雑になるどちらかといえば、フレームワークは、あんまり仕事しないほうがいい。

　なので、プロジェクトレベルで見ると、フレームワークによる共通化だけでは不十分となる。
　そこで、プロジェクトごとに共通化するところが出てくる。

---

■実装レベルでの共通化で、コーディング時に気づくと・・・

　このプロジェクトごとの共通化だが、外部設計でフレームワークを決定するときに気づけばいいが、実際、コーディングして、さらに実機を動かしてみないと分からない場合がある（処理スピードがおそいので、効率化する場合など）。
　このとき、共通化部分＝横断的関心事を直すため、オブジェクトを作るとなると、外部設計にまで戻ることになる（実装の共通化はフレームワークにかかわることなので、外部設計）。
　ところが、外部設計をいじると、コストがかかる（上流を修正するほど、それ以降（下流）をすべて修正・見直しすることになるので、コストがかかる）。

　そこで、実装レベルの共通化において、横断的関心事の対応をする手法が必要になる。

---

■で、アジャイルの場合

　アジャイルだと、実装だけでなく、要求仕様なども動きながら行うため、意味的共通化が（全体を見渡すことが出来ないので）取れないことがある。その場合には、実装レベルだけでなく、意味的なレベルにおいても、横断的関心事を切り出す必要がある可能性もある。