JP2015225562A - Authentication coordination system of plural computer systems - Google Patents
Authentication coordination system of plural computer systems Download PDFInfo
- Publication number
- JP2015225562A JP2015225562A JP2014110789A JP2014110789A JP2015225562A JP 2015225562 A JP2015225562 A JP 2015225562A JP 2014110789 A JP2014110789 A JP 2014110789A JP 2014110789 A JP2014110789 A JP 2014110789A JP 2015225562 A JP2015225562 A JP 2015225562A
- Authority
- JP
- Japan
- Prior art keywords
- account
- service
- authentication
- master
- service system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
この発明は、複数既存コンピュータシステム間アカウント認証情報を共通利用方法である The present invention is a method of commonly using account authentication information between a plurality of existing computer systems.
現状として、情報処理するために、１つ１つ特定機能を実現するため、各コンピュータシステムは開発された。基本的にこんなコンピュータシステムはユーザID、パスワードをペアにして利用者を認証している。
開発時期、開発技術、開発担当会社はバラバラなので、同じ利用者でも各システムの認証部分も独立して、それぞれのユーザID、パスワードを使ってシステム利用しないといけないことは多い。SSO（シングルサインオン）という技術はあるが、この技術を導入すると、既存システムに対して改修しないといけないので、導入コストとリスクが高くなる。
そして、業務を一連システムで実現する場合、各システム間でアカウント情報（有効性、氏名、部署など）の連携は個別するので、管理コストとセキュリティ問題はある。
Currently, each computer system has been developed to realize specific functions one by one for information processing. Basically, such a computer system authenticates a user by pairing a user ID and a password.
Since the development time, development technology, and company in charge of development vary, it is often necessary to use the system with the same user ID and password independently from each other even if the same user. There is a technology called SSO (single sign-on), but if this technology is introduced, the existing system must be modified, which increases the cost and risk of introduction.
When the business is realized by a series of systems, there is a management cost and a security problem because account information (validity, name, department, etc.) is individually linked between the systems.
この発明は下記の課題を解決することを目指します。
１．同じ利用者は複数システム利用するとき、アカウントとパスワードを複数管理することによって、管理コストとセキュリティ課題
２．同じ利用者は複数システム一括利用出来なくなるとき、システム認証不可手続き漏れ発生のセキュリティ課題
３．同じ利用者の複数システム個人情報自動連携課題
The present invention aims to solve the following problems.
1. Management cost and security issues by managing multiple accounts and passwords when the same user uses multiple systems. 2. Security issue of system authentication failure procedure omission when the same user cannot use multiple systems at once. Multi-system personal information automatic cooperation problem of the same user
まず、用語を説明する
１．メインアカウントを管理するシステムをマスターアカウントシステムと呼ぶ
２．ネットワーク設定上、マスターアカウントシステムをアクセス時、必ず経由するプログラムをマスター代理と呼ぶ（WEBシステムの場合、HTTPサーバのモジュールである）
３．自体アカウント機能を利用しなく、サービス機能を利用するシステムをサービスシステムと呼ぶ（アカウント認証と管理は本発明により、マスターアカウントシステムに委託する）
４．２と似る、ネットワーク設定上、サービスシステムをアクセス時、必ず経由するプログラムをサービス代理と呼ぶ
課題を解決する手段：
１．利用者は特定なネットワーク設定の上、マスターアカウントシステムの前にマスター代理、サービスシステム前にサービス代理を設定する
２．利用者はサービスシステム未認証時、サービス代理は利用者をマスターアカウントシステムの認証フローに案内する
３．マスター代理はマスターアカウントシステム認証結果を監視し、成功する場合、サービスシステムのサービス代理を経由して、サービスシステムのアカウントの情報を連携するうえ、認証トークンを取得する
４．サービスシステムの認証トークン（一般的にCookieを使う）を利用者クライアントに返して、サービスシステムを利用する
First, terms will be explained. 1. A system that manages the main account is called a master account system. When accessing the master account system for network settings, the program that is always passed through is called the master proxy (in the case of the WEB system, it is an HTTP server module)
3. A system that does not use the account function itself but uses the service function is called a service system (account authentication and management are entrusted to the master account system according to the present invention).
Similar to 4.2, the network that is always accessed when accessing the service system is called a service proxy.
Means to solve the problem:
1. 1. The user sets the master proxy before the master account system and the service proxy before the service system after specific network settings. 2. When the user is unauthenticated, the service agent guides the user to the master account system authentication flow. The master proxy monitors the master account system authentication result and, if successful, links the service system account information and obtains an authentication token via the service proxy of the service system. Return the service system authentication token (usually using cookies) to the user client and use the service system
１．外部システムを内部に導入するとき、アカウント管理コストを削減する。システム連携もしやすくなる
２．社員退社後の外部サービス無効化の忘れ問題を回避して、セキュリティを強化する
３．アカウント連携後、サービス機能の連携も可能になる
1. Reduce account management costs when introducing external systems internally.
本発明の実施形態について、図面の参照しながら詳細に説明する。 Embodiments of the present invention will be described in detail with reference to the drawings.
図１は現在複数システムを利用するフロー図である。同じユーザでも、システムＡとシステムＢを利用時、それぞれ各システムのアカウントaとbを使って独立ログインして、システムを利用しないといけない。 FIG. 1 is a flow diagram that currently utilizes multiple systems. Even when the same user uses the system A and the system B, the system must be used by logging in independently using the accounts a and b of the respective systems.
図２はこの発明を実施後、複数システムを利用するフロー図である。
本発明は、図１をベースにして、システムＡ（マスターアカウントシステム、下同）とシステムＢ（サービスシステム、下同）の通信経路中、それぞれのマスター代理とサービス代理を設置する。
ユーザはサービスシステムアクセス中、サービス代理を監視して認証ＮＧの場合、マスターアカウントシステムへ認証依頼をする。マスター代理も通信を監視してマスターアカウントシステム認証ＮＧの場合、ユーザにマスターアカウントシステムをログインさせる。認証ＯＫの場合、マスター代理はサービス代理と情報交換、ユーザはパスワード知らずアカウントｂでサービスシステムＢへログインさせて、ログイン結果のアカウントｂ認証トークンをサービス代理経由して、ユーザに返す。ユーザ次回から、アカウントｂの認証トークンを利用して、サービスシステムを利用する。
FIG. 2 is a flowchart for using a plurality of systems after implementing the present invention.
In the present invention, based on FIG. 1, a master agent and a service agent are installed in a communication path between a system A (master account system, lower part) and a system B (service system, lower part).
While accessing the service system, the user monitors the service proxy and, in the case of authentication NG, makes an authentication request to the master account system. The master proxy also monitors the communication, and in the case of master account system authentication NG, the user logs in the master account system. In the case of authentication OK, the master proxy exchanges information with the service proxy, the user logs in to the service system B with the account b without knowing the password, and returns the account b authentication token of the login result to the user via the service proxy. From the user next time, the service system is used by using the authentication token of the account b.
図３はマスターアカウントシステム、サービスシステムともＷＥＢシステムの場合、本発明を実施する処理フローを説明する図である。下記で各ステップを詳細に説明する。
前提：
１．マスター代理はマスターアカウントシステムと同じドメインの下。
２．サービス代理はサービスシステムと同じドメインの下。
３．サービス代理はサービスシステムのアカウント管理権限持つアカウントSを利用可能。
図のステップ番号の書き方の説明：
１．ステップを表現する矢印は左から右への場合、ステップ番号を矢印開始位置の上で書く
２．ステップを表現する矢印は右から左への場合、ステップ番号を矢印開始位置の下で書く
３．図４も同じ
FIG. 3 is a diagram for explaining the processing flow for implementing the present invention when both the master account system and the service system are WEB systems. Each step will be described in detail below.
Assumptions:
1. The master proxy is under the same domain as the master account system.
2. The service agent is under the same domain as the service system.
3. Service surrogate can use Account S with account management authority for the service system.
How to write the step number in the figure:
1. If the arrow representing the step is from left to right, write the step number above the arrow start position. 2. If the arrow representing the step is from right to left, write the step number under the arrow start position. The same applies to FIG.
ステップ３．１：利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。例えば、ブラウザのお気に入れから、サービスシステムのメインメニューへアクセスする。 Step 3.1: The user accesses the service system via the service agent in order to use the service system. For example, access to the main menu of the service system from the preference of the browser.
ステップ３．２：サービスシステムはステップ３．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ３．３へ。認証NGの場合、ステップ３．４へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
Step 3.2: The service system returns a response to the access request at Step 3.1. The service agent checks this response and determines the authentication result. If authentication is OK, go to step 3.3. In case of authentication NG, go to step 3.4.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK.
ステップ３．３；認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。 Step 3.3: If the authentication is OK, the service agent returns to the user side without processing the response of the service system. Processing ends.
ステップ３．４：認証NGの場合、サービス代理はサービスシステムのレスポンスを利用者側へ返せず、ステップ３．１のサービスシステムアクセスURL情報も添付してマスターアカウントシステムへのリダイレクトを返す。ステップ３．５へ。 Step 3.4: In the case of authentication NG, the service proxy does not return the response of the service system to the user side, but returns the redirect to the master account system with the service system access URL information of Step 3.1 attached. Go to step 3.5.
ステップ３．５：利用者側のブラウザはサービス代理から戻ってくるリダイレクト指示を受けて、マスターアカウントシステムへ認証チェックURLへアクセス。マスター代理はアクセスを受けて、マスターアカウントシステムのログイン利用者情報取得可能なおページへアクセス。
一般的に、認証チェックURLはマスターアカウントシステム上として無効、マスター代理しか認識できない特殊URLである。たとえば、/sauth/accountの形式である。マスターアカウントシステムのログイン利用者情報取得可能なおページというものは、一般的にログインユーザのアカウント情報ページである。
Step 3.5: The browser on the user side receives the redirect instruction returned from the service agent, and accesses the authentication check URL to the master account system. The master proxy receives access and accesses the page where login user information can be obtained in the master account system.
Generally, the authentication check URL is invalid as a master account system, and is a special URL that only the master proxy can recognize. For example, / sauth / account. A page that can acquire login user information of the master account system is generally an account information page of a login user.
ステップ３．６：マスターアカウントシステムはステップ３．５のアクセスリクエストに対して、レスポンスを返す。マスター代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ７へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
Step 3.6: The master account system returns a response to the access request in Step 3.5. The master proxy checks this response to determine the authentication result. If authentication is OK, go to Step 7. In case of authentication NG, go to step 3.8.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK.
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを取得して、暗号化の上、サービスステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する かつ bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。 Step 3.7: The master proxy analyzes the response of step 3.6, obtains the account information a of the logged-in user, is encrypted, is invalid on the service system, and the account synchronization URL that only the service proxy can recognize Send to. The account synchronization URL is of the form / sauth / syncAccount. In response to this request, the service agent checks whether the account b of the mapped service system exists for the account a of the master account system. To 3.14, otherwise go to step 3.13.
ステップ３．８：マスター代理は認証NGを判断する場合、マスター代理自身を経由して、マスターシステムのログイン画面へアクセスする。 Step 3.8: When the master proxy determines authentication NG, the master proxy accesses the login screen of the master system via the master proxy itself.
ステップ３．９：ステップ３．８のアクセスリクエストに対して、マスターアカウントシステムはログイン画面を返す。マスター代理はログイン画面に識別情報を埋め込んでから、利用者側のブラウザへ帰す。例として、識別情報というものは、このログインはマスター代理からくるものを表現する画面見えない入力項目である。そして、ステップ３．５で添付されたサービスシステムアクセスURLも埋め込む。 Step 3.9: In response to the access request in Step 3.8, the master account system returns a login screen. The master agent embeds the identification information in the login screen and then returns it to the user's browser. As an example, identification information is an input item that cannot be seen on the screen, which represents what the login comes from the master proxy. The service system access URL attached in step 3.5 is also embedded.
ステップ３．１０：利用者はマスターアカウントシステムのアカウントaとパスワードを入力して、マスター代理を経由して、ログインをする。
マスター代理は通信を監視するが、ステップ３．９で埋め込んだ識別情報がある場合のみ、監視対象とする。
Step 3.10: The user inputs the account a and password of the master account system, and logs in via the master proxy.
The master proxy monitors the communication, but only when there is the identification information embedded in step 3.9.
ステップ３．１１:マスターアカウントシステムはステップ３．１０のアカウントaとパスワードをチェックして、認証結果レスポンスを返す。マスター代理はこの結果レスポンスを解析して、認証OKの場合、認証OKトークンを添付して、ステップ３．１２へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。認証OKトークンというものは、一般的にクッキーの形式である。
Step 3.11: The master account system checks the account a and password in step 3.10 and returns an authentication result response. The master proxy analyzes the response, and if authentication is OK, attaches an authentication OK token and goes to step 3.12. In case of authentication NG, go to step 3.8.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK. An authentication OK token is generally in the form of a cookie.
ステップ３．１２：ステップ３．９で埋め込んだサービスシステムアクセスURL情報を添付して、ステップ３．５と同じマスターアカウントシステムへ認証チェックURLへリダイレクトする。
この時、利用者側ブラウザを経由リダイレクトなので、ステップ３．１１からもらったマスターシステムの認証トークンはブラウザ側で保管され、認証チェックURLにも付いてアクセスする。ステップ３．６の認証結果はOKになる。
Step 3.12: The service system access URL information embedded in step 3.9 is attached, and the authentication check URL is redirected to the same master account system as in step 3.5.
At this time, since it is redirected via the browser on the user side, the authentication token of the master system received from step 3.11 is stored on the browser side and accessed with the authentication check URL. The authentication result in step 3.6 is OK.
ステップ３．１３：この時、サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ３．７の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ３．７の判断＝マッピングされ、かつ アカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ７で利用できるように、アカウントa → アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ３．１４へ。
Step 3.13: At this time, the service agent receives the information of the account a of the master account system and synchronizes the account information with the service system.
In step 3.7, if not mapped, a service system account b is generated based on the account information a, and b is newly registered in the service system using the service system account S. At that time, the password for b is generated with a random number.
Judgment in Step 3.7 = mapped and if the information of accounts a and b does not match, based on account information a, update service system account b information and use service system account S, Update b to the service system.
After the account information is synchronized with the service system, the account a → account b mapping relationship and the account b information are stored so that they can be used in the next step 7.
Go to step 3.14 with account b information.
ステップ３．１４：アカウントｂとパスワードを利用して、サービスシステムへログインする。ステップ３．１５へ。 Step 3.14: Log in to the service system using account b and password. Go to step 3.15.
ステップ３．１５：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理は認証用トークン内容を暗号化してステップ３．６の呼び出す元のマスター代理へ返す。
マスター代理は暗号化されるサービスシステム認証用トークン内容とステップ３．５で受けたサービスシステムアクセスURLと一緒に利用者側ブラウザへ返して、ステップ３．１６へ。
Step 3.15: Now that the login is successful, the authentication token (typically a cookie) is returned to the service agent. The service proxy encrypts the contents of the authentication token and returns it to the calling master proxy in step 3.6.
The master proxy returns the encrypted service system authentication token content and the service system access URL received in step 3.5 to the user side browser, and proceeds to step 3.16.
ステップ３．１６：ステップ３．１５からもらった暗号化認証トークンとサービスシステムアクセスURLを添付して、サービス代理の認証代理URLへリダイレクトする。ステップ３．１７へ
サービス代理の認証代理URLというものは、サービスシステム上無効なサービス代理しか認証できないURLである。例えば、/sauth/authProxyの形式である。
Step 3.16: Attach the encrypted authentication token and service system access URL received from step 3.15, and redirect to the service proxy authentication proxy URL. To Step 3.17 The service proxy authentication proxy URL is a URL that can only authenticate a service proxy that is invalid on the service system. For example, the format is / sauth / authProxy.
ステップ３．１７：ステップ３．１６で添付された暗号化トークンを復号化して、サービスシステムの認証トークン（一般的にクッキーの形式である）として、利用者側ブラウザ経由して、ステップ３．１６で添付されたサービスステムアクセスURLを利用してステップ３．１へ
この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ３．１の次、サービスシステムの認証OKになって、ステップ３．３で処理終了になる。
Step 3.17: The encrypted token attached in Step 3.16 is decrypted and used as a service system authentication token (generally in the form of a cookie) via the user-side browser, Step 3.16. At this time, the service system authentication token is stored in the browser on the user side, so the service system authentication is OK after step 3.1. Thus, the process ends at step 3.3.
図３の実施に対して、１つ無視できない課題は存在する。サービスシステムへの接続は暗号化される場合（https）サービス代理をサービスシステムのファイアウォールの裏側（https通信範囲外）に置かないと、サービスシステム本体まで通信内容は監視不可。サービス代理として、動作できないことである。
この課題を解決する手段はいろいろあるが、下記の３つ方法で説明する：
１．サービス代理の設置はサービスシステム運営側に実施してもらう。
２．利用者の利用場所は限定的なの場合、サービスシステムの外部にサービス代理を設置するが、サービス代理のipをサービスシステムのドメインとして利用場所範囲のdnsに登録する。サービス代理は図３のステップ７以外の接続を本当のサービスシステムへ転送する。そうすれば、利用者はサービス代理経由して、サービスシステムを利用することが確保される。サービス代理上自己署名のssl証書を使うが、マスター代理と利用場所の信任CAに登録すれば、セキュリティ問題にならない
３．２と同じように設置するが、サービス代理はサービスシステムのドメインを使わなく、サービスシステムと異なるサービス代理ドメインを使う。２と同じように接続をサービスシステムへ転送するが、返ってくるレスポンスのサービスシステムドメインをサービス代理ドメインへ変換してから返す。利用者側はサービス代理ドメインを利用して、サービスシステムを利用する。
上記の方法は、課題が解決できることを説明するための例として使う。上記の方法に限らず、サービスシステムにアクセス経路中、サービス代理を設置し、アクセスを監視できれば、どんな方法でも利用可能。
There is one problem that cannot be ignored with respect to the implementation of FIG. When the connection to the service system is encrypted (https) If the service proxy is not placed behind the firewall of the service system (outside the https communication range), the communication contents cannot be monitored until the service system itself. Inability to operate as a service agent.
There are various ways to solve this problem, but it is explained in the following three ways:
1. Have the service system operator install the service agent.
2. If the user's usage location is limited, a service agent is installed outside the service system, but the service agent's ip is registered in the dns of the usage location range as the service system domain. The service agent forwards the connection other than step 7 in FIG. 3 to the real service system. Then, it is ensured that the user uses the service system via the service agent. Self-signed ssl certificate is used on the service agent, but if it is registered with the master agent and the trusted CA of the place of use, it will be installed in the same way as 3.2, but the service agent does not use the service system domain Use a service proxy domain that is different from the service system. The connection is transferred to the service system in the same way as in 2, but the service system domain of the response returned is converted to the service proxy domain and returned. The user uses the service system using the service proxy domain.
The above method is used as an example for explaining that the problem can be solved. Not limited to the above methods, any method can be used as long as a service agent can be installed in the service system and monitored for access.
図４は図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図。その時、図３のマスター代理は省略可能。 FIG. 4 is a diagram for explaining the implementation of the present invention using an existing authentication technique (here, OAuth1.0a is taken as an example) as a special example of FIG. At that time, the master proxy in FIG. 3 can be omitted.
ステップ４．１は図３のステップ３．１と同じく、利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。 Step 4.1 is the same as Step 3.1 in FIG. 3, and the user accesses the service system via the service agent in order to use the service system.
テップ４．２：サービスシステムはステップ４．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ４．３へ。認証NGの場合、ステップ４．４へ。 Step 4.2: The service system returns a response to the access request in step 4.1. The service agent checks this response and determines the authentication result. If authentication is OK, go to step 4.3. In the case of authentication NG, go to step 4.4.
ステップ４．３：認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。 Step 4.3: If the authentication is OK, the service agent does not process the response of the service system and returns it to the user as it is. Processing ends.
ステップ４．４：認証NGの場合、サービス代理はOAuth仕様により、マスターアカウントシステムへ認証要求アクセスを利用者側のブラウザへ返す。 Step 4.4: In the case of authentication NG, the service proxy returns authentication request access to the master account system to the browser on the user side according to the OAuth specification.
ステップ４．５：利用者側のブラウザはステップ４．４のレスポンスを受けて、マスターアカウントシステムへリダイレクトする。 Step 4.5: The browser on the user side receives the response of Step 4.4 and redirects to the master account system.
ステップ４．６：マスターアカウントシステムはOAuth仕様により、認証（権限承認）画面を利用者側のブラウザへ返す。 Step 4.6: The master account system returns an authentication (authorization approval) screen to the browser on the user side according to the OAuth specification.
ステップ４．７：ユーザはマスターアカウントシステムのユーザaとして、認証（権限承認）する。 Step 4.7: The user authenticates (authorizes authorization) as the user a of the master account system.
ステップ４．８：マスターアカウントシステムはOAuthの仕様により、認証（権限承認）OKの場合、リクエストトークンを発行して、ステップ４．９へ。認証NGの場合、ステップ４．５へ戻る。権限承認NGの場合、エラー終了。 Step 4.8: The master account system issues a request token if authentication (authorization approval) is OK according to the OAuth specification, and goes to Step 4.9. In the case of authentication NG, the process returns to step 4.5. If the authorization is NG, the process ends in error.
ステップ４．９：OAuthの仕様により、ステップ４．８で受けたリクエストトークンをサービスシステムへリダイレクトする。 Step 4.9: Redirect the request token received in Step 4.8 to the service system according to the OAuth specification.
ステップ４．１０：OAuthの仕様により、サービス代理はステップ４．９のリクエストトークンを受けて、このリクエストトークンを使って、マスターアカウントシステムへアクセストークンを請求する。 Step 4.10: According to the OAuth specification, the service agent receives the request token of Step 4.9 and uses this request token to request an access token from the master account system.
ステップ４．１１：OAuthの仕様により、マスターアカウントシステムはサービス代理へアクセストークンを返す。 Step 4.11: According to the OAuth specification, the master account system returns an access token to the service agent.
ステップ４．１２：OAuthの仕様により、サービス代理はアクセストークンを使って、マスターアカウントシステムへアカウントaの情報を請求する。 Step 4.12: According to the OAuth specification, the service agent requests the account a information from the master account system using the access token.
ステップ４．１３：OAuthの仕様により、マスターアカウントシステムはアカウントaの情報を返す。 Step 4.13: According to the OAuth specification, the master account system returns account a information.
ステップ４．１４：図３の３．７の部分に相当。サービス代理はマスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する かつ bの情報とaは一致する場合、ステップ４．１５へ、その他の場合、ステップ４．１６へ。 Step 4.14: Corresponds to the portion 3.7 in FIG. The service agent checks whether the account b of the mapped service system exists for the account a of the master account system, and if it exists and the information of b matches a, go to step 4.15, etc. If so, go to step 4.16.
ステップ４．１５：図３の３．１３に相当。サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ４．１４の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ４．１４の判断＝マッピングされ、かつ アカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ４．１４で利用できるように、アカウントa → アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ４．１６へ。
Step 4.15: Corresponds to 3.13 in FIG. The service agent receives the information of the account a of the master account system and synchronizes the account information with the service system.
Step 4.14 = If not mapped, a service system account b is generated based on the account information a, and b is newly registered in the service system using the service system account S. At that time, the password for b is generated with a random number.
Step 4.14 decision = mapped and if the information of accounts a and b do not match, update service system account b information based on account information a and use service system account S, Update b to the service system.
After the account information is synchronized with the service system, the account a → account b mapping relationship and the account b information are saved so that they can be used in the next step 4.14.
Go to step 4.16 with account b information.
ステップ４．１７：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理の呼び元は利用者側のブラウザので、そのまま認証トークンを含めて、ステップ４．１のアクセスURLへリダイレクトレスポンスを利用者側のブラウザへ返す。ステップ４．１８へ。 Step 4.17: Now that the login is successful, the authentication token (typically a cookie) is returned to the service agent. Since the caller of the service proxy is the browser on the user side, the redirect response to the access URL in step 4.1 is returned to the browser on the user side, including the authentication token as it is. Go to step 4.18.
ステップ４．１８：図３のステップ３．１９に相当。ステップ４．１のアクセスURLへリダイレクトする。この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ４．１の次、サービスシステムの認証OKになって、ステップ４．３で処理終了になる。 Step 4.18: Corresponds to step 3.19 of FIG. Redirect to the access URL in step 4.1. At this time, since the authentication token of the service system is stored in the browser on the user side, the authentication of the service system is OK after step 4.1, and the process ends at step 4.3.
例えば、A社は既に社内業務管理システムMを利用しているが、社外掲示板サービス提供するSシステムを利用したい。本発明を利用すれば、社内業務管理システムのアカウント管理をマスターアカウントシステムとして、掲示板システムSをサービスシステムとして、社内業務管理システムのアカウントを利用して、社外掲示板サービスを利用可能になる。
当然、マスターアカウントシステムはドメインシステムを利用しても構わない。アカウント管理機能を提供、そして、第三者のプログラムは認証、アカウント情報取得できれば、どんなシステムでもマスターアカウントシステムとして利用可能。
For example, Company A already uses the internal business management system M, but wants to use the S system that provides an external bulletin board service. If the present invention is used, the external bulletin board service can be used by using the account management of the internal business management system as the master account system, the bulletin board system S as the service system, and the account of the internal business management system.
Of course, the master account system may use a domain system. It provides account management functions, and any third-party program can be used as a master account system as long as it can authenticate and obtain account information.
この発明は、複数コンピュータシステム間のアカウント認証と管理を１本化させて、システム統合コストを削減して、セキュリティーを強化する。 The present invention unifies account authentication and management between a plurality of computer systems, reduces system integration costs, and enhances security.
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを自動取得して、暗号化の上、サービスステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する かつ bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。
上記のレスポンスからログインユーザのアカウント情報自動取得方法は、既に認識用アカウントを作成して（例えばテスト太郎、東京支社、システム開発部、２課、係長）、定期（例えば日次）このアカウントを利用して、アカウント情報ページにアクセスして、アカウント情報を利用して、各項目の画面位置を解析して、この画面位置情報を利用して、上記のアカウント情報aを取得する
Step 3.7: The master proxy analyzes the response of step 3.6, automatically acquires the login user's account information a, synchronizes the account that is encrypted, invalid on the service system, and can only recognize the service proxy Send to URL. The account synchronization URL is of the form / sauth / syncAccount. In response to this request, the service agent checks whether the account b of the mapped service system exists for the account a of the master account system. To 3.14, otherwise go to step 3.13.
From the above response, the login user's account information automatic acquisition method has already created a recognition account (for example, Test Taro, Tokyo Branch, System Development Department,
この発明は、複数既存コンピュータシステム間のアカウント認証情報を共通利用できる複数コンピュータシステムの認証連携システムである The present invention is an authentication linkage system for a plurality of computer systems that can commonly use account authentication information among a plurality of existing computer systems.
現状として、情報処理するために、１つ１つ特定機能を実現するため、各コンピュータシステムは開発された。基本的にこんなコンピュータシステムはユーザID、パスワードをペアにして利用者を認証している。
開発時期、開発技術、開発担当会社はバラバラなので、同じ利用者でも各システムの認証部分も独立して、それぞれのユーザID、パスワードを使ってシステム利用しないといけないことは多い。SSO（シングルサインオン）という技術はあるが、この技術を導入すると、既存システムに対して改修しないといけないので、導入コストとリスクが高くなる。
そして、業務を一連システムで実現する場合、各システム間でアカウント情報（有効性、氏名、部署など）の連携は個別するので、管理コストとセキュリティ問題はある。
Currently, each computer system has been developed to realize specific functions one by one for information processing. Basically, such a computer system authenticates a user by pairing a user ID and a password.
Since the development time, development technology, and company in charge of development vary, it is often necessary to use the system with the same user ID and password independently from each other even if the same user. There is a technology called SSO (single sign-on), but if this technology is introduced, the existing system must be modified, which increases the cost and risk of introduction.
When the business is realized by a series of systems, there is a management cost and a security problem because account information (validity, name, department, etc.) is individually linked between the systems.
この発明は下記の課題を解決することを目指します。
１．同じ利用者は複数システム利用するとき、アカウントとパスワードを複数管理することによって、管理コストとセキュリティ課題
２．同じ利用者は複数システム一括利用出来なくなるとき、システム認証不可手続き漏れ発生のセキュリティ課題
３．同じ利用者の複数システム個人情報自動連携課題
The present invention aims to solve the following problems.
1. Management costs and security issues by managing multiple accounts and passwords when the same user uses multiple systems. 2. Security problem of system authentication failure procedure omission when the same user cannot use multiple systems at once. Multi-system personal information automatic cooperation problem of the same user
まず、用語を説明する
１．メインアカウントを管理するシステムをマスターアカウントシステムと呼ぶ
２．ネットワーク設定上、マスターアカウントシステムをアクセス時、必ず経由するプログラムをマスター代理と呼ぶ（WEBシステムの場合、HTTPサーバのモジュールである）
３．自体アカウント機能を利用しなく、サービス機能を利用するシステムをサービスシステムと呼ぶ（アカウント認証と管理は本発明により、マスターアカウントシステムに委託する）
４．２と似る、ネットワーク設定上、サービスシステムをアクセス時、必ず経由するプログラムをサービス代理と呼ぶ
課題を解決する手段：
１．利用者は特定なネットワーク設定の上、マスターアカウントシステムの前にマスター代理、サービスシステム前にサービス代理を設定する
２．利用者はサービスシステム未認証時、サービス代理は利用者をマスターアカウントシステムの認証フローに案内する
３．マスター代理はマスターアカウントシステム認証結果を監視し、成功する場合、サービスシステムのサービス代理を経由して、サービスシステムのアカウントの情報を連携するうえ、認証トークンを取得する
４．サービスシステムの認証トークン（一般的にCookieを使う）を利用者クライアントに返して、サービスシステムを利用する
First, terms will be explained. 1. A system that manages the main account is called a master account system. When accessing the master account system for network settings, the program that is always passed through is called the master proxy (in the case of the WEB system, it is an HTTP server module)
3. A system that does not use the account function itself but uses the service function is called a service system (account authentication and management are entrusted to the master account system according to the present invention).
Similar to 4.2, the network that is always accessed when accessing the service system is called a service proxy.
Means to solve the problem:
1. 1. The user sets the master proxy before the master account system and the service proxy before the service system after specific network settings. 2. When the user is unauthenticated, the service agent guides the user to the master account system authentication flow. The master proxy monitors the master account system authentication result and, if successful, links the service system account information and obtains an authentication token via the service proxy of the service system. Return the service system authentication token (usually using cookies) to the user client and use the service system
本発明に係る複数コンピュータシステムの認証連携システムは、利用者のメインアカウントを管理するマスターアカウントシステムと、該マスターアカウントシステムの通信経路中に、前記マスターアカウントシステムにアクセスする時に必ず経由するマスター代理と、該利用者が利用したいサービスシステムと、前記サービスシステムの通信経路中に、前記サービスシステムにアクセスする時に必ず経由するサービス代理とを設置して、 An authentication linkage system for a plurality of computer systems according to the present invention includes a master account system that manages a user's main account, and a master proxy that is always passed when accessing the master account system during a communication path of the master account system. , A service system that the user wants to use and a service agent that is always passed when accessing the service system in the communication path of the service system;
利用者が前記サービスシステム利用する場合、前記サービス代理は通信を監視し、ログイン認証が必要な場合、前記マスターアカウントシステムへ認証を依頼して、 When a user uses the service system, the service agent monitors communication, and when login authentication is required, requests authentication to the master account system,
前記マスター代理はこの依頼を監視して、前記マスターアカウントシステムのアカウント情報ページの内容を取得して、ログイン認証成功後、前記サービス代理と連携し、前記マスターアカウントシステムのアカウント情報がマッピングされない場合は、前記アカウント情報をベースにして、サービスシステムアカウントと乱数でパスワードを生成し、前記サービスシステムのアカウント管理権限を持つアカウントを利用して、前記サービスシステムに上記生成したサービスシステムアカウントの新規登録を行う一方、前記マスターアカウントシステムのアカウント情報がマッピングされ、且つマッピングされた前記サービスシステムのアカウント情報と前記マスターアカウントシステムのアカウント情報が不一致な場合は、前記マスターアカウントシステムのアカウント情報をベースに、前記サービスシステムのアカウント情報を更新するステップを経て前記サービスシステムのアカウント情報のマッピング関係と前記サービスシステムのアカウント情報を保存し、その後、代理ログイン処理後認証トークンをクライアントへ返し、利用者は前記サービスシステムを利用できる。 The master agent monitors this request, acquires the contents of the account information page of the master account system, cooperates with the service agent after successful login authentication, and the account information of the master account system is not mapped Based on the account information, a password is generated with a service system account and a random number, and the generated service system account is newly registered in the service system using an account having the account management authority of the service system. On the other hand, if the account information of the master account system is mapped and the account information of the mapped service system does not match the account information of the master account system, the master account system The service system account information mapping relation and the service system account information are stored through the step of updating the service system account information based on the account system account information, and then an authentication token is processed after proxy login processing. Returning to the client, the user can use the service system.
本発明において、前記サービスシステムにログイン認証がNGとされた場合、 In the present invention, when login authentication is NG in the service system,
前記サービス代理は、前記サービスシステムのログイン認証がNGというレスポンスを利用者に返さず、前記サービスシステムのアクセスURL情報を添付して前記マスターアカウントシステムにリダイレクトするようにしてもよい。 The service proxy may redirect the master account system with the access URL information of the service system without returning a response that the login authentication of the service system is NG to the user.
また本発明において、 前記マスター代理は、前記サービス代理から戻ってくるリダイレクトアクセスを受けて、前記マスターアカウントシステムのログイン利用者情報取得可能なページへアクセスしてログイン利用者のアカウント情報を取得するようにしてもよい。 Also, in the present invention, the master proxy receives a redirect access returned from the service proxy, and accesses a login user information acquisition page of the master account system to acquire login user account information. It may be.
１．外部システムを内部に導入するとき、アカウント管理コストを削減する。システム連携もしやすくなる
２．社員退社後の外部サービス無効化の忘れ問題を回避して、セキュリティを強化する
３．アカウント連携後、サービス機能の連携も可能になる
1. Reduce account management costs when introducing external systems internally.
本発明の実施形態について、図面の参照しながら詳細に説明する。 Embodiments of the present invention will be described in detail with reference to the drawings.
図１は現在複数システムを利用するフロー図である。同じユーザでも、システムＡとシステムＢを利用時、それぞれ各システムのアカウントaとbを使って独立ログインして、システムを利用しないといけない。 FIG. 1 is a flow diagram that currently utilizes multiple systems. Even when the same user uses the system A and the system B, the system must be used by logging in independently using the accounts a and b of the respective systems.
図２はこの発明を実施後、複数システムを利用するフロー図である。
本発明は、図１をベースにして、システムＡ（マスターアカウントシステム、下同）とシステムＢ（サービスシステム、下同）の通信経路中、それぞれのマスター代理とサービス代理を設置する。
ユーザはサービスシステムアクセス中、サービス代理を監視して認証ＮＧの場合、マスターアカウントシステムへ認証依頼をする。マスター代理も通信を監視してマスターアカウントシステム認証ＮＧの場合、ユーザにマスターアカウントシステムをログインさせる。認証ＯＫの場合、マスター代理はサービス代理と情報交換、ユーザはパスワード知らずアカウントｂでサービスシステムＢへログインさせて、ログイン結果のアカウントｂ認証トークンをサービス代理経由して、ユーザに返す。ユーザ次回から、アカウントｂの認証トークンを利用して、サービスシステムを利用する。
FIG. 2 is a flowchart for using a plurality of systems after implementing the present invention.
In the present invention, based on FIG. 1, a master agent and a service agent are installed in a communication path between a system A (master account system, lower part) and a system B (service system, lower part).
While accessing the service system, the user monitors the service proxy and, in the case of authentication NG, makes an authentication request to the master account system. The master proxy also monitors the communication, and in the case of master account system authentication NG, the user logs in the master account system. In the case of authentication OK, the master proxy exchanges information with the service proxy, the user logs in to the service system B with the account b without knowing the password, and returns the account b authentication token of the login result to the user via the service proxy. From the user next time, the service system is used by using the authentication token of the account b.
図３はマスターアカウントシステム、サービスシステムともＷＥＢシステムの場合、本発明を実施する処理フローを説明する図である。下記で各ステップを詳細に説明する。
前提：
１．マスター代理はマスターアカウントシステムと同じドメインの下。
２．サービス代理はサービスシステムと同じドメインの下。
３．サービス代理はサービスシステムのアカウント管理権限持つアカウントSを利用可能。
図のステップ番号の書き方の説明：
１．ステップを表現する矢印は左から右への場合、ステップ番号を矢印開始位置の上で書く
２．ステップを表現する矢印は右から左への場合、ステップ番号を矢印開始位置の下で書く
３．図４も同じ
FIG. 3 is a diagram for explaining the processing flow for implementing the present invention when both the master account system and the service system are WEB systems. Each step will be described in detail below.
Assumptions:
1. The master proxy is under the same domain as the master account system.
2. The service agent is under the same domain as the service system.
3. Service surrogate can use Account S with account management authority for the service system.
How to write the step number in the figure:
1. If the arrow representing the step is from left to right, write the step number above the arrow start position. 2. If the arrow representing the step is from right to left, write the step number under the arrow start position. The same applies to FIG.
ステップ３．１：利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。例えば、ブラウザのお気に入れから、サービスシステムのメインメニューへアクセスする。 Step 3.1: The user accesses the service system via the service agent in order to use the service system. For example, access to the main menu of the service system from the preference of the browser.
ステップ３．２：サービスシステムはステップ３．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ３．３へ。認証NGの場合、ステップ３．４へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
Step 3.2: The service system returns a response to the access request at Step 3.1. The service agent checks this response and determines the authentication result. If authentication is OK, go to step 3.3. In case of authentication NG, go to step 3.4.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK.
ステップ３．３；認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。 Step 3.3: If the authentication is OK, the service agent returns to the user side without processing the response of the service system. Processing ends.
ステップ３．４：認証NGの場合、サービス代理はサービスシステムのレスポンスを利用者側へ返せず、ステップ３．１のサービスシステムアクセスURL情報も添付してマスターアカウントシステムへのリダイレクトを返す。ステップ３．５へ。 Step 3.4: In the case of authentication NG, the service proxy does not return the response of the service system to the user side, but returns the redirect to the master account system with the service system access URL information of Step 3.1 attached. Go to step 3.5.
ステップ３．５：利用者側のブラウザはサービス代理から戻ってくるリダイレクト指示を受けて、マスターアカウントシステムへ認証チェックURLへアクセス。マスター代理はアクセスを受けて、マスターアカウントシステムのログイン利用者情報取得可能なおページへアクセス。
一般的に、認証チェックURLはマスターアカウントシステム上として無効、マスター代理しか認識できない特殊URLである。たとえば、/sauth/accountの形式である。マスターアカウントシステムのログイン利用者情報取得可能なおページというものは、一般的にログインユーザのアカウント情報ページである。
Step 3.5: The browser on the user side receives the redirect instruction returned from the service agent, and accesses the authentication check URL to the master account system. The master proxy receives access and accesses the page where login user information can be obtained in the master account system.
Generally, the authentication check URL is invalid as a master account system, and is a special URL that only the master proxy can recognize. For example, / sauth / account. A page that can acquire login user information of the master account system is generally an account information page of a login user.
ステップ３．６：マスターアカウントシステムはステップ３．５のアクセスリクエストに対して、レスポンスを返す。マスター代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ７へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。
Step 3.6: The master account system returns a response to the access request in Step 3.5. The master proxy checks this response to determine the authentication result. If authentication is OK, go to Step 7. In case of authentication NG, go to step 3.8.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK.
ステップ３．７：マスター代理はステップ３．６のレスポンスを解析して、ログインユーザのアカウント情報aを取得して、暗号化の上、サービスシステム上無効、サービス代理しか認識できないのアカウント同期化URLへ送信する。アカウント同期化URLというものは、/sauth/syncAccountの形式である。サービス代理はこのリクエストを受けて、マスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する かつ bの情報とaは一致する場合、ステップ３．１４へ、その他の場合、ステップ３．１３へ。 Step 3.7: The master proxy analyzes the response of step 3.6, obtains the account information a of the logged-in user, encrypts it, disables it on the service system, and can only recognize the service proxy URL Send to. The account synchronization URL is of the form / sauth / syncAccount. In response to this request, the service agent checks whether the account b of the mapped service system exists for the account a of the master account system. To 3.14, otherwise go to step 3.13.
ステップ３．８：マスター代理は認証NGを判断する場合、マスター代理自身を経由して、マスターシステムのログイン画面へアクセスする。 Step 3.8: When the master proxy determines authentication NG, the master proxy accesses the login screen of the master system via the master proxy itself.
ステップ３．９：ステップ３．８のアクセスリクエストに対して、マスターアカウントシステムはログイン画面を返す。マスター代理はログイン画面に識別情報を埋め込んでから、利用者側のブラウザへ帰す。例として、識別情報というものは、このログインはマスター代理からくるものを表現する画面見えない入力項目である。そして、ステップ３．５で添付されたサービスシステムアクセスURLも埋め込む。 Step 3.9: In response to the access request in Step 3.8, the master account system returns a login screen. The master agent embeds the identification information in the login screen and then returns it to the user's browser. As an example, identification information is an input item that cannot be seen on the screen, which represents what the login comes from the master proxy. The service system access URL attached in step 3.5 is also embedded.
ステップ３．１０：利用者はマスターアカウントシステムのアカウントaとパスワードを入力して、マスター代理を経由して、ログインをする。
マスター代理は通信を監視するが、ステップ３．９で埋め込んだ識別情報がある場合のみ、監視対象とする。
Step 3.10: The user inputs the account a and password of the master account system, and logs in via the master proxy.
The master proxy monitors the communication, but only when there is the identification information embedded in step 3.9.
ステップ３．１１:マスターアカウントシステムはステップ３．１０のアカウントaとパスワードをチェックして、認証結果レスポンスを返す。マスター代理はこの結果レスポンスを解析して、認証OKの場合、認証OKトークンを添付して、ステップ３．１２へ。認証NGの場合、ステップ３．８へ。
例えば、ログイン画面（特定なパスワード入力項目がある画面）、またはログイン画面へリダイレクトレスポンスである場合、認証NGとして判断する。これ以外の場合、認証OKとして判断する。認証OKトークンというものは、一般的にクッキーの形式である。
Step 3.11: The master account system checks the account a and password in step 3.10 and returns an authentication result response. The master proxy analyzes the response, and if authentication is OK, attaches an authentication OK token and goes to step 3.12. In case of authentication NG, go to step 3.8.
For example, if it is a login screen (a screen with a specific password input item) or a redirect response to the login screen, it is determined as an authentication NG. Otherwise, it is determined that authentication is OK. An authentication OK token is generally in the form of a cookie.
ステップ３．１２：ステップ３．９で埋め込んだサービスシステムアクセスURL情報を添付して、ステップ３．５と同じマスターアカウントシステムへ認証チェックURLへリダイレクトする。
この時、利用者側ブラウザを経由リダイレクトなので、ステップ３．１１からもらったマスターシステムの認証トークンはブラウザ側で保管され、認証チェックURLにも付いてアクセスする。ステップ３．６の認証結果はOKになる。
Step 3.12: The service system access URL information embedded in step 3.9 is attached, and the authentication check URL is redirected to the same master account system as in step 3.5.
At this time, since it is redirected via the browser on the user side, the authentication token of the master system received from step 3.11 is stored on the browser side and accessed with the authentication check URL. The authentication result in step 3.6 is OK.
ステップ３．１３：この時、サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ３．７の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ３．７の判断＝マッピングされ、かつアカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ７で利用できるように、アカウントa → アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ３．１４へ。
Step 3.13: At this time, the service agent receives the information of the account a of the master account system and synchronizes the account information with the service system.
In step 3.7, if not mapped, a service system account b is generated based on the account information a, and b is newly registered in the service system using the service system account S. At that time, the password for b is generated with a random number.
In step 3.7, if the information of the accounts a and b does not match, the service system account b information is updated based on the account information a, and the service system account S is used. Update b to the service system.
After the account information is synchronized with the service system, the account a → account b mapping relationship and the account b information are stored so that they can be used in the next step 7.
Go to step 3.14 with account b information.
ステップ３．１４：アカウントｂとパスワードを利用して、サービスシステムへログインする。ステップ３．１５へ。 Step 3.14: Log in to the service system using account b and password. Go to step 3.15.
ステップ３．１５：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理は認証用トークン内容を暗号化してステップ３．６の呼び出す元のマスター代理へ返す。
マスター代理は暗号化されるサービスシステム認証用トークン内容とステップ３．５で受けたサービスシステムアクセスURLと一緒に利用者側ブラウザへ返して、ステップ３．１６へ。
Step 3.15: Now that the login is successful, the authentication token (typically a cookie) is returned to the service agent. The service proxy encrypts the contents of the authentication token and returns it to the calling master proxy in step 3.6.
The master proxy returns the encrypted service system authentication token content and the service system access URL received in step 3.5 to the user side browser, and proceeds to step 3.16.
ステップ３．１６：ステップ３．１５からもらった暗号化認証トークンとサービスシステムアクセスURLを添付して、サービス代理の認証代理URLへリダイレクトする。ステップ３．１７へ
サービス代理の認証代理URLというものは、サービスシステム上無効なサービス代理しか認証できないURLである。例えば、/sauth/authProxyの形式である。
Step 3.16: Attach the encrypted authentication token and service system access URL received from step 3.15, and redirect to the service proxy authentication proxy URL. To Step 3.17 The service proxy authentication proxy URL is a URL that can only authenticate a service proxy that is invalid on the service system. For example, the format is / sauth / authProxy.
ステップ３．１７：ステップ３．１６で添付された暗号化トークンを復号化して、サービスシステムの認証トークン（一般的にクッキーの形式である）として、利用者側ブラウザ経由して、ステップ３．１６で添付されたサービスステムアクセスURLを利用してステップ３．１へ
この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ３．１の次、サービスシステムの認証OKになって、ステップ３．３で処理終了になる。
Step 3.17: The encrypted token attached in Step 3.16 is decrypted and used as a service system authentication token (generally in the form of a cookie) via the user-side browser, Step 3.16. At this time, the service system authentication token is stored in the browser on the user side, so the service system authentication is OK after step 3.1. Thus, the process ends at step 3.3.
図３の実施に対して、１つ無視できない課題は存在する。サービスシステムへの接続は暗号化される場合（https）サービス代理をサービスシステムのファイアウォールの裏側（https通信範囲外）に置かないと、サービスシステム本体まで通信内容は監視不可。サービス代理として、動作できないことである。
この課題を解決する手段はいろいろあるが、下記の３つ方法で説明する：
１．サービス代理の設置はサービスシステム運営側に実施してもらう。
２．利用者の利用場所は限定的なの場合、サービスシステムの外部にサービス代理を設置するが、サービス代理のipをサービスシステムのドメインとして利用場所範囲のdnsに登録する。サービス代理は図３のステップ７以外の接続を本当のサービスシステムへ転送する。そうすれば、利用者はサービス代理経由して、サービスシステムを利用することが確保される。サービス代理上自己署名のssl証書を使うが、マスター代理と利用場所の信任CAに登録すれば、セキュリティ問題にならない
３．２と同じように設置するが、サービス代理はサービスシステムのドメインを使わなく、サービスシステムと異なるサービス代理ドメインを使う。２と同じように接続をサービスシステムへ転送するが、返ってくるレスポンスのサービスシステムドメインをサービス代理ドメインへ変換してから返す。利用者側はサービス代理ドメインを利用して、サービスシステムを利用する。
上記の方法は、課題が解決できることを説明するための例として使う。上記の方法に限らず、サービスシステムにアクセス経路中、サービス代理を設置し、アクセスを監視できれば、どんな方法でも利用可能。
There is one problem that cannot be ignored with respect to the implementation of FIG. When the connection to the service system is encrypted (https) If the service proxy is not placed behind the firewall of the service system (outside the https communication range), the communication contents cannot be monitored until the service system itself. Inability to operate as a service agent.
There are various ways to solve this problem, but it is explained in the following three ways:
1. Have the service system operator install the service agent.
2. If the user's usage location is limited, a service agent is installed outside the service system, but the service agent's ip is registered in the dns of the usage location range as the service system domain. The service agent forwards the connection other than step 7 in FIG. 3 to the real service system. Then, it is ensured that the user uses the service system via the service agent. Self-signed ssl certificate is used on the service agent, but if it is registered with the master agent and the trusted CA of the place of use, it will be installed in the same way as 3.2, but the service agent does not use the service system domain Use a service proxy domain that is different from the service system. The connection is transferred to the service system in the same way as in 2, but the service system domain of the response returned is converted to the service proxy domain and returned. The user uses the service system using the service proxy domain.
The above method is used as an example for explaining that the problem can be solved. Not limited to the above methods, any method can be used as long as a service agent can be installed in the service system and monitored for access.
図４は図３の特例として、既存認証技術（ここはOAuth1.0aを例とする）を利用する本発明の実施を説明する図。その時、図３のマスター代理は省略可能。 FIG. 4 is a diagram for explaining the implementation of the present invention using an existing authentication technique (here, OAuth1.0a is taken as an example) as a special example of FIG. At that time, the master proxy in FIG. 3 can be omitted.
ステップ４．１は図３のステップ３．１と同じく、利用者はサービスシステムを利用するために、サービス代理を経由して、サービスシステムへアクセスする。 Step 4.1 is the same as Step 3.1 in FIG. 3, and the user accesses the service system via the service agent in order to use the service system.
テップ４．２：サービスシステムはステップ４．１のアクセスリクエストに対して、レスポンスを返す。サービス代理はこのレスポンスをチェックして、認証結果を判断する。認証OKの場合、ステップ４．３へ。認証NGの場合、ステップ４．４へ。 Step 4.2: The service system returns a response to the access request in step 4.1. The service agent checks this response and determines the authentication result. If authentication is OK, go to step 4.3. In the case of authentication NG, go to step 4.4.
ステップ４．３：認証OKの場合、サービス代理はサービスシステムのレスポンスを処理せず、そのまま利用者側へ返す。処理は終了。 Step 4.3: If the authentication is OK, the service agent does not process the response of the service system and returns it to the user as it is. Processing ends.
ステップ４．４：認証NGの場合、サービス代理はOAuth仕様により、マスターアカウントシステムへ認証要求アクセスを利用者側のブラウザへ返す。 Step 4.4: In the case of authentication NG, the service proxy returns authentication request access to the master account system to the browser on the user side according to the OAuth specification.
ステップ４．５：利用者側のブラウザはステップ４．４のレスポンスを受けて、マスターアカウントシステムへリダイレクトする。 Step 4.5: The browser on the user side receives the response of Step 4.4 and redirects to the master account system.
ステップ４．６：マスターアカウントシステムはOAuth仕様により、認証（権限承認）画面を利用者側のブラウザへ返す。 Step 4.6: The master account system returns an authentication (authorization approval) screen to the browser on the user side according to the OAuth specification.
ステップ４．７：ユーザはマスターアカウントシステムのユーザaとして、認証（権限承認）する。 Step 4.7: The user authenticates (authorizes authorization) as the user a of the master account system.
ステップ４．８：マスターアカウントシステムはOAuthの仕様により、認証（権限承認）OKの場合、リクエストトークンを発行して、ステップ４．９へ。認証NGの場合、ステップ４．５へ戻る。権限承認NGの場合、エラー終了。 Step 4.8: The master account system issues a request token if authentication (authorization approval) is OK according to the OAuth specification, and goes to Step 4.9. In the case of authentication NG, the process returns to step 4.5. If the authorization is NG, the process ends in error.
ステップ４．９：OAuthの仕様により、ステップ４．８で受けたリクエストトークンをサービスシステムへリダイレクトする。 Step 4.9: Redirect the request token received in Step 4.8 to the service system according to the OAuth specification.
ステップ４．１０：OAuthの仕様により、サービス代理はステップ４．９のリクエストトークンを受けて、このリクエストトークンを使って、マスターアカウントシステムへアクセストークンを請求する。 Step 4.10: According to the OAuth specification, the service agent receives the request token of Step 4.9 and uses this request token to request an access token from the master account system.
ステップ４．１１：OAuthの仕様により、マスターアカウントシステムはサービス代理へアクセストークンを返す。 Step 4.11: According to the OAuth specification, the master account system returns an access token to the service agent.
ステップ４．１２：OAuthの仕様により、サービス代理はアクセストークンを使って、マスターアカウントシステムへアカウントaの情報を請求する。 Step 4.12: According to the OAuth specification, the service agent requests the account a information from the master account system using the access token.
ステップ４．１３：OAuthの仕様により、マスターアカウントシステムはアカウントaの情報を返す。 Step 4.13: According to the OAuth specification, the master account system returns account a information.
ステップ４．１４：図３の３．７の部分に相当。サービス代理はマスターアカウントシステムのアカウントaに対して、マッピングされたサービスシステムのアカウントbは存在するかをチェックして、存在する かつ bの情報とaは一致する場合、ステップ４．１５へ、その他の場合、ステップ４．１６へ。 Step 4.14: Corresponds to the portion 3.7 in FIG. The service agent checks whether the account b of the mapped service system exists for the account a of the master account system, and if it exists and the information of b matches a, go to step 4.15, etc. If so, go to step 4.16.
ステップ４．１５：図３の３．１３に相当。サービス代理はマスターアカウントシステムのアカウントaの情報を受けて、サービスシステムへアカウント情報を同期する。
ステップ４．１４の判断＝マッピングされない場合、アカウント情報aをベースにして、サービスシステムアカウントbを生成して、サービスシステムのアカウントSを利用して、サービスシステムへbを新規登録する。その時、bのパスワードを乱数で生成させる。
ステップ４．１４の判断＝マッピングされ、かつアカウントaとbの情報が不一致の場合、アカウント情報aをベースにして、サービスシステムアカウントb情報を更新して、サービスシステムのアカウントSを利用して、サービスシステムへbを更新する。
サービスシステムへアカウント情報同期化後、次回のステップ４．１４で利用できるように、アカウントa → アカウントbのマッピング関係とアカウントbの情報を保存する。
アカウントbの情報を持つステップ４．１６へ。
Step 4.15: Corresponds to 3.13 in FIG. The service agent receives the information of the account a of the master account system and synchronizes the account information with the service system.
Step 4.14 = If not mapped, a service system account b is generated based on the account information a, and b is newly registered in the service system using the service system account S. At that time, the password for b is generated with a random number.
Step 4.14: If the information of the accounts a and b does not match, the service system account b information is updated based on the account information a, and the service system account S is used. Update b to the service system.
After the account information is synchronized with the service system, the account a → account b mapping relationship and the account b information are saved so that they can be used in the next step 4.14.
Go to step 4.16 with account b information.
ステップ４．１７：ここでログインは成功になるので、認証用トークン（一般的にクッキーである）はサービス代理へ返される。サービス代理の呼び元は利用者側のブラウザので、そのまま認証トークンを含めて、ステップ４．１のアクセスURLへリダイレクトレスポンスを利用者側のブラウザへ返す。ステップ４．１８へ。 Step 4.17: Now that the login is successful, the authentication token (typically a cookie) is returned to the service agent. Since the caller of the service proxy is the browser on the user side, the redirect response to the access URL in step 4.1 is returned to the browser on the user side, including the authentication token as it is. Go to step 4.18.
ステップ４．１８：図３のステップ３．１９に相当。ステップ４．１のアクセスURLへリダイレクトする。この時、サービスシステムの認証トークンは利用者側のブラウザで保管されるので、ステップ４．１の次、サービスシステムの認証OKになって、ステップ４．３で処理終了になる。 Step 4.18: Corresponds to step 3.19 of FIG. Redirect to the access URL in step 4.1. At this time, since the authentication token of the service system is stored in the browser on the user side, the authentication of the service system is OK after step 4.1, and the process ends at step 4.3.
例えば、A社は既に社内業務管理システムMを利用しているが、社外掲示板サービス提供するSシステムを利用したい。本発明を利用すれば、社内業務管理システムのアカウント管理をマスターアカウントシステムとして、掲示板システムSをサービスシステムとして、社内業務管理システムのアカウントを利用して、社外掲示板サービスを利用可能になる。
当然、マスターアカウントシステムはドメインシステムを利用しても構わない。アカウント管理機能を提供、そして、第三者のプログラムは認証、アカウント情報取得できれば、どんなシステムでもマスターアカウントシステムとして利用可能。
For example, Company A already uses the internal business management system M, but wants to use the S system that provides an external bulletin board service. If the present invention is used, the external bulletin board service can be used by using the account management of the internal business management system as the master account system, the bulletin board system S as the service system, and the account of the internal business management system.
Of course, the master account system may use a domain system. It provides account management functions, and any third-party program can be used as a master account system as long as it can authenticate and obtain account information.
この発明は、複数コンピュータシステム間のアカウント認証と管理を１本化させて、システム統合コストを削減して、セキュリティーを強化する。
The present invention unifies account authentication and management between a plurality of computer systems, reduces system integration costs, and enhances security.
Claims (2)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014110789A JP5724017B1 (en) | 2014-05-29 | 2014-05-29 | Authentication linkage system for multiple computer systems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014110789A JP5724017B1 (en) | 2014-05-29 | 2014-05-29 | Authentication linkage system for multiple computer systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP5724017B1 JP5724017B1 (en) | 2015-05-27 |
| JP2015225562A true JP2015225562A (en) | 2015-12-14 |
Family
ID=53277953
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014110789A Active JP5724017B1 (en) | 2014-05-29 | 2014-05-29 | Authentication linkage system for multiple computer systems |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5724017B1 (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004234329A (en) * | 2003-01-30 | 2004-08-19 | Nippon Telegraph & Telephone East Corp | Single sign-on system, method, program and storage medium utilizing id mapping |
| WO2009084601A1 (en) * | 2007-12-27 | 2009-07-09 | Nec Corporation | Access right managing system, access right managing method, and access right managing program |
| JP2010268084A (en) * | 2009-05-12 | 2010-11-25 | Nippon Telegr & Teleph Corp <Ntt> | User authentication system, proxy device, user authentication method, and program |
| JP2013149238A (en) * | 2011-12-22 | 2013-08-01 | Canon Marketing Japan Inc | Information processing device, information processing method, and program |
| JP2013152757A (en) * | 2006-03-22 | 2013-08-08 | Alibaba Group Holding Ltd | Intersystem single sign-on |
-
2014
- 2014-05-29 JP JP2014110789A patent/JP5724017B1/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004234329A (en) * | 2003-01-30 | 2004-08-19 | Nippon Telegraph & Telephone East Corp | Single sign-on system, method, program and storage medium utilizing id mapping |
| JP2013152757A (en) * | 2006-03-22 | 2013-08-08 | Alibaba Group Holding Ltd | Intersystem single sign-on |
| WO2009084601A1 (en) * | 2007-12-27 | 2009-07-09 | Nec Corporation | Access right managing system, access right managing method, and access right managing program |
| JP2010268084A (en) * | 2009-05-12 | 2010-11-25 | Nippon Telegr & Teleph Corp <Ntt> | User authentication system, proxy device, user authentication method, and program |
| JP2013149238A (en) * | 2011-12-22 | 2013-08-01 | Canon Marketing Japan Inc | Information processing device, information processing method, and program |
Also Published As
| Publication number | Publication date |
|---|---|
| JP5724017B1 (en) | 2015-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11134071B2 (en) | Data exchange during multi factor authentication | |
| CN112422532B (en) | Service communication method, system and device and electronic equipment | |
| US8024777B2 (en) | Domain based authentication scheme | |
| US20150188779A1 (en) | Split-application infrastructure | |
| US9021570B2 (en) | System, control method therefor, service providing apparatus, relay apparatus and computer-readable medium | |
| US10218691B2 (en) | Single sign-on framework for browser-based applications and native applications | |
| US8938789B2 (en) | Information processing system, method for controlling information processing system, and storage medium | |
| US11841959B1 (en) | Systems and methods for requiring cryptographic data protection as a precondition of system access | |
| US10320771B2 (en) | Single sign-on framework for browser-based applications and native applications | |
| US10284374B2 (en) | Code signing system with machine to machine interaction | |
| US20080263644A1 (en) | Federated authorization for distributed computing | |
| US20100043065A1 (en) | Single sign-on for web applications | |
| CN109150800B (en) | Login access method, system and storage medium | |
| US9239911B2 (en) | Replacement of security credentials for secure proxying | |
| JP6572750B2 (en) | Authentication control program, authentication control device, and authentication control method | |
| CN105592003A (en) | Cross-domain single sign-on method and system based on notification | |
| WO2011055486A1 (en) | Access control system, communication terminal, server, and access control method | |
| US11818114B2 (en) | Systems, methods, and storage media for synchronizing identity information across identity domains in an identity infrastructure | |
| CN107294935B (en) | Virtual private network access method, device and system | |
| KR20230145009A (en) | Single sign on authentication method and system based on terminal using dynamic token generation agent | |
| KR101839049B1 (en) | Single Sign-On Authentication Method of Supporting Session Management by Server and Cookie Information Sharing Way | |
| CN114844656A (en) | Network access method, device, system, equipment and storage medium | |
| CN104243488A (en) | Login authentication method of cross-website server | |
| JP5724017B1 (en) | Authentication linkage system for multiple computer systems | |
| KR20150095255A (en) | A system providing trusted identity management service using trust service device and its methods of operation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150303 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150330 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5724017 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |