ApacheTomcatを使用したSSO - 開発者ドキュメント

1. 概要

この記事では、Tomcatサーバーの基本、その仕組み、およびTomcatのシングルサインオン（ SSO ）機能を有効にする方法について学習します。 TomcatサーバーとWebアプリに必要な構成について説明します。

2. Tomcatアーキテクチャ

Catalinaサーブレットコンテナを構成する主な部分は、コネクタを定義するサービスを含むサーバーとホストで構築されたエンジンであり、最後に、これらのホストにはコンテキストまたはWebアプリが含まれます。

コネクタはクライアントの要求をリッスンし、応答を送り返します。 Tomcat 10には、 HTTP / 1.1 、 HTTP / 2 、およびAJPのプロトコルへのコネクタがあります。

エンジンは、コネクタが受信した要求を処理し、出力を生成します。これには、処理パイプラインが含まれます。これは、応答を生成するために要求ごとに実行される一連のプロセスです。これらのプロセスは、Tomcatのバルブです。たとえば、TomcatのSSOはバルブとして実装されています。

その後、ネットワーク名をサーバーに関連付ける仮想ホストを定義するホストを見つけます。これはSSOバルブが定義されるレベルであるため、ホストのすべてのコンテキストはSSOの下にあります。

そして最後に、ホストに関連付けられたコンテキスト要素があります。これらのコンテキストは、サーバー上で実行されるWebアプリケーションです。コンテキストは、サーブレット仕様2.3以降に従う必要があります。

3. Tomcatでのシングルサインオン

Tomcatは、ホストレベルで構成する必要があるバルブにシングルサインオン機能を実装します。 SSOバルブはユーザーの資格情報を保存し、必要に応じてそれらを渡すため、ユーザーは再度ログインする必要がありません。

SSOバルブでは、次の要件が満たされている必要があります。

レルムまたは「ユーザーデータベース」は、仮想ホスト下のすべてのWebアプリで共有する必要があります。
Webアプリの認証メカニズムは、 Basic 、 Digest 、 Form 、 SSL 、またはSPNEGO[のいずれかの標準認証メカニズムである必要があります。 X153X]。
クライアントが保護されたリソースを要求すると、サーバーはWebアプリの認証メカニズムを実行します。
サーバーは、認証されたユーザーの役割を使用して、再度ログインせずに仮想ホストの下のWebアプリの保護されたリソースにアクセスします。
ユーザーがWebアプリからログアウトすると、サーバーはすべてのWebアプリのユーザーセッションを無効にします。
クライアントはCookieを受け入れる必要があります。 Cookieには、リクエストをユーザーの資格情報に関連付けるトークンが格納されます。

3.1. Tomcatサーバー構成

サーバー側では、SingleSignOnバルブとレルムまたは「ユーザーデータベース」を構成する必要があります。これらの構成は、Tomcatのインストールのconfフォルダーの下にあるserver.xmlファイル内にあります。 SSOバルブを追加するには、次の行のコメントを解除する必要があります。

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

この記事の例では、デフォルトで構成されたレルムに依存し、データベースにユーザーを追加するだけで済みます。レルムの定義は次のようになります。

<Realm
  className="org.apache.catalina.realm.UserDatabaseRealm"
  resourceName="UserDatabase"/>

この構成では、グローバルJNDIリソースを使用して、ユーザーのデータベースのソースを定義します。

<Resource name="UserDatabase" auth="Container"
  type="org.apache.catalina.UserDatabase"
  description="User database that can be updated and saved"
  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
  pathname="conf/tomcat-users.xml" />

リソースはタイプorg.apache.catalina.UserDatabaseのオブジェクトをインスタンス化し、ファクトリクラスorg.apache.catalina.users.MemoryUserDatabaseFactory[を使用してtomcat-users.xmlファイルからオブジェクトを設定します。 X221X]。

最後に、この記事の例で必要な管理者ロールを持つユーザーを追加する方法を示します。 tomcat-users.xmlファイルを変更する必要があります。

<tomcat-users xmlns="http://tomcat.apache.org/xml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
  version="1.0">
    <role rolename="admin"/>
    <user username="demo" password="demo" roles="admin"/>
</tomcat-users>

3.2. Webアプリの構成

サーバーを構成したら、各サーブレットのWEB-INFフォルダー内にあるweb.xml構成ファイルを使用してサーブレットを構成しましょう。

SSOを必要とするすべてのWebアプリは、保護されたリソースを持ち、Tomcat認証方法の1つを使用する必要があります。 サーブレットAPI仕様2.3で定義されているように、Webアプリの認証メカニズムは、web-app要素内のlogin-config要素で定義されています。この要素には、BASIC、DIGEST、FORM、またはCLIENT-CERTのいずれかの値を使用する必要があるauth-methodフォームが含まれます。認証方法ごとに構成は異なりますが、TomcatWebアプリの構成セクションでDIGESTおよびFORM認証方法についてのみ説明します。

Webアプリの構成を完了するには、保護領域を設定する必要があります。 web-app要素の下のweb.xmlファイル内に、必要な数のsecurity-constraint要素を追加できます。各セキュリティ制約は、保護されたリソースへのURLパターンを定義し、許可される役割を設定します。さらに、すべてのロールでsecurity-role要素を定義する必要があり、それらはtomcat-users.xmlファイルの定義と一致する必要があります。次のセクションで例を示します。

4. 認証メカニズムの例

Webアプリの構成方法がわかったので、PingとPongの2つの例を見てみましょう。 SSOがさまざまなメカニズムで適切に機能することを示すために、さまざまな認証メカニズムを選択しました。

4.1. ping認証メカニズム

ping Webアプリでは、FORM認証方式を使用します。 FORM認証方式にはログインフォームが必要であり、Webページへのログインに失敗しました。たとえば、このメソッドは、ログインページをWebアプリのようにカスタマイズする場合に役立ち、構成は次のようになります。

<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/logging.html</form-login-page>
        <form-error-page>/logging_error.html</form-error-page>       
    </form-login-config>
</login-config>

ログインページは、サーブレット仕様2.3 のログインフォームノートで定義されているいくつかの厳格なルールに従う必要があります。これは、フォームの名前も入力フィールドも選択できないためです。 j_security_check 、 j_username 、およびj_passwordである必要があります。これは、ログインフォームがすべての種類のリソースで機能することを実現し、サーバーでアウトバウンドフォームのアクションフィールドを構成する必要をなくすためです。ここに、それがどのように見える必要があるかの例を見ることができます：

<!DOCTYPE html>
<html>
<head>
    <title>Ping - Login</title>
</head>
<body>
    <form method="post" action="j_security_check">
        <table >
            <tr>
                <td>User name: </td>
                <td><input type="text" name="j_username" size="20"/></td>
            </tr>
            <tr>
                <td>Password: </td>
                <td><input type="password" name="j_password" size="20"/></td>
            </tr>
        </table>
        <p></p>
        <input type="submit" value="Submit"/>
         
        <input type="reset" value="Reset"/>
    </form>
</body>
</html>

サーバーがFORM認証済みWebアプリの保護されたリソースから要求を受信したときにサーバーで何が起こるかを理解するために、この認証メカニズムのフローを要約してみましょう。

まず、クライアントは保護されたリソースを要求します。サーバーに有効なSSOセッションIDが含まれていない場合、サーバーはクライアントをログフォームにリダイレクトします。ユーザーがフォームに入力し、その資格情報をサーバーに送信すると、認証メカニズムが開始されます。

ユーザー認証が成功すると、サーバーはユーザーの役割を確認し、セキュリティ上の制約により少なくとも1つの役割が許可されている場合、サーバーはクライアントを要求されたURLにリダイレクトします。別のケースでは、サーバーはクライアントをエラーページにリダイレクトします。

4.2. ポン認証メカニズム

Pong Webアプリでは、DIGEST認証メカニズムを使用しており、構成は次のようになります。

<login-config>
    <auth-method>DIGEST</auth-method>
</login-config>

DIGEST認証メカニズムのフローはBASIC認証に似ています。クライアントが保護されたリソースを要求すると、サーバーはユーザー資格情報を要求するダイアログボックスを返します。認証が成功すると、サーバーは要求されたリソースを返しますが、別の場合、サーバーは認証ダイアログボックスを再度送信します。

DIGEST認証方法とBASIC認証方法は似ていますが、重要な違いがあります。パスワードはサーバーに残ります。

4.3. Webアプリのセキュリティ制約の構成

現時点では、PingとPongを区別するつもりはありません。それらには異なる値の要素がありますが、構成の重要な部分は両方のアプリで同じままです。

<security-constraint>
    <display-name>Ping Login Auth</display-name>
    <web-resource-collection>
        <web-resource-name>PingRestrictedAccess</web-resource-name>
        <url-pattern>/private/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>admin</role-name>
    </auth-constraint>
    <user-data-constraint>
        <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
</security-constraint>

セキュリティ制約は、プライベートフォルダの下にあるすべてのものが保護されたリソースであることを定義し、リソースにアクセスするための管理者ロールが必要であることも定義します。

5. 例の実行

次に、 Tomcat 10 サーバーをインストールし、前の記事で示したように構成を調整し、PingおよびPongWebアプリをTomcatのWebアプリフォルダーに配置する必要があります。

サーバーが稼働し、両方のアプリがデプロイされたら、リソースhttp：// localhost：8080 / ping/privateをリクエストします。ログインしていないため、サーバーにログイン認証が表示されます。

次に、 Tomcatサーバー構成セクションで構成された資格情報を紹介し、フォームを送信する必要があります。サーバーが資格情報を検証すると、pongのプライベートセクションを指すリンクが記載されたWebページが表示されます。

サーバーがアクセスを検証しない場合は、ログインエラーページが表示されます。

Pingアプリへのログインに成功すると、Pongのプライベートセクションへのリンクをクリックして、SSOメカニズムが動作していることを確認できます。セッションがすでにアクティブになっている場合、サーバーは、再度ログインしなくても、Pongの保護されたリソースを送信します。

最後に、セッションの有効期限が切れた後、サーバーにログインページが再び表示されることを確認できます。これを行うには、数分待ってから、pingのプライベートセクションへのリンクをクリックします。

6. その他のSSOソリューション

この記事では、Tomcatサーバーによって実装されたWeb-SSOについて説明しました。他のSSOオプションを検討したい場合は、次のような一般的なオプションを使用します。

7. 結論

このチュートリアルでは、Tomcatアーキテクチャの基本を学びました。後で、サーバーの構成方法を確認しました。最後に、SSOに含める必要のあるサーブレットまたはWebアプリの構成を確認しました。

いつものように、完全なソースコードはGitHubでから入手できます。