Pubcookie：Webアプリケーションの単一認証ポイント

何らかの方法でシングルサインオン（シングルサインオン）のテクノロジを実装できるようにする多くのソリューションがあります。 シングルサインオンとは、専用認証サーバー（またはマシン上）に一度ログインすると、追加の認証なしで利用可能なすべてのネットワークリソースにアクセスできる状況を指します。



現在、自発的に開発されることが多い内部イントラネットサービスを徐々にリファクタリングし、さまざまな技術を検討しています。これらの技術を使用すると、内部インフラストラクチャがより便利で安全になります。



SSOテクノロジーは一般にかなり複雑ですが、Webアプリケーションのセットに対してのみシングルサインオンのタスクに限定する場合、アプリケーションコードを変更またはわずかに変更することなくこの機会を実現できる比較的単純なソリューションがあります。 このソリューションはPubcookieと呼ばれ、説明します。







Pubcookieを使用する場合、保護されたリソースを入力すると、特別な専用ログインサーバーに自動的にリダイレクトされ、ログインサーバーに自動的に戻ります。 同時に、保護されたアプリケーションで何も変更する必要はありません;以前のように、 REMOTE_USER



から現在のユーザーの名前を取得しREMOTE_USER



。



このメカニズムを設定する方法を見てみましょう。



作業スキーム



認証プロセスには、次のコンポーネントが関係しています。

1. クライアントブラウザ
2. 認証を必要とするアプリケーションがデプロイされているアプリケーションサーバー。この場合、Pubookieモジュールを備えたApacheと、実際には保護されたアプリケーション。
3. この場合のログインサーバーは、標準の認証アプリケーションとこのアプリケーションの設定を備えたApacheです。
4. 実際には、認証サービス。

認証は次のとおりです。

1. カスタムブラウザーは、Pubcookieを使用するように構成されたアプリケーションサーバーから特定のリソースを要求します。
2. アプリケーションサーバーにインストールされたPubcookieモジュールは、要求をインターセプトし、有効な現在のセッションに接続されておらず、新しいセッションを作成するためのログインサーバーからの情報（いわゆる許可Cookie）が含まれていないことを確認します。
   
   検証に成功すると、モジュールは、リダイレクトと2つのCookieを含む応答を生成します：アプリケーション用のプリセッションCookieとログインサーバー用の許可リクエストCookie両方のCookieには、モジュールによって生成された乱数が含まれます。 すべてのCookieは暗号化されます。
3. クライアントブラウザーは、許可要求Cookieを使用してログインサーバーへのリダイレクト（要求の許可）を実行します。 要求データにより、アクセスサーバーは、認証が要求されるアプリケーションサーバー、元の要求のURL、承認の種類などを決定できます。
4. ログインサーバーは、許可リクエストCookieをデコードし、コンテンツを解釈します。 サーバーはログインフォームを生成し、クライアントに送信します。
5. ユーザーはフォームにユーザー名とパスワードを入力し、ログインサーバーに送信します。
6. ログインサーバーはユーザー名とパスワードを受け取り、検証に使用される認証サービスに送信します。
7. ログインサーバーは認証サービスから検証結果を受け取ります。
8. 検証が成功すると、ログインサーバーはリダイレクトと2つの新しいCookieを含む応答を生成します。 最初の許可Cookieは、アプリケーションサーバー用であり、検証済みのユーザー名と、ステップ2で生成された乱数を含む追加情報が含まれます。この乱数には、アクセスサーバーの秘密キーで署名され、アプリケーションサーバーとアクセスサーバーで使用される対称キーで暗号化されています。 2番目のログインCookieは、ログインサーバー用であり、その後ユーザーがアクセスする場合に使用されます。
9. ユーザーブラウザは、アプリケーションサーバーから保護されたリソースを再要求します。 要求には、許可Cookieとセッション前Cookieが含まれます。
10. アプリケーションサーバー上のpubcookieモジュールは、要求をインターセプトし、許可Cookieを解読し、署名を検証し、許可Cookieの乱数をプレセッションCookieの同じ番号と比較します。 すべてが収束すると、ユーザー名がアプリケーションに渡され、アプリケーションがリクエストを処理します。 保護されたリソースへの後続のアクセスのために、セッションCookieも生成されます。 アプリケーションによって生成された応答がユーザーに送信されます。

ステップ4で許可リクエストに有効なログインCookie（ステップ8で設定）も含まれている場合、ステップ5、6、7はスキップされ、ログインサーバーは直接ステップ8に進み、ログインCookieから取得したユーザー名を使用して許可Cookieを生成します。 したがって、一連のWebアプリケーション用のシングルサインオンテクノロジーの要素が得られます。Webアプリケーションごとにログインする必要はなく、ユーザー名とパスワードを1回入力するだけです。



組立



Ubuntuについては、FreeBSDでは問題が発生しないことを考慮します。



www.pubcookie.orgからディストリビューションをダウンロードします。 アセンブリする前に、2つのパッチを作成します。



1. APXSの問題に対するパッチ構成：

 3783c3783 < APACHE_PREFIX=`$APXS -q PREFIX` --- > APACHE_PREFIX="/usr/share/apache2"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ハンマーで打つことにより、おそらくより正確に行うことができます。



2. src / index.cgi.cにUTF-8エンコーディングのパッチを適用します。

 461c461 < print_header (p, "Content-Type: text/html; charset=ISO-8859-1\n"); --- > print_header (p, "Content-Type: text/html; charset=utf-8\n");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成時に、入力用のモジュールとcgi-applicationのアセンブリを指定します。

 $./configure --enable-apache --with-apxs=/usr/bin/apxs2 --enable-login
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、できればdebパッケージで収集します。



キーと証明書の生成



保護されたリソースを使用するには、httpsが使用されます。 まあ、それは彼らが保護されている理由です。



2組のキーを生成します。



1つはSSLキーペアです。これは、ApacheがSSLとキーサーバー（以下について）で使用します。

 $ openssl req -new -x509 -out server.crt -newkey rsa:1024 -nodes -keyout server.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つ目は、許可Cookieの署名とチェックのためのキーペアの許可です。

 $ openssl req -new -x509 -out granting.crt -newkey rsa:1024 -nodes -keyout granting.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は純粋にデモであり、自己署名証明書を使用していますが、実際にはすべてがより複雑です。 したがって、おもちゃのCAバンドルを生成します。

 $ cp server.crt ca-bundle.crt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、server.crt、server.key、granting.crt、granting.key、c​​a-bundle.crtのファイルを取得します。



ログインサーバーのセットアップ



サーバーをaccess.techart.intranetと呼びます



アクセスサーバーでは、キーサーバーと認証アプリケーションがWebサーバーの制御下で実行されています。



キーサーバーは、Cookieのコンテンツの暗号化に使用される対称キーを配布します。 それぞれxinetdの下で開始し、そこで処方します：

 service keyserver { type = UNLISTED protocol = tcp port = 2222 disable = no socket_type = stream wait = no user = root group = tty server = /usr/local/pubcookie/keyserver }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

xinetdを再起動すると、サーバーはポート2222で利用可能になります。



認証アプリケーションは、https経由でアクセスできる必要がある通常のCGIアプリケーションです。 したがって、仮想ホストを構成する必要があります。

 <VirtualHost *:443> ServerName login.techart.intranet DocumentRoot /usr/local/pubcookie/login DirectoryIndex index.cgi AddHandler cgi-script cgi <Directory /> Options FoolowSymLinks Options +ExecCGI AllowOverride None </Directory> SSLEngine on SSLCertificateFile /usr/local/pubcookie/keys/server.crt SSLCertificateKeyFile /usr/local/pubcookie/keys/server.key </VirtualHost>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pubcookieを構成するために残ります。 ファイル/ usr / local / pubcookie / configを編集します。

 #    logging_level: 1 #   . #        auth.php, #     . basic_verifier: verify_fork verify_exe: /usr/local/pubcookie/auth.php #   SSL ssl_key_file: /usr/local/pubcookie/keys/server.key ssl_cert_file: /usr/local/pubcookie/keys/server.crt #  granting  granting_key_file: /usr/local/pubcookie/keys/granting.key granting_cert_file: /usr/local/pubcookie/keys/granting.crt # - (CGI) login_uri: https://access.techart.intranet/ login_host: access.techart.intranet enterprise_domain: .techart.intranet logout_prog: /logout/index.cgi #   keymgt_uri: localhost:2222 ssl_ca_file: /usr/local/pubcookie/keys/ca-bundle.crt #    default_l_expire: 8h #   -,  ,    . app_logout_string-app1.techart.intranet-app1:   app1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、認証サービスとして任意の外部プログラムが使用されている場合にverify_forkモードを使用し、ユーザーが識別されたかどうかに応じて正常またはエラー終了コードを返します。 この場合、プログラムは標準入力からユーザー名とパスワードを読み取ります。



私たちの場合、これは、たとえばデータベースやテキストファイルにアクセスできるphpスクリプトですが、他のモードはサポートされています。たとえば、LDAPやKerberosで動作します。



次に、ログインサーバーがキーサーバーに接続できるようにするキーを生成します。

 $ sudo keyclient -P access.techart.intranet
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

生成されたkeys/access.techart.intranet



書き込まれkeys/access.techart.intranet



。 この操作は、Pubcookieを使用してホストごとに実行する必要があります。



access.techart.intranetでこれらすべての操作を実行すると、ログインフォームが表示されます。



アプリケーションサーバーのセットアップ。



アプリケーションサーバーでは、アクセスサーバーと同じ方法でpubcookie構成ファイルを構成します。 さらに、mod_pubcookieモジュールをApacheに接続する必要があります。



これを行うには、ファイル/etc/apache2/mods-available/pubcookie.conf



作成します。

 PubcookieGrantingCertFile /usr/local/pubcookie/keys/granting.crt PubcookieSessionKeyFile /usr/local/pubcookie/keys/server.key PubcookieSessionCertFile /usr/local/pubcookie/keys/server.crt PubcookieKeyDir /usr/local/pubcookie/keys/ PubcookieLogin https://access.techart.intranet/ PubcookieLoginMethod POST PubcookieDomain .techart.intranet PubcookieEncryption AES PubcookieAuthTypeNames EGNetID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、すべてが通常通りです：

 /etc/apache2/mods-available/pubcookie.load: LoadModule pubcookie_module /usr/lib/apache2/modules/mod_pubcookie.so $ sudo a2enmod pubcookie $ sudo service restart apache2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、アプリケーション自体を構成します。

 <VirtualHost *:443> ServerName app1.techart.intranet <Directory /srv/http/app1> AuthType EGNetID require valid-user PubcookieAppID app1 Options Indexes FollowSymLinks MultiViews AllowOverride None AllowOverride AuthConfig Order allow,deny allow from all </Directory> SSLEngine on SSLCertificateFile /usr/local/pubcookie/keys/server.cert SSLCertificateKeyFile /usr/local/pubcookie/keys/server.key </VirtualHost>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、アプリケーション全体へのアクセスを閉じましたが、特定のサブディレクトリの認証オプションを規定し、それらを.htaccess



に入れるなどできました。



AllowOverride AuthConfig



設定すると、アプリケーションは現在のユーザーの名前をREMOTE_USERから取得できます。



Apacheを再起動し、すべてがうまくいったら、 app1.techart.intranetに移動したときにlogin.techart.intranetにリダイレクトしてログインし、自動的に戻ります。



仮想ホスト



上記のすべては、専用IPに関連付けられた仮想ホストで機能します。 名前ベースの仮想ホストを使用するには 、OpenSSL（バージョン0.9.8j以降）およびApache（2.2.12以降）でSNIサポートが必要です。 さらに、SNIは7より前のIEバージョンではサポートされていません。



この構成の場合、「共通名」フィールドには使用済みホストのリストが含まれている必要があります。 openssl.cnfを編集して、キーセットを再生成します。

 [req_distinguished_name] 0.commonName = Common Name (eg, YOUR name) 0.commonName_default = app1.techart.intranet 0.commonName_max = 64 1.commonName = Common Name (eg, YOUR name) 1.commonName_default = app2.techart.intranet 1.commonName_max = 64 ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Apacheの仮想ホストの説明では、次のように記述します。

 SLCipherSuite HIGH SSLProtocol all -SSLv2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてApacheを再起動します。



アクセスサーバーのユーザーインターフェイスを構成する



ログインサーバーのログインフォームとサービスページの外観は、login_templatesディレクトリにあるテンプレートを使用して構成できます。 UTF-8を使用するには、 index.cgi.c



にパッチを適用する必要があります。



ログアウトを構成する



セッションの終了は、別のアプリケーションとログインサーバーの両方で実行できます。 ログインサーバーでこれを行う最も簡単な方法は、単一のディレクティブを含む.htaccess



logout



サブディレクトリを作成することです。

 PubcookieEndSession redirect
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

合計



一般に、メカニズムは非常にシンプルであり、セットアップの主な難しさは、Pubcookieを使用した場合とOpenSSLを使用した場合のどちらでもありません。



したがって、実装の場合、最も重要なことは、基本キー/証明書管理インフラストラクチャを正しく構成することです。



同時に、イントラネット上に多くのレガシーアプリケーションが存在する状況では、Pubcookieを使用することで、最小限の労力で集中管理されたアクセス制御を実装できます。



いくつかのリンク：

• http: //www.pubcookie.org-プロジェクトサイト、2010年2月1日の最新バージョン。
• Apache 7.10でUbuntu 7.10にpubcookie 3.3をインストールする -この記事は古いですが、まだ関連しています。
• PubCookieを使用したシングルサインオンは別の記事です。