JP5724017B1 - 複数コンピュータシステムの認証連携システム - Google Patents

Abstract

【課題】同じ利用者が複数のシステムを利用するとき、アカウントとパスワードを複数管理することによって発生する、管理コストとセキュリティ課題を解決する方法およびプログラムを提供する。また、同じ利用者が複数のシステムを一括利用出来なくなるとき、システム認証不可の手続き漏れが発生するセキュリティ課題を解決する方法およびプログラムを提供する。さらに、同じ利用者が複数のシステムで個人情報を自動連携する方法およびプログラムを提供する。【解決手段】利用者とシステムの間に代理を設置し、複数のシステム間で、代理同志が情報交換して、複数のシステムで情報連携をさせる。ここでアカウント認証と管理を一本化させる。【選択図】図２

Description

この発明は、複数既存コンピュータシステム間のアカウント認証情報を共通利用できる複数コンピュータシステムの認証連携システムである

現状として、情報処理するために、１つ１つ特定機能を実現するため、各コンピュータシステムは開発された。基本的にこんなコンピュータシステムはユーザ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をサービスシステムとして、社内業務管理システムのアカウントを利用して、社外掲示板サービスを利用可能になる。
当然、マスターアカウントシステムはドメインシステムを利用しても構わない。アカウント管理機能を提供、そして、第三者のプログラムは認証、アカウント情報取得できれば、どんなシステムでもマスターアカウントシステムとして利用可能。

この発明は、複数コンピュータシステム間のアカウント認証と管理を１本化させて、システム統合コストを削減して、セキュリティーを強化する。

Claims (3)

1. 利用者のメインアカウントを管理するマスターアカウントシステムと、該マスターアカウントシステムの通信経路中に、前記マスターアカウントシステムにアクセスする時に必ず経由するマスター代理と、該利用者が利用したいサービスシステムと、前記サービスシステムの通信経路中に、前記サービスシステムにアクセスする時に必ず経由するサービス代理とを設置して、
   利用者が前記サービスシステム利用する場合、前記サービス代理は通信を監視し、ログイン認証が必要な場合、前記マスターアカウントシステムへ認証を依頼して、
   前記マスター代理はこの依頼を監視して、前記マスターアカウントシステムのアカウント情報ページの内容を取得して、ログイン認証成功後、前記サービス代理と連携し、前記マスターアカウントシステムのアカウント情報がマッピングされない場合は、前記アカウント情報をベースにして、サービスシステムアカウントと乱数でパスワードを生成し、前記サービスシステムのアカウント管理権限を持つアカウントを利用して、前記サービスシステムに上記生成したサービスシステムアカウントの新規登録を行う一方、前記マスターアカウントシステムのアカウント情報がマッピングされ、且つマッピングされた前記サービスシステムのアカウント情報と前記マスターアカウントシステムのアカウント情報が不一致な場合は、前記マスターアカウントシステムのアカウント情報をベースに、前記サービスシステムのアカウント情報を更新するステップを経て前記サービスシステムのアカウント情報のマッピング関係と前記サービスシステムのアカウント情報を保存し、その後、代理ログイン処理後認証トークンをクライアントへ返し、利用者は前記サービスシステムを利用できる複数コンピュータシステムの認証連携システム。
2. 請求項１において、
   前記サービスシステムにログイン認証がNGとされた場合、
   前記サービス代理は、前記サービスシステムのログイン認証がNGというレスポンスを利用者に返さず、前記サービスシステムのアクセスURL情報を添付して前記マスターアカウントシステムにリダイレクトする複数コンピュータシステムの認証連携システム。
3. 請求項２において、
   前記マスター代理は、前記サービス代理から戻ってくるリダイレクトアクセスを受けて、前記マスターアカウントシステムのログイン利用者情報取得可能なページへアクセスしてログイン利用者のアカウント情報を取得する複数コンピュータシステムの認証連携システム。

Images