(57)【要約】      （修正有）【課題】複数の認証基盤を持つ企業でもクラウドサービスと認証連携が可能なシステムを提供する。【解決手段】クラウドサービスと接続する認証システムであって、ユーザＩＤが登録された複数の認証基盤サーバ１１１と、ユーザ端末２０１から入力されたユーザＩＤと一致するユーザＩＤの登録された認証基盤サーバ１１１を特定する情報を、クラウドサービスから取得し、前記特定する情報に基づき、認証基盤サーバ１１１から入力されたユーザＩＤの登録情報を取得するデータ連携サーバ２０３とを備えた。【選択図】図２
2017004296.tif 000002
【特許請求の範囲】
【請求項１】
クラウドサービスと接続する認証システムであって、
ユーザＩＤが登録された複数の認証基盤サーバと、
入力されたユーザＩＤと一致するユーザＩＤの登録された認証基盤サーバを特定する情報を、前記クラウドサービスから取得し、前記特定する情報に基づき、前記認証基盤サーバから前記入力されたユーザＩＤの登録情報を取得するデータ連携サーバと
を備えたことを特徴とする認証システム。
【請求項２】
前記データ連携サーバは、
前記クラウドサービスへ代理認証を要求して、認証情報を前記クラウドサービスから受信し、前記受信した認証情報を前記認証基盤サーバへ送信して、認証結果を前記認証基盤サーバから受信し、前記受信した認証結果を前記クラウドサービスへ送信すること
を特徴とする請求項１に記載の認証システム。
【請求項３】
前記データ連携サーバは、
前記入力されたユーザＩＤを前記クラウドサービスへ送信し、前記送信されたユーザＩＤに対応するクラウドＩＤを前記特定する情報とともに前記クラウドサービスから取得し、前記取得されたクラウドＩＤからユーザＩＤと同じ形式のＩＤへ変換し、前記変換されたＩＤを前記クラウドサービスへ送信して前記代理認証を要求すること
を特徴とする請求項２に記載の認証システム。
【請求項４】
前記データ連携サーバは、
前記入力されたユーザＩＤおよび入力されたパスワードを、前記特定する情報に基づき、前記認証基盤サーバへ送信して、前記認証基盤サーバから前記入力されたユーザＩＤの登録情報を取得し、
前記認証基盤サーバは、
ユーザＩＤと対応するパスワードが登録され、前記データ連携サーバから送信されたユーザＩＤおよびパスワードと一致するユーザＩＤおよびパスワードが登録されているか否かの前記登録情報を前記データ連携サーバへ送信すること
を特徴とする請求項３に記載の認証システム。
【請求項５】
クラウドサービスと接続するシステムの認証方法であって、
入力されたユーザＩＤを前記クラウドサービスへ送信し、
前記入力されたユーザＩＤの登録されている認証基盤サーバを特定する情報を前記クラウドサービスから受信し、
前記特定された情報に基づき、前記認証基盤サーバへユーザＩＤを送信し、
前記ユーザＩＤの登録状態を前記認証基盤サーバから受信すること
を特徴とする認証方法。
【請求項６】
前記クラウドサービスへ代理認証を要求し、
前記クラウドサービスから認証情報を受信し、
前記受信した認証情報を前記認証基盤サーバへ送信し、
認証結果を前記認証基盤サーバから受信すること
を特徴とする請求項５に記載の認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証システムおよび認証方法に関するものである。
【背景技術】
【０００２】
近年、利用検討の開始からサービスインまでの期間が非常に短いことや、導入コストが安価であることなどのメリットから、クラウドサービスを利用する企業が増加している。一般的に、クラウドサービスを利用する場合はクラウドサービスを利用するためのユーザＩＤやパスワードなどの、ログイン情報をクラウドサービス側で管理し、その情報を用いてクラウドサービスへログインする。
【０００３】
しかし、多くの企業はクラウドサービスの利用よりも前に、社内にＩＴシステムを導入している。そのシステム利用者である社員は社内のシステムへログインするためのログイン情報が与えられている。そのため、新たにクラウドサービス用のログイン情報が増えると、日常的に利用する社内システムへのログイン情報とは別のログイン情報の管理が必要になり、利用者一人ひとりのログイン情報管理が煩雑になる。
【０００４】
そこで、特許文献１に記載された技術の様に、クラウドサービスと社内の認証基盤を連携し、社内のＩＴシステムで利用しているログイン情報を利用してクラウドサービスにログインする仕組みもある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−８１４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載された技術を用いれば、複数のログイン情報を管理する必要がなくなる。しかしながら、特許文献１に記載された技術は、１つの企業で複数の認証基盤を持つ場合の対策については記載されていない。近年の企業は、国外を含めて複数の拠点を有しており、拠点ごとに異なる認証基盤を利用していることも多い。また、Ｍ＆Ａなどで企業が統合されることによって、表向きは１つの企業であっても、内部では複数社分の認証基盤を運用する様なケースが発生している。
【０００７】
本発明は、以上の事情に鑑みてなされたものであり、複数の認証基盤を持つ企業でもクラウドサービスと認証連携を行うことが可能なシステムの提供を目的とする。
【課題を解決するための手段】
【０００８】
本発明に係る代表的な認証システムは、クラウドサービスと接続する認証システムであって、ユーザＩＤが登録された複数の認証基盤サーバと、入力されたユーザＩＤと一致するユーザＩＤの登録された認証基盤サーバを特定する情報を、前記クラウドサービスから取得し、前記特定する情報に基づき、前記認証基盤サーバから前記入力されたユーザＩＤの登録情報を取得するデータ連携サーバとを備えたことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、複数の認証基盤を持つ企業でもクラウドサービスと認証連携を行うことが可能になる。
【図面の簡単な説明】
【００１０】
【図１】企業における認証の構成の例を示す図である。
【図２】認証情報連携システムの構成の例を示す図である。
【図３】データ連携サーバの構成の例を示す図である。
【図４】クラウドサービスサーバの構成の例を示す図である。
【図５】認証基盤サーバの構成の例を示す図である。
【図６】拠点管理テーブルのデータ構成の例を示す図である。
【図７】クラウドサービスユーザ管理テーブルのデータ構成の例を示す図である。
【図８】社内システムユーザ管理テーブル５１２のデータ構成例を示す図である。
【図９Ａ】代理認証の前処理の例を示すシーケンス図である。
【図９Ｂ】代理認証の処理の例を示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下、図面を用いて実施例を説明する。
【００１２】
図１は、企業１００における認証の構成の例を示す図である。企業１００は、例えば本社１１０−１と国内工場１１０−２と海外拠点１１０−３の３拠点を有している。また、各拠点１１０（本社１１０−１と国内工場１１０−２などの個別の拠点を特に区別しない場合は拠点１１０と表し、以下の他の符号も同じ表現とする）では、社内１０１のシステムである社内システムへログインして利用するために、拠点１１０ごとに別々の認証基盤サーバ１１１を利用する。
【００１３】
本社１１０−１では本社認証基盤サーバ１１１−１を利用し、国内工場１１０−２では国内工場認証基盤サーバ１１１−２を利用し、海外拠点１１０−３では海外拠点認証基盤サーバ１１１−３を利用する。ここで、社内システムログイン情報１１２−１は本社１１０−１のシステムにログインするための情報であり、社内システムログイン情報１１２−２は国内工場１１０−２のシステムにログインするための情報であり、社内システムログイン情報１１２−３は海外拠点１１０−３のシステムにログインする情報であってもよい。
【００１４】
そして、各認証基盤サーバ１１１は異なる仕組みで構築されているため、企業１００で１つの認証基盤サーバに統合することはきわめて困難であり、仮に統合した認証基盤サーバを構築する場合には多大な工数が必要になる。
【００１５】
この様な背景の中、企業１００にて新規にクラウドサービス１２０を利用することになった場合、エンドユーザ（利用者）である企業１００の社員は、クラウドサービス１２０側にクラウドサービスログイン情報１２１に登録するのが一般的である。このため、社員は社内システムを利用するために使用している社内システムログイン情報１１２とクラウドサービスログイン情報１２１の２つのログイン情報を管理しなくてはならない。
【００１６】
そこで、社員が普段利用している社内システムログイン情報１１２を利用してクラウドサービス１２０にログインすることを可能にし、また、企業１００の様に複数の拠点１１０と認証基盤サーバ１１１を有する企業においても、認証基盤サーバ１１１を統合することなく、社員が普段利用している社内システムログイン情報１１２でクラウドサービス１２０へのログインを可能にする仕組みを、以下で説明する。
【００１７】
図２は、認証情報連携システム２００の構成の例を示す図である。なお、認証情報連携システム２００は、コンピュータネットワークシステムであってもよい。図２は、その構成を詳しく説明するため、１つの拠点１１０で利用した場合の構成を示した図とする。認証情報連携システム２００は、認証基盤サーバ１１１に登録されているＵＩＤ（ユーザＩＤ）とＰＷＤ（パスワード）のログイン情報を利用してクラウドサービスサーバ２０４へのログインを可能にするシステムである。
【００１８】
ユーザ端末２０１は、インターネットブラウザにより、ログイン画面格納サーバ２０２のＵＲＬ（ユニフォームリソースロケータ）が入力されることで、クラウドサービス１２０のログイン画面を表示し、入力されたＵＩＤ及びＰＷＤからなる認証情報を送信及び受信して、クラウドサービスの画面を表示する。
【００１９】
データ連携サーバ２０３は、社内１０１に既に存在する社内ネットワーク２０７に属するサーバ群と、インターネット２０６に属する前記クラウドサービス１２０とのデータ連携を可能にする。また、データ連携サーバ２０３は、前記ＵＩＤの内容を変換も可能にする。このため、データ連携サーバ２０３は、インターネット２０６と社内ネットワーク２０７との間の独自ネットワーク２０８に配置される。
【００２０】
データ連携サーバ２０３が接続されるインターネット２０６は、クラウドサービス１２０を実現するためにクラウドサービスサーバ２０４を有してもよい。なお、図２の例では別のサーバであるログイン画面格納サーバ２０２とデータ連携サーバ２０３は１つのサーバであってもよい。
【００２１】
図３は、データ連携サーバ２０３の構成の例を示す図である。データ連携サーバ２０３は、記憶部３０１と、コントローラ（制御部）３０２と、メモリ３０３と、通信制御部３０４と、通信制御部３０５を具備し、各部はバス３０６によって接続される。コントローラ３０２はプロセッサであってもよい。通信制御部３０４はインターネット２０６に接続され、通信制御部３０５は社内ネットワーク２０７に接続されてもよい。
【００２２】
記憶部３０１は、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）やフラッシュメモリなどであってもよい。記憶部３０１には、プログラム３１０の一部として、データ変換部３１１、クラウドサービス問合せ部３１２、認証基盤問合せ部３１３が格納される。また、記憶部３０１には、拠点管理テーブル３１４が格納される。記憶部３０１に格納されたプログラム３１０と拠点管理テーブル３１４は、メモリ３０３へ転送され、コントローラ３０２で処理されてもよい。
【００２３】
図４は、クラウドサービスサーバ２０４の構成の例を示す図である。クラウドサービスサーバ２０４は、記憶部４０１と、コントローラ（制御部）４０２と、メモリ４０３と、通信制御部４０４を具備し、各部はバス４０６によって接続される。コントローラ４０２はプロセッサであってもよい。通信制御部４０４はインターネット２０６を介して独自ネットワーク２０８に接続されてもよい。
【００２４】
記憶部４０１は、ＨＤＤやＳＳＤやフラッシュメモリなどであってもよい。記憶部４０１には、プログラム４１０の一部として、代理認証部４１１が格納される。また、記憶部４０１には、クラウドサービスユーザ管理テーブル４１２が格納される。クラウドサービスユーザ管理テーブル４１２は、クラウドサービスログイン情報１２１の一部またはすべてを含んでもよい。記憶部４０１に格納されたプログラム４１０とクラウドサービスユーザ管理テーブル４１２は、メモリ４０３へ転送され、コントローラ４０２で処理されてもよい。
【００２５】
図５は、認証基盤サーバ１１１の構成の例を示す図である。認証基盤サーバ１１１は、記憶部５０１と、コントローラ（制御部）５０２と、メモリ５０３と、通信制御部５０４を具備し、各部はバス５０６によって接続される。コントローラ５０２はプロセッサであってもよい。通信制御部５０４は独自ネットワーク２０８に接続されてもよい。
【００２６】
記憶部５０１は、ＨＤＤやＳＳＤやフラッシュメモリなどであってもよい。記憶部５０１には、プログラム５１０の一部として、認証部５１１が格納される。また、記憶部５０１には、社内システムユーザ管理テーブル５１２が格納される。社内システムユーザ管理テーブル５１２は、社内システムログイン情報１１２を含んでもよい。記憶部５０１に格納されたプログラム５１０と社内システムユーザ管理テーブル５１２は、メモリ５０３へ転送され、コントローラ５０２で処理されてもよい。
【００２７】
図６は、データ連携サーバ２０３の記憶部３０１に格納される拠点管理テーブル３１４のデータ構成の例を示す図である。拠点管理テーブル３１４は、拠点１１０を区別するための拠点ＩＤ６０１と、各拠点１１０で利用している認証基盤ＵＲＬ６０２が格納されるテーブルである。ここで、拠点ＩＤ６０１と認証基盤ＵＲＬ６０２は関連付けられており、図６の例においては同一の行が関連する。
【００２８】
図７は、クラウドサービスサーバ２０４の記憶部４０１に格納されるクラウドサービスユーザ管理テーブル４１２のデータ構成の例を示す図である。クラウドサービスユーザ管理テーブル４１２は、ＣＩＤ７０１、ＵＩＤ７０２、ＵｓｅｒＮａｍｅ７０３、拠点ＩＤ７０４が関連付けられて格納されるテーブルである。
【００２９】
ＣＩＤ７０１はクラウドＩＤであり、クラウドサービス１２０側の利用者１人に対して１つ割り当てられるログイン情報である。図７の例では「＠」以降がドメインであり、企業１００に対応してもよいし、拠点１１０に対応してもよい。拠点ＩＤ７０４は利用者がどこの拠点１１０に属するかを定義する情報であり、拠点管理テーブル３１４から認証基盤ＵＲＬ６０２を検索するときに利用される。
【００３０】
なお、異なる拠点１１１において同じＵＩＤが、クラウドサービスユーザ管理テーブル４１２のＵＩＤ７０２にそれぞれ登録されてもよい。
【００３１】
図８は、認証基盤サーバ１１１の記憶部５０１に格納される社内システムユーザ管理テーブル５１２のデータ構成の例を示す図である。社内システムユーザ管理テーブル５１２は、ＵｓｅｒＮａｍｅ８０１、ＵＩＤ８０２、ＰＷＤ８０３が関連付けられて格納されているテーブルである。この社内システムユーザ管理テーブル５１２に格納（登録）されたＵＩＤとＰＷＤの組合せに対してログインが許可される。
【００３２】
なお、以上で説明した拠点管理テーブル３１４、クラウドサービスユーザ管理テーブル４１２、社内ユーザ管理テーブル５１２の各内容は、図示を省略した入力装置あるいはネットワーク経由で予め設定される。
【００３３】
図９は、認証情報連携システム２００における処理の例を示すシーケンス図である。図９Ｂに示したシーケンスが代理認証であり、図９Ａに示したシーケンスが代理認証の前処理であって、図９Ａに示したシーケンスの後に連続して図９Ｂに示したシーケンスが実行されてもよい。
【００３４】
ユーザ端末２０１のインターネットブラウザにおいて、利用者によりログイン画面格納サーバ２０２のＵＲＬが入力されると、ユーザ端末２０１はログイン画面格納サーバ２０２へアクセスする(ステップＳ９０１)。これに対して、ログイン画面格納サーバ２０２は、アクセスしたユーザ端末２０１へログイン画面を送信する（ステップＳ９０２）。
【００３５】
ユーザ端末２０１は、クラウドサービスログインの画面を表示し、利用者へＵＩＤとＰＷＤの入力を要求する。利用者によりＵＩＤとＰＷＤがログイン画面に入力されると、ユーザ端末２０１はデータ連携サーバ２０３へＵＩＤとＰＷＤのログイン情報を送信する(ステップＳ９０３)。なお、ログイン画面格納サーバ２０２とデータ連携サーバ２０３とは１つのサーバであってもよい。
【００３６】
データ連携サーバ２０３はログイン情報を取得すると、プログラム３１０のクラウドサービス問合せ部３１２を実行し、クラウドサービスサーバ２０４へＵＩＤを送信して、ＣＩＤと拠点ＩＤを問合せる（ステップＳ９０４）。クラウドサービスサーバ２０４は、受信したＵＩＤをキーとしてクラウドサービス管理テーブル４１２のＵＩＤ７０２を検索し、受信したＵＩＤに関連付けられたＣＩＤと拠点ＩＤをＣＩＤ７０１と拠点ＩＤ７０４から取得し、データ連携サーバ２０３へ応答する(ステップＳ９０５)。
【００３７】
データ連携サーバ２０３は、取得した拠点ＩＤをキーとして拠点管理テーブル３１４の拠点ＩＤ６０１を検索し、取得した拠点ＩＤに紐付く認証基盤ＵＲＬを認証基盤ＵＲＬ６０２から取得する（ステップＳ９０６）。ステップＳ９０６にて、利用者が所属する拠点１１０の認証基盤サーバ１１１の認証基盤ＵＲＬを検索することが可能なため、複数の認証基盤サーバ１１１を有する企業１００の場合でも、利用者が属する認証基盤サーバ１１１を特定し、クラウドサービスと認証情報連携が可能となる。
【００３８】
データ連携サーバ２０３は、プログラム３１０の認証基盤問合せ部３１３を実行し、ステップＳ９０３でユーザ端末２０１から受信したＵＩＤとＰＷＤを、ステップＳ９０６で取得した認証基盤ＵＲＬと対応する認証基盤サーバ１１１へ送信し(ステップＳ９０７)、ＵＩＤのチェックを依頼する。
【００３９】
一般的に、利用者の入力したログイン情報に誤りがある場合、あるいは認証基盤に登録されていない利用者がログインを実施した場合、利用者へはログインに失敗したことを伝えるためのエラー画面を表示する必要がある。ステップＳ９０７に基づいてＵＩＤのチェックを実施しない構成の場合、ステップＳ９１０から開始する代理認証の処理の中で初めて認証情報の整合性がチェックされることになる。
【００４０】
代理認証は、クラウドサービス１２０が具備する認証であるため、利用者へのエラー画面表示のための送信もクラウドサービス１２０が担うことになる。何故ならば、クラウドサービス１２０は、クラウドサービス１２０側で用意されているログイン画面を送信することしかできない。そして、利用者のログイン情報が不正である場合に、クラウドサービス１２０のエラー画面が表示されてしまうこととなる。
【００４１】
これに対し、顧客（社内１０１）独自のログイン画面を利用することを前提とし、エラー画面も顧客独自の画面を利用可能とする。これにより、利用者のログイン情報に不正のある場合、顧客のどの部署へ問合せるかを表示するなど、顧客独自の情報を含む画面の表示が可能となる。
【００４２】
認証基盤サーバ１１１は、ステップＳ９０７で受信したログイン情報であるＵＩＤ及びＰＷＤの組合せが社内システムユーザ管理テーブル５１２に登録されているか検索し、検索結果を返す（ステップＳ９０８）。ログイン情報が登録されていない場合は、データ連携サーバ２０３にリターンコードとして「１」を返す。「１」リターンコードを受信したデータ連携サーバ２０３はユーザ端末２０１にエラー画面を表示させる。一方で、認証情報が登録されていた場合は、データ連携サーバ２０３にリターンコードとして「０」を返す。
【００４３】
「０」のリターンコードを受信したデータ連携サーバ２０３は、認証基盤サーバ１１１で認証の対象となるＵＩＤ８０２に登録されたＵＩＤの末尾に「＠」及びドメイン名が付与された形式のＣＩＤであって、ステップＳ９０５で取得したＣＩＤを、プログラム３１０のデータ変換部４１２を実行して加工し、ＣＩＤの「＠」以降を削ることで、ＵＩＤ８０２に登録されたＵＩＤと同じ形式のＣＩＤへ変換する。例えば、変換前のＣＩＤが「１２３４５６７８＠ｌｏｇｉｎ．ｃｏｍ」である場合、変換後のＣＩＤは「１２３４５６７８」となる。
【００４４】
なお、「０」のリターンコードを受信したデータ連携サーバ２０３は、その受信の時点で社内システムの利用を許可してもよい。そして、既に説明したＣＩＤの変換を実行して以下に説明する代理認証のシーケンスへ進んでもよいし、社内システムの利用を許可した時点で認証のシーケンスを終了してもよい。
【００４５】
また、クラウドサービスユーザ管理テーブル４１２のＵＩＤ７０２に同じＵＩＤが複数登録されている場合、そのＵＩＤが登録された複数の拠点ＩＤをステップＳ９０５でクラウドサービスサーバ２０４が送信し、その同じＵＩＤの登録されている複数の拠点１１１へＵＩＤのチェックを依頼してもよい。
【００４６】
すなわち、データ連携サーバ２０３はステップＳ９０８で「０」のリターンコードを受信するごとに、ステップＳ９０５で取得した複数の拠点ＩＤの中から別の拠点ＩＤを選択して、その選択した拠点ＩＤから認証基盤ＵＲＬを新たに取得し、新たに取得した認証基盤ＵＲＬに対応する認証基盤サーバ１１１へ向けてステップＳ９０７を実行するシーケンスを繰り返してもよい。ここで、一般的なセキュリティポリシーでは、同じになるようなＰＷＤの設定が禁止されている。
【００４７】
データ連携サーバ２０３は、代理認証を実行する為に、変換されたＣＩＤとユーザ端末２０１から入力されたＰＷＤからなる認証情報をクラウドサービスサーバ２０４に送信し、代理認証の実行を要求する(ステップＳ９０９)。代理認証とは、クラウドサービスサーバ２０４が実行する認証動作であり、外部の認証基盤による認証結果を利用してクラウドサービス１２０へのログインを可能にする。
【００４８】
クラウドサービスサーバ２０４は、代理認証実行要求を受信すると、プログラム４１０の代理認証部４１１を実行し、データ連携サーバ２０３に認証情報を送信する(ステップ９１０)。ここで、代理認証の対象となるＵＩＤ（変換されたＣＩＤ）やＰＷＤを認証情報が含んでもよい。
【００４９】
本来、代理認証を実施する場合は、クラウドサービス１２０が直接に認証基盤と通信をする手順が最も単純な手順である。しかしながら、認証基盤は一般的に企業１００の社内ネットワーク２０７内に設けられているため、クラウドサービス１２０などのインターネット２０６に公開されているサーバ（クラウドサービスサーバ２０４）と直接やりとりをすることが企業１００のセキュリティポリシーなどで禁じられることが多い。
【００５０】
そのため、この実施例では社内ネットワーク２０７とインターネット２０６のどちらとも通信が可能な独自ネットワーク２０８内にデータ連携サーバ２０３を配置する。これにより、クラウドサービスサーバ２０４と認証基盤サーバ１１１の間で認証情報を連携することが可能となる。
【００５１】
データ連携サーバ２０３は、受信した認証情報を、プログラム３１０の認証基盤問合せ部３１３を実行して、認証基盤サーバ１１１へ送信する（ステップＳ９１１）。認証基盤サーバ１１１は、受信した認証情報が社内システムユーザ管理テーブル５１２に登録されているかどうかを検索し、検索結果を返す（ステップＳ９１２）。認証情報が登録されていない場合は、データ連携サーバ２０３にリターンコードとして「１」を返す。なお、ステップＳ９０７で送信される情報とステップＳ９１１で送信される情報とが同じであり、ステップＳ９０８のリターンコードとして「１」の場合は、既に説明したようにデータ連携サーバ２０３によりエラー画面が表示されている。
【００５２】
「１」のリターンコードを受信したデータ連携サーバ２０３は、プログラム３１０のデータ変換部３１１を実行して、リターンコードをクラウドサービスサーバ２０４が読み込み可能な文字列「ＦＡＬＳＥ」に変換し、クラウドサービスサーバ２０４へ変換したリターンコードを送信する（ステップＳ９１３）。リターンコード「ＦＡＬＳＥ」を受信したクラウドサービスサーバ２０４は、プログラム４１０の代理認証部４１１を実行して、不正な認証情報であると判定し、ユーザ端末２０１へエラー画面を送信する。
【００５３】
一方で、認証情報が登録されていた場合は、データ連携サーバ２０３にリターンコードとして「０」を返す。「０」のリターンコードを受信したデータ連携サーバ２０３は、プログラム３１０のデータ変換部３１１を実行して、リターンコードをクラウドサービスサーバ２０４が読み込み可能な文字列「ＴＲＵＥ」に変換し、クラウドサービスサーバ２０４へ変換したリターンコードを送信する。
【００５４】
リターンコード「ＴＲＵＥ」を受信したクラウドサービスサーバ２０４は、プログラム４１０の代理認証部４１１を実行して、正しい認証情報であると判定し、クラウドサービス１２０へのログインを許可する（ステップ９１３）。以上で、代理認証は終了である。クラウドサービスサーバ２０４は、クラウドサービスへのログインが代理認証によって許可された利用者のユーザ端末２０１へクラウドサービスのホーム（メニュー）画面を送信する（ステップＳ９１４）。
【００５５】
以上で説明したように、社内システムの認証基盤サーバ１１１を利用してクラウドサービス１２０へログインすることが可能になり、利用者は社内システムのログイン情報だけを管理すれば、クラウドサービス１２０へのログインも可能になる。また、例えば複数の認証基盤を統合することと比較して、従来の複数の認証基盤そのものは変更が必要ないため、短期間かつ低コストでシステムを構築することが可能である。
【００５６】
さらに、クラウドサービス１２０へのログインにおいても、認証に必要な認証基盤サーバ１１１を特定できるため、不要な認証基盤サーバ１１１への認証依頼などのオーバーヘッドが発生することはない。
【符号の説明】
【００５７】
１１１・・・認証基盤サーバ
２０３・・・データ連携サーバ
２０４・・・クラウドサービスサーバ
３１１・・・データ変換部
３１２・・・クラウドサービス問合せ部
３１３・・・認証基盤問合せ部
３１４・・・拠点管理テーブル
４１１・・・代理認証部
【図１】
2017004296.tif 000003
【図２】
2017004296.tif 000004
【図３】
2017004296.tif 000005
【図４】
2017004296.tif 000006
【図５】
2017004296.tif 000007
【図６】
2017004296.tif 000008
【図７】
2017004296.tif 000009
【図８】
2017004296.tif 000010
【図９Ａ】
2017004296.tif 000011
【図９Ｂ】
2017004296.tif 000012