JP4615247B2

JP4615247B2 - コンピュータシステム

Info

Publication number: JP4615247B2
Application number: JP2004138834A
Authority: JP
Inventors: 克朗菊地
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-05-07
Filing date: 2004-05-07
Publication date: 2011-01-19
Anticipated expiration: 2024-05-07
Also published as: JP2005321970A

Description

本発明は、クライアントからのログインに基づき機能するサーバを有するコンピュータシステムに関し、Ｗｅｂアプリケーションに自動的にログインする技術に関する。

企業内の情報システムは、従来のクライアントサーバ型システムからＷｅｂ（ＷｏｒｌｄＷｉｄｅＷｅｂ）技術を基盤とした３階層システムに移行しつつある。これまでに様々な業務がＷｅｂアプリケーション化され、業務効率の向上が図られてきている。しかしその一方で、企業内に多数の情報システムが業務ごとに存在する結果となり、ユーザは日常業務遂行のためこれらのシステムを巡回し、それぞれのシステムにログインするなど煩雑な操作を強いられている。この問題を解決するためにシングルサインオン技術が注目されている。シングルサインオンとは、認証を必要とする複数のシステムを利用する際に、一度だけログイン操作を行い認証を受けるのみで、全てのシステムを利用できるようにするログイン方式である。

シングルサインオン技術としては、クライアントが複数のＷｅｂサーバに自動ログインするためのポータルサーバを備え、ポータルサーバは、クライアントからアクセス要求があった場合、ユーザ認証処理を行い、このユーザ認証の結果、ログインを許可したユーザＩＤを基に、当該クライアントがよく利用するシステムのログイン情報を取り出し、Ｗｅｂサーバへのログインを代行する技術が知られている。（例えば、特許文献１参照。）。

また、Ｗｅｂサイトにおいて、Ｗｅｂサイトからクライアント側の末端に提供する情報として、クライアントのログインＩＤ及びパスワードからなる認証情報等を入力するためのサインアップ画面並びにＷｅｂサーバ内の所在を示すＵＲＬ情報にサインアップ画面で入力された任所情報を含ませたＵＲＬ情報を設定したブックマーク登録画面を用意して、クライアント側の末端に提供し、自動ログインを実現する技術が知られている（例えば、特許文献２参照。）。

また、ログイン代行システムがクライアントと複数のアプリケーションサーバに接続されたログイン要求に応答して、当該ユーザの当該アプリケーションに対する認証情報を含むログイン要求を生成して当該ユーザに代わってログインし、当該アプリケーションから返信されるレスポンスの内容を、当該クライアントが当該アプリケーションサーバから直接受け取った場合と同様に機能するように変換して、当該クライアントへ返信する技術が知られている（例えば、特許文献３参照）。
特開２００３−１４１０８１号公報特開２００２−４１３８０号公報特開２００２−３３４０５６号公報

前述した従来技術によると、基本的にバックエンドサーバを改変が必要であり、シングルサインオン実現のための構築期間や構築コストが大きくなる傾向がある。ITシステムの構築には、構築期間の短縮と費用対効果が求められており、これらの製品では、本要求の達成が難しい場合がある。

また、バックエンドサーバの改変が不要な特許文献３の方法によるシングルサインオンにおいても、代行サーバの計算機リソースに対する負荷が大きくなったり、JavaScript(登録商標)などクライアント側でＵＲＬを作成する場合に、ＵＲＬ変換が困難であったりと実現性に問題がある。また、ＵＲＬ変換を実現しても、リクエストＵＲＬ中にユーザＩＤ及びパスワードを埋め込む方法は、セキュリティ上の問題も残る。

本発明は、バックエンドサーバを改変することなく自動ログインを実現し、シングルサインオン環境が実現することを目的とする。

本発明は、クライアントに対するサービスの窓口となる窓口サーバと、前記クライアントにサービスを提供する一つ以上のバックエンドサーバと、前記バックエンドサーバへのアクセスを中継する中継サーバと、を含むコンピュータシステムにおいて、前記窓口サーバは、第１認証情報に基づいて前記クライアントに対する認証を行い、セッションを確立する第１セッション確立手段と、前記バックエンドサーバへのアクセスを当該窓口サーバに対して要求するリンクを含む画面を当該クライアントに送信する画面送信手段と、前記確立したセッションを維持しつつ、前記クライアントから前記バックエンドサーバへのアクセス要求を受け付けるアクセス要求受付手段と、前記クライアントから取得した前記第１認証情報に基づいて前記バックエンドサーバに対する前記クライアントの第２認証情報を取得する第２認証情報取得手段と、当該クライアントに対して前記中継サーバとのセッションを確立させる第２セッション確立手段と、を備え、当該中継サーバは、当該クライアントとのセッションを維持しつつ、当該クライアントから前記バックエンドサーバへのアクセス要求に前記窓口サーバが取得した第２認証情報を付加して、前記バックエンドサーバへアクセスを要求するアクセス要求手段を備え、前記バックエンドサーバは、前記第２認証情報によって認証を行った後、前記クライアントから要求されたコンテンツを前記中継サーバに送信するコンテンツ送信手段を備え、前記中継サーバは、前記バックエンドサーバからコンテンツを受信すると、当該コンテンツを前記クライアントに送信するコンテンツ中継手段を備えることを特徴とするコンピュータシステム。

本発明によればバックエンドサーバを改変することなく自動ログインを実現できる。これにより低コストでのシングルサインオン環境が実現できる。

以下、本発明の実施の形態を図面を参照して説明する。

（第１の実施形態）
まず、第１の実施形態として、バックエンドサーバのＷｅｂアプリケーションがBasic認証を用いる場合について説明する。

図１は、本発明の第１の実施形態のコンピュータシステムのシステム構成図である。

クライアント１００、窓口サーバ１０１、中継サーバ１０４、バックエンドサーバ１（１０６）及びバックエンドサーバ２（１０７）は、制御装置（ＣＰＵ）、メモリ、入出力装置及びネットワークインターフェイスを有し、制御装置（ＣＰＵ）がメモリに記憶されたプログラムを実行することによって演算処理を行うコンピュータ装置である。クライアント１００、窓口サーバ１０１、中継サーバ１０４、バックエンドサーバ１（１０６）及びバックエンドサーバ２（１０７）は、ネットワーク１０８によって接続されており、これらのコンピュータ装置間でデータや制御情報等が通信可能となっている。

窓口サーバ１０１及び中継サーバ１０４は、クライアント１００に対してバックエンドサーバ１０６、１０７への自動ログインを提供する。但し、クライアント１００からバックエンドサーバ１（１０６）及びバックエンドサーバ２（１０７）へのアクセスは、プロキシの設定によって、中継サーバ１０４を経由する。図１の例ではバックエンドサーバ１０６等は２つだが、多数のバックエンドサーバが設けられた場合には、クライアント１００は多数のバックエンドサーバへの自動ログインが可能である。

窓口サーバ１０１には、クライアント１００の窓口サーバへの認証情報が格納されたユーザ管理テーブル１０２（図３（ａ））、及びクライアント１００のバックエンドサーバ１０６等の認証情報が格納されたマッピングテーブル１０３（図３（ｂ））が設けられている。但し、窓口サーバ１０１がユーザ管理テーブル１０２及びマッピングテーブル１０３にアクセス可能であれば、ユーザ管理テーブル１０２及びマッピングテーブル１０３は窓口サーバ１０１の外部に設けられてもよい。

中継サーバ１０４には、バックエンドサーバ１０６等への自動ログインを行うための認証情報を格納する認証情報テーブル１０５（図３（ｃ））が設けられている。但し、中継サーバ１０４が認証情報テーブル１０５にアクセス可能であれば、認証情報テーブル１０５は中継サーバ１０４の外部に設けられていてもよい。

図２は、第１の実施形態のタイミングチャートであり、バックエンドサーバ１０６等がBasic認証を用いる場合を示す。

クライアント１００がバックエンドサーバ１（１０６）に自動ログインする場合には、まず、窓口サーバ１０１にログインする必要がある（２００）。具体的には、ユーザが入力した窓口ユーザＩＤ及び窓口パスワードを、クライアント１００のブラウザがログイン要求に含めて窓口サーバ１０１に送信する。クライアント１００からのログイン要求を受け取った窓口サーバ１０１は、ログイン要求に含められた窓口ユーザＩＤ及び窓口パスワードと、ユーザ管理テーブル１０２に記録された窓口ユーザＩＤ３００と窓口パスワード３０１の照合を行うことによって認証を行う（２０１）。ここで窓口サーバの認証方法は、Form認証やBasic認証等Ｗｅｂアプリケーションにおいて用いられる任意の認証方法でよい。

ユーザ認証（２０１）が成功したら、クライアント１００に窓口セッションＩＤ３０２を送信することによって、クライアント１００と窓口サーバ１０１のセッションを確立する（２０２）。以後、クライアント１００からのアクセスに、この窓口セッションＩＤ３０２を含めることによってセッションを有効にする。以降のこのセッションが有効な期間では、クライアント１００は自動ログイン対象のバックエンドサーバ１０６等への自動ログインが可能である。セッションが有効な期間とは、クライアント１００が窓口サーバ１０１からログアウトする、又はタイムアウトするまでである。

このセッション確立時（２０２）に、窓口サーバ１０１は、自動ログイン用画面４００（図４）をクライアント１００に送信する。

クライアント１００が自動ログイン用画面４００を受信し、ユーザがバックエンドサーバ１（１０６）へのアクセスを希望し、自動ログイン用画面４００（図４）でバックエンドサーバ１（１０６）へのログインを選択すると、クライアント１００から窓口サーバ１０１に対してバックエンドサーバ１（１０６）へのアクセスが要求される（２０３）。

すると窓口サーバ１０１は、本セッション（２０２）に対応する窓口ユーザＩＤ３００を取り出し、マッピングテーブル１０３から窓口ユーザＩＤ３００に対応したバックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５を取得する。

次いで、窓口サーバ１０１は、クライアント１００と中継サーバ１０４とのセッションを維持するために、ＳＳＯセッションＩＤ３０８を発行する（２０５）。ＳＳＯセッションＩＤ３０８は、乱数を用いて発行することが考えられる。

更に、窓口サーバ１０１は、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５に基づいて、Basic認証に必要な認証情報（ユーザＩＤとパスワードの間にコロン記号を入れ、全体文字列をＢａｓｅ６４で符号化した記号列）を作成し、ＳＳＯセッションＩＤ３０８と組みにして中継サーバ１０４の認証情報テーブル１０５に設定する（２０６）。

次いで、窓口サーバ１０６は、ＳＳＯセッションＩＤ３０８を設定させるため、ＨＴＴＰのリダイレクト要求（図５の５００）をクライアント１００に送信する（２０７）。

バックエンドサーバ１（１０６）へのＨＴＴＰリダイレクト要求を受け取ったクライアント１００は、ＳＳＯセッションＩＤ３０８の設定を要求するために、バックエンドサーバ１（１０６）にＳＳＯセッションＩＤ３０８を含めたアクセスを試みるが（図５の５０１）、予め、バックエンドサーバ１（１０６）にアクセスするときには中継サーバ（１０４）を経由するプロキシ設定がなされているので、クライアント１００は中継サーバ１０４にアクセスすることになる（２０８）。

クライアント１００からのアクセス要求を受け取った中継サーバ１０４は、ＵＲＬ（図５の５０１）からＳＳＯセッションＩＤ３０８を取り出す。更に中継サーバ１０４は、取り出したＳＳＯセッションＩＤ３０８をクライアント１００のＣｏｏｋｉｅに設定させ、バックエンドサーバ１（１０６）へのリダイレクトさせる要求（図５の５０２）をクライアント１００に送信する（２０９）。

中継サーバ１０４からのリダイレクト要求を受け取ったクライアント１００は、ＳＳＯセッションＩＤ３０８をＣｏｏｋｉｅに設定し、バックエンドサーバ１（１０６）へアクセスしようとする（図５の５０３）が、プロキシの設定によって、中継サーバ１０４にアクセスする（２１０）。クライアント１００は、Ｃｏｏｋｉｅの設定によってＳＳＯセッションＩＤ３０８を含んで中継サーバ１０５にアクセスする。

アクセスを受けた中継サーバ１０４は、認証情報テーブル１０５を参照して、ＳＳＯセッションＩＤ３０８に対応するバックエンドサーバ１（１０６）の認証情報３０９を取り出し、その認証情報３０９をクライアント１００からのアクセス要求のＨＴＴＰヘッダへ付加し、バックエンドサーバ１（１０６）へアクセス要求を行う（２１２）。

アクセス要求を受け取ったバックエンドサーバ１（１０６）は、ＨＴＴＰヘッダに付加された認証情報とバックエンドサーバ１（１０６）に記録された認証情報を照合してBasic認証を行う。認証が成功したら、コンテンツを中継サーバ１０４に送信する（２１３）。

バックエンドサーバ１（１０６）からコンテンツを受け取った中継サーバ１０４はクライアント１００にコンテンツを転送する。そして、クライアント１００が中継サーバ１０４から、バックエンドサーバ１（１０６）が送信したコンテンツを受け取る。

以上の処理によって、バックエンドサーバ１（１０６）がBasic認証の場合の自動ログインが実現できる。以降、バックエンドサーバ１（１０６）にアクセス要求するときは、２１０から２１４が繰り返される。

なお、本実施形態では、窓口サーバ１０１と中継サーバ１０４は別サーバとして説明したが、同一のサーバ（同一のプログラム）として実現することも可能である。このような構成の場合、クライアント１００と中継サーバ１０４との間で確立させるＳＳＯセッション（２０９）を、クライアント１００と窓口サーバ１０１との間で確立されているセッション（２０２）で代用することも可能である。セッションを代用する場合、ＳＳＯセッションＩＤ発行（２０５）で発行されるＳＳＯセッションＩＤ３０８は、クライアント１００と窓口サーバ１０１で確立されているセッション（２０２）の窓口セッションＩＤ３０２で代用することになる。よって、クライアント１００と中継サーバ１０４との間でセッションを確立するための処理ステップ２０７〜２０９は不要となる。代わりに、クライアント１００にバックエンドサーバ１（１０６）に対してアクセス要求を行わせるため、窓口サーバ１０１は、クライアント１００にＨＴＴＰリダイレクト要求を送信する。

以上によって、自動ログインが実現できる。

図３（ａ）は、ユーザ管理テーブル１０２の一例である。ユーザ管理テーブル１０２には、窓口ユーザＩＤ３００に対応して、窓口パスワード３０１及び窓口セッションＩＤ３０２が格納されている。窓口ユーザＩＤ３００及び窓口パスワード３０１は、クライアント１００の窓口サーバ１０１へのログイン時において、クライアント１００が送信した認証情報と照合される。本実施形態のユーザテーブル１０２では、窓口サーバ１０１とクライアント１００とのセッション維持のための窓口セッションＩＤ３０２も格納している。

図３（ｂ）は、マッピングテーブル１０３の一例である。マッピングテーブル１０３には、窓口ユーザＩＤ３０３に対応して、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５、並びにバックエンドサーバ２（１０７）のユーザＩＤ３０６及びパスワード３０７を格納されている。バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５とは、バックエンドサーバ１（１０６）へのアクセス時にバックエンドサーバ１（１０６）が予め記憶されている認証情報と照合される認証情報である。バックエンドサーバ２（１０７）に関しても同様である。

なお、マッピングテーブル１０３は、ユーザーインターフェイス（図６）を用いて画面からバックエンドサーバ１０６等の認証情報を入力させることによって、クライアント１００に設定させてもよいし、管理者が一括で設定してもよい。

図３（ｃ）は、認証情報テーブル１０５の構成の一例である。認証情報テーブル１０５には、ＳＳＯセッションＩＤ３０８に対応して、符号化された認証情報３０９が格納されている。

図４は、自動ログイン用画面４００の一例である。自動ログイン用画面４００には、バックエンドサーバ１（１０６）へのリンク４０２及びバックエンドサーバ２（１０７）へのリンク４０３が含まれ、バックエンドサーバ１（１０６）へのリンク先は４０１のように記載される。ユーザがバックエンドサーバ１（１０６）へのアクセスを要求する場合には、リンク４０２を選択することにより、自動ログインが実現される。

自動ログイン用のリンク先は、４０１に示すように窓口サーバ１０１の自動ログイン要求用ＵＲＬに、自動ログイン先を格納したパラメータを付加して形成される。但し、自動ログイン先をＵＲＬ中に付加する方法としては、自動ログイン先をＵＲＬの４０１以外のパス中に含めたり、ＨＴＴＰのＰＯＳＴメソッドを使って自動ログイン先をＰＯＳＴして実現してもよい。すなわち、ＰＯＳＴメソッドによると、リクエストに続く本体（エンティティ）に送信したいデータ（自動ログイン先）を含めることができる。

図６は、マッピングテーブル１０３をクライアント１００に設定させる場合のユーザーインターフェイスの一例である。バックエンドサーバ１（１０６）及びバックエンドサーバ２（１０７）の認証情報をユーザに入力させる画面を表示し、ユーザが認証情報の入力後に入力完了を指示（「ＯＫ」をクリック）すると、マッピングテーブル１０３に窓口ユーザＩＤ３０３に対応した認証情報が登録される。

図７は、自動ログイン及び直接ログインを併用した場合の実施形態のシステム構成図である。

前述したBasic認証の自動ログインと平行して、直接ログインしてバックエンドサーバ１（１０６）を利用したい場合には、自動ログイン用のサブドメインを作成し、自動ログイン時のみ中継サーバ１０４を経由するよう、ブラウザのプロキシ設定を変更するとよい。

具体的には、バックエンドシステム１（１０６）には、通常のログイン用とは異なる自動ログイン用のサブドメインssodomainを設けている。また、バックエンドシステム１（１０６）には、通常ログイン用のサブドメインanydomainも設けている。クライアント１００のプロキシは、ssodomainにアクセスするときには、ssogateway.ssodomain（中継サーバ１０４）をアクセスするように設定されている（７０２）。

自動ログイン時には、ssodomainにアクセス要求することによって、中継サーバ１０４を経由させ（７０１）、直接ログイン時には、anydomainにアクセス要求することによって、中継サーバ１０４を経由することなく（７００）バックエンドサーバ１（１０６）にアクセスできる。

直接ログインと自動ログインを併用することによって、不要なアクセス要求が中継サーバ１０４を経由せずにすむため、中継サーバ１０４の負荷を軽減することができる。

また、前述した実施形態では、中継サーバ１０４はバックエンドサーバ１（１０６）及びバックエンドサーバ２（１０７）と別に設けられており、Basic認証用ヘッダをアクセス要求に付加することで、Basic認証を行い自動ログインを実現しているが、中継サーバ１０４をそれぞれのバックエンドサーバ１０６等を構成するＷｅｂサーバの拡張機能を利用して実現することも可能である。

具体的には、クライアント１００からのアクセス要求をバックエンドサーバ１（１０６）のプログラムが受信する前に、Ｗｅｂサーバ内で取得させ、取得したアクセス要求にBasic認証用ヘッダを付加し、バックエンドサーバ１（１０６）のプログラムに送信することによって、自動ログインを実現する。マイクロソフト社のIIS(Internet Information Server / Internet Information Service)の場合はISAPIインターフェイス、Apache Software FoundationのApache ＷｅｂサーバのApache APIを利用することで実現可能である。

以上説明したように第１の実施形態によると、バックエンドサーバ１０６等がBasic認証を用いる場合に自動ログインを実現することができる。

すなわち、Basic認証では、クライアントがバックエンドサーバにアクセス要求をすると、バックエンドサーバはクライアントに対して、ユーザＩＤ及びパスワードの認証情報を要求する。クライアントは、ユーザが入力したユーザＩＤ及びパスワードをＢａｓｅ６４で符号化したBasic認証用ヘッダを付加して、バックエンドサーバにアクセス要求を行う。アクセス要求を受けたバックエンドサーバは、送信されたBasic認証用ヘッダとバックエンドサーバに記憶されているユーザＩＤ及びパスワードを照合することによって認証を行っている。

このようなBasic認証において、クライアントは、バックエンドサーバに対する全てのアクセス要求毎にBasic認証用ヘッダをＨＴＴＰヘッダに付加する必要がある。しかし通常は、ブラウザが、クライアントからの最初のアクセス要求時に、取得したユーザＩＤ及びパスワードをブラウザの内部に保存し、バックエンドサーバへのアクセス要求毎に、自動的にBasic認証用ヘッダを、リクエストのＨＴＴＰヘッダに付加することによって実現している。なお、Microsoft社のInternet ExploreやNetscape CommunicationsのNetscape Navigatorなど一般的なブラウザは、Basic認証用のユーザＩＤ及びパスワードを外部からブラウザに設定することは不可能である。

そこで、第１の実施形態では、クライアント１００からバックエンドサーバ１（１０６）へのアクセス要求時のＨＴＴＰリクエストを直接送信しないで、中継サーバ１０４を経由させ、中継サーバ１０４がBasic認証用ヘッダをＨＴＴＰヘッダに付加することによって、Basic認証のシングルサインオンを実現している。

（第２の実施形態）
次に、本発明の第２の実施形態として、バックエンドサーバのＷｅｂアプリケーションがForm認証を用いる場合について説明する。

図８は、本発明の第２の実施形態のコンピュータシステムのシステム構成図である。

第２の実施形態では、前述した第１の実施形態と異なり、中継サーバ１０４及び認証情報テーブル１０５は設けられていない。それ以外の構成は、第１の実施形態と同一である。なお、第１の実施形態と同じ構成は同じ符号を付し、その説明は省略する。

図９は、第２の実施形態のタイミングチャートであり、バックエンドサーバ１０６等がForm認証を用いる場合を示す。

クライアント１００がバックエンドサーバ１（１０６）に自動ログインする場合の最初のステップは、前述した第１の実施形態の２００から２０４と同様である。

窓口サーバ１０１が、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５を取得したら（２０４）、窓口サーバ１０１はバックエンドサーバ１（１０６）にログインを行う（９００）。このログインは、通常のForm認証のログインと同様であり、バックエンドサーバ１（１０６）がＰＯＳＴメソッドを要求している場合には、窓口サーバ１０１は、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５をＰＯＳＴする（リクエストに続く本体（エンティティ）に送信したいデータ（ユーザＩＤ３０４及びパスワード３０５）を含めて送信する）。また、バックエンドサーバ１（１０６）がＧＥＴメソッドを要求している場合には、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５をＧＥＴする（ＵＲＬにユーザＩＤ３０４及びパスワード３０５をクエリとして含めて送信する）。

なお、Form認証を行う際に、予め特定のページにアクセスしてセッションＩＤを取得するなど前処理が必要な場合には、窓口サーバ１０１が前処理を行ってもよい。また認証方法は、ユーザＩＤ３０４及びパスワード３０５以外の任意の情報を使った認証方法でもよい。

ログイン要求を受け取ったバックエンドサーバ１（１０６）は、ログイン要求からユーザＩＤ３０４及びパスワード３０５を取得する。バックエンドサーバ１（１０６）は、取得したユーザＩＤ３０４及びパスワード３０５を予め記憶されているユーザＩＤ及びパスワードと照合することによって、バックエンドユーザ認証を行う（９０１）。バックエンドサーバ１（１０６）は、認証が成功したら、バックエンドセッションＩＤを発行し、窓口サーバ１０１にログイン後画面とバックエンドセッションＩＤを送信する（９０２）。

応答を受けた窓口サーバ１０１は、応答からバックエンドセッションＩＤを取得して、クライアント１００への引継ぎ処理を行う。

引継ぎ処理は、バックエンドサーバ１（１０６）のセッショントラッキング方式により異なる。セッショントラッキング方式とは、セッションの概念がないＨＴＴＰにおいて、セッションを維持する方式であり、Ｃｏｏｋｉｅ方式とＵＲＬ書き換え方式がある。Ｃｏｏｋｉｅ方式は、クライアント１００のＣｏｏｋｉｅにバックエンドセッションＩＤを設定し、クライアント１００がバックエンドサーバ１（１０６）へのアクセスにＣｏｏｋｉｅを含めることによって、セッションを維持する方式である。ＵＲＬ書き換え方式は、バックエンドサーバ１（１０６）の応答コンテンツ中のＵＲＬにバックエンドセッションＩＤを埋め込んでアクセスすることによって、セッションを維持する方式である。以下、それぞれのセッショントラッキング方式について自動ログイン方法を順に説明する。

まず、バックエンドサーバ１（１０６）のセッショントラッキング方式がＣｏｏｋｉｅ方式の場合を説明する。

バックエンドセッションＩＤを発行したバックエンドサーバ１（１０６）は、図１０の１０００に示すように、ＨＴＴＰ応答ヘッダにＣｏｏｋｉｅを設定してセッションＩＤを窓口サーバ１０１に送信する（９０２）。

応答を受け取った窓口サーバ１０１は、ＨＴＴＰの応答ヘッダからバックエンドセッションＩＤを取得する（９０３）。次いで、窓口サーバ１０１は、クライアント１００にセッションＩＤ引継ぎ用リダイレクト応答（図１０の１００１）を送信する（９０４）。セッションＩＤ引継ぎ用リダイレクト応答によって、クライアント１００は、バックエンドセッションＩＤをdomain指定を利用したＣｏｏｋｉｅに設定する（ssodomainサブドメインのサーバに対してsessionid=xvzのＣｏｏｋｉｅを設定する）。更にクライアント１００は、バックエンドサーバ１（１０６）にアクセスする。Ｃｏｏｋｉｅのdomain指定によって、クライアント１００が、指定されたドメイン（ssodomainサブドメイン）にアクセスするときに、設定されたＣｏｏｋｉｅ（sessionid=xvz）をアクセス要求に含めてアクセスを行う。

domain指定を利用すること並びに窓口サーバ１０１及びバックエンドサーバ１（１０６）を同一のサブドメインに配置することによって、窓口サーバ１０１からバックエンドセッションＩＤ設定のリダイレクト要求を受けたクライアント１００が、バックエンドサーバ１（１０６）に対しても同一のバックエンドセッションＩＤを設定し、セッションを維持することができる。

このため、Ｃｏｏｋｉｅ方式の場合には、窓口サーバ１０１とバックエンドサーバ１（１０６）を同一のサブドメインに配置する。本実施形態ではssodomainに両サーバを配置している。窓口サーバ１０１は、サブドメインがssodomainのサーバに対して、sessionid=xyzのＣｏｏｋｉｅをクライアント１００に設定させるリダイレクト要求を送信している（図１０の１００１）。

窓口サーバ１０６からリダイレクト要求を受け取ったクライアント１００は、前記のＣｏｏｋｉｅの設定によって、バックエンドサーバ１（１０６）のバックエンドセッションＩＤを含めて（図１０の１００２）、バックエンドサーバ１（１０６）へアクセスを要求する（９０５）。アクセスを受けたバックエンドサーバ１（１０６）は、クライアント１００のアクセス要求からバックエンドセッションＩＤを取り出し、バックエンドセッションＩＤに対応する処理を行う。

以降、クライアント１００はＣｏｏｋｉｅを含むアクセスをバックエンドサーバ１（１０６）に直接行う。

以上の処理によって、バックエンドサーバ１（１０６）がForm認証の場合の自動ログインを実現することができる。

次に、バックエンドサーバ１（１０６）のセッショントラッキング方式がＵＲＬ書き換え方式の場合について説明する。

Ｃｏｏｋｉｅ方式との相違点は図９の９０２以降である。ＵＲＬ書き換え方式の場合、バックエンドサーバ１（１０６）は、バックエンドセッションＩＤが含まれた応答コンテンツ（図１１の１１００）を窓口サーバ１０１に送信する（９０２）。

応答コンテンツを受け取った窓口サーバ１０１は、応答コンテンツからバックエンドセッションＩＤを取得する（９０３）。

次いで、窓口サーバ１０１は、クライアント１００へセッションＩＤ引継ぎ用リダイレクトを送信する（９０４）。セッションＩＤ引継ぎ用リダイレクトは、クライアント１００をバックエンドサーバ１（１０６）へアクセスさせるＵＲＬ中に、取得したバックエンドセッションＩＤを埋め込んである（図１１の１１０１）。

リダイレクト要求を受け取ったクライアント１００は、バックエンドサーバ１（１０６）にバックエンドセッションＩＤを含んだＵＲＬ（図１１の１１０２）によってアクセスする（９０５）。

アクセス要求を受けたバックエンドサーバ１（１０６）は、クライアント１００のアクセス要求からバックエンドセッションＩＤを取り出し、バックエンドセッションＩＤに対応する処理を行う。

なお、ＵＲＬ書き換え方式の場合には、Ｃｏｏｋｉｅ方式のように、窓口サーバ１０１とバックエンドサーバ１（１０６）を同一サブドメインにおく必要はない。

（第３の実施形態）
次に、本発明の第３の実施形態として、バックエンドサーバのＷｅｂアプリケーションがForm認証を用いている場合の別の実施形態を説明する。

第３の実施形態のシステム構成は、前述した第２実施形態（図８）と同様の構成である。

図１２は、第３の実施形態のタイミングチャートであり、バックエンドサーバ１０６等がForm認証を用いている場合を示す。なお、本実施形態では、バックエンドサーバのセッショントラッキング方式がＣｏｏｋｉｅ方式又はＵＲＬ書き換え方式のいずれでも適用できる。

窓口サーバ１０１が、バックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５を取得したら（２０４）、取得したバックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５をログイン用フォームに埋め込み、埋め込んだログイン用フォームを、クライアント１００に送信する（１２００）。ログイン用フォームは、クライアント１００がバックエンドサーバ１（１０６）にログイン要求するＵＲＬ並びにアクセスするバックエンドサーバ１０６等のユーザＩＤ３０４等及びパスワード３０５等を埋め込む場所を含んでいる。更にバックエンドサーバ１０６等のユーザＩＤ３０４等及びパスワード３０５等が記載されるinput typeをhidden属性とすること及び応答ＨＴＭＬ読み込み時にフォームをサブミットするようになっている（図１３の１３００）。input typeをhidden属性とすることによって、ＨＴＭＬ読み込み時にバックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５がクライアント１００の画面に表示されない。また、onloadイベントのハンドラスクリプトを使うことによって、応答ＨＴＭＬ読み込み時にフォームをサブミットするので、応答ＨＴＭＬの読み込み完了と同時に、クライアント１００はバックエンドサーバ１（１０６）のユーザＩＤ３０４及びパスワード３０５を含んだログイン用フォーム（図１３の１３０１）をバックエンドサーバ１（１０６）に送信する（１２０１）。

そして、バックエンドサーバ１（１０６）が、クライアント１００から送信された認証情報とバックエンドサーバに記憶されている認証情報を照合し、認証が成功すると、クライアント１００はバックエンドサーバ１（１０６）へログインを行うことができる。

（第４の実施形態）
次に、本発明の第４の実施形態として、サマリ機能付きの自動ログインについて説明する。

図１４の１４００は、サマリ機能付き自動ログインの自動ログイン画面（サマリ画面）の一例である。サマリ機能とは、自動ログイン画面をサマリ情報（要約情報）を含む表示として、ユーザが、サマリ情報からバックエンドサーバ１０６等のアクセスしたいコンテンツを直接選択し、アクセスすることができる機能である。サマリ画面１４００は、バックエンドサーバ１（１０６）の「ＰＣ貸し出し依頼」（１４０１）及び「旅費精算依頼」（１４０２）というサマリ情報のリンク並びにバックエンドサーバ２（１０７）のサマリ情報のリンク（図示省略）から構成される。

バックエンドサーバ１（１０６）の「ＰＣ貸し出し依頼」（１４０１）及び「旅費精算依頼」（１４０２）の詳細情報へのリンク先は、それぞれ１４０３及び１４０４のように記載される。

本実施形態では、クライアント１００と窓口サーバ１０１のセッション確立時（２０２）に、窓口サーバ１０１が送信する自動ログイン用画面は、バックエンドサーバ１０６等への固定のページ（例えば、トップページ）へのリンクから構成される自動ログイン用画面４００に代わって、バックエンドサーバ１０６等のサマリ情報を含むサマリ画面１４００となる。

クライアント１００がサマリ画面１４００を取得することによって、バックエンドサーバ１０６等の固定のページにアクセスせずに、必要なコンテンツに直接アクセス要求することが可能となり、バックエンドサーバ１０６等への無駄なアクセスを減らすことができる。

本実施形態の自動ログインは、前述した第１から第２の実施形態の自動ログインを適用することにより実現する。なお、前述した第３の実施形態を適用することはできない。

第１及び第２の実施形態では、窓口サーバは、セッション確立２０２時の応答コンテンツとして、バックエンドサーバ１０６等の固定のページへのリンクから形成される自動ログイン用画面４００を送信している。本実施形態では、クライアント１００が窓口サーバ１０１にログインし、ユーザ認証（２０１）を受けた後に、窓口サーバ１０１がバックエンドサーバ１０６等にアクセスしてサマリ画面１４００を作成する。（サマリ画面の作成に方法については後記する。）そして、窓口サーバ１０１は、作成したサマリ画面１４００をセッション確立２０２時に、クライアント１００に応答コンテンツとして送信する。

応答を受けたクライアント１００は、サマリ画面１４００を表示し、ユーザがサマリ画面１４００中のバックエンドサーバ１（１０６）の「パソコン貸し出し情報」のリンク１４０１を選択すると、自動ログインを行い、直接「パソコン貸し出し情報」の詳細情報にアクセスすることができる。この自動ログインは、本実施形態に適用した前述の第１又は第２の実施形態を使った自動ログインである。

図１５は、サマリ画面（図１４の１４００）の作成処理のフローチャートである。

窓口サーバ１０１は、ユーザ認証２０１後、マッピングテーブル１０３からクライアント１００の窓口ユーザＩＤ３０３に対応するバックエンドサーバ１０６等のユーザＩＤ３０４等及びパスワード３０６等を取得する(１５００)。

次いで窓口サーバ１０１は、取得したユーザＩＤ３０４等及びパスワード３０６等を用いて、バックエンドサーバ１０６等にログインする(１５０１)。ログインは、第１の実施形態が適用される場合にはBasic認証用ヘッダをＰＯＳＴし、第２の実施形態が適用される場合にはログイン用フォームを、ＰＯＳＴ又はＧＥＴする。

ログインした窓口サーバ１０１は、バックエンドサーバ１０６等のサマリ情報とする情報が存在するコンテンツを取得する(１５０２)。このコンテンツの取得は、ログイン時（１５０１）の応答コンテンツで足りる場合には必要ない。

次いで、窓口サーバ１０１は、ＨＴＭＬのパーサや文字列処理を使って、取得したコンテンツからクライアント１００向けのサマリ情報となる情報の見出し及びＵＲＬを取得する(１５０３)。

更に、窓口サーバ１０１は、取得したすべてのＵＲＬを窓口サーバ１０１を経由させるため、窓口サーバ１０１のＵＲＬに、詳細情報のＵＲＬをエンコード（符号化）してクエリに付加したＵＲＬ（１４０２、１４０３）に変換する(１５０４)。変換したＵＲＬは、窓口サーバ１０１を経由させるための変換であれば任意の変換方法であってもよい。

ＵＲＬを変換した窓口サーバ１０１は、１５０３で取得した見出し及び１５０４で変換したＵＲＬを用いてサマリ画面１４００を作成し、クライアント１００に送信する(１５０５)。

サマリ画面１４００を受信したクライアント１００は、サマリ画面１４００を表示する。そして、ユーザがサマリ画面１４００中のサマリ情報のリンク１４０１等を選択して、窓口サーバ１０１に自動ログイン要求がされると、窓口サーバ１０１は、エンコードされているクエリ中の詳細情報のＵＲＬをデコードする。

以降のステップは、本実施形態として適用した第１又は第２の実施形態の２０４以降と同様である。

但し、第１の実施形態が適用される場合には、図５の５００〜５０３のＵＲＬのクエリ及びパラメータを除いた部分と詳細情報のＵＲＬが置き換わることとなる。第２の実施形態が適用される場合にも、図１０の１０００〜１００２及び図１１の１１０１〜１１０２のＵＲＬのクエリ及びパラメータを除いた部分と詳細情報のＵＲＬが置き換わることとなる。

以上の処理によって、サマリ機能付きの自動ログインを実現することができる。

本発明によると、シングルサインオンが実現されることによって、ユーザの煩雑なログイン操作やパスワード管理が不要となる。更にバックエンドサーバの改変無しにシングルサインオンを実現できるので、低コストでのシングルサインオン環境が実現できる。これらの効果により社内ＩＴシステムに適用することができる。

本発明の第１の実施形態のコンピュータシステムのシステム構成図である。本発明の第１の実施形態のタイミングチャートである。本発明の第１の実施形態のユーザ管理テーブル、マッピングテーブル及び認証情報テーブルの構成図の一例である。本発明の第１の実施形態の自動ログイン用の画面及び自動ログイン用ＵＲＬの一例の説明図である。本発明の第１の実施形態において通信されるメッセージの一例の説明図である。本発明の第１の実施形態のバックエンドサーバのユーザＩＤ及びパスワードの設定画面の一例である。本発明第１の実施形態で自動ログイン及び直接ログインを併用した場合のシステム構成図である。本発明の第２及び第３の実施形態のコンピュータシステムのシステム構成図である。本発明の第２の実施形態のタイミングチャートである。本発明の第２の実施形態において通信されるメッセージの一例の説明図である。本発明の第２の実施形態において通信されるメッセージの一例の説明図である。本発明の第３の実施形態のタイミングチャートである。本発明の第３の実施形態において通信されるメッセージの一例の説明図である。本発明の第４の実施形態の自動ログイン用の画面及び自動ログイン用ＵＲＬの一例の説明図である。本発明の第４の実施形態のサマリ画面作成処理フローチャートである。

符号の説明

１００クライアント
１０１窓口サーバ
１０２ユーザ管理テーブル
１０３マッピングテーブル
１０４中継サーバ
１０５認証情報テーブル
１０６バックエンドサーバ１
１０７バックエンドサーバ２
１０８ネットワーク

Claims

クライアントに対するサービスの窓口となる窓口サーバと、前記クライアントにサービスを提供する一つ以上のバックエンドサーバと、前記バックエンドサーバへのアクセスを中継する中継サーバと、を含むコンピュータシステムにおいて、
前記窓口サーバは、
第１認証情報に基づいて前記クライアントに対する認証を行い、セッションを確立する第１セッション確立手段と、
前記バックエンドサーバへのアクセスを当該窓口サーバに対して要求するリンクを含む画面を当該クライアントに送信する画面送信手段と、
前記確立したセッションを維持しつつ、前記クライアントから前記バックエンドサーバへのアクセス要求を受け付けるアクセス要求受付手段と、
前記クライアントから取得した前記第１認証情報に基づいて前記バックエンドサーバに対する前記クライアントの第２認証情報を取得する第２認証情報取得手段と、
当該クライアントに対して前記中継サーバとのセッションを確立させる第２セッション確立手段と、を備え、
当該中継サーバは、当該クライアントとのセッションを維持しつつ、当該クライアントから前記バックエンドサーバへのアクセス要求に前記窓口サーバが取得した第２認証情報を付加して、前記バックエンドサーバへアクセスを要求するアクセス要求手段を備え、
前記バックエンドサーバは、前記第２認証情報によって認証を行った後、前記クライアントから要求されたコンテンツを前記中継サーバに送信するコンテンツ送信手段を備え、
前記中継サーバは、前記バックエンドサーバからコンテンツを受信すると、当該コンテンツを前記クライアントに送信するコンテンツ中継手段を備えることを特徴とするコンピュータシステム。
前記画面送信手段は、
前記第２認証情報取得手段と、
前記取得した第２認証情報を用いて前記バックエンドサーバにログインしてコンテンツを取得するコンテンツ取得手段と、
前記取得したコンテンツからサマリ情報となる情報の見出し及びリンクを抽出するサマリ情報抽出手段と、
前記抽出したリンクに対して窓口サーバを経由させるための変換をするリンク変換手段と、
前記取得した見出し及び前記変換したリンクを用いてサマリ画面を作成するサマリ画面作成手段と、
前記作成したサマリ画面を前記クライアントが前記窓口サーバにログインした際に返却するサマリ画面返却手段と、を備えることを特徴とする請求項１に記載のコンピュータシステム。