| Mr.Hack | ||
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■Authentication（認証）とAuthorization(認可）
Mr.Hackです。今週はメルマガの発行が遅れてしまいました。メルマガを楽しみにしていた方、ごめんなさい。といいますのも、我が愛機Thinkpad T20のハードディスクが急遽逝ってしまったのです。嗚呼。カッチン、カッチン、音がするので、これはおかしいな・・・と思ったのですが（その時バックアップをとっておけば・・・）、スキャンディスクと、デフラグすれば、何とかなるだ・ろ・う・・・と思ったのが、運の尽き。今回は、唖然です。ホント大切なデータがなくなって初めて、バックアップの大切さを痛感しますね・・・。皆さんもぜひ、OSごとのバックアップまでいかなくても、大切なデータ、Email、お気に入りのバックアップはとっておいたほうがいいですよ。 そういうわけで、今週はスロースタートです。 前回は、.equals()と==の違いと、サブメニューを設定したユーザーインターフェイスを見ました。そして、前回の宿題では、仮想銀行システムにパスワードを設定するというものでした。 ■Authentication（認証）とAuthorization(認可） システムにログインするときは、一般的に、Authentication（認証）とAuthorization（認可）があります。認証と認可はどこが違うのかといいますと、認証は、『誰(Who)がアクセスしてきたのか』をチェックすることに対し、認可は『どのような権限(What, how)を与えるか』をチェックします。たとえば、あなたが仮想銀行システムにログインするときにまずIDとパスワードをチェックされるのが認証です。MrHackというIDがアカウントリストに存在して、そのパスワードが適切なものであれば、認証をパスできます。次にチェックされるのが、認可です。認証をパスしたあなたに、どれだけの権限を与えるかが決められます。あなたが一般のカスタマーということになれば、自分の口座の預金・引き出し・残高参照といった、機能を利用利用することが許可（認可）されます。しかしながら、権限外のすべての顧客情報（アカウントリスト）を見たり、ほかの人のアカウントをリセットしたりすることは、できません。 今回は、認証の後にチェックする認可は、おいておきまして、認証をチェックするプログラムを考えていきましょう。 ■データベースを視野に入れた設計（マルチユーザー） 本来ですと、仮想バンキングにログインするのは、あなただけではありませんね。顧客情報の閲覧権限を持った銀行関係者も含まれているかもしれません。その場合、あなたが入力したIDが、『どこか』の顧客リスト（アカウントIDリスト）の中に存在し、それにユーザーが入力したIDを照らし合わせて、IDが一致すれば（存在すれば）、パスワード入力を求め、パスワードが適切なら、ログインするという形になります。 ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ ２．で、『どこか』に注目です。この『どこか』を表す代表的な場所が、データーベースの中です。大きなシステムになりますと、データベース（オラクルのOracle 9i、マイクロソフトのMS SQL 2000、やその他フリーのMySQLなどのソフトウェアがデーターを管理）がありまして、そこにアカウント情報が保持されています。しかしながら、いつもこういったデータベースソフトが顧客情報を管理しているとは限りません、テキストファイルやXMLのような簡易的なものもデーターベースとして機能しますね。はたまた、システムがずーと起動しているのであれば、RAM（Random Access Memory、メモリー）に保持されているかもしれません。今現在では、その顧客情報が、データベースであろうが、ファイル上であろうが、メモリー上であろうが、関係ありません（最終的にはこのメルマガで、MS SQL2000かMy SQLでデータベースアクセスできるようになりましょう）。 ユーザーがログインする前に、『どこか』にデータが存在していればいいのです。今回は簡単にするため、マルチユーザーを考えませんので、任意のシングルユーザーを扱えればいいとします。つまり、ユーザーから入力されたIDがどこかに存在し、それをクエリー（Query、そのIDが存在しているかどうかを問い合わせ）し、存在していれば、その情報をUserInterfaceクラスで得れるように、あらかじめ、UserInterfaceクラスでそのシングルユーザーのオブジェクトを作成しておきます。 データベース等を使う場合ですと、データベースに直接問い合わせたり、データベースに問い合わせたりするクラスに"MrHack"をキーワードとしてクエリーします。直接データベースに問い合わせる場合は、UserInterfaceクラスにそのロジックを書かないといけないので、そのロジックを担当してくれるクラスを用意する方が役割を分担できます。たとえば、DataManagementクラスがその役割を担当し、その中の一つのメソッドget(int id)が渡されたidを元にデータベースに問い合わせたりして、得た情報をBankAccountクラスのオブジェクトにそれぞれ格納して、そのオブジェクトの参照先を返します。 ┌──────────────────────────────────┐ ユーザーがMrHackとMrha9を入力 DataManagement aContainerObject = new DataManagement(); └──────────────────────────────────┘ 何を言っているか、さっぱり分かりませんか？ ■今回の設計（シングルユーザー） 今回は、複雑な構造を全く抜きにしていきます。外部のクラス（データベース）や、問い合わせ等のプロセスは省略し、情報がBankUserInterfaceクラスに戻ってきたところからスタートします。 ┌──────────────────────────────────┐ 上記の『情報』を返す所だけに注目しBankAccountオブジェクトを参照して いるaccountは、あたかも外部のクラスがBankAccountクラスのオブジェクトに情報を詰めて、その参照先を教えてくれたかのように、newで確保された領域上の情報（idは"MrHak"で、passwordは"Mrha9"で、残高は0）を参照します。 もちろん、newで確保された領域に、"MrHack"、"Mrha9"、0を保持したBankAccountオブジェクトが存在するのは、当たり前ですね。newでメモリー領域を確保したのですから。しかし、将来は、このnewで確保した参照先ではなく、外部がデータベース（やファイル）を操作して得た結果をBankAccountオブジェクトに格納して、その参照先をaccountが参照するようになります。 Javaで書きますと、下記のようになります。
└──────────────────────────────────┘
class BankAcount { hasPassword(String aPassword) { 一方、今回のBankAccountクラスは、残高を表すbanlanceフィールドに付け加えて、新たにaccountIdとpasswordをインスタンフィールドに持ちます。 当分の間は、『どこかの』データベース（データを格納するスペース）に有効なIDがすでに存在すると仮定しますので、 ┌──────────────────────────────────┐ でいいですね。これは、"MrHack"をアカウントIDとするBankAccountクラスのオブジェクトが存在（メモリー上に存在）し、そのオブジェクトの参照先をaccountが、参照しているということを意味しましたね。そして、accountオブジェクトにhasPassword(myPassword)のようなメソッドを適用して、このmyPasswordが、すでにaccountが参照しているオブジェクトに格納されているインスタンスフィールドのpasswordと一致するか（aPasswordとpasswordが一致するか）チェックします。確認ですが、UserInterfaceクラスのmyPasswordとBankAccountのaPasswordは、ユーザーが入力したパスワードです。一方で、newで初期化したときの、accountが参照しているインスタンスはBankAccountのpasswordに"Mrha9"を保持することになりますね。 ここでパスワードが一致すれば、『どこか』データベース上にある（今回は、データベースの代わりにnew BankAccount()確保された、メモリー上にある）パスワードと一致することになりますから、ログイン成功です。 将来的には、/** */でコメントしたように、BankAccountクラスの参照変数であるaccountは、accountIdをキーワードとして検索し、該当したインスタンス（参照先）を参照します。別の言い方をすれば、データを管理するクラスのインスタンスのメソッド(たとえばBankAccountクラスのインスタンスを得るgetメソッド）に、ユーザーからのAccountIdを渡して、データベースを検索して、見つかったら、それをBankAccountオブジェクトにそれぞれ必要な情報（AccountId, Password, balance等）をいれて、そのオブジェクト（参照先）を返します。 そのため、ユーザーアカウントIDは"MrHack"だけでなく、利用するユーザーが入力したどんなIDも、キーワードとして検索して、見つかれば、accountがその見つかったオブジェクトを参照できます。
いままで、仮想バンキングシステムを構成しているクラスは、BankUserInterfaceクラスと、BankAccountクラスの二つですね。先ほどは、AccountIdとpasswordという変数を、役割分担という観点から、BankAccountクラスに入れると述べました。ユーザーインターフェイス部分を担うBankUserInterfaceクラスよりも、残高を計算するロジック部分のBankAccountクラスの方が適切だと。しかしながら、もっと積極的な理由があります。それは、オブジェクト指向の考えです。 皆さん、オブジェクトとは何でしたっけ？思い出してください。『たいやき』でしたね。クラスという鉄板型（設計図）を元にして作られた、たいやき（オブジェクト）です。オブジェクト指向プログラミングのオブジェクトは、人間の実生活を母体にしていますので、実際にある対象物（物体、考え）をそのまま投影しています。たい焼きを構成している要素（メンバー、フィールド）に、あんこ、目、色、があるように、Java上に投影されたTaiyakiというクラスにも、 ┌──────────────────────────────────┐ というようなフィールドを作ることができます。このクラスである設計図から、実際のオブジェクトであるたい焼きが作られるのでしたね。 それでは、BankAccountクラスはどうでしょう。もし、BankAccountクラスを、実社会にある預金口座（考え）、または、通帳（物体）が投影されたと考えると、どのようになるでしょう？預金口座には、口座番号があり、残高または、氏名などの個人情報がありますね。 ┌──────────────────────────────────┐ もちろんもっと口座というのを狭義にとらえて、口座とは、あるアカウントに対する残高だけを意味する（概念）として、addressなどは、別個の概念を意味するとするものと考えることもできますね。そうした場合は、新たに、address関係のphone, postalCodeなどのフィールドを格納する、Addressクラスをつくってもいいですね。 さて、BankAccountクラスにAccountIdとpasswordフィールドを入れることを決めました。しかしながら、口座を作るとき(BankAccountオブジェクトを作るとき）、IDとPasswordの仕様はどうしましょう？IDは100桁からなっていてもいいでしょうか？パスワードは、すべて同じだったり、1桁だけでもいいでしょうか？IDが100桁もあったら、IDを通帳番号として使うには、使いずらそうですね。というのも2桁あれば１００人分のIDを区別できますから(0から99までの数）、100桁というIDは、超がつくくらい、余裕で日本人口をカバーできてしまいます。そうすると100桁もあっても、そのほとんどの桁が意味をなさなくなってしまいますね。パスワードにおいては、1桁というパスワードを許せば、セキュリティー上大変な問題になります。なぜなら、いったんIDさえ分かってしまえば、1桁のため、10通り（0から9までの数字）で有効なパスワードを見つけることができてしまいます。 つまり、IDやPasswordには、何でも指定できるのではなく、ある規則を設定してあげないといけませんね。それが、今回のIDは3桁以上の大文字と小文字からなり、、Passwordは5桁以上の大文字、小文字、数字からなり、それぞれ最低一つ入れること、を設定した理由です。実際にどのように、Javaで書いていくかは来週のお楽しみです。 さて今日はこのくらいにして、宿題にいってみましょう。今週は、来週の予習をかねた宿題です。 ■Question 12 ちなみに、これは、コンピュータサイエンス学科の学生が最初の一年目に習わないといけないDiscrete Mathのトピックの一部です。さあ、アメリカの学生に負けていられません。数学と聞くと頭の痛い方もたくさんいらっしゃるでしょうが、がんばっていきましょう。 今回は、一つのアカウントが存在すると仮定したり、オブジェクト指向の考えを見ましたので、難しかったかと思います。疑問に思った点がありましたら、掲示板でどしどし質問してください。それでは、また会いましょう。 Mr.Hack ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ |
||
| © 2002 MR.HACK ALL RIGHTS RESERVED | ||