2013年2月11日月曜日

◆認証

 

匿名認証

デフォルトでONになっているので通常は誰もがアクセスできる。
IISレベルでは匿名認証を許可し、アプリケーション側でユーザーID/パスワードを入力させて独自に認証するパターンも多い。

匿名認証の設定を行うには

  • 「IISマネージャ」を開く
  • 左側の「接続ペイン」で設定したいサイトを選択
  • 「機能ビュー」で「認証」をダブルクリック
    image
  • 「機能ビュー」で「匿名認証」を選択し、「操作ペイン」で「編集」をクリック
  • 「匿名認証資格情報の編集」画面が表示される
    この画面を見ると、デフォルトでは匿名アクセスユーザーは内部的に「IUSR」というユーザーで扱われることが判る。通常はそのままで良いのかと思うが、必要があれば「設定」ボタンを押して変更できる。image

※アプリケーションプールID

ここで指定できる「アプリケーションプールID」をちょっと調べてみた。
どのバージョンからかは判らないが、現在アプリケーションプールはその名前と同じユーザー名で動作しているようだ。

例えば、ここの「TestSite」というアプリケーションプールは「TestSite」というユーザーで実行されている。
image

タスクマネージャで確認すると、
image

アプリケーションプールの実体である「w3wp.exe」が「TestSite」ユーザーで実行されているのがわかる。

なので、「匿名認証資格情報の編集」で「アプリケーションプールID」を指定した場合は、この「TestSite」というユーザーが使われることになるのだろう。

なお、この「w3wp.exe」はデフォルトでは「開始モード」が「Ondemand」となっていてクライアントからのアクセスがないと起動されないようである。
よって確認するためには一時的に設定変更(「詳細設定」で「開始モード」を「AlwaysRunning」)しておくと良い。
image

基本認証とWindows認証
インストール

デフォルトでは「匿名認証」しかインストールされないようなので、「基本認証」のような他の認証を使うときは予めインストールが必要になる。

インストール方法はIIS: ◆アクセス制限で記載した「IPおよびドメインの制限」のインストール方法と同じである。
image

基本認証とWindows認証の違い

他にも「ダイジェスト認証」や最近追加になった?と思われるものがあるが、ポピュラーな「基本認証」と「Windows」認証を押さえておけばよいだろう。

「基本認証」と「Windows」認証と書いてしまうと、なにやらまったく別のユーザー管理を行うように感じるが(困ったことに今回参考にしている資料も混乱させる説明しか載っていない)、実は「基本認証」も使用するユーザーIDとパスワードはWindowsに登録しているユーザーIDとパスワードそのものである。

「基本認証」の場合はクライアントにログオンしているユーザーとは無関係に必ず「ログインダイアログ」が表示される。
そこにサーバーでユーザー登録されているユーザーIDとパスワードを入力することによって認証が行われる。

「Windows認証」では、通常、Windowsにログオンしているユーザーが自動的にブラウザからサーバーに伝えられて認証が行われる。
ただし、これはIEでかつイントラネット環境の場合のデフォルト動作なので、ブラウザが異なったり、インターネット環境の場合は動作が異なる可能性がある。(確か)

そう、結局のところ「基本認証」と「Windows認証」はユーザー管理的な視点からみれば同じものである。
単に、都度ダイアログ入力を必要とするかシームレスな認証になるかの違いでしかない。
要は、サーバーにたどり着くまでの道のりが違うだけである。

「基本認証」は暗号化されないが、サーバー・クライアントともにすべての環境でサポートされている可能性が高いので、そのような混在環境で必要とされるのだろう。(別途SSL等でセキュリティを確保)

一般的なWindowsのイントラネット環境であれば「Windows認証」を使のでしょう。

ASP.NETシステムなどでWindowsユーザーを使わずに独自ユーザー管理する場合は「匿名認証」を有効にしてIISの認証はスルーする形になるようです。

今回参照している「インターネット Web サーバー構築ガイドライン | IIS | マイクロソフト 技術情報」では「Windows認証」と呼んでいるが本当は「Windows統合認証」とでも呼ぶべきものではないだろうか。
そして「ASP.NET」などのシステムと絡めば、

IISの認証 ASP.NETでの認証
匿名認証 Form認証
基本認証 Windows認証
Windows統合認証
ダイジェスト認証

といった感じになるのでは?と思うが・・・。

アクセス許可

認証を受けた後のアクセス許可、すなわちどのユーザーはどのリソースにアクセスできるのかといったあたり。

ASP.NETシステムについてはアプリケーション側での制御になると思うので(Web.configでごねごね)、ここでは静的ページだけを考える。

IISマネージャでサイトやディレクトリを選択すると右側の「操作ペイン」に「アクセス許可の編集」というのが現れる。
image

これをクリックするとファイル(フォルダ)のプロパティ画面が表示される。
image

すなわち、アクセス許可の制御は通常のACLでやれという事なのだろう。

であれば特に目新しいことは無いので問題はない。

0 件のコメント:

コメントを投稿