(57)【要約】      （修正有）【課題】同じ利用者が複数のシステムを利用するとき、アカウントとパスワードを複数管理することによって発生する、管理コストとセキュリティ課題を解決する方法およびプログラムを提供する。また、同じ利用者が複数のシステムを一括利用出来なくなるとき、システム認証不可の手続き漏れが発生するセキュリティ課題を解決する方法およびプログラムを提供する。さらに、同じ利用者が複数のシステムで個人情報を自動連携する方法およびプログラムを提供する。【解決手段】利用者とシステムの間に代理を設置し、複数のシステム間で、代理同志が情報交換して、複数のシステムで情報連携をさせる。ここでアカウント認証と管理を一本化させる。【選択図】図２
2015225562.tif 000002
【特許請求の範囲】
【請求項１】
利用者とコンピュータシステム通信経路中、代理を設置して、代理の情報連携の上、複数コンピュータシステム間で、一つをマスターアカウントシステムとして、他のシステムのアカウント管理と認証をマスターアカウントシステムに委託する方法とプログラム。
【請求項２】
請求項１の特定として、マスターアカウントシステムはアカウントサービスを提供する場合、利用者と他システムの間の代理は直接アカウントサービスを利用して、アカウント管理と認証を委託する方法とプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数既存コンピュータシステム間アカウント認証情報を共通利用方法である
【背景技術】
【０００２】
現状として、情報処理するために、１つ１つ特定機能を実現するため、各コンピュータシステムは開発された。基本的にこんなコンピュータシステムはユーザID、パスワードをペアにして利用者を認証している。
開発時期、開発技術、開発担当会社はバラバラなので、同じ利用者でも各システムの認証部分も独立して、それぞれのユーザID、パスワードを使ってシステム利用しないといけないことは多い。SSO（シングルサインオン）という技術はあるが、この技術を導入すると、既存システムに対して改修しないといけないので、導入コストとリスクが高くなる。
そして、業務を一連システムで実現する場合、各システム間でアカウント情報（有効性、氏名、部署など）の連携は個別するので、管理コストとセキュリティ問題はある。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】OAuth:オー オース(oauth.net）
【非特許文献２】SSO:シングルサインオン（英語：Single Sign-On）
【非特許文献３】SAML：Security Assertion Markup Language
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明は下記の課題を解決することを目指します。
１．同じ利用者は複数システム利用するとき、アカウントとパスワードを複数管理することによって、管理コストとセキュリティ課題
２．同じ利用者は複数システム一括利用出来なくなるとき、システム認証不可手続き漏れ発生のセキュリティ課題
３．同じ利用者の複数システム個人情報自動連携課題
【課題を解決するための手段】
【０００５】
まず、用語を説明する
１．メインアカウントを管理するシステムをマスターアカウントシステムと呼ぶ
２．ネットワーク設定上、マスターアカウントシステムをアクセス時、必ず経由するプログラムをマスター代理と呼ぶ（WEBシステムの場合、HTTPサーバのモジュールである）
３．自体アカウント機能を利用しなく、サービス機能を利用するシステムをサービスシステムと呼ぶ（アカウント認証と管理は本発明により、マスターアカウントシステムに委託する）
４．２と似る、ネットワーク設定上、サービスシステムをアクセス時、必ず経由するプログラムをサービス代理と呼ぶ
課題を解決する手段：
１．利用者は特定なネットワーク設定の上、マスターアカウントシステムの前にマスター代理、サービスシステム前にサービス代理を設定する
２．利用者はサービスシステム未認証時、サービス代理は利用者をマスターアカウントシステムの認証フローに案内する
３．マスター代理はマスターアカウントシステム認証結果を監視し、成功する場合、サービスシステムのサービス代理を経由して、サービスシステムのアカウントの情報を連携するうえ、認証トークンを取得する
４．サービスシステムの認証トークン（一般的にCookieを使う）を利用者クライアントに返して、サービスシステムを利用する
【発明の効果】
【０００６】
１．外部システムを内部に導入するとき、アカウント管理コストを削減する。システム連携もしやすくなる
２．社員退社後の外部サービス無効化の忘れ問題を回避して、セキュリティを強化する
３．アカウント連携後、サービス機能の連携も可能になる
【図面の簡単な説明】
【０００７】
【図１】現在複数システムを利用するフロー図である。
【図２】この発明を実施後、複数システムを利用するフロー図である。
【図３】この発明を実施する例として、複数ＷＥＢシステムの処理フロー図である。
【図４】図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図である。
【発明を実施するための形態】
【０００８】
本発明の実施形態について、図面の参照しながら詳細に説明する。
【０００９】
図１は現在複数システムを利用するフロー図である。同じユーザでも、システムＡとシステムＢを利用時、それぞれ各システムのアカウントaとbを使って独立ログインして、システムを利用しないといけない。
【００１０】
図２はこの発明を実施後、複数システムを利用するフロー図である。
本発明は、図１をベースにして、システムＡ（マスターアカウントシステム、下同）とシステムＢ（サービスシステム、下同）の通信経路中、それぞれのマスター代理とサービス代理を設置する。
ユーザはサービスシステムアクセス中、サービス代理を監視して認証ＮＧの場合、マスターアカウントシステムへ認証依頼をする。マスター代理も通信を監視してマスターアカウントシステム認証ＮＧの場合、ユーザにマスターアカウントシステムをログインさせる。認証ＯＫの場合、マスター代理はサービス代理と情報交換、ユーザはパスワード知らずアカウントｂでサービスシステムＢへログインさせて、ログイン結果のアカウントｂ認証トークンをサービス代理経由して、ユーザに返す。ユーザ次回から、アカウントｂの認証トークンを利用して、サービスシステムを利用する。
【００１１】
図３はマスターアカウントシステム、サービスシステムともＷＥＢシステムの場合、本発明を実施する処理フローを説明する図である。下記で各ステップを詳細に説明する。
前提：
１．マスター代理はマスターアカウントシステムと同じドメインの下。
２．サービス代理はサービスシステムと同じドメインの下。
３．サービス代理はサービスシステムのアカウント管理権限持つアカウントSを利用可能。
図のステップ番号の書き方の説明：
１．ステップを表現する矢印は左から右への場合、ステップ番号を矢印開始位置の上で書く
２．ステップを表現する矢印は右から左への場合、ステップ番号を矢印開始位置の下で書く
３．図４も同じ
【００１２】
ステップ３．１：利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。例えば、ブラウザのお気に入れから、サービスシステムのメインメニューへアクセスする。
【００１３】
ステップ３．２：サービスシステムはステップ３．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ３．３へ。認証NGの場合、ステップ３．４へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
【００１４】
ステップ３．３；認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。
【００１５】
ステップ３．４：認証NGの場合、サービス代理はサービスシステムのレスポンスを利用者側へ返せず、ステップ３．１のサービスシステムアクセスURL情報も添付してマスターアカウントシステムへのリダイレクトを返す。ステップ３．５へ。
【００１６】
ステップ３．５：利用者側のブラウザはサービス代理から戻ってくるリダイレクト指示を受けて、マスターアカウントシステムへ認証チェックURLへアクセス。マスター代理はアクセスを受けて、マスターアカウントシステムのログイン利用者情報取得可能なおページへアクセス。
一般的に、認証チェックURLはマスターアカウントシステム上として無効、マスター代理しか認識できない特殊URLである。たとえば、/sauth/accountの形式である。マスターアカウントシステムのログイン利用者情報取得可能なおページというものは、一般的にログインユーザのアカウント情報ページである。
【００１７】
ステップ３．６：マスターアカウントシステムはステップ３．５のアクセスリクエストに対して、レスポンスを返す。マスター代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ７へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
【００１８】
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを取得して、暗号化の上、サービスステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する  かつ  bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。
【００１９】
ステップ３．８：マスター代理は認証NGを判断する場合、マスター代理自身を経由して、マスターシステムのログイン画面へアクセスする。
【００２０】
ステップ３．９：ステップ３．８のアクセスリクエストに対して、マスターアカウントシステムはログイン画面を返す。マスター代理はログイン画面に識別情報を埋め込んでから、利用者側のブラウザへ帰す。例として、識別情報というものは、このログインはマスター代理からくるものを表現する画面見えない入力項目である。そして、ステップ３．５で添付されたサービスシステムアクセスURLも埋め込む。
【００２１】
ステップ３．１０：利用者はマスターアカウントシステムのアカウントaとパスワードを入力して、マスター代理を経由して、ログインをする。
マスター代理は通信を監視するが、ステップ３．９で埋め込んだ識別情報がある場合のみ、監視対象とする。
【００２２】
ステップ３．１１:マスターアカウントシステムはステップ３．１０のアカウントaとパスワードをチェックして、認証結果レスポンスを返す。マスター代理はこの結果レスポンスを解析して、認証OKの場合、認証OKトークンを添付して、ステップ３．１２へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。認証OKトークンというものは、一般的にクッキーの形式である。
【００２３】
ステップ３．１２：ステップ３．９で埋め込んだサービスシステムアクセスURL情報を添付して、ステップ３．５と同じマスターアカウントシステムへ認証チェックURLへリダイレクトする。
この時、利用者側ブラウザを経由リダイレクトなので、ステップ３．１１からもらったマスターシステムの認証トークンはブラウザ側で保管され、認証チェックURLにも付いてアクセスする。ステップ３．６の認証結果はOKになる。
【００２４】
ステップ３．１３：この時、サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ３．７の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ３．７の判断＝マッピングされ、かつ アカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ７で利用できるように、アカウントa  →  アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ３．１４へ。
【００２５】
ステップ３．１４：アカウントｂとパスワードを利用して、サービスシステムへログインする。ステップ３．１５へ。
【００２６】
ステップ３．１５：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理は認証用トークン内容を暗号化してステップ３．６の呼び出す元のマスター代理へ返す。
マスター代理は暗号化されるサービスシステム認証用トークン内容とステップ３．５で受けたサービスシステムアクセスURLと一緒に利用者側ブラウザへ返して、ステップ３．１６へ。
【００２７】
ステップ３．１６：ステップ３．１５からもらった暗号化認証トークンとサービスシステムアクセスURLを添付して、サービス代理の認証代理URLへリダイレクトする。ステップ３．１７へ
サービス代理の認証代理URLというものは、サービスシステム上無効なサービス代理しか認証できないURLである。例えば、/sauth/authProxyの形式である。
【００２８】
ステップ３．１７：ステップ３．１６で添付された暗号化トークンを復号化して、サービスシステムの認証トークン（一般的にクッキーの形式である）として、利用者側ブラウザ経由して、ステップ３．１６で添付されたサービスステムアクセスURLを利用してステップ３．１へ
この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ３．１の次、サービスシステムの認証OKになって、ステップ３．３で処理終了になる。
【００２９】
図３の実施に対して、１つ無視できない課題は存在する。サービスシステムへの接続は暗号化される場合（https）サービス代理をサービスシステムのファイアウォールの裏側（https通信範囲外）に置かないと、サービスシステム本体まで通信内容は監視不可。サービス代理として、動作できないことである。
この課題を解決する手段はいろいろあるが、下記の３つ方法で説明する：
１．サービス代理の設置はサービスシステム運営側に実施してもらう。
２．利用者の利用場所は限定的なの場合、サービスシステムの外部にサービス代理を設置するが、サービス代理のipをサービスシステムのドメインとして利用場所範囲のdnsに登録する。サービス代理は図３のステップ７以外の接続を本当のサービスシステムへ転送する。そうすれば、利用者はサービス代理経由して、サービスシステムを利用することが確保される。サービス代理上自己署名のssl証書を使うが、マスター代理と利用場所の信任CAに登録すれば、セキュリティ問題にならない
３．２と同じように設置するが、サービス代理はサービスシステムのドメインを使わなく、サービスシステムと異なるサービス代理ドメインを使う。２と同じように接続をサービスシステムへ転送するが、返ってくるレスポンスのサービスシステムドメインをサービス代理ドメインへ変換してから返す。利用者側はサービス代理ドメインを利用して、サービスシステムを利用する。
上記の方法は、課題が解決できることを説明するための例として使う。上記の方法に限らず、サービスシステムにアクセス経路中、サービス代理を設置し、アクセスを監視できれば、どんな方法でも利用可能。
【００３０】
図４は図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図。その時、図３のマスター代理は省略可能。
【００３１】
ステップ４．１は図３のステップ３．１と同じく、利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。
【００３２】
テップ４．２：サービスシステムはステップ４．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ４．３へ。認証NGの場合、ステップ４．４へ。
【００３３】
ステップ４．３：認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。
【００３４】
ステップ４．４：認証NGの場合、サービス代理はOAuth仕様により、マスターアカウントシステムへ認証要求アクセスを利用者側のブラウザへ返す。
【００３５】
ステップ４．５：利用者側のブラウザはステップ４．４のレスポンスを受けて、マスターアカウントシステムへリダイレクトする。
【００３６】
ステップ４．６：マスターアカウントシステムはOAuth仕様により、認証（権限承認）画面を利用者側のブラウザへ返す。
【００３７】
ステップ４．７：ユーザはマスターアカウントシステムのユーザaとして、認証（権限承認）する。
【００３８】
ステップ４．８：マスターアカウントシステムはOAuthの仕様により、認証（権限承認）OKの場合、リクエストトークンを発行して、ステップ４．９へ。認証NGの場合、ステップ４．５へ戻る。権限承認NGの場合、エラー終了。
【００３９】
ステップ４．９：OAuthの仕様により、ステップ４．８で受けたリクエストトークンをサービスシステムへリダイレクトする。
【００４０】
ステップ４．１０：OAuthの仕様により、サービス代理はステップ４．９のリクエストトークンを受けて、このリクエストトークンを使って、マスターアカウントシステムへアクセストークンを請求する。
【００４１】
ステップ４．１１：OAuthの仕様により、マスターアカウントシステムはサービス代理へアクセストークンを返す。
【００４２】
ステップ４．１２：OAuthの仕様により、サービス代理はアクセストークンを使って、マスターアカウントシステムへアカウントaの情報を請求する。
【００４３】
ステップ４．１３：OAuthの仕様により、マスターアカウントシステムはアカウントaの情報を返す。
【００４４】
ステップ４．１４：図３の３．７の部分に相当。サービス代理はマスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する  かつ  bの情報とaは一致する場合、ステップ４．１５へ、その他の場合、ステップ４．１６へ。
【００４５】
ステップ４．１５：図３の３．１３に相当。サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ４．１４の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ４．１４の判断＝マッピングされ、かつ アカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ４．１４で利用できるように、アカウントa  →  アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ４．１６へ。
【００４６】
ステップ４．１７：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理の呼び元は利用者側のブラウザので、そのまま認証トークンを含めて、ステップ４．１のアクセスURLへリダイレクトレスポンスを利用者側のブラウザへ返す。ステップ４．１８へ。
【００４７】
ステップ４．１８：図３のステップ３．１９に相当。ステップ４．１のアクセスURLへリダイレクトする。この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ４．１の次、サービスシステムの認証OKになって、ステップ４．３で処理終了になる。
【実施例】
【００４８】
例えば、A社は既に社内業務管理システムMを利用しているが、社外掲示板サービス提供するSシステムを利用したい。本発明を利用すれば、社内業務管理システムのアカウント管理をマスターアカウントシステムとして、掲示板システムSをサービスシステムとして、社内業務管理システムのアカウントを利用して、社外掲示板サービスを利用可能になる。
当然、マスターアカウントシステムはドメインシステムを利用しても構わない。アカウント管理機能を提供、そして、第三者のプログラムは認証、アカウント情報取得できれば、どんなシステムでもマスターアカウントシステムとして利用可能。
【産業上の利用可能性】
【００４９】
この発明は、複数コンピュータシステム間のアカウント認証と管理を１本化させて、システム統合コストを削減して、セキュリティーを強化する。
【図１】
2015225562.tif 000003
【図２】
2015225562.tif 000004
【図３】
2015225562.tif 000005
【図４】
2015225562.tif 000006
【手続補正書】
【提出日】平成26年8月15日(2014.8.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
利用者とマスターアカウントシステムの通信経路中、マスタ代理を設置して、利用者とサービスシステムの通信経路中、サービス代理を設置して、利用者はサービスシステム利用する場合、サービス代理は通信を監視し、認証は必要な場合、マスターアカウントシステムへ認証を依頼して、マスタ代理はこの依頼を監視して、認証成功の場合、マスターアカウントシステムのアカウント情報ページの内容を自動解析して、サービス代理と連携する。サービス代理はマスターアカウントシステムのアカウント情報をマッピング管理の上、サービスシステムへ登録または更新して、代理ログイン処理後認証トークンをクライアントへ返し、利用者はサービスシステムを利用できる認証委託プログラム
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項３
【補正方法】変更
【補正の内容】
【請求項３】
請求項１と請求項２の実施時、既定の認識用アカウントの情報画面にアクセスして、画面内容を解析し、アカウント情報の表示位置を認識して、一般アカウントを利用時、一般アカウント情報画面を解析して、前項の表示位置情報を利用して、一般アカウント情報を自動取得するプログラム
【手続補正書】
【提出日】平成26年8月18日(2014.8.18)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】変更
【補正の内容】
【００１８】
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを自動取得して、暗号化の上、サービスステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する  かつ  bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。
上記のレスポンスからログインユーザのアカウント情報自動取得方法は、既に認識用アカウントを作成して（例えばテスト太郎、東京支社、システム開発部、２課、係長）、定期（例えば日次）このアカウントを利用して、アカウント情報ページにアクセスして、アカウント情報を利用して、各項目の画面位置を解析して、この画面位置情報を利用して、上記のアカウント情報aを取得する
【手続補正書】
【提出日】平成26年9月8日(2014.9.8)
【手続補正１】
【補正対象書類名】手続補正書
【補正対象項目名】手続補正１
【補正方法】変更
【補正の内容】
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
利用者とマスターアカウントシステムの通信経路中、マスタ代理を設置して、利用者とサービスシステムの通信経路中、サービス代理を設置して、利用者はサービスシステム利用する場合、サービス代理は通信を監視し、認証は必要な場合、マスターアカウントシステムへ認証を依頼して、マスタ代理はこの依頼を監視して、認証成功の場合、マスターアカウントシステムのアカウント情報ページの内容を自動解析して、サービス代理と連携する。サービス代理はマスターアカウントシステムのアカウント情報をマッピング管理の上、サービスシステムへ登録または更新して、代理ログイン処理後認証トークンをクライアントへ返し、利用者はサービスシステムを利用できる認証委託プログラム。
【請求項２】
請求項１の特定として、マスターアカウントシステムはアカウントサービスを提供する場合、利用者と他システムの間の代理は直接アカウントサービスを利用して、アカウント管理と認証を委託する方法とプログラム。
【請求項３】
請求項１と請求項２の実施時、既定の認識用アカウントの情報画面にアクセスして、画面内容を解析し、アカウント情報の表示位置を認識して、一般アカウントを利用時、一般アカウント情報画面を解析して、前項の表示位置情報を利用して、一般アカウント情報を自動取得するプログラム。
【手続補正２】
【補正対象書類名】手続補正書
【補正対象項目名】手続補正２
【補正方法】削除
【補正の内容】
【手続補正書】
【提出日】平成27年2月9日(2015.2.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
利用者のメインアカウントを管理するマスターアカウントシステムと、該マスターアカウントシステムの通信経路中に、前記マスターアカウントシステムにアクセスする時に必ず経由するマスター代理と、該利用者が利用したいサービスシステムと、前記サービスシステムの通信経路中に、前記サービスシステムにアクセスする時に必ず経由するサービス代理とを設置して、
利用者が前記サービスシステム利用する場合、前記サービス代理は通信を監視し、ログイン認証が必要な場合、前記マスターアカウントシステムへ認証を依頼して、
前記マスター代理はこの依頼を監視して、前記マスターアカウントシステムのアカウント情報ページの内容を取得して、ログイン認証成功後、前記サービス代理と連携し、前記マスターアカウントシステムのアカウント情報がマッピングされない場合は、前記アカウント情報をベースにして、サービスシステムアカウントと乱数でパスワードを生成し、前記サービスシステムのアカウント管理権限を持つアカウントを利用して、前記サービスシステムに上記生成したサービスシステムアカウントの新規登録を行う一方、前記マスターアカウントシステムのアカウント情報がマッピングされ、且つマッピングされた前記サービスシステムのアカウント情報と前記マスターアカウントシステムのアカウント情報が不一致な場合は、前記マスターアカウントシステムのアカウント情報をベースに、前記サービスシステムのアカウント情報を更新するステップを経て前記サービスシステムのアカウント情報のマッピング関係と前記サービスシステムのアカウント情報を保存し、その後、代理ログイン処理後認証トークンをクライアントへ返し、利用者は前記サービスシステムを利用できる複数コンピュータシステムの認証連携システム。
【請求項２】
請求項１において、
前記サービスシステムにログイン認証がNGとされた場合、
前記サービス代理は、前記サービスシステムのログイン認証がNGというレスポンスを利用者に返さず、前記サービスシステムのアクセスURL情報を添付して前記マスターアカウントシステムにリダイレクトする複数コンピュータシステムの認証連携システム。
【請求項３】
請求項２において、
前記マスター代理は、前記サービス代理から戻ってくるリダイレクトアクセスを受けて、前記マスターアカウントシステムのログイン利用者情報取得可能なページへアクセスしてログイン利用者のアカウント情報を取得する複数コンピュータシステムの認証連携システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数既存コンピュータシステム間のアカウント認証情報を共通利用できる複数コンピュータシステムの認証連携システムである
【背景技術】
【０００２】
現状として、情報処理するために、１つ１つ特定機能を実現するため、各コンピュータシステムは開発された。基本的にこんなコンピュータシステムはユーザID、パスワードをペアにして利用者を認証している。
開発時期、開発技術、開発担当会社はバラバラなので、同じ利用者でも各システムの認証部分も独立して、それぞれのユーザID、パスワードを使ってシステム利用しないといけないことは多い。SSO（シングルサインオン）という技術はあるが、この技術を導入すると、既存システムに対して改修しないといけないので、導入コストとリスクが高くなる。
そして、業務を一連システムで実現する場合、各システム間でアカウント情報（有効性、氏名、部署など）の連携は個別するので、管理コストとセキュリティ問題はある。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】OAuth:オー オース(oauth.net）
【非特許文献２】SSO:シングルサインオン（英語：Single Sign-On）
【非特許文献３】SAML：Security Assertion Markup Language
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明は下記の課題を解決することを目指します。
１．同じ利用者は複数システム利用するとき、アカウントとパスワードを複数管理することによって、管理コストとセキュリティ課題
２．同じ利用者は複数システム一括利用出来なくなるとき、システム認証不可手続き漏れ発生のセキュリティ課題
３．同じ利用者の複数システム個人情報自動連携課題
【課題を解決するための手段】
【０００５】
まず、用語を説明する
１．メインアカウントを管理するシステムをマスターアカウントシステムと呼ぶ
２．ネットワーク設定上、マスターアカウントシステムをアクセス時、必ず経由するプログラムをマスター代理と呼ぶ（WEBシステムの場合、HTTPサーバのモジュールである）
３．自体アカウント機能を利用しなく、サービス機能を利用するシステムをサービスシステムと呼ぶ（アカウント認証と管理は本発明により、マスターアカウントシステムに委託する）
４．２と似る、ネットワーク設定上、サービスシステムをアクセス時、必ず経由するプログラムをサービス代理と呼ぶ
課題を解決する手段：
１．利用者は特定なネットワーク設定の上、マスターアカウントシステムの前にマスター代理、サービスシステム前にサービス代理を設定する
２．利用者はサービスシステム未認証時、サービス代理は利用者をマスターアカウントシステムの認証フローに案内する
３．マスター代理はマスターアカウントシステム認証結果を監視し、成功する場合、サービスシステムのサービス代理を経由して、サービスシステムのアカウントの情報を連携するうえ、認証トークンを取得する
４．サービスシステムの認証トークン（一般的にCookieを使う）を利用者クライアントに返して、サービスシステムを利用する
【０００６】
本発明に係る複数コンピュータシステムの認証連携システムは、利用者のメインアカウントを管理するマスターアカウントシステムと、該マスターアカウントシステムの通信経路中に、前記マスターアカウントシステムにアクセスする時に必ず経由するマスター代理と、該利用者が利用したいサービスシステムと、前記サービスシステムの通信経路中に、前記サービスシステムにアクセスする時に必ず経由するサービス代理とを設置して、
利用者が前記サービスシステム利用する場合、前記サービス代理は通信を監視し、ログイン認証が必要な場合、前記マスターアカウントシステムへ認証を依頼して、
前記マスター代理はこの依頼を監視して、前記マスターアカウントシステムのアカウント情報ページの内容を取得して、ログイン認証成功後、前記サービス代理と連携し、前記マスターアカウントシステムのアカウント情報がマッピングされない場合は、前記アカウント情報をベースにして、サービスシステムアカウントと乱数でパスワードを生成し、前記サービスシステムのアカウント管理権限を持つアカウントを利用して、前記サービスシステムに上記生成したサービスシステムアカウントの新規登録を行う一方、前記マスターアカウントシステムのアカウント情報がマッピングされ、且つマッピングされた前記サービスシステムのアカウント情報と前記マスターアカウントシステムのアカウント情報が不一致な場合は、前記マスターアカウントシステムのアカウント情報をベースに、前記サービスシステムのアカウント情報を更新するステップを経て前記サービスシステムのアカウント情報のマッピング関係と前記サービスシステムのアカウント情報を保存し、その後、代理ログイン処理後認証トークンをクライアントへ返し、利用者は前記サービスシステムを利用できる。
【０００７】
本発明において、前記サービスシステムにログイン認証がNGとされた場合、
前記サービス代理は、前記サービスシステムのログイン認証がNGというレスポンスを利用者に返さず、前記サービスシステムのアクセスURL情報を添付して前記マスターアカウントシステムにリダイレクトするようにしてもよい。
また本発明において、  前記マスター代理は、前記サービス代理から戻ってくるリダイレクトアクセスを受けて、前記マスターアカウントシステムのログイン利用者情報取得可能なページへアクセスしてログイン利用者のアカウント情報を取得するようにしてもよい。
【発明の効果】
【０００８】
１．外部システムを内部に導入するとき、アカウント管理コストを削減する。システム連携もしやすくなる
２．社員退社後の外部サービス無効化の忘れ問題を回避して、セキュリティを強化する
３．アカウント連携後、サービス機能の連携も可能になる
【図面の簡単な説明】
【０００９】
【図１】現在複数システムを利用するフロー図である。
【図２】この発明を実施後、複数システムを利用するフロー図である。
【図３】この発明を実施する例として、複数ＷＥＢシステムの処理フロー図である。
【図４】図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図である。
【発明を実施するための形態】
【００１０】
本発明の実施形態について、図面の参照しながら詳細に説明する。
【００１１】
図１は現在複数システムを利用するフロー図である。同じユーザでも、システムＡとシステムＢを利用時、それぞれ各システムのアカウントaとbを使って独立ログインして、システムを利用しないといけない。
【００１２】
図２はこの発明を実施後、複数システムを利用するフロー図である。
本発明は、図１をベースにして、システムＡ（マスターアカウントシステム、下同）とシステムＢ（サービスシステム、下同）の通信経路中、それぞれのマスター代理とサービス代理を設置する。
ユーザはサービスシステムアクセス中、サービス代理を監視して認証ＮＧの場合、マスターアカウントシステムへ認証依頼をする。マスター代理も通信を監視してマスターアカウントシステム認証ＮＧの場合、ユーザにマスターアカウントシステムをログインさせる。認証ＯＫの場合、マスター代理はサービス代理と情報交換、ユーザはパスワード知らずアカウントｂでサービスシステムＢへログインさせて、ログイン結果のアカウントｂ認証トークンをサービス代理経由して、ユーザに返す。ユーザ次回から、アカウントｂの認証トークンを利用して、サービスシステムを利用する。
【００１３】
図３はマスターアカウントシステム、サービスシステムともＷＥＢシステムの場合、本発明を実施する処理フローを説明する図である。下記で各ステップを詳細に説明する。
前提：
１．マスター代理はマスターアカウントシステムと同じドメインの下。
２．サービス代理はサービスシステムと同じドメインの下。
３．サービス代理はサービスシステムのアカウント管理権限持つアカウントSを利用可能。
図のステップ番号の書き方の説明：
１．ステップを表現する矢印は左から右への場合、ステップ番号を矢印開始位置の上で書く
２．ステップを表現する矢印は右から左への場合、ステップ番号を矢印開始位置の下で書く
３．図４も同じ
【００１４】
ステップ３．１：利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。例えば、ブラウザのお気に入れから、サービスシステムのメインメニューへアクセスする。
【００１５】
ステップ３．２：サービスシステムはステップ３．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ３．３へ。認証NGの場合、ステップ３．４へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。  
【００１６】
ステップ３．３；認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。
【００１７】
ステップ３．４：認証NGの場合、サービス代理はサービスシステムのレスポンスを利用者側へ返せず、ステップ３．１のサービスシステムアクセスURL情報も添付してマスターアカウントシステムへのリダイレクトを返す。ステップ３．５へ。
【００１８】
ステップ３．５：利用者側のブラウザはサービス代理から戻ってくるリダイレクト指示を受けて、マスターアカウントシステムへ認証チェックURLへアクセス。マスター代理はアクセスを受けて、マスターアカウントシステムのログイン利用者情報取得可能なおページへアクセス。
一般的に、認証チェックURLはマスターアカウントシステム上として無効、マスター代理しか認識できない特殊URLである。たとえば、/sauth/accountの形式である。マスターアカウントシステムのログイン利用者情報取得可能なおページというものは、一般的にログインユーザのアカウント情報ページである。
【００１９】
ステップ３．６：マスターアカウントシステムはステップ３．５のアクセスリクエストに対して、レスポンスを返す。マスター代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ７へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
【００２０】
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを取得して、暗号化の上、サービスシステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する  かつ  bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。
【００２１】
ステップ３．８：マスター代理は認証NGを判断する場合、マスター代理自身を経由して、マスターシステムのログイン画面へアクセスする。
【００２２】
ステップ３．９：ステップ３．８のアクセスリクエストに対して、マスターアカウントシステムはログイン画面を返す。マスター代理はログイン画面に識別情報を埋め込んでから、利用者側のブラウザへ帰す。例として、識別情報というものは、このログインはマスター代理からくるものを表現する画面見えない入力項目である。そして、ステップ３．５で添付されたサービスシステムアクセスURLも埋め込む。
【００２３】
ステップ３．１０：利用者はマスターアカウントシステムのアカウントaとパスワードを入力して、マスター代理を経由して、ログインをする。
マスター代理は通信を監視するが、ステップ３．９で埋め込んだ識別情報がある場合のみ、監視対象とする。
【００２４】
ステップ３．１１:マスターアカウントシステムはステップ３．１０のアカウントaとパスワードをチェックして、認証結果レスポンスを返す。マスター代理はこの結果レスポンスを解析して、認証OKの場合、認証OKトークンを添付して、ステップ３．１２へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。認証OKトークンというものは、一般的にクッキーの形式である。
【００２５】
ステップ３．１２：ステップ３．９で埋め込んだサービスシステムアクセスURL情報を添付して、ステップ３．５と同じマスターアカウントシステムへ認証チェックURLへリダイレクトする。
この時、利用者側ブラウザを経由リダイレクトなので、ステップ３．１１からもらったマスターシステムの認証トークンはブラウザ側で保管され、認証チェックURLにも付いてアクセスする。ステップ３．６の認証結果はOKになる。
【００２６】
ステップ３．１３：この時、サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ３．７の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ３．７の判断＝マッピングされ、かつアカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ７で利用できるように、アカウントa  →  アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ３．１４へ。
【００２７】
ステップ３．１４：アカウントｂとパスワードを利用して、サービスシステムへログインする。ステップ３．１５へ。
【００２８】
ステップ３．１５：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理は認証用トークン内容を暗号化してステップ３．６の呼び出す元のマスター代理へ返す。
マスター代理は暗号化されるサービスシステム認証用トークン内容とステップ３．５で受けたサービスシステムアクセスURLと一緒に利用者側ブラウザへ返して、ステップ３．１６へ。
【００２９】
ステップ３．１６：ステップ３．１５からもらった暗号化認証トークンとサービスシステムアクセスURLを添付して、サービス代理の認証代理URLへリダイレクトする。ステップ３．１７へ
サービス代理の認証代理URLというものは、サービスシステム上無効なサービス代理しか認証できないURLである。例えば、/sauth/authProxyの形式である。
【００３０】
ステップ３．１７：ステップ３．１６で添付された暗号化トークンを復号化して、サービスシステムの認証トークン（一般的にクッキーの形式である）として、利用者側ブラウザ経由して、ステップ３．１６で添付されたサービスステムアクセスURLを利用してステップ３．１へ
この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ３．１の次、サービスシステムの認証OKになって、ステップ３．３で処理終了になる。
【００３１】
図３の実施に対して、１つ無視できない課題は存在する。サービスシステムへの接続は暗号化される場合（https）サービス代理をサービスシステムのファイアウォールの裏側（https通信範囲外）に置かないと、サービスシステム本体まで通信内容は監視不可。サービス代理として、動作できないことである。
この課題を解決する手段はいろいろあるが、下記の３つ方法で説明する：
１．サービス代理の設置はサービスシステム運営側に実施してもらう。
２．利用者の利用場所は限定的なの場合、サービスシステムの外部にサービス代理を設置するが、サービス代理のipをサービスシステムのドメインとして利用場所範囲のdnsに登録する。サービス代理は図３のステップ７以外の接続を本当のサービスシステムへ転送する。そうすれば、利用者はサービス代理経由して、サービスシステムを利用することが確保される。サービス代理上自己署名のssl証書を使うが、マスター代理と利用場所の信任CAに登録すれば、セキュリティ問題にならない
３．２と同じように設置するが、サービス代理はサービスシステムのドメインを使わなく、サービスシステムと異なるサービス代理ドメインを使う。２と同じように接続をサービスシステムへ転送するが、返ってくるレスポンスのサービスシステムドメインをサービス代理ドメインへ変換してから返す。利用者側はサービス代理ドメインを利用して、サービスシステムを利用する。
上記の方法は、課題が解決できることを説明するための例として使う。上記の方法に限らず、サービスシステムにアクセス経路中、サービス代理を設置し、アクセスを監視できれば、どんな方法でも利用可能。
【００３２】
図４は図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図。その時、図３のマスター代理は省略可能。
【００３３】
ステップ４．１は図３のステップ３．１と同じく、利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。
【００３４】
テップ４．２：サービスシステムはステップ４．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ４．３へ。認証NGの場合、ステップ４．４へ。
【００３５】
ステップ４．３：認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。
【００３６】
ステップ４．４：認証NGの場合、サービス代理はOAuth仕様により、マスターアカウントシステムへ認証要求アクセスを利用者側のブラウザへ返す。
【００３７】
ステップ４．５：利用者側のブラウザはステップ４．４のレスポンスを受けて、マスターアカウントシステムへリダイレクトする。
【００３８】
ステップ４．６：マスターアカウントシステムはOAuth仕様により、認証（権限承認）画面を利用者側のブラウザへ返す。
【００３９】
ステップ４．７：ユーザはマスターアカウントシステムのユーザaとして、認証（権限承認）する。
【００４０】
ステップ４．８：マスターアカウントシステムはOAuthの仕様により、認証（権限承認）OKの場合、リクエストトークンを発行して、ステップ４．９へ。認証NGの場合、ステップ４．５へ戻る。権限承認NGの場合、エラー終了。
【００４１】
ステップ４．９：OAuthの仕様により、ステップ４．８で受けたリクエストトークンをサービスシステムへリダイレクトする。
【００４２】
ステップ４．１０：OAuthの仕様により、サービス代理はステップ４．９のリクエストトークンを受けて、このリクエストトークンを使って、マスターアカウントシステムへアクセストークンを請求する。
【００４３】
ステップ４．１１：OAuthの仕様により、マスターアカウントシステムはサービス代理へアクセストークンを返す。
【００４４】
ステップ４．１２：OAuthの仕様により、サービス代理はアクセストークンを使って、マスターアカウントシステムへアカウントaの情報を請求する。
【００４５】
ステップ４．１３：OAuthの仕様により、マスターアカウントシステムはアカウントaの情報を返す。
【００４６】
ステップ４．１４：図３の３．７の部分に相当。サービス代理はマスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する  かつ  bの情報とaは一致する場合、ステップ４．１５へ、その他の場合、ステップ４．１６へ。
【００４７】
ステップ４．１５：図３の３．１３に相当。サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ４．１４の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ４．１４の判断＝マッピングされ、かつアカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ４．１４で利用できるように、アカウントa  →  アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ４．１６へ。
【００４８】
ステップ４．１７：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理の呼び元は利用者側のブラウザので、そのまま認証トークンを含めて、ステップ４．１のアクセスURLへリダイレクトレスポンスを利用者側のブラウザへ返す。ステップ４．１８へ。
【００４９】
ステップ４．１８：図３のステップ３．１９に相当。ステップ４．１のアクセスURLへリダイレクトする。この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ４．１の次、サービスシステムの認証OKになって、ステップ４．３で処理終了になる。
【実施例】
【００５０】
例えば、A社は既に社内業務管理システムMを利用しているが、社外掲示板サービス提供するSシステムを利用したい。本発明を利用すれば、社内業務管理システムのアカウント管理をマスターアカウントシステムとして、掲示板システムSをサービスシステムとして、社内業務管理システムのアカウントを利用して、社外掲示板サービスを利用可能になる。
当然、マスターアカウントシステムはドメインシステムを利用しても構わない。アカウント管理機能を提供、そして、第三者のプログラムは認証、アカウント情報取得できれば、どんなシステムでもマスターアカウントシステムとして利用可能。
【産業上の利用可能性】
【００５１】
この発明は、複数コンピュータシステム間のアカウント認証と管理を１本化させて、システム統合コストを削減して、セキュリティーを強化する。