アカウント情報連携システム
【課題】組織内で通常使用するアカウント情報をそのまま使用して外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供する。
【解決手段】社内Ｗｅｂサーバ１４と、ディレクトリサーバ１７と、Ｗｅｂブラウザ１３、および外部アプリケーションサーバ３０とからなり、社内Ｗｅｂサーバ１４は、外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、ディレクトリサーバ１７によってユーザ認証を行う認証部１５と、ユーザ１２のアカウント情報に基づいて認証チケットを発行し、Ｗｅｂブラウザ１３に応答する認証チケット発行部１６とを有し、Ｗｅｂブラウザ１３は認証チケットを外部アプリケーションサーバ３０に転送し、外部アプリケーションサーバ３０は、認証チケットからユーザ１２のアカウント情報を取得して認証部３２を介してユーザ認証を行う連携認証部３１を有する。
【解決手段】社内Ｗｅｂサーバ１４と、ディレクトリサーバ１７と、Ｗｅｂブラウザ１３、および外部アプリケーションサーバ３０とからなり、社内Ｗｅｂサーバ１４は、外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、ディレクトリサーバ１７によってユーザ認証を行う認証部１５と、ユーザ１２のアカウント情報に基づいて認証チケットを発行し、Ｗｅｂブラウザ１３に応答する認証チケット発行部１６とを有し、Ｗｅｂブラウザ１３は認証チケットを外部アプリケーションサーバ３０に転送し、外部アプリケーションサーバ３０は、認証チケットからユーザ１２のアカウント情報を取得して認証部３２を介してユーザ認証を行う連携認証部３１を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザのアカウント情報を他サービスに連携させる技術に関し、特に、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年、企業で利用される社内システム等においては、ユーザ（社員等）のＩＤやパスワード等、および氏名や所属部署その他の属性情報などを含むアカウント情報を一元的に管理するとともに、ＩＤとパスワードによるユーザ認証の手段を提供し、これを複数の社内システムから共通で利用可能とするような仕組みが実装される場合が増えている。このようなユーザ管理の仕組みの実装に際しては、例えば、ＬＤＡＰ（Lightweight Directory Access Protocol）を実装したソフトウェアを用いたディレクトリサーバなどが利用される。
【０００３】
また、ユーザが一回のユーザ認証処理を行うことで、ユーザ認証が必要な複数の社内システムを利用できるようにするシングルサインオンの仕組みが実装される場合もある。例えば、各社内システムのサーバにおいてＳＡＭＬ（Security Assertion Markup Language）プロトコルを用いてサーバ間で通信を行って認証情報を自動的に引き継ぐことで、複数の社内システム間でシングルサインオンを実現することができる。
【０００４】
しかしながら、イントラネット内での社内システムの利用のみで業務を完結できない場合もあり、例えば、外部のベンダー等によってＡＳＰ（Application Service Provider）として提供されるサービスをインターネットを介して業務上利用することになる場合も多い。このとき通常は、当該外部のサービスに対して別途ユーザ登録等を行って、これに対して個別にログイン等の認証処理を行った上でサービスを利用する。
【０００５】
このような環境では、社内システムと外部のシステムとの間でシングルサインオンを実現することは困難である。通常、上述したようなシングルサインオンの仕組みでは、サーバ間で認証情報の引き継ぎが行われるところ、これを可能とするためにはサーバ間で認証情報の引き継ぎ・受け入れを許容する信頼関係の成立が必要とされる。しかし、社内システムと外部のシステムとの間では、セキュリティ上の関係等からこのような信頼関係が成立しない場合も多いからである。
【０００６】
これに対して、例えば、特開２０１０−８６４３５号公報（特許文献１）には、以下のようなネットワークシステムの例が記載されている。すなわち、当該ネットワークシステムは、複数のＷｅｂサーバと中継サーバおよび複数のユーザ端末から構成され、第一のＷｅｂサーバは、端末からの認証情報と記憶部の認証情報とを照合して認証を行い、認証が成立した場合に、認証情報に含まれる第一のユーザＩＤ、第一のＷｅｂサーバへの第一のＵＲＬ、第二Ｗｅｂサーバへの第二のＵＲＬおよび認証強度に関連する情報を含むメッセージを生成して中継サーバに送信する。
【０００７】
中継サーバは、同一ユーザ情報を登録するテーブルから第一のユーザＩＤに対応する第二のユーザＩＤを取得して、メッセージ中の第一のユーザＩＤを第二のユーザＩＤに書き換えて第二のＷｅｂサーバに送信する。第二のＷｅｂサーバは、メッセージを受信すると、メッセージから第二のユーザＩＤを取得し、第二のユーザＩＤが記憶部に記憶されている場合に、受信した認証強度に関連する情報と記憶部の認証強度に関連する情報に基づいてユーザの再認証を行う。これにより、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報の入力により、認証が必要な複数のアプリケーションを利用可能とする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−８６４３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１のような仕組みを用いれば、例えば、社内システムと外部のＡＳＰサービスとの間のような信頼関係が成立していないシステム間で、シングルサインオンの環境を構築することが可能である。
【００１０】
しかしながら、ユーザ（社員等）は、社内システムでのユーザ管理とは別に、外部のサービスにおいても個別にアカウント情報の登録や変更等の管理を行わなければならないのが通常である。また、例えば特許文献１での中継サーバなどのように、社内で通常使用するユーザＩＤと外部のサービスにおけるユーザＩＤとの対応情報の管理も行う必要がある。
【００１１】
また従来技術では、例えば社内システムでユーザ認証を経た上でいずれかのアプリケーションを実行した後、その認証情報を引き継いで外部のサービスを利用するという、一般的なシングルサインオンの形態ではなく、ユーザが社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用して、外部のサービスに対してユーザ認証を行った上で利用するという形態（アカウント情報の共用）のシステムを構築することは考慮されていない。
【００１２】
そこで本発明の目的は、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供することにある。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することができるアカウント情報連携システムを提供することにある。
【００１３】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１４】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１５】
本発明の代表的な実施の形態によるアカウント情報連携システムは、組織の内部の第１のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第１のサーバと、前記組織内のユーザのアカウント情報を管理する第２のサーバと、前記第１のネットワークおよび前記組織の外部の第２のネットワークに接続可能なクライアント端末、および前記第２のネットワークに接続されたアプリケーションサーバとからなり、前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、以下の特徴を有するものである。
【００１６】
すなわち、前記第１のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第２のサーバによってユーザ認証を行う第１の認証部と、前記第１の認証部が前記第２のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第１の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有する。
【００１７】
また、前記クライアント端末は、前記第１のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第２の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第２の認証部を介してユーザ認証を行う連携認証部とを有する。
【発明の効果】
【００１８】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１９】
本発明の代表的な実施の形態によれば、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することが可能となる。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における全体的な処理の流れの例について概要を示した図である。
【図３】本発明の一実施の形態における暗号鍵を初期登録しておく処理の流れの例について示した図である。
【図４】本発明の一実施の形態におけるアカウント情報に基づいて認証チケットを生成する処理の流れの例について示した図である。
【図５】本発明の一実施の形態における認証チケットからアカウント情報を復元する処理の流れの例について示した図である。
【図６】本発明の一実施の形態における認証チケットから取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。
【発明を実施するための形態】
【００２１】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２２】
本発明の一実施の形態であるアカウント情報連携システムは、企業の社員等のユーザが、社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用（ここでの「使用」とは画面を通して「入力」することを指す）して、社内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対して、ユーザ認証を行った上で利用することを可能とするシステムである。さらに、当該外部のサービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザが個別にアカウント情報の登録や変更、削除等の管理作業を行うことを不要とする。
【００２３】
＜システム構成＞
図１は、本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。アカウント情報連携システム１は、例えば、企業内においてＬＡＮ（Local Area Network）等からなる社内ネットワーク１１によってイントラネット１０が構成され、これに社内Ｗｅｂサーバ１４、ディレクトリサーバ１７、および社員等であるユーザ１２の有するクライアント端末上で稼働するＷｅｂブラウザ１３がそれぞれ接続する構成を有する。
【００２４】
ユーザ１２は、Ｗｅｂブラウザ１３を利用して社内Ｗｅｂサーバ１４にアクセス可能であるとともに、さらに、インターネット２０を介して外部アプリケーションサーバ３０にアクセスして外部サービスの提供を受けることが可能である。ここでの外部サービスとしては、ユーザ登録を行った上で、ユーザ認証を経て利用可能となるものが該当し、例えば、Ｗｅｂベースでのメールやストレージなどを始めとするクラウドコンピューティングサービスや、ファイル転送サービス、会員制の各種ポータルサイト、情報提供サイトなどが挙げられる。なお、セキュリティ上、社内Ｗｅｂサーバ１４およびディレクトリサーバ１７と、外部アプリケーションサーバ３０との間での直接の通信は許可されないものとする。
【００２５】
社内Ｗｅｂサーバ１４は、例えば、図示しないＷｅｂサーバプログラム上で稼働するソフトウェアプログラムとして実装される認証部１５および認証チケット発行部１６を有し、ユーザ１２に対してユーザ認証のためのインタフェースを提供する情報処理装置である。認証部１５は、Ｗｅｂブラウザ１３を介して、ユーザ１２に対して、外部アプリケーションサーバ３０によって提供される外部サービスを利用する際のユーザ認証のためのインタフェース（例えばユーザＩＤ／パスワードの入力画面）を外部アプリケーションサーバ３０に代わって提供する。また、入力されたユーザＩＤ／パスワード等のアカウント情報を利用してディレクトリサーバ１７に問合せてユーザ認証を行う。
【００２６】
認証チケット発行部１６は、認証部１５がユーザ認証の際にディレクトリサーバ１７から取得したアカウント情報に基づいて後述する認証チケットを発行する。発行した認証チケットは、認証部１５によってＷｅｂブラウザ１３に対して応答される。
【００２７】
ディレクトリサーバ１７は、ユーザ１２が社内において通常使用するユーザＩＤやパスワード、属性情報等からなるアカウント情報を一元的に管理するディレクトリサービスの機能を提供する情報処理装置である。本実施の形態では、当該ディレクトリサーバ１７においてＬＤＡＰを用いて社内のアカウント情報の管理を行うものとしているが、ＬＤＡＰ以外の手法によるものや、ディレクトリサービス以外の仕組みによってアカウント情報を管理するものであってもよい。また、社内で通常使用されるアカウント情報を一元的に管理していることから、他の社内システムやサービスに対して同様にユーザ認証の機能を提供するものであってもよい。
【００２８】
外部アプリケーションサーバ３０は、インターネット２０等を介してＡＳＰ等により外部のサービスを提供する情報処理装置であり、例えば、図示しないＷｅｂサーバプログラム上で稼働するソフトウェアプログラムとして実装される連携認証部３１および認証部３２と、外部サービスに係る処理を実行する業務アプリケーション（図示しない）を有する。
【００２９】
認証部３２は、外部アプリケーションサーバ３０が通常のユーザに対して提供する一般的なユーザ認証の機能を実装するものであり、例えば、ユーザＩＤ／パスワードの入力を受け付けて認証を行う認証機能や、アカウント情報の登録や変更・削除などの管理機能などのインタフェースを有する。
【００３０】
連携認証部３１は、イントラネット１０内のＷｅｂブラウザ１３から認証チケットの送付を受け、認証チケットからアカウント情報を取得して、これに基づいて認証部３２を介してユーザ認証を行う。このとき、認証チケットから取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ３０に登録されていない場合は、認証部３２を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、必要に応じて認証チケットから取得したアカウント情報に基づいて登録内容を更新する。
【００３１】
なお、本実施の形態では、アカウント情報連携システム１をＷｅｂベースのシステム構成により実装する場合を例としているが、これに限らず、例えばクライアント／サーバ型のシステム構成とすることも当然可能である。
【００３２】
＜処理の流れ（概要）＞
図２は、本実施の形態のアカウント情報連携システムにおける全体的な処理の流れの例について概要を示した図である。まず、社内のユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスを利用するため、Ｗｅｂブラウザ１３を利用して社内Ｗｅｂサーバ１４の認証部１５にアクセスして、アカウント情報の入力画面を介してユーザＩＤ／パスワードを入力する（１）。認証部１５へのアクセスは、例えば、社内Ｗｅｂサーバ１４によって提供されるイントラネット１０のポータルサイトからのリンクや、Ｗｅｂブラウザ１３のブックマーク等を利用して行うことができる。なお、ここで入力するユーザＩＤ／パスワードは、ユーザ１２がイントラネット１０内の社内システムを利用する際に通常使用するものと同じものである。
【００３３】
社内Ｗｅｂサーバ１４の認証部１５は、入力されたアカウント情報に基づいてディレクトリサーバ１７に問合せてユーザ認証を行い（２）、認証が成功した場合にはユーザ１２についてのユーザＩＤや属性情報などを含むアカウント情報をディレクトリサーバ１７から取得する（３）。
【００３４】
その後、認証部１５は、取得したアカウント情報を認証チケット発行部１６に渡す。認証チケット発行部１６は、渡されたアカウント情報について所定の妥当性チェックを行った後、アカウント情報を暗号化することによって認証チケットを生成して認証部１５に発行する（４）。認証部１５は、発行された認証チケット１８の情報を含むリダイレクト画面をいったんＷｅｂブラウザ１３に送信する（５）。
【００３５】
Ｗｅｂブラウザ１３では、例えばリダイレクト画面を介して外部アプリケーションサーバ３０に対して自動的にアクセスをリダイレクトすることで、認証チケット１８を外部アプリケーションサーバ３０に転送する（６）。当該処理には公知技術を利用することができ、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等を利用した自動Ｓｕｂｍｉｔによって認証チケット１８の情報を外部アプリケーションサーバ３０の連携認証部３１に対してＰＯＳＴ送信することができる。
【００３６】
外部アプリケーションサーバ３０の連携認証部３１は、転送されたリクエストの内容から認証チケット１８の情報を取得し、取得した認証チケット１８を復号化してアカウント情報を復元する。さらに、アカウント情報の内容について所定の妥当性チェックを行い、問題がない場合はこのアカウント情報を用いて連携認証処理を行う。すなわち、認証部３２を介して外部アプリケーションサーバ３０においてユーザ認証処理を行う（７）。なお、ここでは通常のユーザ認証処理と同様の判定処理を行ってもよいし、アカウント情報の内容が妥当であればその内容を引き継いでそのまま認証を成功させるようにしてもよい。
【００３７】
また、上述したように、このとき認証チケット１８から取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ３０に登録されていない場合は、認証部３２を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、認証チケット１８から取得したアカウント情報に基づいて登録内容を更新する。
【００３８】
連携認証が成功した場合は、外部アプリケーションサーバ３０は、サービスを提供するための画面をＷｅｂブラウザ１３に対して応答する（８）。以上の一連の処理により、ユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスに対して、社内で通常使用するユーザＩＤ／パスワード等のアカウント情報を使用して認証処理を行い、シームレスにアクセスすることが可能となる。
【００３９】
＜処理の流れ（初期登録）＞
以下では、社内Ｗｅｂサーバ１４と外部アプリケーションサーバ３０との間で認証チケット１８の授受を行い、アカウント情報を連携して認証を行う際の処理の詳細について説明する。図３は、アカウント情報連携システム１の環境構築時に暗号鍵を初期登録しておく処理の流れの例について示した図である。
【００４０】
本実施の形態では、社内Ｗｅｂサーバ１４と外部アプリケーションサーバ３０との間での認証チケット１８の授受に際して、公開鍵暗号化方式と共通鍵暗号化方式を用いたハイブリッド暗号化方式による暗号化を行う。これにより、外部アプリケーションサーバ３０に対するアクセスが、アカウント情報を連携して認証処理を行うことができる企業等からのものであることを証明するとともに、認証チケット１８の情報が外部に漏洩した場合でも、社内のディレクトリサーバ１７に登録されている元のアカウント情報が復元されないようにする。
【００４１】
このため、まず事前の初期登録として、社内Ｗｅｂサーバ１４および外部アプリケーションサーバ３０において、秘密鍵と公開鍵からなる鍵ペア（秘密鍵４１と公開鍵４２、および秘密鍵５１と公開鍵５２）をそれぞれ生成する（Ｓ０１、Ｓ０２）。鍵ペアの生成については、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。
【００４２】
生成した鍵ペアのうち、それぞれの公開鍵４２および公開鍵５２を相互に交換する（Ｓ０３）。鍵交換の手段については特に限定されず、例えば、インターネット２０を介して電子メール等により交換してもよいし、電子証明書の形で発行してもよい。記録媒体に格納してインターネット２０を介さずに手動で交換することも可能である。交換した公開鍵５２、４２は、社内Ｗｅｂサーバ１４および外部アプリケーションサーバ３０においてそれぞれ保管しておく（Ｓ０４、Ｓ０５）。
【００４３】
＜処理の流れ（認証チケット生成）＞
図４は、ユーザ１２が外部サービスの利用にあたって社内Ｗｅｂサーバ１４にユーザ認証の要求を行った際に、認証チケット発行部１６においてアカウント情報に基づいて認証チケット１８を生成する処理の流れの例について示した図である。まず、ディレクトリサーバ１７から取得したアカウント情報を暗号化するための共通鍵（セッション鍵）４３を生成する（Ｓ１１）。共通鍵４３の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。所定のデータ長の乱数を生成して共通鍵４３としてもよい。
【００４４】
さらにこの共通鍵４３によって、アカウント情報４４を暗号化して暗号化アカウント情報４４’を得る（Ｓ１２）。ここでは、例えばＡＥＳ（Advanced Encryption Standard）などの公知の暗号化技術を利用することができる。ＡＥＳによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。一方、アカウント情報４４の暗号化に用いた共通鍵４３は、外部アプリケーションサーバ３０から鍵交換によって取得している公開鍵５２によって暗号化し、暗号化共通鍵４３’としておく（Ｓ１３）。
【００４５】
また、アカウント情報４４については、別途ハッシュ化してアカウント情報ハッシュ値４５を取得し（Ｓ１４）、これを社内Ｗｅｂサーバ１４が生成して保管している秘密鍵４１によって暗号化して、暗号化アカウント情報ハッシュ値４５’を得る（Ｓ１５）。ここでは、例えばＲＳＡ（Rivest Shamir Adleman）などの公知の暗号化技術を利用することができる。ＲＳＡによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。
【００４６】
上記の処理によって得られた、暗号化共通鍵４３’、暗号化アカウント情報４４’、および暗号化アカウント情報ハッシュ値４５’をまとめて認証チケット１８として取り扱う。ここで、暗号化アカウント情報ハッシュ値４５’は、アカウント情報４４がＷｅｂブラウザ１３等を介して改竄されていないことを証明する電子署名としての役割を有する。
【００４７】
＜処理の流れ（アカウント情報復元）＞
図５は、Ｗｅｂブラウザ１３を介して社内Ｗｅｂサーバ１４から認証チケット１８の送付を受けた外部アプリケーションサーバ３０の連携認証部３１において、認証チケット１８からアカウント情報を復元する処理の流れの例について示した図である。まず、Ｗｅｂブラウザ１３からのリクエストの内容から認証チケット１８、すなわち暗号化共通鍵４３’、暗号化アカウント情報４４’、および暗号化アカウント情報ハッシュ値４５’を取得する。このうちの暗号化共通鍵４３’について、外部アプリケーションサーバ３０が生成して保管している秘密鍵５１によって復号化して、共通鍵４３を得る（Ｓ２１）。
【００４８】
この共通鍵４３によって、認証チケット１８の暗号化アカウント情報４４’を復号化して、アカウント情報４４を得る（Ｓ２２）。さらに、このアカウント情報４４についてハッシュ化して復元アカウント情報ハッシュ値４６を取得する（Ｓ２３）。一方、認証チケット１８の暗号化アカウント情報ハッシュ値４５’について、社内Ｗｅｂサーバ１４から鍵交換によって取得している公開鍵４１によって復号化して、アカウント情報ハッシュ値４５を取得する（Ｓ２４）。
【００４９】
このアカウント情報ハッシュ値４５と、ステップＳ２３で得られた復元アカウント情報ハッシュ値４６とを比較して一致するか否かを判定する（Ｓ２５）。一致していれば、ステップＳ２２で取得したアカウント情報４４はＷｅｂブラウザ１３等を介して改竄されていないことが証明されるため、このアカウント情報４４を用いて後続する連携認証処理を行うことができる。一致しない場合には、Ｗｅｂブラウザ１３にエラーを応答して処理を終了する。
【００５０】
なお、上述した認証チケット１８の授受に際しての一連の暗号化方式は一例であって、他の暗号化方式を採用することも当然可能である。
【００５１】
＜処理の流れ（連携認証）＞
図６は、外部アプリケーションサーバ３０の連携認証部３１および認証部３２において、認証チケット１８から取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。まず、連携認証部３１は、認証チケット１８から取得したアカウント情報４４の内容について所定の妥当性チェックを行う（Ｓ３１）。ここでは、例えば、ユーザＩＤの一意性チェック（他のグループ等に同一のユーザＩＤが存在しないか）や、接続元のＷｅｂブラウザ１３のＩＰアドレスの範囲チェック、認証チケット１８の発行日時（例えばアカウント情報４４に予め設定しておく）と現在日時との乖離チェックなどのチェックが行われる。チェックの結果不当な内容がある場合には、Ｗｅｂブラウザ１３にエラーを応答して処理を終了する。
【００５２】
次に、連携認証部３１は、取得したアカウント情報４４の内容が、外部アプリケーションサーバ３０によって提供される外部サービスに対して既に登録済みかを判定する（Ｓ３２）。登録されていない場合は、認証部３２を介して当該アカウント情報を新規登録する（Ｓ３３）。一方、既に登録済みの場合は、登録されている内容に対して取得したアカウント情報４４の内容に変更があるかを判定し（Ｓ３４）、変更がある場合は、取得したアカウント情報４４の内容に基づいて登録内容を更新する（Ｓ３５）。
【００５３】
その後、連携認証部３１は、認証チケット１８から取得したアカウント情報４４の内容に基づいて、認証部３２を介して外部サービスに対するユーザ認証（ログイン）処理を行い（Ｓ３６）、連携認証処理を終了する。これにより、ユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスに対して直接アクセスしてユーザ認証を行った場合と同様に、Ｗｅｂブラウザ１３を介して当該外部サービスを利用することができる。
【００５４】
以上に説明したように、本発明の一実施の形態であるアカウント情報連携システム１によれば、企業の社員等のユーザ１２が、社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用して、社内Ｗｅｂサーバ１４等からの直接の通信がセキュリティ上制限されている外部アプリケーションサーバ３０によって提供される外部サービスに対して、ユーザ認証を行った上で利用することが可能となる。また、当該外部サービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザ１２が個別にアカウント情報の登録や変更、削除等の管理作業を行うことが不要となる。
【００５５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００５６】
例えば、本実施の形態では、外部アプリケーションサーバ３０によって提供される外部サービスについての専用のユーザ認証画面を提供するものとして、社内Ｗｅｂサーバ１４および認証部１５を構成しているが、他の社内システムによって提供されるサービスについて既に行われているユーザ認証の情報を引き継ぐものとして、シングルサインオンにより当該外部サービスを利用できるようにしてもよい。
【００５７】
すなわち、例えば社内Ｗｅｂサーバ１４では他の社内システムが稼動してサービスを提供しており、ユーザ１２が当該社内システムの使用に際して、社内Ｗｅｂサーバ１４上で認証部１５を介してディレクトリサーバ１７によるユーザ認証を行った場合は、その後、当該社内システムからユーザ１２がＵＲＬのリンク等を介して外部アプリケーションサーバ３０によって提供される外部サービスを新たに使用する際に、社内Ｗｅｂサーバ１４でのユーザ認証の際に使用されたアカウント情報（例えばＣｏｏｋｉｅ等に保存）を用いることで、認証チケット発行部１６は、ディレクトリサーバ１７からアカウント情報を再度取得することなく認証チケット１８を発行する。
【００５８】
この認証チケット１８を上述した手順と同様の手順でＷｅｂブラウザ１３を介して外部アプリケーションサーバ３０に受け渡し、外部アプリケーションサーバ３０において連携認証を行うことで、ユーザ１２によるユーザＩＤ／パスワードの再度の入力およびディレクトリサーバ１７での再度のユーザ認証処理を要さずに外部サービスを利用可能とすることができる。
【産業上の利用可能性】
【００５９】
本発明は、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに利用可能である。
【符号の説明】
【００６０】
１…アカウント情報連携システム、
１０…イントラネット、１１…社内ネットワーク、１２…ユーザ、１３…Ｗｅｂブラウザ、１４…社内Ｗｅｂサーバ、１５…認証部、１６…認証チケット発行部、１７…ディレクトリサーバ、１８…認証チケット、
２０…インターネット、
３０…外部アプリケーションサーバ、３１…連携認証部、３２…認証部、
４１…秘密鍵、４２…公開鍵、４３…共通鍵、４３’…暗号化共通鍵、４４…アカウント情報、４４’…暗号化アカウント情報、４５…アカウント情報ハッシュ値、４５’…暗号化アカウント情報ハッシュ値、４６…復元アカウント情報ハッシュ値、
５１…秘密鍵、５２…公開鍵
【技術分野】
【０００１】
本発明は、ユーザのアカウント情報を他サービスに連携させる技術に関し、特に、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年、企業で利用される社内システム等においては、ユーザ（社員等）のＩＤやパスワード等、および氏名や所属部署その他の属性情報などを含むアカウント情報を一元的に管理するとともに、ＩＤとパスワードによるユーザ認証の手段を提供し、これを複数の社内システムから共通で利用可能とするような仕組みが実装される場合が増えている。このようなユーザ管理の仕組みの実装に際しては、例えば、ＬＤＡＰ（Lightweight Directory Access Protocol）を実装したソフトウェアを用いたディレクトリサーバなどが利用される。
【０００３】
また、ユーザが一回のユーザ認証処理を行うことで、ユーザ認証が必要な複数の社内システムを利用できるようにするシングルサインオンの仕組みが実装される場合もある。例えば、各社内システムのサーバにおいてＳＡＭＬ（Security Assertion Markup Language）プロトコルを用いてサーバ間で通信を行って認証情報を自動的に引き継ぐことで、複数の社内システム間でシングルサインオンを実現することができる。
【０００４】
しかしながら、イントラネット内での社内システムの利用のみで業務を完結できない場合もあり、例えば、外部のベンダー等によってＡＳＰ（Application Service Provider）として提供されるサービスをインターネットを介して業務上利用することになる場合も多い。このとき通常は、当該外部のサービスに対して別途ユーザ登録等を行って、これに対して個別にログイン等の認証処理を行った上でサービスを利用する。
【０００５】
このような環境では、社内システムと外部のシステムとの間でシングルサインオンを実現することは困難である。通常、上述したようなシングルサインオンの仕組みでは、サーバ間で認証情報の引き継ぎが行われるところ、これを可能とするためにはサーバ間で認証情報の引き継ぎ・受け入れを許容する信頼関係の成立が必要とされる。しかし、社内システムと外部のシステムとの間では、セキュリティ上の関係等からこのような信頼関係が成立しない場合も多いからである。
【０００６】
これに対して、例えば、特開２０１０−８６４３５号公報（特許文献１）には、以下のようなネットワークシステムの例が記載されている。すなわち、当該ネットワークシステムは、複数のＷｅｂサーバと中継サーバおよび複数のユーザ端末から構成され、第一のＷｅｂサーバは、端末からの認証情報と記憶部の認証情報とを照合して認証を行い、認証が成立した場合に、認証情報に含まれる第一のユーザＩＤ、第一のＷｅｂサーバへの第一のＵＲＬ、第二Ｗｅｂサーバへの第二のＵＲＬおよび認証強度に関連する情報を含むメッセージを生成して中継サーバに送信する。
【０００７】
中継サーバは、同一ユーザ情報を登録するテーブルから第一のユーザＩＤに対応する第二のユーザＩＤを取得して、メッセージ中の第一のユーザＩＤを第二のユーザＩＤに書き換えて第二のＷｅｂサーバに送信する。第二のＷｅｂサーバは、メッセージを受信すると、メッセージから第二のユーザＩＤを取得し、第二のユーザＩＤが記憶部に記憶されている場合に、受信した認証強度に関連する情報と記憶部の認証強度に関連する情報に基づいてユーザの再認証を行う。これにより、互いに信頼関係や連携関係にない複数のシステムから構成されるネットワークシステムにおいて、一回の認証情報の入力により、認証が必要な複数のアプリケーションを利用可能とする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１０−８６４３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１のような仕組みを用いれば、例えば、社内システムと外部のＡＳＰサービスとの間のような信頼関係が成立していないシステム間で、シングルサインオンの環境を構築することが可能である。
【００１０】
しかしながら、ユーザ（社員等）は、社内システムでのユーザ管理とは別に、外部のサービスにおいても個別にアカウント情報の登録や変更等の管理を行わなければならないのが通常である。また、例えば特許文献１での中継サーバなどのように、社内で通常使用するユーザＩＤと外部のサービスにおけるユーザＩＤとの対応情報の管理も行う必要がある。
【００１１】
また従来技術では、例えば社内システムでユーザ認証を経た上でいずれかのアプリケーションを実行した後、その認証情報を引き継いで外部のサービスを利用するという、一般的なシングルサインオンの形態ではなく、ユーザが社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用して、外部のサービスに対してユーザ認証を行った上で利用するという形態（アカウント情報の共用）のシステムを構築することは考慮されていない。
【００１２】
そこで本発明の目的は、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することができるアカウント情報連携システムを提供することにある。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することができるアカウント情報連携システムを提供することにある。
【００１３】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１４】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１５】
本発明の代表的な実施の形態によるアカウント情報連携システムは、組織の内部の第１のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第１のサーバと、前記組織内のユーザのアカウント情報を管理する第２のサーバと、前記第１のネットワークおよび前記組織の外部の第２のネットワークに接続可能なクライアント端末、および前記第２のネットワークに接続されたアプリケーションサーバとからなり、前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、以下の特徴を有するものである。
【００１６】
すなわち、前記第１のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第２のサーバによってユーザ認証を行う第１の認証部と、前記第１の認証部が前記第２のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第１の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有する。
【００１７】
また、前記クライアント端末は、前記第１のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第２の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第２の認証部を介してユーザ認証を行う連携認証部とを有する。
【発明の効果】
【００１８】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１９】
本発明の代表的な実施の形態によれば、企業等の組織内で通常使用するアカウント情報をそのまま使用して、組織内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対してユーザ認証を行った上で利用することが可能となる。また、外部のサービスに対して個別のアカウント情報の管理を行うことなく利用することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における全体的な処理の流れの例について概要を示した図である。
【図３】本発明の一実施の形態における暗号鍵を初期登録しておく処理の流れの例について示した図である。
【図４】本発明の一実施の形態におけるアカウント情報に基づいて認証チケットを生成する処理の流れの例について示した図である。
【図５】本発明の一実施の形態における認証チケットからアカウント情報を復元する処理の流れの例について示した図である。
【図６】本発明の一実施の形態における認証チケットから取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。
【発明を実施するための形態】
【００２１】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００２２】
本発明の一実施の形態であるアカウント情報連携システムは、企業の社員等のユーザが、社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用（ここでの「使用」とは画面を通して「入力」することを指す）して、社内のサーバ等からの直接の通信がセキュリティ上制限されている外部のサービスに対して、ユーザ認証を行った上で利用することを可能とするシステムである。さらに、当該外部のサービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザが個別にアカウント情報の登録や変更、削除等の管理作業を行うことを不要とする。
【００２３】
＜システム構成＞
図１は、本発明の一実施の形態であるアカウント情報連携システムの構成例について概要を示した図である。アカウント情報連携システム１は、例えば、企業内においてＬＡＮ（Local Area Network）等からなる社内ネットワーク１１によってイントラネット１０が構成され、これに社内Ｗｅｂサーバ１４、ディレクトリサーバ１７、および社員等であるユーザ１２の有するクライアント端末上で稼働するＷｅｂブラウザ１３がそれぞれ接続する構成を有する。
【００２４】
ユーザ１２は、Ｗｅｂブラウザ１３を利用して社内Ｗｅｂサーバ１４にアクセス可能であるとともに、さらに、インターネット２０を介して外部アプリケーションサーバ３０にアクセスして外部サービスの提供を受けることが可能である。ここでの外部サービスとしては、ユーザ登録を行った上で、ユーザ認証を経て利用可能となるものが該当し、例えば、Ｗｅｂベースでのメールやストレージなどを始めとするクラウドコンピューティングサービスや、ファイル転送サービス、会員制の各種ポータルサイト、情報提供サイトなどが挙げられる。なお、セキュリティ上、社内Ｗｅｂサーバ１４およびディレクトリサーバ１７と、外部アプリケーションサーバ３０との間での直接の通信は許可されないものとする。
【００２５】
社内Ｗｅｂサーバ１４は、例えば、図示しないＷｅｂサーバプログラム上で稼働するソフトウェアプログラムとして実装される認証部１５および認証チケット発行部１６を有し、ユーザ１２に対してユーザ認証のためのインタフェースを提供する情報処理装置である。認証部１５は、Ｗｅｂブラウザ１３を介して、ユーザ１２に対して、外部アプリケーションサーバ３０によって提供される外部サービスを利用する際のユーザ認証のためのインタフェース（例えばユーザＩＤ／パスワードの入力画面）を外部アプリケーションサーバ３０に代わって提供する。また、入力されたユーザＩＤ／パスワード等のアカウント情報を利用してディレクトリサーバ１７に問合せてユーザ認証を行う。
【００２６】
認証チケット発行部１６は、認証部１５がユーザ認証の際にディレクトリサーバ１７から取得したアカウント情報に基づいて後述する認証チケットを発行する。発行した認証チケットは、認証部１５によってＷｅｂブラウザ１３に対して応答される。
【００２７】
ディレクトリサーバ１７は、ユーザ１２が社内において通常使用するユーザＩＤやパスワード、属性情報等からなるアカウント情報を一元的に管理するディレクトリサービスの機能を提供する情報処理装置である。本実施の形態では、当該ディレクトリサーバ１７においてＬＤＡＰを用いて社内のアカウント情報の管理を行うものとしているが、ＬＤＡＰ以外の手法によるものや、ディレクトリサービス以外の仕組みによってアカウント情報を管理するものであってもよい。また、社内で通常使用されるアカウント情報を一元的に管理していることから、他の社内システムやサービスに対して同様にユーザ認証の機能を提供するものであってもよい。
【００２８】
外部アプリケーションサーバ３０は、インターネット２０等を介してＡＳＰ等により外部のサービスを提供する情報処理装置であり、例えば、図示しないＷｅｂサーバプログラム上で稼働するソフトウェアプログラムとして実装される連携認証部３１および認証部３２と、外部サービスに係る処理を実行する業務アプリケーション（図示しない）を有する。
【００２９】
認証部３２は、外部アプリケーションサーバ３０が通常のユーザに対して提供する一般的なユーザ認証の機能を実装するものであり、例えば、ユーザＩＤ／パスワードの入力を受け付けて認証を行う認証機能や、アカウント情報の登録や変更・削除などの管理機能などのインタフェースを有する。
【００３０】
連携認証部３１は、イントラネット１０内のＷｅｂブラウザ１３から認証チケットの送付を受け、認証チケットからアカウント情報を取得して、これに基づいて認証部３２を介してユーザ認証を行う。このとき、認証チケットから取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ３０に登録されていない場合は、認証部３２を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、必要に応じて認証チケットから取得したアカウント情報に基づいて登録内容を更新する。
【００３１】
なお、本実施の形態では、アカウント情報連携システム１をＷｅｂベースのシステム構成により実装する場合を例としているが、これに限らず、例えばクライアント／サーバ型のシステム構成とすることも当然可能である。
【００３２】
＜処理の流れ（概要）＞
図２は、本実施の形態のアカウント情報連携システムにおける全体的な処理の流れの例について概要を示した図である。まず、社内のユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスを利用するため、Ｗｅｂブラウザ１３を利用して社内Ｗｅｂサーバ１４の認証部１５にアクセスして、アカウント情報の入力画面を介してユーザＩＤ／パスワードを入力する（１）。認証部１５へのアクセスは、例えば、社内Ｗｅｂサーバ１４によって提供されるイントラネット１０のポータルサイトからのリンクや、Ｗｅｂブラウザ１３のブックマーク等を利用して行うことができる。なお、ここで入力するユーザＩＤ／パスワードは、ユーザ１２がイントラネット１０内の社内システムを利用する際に通常使用するものと同じものである。
【００３３】
社内Ｗｅｂサーバ１４の認証部１５は、入力されたアカウント情報に基づいてディレクトリサーバ１７に問合せてユーザ認証を行い（２）、認証が成功した場合にはユーザ１２についてのユーザＩＤや属性情報などを含むアカウント情報をディレクトリサーバ１７から取得する（３）。
【００３４】
その後、認証部１５は、取得したアカウント情報を認証チケット発行部１６に渡す。認証チケット発行部１６は、渡されたアカウント情報について所定の妥当性チェックを行った後、アカウント情報を暗号化することによって認証チケットを生成して認証部１５に発行する（４）。認証部１５は、発行された認証チケット１８の情報を含むリダイレクト画面をいったんＷｅｂブラウザ１３に送信する（５）。
【００３５】
Ｗｅｂブラウザ１３では、例えばリダイレクト画面を介して外部アプリケーションサーバ３０に対して自動的にアクセスをリダイレクトすることで、認証チケット１８を外部アプリケーションサーバ３０に転送する（６）。当該処理には公知技術を利用することができ、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等を利用した自動Ｓｕｂｍｉｔによって認証チケット１８の情報を外部アプリケーションサーバ３０の連携認証部３１に対してＰＯＳＴ送信することができる。
【００３６】
外部アプリケーションサーバ３０の連携認証部３１は、転送されたリクエストの内容から認証チケット１８の情報を取得し、取得した認証チケット１８を復号化してアカウント情報を復元する。さらに、アカウント情報の内容について所定の妥当性チェックを行い、問題がない場合はこのアカウント情報を用いて連携認証処理を行う。すなわち、認証部３２を介して外部アプリケーションサーバ３０においてユーザ認証処理を行う（７）。なお、ここでは通常のユーザ認証処理と同様の判定処理を行ってもよいし、アカウント情報の内容が妥当であればその内容を引き継いでそのまま認証を成功させるようにしてもよい。
【００３７】
また、上述したように、このとき認証チケット１８から取得したアカウント情報に該当するアカウント情報が外部アプリケーションサーバ３０に登録されていない場合は、認証部３２を介してアカウント情報の新規登録を行う。アカウント情報が登録されている場合は、認証チケット１８から取得したアカウント情報に基づいて登録内容を更新する。
【００３８】
連携認証が成功した場合は、外部アプリケーションサーバ３０は、サービスを提供するための画面をＷｅｂブラウザ１３に対して応答する（８）。以上の一連の処理により、ユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスに対して、社内で通常使用するユーザＩＤ／パスワード等のアカウント情報を使用して認証処理を行い、シームレスにアクセスすることが可能となる。
【００３９】
＜処理の流れ（初期登録）＞
以下では、社内Ｗｅｂサーバ１４と外部アプリケーションサーバ３０との間で認証チケット１８の授受を行い、アカウント情報を連携して認証を行う際の処理の詳細について説明する。図３は、アカウント情報連携システム１の環境構築時に暗号鍵を初期登録しておく処理の流れの例について示した図である。
【００４０】
本実施の形態では、社内Ｗｅｂサーバ１４と外部アプリケーションサーバ３０との間での認証チケット１８の授受に際して、公開鍵暗号化方式と共通鍵暗号化方式を用いたハイブリッド暗号化方式による暗号化を行う。これにより、外部アプリケーションサーバ３０に対するアクセスが、アカウント情報を連携して認証処理を行うことができる企業等からのものであることを証明するとともに、認証チケット１８の情報が外部に漏洩した場合でも、社内のディレクトリサーバ１７に登録されている元のアカウント情報が復元されないようにする。
【００４１】
このため、まず事前の初期登録として、社内Ｗｅｂサーバ１４および外部アプリケーションサーバ３０において、秘密鍵と公開鍵からなる鍵ペア（秘密鍵４１と公開鍵４２、および秘密鍵５１と公開鍵５２）をそれぞれ生成する（Ｓ０１、Ｓ０２）。鍵ペアの生成については、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。
【００４２】
生成した鍵ペアのうち、それぞれの公開鍵４２および公開鍵５２を相互に交換する（Ｓ０３）。鍵交換の手段については特に限定されず、例えば、インターネット２０を介して電子メール等により交換してもよいし、電子証明書の形で発行してもよい。記録媒体に格納してインターネット２０を介さずに手動で交換することも可能である。交換した公開鍵５２、４２は、社内Ｗｅｂサーバ１４および外部アプリケーションサーバ３０においてそれぞれ保管しておく（Ｓ０４、Ｓ０５）。
【００４３】
＜処理の流れ（認証チケット生成）＞
図４は、ユーザ１２が外部サービスの利用にあたって社内Ｗｅｂサーバ１４にユーザ認証の要求を行った際に、認証チケット発行部１６においてアカウント情報に基づいて認証チケット１８を生成する処理の流れの例について示した図である。まず、ディレクトリサーバ１７から取得したアカウント情報を暗号化するための共通鍵（セッション鍵）４３を生成する（Ｓ１１）。共通鍵４３の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。所定のデータ長の乱数を生成して共通鍵４３としてもよい。
【００４４】
さらにこの共通鍵４３によって、アカウント情報４４を暗号化して暗号化アカウント情報４４’を得る（Ｓ１２）。ここでは、例えばＡＥＳ（Advanced Encryption Standard）などの公知の暗号化技術を利用することができる。ＡＥＳによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。一方、アカウント情報４４の暗号化に用いた共通鍵４３は、外部アプリケーションサーバ３０から鍵交換によって取得している公開鍵５２によって暗号化し、暗号化共通鍵４３’としておく（Ｓ１３）。
【００４５】
また、アカウント情報４４については、別途ハッシュ化してアカウント情報ハッシュ値４５を取得し（Ｓ１４）、これを社内Ｗｅｂサーバ１４が生成して保管している秘密鍵４１によって暗号化して、暗号化アカウント情報ハッシュ値４５’を得る（Ｓ１５）。ここでは、例えばＲＳＡ（Rivest Shamir Adleman）などの公知の暗号化技術を利用することができる。ＲＳＡによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。
【００４６】
上記の処理によって得られた、暗号化共通鍵４３’、暗号化アカウント情報４４’、および暗号化アカウント情報ハッシュ値４５’をまとめて認証チケット１８として取り扱う。ここで、暗号化アカウント情報ハッシュ値４５’は、アカウント情報４４がＷｅｂブラウザ１３等を介して改竄されていないことを証明する電子署名としての役割を有する。
【００４７】
＜処理の流れ（アカウント情報復元）＞
図５は、Ｗｅｂブラウザ１３を介して社内Ｗｅｂサーバ１４から認証チケット１８の送付を受けた外部アプリケーションサーバ３０の連携認証部３１において、認証チケット１８からアカウント情報を復元する処理の流れの例について示した図である。まず、Ｗｅｂブラウザ１３からのリクエストの内容から認証チケット１８、すなわち暗号化共通鍵４３’、暗号化アカウント情報４４’、および暗号化アカウント情報ハッシュ値４５’を取得する。このうちの暗号化共通鍵４３’について、外部アプリケーションサーバ３０が生成して保管している秘密鍵５１によって復号化して、共通鍵４３を得る（Ｓ２１）。
【００４８】
この共通鍵４３によって、認証チケット１８の暗号化アカウント情報４４’を復号化して、アカウント情報４４を得る（Ｓ２２）。さらに、このアカウント情報４４についてハッシュ化して復元アカウント情報ハッシュ値４６を取得する（Ｓ２３）。一方、認証チケット１８の暗号化アカウント情報ハッシュ値４５’について、社内Ｗｅｂサーバ１４から鍵交換によって取得している公開鍵４１によって復号化して、アカウント情報ハッシュ値４５を取得する（Ｓ２４）。
【００４９】
このアカウント情報ハッシュ値４５と、ステップＳ２３で得られた復元アカウント情報ハッシュ値４６とを比較して一致するか否かを判定する（Ｓ２５）。一致していれば、ステップＳ２２で取得したアカウント情報４４はＷｅｂブラウザ１３等を介して改竄されていないことが証明されるため、このアカウント情報４４を用いて後続する連携認証処理を行うことができる。一致しない場合には、Ｗｅｂブラウザ１３にエラーを応答して処理を終了する。
【００５０】
なお、上述した認証チケット１８の授受に際しての一連の暗号化方式は一例であって、他の暗号化方式を採用することも当然可能である。
【００５１】
＜処理の流れ（連携認証）＞
図６は、外部アプリケーションサーバ３０の連携認証部３１および認証部３２において、認証チケット１８から取得したアカウント情報に基づいて連携認証を行う処理の流れの例について示したフローチャートである。まず、連携認証部３１は、認証チケット１８から取得したアカウント情報４４の内容について所定の妥当性チェックを行う（Ｓ３１）。ここでは、例えば、ユーザＩＤの一意性チェック（他のグループ等に同一のユーザＩＤが存在しないか）や、接続元のＷｅｂブラウザ１３のＩＰアドレスの範囲チェック、認証チケット１８の発行日時（例えばアカウント情報４４に予め設定しておく）と現在日時との乖離チェックなどのチェックが行われる。チェックの結果不当な内容がある場合には、Ｗｅｂブラウザ１３にエラーを応答して処理を終了する。
【００５２】
次に、連携認証部３１は、取得したアカウント情報４４の内容が、外部アプリケーションサーバ３０によって提供される外部サービスに対して既に登録済みかを判定する（Ｓ３２）。登録されていない場合は、認証部３２を介して当該アカウント情報を新規登録する（Ｓ３３）。一方、既に登録済みの場合は、登録されている内容に対して取得したアカウント情報４４の内容に変更があるかを判定し（Ｓ３４）、変更がある場合は、取得したアカウント情報４４の内容に基づいて登録内容を更新する（Ｓ３５）。
【００５３】
その後、連携認証部３１は、認証チケット１８から取得したアカウント情報４４の内容に基づいて、認証部３２を介して外部サービスに対するユーザ認証（ログイン）処理を行い（Ｓ３６）、連携認証処理を終了する。これにより、ユーザ１２は、外部アプリケーションサーバ３０によって提供される外部サービスに対して直接アクセスしてユーザ認証を行った場合と同様に、Ｗｅｂブラウザ１３を介して当該外部サービスを利用することができる。
【００５４】
以上に説明したように、本発明の一実施の形態であるアカウント情報連携システム１によれば、企業の社員等のユーザ１２が、社内で通常使用するユーザＩＤ、パスワード等のアカウント情報をそのまま使用して、社内Ｗｅｂサーバ１４等からの直接の通信がセキュリティ上制限されている外部アプリケーションサーバ３０によって提供される外部サービスに対して、ユーザ認証を行った上で利用することが可能となる。また、当該外部サービスにおいて、ユーザ認証時にアカウント情報の作成や変更等を自動的に行うことにより、ユーザ１２が個別にアカウント情報の登録や変更、削除等の管理作業を行うことが不要となる。
【００５５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００５６】
例えば、本実施の形態では、外部アプリケーションサーバ３０によって提供される外部サービスについての専用のユーザ認証画面を提供するものとして、社内Ｗｅｂサーバ１４および認証部１５を構成しているが、他の社内システムによって提供されるサービスについて既に行われているユーザ認証の情報を引き継ぐものとして、シングルサインオンにより当該外部サービスを利用できるようにしてもよい。
【００５７】
すなわち、例えば社内Ｗｅｂサーバ１４では他の社内システムが稼動してサービスを提供しており、ユーザ１２が当該社内システムの使用に際して、社内Ｗｅｂサーバ１４上で認証部１５を介してディレクトリサーバ１７によるユーザ認証を行った場合は、その後、当該社内システムからユーザ１２がＵＲＬのリンク等を介して外部アプリケーションサーバ３０によって提供される外部サービスを新たに使用する際に、社内Ｗｅｂサーバ１４でのユーザ認証の際に使用されたアカウント情報（例えばＣｏｏｋｉｅ等に保存）を用いることで、認証チケット発行部１６は、ディレクトリサーバ１７からアカウント情報を再度取得することなく認証チケット１８を発行する。
【００５８】
この認証チケット１８を上述した手順と同様の手順でＷｅｂブラウザ１３を介して外部アプリケーションサーバ３０に受け渡し、外部アプリケーションサーバ３０において連携認証を行うことで、ユーザ１２によるユーザＩＤ／パスワードの再度の入力およびディレクトリサーバ１７での再度のユーザ認証処理を要さずに外部サービスを利用可能とすることができる。
【産業上の利用可能性】
【００５９】
本発明は、企業内で通常使用されるアカウント情報を外部のサービスに連携させるアカウント情報連携システムに利用可能である。
【符号の説明】
【００６０】
１…アカウント情報連携システム、
１０…イントラネット、１１…社内ネットワーク、１２…ユーザ、１３…Ｗｅｂブラウザ、１４…社内Ｗｅｂサーバ、１５…認証部、１６…認証チケット発行部、１７…ディレクトリサーバ、１８…認証チケット、
２０…インターネット、
３０…外部アプリケーションサーバ、３１…連携認証部、３２…認証部、
４１…秘密鍵、４２…公開鍵、４３…共通鍵、４３’…暗号化共通鍵、４４…アカウント情報、４４’…暗号化アカウント情報、４５…アカウント情報ハッシュ値、４５’…暗号化アカウント情報ハッシュ値、４６…復元アカウント情報ハッシュ値、
５１…秘密鍵、５２…公開鍵
【特許請求の範囲】
【請求項１】
組織の内部の第１のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第１のサーバと、前記組織内のユーザのアカウント情報を管理する第２のサーバと、前記第１のネットワークおよび前記組織の外部の第２のネットワークに接続可能なクライアント端末、および前記第２のネットワークに接続されたアプリケーションサーバとからなり、
前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、
前記第１のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第２のサーバによってユーザ認証を行う第１の認証部と、前記第１の認証部が前記第２のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第１の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有し、
前記クライアント端末は、前記第１のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、
前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第２の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第２の認証部を介してユーザ認証を行う連携認証部とを有することを特徴とするアカウント情報連携システム。
【請求項２】
請求項１に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに登録されていない場合は、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバに対してアカウント情報の新規登録を行うことを特徴とするアカウント情報連携システム。
【請求項３】
請求項１または２に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに既に登録されている場合は、前記アプリケーションサーバでのアカウント情報の登録内容に対して、前記組織内でのアカウント情報の内容に変更がある場合に、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバでのアカウント情報の登録内容を更新することを特徴とするアカウント情報連携システム。
【請求項４】
請求項１〜３のいずれか１項に記載のアカウント情報連携システムにおいて、
前記第１のサーバの前記認証チケット発行部は、前記認証チケットを暗号化して発行し、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットを復号化して前記ユーザの前記組織内でのアカウント情報を取得することを特徴とするアカウント情報連携システム。
【請求項５】
請求項１〜４のいずれか１項に記載のアカウント情報連携システムにおいて、
前記第１のサーバでは他のサービスを提供しており、
前記第１の認証部は、前記ユーザが前記他のサービスを利用する際のユーザ認証を行うためのインタフェースを提供し、
前記認証チケット発行部は、前記ユーザが前記他のサービスの利用中に前記アプリケーションサーバによって提供される前記外部サービスを新たに利用する際に、前記他のサービスを利用する際のユーザ認証において使用されたアカウント情報を用いて認証チケットを発行することを特徴とするアカウント情報連携システム。
【請求項１】
組織の内部の第１のネットワークに接続され、前記組織内のユーザに対してユーザ認証のためのインタフェースを提供する第１のサーバと、前記組織内のユーザのアカウント情報を管理する第２のサーバと、前記第１のネットワークおよび前記組織の外部の第２のネットワークに接続可能なクライアント端末、および前記第２のネットワークに接続されたアプリケーションサーバとからなり、
前記ユーザが、前記アプリケーションサーバによって提供される外部サービスに対して、前記組織内でのアカウント情報を使用してユーザ認証を行った上で利用することを可能とするアカウント情報連携システムであって、
前記第１のサーバは、前記組織内のユーザに対して前記外部サービスを利用する際のユーザ認証のためのインタフェースを提供し、前記ユーザによって前記クライアント端末から入力されたアカウント情報を利用して前記第２のサーバによってユーザ認証を行う第１の認証部と、前記第１の認証部が前記第２のサーバから取得した前記ユーザの前記組織内でのアカウント情報に基づいて認証チケットを発行し、発行した前記認証チケットを前記第１の認証部を介して前記クライアント端末に応答する認証チケット発行部とを有し、
前記クライアント端末は、前記第１のサーバから応答された前記認証チケットを前記アプリケーションサーバに転送し、
前記アプリケーションサーバは、前記外部サービスを利用するためのユーザ認証の機能を提供する第２の認証部と、前記クライアント端末からの前記認証チケットの送付を受け、前記認証チケットから前記ユーザの前記組織内でのアカウント情報を取得して、前記組織内でのアカウント情報に基づいて前記第２の認証部を介してユーザ認証を行う連携認証部とを有することを特徴とするアカウント情報連携システム。
【請求項２】
請求項１に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに登録されていない場合は、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバに対してアカウント情報の新規登録を行うことを特徴とするアカウント情報連携システム。
【請求項３】
請求項１または２に記載のアカウント情報連携システムにおいて、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットから取得した前記ユーザの前記組織内でのアカウント情報が前記アプリケーションサーバに既に登録されている場合は、前記アプリケーションサーバでのアカウント情報の登録内容に対して、前記組織内でのアカウント情報の内容に変更がある場合に、前記認証部を介して、前記組織内でのアカウント情報に基づいて前記アプリケーションサーバでのアカウント情報の登録内容を更新することを特徴とするアカウント情報連携システム。
【請求項４】
請求項１〜３のいずれか１項に記載のアカウント情報連携システムにおいて、
前記第１のサーバの前記認証チケット発行部は、前記認証チケットを暗号化して発行し、
前記アプリケーションサーバの前記連携認証部は、前記クライアント端末から送付された前記認証チケットを復号化して前記ユーザの前記組織内でのアカウント情報を取得することを特徴とするアカウント情報連携システム。
【請求項５】
請求項１〜４のいずれか１項に記載のアカウント情報連携システムにおいて、
前記第１のサーバでは他のサービスを提供しており、
前記第１の認証部は、前記ユーザが前記他のサービスを利用する際のユーザ認証を行うためのインタフェースを提供し、
前記認証チケット発行部は、前記ユーザが前記他のサービスの利用中に前記アプリケーションサーバによって提供される前記外部サービスを新たに利用する際に、前記他のサービスを利用する際のユーザ認証において使用されたアカウント情報を用いて認証チケットを発行することを特徴とするアカウント情報連携システム。
【図３】
【図４】
【図５】
【図６】
【図１】
【図２】
【図４】
【図５】
【図６】
【図１】
【図２】
【公開番号】特開２０１２−１８１６６２（Ｐ２０１２−１８１６６２Ａ）
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願番号】特願２０１１−４３９２０（Ｐ２０１１−４３９２０）
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年９月２０日（２０１２．９．２０）
【国際特許分類】
【出願日】平成２３年３月１日（２０１１．３．１）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]