(57)【要約】      （修正有）【課題】シングルサインオンによるログイン先のシステムへの影響を抑制しつつ、ＪＩＴ（ジャスト、イン、タイム）プロビジョニングを実現する。【解決手段】リバースプロキシ１２は、ユーザの認証処理を実行する業務サーバである人事情報サーバ２０、経理情報サーバ２２、ファイルサーバ２４、クラウドサーバ２６に対するユーザ端末１８からのアクセスを業務サーバに代わって受け付ける。認証サーバ１４は、業務サーバとは独立してユーザ端末１８のユーザを認証する。連携装置１６は、認証サーバ１４による認証が成功したユーザのアクセスを許可するように、業務サーバで予め定められた手続にしたがって業務サーバに指示する。リバースプロキシ１２は、認証サーバ１４による認証が成功したユーザの情報をユーザ端末１８へ送信し、その情報を用いた認証要求をユーザ端末１８から業務サーバへ送信させる。【選択図】図１
2016218825.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの認証処理を実行する外部装置に対するユーザ端末からのアクセスを前記外部装置に代わって受け付けるプロキシ部と、
前記外部装置とは独立して前記ユーザ端末のユーザを認証する認証部と、
前記認証部による認証が成功したユーザのアクセスを許可するように、前記外部装置で予め定められた手続にしたがって前記外部装置に指示する連携部と、
を備え、
前記プロキシ部は、前記認証部による認証が成功したユーザの情報を前記ユーザ端末へ送信し、当該情報を用いた認証要求を前記ユーザ端末から前記外部装置へ送信させることを特徴とするシングルサインオンシステム。
【請求項２】
前記連携部は、ユーザの認証処理を各々独立して実行する複数の外部装置のそれぞれで予め定められた手続であって、ユーザのアクセスを許可するように指示するための手続に関する情報を保持し、
前記プロキシ部は、前記複数の外部装置のうち特定の外部装置に対するユーザ端末からのアクセスを受け付け、
前記連携部は、前記認証部による認証が成功したユーザのアクセスを許可するように、前記特定の外部装置で予め定められた手続にしたがって前記特定の外部装置に指示することを特徴とする請求項１に記載のシングルサインオンシステム。
【請求項３】
前記プロキシ部は、前記連携部による前記外部装置に対する処理の終了を検出した場合に、前記認証部による認証が成功したユーザの情報を前記ユーザ端末へ送信し、当該情報を用いた認証要求を前記ユーザ端末から前記外部装置へ送信させることを特徴とする請求項１または２に記載のシングルサインオンシステム。
【請求項４】
前記プロキシ部は、前記連携部による前記外部装置に対する処理が異常終了した場合も、前記認証部による認証が成功していれば、前記認証部による認証が成功したユーザの情報を前記ユーザ端末へ送信し、当該情報を用いた認証要求を前記ユーザ端末から前記外部装置へ送信させることを特徴とする請求項１から３のいずれかに記載のシングルサインオンシステム。
【請求項５】
ユーザの認証処理を実行する外部装置に対するユーザ端末からのアクセスを前記外部装置に代わって受け付けるステップと、
前記外部装置とは独立して前記ユーザ端末のユーザを認証するステップと、
前記認証するステップで認証が成功したユーザのアクセスを許可するように、前記外部装置で予め定められた手続にしたがって前記外部装置に指示するステップと、
前記認証するステップで認証が成功したユーザの情報を前記ユーザ端末へ送信し、当該情報を用いた認証要求を前記ユーザ端末から前記外部装置へ送信させるステップと、
をコンピュータが実行することを特徴とするシングルサインオン方法。
【請求項６】
ユーザの認証処理を実行する外部装置に対するユーザ端末からのアクセスを前記外部装置に代わって受け付けるプロキシ機能と、
前記外部装置とは独立して前記ユーザ端末のユーザを認証する認証機能と、
前記認証機能による認証が成功したユーザのアクセスを許可するように、前記外部装置で予め定められた手続にしたがって前記外部装置に指示する連携機能と、
をコンピュータに実現させ、
前記プロキシ機能は、前記認証機能による認証が成功したユーザの情報を前記ユーザ端末へ送信し、当該情報を用いた認証要求を前記ユーザ端末から前記外部装置へ送信させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理技術に関し、特にシングルサインオンの技術に関する。
【背景技術】
【０００２】
複数の業務システムを利用する際に、本来なら業務システム個別に必要となる認証処理を１回のログイン操作だけで可能にする仕組みであるシングルサインオン（以下「ＳＳＯ」とも呼ぶ。）が普及している。ＳＳＯを実現する方式の１つに、代理認証方式がある（例えば特許文献１参照）。
【０００３】
近年、ＳＳＯの方式として、ジャスト・イン・タイム・プロビジョニング（以下「ＪＩＴプロビジョニング」と呼ぶ。）が普及しつつある。ＪＩＴプロビジョニングは、ユーザがＳＳＯを行う際に、ＳＡＭＬ（Security Assertion Markup Language）等によるアサーションを使用して、ＳＳＯ連携先に動的にユーザを作成し、またユーザの属性情報を動的に連携する機能である。ＪＩＴプロビジョニングを採用することで、疎なＳＳＯシステムを構築することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１８６２０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
これまでＪＩＴプロビジョニングを実現するためには、ＳＳＯによるログイン先となるシステム側でＪＩＴプロビジョニングを実装する必要があった。そのため、ＳＳＯによるログイン先システムに手を加えられない場合、ＪＩＴプロビジョニングの採用は困難であった。
【０００６】
本発明は、上記課題を鑑みてなされたものであり、主たる目的は、ＳＳＯによるログイン先となるシステムへの影響を抑制しつつ、ＪＩＴプロビジョニングを実現することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様のシングルサインオンシステムは、ユーザの認証処理を実行する外部装置に対するユーザ端末からのアクセスを外部装置に代わって取得するプロキシ部と、外部装置とは独立してユーザ端末のユーザを認証する認証部と、認証部による認証が成功したユーザのアクセスを許可するように、外部装置で予め定められた手続にしたがって外部装置に指示する連携部とを備える。プロキシ部は、認証部による認証が成功したユーザの情報をユーザ端末へ送信し、当該情報を用いた認証要求をユーザ端末から外部装置へ送信させる。
【０００８】
本発明の別の態様は、シングルサインオン方法である。この方法は、ユーザの認証処理を実行する外部装置に対するユーザ端末からのアクセスを外部装置に代わって取得するステップと、外部装置とは独立してユーザ端末のユーザを認証するステップと、認証するステップで認証が成功したユーザのアクセスを許可するように、外部装置で予め定められた手続にしたがって外部装置に指示するステップと、認証するステップで認証が成功したユーザの情報をユーザ端末へ送信し、当該情報を用いた認証要求をユーザ端末から外部装置へ送信させるステップとをコンピュータが実行する。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、ＳＳＯによるログイン先となるシステムへの影響を抑制しつつ、ＪＩＴプロビジョニングを実現することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態のエンタープライズシステムの構成を示す図である。
【図２】図１のリバースプロキシの構成を示すブロック図である。
【図３】図１の連携装置の構成を示すブロック図である。
【図４】連携先情報保持部に保持される連携先情報を示す図である。
【図５】実施の形態のエンタープライズシステムの動作を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
実施の形態のＳＳＯシステムについて、詳細な構成を説明する前に概要を説明する。
ＳＳＯを実現する１つに代理認証方式があり、上記の特許文献１は代理認証方式を採用している。特許文献１では、リバースプロキシサーバ１がユーザ認証に使用するユーザ情報（データベースサーバ４が保持するユーザ情報）と、ユーザのアクセス先となるウェブサーバ３がユーザ認証に使用するユーザ情報とを常時同期させる必要がある。すなわち特許文献１は密なＳＳＯシステムを実現するものである。しかし現実には、リバースプロキシサーバ１側とウェブサーバ３側双方のユーザ情報を常時同期させることは困難なこともある。
【００１３】
ＳＳＯを実現する別の方式として、サインオン時に、連携先システムに動的にプロビジョニング、すなわちユーザを作成するＪＩＴプロビジョニングがある。ＪＩＴプロビジョニングでは、連携するシステム間でユーザ情報を常時同期させる必要がなく、すなわち疎なＳＳＯシステムを実現できる。しかし、これまでＪＩＴプロビジョニングを実現するためには、連携先システム（連携先アプリケーション）がＪＩＴプロビジョニングに対応する必要があった。例えば、アサーションの解析処理や、解析結果に基づくユーザ作成処理等を連携先システム（連携先アプリケーション）に実装する必要があった。そのため、連携先システムが既存の基幹システム等、改変が困難なものである場合にＪＩＴプロビジョニングの採用は困難であった。
【００１４】
そこで実施の形態では、代理認証のためのリバースプロキシとＩＤ連携機能を活用してＪＩＴプロビジョニングを実現するＳＳＯシステムを提案する。具体的には、代理認証のためのリバースプロキシがユーザのリクエストをフックし、ＩＤ連携機能がＳＡＭＬ等によるアサーションの使用に代えて、ＳＳＯ連携先のユーザ認証用データベースを直接更新し、ログインユーザのＩＤ情報を連携先へ動的に登録する。これにより、ＳＳＯ連携先のシステムやアプリケーションに新たな作り込みを発生させることなく、ＪＩＴプロビジョニングを実現し、すなわち疎なＳＳＯシステムを実現できる。
【００１５】
図１は、実施の形態のエンタープライズシステムの構成を示す。エンタープライズシステム１００は、企業に構築された情報システムであり、図１の各装置はＬＡＮ・ＷＡＮ・インターネットを含む通信網を介して接続される。エンタープライズシステム１００は、社員（以下「ユーザ」とも呼ぶ。）が使用する情報処理装置であるユーザ端末１８を含む。また、ユーザの業務遂行を支援するためのサービスを提供する情報処理装置（以下「業務サーバ」とも呼ぶ。）である人事情報サーバ２０、経理情報サーバ２２、ファイルサーバ２４、クラウドサーバ２６を含む。
【００１６】
複数の業務サーバのそれぞれは、アクセスを許可するユーザが示される情報である許可ユーザ情報を装置内のストレージ、または、予め接続された外部装置に保持する。そして、後述のＳＳＯシステム１０および他の業務サーバとは独立した個別のユーザ認証処理を実行する。各業務サーバは、業務サーバ個別の認証に成功したユーザにのみアクセスを許可し、例えばユーザが要求した業務画面（ウェブページ等）をユーザ端末１８へ提供する。また各業務サーバは、独自のログインフォームを提供する。実施の形態のログインフォームは、ユーザＩＤやパスワードをユーザに入力させ、認証要求を送信させるログイン画面としてのウェブページとする。
【００１７】
人事情報サーバ２０は、ＬＤＡＰサーバであるユーザ情報管理装置３０が保持する許可ユーザ情報を参照してユーザを認証する。経理情報サーバ２２は、ＲＤＢサーバであるユーザ情報管理装置３２が保持する許可ユーザ情報を参照してユーザを認証する。ファイルサーバ２４は、装置内のＣＳＶファイルに記録された許可ユーザ情報を参照してユーザを認証する。クラウドサーバ２６は、クラウド環境に構築された当該企業用の物理的または仮想的な業務サーバである。クラウドサーバ２６は、ユーザ情報管理装置３２とは異なる種類のＲＤＢサーバであるユーザ情報管理装置３６が保持する許可ユーザ情報を参照してユーザを認証する。
【００１８】
エンタープライズシステム１００はさらに、ユーザの作業効率化のために複数の業務サーバへのＳＳＯを実現するＳＳＯシステム１０を含む。ＳＳＯシステム１０は、リバースプロキシ１２、認証サーバ１４、連携装置１６を備える。リバースプロキシ１２は、ユーザ端末１８から各業務サーバへのアクセスを仲介するリバースプロキシサーバである。連携装置１６は、認証サーバ１４による認証に成功したユーザの情報を、ユーザのアクセス先となる業務サーバへ登録する。
【００１９】
認証サーバ１４は、企業におけるユーザ情報のマスタを保持し、各業務サーバとは独立してユーザ端末１８のユーザを認証する。認証サーバ１４は、認証に成功したユーザの情報を予め定められた一定期間保持し、セッション情報等を用いる公知の方法でユーザを認証済か否か、ユーザ認証に成功した状態が有効か否かを判定する。認証サーバ１４は、未認証のユーザまたは認証成功の状態が無効になったユーザの端末へユーザＩＤ、パスワード等の入力フィールドを備えるログインフォームを提供する。
【００２０】
実施の形態では、リバースプロキシ１２、認証サーバ１４、連携装置１６のそれぞれが物理的に異なる情報処理装置で実現されることとするが、ＳＳＯシステム１０の物理構成、例えば装置数等に制限はない。例えば、リバースプロキシ１２、認証サーバ１４、連携装置１６それぞれの機能を１つの装置に集約してもよく、リバースプロキシ１２と連携装置１６の機能を１つの装置で実現して認証サーバ１４と連携する構成としてもよい。
【００２１】
図２は、図１のリバースプロキシ１２の構成を示すブロック図である。リバースプロキシ１２は、制御部４０、記憶部４２、通信部４４を備える。制御部４０は、各種データ処理を実行する。記憶部４２は、制御部４０により参照され、また更新されるデータを記憶する。通信部４４は、種々の通信プロトコルにしたがって外部装置と通信する。制御部４０は、通信部４４を介して外部装置とデータを送受する。制御部、記憶部、通信部の基本的な機能は後述の連携装置１６においても同様である。
【００２２】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００２３】
例えば、制御部４０内の各ブロックに対応するモジュールを含むリバースプロキシプログラムがＤＶＤ等の記録媒体に格納され、リバースプロキシ１２にインストールされてもよい。そして、リバースプロキシ１２のストレージに格納されたリバースプロキシプログラムをリバースプロキシ１２のプロセッサ（ＣＰＵ等）が実行することで、リバースプロキシ１２は制御部４０内の各ブロックの機能を発揮してもよい。記憶部４２は、リバースプロキシ１２のストレージやメモリがデータを記憶することで実現されてよい。
【００２４】
記憶部４２はログインフォーム保持部４６を含む。ログインフォーム保持部４６は、各業務サーバにおいて予め定められたログインフォームのデータを保持する。ログインフォームは、例えばユーザＩＤ入力フィールド、パスワード入力フィールド、ログインボタンを含む。またログインフォーム保持部４６に保持されるログインフォームには、当該フォームをユーザ端末１８で非表示にし、かつ、自動的なサブミットを実行させるためのＪａｖａＳｃｒｉｐｔ（登録商標）コードが付加されている。
【００２５】
制御部４０は、要求フック部４８、認証確認部５０、ユーザ情報転送部５２、更新通知受付部５４、代理認証要求部５６を含む。要求フック部４８は、複数の業務サーバのうち特定の業務サーバに対するユーザ端末１８からのアクセスを業務サーバに代わって受け付ける。例えば要求フック部４８は、ユーザ端末１８からある１つの業務サーバ宛に送信された、業務画面を要求する要求電文をフックする。
【００２６】
認証確認部５０は、認証サーバ１４に対して、ユーザ端末１８のユーザの認証状態を確認する。例えば、要求フック部４８がフックした要求電文のセッション情報を認証サーバ１４に渡し、ユーザの認証に成功したか否か、また、認証成功の状態が有効か否かを問い合わせてもよい。ユーザ端末１８のユーザが未認証であり、または、時間経過等の理由により認証成功の状態が無効である場合、認証サーバ１４は、ユーザ端末１８へログインフォームを送信し、ログインフォームへの入力情報に基づいてユーザを認証する。
【００２７】
ユーザ情報転送部５２は、ユーザの認証に成功した（認証成功の状態が有効である）旨の通知を認証サーバ１４から受信した場合に、認証に成功したユーザの情報（以下「認証済ユーザ情報」とも呼ぶ。）を含むＩＤ連携要求を連携装置１６へ送信する。認証済ユーザ情報は、ユーザ端末１８のユーザの属性情報であり、ユーザのアクセスを許可させるために業務サーバ（ユーザ情報管理装置）へ登録すべき情報を含む。
【００２８】
例えば認証済ユーザ情報は、認証サーバ１４に予め登録されたユーザ端末１８のユーザのユーザＩＤとパスワードを含む。また認証済ユーザ情報は、ユーザの属性情報（ＩＤ、パスワード）の登録先であり、すなわちユーザ端末１８のアクセス先である業務サーバの識別情報を含む。ユーザ情報転送部５２は、認証サーバ１４から提供された、認証に成功したユーザのＩＤとパスワードを認証済ユーザ情報に設定する。また、要求フック部４８がフックした要求電文で指定されたアクセス先の業務サーバの識別情報を登録先として認証済ユーザ情報に設定する。
【００２９】
更新通知受付部５４は、連携装置１６から送信された、業務サーバに対するＩＤ連携処理が終了した旨の情報を受け付ける。代理認証要求部５６は、連携装置１６によるＩＤ連携処理の終了を検出したことを契機に、認証サーバ１４による認証が成功したユーザの情報、実施の形態ではユーザＩＤとパスワードをユーザ端末１８へ送信する。
【００３０】
具体的には代理認証要求部５６は、認証サーバ１４からユーザの認証に成功した旨が通知され、かつ、更新通知受付部５４が連携装置１６からＩＤ連携処理の終了通知を受け付けた場合に、認証済ユーザ情報としてのＩＤとパスワードをユーザ端末１８へ提供する。また代理認証要求部５６は、連携装置１６からＩＤ連携処理が異常終了した旨の通知を受け付けた場合も、認証サーバ１４によるユーザ認証が成功していれば、ＩＤ連携処理が正常終了した場合と同様に、認証済ユーザ情報としてのＩＤとパスワードをユーザ端末１８へ提供する。
【００３１】
代理認証要求部５６は、ログイン指示部とも言え、認証サーバ１４による認証が成功したユーザの情報をユーザ端末１８へ送信することにより、その情報を用いた認証要求をユーザ端末１８からアクセス先の業務サーバへ送信させる。具体的には、代理認証要求部５６は、要求フック部４８がフックした要求電文で指定されたアクセス先の業務サーバを識別し、その業務サーバに対応付けられたログインフォームをログインフォーム保持部４６から取得する。代理認証要求部５６は、取得したログインフォームに、認証サーバ１４による認証が成功したユーザのＩＤとパスワード、すなわち連携装置１６により業務サーバに登録されたＩＤとパスワードを設定し、設定後のログインフォームをユーザ端末１８へ送信する。
【００３２】
既述したように、ログインフォームには非表示属性と、自動サブミットが予め設定される。そのためユーザ端末１８（例えばユーザ端末１８のウェブブラウザ）は、ログインフォームのデータを非表示のままアクセス先の業務サーバへ自動で送信する。ユーザ端末１８は、ログインフォームのデータとともに、業務画面を指定するＵＲＬ等のデータを業務サーバへ自動で送信してもよい。業務サーバは、ログインフォームに設定されたＩＤとパスワードに基づいてユーザの認証に成功すると、所定のレスポンスをユーザ端末１８へ送信する。例えば、ユーザ端末１８により指定された業務画面のウェブページをユーザ端末１８へ送信し、表示させる。
【００３３】
変形例として、代理認証要求部５６は、一旦アクセス先の業務サーバへアクセスし、ログインフォームのデータを動的に取得してもよい。代理認証要求部５６は、業務サーバから取得したログインフォームのデータに対して、非表示と自動サブミットを実行するＪａｖａＳｃｒｉｐｔコードを追加する改変と、ユーザＩＤとパスワードを設定する改変を施した上で、改変後のログインフォームをユーザ端末１８へ提供してもよい。
【００３４】
図３は、図１の連携装置１６の構成を示すブロック図である。連携装置１６は、制御部６０、記憶部６２、通信部６４を備える。制御部６０内の各ブロックに対応するモジュールを含むＩＤ連携プログラムがＤＶＤ等の記録媒体に格納され、連携装置１６にインストールされてもよい。そして、連携装置１６のストレージに格納されたＩＤ連携プログラムを連携装置１６のプロセッサ（ＣＰＵ等）が実行することで、連携装置１６は制御部６０内の各ブロックの機能を発揮してもよい。記憶部６２は、連携装置１６のストレージやメモリがデータを記憶することで実現されてよい。
【００３５】
記憶部６２は連携先情報保持部６６を含む。連携先情報保持部６６は、ＳＳＯの対象になる複数の業務サーバのそれぞれで予め定められた手続であり、ユーザのアクセスを許可するよう業務サーバに指示するための手続に関する情報（以下「連携先情報」とも呼ぶ。）を保持する。この手続は、業務サーバに接続し、業務サーバ側で保持される許可ユーザ情報を更新するための規則、手順と言え、連携先情報は、コネクション情報、コマンド情報とも言える。
【００３６】
図４は、連携先情報保持部６６に保持される連携先情報を示す。連携先情報は、図１の各業務サーバ（ユーザ情報管理装置）に保持される許可ユーザ情報に、認証に成功したユーザの情報を登録する際に使用すべきＩＰアドレス、ポート番号、通信プロトコルを含む。なお図１の構成では、アクセス先装置名「人事情報サーバ」「経理情報サーバ」に対応する連携先情報はそれぞれ、ユーザ情報管理装置３０、ユーザ情報管理装置３２に関する情報になる。
【００３７】
またクラウドサーバ２６の場合、クラウドサーバ２６がユーザ情報管理装置３６のユーザ情報を更新するインタフェース（例えばウェブサービスＡＰＩ）を公開していることとし、連携装置１６はそのウェブサービスを利用することとする。図４に示す連携先情報は一例であり、各業務サーバ（ユーザ情報管理装置）にログインし、データベースやディレクトリを更新するための他の情報を含んでもよい。例えば連携先情報は、ログイン権限や更新権限が付与されたＩＤ・パスワード、また、ログインおよびユーザ情報登録のためのメッセージフォーマット等を含んでもよい。
【００３８】
図３に戻り、制御部６０は、ユーザ情報受付部６８、外部情報更新部７０、更新通知部７２を含む。ユーザ情報受付部６８は、リバースプロキシ１２から送信された認証済ユーザ情報を受け付ける。更新通知部７２は、外部情報更新部７０によるＩＤ連携処理が終了した場合に、ＩＤ連携処理の成功または失敗を示す情報を含む更新完了通知をリバースプロキシ１２へ送信する。
【００３９】
外部情報更新部７０は、ＩＤ連携処理として、認証サーバ１４による認証が成功したユーザのアクセスを許可するように、業務サーバで予め定められた手続にしたがって業務サーバに指示する。具体的には、外部情報更新部７０は、複数の業務サーバのうちユーザのアクセス先となる特定の業務サーバに保持される許可ユーザ情報を、特定の業務サーバが定める手続にしたがって、認証サーバ１４による認証が成功したユーザのアクセスを許可するよう更新する。言い換えれば、許可ユーザ情報を、認証サーバ１４による認証が成功したユーザのアクセスを許可する内容に更新する。
【００４０】
より具体的には、外部情報更新部７０は、連携先情報保持部６６を参照して、認証済ユーザ情報で指定されたアクセス先業務サーバに対応付けられた連携先情報を識別する。外部情報更新部７０は、アクセス先業務サーバに対応付けられた連携先情報にしたがって、認証済ユーザ情報で指定されたユーザＩＤとパスワードをアクセス先業務サーバ（またはユーザ情報管理装置）に登録するための電文を作成する。この電文は、例えばＬＤＡＰサーバにユーザの登録を要求するＬＤＡＰ要求であり、また、ＤＢサーバのテーブルにユーザ情報のレコード追加を要求するＳＱＬクエリである。外部情報更新部７０は、作成した電文をアクセス先業務サーバ（またはユーザ情報管理装置）へ送信することにより、認証サーバ１４による認証が成功したユーザの情報をアクセス先業務サーバ（またはユーザ情報管理装置）に登録する。
【００４１】
以上の構成によるエンタープライズシステム１００の動作を説明する。
図５は、実施の形態のエンタープライズシステム１００の動作を示すシーケンス図である。同図は、ユーザのアクセス先が人事情報サーバ２０のときの動作を示している。例えば、企業の社内ポータルサイトに、人事情報、経理情報、共有ファイルアクセス等のリンクが配置され、ユーザが人事情報のリンクを選択した場合に次の動作が実行される。なお、人事情報のリンクには、人事情報サーバ２０のＵＲＬが設定され、そのリンク選択を契機とする要求をリバースプロキシ１２がフックしてもよい。また、人事情報のリンクにはリバースプロキシ１２のＵＲＬ（パラメータとして人事情報サーバ２０を含む）が設定され、そのリンク選択による要求をリバースプロキシ１２が受信し、パラメータに基づいてアクセス先を人事情報サーバ２０と識別してもよい。
【００４２】
ユーザ端末１８は、人事情報サーバ２０へ業務画面の提供を要求する要求電文を送信する（Ｓ１０）。リバースプロキシ１２の要求フック部４８は、ユーザ端末１８から送信された要求電文をフックし、認証確認部５０は、ユーザ端末１８のユーザの認証状況を認証サーバ１４に問い合わせる（Ｓ１２）。認証サーバ１４は、ユーザを未認証であれば、ログインフォームをユーザ端末１８へ提供する。この場合、ユーザは、そのログインフォームへユーザＩＤとパスワードを入力してログインボタンを押下する。認証サーバ１４は、ユーザ端末１８から送信されたユーザＩＤとパスワードを取得し、不図示のＤＢに保持されたユーザＩＤとパスワードに照合してユーザを認証する。
【００４３】
認証サーバ１４は、ユーザの認証に成功した場合、認証成功を示す情報とともにユーザ端末１８のユーザのＩＤとパスワードをリバースプロキシ１２へ提供する（Ｓ１４）。なお、リバースプロキシ１２からＳ１２の問い合わせを受け付けた際にユーザを認証済であれば、再度のユーザ認証をスキップしてＳ１４を実行してもよい。認証サーバ１４は、ユーザ認証に失敗した場合（ＩＤやパスワードが不正であった場合等）は、その旨をリバースプロキシ１２へ通知する。この場合、リバースプロキシ１２は、Ｓ１６以降の処理をスキップして、ユーザ端末１８へログイン失敗を通知する。
【００４４】
認証サーバ１４から認証成功が通知されると、リバースプロキシ１２のユーザ情報転送部５２は、認証サーバ１４による認証に成功したユーザのＩＤ、パスワードと、アクセス先の業務サーバ情報を含むＩＤ連携要求を連携装置１６へ送信する（Ｓ１６）。連携装置１６のユーザ情報受付部６８は、ＩＤ連携要求を受け付け、外部情報更新部７０は、ＩＤ連携要求が示すユーザＩＤとパスワードを、人事情報サーバ２０に対応するユーザ情報管理装置３０へ登録する（Ｓ１８）。具体的には、ユーザＩＤとパスワードを指定したユーザ登録要求を示すＬＡＤＰ電文をユーザ情報管理装置３０へ送信し、ユーザ情報管理装置３０にユーザ情報を追加させる。
【００４５】
ユーザ情報管理装置３０から更新の成功が通知されると（Ｓ２０）、連携装置１６の更新通知部７２は、ユーザ登録の成功を示す更新完了通知をリバースプロキシ１２へ送信する。更新通知部７２は、ユーザ情報管理装置３０から更新の失敗が通知され、または、通信障害等により更新の失敗を自律的に検出すると、ユーザ登録の失敗を示す更新完了通知をリバースプロキシ１２へ送信する。リバースプロキシ１２の更新通知受付部５４は、連携装置１６から送信された更新完了通知を受け付ける。
【００４６】
リバースプロキシ１２の代理認証要求部５６は、更新完了通知の受け付けを契機に、認証サーバ１４による認証に成功したユーザのＩＤ、パスワードを設定した人事情報サーバ２０のログインフォームをユーザ端末１８へ送信する（Ｓ２４）。リバースプロキシ１２は、Ｓ１０に伴う要求電文のフックから、Ｓ２４におけるログインフォーム提供までの処理を一連の同期処理として実行する。言い換えれば、リバースプロキシ１２は、Ｓ２２の更新完了通知を受け付けたことを条件として、Ｓ１０に対する返信としてＳ２４を実行する。これにより、ユーザ情報がアクセス先の業務サーバ（図５ではユーザ情報管理装置３０）に登録される前に、ユーザ端末１８が業務サーバへ認証要求を送信し、人事情報サーバ２０による認証が失敗してしまうことを確実に回避できる。
【００４７】
またＳ２４において、代理認証要求部５６は、認証サーバ１４による認証が成功していれば、連携装置１６によるユーザ登録が失敗しても、認証サーバ１４による認証に成功したユーザのＩＤ、パスワードを設定したログインフォームをユーザ端末１８へ送信する。現実には、認証サーバ１４が保持するユーザ情報（ＩＤ、パスワード）を、ＳＳＯによるアクセス先装置（図５ではユーザ情報管理装置３０）が既に保持していることもある。このような場合、連携装置１６によるユーザ情報登録が失敗しても、認証サーバ１４が保持するユーザ情報を使用すれば人事情報サーバ２０の認証に成功する。実施の形態の態様によると、連携装置１６によるユーザ情報登録が失敗した場合も、業務サーバへのログインを試行させ、ログインの可能性を残すことで、ユーザの利便性の低下を抑制する。
【００４８】
ユーザ端末１８は、リバースプロキシ１２から受信したログインフォームを自動でサブミットし、そのログインフォームに予め設定されたユーザＩＤとパスワードを含む認証要求を人事情報サーバ２０へ自動的に送信する（Ｓ２６）。ここでもリバースプロキシ１２は、認証要求の電文を一旦フックしてもよく、認証要求であることを識別すると、その認証要求電文を通過させ、または宛先へ転送してもよい。
【００４９】
人事情報サーバ２０は、ユーザ情報管理装置３０のユーザ情報を参照してユーザを認証する。認証要求で指定されたユーザＩＤとパスワードはＳ１８で登録済であるため認証は成功し、人事情報サーバ２０は、ユーザ端末１８の要求に応じたレスポンスをユーザ端末１８へ送信する（Ｓ２８）。図５に示した一連の動作により、ユーザ端末１８のユーザは、社内ポータルサイトで人事情報のリンクをクリックし、認証サーバ１４へのログインフォームに正規のユーザＩＤとパスワードを入力すれば、人事情報サーバ２０から所望のレスポンスを得ることができる。
【００５０】
実施の形態のＳＳＯシステム１０によると、ＳＳＯによるアクセス先の装置側で保持される許可ユーザ情報を、アクセス先の装置側の既存インタフェースに則して直接更新する。これにより、ＳＳＯによるアクセス先の装置がＪＩＴプロビジョニングを未実装であっても、ＪＩＴプロビジョニングによるＳＳＯを実現し、疎なＳＳＯを実現できる。すなわち、ＳＳＯによるアクセス先となる装置への影響を抑制しつつ、ＪＩＴプロビジョニングのメリットを享受できる。
【００５１】
なお、ユーザのアクセス先が経理情報サーバ２２、ファイルサーバ２４、クラウドサーバ２６の場合、Ｓ１８における通信プロトコルやメッセージフォーマットが異なり、例えばＤＢ更新要求、ファイル更新要求、ＨＴＴＰリクエストとなる。その一方、他のステップは図５と同様の処理になる。実施の形態のＳＳＯシステム１０によると、連携装置１６が、複数の業務サーバ（ユーザ情報管理装置）それぞれのインタフェースに対応することで、業務サーバ（ユーザ情報管理装置）への新たな作り込みを抑制できる。また、ＳＳＯの対象となる複数の業務サーバ間のインタフェースの差異を連携装置１６が吸収するため、基幹システムを含む多数の装置をＳＳＯの対象に組み込むことが容易になる。
【００５２】
また実施の形態のＳＳＯシステム１０によると、ＳＳＯのログイン先に、別のＳＳＯシステムを組み込むことができる。言い換えれば、実施の形態の業務サーバの位置づけで、別のＳＳＯシステムを組み込むことができる。この場合、連携装置１６は、別のＳＳＯシステムが備える認証サーバ（ここでは「外部認証サーバ」と呼ぶ。）に対して、認証サーバ１４による認証が成功したユーザのアクセスを許可するように、外部認証サーバが予め定める手続にしたがって指示する。例えば連携装置１６は、外部認証サーバの既存インタフェースを使用して、外部認証サーバが保持する許可ユーザ情報に、認証サーバ１４による認証が成功したユーザの情報を登録する。ＳＳＯシステムは通常、ＪＩＴプロビジョニングの受け付けを想定して実装されないが、実施の形態のＳＳＯシステム１０は、既存のＳＳＯシステムへの影響を抑制しつつ、既存のＳＳＯシステムをＳＳＯによるログイン先に組み込むことができる。
【００５３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００５４】
実施の形態では言及していないが、ＳＳＯシステム１０の連携装置１６は、ＳＳＯのログイン先となる複数の装置（業務サーバ等）のうち従来のＪＩＴプロビジョニングに対応する特定の装置に対しては、従来通りＳＡＭＬ等のアサーションを送信することによりユーザ情報を動的に登録してもよいことはもちろんである。
【００５５】
また、ＳＳＯシステム１０の連携装置１６が、ＳＳＯのログイン先となる装置（業務サーバやユーザ情報管理装置）へ登録するユーザ情報は、ユーザＩＤやパスワードに限られない。例えば、認証サーバ１４に予め保持されるユーザに関する様々な属性情報、アクセス権限情報等を登録してもよい。
【００５６】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【符号の説明】
【００５７】
１０  ＳＳＯシステム、  １２  リバースプロキシ、  １４  認証サーバ、  １６  連携装置、  １８  ユーザ端末、  ４８  要求フック部、  ５０  認証確認部、  ５６  代理認証要求部、  ７０  外部情報更新部、  ７２  更新通知部、  １００  エンタープライズシステム。
【図１】
2016218825.tif 000003
【図２】
2016218825.tif 000004
【図３】
2016218825.tif 000005
【図４】
2016218825.tif 000006
【図５】
2016218825.tif 000007