Webリソースのセキュリティ制約の設定

6573 ワード

tomcat Web アプリケーションサーバアルゴリズム Security

Serlvet仕様では、Webコンテナとは独立した構成のWebリソースセキュリティ制約を構成するための配置記述子を定義します.前述のブログではTomcatにおけるセキュリティドメインの実装について述べた.広くなると、我々のウェブアプリケーションのリソースセキュリティ制約は完全にWebコンテナにまたがっており、JSP/サーブレットをサポートするWebコンテナであれば、そのプロファイルに基づいてwebを構成することができる.xmlでは,およびの3つの要素を使用して構成され、その構成プロセスは以下の3つのステップに分けることができます.
1、要素を使用して、現在のWebアプリケーションで使用されているセキュリティロール名を宣言します.
2、要素を使用して、保護されたウェブリソースと保護されたリソースにアクセスできる役割とHTTPプロトコルを宣言します.
3、要素を使用して、サーバがどのタイプの検証方式を採用するかを宣言し、アクセス者に認証情報の入力と検証を要求します.

次に、セキュリティ制約構成の実装例を示します.
一、構成:現在のWebアプリケーションで使用されているセキュリティロールのリストを宣言します.
サブエレメント::Webアプリケーションのセキュリティロール名を指定する

<security-role>
   <role-name>username</role-name>
   <role-name>username2</role-name>
</security-role>

要素は0回以上表示できます.前の例では、usernameとusername 2の2つのセキュリティロールが宣言されています.

二、構成:保護されたウェブリソースと保護されたリソースにアクセスできる役割と転送プロトコルを宣言します.
サブエレメント:
1、:保護されたwebリソースを宣言し、1回または複数回表示できます.3つの主要なサブ要素が含まれています.
1)、:保護されたリソースを識別する名前で、1回のみ表示されます.
2)、:保護されたリソースのURLパスを指定し、1回または複数回表示します.
3)、:保護されたHTTPリクエスト方式(GET、POSTなど)を指定し、0回以上出現する.出現しない場合、すべてのHTTPリクエスト方式が保護されます.ユーザーが指定したリクエストで保護されたWebリソースにアクセスする場合は、セキュリティ検証が必要です.
2、:保護されたリソースにアクセスできる役割を宣言します.0回以上表示できます.
サブエレメント:

:Webアプリケーションのセキュリティロール名を指定します.要素は0回以上表示できます.保護されたWebリソースが複数のロールでアクセスできることを示す複数回の表示が表示されます.要素の内容が「*」の場合、Webアプリケーションに登録されているすべてのロールがこの手で保護されたリソースにアクセスできることを示します.
3、:保護されたリソースをどのような通信方式で伝送するかを指定します.0回以上表示できます.
サブエレメント:

:値はNONE、INTEGRAL、CONFidentIAlのいずれかになります.ここで、NONEは、暗号化されていない一般的な方法でアクセスされたリソースを転送することを示す.INTEGRALとCOnFIDENTIAlの2つの値は、現在のバージョンのサーブレット仕様では大きく異なりません.いずれも、保護されたWebリソースにHTTPSプロトコルのみでアクセスするためのSSL方式のデータinxing暗号化伝送を簡単に要求するだけです.

<security-constraint>
    <web-resource-collection>
      <web-resource-name>webapp</web-resource-name>
      <url-pattern>/jmxproxy/*</url-pattern>
      <url-pattern>/html/*</url-pattern>
      <url-pattern>/list</url-pattern>
      <url-pattern>/sessions</url-pattern>
      <url-pattern>/start</url-pattern>
      <url-pattern>/stop</url-pattern>
      <url-pattern>/install</url-pattern>
      <url-pattern>/remove</url-pattern>
      <url-pattern>/deploy</url-pattern>
      <url-pattern>/undeploy</url-pattern>
      <url-pattern>/reload</url-pattern>
      <url-pattern>/save</url-pattern>
      <url-pattern>/serverinfo</url-pattern>
      <url-pattern>/status/*</url-pattern>
      <url-pattern>*.jsp</url-pattern>
      <url-pattern>*.html</url-pattern>
      <http-method>GET</http-method>  
    </web-resource-collection>
    <auth-constraint>
       <!-- NOTE:  This role is not present in the default users file -->
       <role-name>manager</role-name>
       <role-name>username</role-name>
    </auth-constraint>
  </security-constraint>

例では、このWebアプリケーション内のすべてのJSPページおよびHTMLページおよびその他のファイルがmanagerまたはusernameロールに属するユーザによってGET要求方式でアクセスできることを示している.

三、構成:ユーザーが保護されたWebリソースにアクセスすると、Webサーバがアクセス者にアイデンティティ情報の入力と検証を要求する認証方法のタイプを宣言します.
サブエレメント:
1、:検証タイプを指定します.オプションの値はBASIC、DIGEST、FORMです.BASICとは、ブラウザがログイン情報入力ボックスをポップアップし、ユーザーの検証情報をbase 64アルゴリズムで符号化してwebサーバに送信することを指す.DIGESTとは、ブラウザがログイン情報入力ボックスをポップアップし、ユーザー情報をMD 5アルゴリズムで暗号化してwebサーバに送信することを指す(これはブラウザがMD 5の暗号化アルゴリズムをサポートする必要がある).FORMは、Web開発者がカスタマイズしたフォームページを使用してユーザー情報を入力および検証します.FORM検証を使用する場合は、要素を定義する必要があります.要素には、開発者がカスタマイズしたログインページとログインエラー処理ページをそれぞれ指定するために必要な2つの要素とが含まれています.
2、:セキュリティドメインの名前.
3、:FORM検証を使用する場合、要素を定義する必要があります.
BASICとDIGEST:

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Tomcat Manager Application</realm-name>
 </login-config>

FORM:

<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>Tomcat Manager Application</realm-name>
    <form-login-config>
       <form-login-page>/login.html</form-login-config>
       <form-error-page>/error.html</form-error-page>
    </form-login-config>
  </login-config>

また、認証方式がFORMである場合には、カスタムログインフォームのaction属性値を擬似パス「j_security-check」に設定、ユーザ名とパスワードのフィールド名を「j_username」と「j_password」と命名する必要がある.

<HTML>
 <HEAD>
  <TITLE> login.html </TITLE>
 </HEAD>
 <BODY>
   <FORM METHOD=POST ACTION="j_security_check">
      ：<INPUT TYPE="text" NAME="j_username" /><BR>
       ：<INPUT TYPE="text" NAME="j_password" /><BR>
	 <INPUT TYPE="submit" value="  " />&nbsp;&nbsp;
	 <INPUT TYPE="reset"  value="  " />
   </FORM>
 </BODY>
</HTML>

最後に、以上の3つの検証方式について、web.xmlファイルで構成されたセキュリティ制約は、クライアントが直接要求したリソース(HttpServeretResponse.sendRedirectメソッドを使用してリダイレクトしたリソースを含む)のみを保護します.つまり、ユーザーが直接要求したURLが要素のコンテンツと一致している場合にのみ、セキュリティ制約が有効になります.一方、Webアプリケーションでforwardまたはinclude方式で転送または含まれる対応するページについては、セキュリティ制約は有効ではありません.

C++における単例パターン(怠け者、餓漢)

spring-batchでメタデータとstepで異なるTransactionManagerを使う