JPWO2013046336A1 - グループ定義管理システム - Google Patents

Abstract

内部ＩＤと外部ＩＤとの対応を容易に取得し、内部ＩＤのグループ定義の情報を外部サイトに容易に反映させることが可能なグループ定義管理システムである。本発明の代表的な実施の形態は、内部サーバ１０と外部サーバ２０およびクライアントからなり、内部サーバ１０は、内部ユーザ管理テーブル１５と、内部ＩＤにより認証を行う内部認証部１１を有し、外部サーバ２０は、外部ユーザ管理テーブル２４と、外部ＩＤにより認証を行い、指定されたユーザが正当な利用者であるかの問い合わせに対して外部ＩＤの情報を応答する外部認証部２１を有し、内部サーバ１０は、さらに内部認証部１１による認証を受けたユーザが利用するクライアントからの要求に応じて、外部サーバ２０に対して当該ユーザが外部サーバ２０の正当な利用者であるかの問い合わせを行い、応答された外部ＩＤを内部ＩＤと関連付けて内部ユーザ管理テーブル１５に登録する認証連携部１３を有する。

Description

本発明は、Ｗｅｂサイト間の連携技術に関し、特に、社内システム等の内部サイトとＳＮＳサービス等の外部サイトとの間でユーザグループのメンバーの情報を連携するグループ定義管理システムに適用して有効な技術に関するものである。

近年、例えば、Ｆａｃｅｂｏｏｋ（登録商標）やＴｗｉｔｔｅｒ（登録商標）などを始めとするいわゆるＳＮＳ（Social Networking Service）サービスの利用がグローバルな規模で拡がっており、コミュニケーションの手段として有効なツールであることが広く認識されてきている。そこで、これらのサービスを、個人的な利用だけではなく、例えば、企業等が社内外におけるコミュニケーションツールとして活用するということも検討されている。

ここで、例えば、企業等の社員が、社内システムと外部のＳＮＳサービスとの両方を利用するという場面で用いられる仕組みとして、いわゆるシングルサインオン（ＳＳＯ）の技術がある。ＳＳＯでは、ユーザが一度の認証（例えば社内システムでの認証）を行うことで、ユーザ認証が必要な複数のシステムやサーバに対して個別の認証手続きを行わずにアクセスすることを可能とする。この仕組みを実現する手法としては、例えば、各サーバやシステムがＳＡＭＬ（Security Assertion Markup Language）プロトコル（非特許文献１）を用いてサーバ間で通信を行って、特定のサーバで行った認証結果の情報をプライバシーを保ったまま自動的に引き継ぐことで、各サーバ等でのユーザによる再度の認証手続きを不要とするという手法がとられる。

また、例えば、特開２００９−９３５８０号公報（特許文献１）には、クライアントからユーザ認証装置へのアクセス要求を受信したときに、任意の認証用コード列を生成してクライアントへ送信する生成部と、第二のサーバが生成した応答用コード列と第一のサーバが生成した応答用コード列とを比較して、クライアントに対するユーザ認証装置へのアクセスを許可するか否かを判定する判定部とを備え、第二のサーバは、ログイン情報を共有する相手である第一のサーバにおけるユーザＩＤを持たない或いは持つ必要がない、すなわち、サーバから与えられる情報以外に、第二のサーバのユーザが第一のサーバ上の誰なのかを特定できる情報がないようにすることで、個人がある程度特定され得る個人情報の登録を要することなく、ある程度身元が保証されたユーザにそのサービスを提供できるようにするユーザ認証システムが記載されている。

特開２００９−９３５８０号公報

"Security Assertion Markup Language (SAML) v2.0"、[online]、２００５年３月１５日、ＯＡＳＩＳ（Organization for the Advancement of Structured Information Standards）、［平成２３年９月８日検索］、インターネット＜URL:http://www.oasis-open.org/standards#samlv2.0＞

社員のコミュニケーションツールとして外部のＳＮＳサービスを利用する場合、情報漏洩等の観点から、社員等の関係者のみが参加できるコミュニティやグループの中でコミュニケーションを行うよう制限するのが望ましい。この点、上記のようなＳＳＯによる認証の仕組みでは、例えば、社内システムにログインすることで、再度のログイン処理を要さずに外部のＳＮＳサービスを利用するということが可能であるものの、ＳＮＳサービスにおいて社員等の関係者のみが参加することができるようなコミュニティやグループを形成することを可能とするものではない。また、例えば、社員が自宅等で業務外にＳＮＳサービスを利用する場合は、原則として社内システムにアクセスすることができないことから、そもそも社内システムとの間でのＳＳＯの仕組み自体を利用することができない。

通常、企業等の社内システムにおいては、社員のユーザＩＤの登録・削除やグループの定義などの管理は、退職や異動等の人事情報と連携して行われている。そこで、外部のＳＮＳサービスにおいても、社内システムで管理されているユーザ情報（部署等のユーザのグループに係る情報）を利用・参照してコミュニティやグループを形成することが考えられる。しかしながら、このような形で社内のユーザ情報を外部のＳＮＳサービス（当該企業がその管理等についてコントロールすることができないサービス）に連携させることは、インフラの整備の面で負担が大きい。

そこで、外部のＳＮＳサービスにおいて、管理者等が通常の運用手順に則って、社員のみが参加することができるコミュニティやグループを直接作成するということが考えられる。この場合、社内システムのユーザ情報をＳＮＳサービスに連携させるインフラを整備する必要はない。しかしながら、この場合は、社員の人事異動等に伴ってユーザ情報に追加・変更等があった場合に、管理者等がその都度ＳＮＳサービスにおけるユーザ情報に反映させてメンテナンスする必要があるなど、管理者等の作業負担が大きく、また、反映漏れなどが生じる可能性もある。

また、この場合、管理者等は、社内における各社員のユーザＩＤと、当該社員のＳＮＳサービスにおけるユーザＩＤとの対応付けを把握しておくことで、社内でのユーザＩＤについてのグループ定義の情報に基づいて、外部のＳＮＳサービスにおけるユーザＩＤについてのグループ定義を行うことができる。このとき、例えば、管理者等が各社員に対して外部のＳＮＳサービスにおけるユーザＩＤを問い合せて聞き出した上で、社内におけるユーザＩＤと対応付けて登録するという手法では非常に効率が悪い。

一方、例えば、各社員がＳＮＳサービスで利用するユーザＩＤの情報を別途申告したり登録したりすることで社内のユーザＩＤとの対応付けを把握するという手法も考えられるが、申告漏れや虚偽の申告などにより、ＳＮＳサービスにおいて利用するユーザＩＤについての正確な情報を得ることができない。

そこで本発明の目的は、社内システム等の内部のサイトにおけるユーザＩＤと外部のサイトのＳＮＳサービス等におけるユーザＩＤとの対応を容易に取得し、また、内部のサイトにおけるユーザＩＤのグループ定義の情報を外部のサイトのＳＮＳサービスにおけるコミュニティ等を形成するユーザＩＤのグループ定義の情報に容易に反映させることが可能なグループ定義管理システムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるグループ定義管理システムは、ネットワークに接続された第１のサーバと第２のサーバ、および前記第１のサーバと前記第２のサーバのいずれにも接続可能なクライアントからなるクループ定義管理システムであって、以下の特徴を有するものである。

すなわち、前記第１のサーバは、前記第１のサーバを利用可能な各ユーザについての第１のＩＤの情報、および各ユーザのグループ定義に係る情報を保持する第１のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第１のＩＤにより当該ユーザの認証を行う第１の認証部を有し、前記第２のサーバは、前記第２のサーバを利用可能な各ユーザについての第２のＩＤの情報、および各ユーザのグループ定義に係る情報を保持する第２のユーザ管理テーブルと、前記クライアントを介したユーザからの要求に応じて前記第２のＩＤにより当該ユーザの認証を行い、また、指定されたユーザが前記第２のサーバの正当な利用者であるかの問い合わせに対して、正当な利用者である場合には前記第２のユーザ管理テーブルから取得した当該ユーザについての前記第２のＩＤの情報を応答する認証インタフェースを有する第２の認証部とを有する。

また、前記第１のサーバは、さらに、前記第１の認証部による認証を受けたユーザが利用する前記クライアントからの要求に応じて、前記第２のサーバに対して当該ユーザが前記第２のサーバの正当な利用者であるかの問い合わせを行い、前記第２のサーバから応答された当該ユーザについての前記第２のＩＤを、当該ユーザについての前記第１のＩＤと関連付けて前記ユーザ管理テーブルに登録する認証連携部を有することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、社内システム等の内部のサイトにおけるユーザＩＤと外部のサイトのＳＮＳサービス等におけるユーザＩＤとの対応を容易に取得することが可能となる。また、内部のサイトにおけるユーザＩＤのグループ定義の情報を外部のサイトのＳＮＳサービス等におけるコミュニティやグループを形成するグループ定義の情報に容易に反映させることが可能となる。これらにより、外部のサイトのＳＮＳサービス等において、社員など内部のサイトの特定のユーザのみがメンバーとして参加することができ、社内コミュニケーションを行うことが可能なコミュニティやグループを容易に形成することが可能となる。

本発明の一実施の形態であるグループ定義管理システムの構成例について概要を示した図である。 本発明の一実施の形態における内部サーバが外部サーバから対応するユーザの外部ＩＤの情報を取得して登録する際の処理の流れの例について概要を示した図である。 本発明の一実施の形態における内部サーバでの内部ＩＤのグループ定義の情報に基づいて外部サーバにおける外部ＩＤのグループ定義を更新する際の処理の流れの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態であるグループ定義管理システムは、企業等において外部のＳＮＳサービス等を社内コミュニケーション用に活用することを可能とするため、外部のＳＮＳサービス等において特定のグループの社員等のみが参加することができるコミュニティやグループを形成することを支援するシステムである。

本実施の形態では、社内システム等の内部サイトにおける各ユーザ（社員等）のユーザＩＤ（内部サイトでのユーザＩＤであり、以下では「内部ＩＤ」と記載する場合がある）と、ＳＮＳサービス等の外部サイトにおいて各ユーザが利用するユーザＩＤ（外部サイトでのユーザＩＤであり、以下では「外部ＩＤ」と記載する場合がある）との対応関係を容易に取得可能とする。

これにより、内部サイトの管理者等が、社内等における部署やプロジェクト等に基づくユーザ（社員）のグループ定義に基づいて、ＳＮＳサービス等の外部サイト（内部サイトの企業等が管理や運用を原則としてコントロールできないサイトを含む）において、対応するユーザ（社員）のみが参加することができるクローズドのコミュニティやグループを形成し、またこれに含まれるメンバーの情報をメンテナンスすることを支援する。外部サイトが、ユーザのグループ定義の操作に係るコマンドやＡＰＩ（Application Programming Interface）等の外部インタフェースを有している場合は、これらを利用して自動的に外部サイトにおけるグループ定義の処理を行うことも可能である。

内部サイトは、社員等の各ユーザについて、外部サイトから対応する外部ＩＤの情報を取得する。ここで、外部サイトは外部インタフェースとして認証ＡＰＩを有しており、内部サイトはこれを利用して外部ＩＤの情報を取得するものとする。ここでの認証ＡＰＩは、ユーザＩＤとパスワードを指定して認証処理を行うものではなく、対象のユーザが、当該サイト（外部サイト）における正当な利用者であるか否かを応答するものであり、この応答内容には、対象のユーザの外部ＩＤの情報が含まれる。認証ＡＰＩは、他のＷｅｂサイトと認証情報を連携して動作することが想定されるＳＮＳサービスなどでは、細かな実装方法は異なるものの、一般的に有するインタフェースである。

通常は、当該認証ＡＰＩは、Ｗｅｂサイト間の連携においていわゆるＳＳＯを実現するために用いられる。例えば、あるＷｅｂサイトＡ（例えば交流ゲームサイト）での認証システムが、他のＷｅｂサイトＢ（例えば提携するＳＮＳサイト）が有する認証ＡＰＩを利用して、対象のユーザがＷｅｂサイトＢにおいて何らかの権限を持っていることを確認できれば利用を許可する、というような場合に用いられる。なお、ここでの利用は、ＷｅｂサイトＢではなくＷｅｂサイトＡの利用が対象となる。

従って、従来の認証ＡＰＩの利用形態は、ＷｅｂサイトＡにこれからログインするという状況で、ＷｅｂサイトＢの認証情報を取得するために用いられるものである。これに対し、本実施の形態では、後述するように、内部サイト、外部サイト双方に既にログインしている状態で、さらに、外部サイトから認証情報（外部サイトでログインしている外部ＩＤの情報が含まれる）を取得するために用いるという点が異なっている。

＜システム構成＞
図１は、本発明の一実施の形態であるグループ定義管理システムの構成例について概要を示した図である。グループ定義管理システム１は、例えば、企業における社内システム等の内部サイトを構成するサーバシステムである内部サーバ１０が、社内ＬＡＮ（Local Area Network）等の内部ネットワーク３０に接続される構成と、Ｆａｃｅｂｏｏｋ等のＳＮＳサービスからなる外部サイトを構成するサーバシステムである外部サーバ２０が、インターネット等の外部ネットワーク４０に接続される構成とを有する。

内部ネットワーク３０には、社員等のユーザが業務上利用するＰＣ（Personal Computer）等の情報処理端末である内部クライアント６１が接続され、外部ネットワーク４０には、社員等が自宅などで個人として利用するＰＣ等からなる外部クライアント６２が接続されている。なお、内部クライアント６１からは、内部ネットワーク３０に対するアクセスが可能であるとともに、ゲートウェイサーバ５０等を介して外部ネットワーク４０に対するアクセスも可能であるものとする。また、外部クライアント６２からは、原則として外部ネットワーク４０に対するアクセスのみが可能であるが、例えば、ＶＰＮ（Virtual Private Network）などを利用して、ゲートウェイサーバ５０を介して内部ネットワーク３０に対するアクセスを可能とするように構成してもよい。

内部サーバ１０は、社内システム等の内部サイトを構成するサーバシステムであり、例えば、図示しないＯＳ（Operating System）やＷｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアプログラムとして実装される内部認証部１１、内部サイトアプリケーション１２、認証連携部１３、およびグループ管理部１４などの各部を有する。また、データベース等により構成される内部ユーザ管理テーブル１５を有する。

この内部ユーザ管理テーブル１５は、内部サーバ１０（内部サイト）にアクセスして内部サイトアプリケーション１２によるサービス（社内システム）を利用することができる社員等のユーザに係るユーザ情報を保持する。ユーザ情報には、例えば、ユーザＩＤ（内部ＩＤ）やパスワード等の他に、各ユーザが属する部署やプロジェクト、社内活動などのグループやコミュニティの情報であるグループ定義の情報が含まれる。

内部認証部１１は、内部クライアント６１（もしくは外部クライアント６２）を介して社員等のユーザが内部サーバ１０（内部サイト）にアクセスする際のログイン認証に係る処理を行う。このとき、内部ＩＤやパスワード等のユーザ情報を得るため、内部ユーザ管理テーブル１５を参照する。

内部サイトアプリケーション１２は、内部サイトで提供するサービスに係る処理を行うアプリケーションプログラムである。例えば、図示しないＷｅｂサーバプログラム上で稼働するＷｅｂアプリケーションとして実装され、ユーザは、内部クライアント６１（もしくは外部クライアント６２）上の図示しないＷｅｂブラウザを利用して内部サイトアプリケーション１２により提供されるサービスを利用することができる。

認証連携部１３は、内部認証部１１を介してログインしたユーザについて、外部サーバ２０（外部サイト）との間で上述した認証ＡＰＩを用いて認証情報の連携を行い、当該ユーザの外部サーバ２０におけるユーザＩＤ（外部ＩＤ）に係る情報を取得する。取得した外部ＩＤの情報は、当該ユーザの内部ＩＤの情報と対応付けて内部ユーザ管理テーブル１５に登録する。すなわち、内部ユーザ管理テーブル１５では、社員等のユーザについて、ユーザ情報として、社内システムで用いる内部ＩＤと、外部のＳＮＳサービスを利用する際に用いる外部ＩＤとの対応関係についても保持する。

なお、各社員等のユーザは、原則として全員が内部ＩＤを有するが、外部ＩＤについては、ユーザによっては外部のＳＮＳサービスを利用しないために有していない、もしくは社内コミュニケーション用には利用せず、個人的利用のみとすることから、登録されない場合もある。また、外部のＳＮＳサービスで複数のユーザＩＤを有するユーザについては、社内コミュニケーションのために用いる外部ＩＤのみ（複数であってもよい）が登録されるものとする。

グループ管理部１４は、内部ユーザ管理テーブル１５での内部ＩＤのグループ定義の情報に基づいて、対応する外部ＩＤのグループ定義についてのメンテナンス情報（グループの新規追加や、削除、変更などの指示情報）を出力する。当該メンテナンス情報に基づいて、例えば、管理者等が、外部サーバ２０に対してコミュニティやグループの新規追加や削除、変更、およびこれらのコミュニティやグループに対する外部ＩＤの新規追加や削除、変更などのグループ定義に係るメンテナンス処理を行うことができる。なお、外部サーバ２０が、ユーザ情報のメンテナンスを行うためのコマンドやＡＰＩ等の外部インタフェースを有している場合は、これらを利用してメンテナンス情報に基づいて外部サーバ２０における外部ＩＤのグループ定義についてのメンテナンス処理を自動的に行うことも可能である。

外部サーバ２０は、ＳＮＳサービス等の外部サイトを構成するサーバシステムであり、内部サーバ１０と同様に、例えば、図示しないＯＳやＷｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアプログラムとして実装される外部認証部２１、外部サイトアプリケーション２２、およびユーザ管理インタフェース（Ｉ／Ｆ）２３などの各部を有する。また、データベース等により構成される外部ユーザ管理テーブル２４を有する。この外部ユーザ管理テーブル２４は、外部サーバ２０（外部サイト）にアクセスして外部サイトアプリケーション２２によるＳＮＳサービスを利用することができるユーザについての、外部ＩＤやパスワード等を含むユーザ情報を保持する。

外部認証部２１は、外部クライアント６２もしくは内部クライアント６１を介して社員等のユーザが外部サーバ２０（外部サイト）にアクセスしてＳＮＳサービスを利用する際のログイン認証に係る処理を行う。このとき、外部ＩＤやパスワード等のユーザ情報を得るため、外部ユーザ管理テーブル２４を参照する。なお、外部認証部２１は、ＡＰＩ等による外部インタフェースとして、上述した認証ＡＰＩを有するものとする。

外部サイトアプリケーション２２は、外部サイトで提供するＳＮＳサービスに係る処理を行うアプリケーションプログラムである。例えば、図示しないＷｅｂサーバプログラム上で稼働するＷｅｂアプリケーションとして実装され、ユーザは、内部クライアント６１もしくは外部クライアント６２上の図示しないＷｅｂブラウザを利用して外部サイトアプリケーション２２により提供されるＳＮＳサービスを利用する。なお、本実施の形態では、外部サイトによって提供されるサービスをＳＮＳサービスとしているが、これに限られず、社員等以外の多数のユーザが利用し、ユーザ毎にグループ等が形成されるようなサービスであれば適用することができる。

ユーザ管理インタフェース（Ｉ／Ｆ）２３は、外部ユーザ管理テーブル２４に登録され管理されているユーザＩＤや、ＳＮＳサービスにおけるグループやコミュニティなどのグループ定義の情報などを含むユーザ情報を管理（参照、登録、削除、変更等）するためのコマンドや、ＡＰＩなどの公開された外部インタフェースである。当該インタフェースは、例えば、管理者等の特定のユーザがログインした上で利用可能なものであってもよいし、ユーザを介さずに鍵やパスワード等を用いて直接アクセス可能なものであってもよい。なお、外部サーバ２０によってはこのようなプログラムやスクリプト等から利用可能なインタフェースを有さず、Ｗｅｂブラウザ等での操作による手動でのインタフェースしか有していないなどの場合もあるが、そのような外部サーバ２０であっても適用することができる。

＜処理の流れ（外部ＩＤ情報取得）＞
以下では、内部サーバ１０が、外部サーバ２０から、特定のユーザについての当該外部サーバ２０において社内コミュニケーションのために使用する外部ＩＤの情報を取得し、内部ＩＤと対応付けて内部ユーザ管理テーブル１５に登録する際の処理について説明する。

図２は、内部サーバ１０が外部サーバ２０から対応するユーザの外部ＩＤの情報を取得して登録する際の処理の流れの例について概要を示した図である。まず、内部クライアント６１（もしくは外部クライアント６２）は、Ｗｅｂブラウザを介して社員等のユーザから外部サーバ２０に対する外部ＩＤ（図２の例ではユーザ“α”）を指定したログイン要求を受け付け（Ｓ０１）、外部サーバ２０に対してユーザ“α”のログイン要求を送信する（Ｓ０２）。ログイン要求を受信した外部サーバ２０では、外部認証部２１により外部ユーザ管理テーブル２４を参照して認証処理を行い（Ｓ０３）、Ｗｅｂサーバプログラムによりユーザ“α”の当該セッションについてのセッション情報を生成して、認証結果とともに内部クライアント６１に応答する。

さらに、内部クライアント６１（もしくは外部クライアント６２）は、同様に、Ｗｅｂブラウザを介して社員等のユーザから内部サーバ１０に対する内部ＩＤ（図２の例ではユーザ“Ａ”）を指定したログイン要求を受け付け（Ｓ０４）、内部サーバ１０に対してユーザ“Ａ”のログイン要求を送信する（Ｓ０５）。ログイン要求を受信した内部サーバ１０では、内部認証部１１により内部ユーザ管理テーブル１５を参照して認証処理を行い（Ｓ０６）、Ｗｅｂサーバプログラムによりユーザ“Ａ”の当該セッションについてのセッション情報を生成して、認証結果とともに内部クライアント６１に応答する。

なお、以降の処理では、内部クライアント６１は、内部サーバ１０へのアクセス（外部サーバ２０へのアクセスについても同様）の際に当該セッション情報“Ａ”を提示することで、当該アクセスが、ユーザ“Ａ”として認証されているユーザによるものであることを示すものとするが、これに限らず、例えば、内部サーバ１０に対してアクセスする毎に内部ＩＤとパスワードを提示したり、公開鍵（例えばクライアント証明書等）による認証を行うような方式であってもよい。

その後、自動もしくはユーザからの指示に基づいて、内部クライアント６１は、内部サーバ１０に対して、外部サーバ２０における外部ＩＤの取得要求を送信する（Ｓ０７）。外部ＩＤの取得要求を受信した内部サーバ１０では、当該アクセスに伴う情報（セッション情報“Ａ”等）により、アクセスしているユーザがユーザ“Ａ”であることを確認できる状況で、認証連携部１３により、外部サーバ２０に対して外部ＩＤの取得要求（認証ＡＰＩの実行要求）を送信する（Ｓ０８）。

ここでは、認証連携部１３は、例えば特許文献１や非特許文献１などの従来技術における認証の連携の手法と同様に、例えば、予め内部サーバ１０と外部サーバ２０との間でシェアされた鍵等の情報に基づいて、チャレンジアンドレスポンス方式によるチャレンジとして外部ＩＤの取得要求を生成する。生成した取得要求は、例えば、内部クライアント６１上のＷｅｂブラウザでのリダイレクトにより間接的に外部サーバ２０に対して送信される。

外部ＩＤの取得要求を受信した外部サーバ２０では、外部認証部２１により、対象のユーザが外部サーバ２０上において正当なユーザであるか否かを確認するための認証ＡＰＩを発行する。このとき、対象のユーザが外部サーバ２０に既にログインしている場合は、外部サーバ２０は、当該アクセスに伴う情報（セッション情報“α”等）により、当該ユーザに何ら問い合わせることなく、内部サーバ１０に対して応答を返すことも技術的には可能であるが、外部サーバ２０にログインしていない場合は、例えば、ログインを促したり、「内部サイトから問い合わせがきている」旨を当該ユーザに通知するとともに、当該ユーザの外部サーバ２０上での権限に係る情報を内部サーバ１０に送信することに対して諾否を確認するようにしてもよい。

本実施の形態では、外部サーバ２０は、当該アクセスにおいて、対象のユーザの情報（セッション情報“α”等）が得られているため、当該ユーザはユーザ“α”であることが分かっていることになる。従って、例えば、内部サーバ１０からの問い合わせに対して、外部ＩＤ（ユーザ“α”）に係る情報の提供を承認するか否かをＷｅｂブラウザ上での表示を介してユーザに問い合わせ（Ｓ０９）、承認を得るようにしてもよい（Ｓ１０）。

セッション情報“α”の情報を受信した外部サーバ２０の外部認証部２１は、セッション情報“α”に基づいて、対応する外部ＩＤ（ユーザ“α”）の情報を含む認証情報を取得し（Ｓ１１）、セッション情報“α”に対応するユーザの外部ＩＤはユーザ“α”であることの証明情報を内部サーバ１０に対して送信する。ここでも、例えば、内部クライアント６１上のＷｅｂブラウザでのリダイレクトにより、内部サーバ１０に対して間接的にユーザ“α”であることの証明情報を送信する。

なお、内部サーバ１０と外部サーバ２０との間で直接通信を行うことで、より詳細な情報を受け渡したり、また、外部サーバ２０から見て内部サーバ１０がこれらの情報の受け渡しについて許可するよう設定されているものであるか否かを確認するようにしてもよい。これにより、例えば、外部サーバ２０において、事前に登録されたサーバにのみ応答するよう制限が設けられているような場合であっても対応することが可能となる。

外部ＩＤがユーザ“α”であることの証明情報を受信した内部サーバ１０では、認証連携部１３により、取得した外部ＩＤの情報を、内部ＩＤの情報と対応付けて内部ユーザ管理テーブル１５に登録する（Ｓ１２）。これにより、内部ユーザ管理テーブル１５において、業務上使用する内部ＩＤ（ユーザ“Ａ”）と外部ＩＤ（ユーザ“α”）との対応関係について把握することが可能となる。なお、上記の一連の処理は、外部サイトのＳＮＳサービス等において、社内コミュニケーションを行うコミュニティ等への参加を希望するユーザ（社員）のみ行えばよい。

なお、上記の例では、ユーザが先に外部サーバ２０（外部サイト）にログインし（ステップＳ０１〜Ｓ０３）、その後に内部サーバ１０（内部サイト）にログインする（ステップＳ０４〜Ｓ０６）順となっているが、各サーバ（サイト）へのログインの順序は逆であってもよい。また、ステップＳ０７で内部クライアント６１が内部サーバ１０に対して外部ＩＤの取得要求を送信する前に、外部サーバ２０に対するログインが行われていない（ステップＳ０１〜Ｓ０３に相当する処理が行われていない）状態であってもよい。このときは、例えば、ステップＳ０９〜Ｓ１０での処理に代えて、外部サーバ２０に対するログイン処理（ステップＳ０１〜Ｓ０３に相当する処理）を内部クライアント６１に対して要求して行うようにしてもよい。

また、内部サーバ１０の認証連携部１３から外部サーバ２０に対して外部ＩＤを問い合わせる手法についても種々のものがあり、これらを適宜利用することができる。例えば、上記の例のように外部サーバ２０が認証情報の連携のために認証ＡＰＩを提供しており、これを内部サーバ１０から利用する方式に限らず、例えば、ＳＳＯの仕組みを利用して、単純に内部サーバ１０の認証連携部１３経由で外部サーバ２０に対してログインする構成とすることで、その際に外部ＩＤを取得するという方式をとることも可能である。

＜処理の流れ（グループ定義情報のメンテナンス）＞
以下では、内部サーバ１０が、上述の図２に示した処理により、内部ＩＤと外部ＩＤとの対応関係を把握した後、内部サーバ１０側（内部サイト）における社員の人事情報等に基づく内部ＩＤのグループ定義の更新情報（新規追加、削除、変更等）に基づいて、外部サーバ２０（外部サイト）における外部ＩＤのグループ定義（グループやコミュニティの形成）をメンテナンスして、内部ＩＤのグループ定義の情報を外部サーバ２０における外部ＩＤのグループ定義に自動的に反映させる際の処理について説明する。

図３は、内部サーバ１０での内部ＩＤのグループ定義の情報に基づいて外部サーバ２０における外部ＩＤのグループ定義を更新する際の処理の流れの例について概要を示した図である。まず、図２に示した処理におけるステップＳ０１〜Ｓ０６の処理と同様に、内部クライアント６１（もしくは外部クライアント６２）は、Ｗｅｂブラウザを介した社員等のユーザからのログイン要求を受けて、外部サーバ２０および内部サーバ１０の双方に対してログイン処理を行い、セッション情報（“α”および“Ａ”）を取得する（Ｓ２１〜Ｓ２６）。なお、ここでのユーザは、外部サーバ２０におけるユーザのグループ定義（グループやコミュニティの形成）について管理権限のあるユーザである。

その後、自動もしくはユーザからの指示に基づいて、内部クライアント６１は、内部サーバ１０に対して、セッション情報“Ａ”およびセッション情報“α”に基づく外部サーバ２０へのアクセスのための鍵類ともに、外部サーバ２０におけるグループ定義の更新要求を送信する（Ｓ２７）。グループ定義の更新要求を受信した内部サーバ１０では、セッション情報“Ａ”を確認した上で、グループ管理部１４により、外部サーバ２０に対して現状のグループ定義の取得要求を送信する（Ｓ２８）。

ここでは、グループ管理部１４は、例えば、外部サーバ２０のユーザ管理Ｉ／Ｆ２３を直接呼び出すことにより、グループ定義の取得要求を行う。なお、例えば、内部クライアント６１上のＷｅｂブラウザを介して自動で画面を切り替えてデータを受け渡す等の処理により、間接的に外部サーバ２０に対して要求を送信するなど、他の方式をとることも可能である。外部ＩＤのグループ定義の取得要求を受信した外部サーバ２０では、ユーザ管理Ｉ／Ｆ２３により、外部ユーザ管理テーブル２４から現状の外部ＩＤのグループ定義情報を取得し（Ｓ２９）、これを内部サーバ１０に対して送信する。

現状の外部ＩＤのグループ定義情報を受信した内部サーバ１０では、グループ管理部１４により、現状の外部ＩＤのグループ定義情報と、内部ユーザ管理テーブル１５のグループ定義情報との比較に基づいて、その差分から、外部ＩＤのグループ定義についての更新情報（グループやコミュニティ、およびそのメンバーについての新規追加、削除、変更等に係る情報）を生成する（Ｓ３０）。

その後、内部サーバ１０のグループ管理部１４は、グループ定義の更新情報とともに、外部サーバ２０に対してグループ定義の更新要求を送信する（Ｓ３１）。ここでも上記と同様に、例えば、外部サーバ２０のユーザ管理Ｉ／Ｆ２３を直接呼び出すことにより、グループ定義の更新要求を行う。なお、例えば、内部クライアント６１上のＷｅｂブラウザを介して自動で画面を切り替えてデータを受け渡す等の処理により、間接的に外部サーバ２０に対して要求を送信するなど、他の方式をとることも可能である。

外部ＩＤのグループ定義の更新要求を受信した外部サーバ２０では、グループ定義の更新情報に基づいて、ユーザ管理Ｉ／Ｆ２３により、外部ユーザ管理テーブル２４に対してグループ定義の更新の登録を行う（Ｓ３２）。以上のような処理により、管理権限のあるユーザがログインした際に、外部サーバ２０における管理対象のグループやコミュニティの現状のグループ定義について、内部サーバ１０におけるグループ定義（社内の人事情報等に基づいて適宜更新される）と比較して最新の状態であるかチェックし、最新の状態となるよう、外部サーバ２０におけるグループ定義に自動で反映させることが可能となる。

なお、図３に示した例では、外部サーバ２０がユーザ管理Ｉ／Ｆ２３を有しているため、これを利用して自動で外部ユーザ管理テーブル２４における外部ＩＤのグループ定義を更新することが可能であるが、外部サーバ２０がこのような外部インタフェースを有さず、Ｗｅｂブラウザ等での操作による手動でのインタフェースしか有していない場合は、管理権限を有するユーザがこれを利用して手動でグループ定義を更新するようにしてもよい。また、例えば、グループ定義の更新情報からなるＣＳＶ（Comma Separated Values）ファイル等を外部サーバ２０にアップロードして反映させるというようなインタフェースでも対応することが可能である。

また、図３に示した例以外にも、上述したように、例えば、ユーザ管理Ｉ／Ｆ２３が、ユーザを介さずに直接アクセスして外部ユーザ管理テーブル２４のメンテナンスを可能とするようなインタフェースである場合は、直接アクセスするための鍵やパスワードなどの情報を内部サーバ１０にて予め保持しておき、内部サーバ１０が定期的に外部サーバ２０にアクセスしてグループ定義の更新・メンテナンスを行うという方式をとることも可能である。

以上に説明したように、本発明の一実施の形態であるグループ定義管理システム１によれば、社内システム等の内部サーバ１０（内部サイト）における内部ＩＤと外部サーバ２０（外部サイト）のＳＮＳサービス等における外部ＩＤとの対応を容易に取得することが可能となる。また、内部サーバ１０における内部ＩＤに基づくグループ定義の情報を外部サーバ２０のＳＮＳサービス等におけるコミュニティやグループを形成するグループ定義の情報に容易に反映させることが可能となる。

これらにより、企業等が原則としてコントロールすることができない外部サーバ２０上のＳＮＳサービス等において、社員など内部サーバ１０の特定のユーザのみがメンバーとして参加することができ、社内コミュニケーションを行うことが可能なコミュニティやグループを容易に形成することが可能となる。また、一度外部サーバ２０（外部サイト）においてコミュニティやグループが形成されれば、以降は、グループ定義のメンテナンス時以外は、外部サイトに対するアクセスのみで（内部サイトへの接続を要さず）コミュニケーションを行うことができる。また、当該コミュニティでは、業務外での社内コミュニケーションであることが明確となる一方、メンバーは全て社員であることが保証されるため、安心してコミュニケーションを行うことができる。

また、社内における人事異動や退職等に伴う社内でのグループ定義の変更を、自動で外部サーバ２０（外部サイト）におけるグループ定義に確実に反映させることができる。また、部署などの人事情報に係るグループだけではなく、社員の属性情報や、プロジェクト、社内活動テーマ毎のグループなどについても容易に自動で形成することができ、かつ、必要最低限の適切なメンバーに限定する（外部サイトにおける自由なグループやコミュニティの形成を制限する）ことができる。

また、社員の申告や申請等によらず、システム的に当該社員の外部ＩＤの情報を取得するため、外部サイトにおけるユーザ（内部サイト側で把握している外部ＩＤの所有者）が本人（社員）であるか否かを確実に把握することができる。また、外部ＩＤの情報だけにとどまらず、外部サーバ２０（外部サイト）における社員等の活動実績に係る情報を内部サーバ１０（内部サイト、社内システム）側に取り込んで活用するというような利用方法も可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、本実施の形態では、上述したように、外部サーバ２０（例えばＦａｃｅｂｏｏｋ等の外部サイト）上での外部ＩＤの情報を取得して、内部サーバ１０（例えば社内システム等の内部サイト）における内部ＩＤと関連付けることで、内部ＩＤでのグループ定義の情報を外部ＩＤでのグループ定義に反映させることを可能とするものであるが、グループ定義を反映させるサーバ（サイト）間の関係はこれに限らない。

変形例として、例えば、外部ＩＤの情報を取得する先が、外部サーバ２０（例えばＦａｃｅｂｏｏｋ等の外部のＳＮＳサイト）ではなく、外部サーバ２０とユーザ情報を連携して稼働する他の外部サイト（例えば、Ｆａｃｅｂｏｏｋ等のＳＮＳサービスと連携して稼働するソーシャルゲームサイト等。同一の外部サーバ２０上のものでも別の外部サーバ２０上のものでもよい）から、ユーザＩＤ（外部ＩＤ）やこれに基づいて特定される情報を取得する構成とすることも可能である。また、これに対応して、内部ＩＤでのグループ定義の情報を反映させる先も、外部サーバ２０（例えばＦａｃｅｂｏｏｋ等の外部のＳＮＳサイト）ではなく、上記の他の外部サイト（ソーシャルゲームサイト等）とすることも可能である。

上記の例は、例えば、外部サーバ２０（例えばＦａｃｅｂｏｏｋ等のＳＮＳサービス）が、グループ定義の情報を自動で行うことを可能とするユーザ管理Ｉ／Ｆ２３を有していないような場合に、これとユーザ情報を連携する外部サイト（例えば、内部サーバ１０を運営する企業が開発・運用しているソーシャルゲームサイト等）が、ユーザ管理Ｉ／Ｆ２３を有することができ、かつ、グループ定義を管理したいのは当該外部サイトの方であるような場合に適用することができる。この場合、当該外部サイト（ソーシャルゲームサイト等）にアクセスするユーザは、外部サーバ２０（Ｆａｃｅｂｏｏｋ等のＳＮＳサービス）によるユーザ認証を利用するが、当該外部サイトでのグループ定義には内部サーバ１０でのグループ定義が反映されるということになる。

また、別の変形例として、例えば、外部サーバ２０（例えばＦａｃｅｂｏｏｋ等の外部のＳＮＳサイト）での外部ＩＤの情報およびそのグループ定義の情報を内部サーバ１０が取得して、これに基づいて他の外部サイト（例えばＦａｃｅｂｏｏｋ等のＳＮＳサービスと連携して稼働するソーシャルゲーム等。同一の外部サーバ２０上のものでも別の外部サーバ２０上のものでもよい）のユーザ登録やグループ定義に反映させる構成とすることも可能である。

本発明は、社内システム等の内部サイトとＳＮＳサービス等の外部サイトとの間でユーザグループのメンバーの情報を連携するグループ定義管理システムに利用可能である。

１…グループ定義管理システム、
１０…内部サーバ、１１…内部認証部、１２…内部サイトアプリケーション、１３…認証連携部、１４…グループ管理部、１５…内部ユーザ管理テーブル、
２０…外部サーバ、２１…外部認証部、２２…外部サイトアプリケーション、２３…ユーザ管理インタフェース（Ｉ／Ｆ）、
３０…内部ネットワーク、
４０…外部ネットワーク、
５０…ゲートウェイサーバ、
６１…内部クライアント、６２…外部クライアント。

Claims (5)

1. ネットワークに接続された第１のサーバと第２のサーバ、および前記第１のサーバと前記第２のサーバのいずれにも接続可能なクライアントからなるクループ定義管理システムであって、
   前記第１のサーバは、前記第１のサーバを利用可能な各ユーザについての第１のＩＤの情報、および各ユーザのグループ定義に係る情報を保持する第１のユーザ管理テーブルと、
   前記クライアントを介したユーザからの要求に応じて前記第１のＩＤにより当該ユーザの認証を行う第１の認証部を有し、
   前記第２のサーバは、前記第２のサーバを利用可能な各ユーザについての第２のＩＤの情報、および各ユーザのグループ定義に係る情報を保持する第２のユーザ管理テーブルと、
   前記クライアントを介したユーザからの要求に応じて前記第２のＩＤにより当該ユーザの認証を行い、また、指定されたユーザが前記第２のサーバの正当な利用者であるかの問い合わせに対して、正当な利用者である場合には前記第２のユーザ管理テーブルから取得した当該ユーザについての前記第２のＩＤの情報を応答する認証インタフェースを有する第２の認証部とを有し、
   前記第１のサーバは、さらに、
   前記第１の認証部による認証を受けたユーザが利用する前記クライアントからの要求に応じて、前記第２のサーバに対して当該ユーザが前記第２のサーバの正当な利用者であるかの問い合わせを行い、前記第２のサーバから応答された当該ユーザについての前記第２のＩＤを、当該ユーザについての前記第１のＩＤと関連付けて前記第１のユーザ管理テーブルに登録する認証連携部を有することを特徴とするグループ定義管理システム。
2. 請求項１に記載のグループ定義管理システムにおいて、
   前記第２のサーバの前記第２の認証部は、指定されたユーザが前記第２のサーバの正当な利用者であるかの問い合わせを受けた際に、当該ユーザが前記第２の認証部による認証を受けていない場合は、前記クライアントを介して当該ユーザに対して前記第２のサーバに対する認証処理を行うよう要求することを特徴とするグループ定義管理システム。
3. 請求項１または２に記載のグループ定義管理システムにおいて、
   前記第１のサーバは、さらに、前記第１のユーザ管理テーブルにおける前記第１のＩＤについてのグループ定義の変更内容に基づいて、前記第２のＩＤについてのグループ定義を更新するための更新情報を生成するグループ管理部を有することを特徴とするグループ定義管理システム。
4. 請求項３に記載のグループ定義管理システムにおいて、
   前記第２のサーバは、さらに、前記第２のユーザ管理テーブルにおける前記第２のＩＤについてのグループ定義を管理するためのユーザ管理インタフェースを有し、
   前記第１のサーバの前記グループ管理部は、前記更新情報に基づいて、前記第２のサーバの前記ユーザ管理インタフェースにより、前記第２のユーザ管理テーブルにおける前記第２のＩＤについてのグループ定義を更新することを特徴とするグループ定義管理システム。
5. 請求項４に記載のグループ定義管理システムにおいて、
   前記第１のサーバの前記グループ管理部は、前記第２のサーバの前記第２のユーザ管理テーブルにおける前記第２のＩＤについてのグループ定義を管理する権限を有するユーザが、前記第１のサーバの前記第１の認証部により認証を受けた後、当該ユーザが利用する前記クライアントからの要求に応じて、前記第２のサーバの前記ユーザ管理インタフェースにより、前記第２のユーザ管理テーブルにおける前記第２のＩＤについての現状のグループ定義の情報を取得し、取得した現状のグループ定義の情報と、前記第１のユーザ管理テーブルにおけるグループ定義の情報とに基づいて前記更新情報を生成することを特徴とするグループ定義管理システム。
   
   
   
   
   

Images