組織の内部の第1のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第1のサーバと、前記組織内のユーザのアカウント情報を管理する第2のサーバと、前記第1のネットワークおよび前記組織の外部の第2のネットワークに接続可能なクライアント端末、および前記第2のネットワークに接続されたアプリケーションサーバとからなり、前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、前記第1のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第2のサーバによってユーザ認証を行う第1の認証部と、前記第1の認証部が前記第2のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第1の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有し、前記クライアント端末は、前記第1のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第2の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第2の認証部を介してユーザ認証を行う連携認証部とを有することを特徴とするアカウント情報連携システム。請求項1に記載のアカウント情報連携システムにおいて、前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに登録されていない場合は、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバに対してアカウント情報の新規登録を行うことを特徴とするアカウント情報連携システム。請求項1または2に記載のアカウント情報連携システムにおいて、前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに既に登録されている場合は、前記アプリケーションサーバでのアカウント情報の登録内容に対して、前記組織内でのアカウント情報の内容に変更がある場合に、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバでのアカウント情報の登録内容を更新することを特徴とするアカウント情報連携システム。請求項1~3のいずれか1項に記載のアカウント情報連携システムにおいて、前記第1のサーバの前記認証チケット発行部は、前記認証チケットを暗号化して発行し、前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットを復号化して前記ユーザの前記組織内でのアカウント情報を取得することを特徴とするアカウント情報連携システム。請求項1~4のいずれか1項に記載のアカウント情報連携システムにおいて、前記第1のサーバでは他のサービスを提供しており、前記第1の認証部は、前記ユーザが前記他のサービスを利用する際のユーザ認証を行うためのインタフェースを提供し、前記認証チケット発行部は、前記ユーザが前記他のサービスの利用中に前記アプリケーションサーバによって提供される前記外部サービスを新たに利用する際に、前記他のサービスを利用する際のユーザ認証において使用されたアカウント情報を用いて認証チケットを発行することを特徴とするアカウント情報連携システム。特許文献1のような仕組みを用いれば、例えば、社内システムと外部のASPサービスとの間のような信頼関係が成立していないシステム間で、シングルサインオンの環境を構築することが可能である。しかしながら、ユーザ社員等は、社内システムでのユーザ管理とは別に、外部のサービスにおいても個別にアカウント情報の登録や変更等の管理を行わなければならないのが通常である。また、例えば特許文献1での中継サーバなどのように、社内で通常使用するユーザIDと外部のサービスにおけるユーザIDとの対応情報の管理も行う必要がある。また従来技術では、例えば社内システムでユーザ認証を経た上でいずれかのアプリケーションを実行した後、その認証情報を引き継いで外部のサービスを利用するという、一般的なシングルサインオンの形態ではなく、ユーザが社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用して、外部のサービスに対してユーザ認証を行った上で利用するという形態アカウント情報の共用のシステムを構築することは考慮されていない。そこで本発明の目的は、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供することにある。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することができるアカウント情報連携システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。本発明の代表的な実施の形態によるアカウント情報連携システムは、組織の内部の第1のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第1のサーバと、前記組織内のユーザのアカウント情報を管理する第2のサーバと、前記第1のネットワークおよび前記組織の外部の第2のネットワークに接続可能なクライアント端末、および前記第2のネットワークに接続されたアプリケーションサーバとからなり、前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、以下の特徴を有するものである。すなわち、前記第1のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第2のサーバによってユーザ認証を行う第1の認証部と、前記第1の認証部が前記第2のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第1の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有する。また、前記クライアント端末は、前記第1のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第2の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第2の認証部を介してユーザ認証を行う連携認証部とを有する。本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。本発明の代表的な実施の形態によれば、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することが可能となる。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することが可能となる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。本発明の一実施の形態であるアカウント情報連携システムは、企業の社員等のユーザが、社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用ここでの使用とは画面を通して入力することを指すして、社内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対して、ユーザ認証を行った上で利用することを可能とするシステムである。さらに、当該外部のサービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザが個別にアカウント情報の登録や変更、削除等の管理作業を行うことを不要とする。<システム構成>図1は、本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。アカウント情報連携システム1は、例えば、企業内においてLANLocalAreaNetwork等からなる社内ネットワーク11によってイントラネット10が構成され、これに社内Webサーバ14、ディレクトリサーバ17、および社員等であるユーザ12の有するクライアント端末上で稼働するWebブラウザ13がそれぞれ接続する構成を有する。ユーザ12は、Webブラウザ13を利用して社内Webサーバ14にアクセス可能であるとともに、さらに、インターネット20を介して外部アプリケーションサーバ30にアクセスして外部サービスの提供を受けることが可能である。ここでの外部サービスとしては、ユーザ登録を行った上で、ユーザ認証を経て利用可能となるものが該当し、例えば、Webベースでのメールやストレージなどを始めとするクラウドコンピューティングサービスや、ファイル転送サービス、会員制の各種ポータルサイト、情報提供サイトなどが挙げられる。なお、セキュリティ上、社内Webサーバ14およびディレクトリサーバ17と、外部アプリケーションサーバ30との間での直接の通信は許可されないものとする。社内Webサーバ14は、例えば、図示しないWebサーバプログラム上で稼働するソフトウェアプログラムとして実装される認証部15および認証チケット発行部16を有し、ユーザ12に対してユーザ認証のためのインタフェースを提供する情報処理装置である。認証部15は、Webブラウザ13を介して、ユーザ12に対して、外部アプリケーションサーバ30によって提供される外部サービスを利用する際のユーザ認証のためのインタフェース例えばユーザID/パスワードの入力画面を外部アプリケーションサーバ30に代わって提供する。また、入力されたユーザID/パスワード等のアカウント情報を利用してディレクトリサーバ17に問合せてユーザ認証を行う。認証チケット発行部16は、認証部15がユーザ認証の際にディレクトリサーバ17から取得したアカウント情報に基づいて後述する認証チケットを発行する。発行した認証チケットは、認証部15によってWebブラウザ13に対して応答される。ディレクトリサーバ17は、ユーザ12が社内において通常使用するユーザIDやパスワード、属性情報等からなるアカウント情報を一元的に管理するディレクトリサービスの機能を提供する情報処理装置である。本実施の形態では、当該ディレクトリサーバ17においてLDAPを用いて社内のアカウント情報の管理を行うものとしているが、LDAP以外の手法によるものや、ディレクトリサービス以外の仕組みによってアカウント情報を管理するものであってもよい。また、社内で通常使用されるアカウント情報を一元的に管理していることから、他の社内システムやサービスに対して同様にユーザ認証の機能を提供するものであってもよい。外部アプリケーションサーバ30は、インターネット20等を介してASP等により外部のサービスを提供する情報処理装置であり、例えば、図示しないWebサーバプログラム上で稼働するソフトウェアプログラムとして実装される連携認証部31および認証部32と、外部サービスに係る処理を実行する業務アプリケーション図示しないを有する。認証部32は、外部アプリケーションサーバ30が通常のユーザに対して提供する一般的なユーザ認証の機能を実装するものであり、例えば、ユーザID/パスワードの入力を受け付けて認証を行う認証機能や、アカウント情報の登録や変更削除などの管理機能などのインタフェースを有する。連携認証部31は、イントラネット10内のWebブラウザ13から認証チケットの送付を受け、認証チケットからアカウント情報を取得して、これに基づいて認証部32を介してユーザ認証を行う。このとき、認証チケットから取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ30に登録されていない場合は、認証部32を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、必要に応じて認証チケットから取得したアカウント情報に基づいて登録内容を更新する。なお、本実施の形態では、アカウント情報連携システム1をWebベースのシステム構成により実装する場合を例としているが、これに限らず、例えばクライアント/サーバ型のシステム構成とすることも当然可能である。<処理の流れ概要>図2は、本実施の形態のアカウント情報連携システムにおける全体的な処理の流れの例について概要を示した図である。まず、社内のユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスを利用するため、Webブラウザ13を利用して社内Webサーバ14の認証部15にアクセスして、アカウント情報の入力画面を介してユーザID/パスワードを入力する1。認証部15へのアクセスは、例えば、社内Webサーバ14によって提供されるイントラネット10のポータルサイトからのリンクや、Webブラウザ13のブックマーク等を利用して行うことができる。なお、ここで入力するユーザID/パスワードは、ユーザ12がイントラネット10内の社内システムを利用する際に通常使用するものと同じものである。社内Webサーバ14の認証部15は、入力されたアカウント情報に基づいてディレクトリサーバ17に問合せてユーザ認証を行い2、認証が成功した場合にはユーザ12についてのユーザIDや属性情報などを含むアカウント情報をディレクトリサーバ17から取得する3。その後、認証部15は、取得したアカウント情報を認証チケット発行部16に渡す。認証チケット発行部16は、渡されたアカウント情報について所定の妥当性チェックを行った後、アカウント情報を暗号化することによって認証チケットを生成して認証部15に発行する4。認証部15は、発行された認証チケット18の情報を含むリダイレクト画面をいったんWebブラウザ13に送信する5。Webブラウザ13では、例えばリダイレクト画面を介して外部アプリケーションサーバ30に対して自動的にアクセスをリダイレクトすることで、認証チケット18を外部アプリケーションサーバ30に転送する6。当該処理には公知技術を利用することができ、例えば、JavaScript登録商標等を利用した自動Submitによって認証チケット18の情報を外部アプリケーションサーバ30の連携認証部31に対してPOST送信することができる。外部アプリケーションサーバ30の連携認証部31は、転送されたリクエストの内容から認証チケット18の情報を取得し、取得した認証チケット18を復号化してアカウント情報を復元する。さらに、アカウント情報の内容について所定の妥当性チェックを行い、問題がない場合はこのアカウント情報を用いて連携認証処理を行う。すなわち、認証部32を介して外部アプリケーションサーバ30においてユーザ認証処理を行う7。なお、ここでは通常のユーザ認証処理と同様の判定処理を行ってもよいし、アカウント情報の内容が妥当であればその内容を引き継いでそのまま認証を成功させるようにしてもよい。また、上述したように、このとき認証チケット18から取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ30に登録されていない場合は、認証部32を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、認証チケット18から取得したアカウント情報に基づいて登録内容を更新する。連携認証が成功した場合は、外部アプリケーションサーバ30は、サービスを提供するための画面をWebブラウザ13に対して応答する8。以上の一連の処理により、ユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスに対して、社内で通常使用するユーザID/パスワード等のアカウント情報を使用して認証処理を行い、シームレスにアクセスすることが可能となる。<処理の流れ初期登録>以下では、社内Webサーバ14と外部アプリケーションサーバ30との間で認証チケット18の授受を行い、アカウント情報を連携して認証を行う際の処理の詳細について説明する。図3は、アカウント情報連携システム1の環境構築時に暗号鍵を初期登録しておく処理の流れの例について示した図である。本実施の形態では、社内Webサーバ14と外部アプリケーションサーバ30との間での認証チケット18の授受に際して、公開鍵暗号化方式と共通鍵暗号化方式を用いたハイブリッド暗号化方式による暗号化を行う。これにより、外部アプリケーションサーバ30に対するアクセスが、アカウント情報を連携して認証処理を行うことができる企業等からのものであることを証明するとともに、認証チケット18の情報が外部に漏洩した場合でも、社内のディレクトリサーバ17に登録されている元のアカウント情報が復元されないようにする。このため、まず事前の初期登録として、社内Webサーバ14および外部アプリケーションサーバ30において、秘密鍵と公開鍵からなる鍵ペア秘密鍵41と公開鍵42、および秘密鍵51と公開鍵52をそれぞれ生成するS01、S02。鍵ペアの生成については、PKIPublicKeyInfrastructure:公開鍵基盤を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。生成した鍵ペアのうち、それぞれの公開鍵42および公開鍵52を相互に交換するS03。鍵交換の手段については特に限定されず、例えば、インターネット20を介して電子メール等により交換してもよいし、電子証明書の形で発行してもよい。記録媒体に格納してインターネット20を介さずに手動で交換することも可能である。交換した公開鍵52、42は、社内Webサーバ14および外部アプリケーションサーバ30においてそれぞれ保管しておくS04、S05。<処理の流れ認証チケット生成>図4は、ユーザ12が外部サービスの利用にあたって社内Webサーバ14にユーザ認証の要求を行った際に、認証チケット発行部16においてアカウント情報に基づいて認証チケット18を生成する処理の流れの例について示した図である。まず、ディレクトリサーバ17から取得したアカウント情報を暗号化するための共通鍵セッション鍵43を生成するS11。共通鍵43の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。所定のデータ長の乱数を生成して共通鍵43としてもよい。さらにこの共通鍵43によって、アカウント情報44を暗号化して暗号化アカウント情報44’を得るS12。ここでは、例えばAESAdvancedEncryptionStandardなどの公知の暗号化技術を利用することができる。AESによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。一方、アカウント情報44の暗号化に用いた共通鍵43は、外部アプリケーションサーバ30から鍵交換によって取得している公開鍵52によって暗号化し、暗号化共通鍵43’としておくS13。また、アカウント情報44については、別途ハッシュ化してアカウント情報ハッシュ値45を取得しS14、これを社内Webサーバ14が生成して保管している秘密鍵41によって暗号化して、暗号化アカウント情報ハッシュ値45’を得るS15。ここでは、例えばRSARivestShamirAdlemanなどの公知の暗号化技術を利用することができる。RSAによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。上記の処理によって得られた、暗号化共通鍵43’、暗号化アカウント情報44’、および暗号化アカウント情報ハッシュ値45’をまとめて認証チケット18として取り扱う。ここで、暗号化アカウント情報ハッシュ値45’は、アカウント情報44がWebブラウザ13等を介して改竄されていないことを証明する電子署名としての役割を有する。<処理の流れアカウント情報復元>図5は、Webブラウザ13を介して社内Webサーバ14から認証チケット18の送付を受けた外部アプリケーションサーバ30の連携認証部31において、認証チケット18からアカウント情報を復元する処理の流れの例について示した図である。まず、Webブラウザ13からのリクエストの内容から認証チケット18、すなわち暗号化共通鍵43’、暗号化アカウント情報44’、および暗号化アカウント情報ハッシュ値45’を取得する。このうちの暗号化共通鍵43’について、外部アプリケーションサーバ30が生成して保管している秘密鍵51によって復号化して、共通鍵43を得るS21。この共通鍵43によって、認証チケット18の暗号化アカウント情報44’を復号化して、アカウント情報44を得るS22。さらに、このアカウント情報44についてハッシュ化して復元アカウント情報ハッシュ値46を取得するS23。一方、認証チケット18の暗号化アカウント情報ハッシュ値45’について、社内Webサーバ14から鍵交換によって取得している公開鍵41によって復号化して、アカウント情報ハッシュ値45を取得するS24。このアカウント情報ハッシュ値45と、ステップS23で得られた復元アカウント情報ハッシュ値46とを比較して一致するか否かを判定するS25。一致していれば、ステップS22で取得したアカウント情報44はWebブラウザ13等を介して改竄されていないことが証明されるため、このアカウント情報44を用いて後続する連携認証処理を行うことができる。一致しない場合には、Webブラウザ13にエラーを応答して処理を終了する。なお、上述した認証チケット18の授受に際しての一連の暗号化方式は一例であって、他の暗号化方式を採用することも当然可能である。<処理の流れ連携認証>図6は、外部アプリケーションサーバ30の連携認証部31および認証部32において、認証チケット18から取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。まず、連携認証部31は、認証チケット18から取得したアカウント情報44の内容について所定の妥当性チェックを行うS31。ここでは、例えば、ユーザIDの一意性チェック他のグループ等に同一のユーザIDが存在しないかや、接続元のWebブラウザ13のIPアドレスの範囲チェック、認証チケット18の発行日時例えばアカウント情報44に予め設定しておくと現在日時との乖離チェックなどのチェックが行われる。チェックの結果不当な内容がある場合には、Webブラウザ13にエラーを応答して処理を終了する。次に、連携認証部31は、取得したアカウント情報44の内容が、外部アプリケーションサーバ30によって提供される外部サービスに対して既に登録済みかを判定するS32。登録されていない場合は、認証部32を介して当該アカウント情報を新規登録するS33。一方、既に登録済みの場合は、登録されている内容に対して取得したアカウント情報44の内容に変更があるかを判定しS34、変更がある場合は、取得したアカウント情報44の内容に基づいて登録内容を更新するS35。その後、連携認証部31は、認証チケット18から取得したアカウント情報44の内容に基づいて、認証部32を介して外部サービスに対するユーザ認証ログイン処理を行いS36、連携認証処理を終了する。これにより、ユーザ12は、外部アプリケーションサーバ30によって提供される外部サービスに対して直接アクセスしてユーザ認証を行った場合と同様に、Webブラウザ13を介して当該外部サービスを利用することができる。以上に説明したように、本発明の一実施の形態であるアカウント情報連携システム1によれば、企業の社員等のユーザ12が、社内で通常使用するユーザID、パスワード等のアカウント情報をそのまま使用して、社内Webサーバ14等からの直接の通信がセキュリティ上制限されている外部アプリケーションサーバ30によって提供される外部サービスに対して、ユーザ認証を行った上で利用することが可能となる。また、当該外部サービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザ12が個別にアカウント情報の登録や変更、削除等の管理作業を行うことが不要となる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、本実施の形態では、外部アプリケーションサーバ30によって提供される外部サービスについての専用のユーザ認証画面を提供するものとして、社内Webサーバ14および認証部15を構成しているが、他の社内システムによって提供されるサービスについて既に行われているユーザ認証の情報を引き継ぐものとして、シングルサインオンにより当該外部サービスを利用できるようにしてもよい。すなわち、例えば社内Webサーバ14では他の社内システムが稼動してサービスを提供しており、ユーザ12が当該社内システムの使用に際して、社内Webサーバ14上で認証部15を介してディレクトリサーバ17によるユーザ認証を行った場合は、その後、当該社内システムからユーザ12がURLのリンク等を介して外部アプリケーションサーバ30によって提供される外部サービスを新たに使用する際に、社内Webサーバ14でのユーザ認証の際に使用されたアカウント情報例えばCookie等に保存を用いることで、認証チケット発行部16は、ディレクトリサーバ17からアカウント情報を再度取得することなく認証チケット18を発行する。この認証チケット18を上述した手順と同様の手順でWebブラウザ13を介して外部アプリケーションサーバ30に受け渡し、外部アプリケーションサーバ30において連携認証を行うことで、ユーザ12によるユーザID/パスワードの再度の入力およびディレクトリサーバ17での再度のユーザ認証処理を要さずに外部サービスを利用可能とすることができる。