JP2017211769A - 管理システム、通信システム、認可方法、及びプログラム - Google Patents
管理システム、通信システム、認可方法、及びプログラム Download PDFInfo
- Publication number
- JP2017211769A JP2017211769A JP2016103489A JP2016103489A JP2017211769A JP 2017211769 A JP2017211769 A JP 2017211769A JP 2016103489 A JP2016103489 A JP 2016103489A JP 2016103489 A JP2016103489 A JP 2016103489A JP 2017211769 A JP2017211769 A JP 2017211769A
- Authority
- JP
- Japan
- Prior art keywords
- management system
- authentication
- name
- identification information
- user
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】 同じユーザの異なる通信端末を識別するために、通信端末ごとに認証用の情報を生成して認証することとした場合には、認証用の情報の生成に伴う通信システムの負荷が大きくなる。【解決手段】 管理システム50の送受信部51は、自管理システムの利用が認可されたユーザのユーザ名を含む認可トークン、及び、ユーザ名に端末名が付加されているアカウント名を受信する。送受信部51によるアカウント名の受信に応じて、管理システム50のトークン確認部52は、認可トークンに含まれるユーザ名、及びアカウント名から抽出されるユーザ名が一致するかにより認証する。トークン確認部52によって認証されると、sub処理部54は、上記のアカウント名に対応するアカウントに対して、端末10間で送信されるメッセージのsubを認可する。【選択図】図1
Description
本発明は、管理システム、通信システム、認可方法、及びプログラムに関する。
近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通信する通信システムが普及している。このような通信システムでは、認証システムを設けて、通信端末ごとのユーザ認証を行う。これにより、通信端末ごとのユーザを識別できるようになるので、通信端末による指定されたユーザ間のコミュニケーションが可能になる。
特許文献1には、ユーザアカウント名の自動割当システムにおいて、端末がネットワークに接続後、前記端末がAPサーバのサーバ・ソフトウェアへアクセスする前に、前記端末がDHCPサーバによって割り当てられる前記ネットワークのホストアドレスを取得し、前記端末が当該ホストアドレスを接尾語とするユーザアカウント名を生成することでユーザアカウント名の自動割り当てを行うことが開示されている。
例えば、IoT(Internet of Things)などの分野では、異なるユーザの通信端末間の通信に限らず、同じユーザの異なる通信端末間の通信が確立される。しかしながら、同じユーザの異なる通信端末を識別するために、通信端末ごとに認証用の情報を生成して認証することとした場合には、認証用の情報の生成に伴う通信システムの負荷が大きくなるという課題が生じる。
請求項1に係る発明の管理システムは、自管理システムの利用が認可された対象の識別情報を含む認可情報、及び、認証の対象の識別情報に通信端末の識別情報が付加されている付加情報を受信する受信手段で受信した前記認可された対象の識別情報、及び前記受信手段で受信した前記付加情報のうち前記認証の対象の識別情報が一致するかにより認証する認証手段と、前記認証手段によって認証されると、前記付加情報に対応するアカウントに対して、通信端末間で送信される情報の受信を認可する認可手段と、を有する。
以上説明したように本発明によれば、同じユーザの異なる通信端末間の通信を行うときに、認証用の情報の生成に伴う通信システムの負荷を軽減できるという効果を奏する。
以下、本発明の実施形態について説明する。
<<通信システムの概略>>
図1は、本発明の一実施形態に係る通信システムの概略図である。図1に示されているように、通信システム1は、通信端末10、認証サーバ40、管理システム50によって構築されている。以下、通信端末10を単に端末10と記載する。
図1は、本発明の一実施形態に係る通信システムの概略図である。図1に示されているように、通信システム1は、通信端末10、認証サーバ40、管理システム50によって構築されている。以下、通信端末10を単に端末10と記載する。
管理システム50は、出版−購読(Publish-Subscribe、以下PubSubと記載する)モデルにおいて、クライアント間でメッセージを交換するために、クライアントから、メッセージの出版(Publish、以下pubと記載する)やメッセージの購読(Subscribe、以下subと記載する)の要求を受け付けるサーバである。管理システム50は、PubSubモデルに対応するプロトコルとして、例えば、MQTT(MQ Telemetry Transport)や、XMPP(eXtensible Messaging and Presence Protocol)のPubSub拡張(XEP-0060)等を実装しても良い。
端末10は、例えば、汎用端末であって、任意のクライアントアプリケーションがインストールされている。以下、クライアントアプリケーションをクライアントアプリと表す。また、端末10は、例えば、専用端末であって、クライアントとして稼働する特定のクライアントアプリが組み込まれている。端末10が通信ネットワーク2を介して管理システム50と通信可能に接続することで、各クライアントは、管理システム50にメッセージのpubやメッセージのsubを要求することができる。端末10は、例えば、テレビ会議端末、電子黒板、電子看板、電話、タブレット、スマートフォン、カメラ、PC(personal computer)等であっても良い。
認証サーバ40は、端末10上で動作するクライアントアプリである「クライアント」と、そのクライアントを利用する「ユーザ」とをそれぞれ認証し、管理システム50の利用を認可するサーバである。管理システム50は、上記の認証及び認可を実現するため、例えば、OAuth 2.0やOpenID Connectといった認証、認可のプロトコルを実装する。
図1では、説明を簡単にするために、管理システム50、及び認証サーバ40がそれぞれ一つの装置である場合について説明したが、本発明はこのような実施形態に限定されない。管理システム50、及び認証サーバ40の少なくとも一方は、複数の装置により構築されていても良い。また、管理システム50、及び認証サーバ40が、一つのシステム又は装置によって構築されていても良い。また、図1では、説明を簡単にするために、通信システム1において、4つの端末10が設けられている場合について説明したが、本発明はこのような実施形態に限定されない。通信システム1に設けられる端末10は、2つであっても、3つであっても、5つ以上であっても良い。また、各端末10は、それぞれ同種であっても、図1のように異種であっても良い。
<<ハードウェア構成>>
次に、通信システム1を構成する各装置のハードウェア構成を説明する。
次に、通信システム1を構成する各装置のハードウェア構成を説明する。
図2は、一実施形態に係る端末10のハードウェア構成図である。なお、端末10は、通信可能であれば、端末10のハードウェア構成は図2の構成に限定されない。例えば、端末10は、図2に記載されていない構成が含まれていても、図2に記載の構成の一部が含まれていなくても良い。また、図2に記載の構成の一部は端末10に接続可能な外部装置等であっても良い。図2に示されているように、本実施形態の端末10は、端末10全体の動作を制御するCPU(Central Processing Unit)101、IPL(Initial Program Loader)等のCPU101の駆動に用いられるプログラムを記憶したROM(Read Only Memory)102、CPU101のワークエリアとして使用されるRAM(Random Access Memory)103、端末10の各種端末用のプログラム、画像データ、及び音データ等の各種データを記憶するフラッシュメモリ104、CPU101の制御にしたがってフラッシュメモリ104に対する各種データの読み出し又は書き込みを制御するSSD(Solid State Drive)105、フラッシュメモリやICカード(Integrated Circuit Card)等の記録メディア106に対するデータの読み出し又は書き込み(記憶)を制御するメディアI/F107、宛先を選択する場合などに操作される操作ボタン108、端末10の電源のON/OFFを切り換えるための電源スイッチ109、通信ネットワーク2を利用してデータ伝送をするためのネットワークI/F(Interface)111を備えている。
また、端末10は、CPU101の制御に従って被写体を撮像して画像データを得る内蔵型のカメラ112、このカメラ112の駆動を制御する撮像素子I/F113、音を入力する内蔵型のマイク114、音を出力する内蔵型のスピーカ115、CPU101の制御に従ってマイク114及びスピーカ115との間で音信号の入出力を処理する音入出力I/F116、CPU101の制御に従って外付けのディスプレイ120に画像データを伝送するディスプレイI/F117、各種の外部機器を接続するための外部機器接続I/F118、端末10の各種機能の異常を知らせるアラームランプ119、及び上記各構成要素を図2に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン110を備えている。
ディスプレイ120は、被写体の画像や操作等を表示する液晶や有機EL(Organic Electroluminescence)によって構成された表示部である。また、ディスプレイ120は、ケーブル120cによってディスプレイI/F117に接続される。このケーブル120cは、アナログRGB(VGA)信号用のケーブルであってもよいし、コンポーネントビデオ用のケーブルであってもよいし、HDMI(登録商標)(High-Definition Multimedia Interface)やDVI(Digital Video Interactive)信号用のケーブルであってもよい。
カメラ112は、レンズや、光を電荷に変換して被写体の画像(映像)を電子化する固体撮像素子を含み、固体撮像素子として、CMOS(Complementary Metal Oxide Semiconductor)や、CCD(Charge Coupled Device)等が用いられる。
外部機器接続I/F118には、筐体1100の接続口1132に差し込まれたUSB(Universal Serial Bus)ケーブル等によって、外付けカメラ、外付けマイク、及び外付けスピーカ等の外部機器がそれぞれ電気的に接続可能である。外付けカメラが接続された場合には、CPU101の制御に従って、内蔵型のカメラ112に優先して、外付けカメラが駆動する。同じく、外付けマイクが接続された場合や、外付けスピーカが接続された場合には、CPU101の制御に従って、それぞれが内蔵型のマイク114や内蔵型のスピーカ115に優先して、外付けマイクや外付けスピーカが駆動する。
なお、記録メディア106は、端末10に対して着脱自在な構成となっている。また、CPU101の制御にしたがってデータの読み出し又は書き込みを行う不揮発性メモリであれば、フラッシュメモリ104に限らず、EEPROM(Electrically Erasable and Programmable ROM)等を用いてもよい。
図3は、一実施形態に係る管理システム50のハードウェア構成図である。管理システム50は、管理システム50全体の動作を制御するCPU501、IPL等のCPU501の駆動に用いられるプログラムを記憶したROM502、CPU501のワークエリアとして使用されるRAM503、管理システム50用のプログラム等の各種データを記憶するHD504、CPU501の制御にしたがってHD504に対する各種データの読み出し又は書き込みを制御するHDD(Hard Disk Drive)505、フラッシュメモリ等の記録メディア506に対するデータの読み出し又は書き込み(記憶)を制御するメディアドライブ507、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ508、通信ネットワーク2を利用してデータ通信するためのネットワークI/F509、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード511、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス512、着脱可能な記録媒体の一例としてのCD−ROM(Compact Disc Read Only Memory)513に対する各種データの読み出し又は書き込みを制御するCD−ROMドライブ514、及び、上記各構成要素を図3に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン510を備えている。
認証サーバ40は、管理システム50と同様のハードウェア構成を有しているため、その説明を省略する。
認証サーバ40は、管理システム50と同様のハードウェア構成を有しているため、その説明を省略する。
<<ソフトウェア構成>>
図4は、一実施形態に係る端末10のソフトウェア構成図である。図4に示されているように、OS1020、クライアントアプリ(1031,1032)は、端末10のRAM103の作業領域1010上で動作する。OS1020、及び、クライアントアプリ(1031,1032)は、端末10にインストールされている。
図4は、一実施形態に係る端末10のソフトウェア構成図である。図4に示されているように、OS1020、クライアントアプリ(1031,1032)は、端末10のRAM103の作業領域1010上で動作する。OS1020、及び、クライアントアプリ(1031,1032)は、端末10にインストールされている。
OS1020は、基本的な機能を端末10に提供し、端末10全体を管理する基本ソフトウェアである。クライアントアプリ(1031,1032)は、認証サーバ40に認証を要求し、管理システム50にpub要求及びsub要求の少なくとも一つを実行するためのアプリである。
なお、図4では少なくとも2つのクライアントアプリ(1031,1032)が端末10にインストールされているが、1以上の任意の数のクライアントアプリが端末10にインストールされていれば良い。また、OS1020上で任意のアプリケーションが動作しており、この任意のアプリケーション上でクライアントアプリが動作しても良い。
<<機能構成>>
次に、本実施形態の機能構成について説明する。図5は、一実施形態に係る通信システム1の一部を構成する端末10、認証サーバ40、及び管理システム50の機能ブロック図である。図5では、端末10、認証サーバ40、及び管理システム50が、通信ネットワーク2を介してデータ通信することができるように接続されている。
次に、本実施形態の機能構成について説明する。図5は、一実施形態に係る通信システム1の一部を構成する端末10、認証サーバ40、及び管理システム50の機能ブロック図である。図5では、端末10、認証サーバ40、及び管理システム50が、通信ネットワーク2を介してデータ通信することができるように接続されている。
<端末の機能構成>
端末10は、送受信部11、操作入力受付部12、表示制御部13、認証要求部14、pub要求部15、sub要求部16、及び記憶・読出部19を有している。これら各部は、図2に示されている各構成要素のいずれかが、フラッシュメモリ104からRAM103上に展開されたプログラムに従ったCPU101からの命令によって動作することで実現される機能である。また、端末10は、図2に示されているROM102、RAM103、フラッシュメモリ104によって構築される記憶部1000を有している。
端末10は、送受信部11、操作入力受付部12、表示制御部13、認証要求部14、pub要求部15、sub要求部16、及び記憶・読出部19を有している。これら各部は、図2に示されている各構成要素のいずれかが、フラッシュメモリ104からRAM103上に展開されたプログラムに従ったCPU101からの命令によって動作することで実現される機能である。また、端末10は、図2に示されているROM102、RAM103、フラッシュメモリ104によって構築される記憶部1000を有している。
(端末の各機能構成)
次に、図2及び図5を用いて、端末10の各機能構成について詳細に説明する。なお、以下では、端末10の各機能構成を説明するにあたって、図2に示されている各構成要素のうち、端末10の各機能構成を実現させるための主な構成要素との関係も説明する。
次に、図2及び図5を用いて、端末10の各機能構成について詳細に説明する。なお、以下では、端末10の各機能構成を説明するにあたって、図2に示されている各構成要素のうち、端末10の各機能構成を実現させるための主な構成要素との関係も説明する。
送受信部11は、CPU101からの命令、及びネットワークI/F111によって実現され、通信ネットワーク2を介して、相手側の端末、各装置又はシステム等と各種データ(または情報)の送受信を行う。
操作入力受付部12は、CPU101からの命令、並びに操作ボタン108及び電源スイッチ109によって実現され、ユーザによる各種入力を受け付けたり、ユーザによる各種選択を受け付けたりする。
表示制御部13は、CPU101からの命令、及びディスプレイI/F117によって実現され、通話する際に相手側から送られてきた画像データをディスプレイ120に送信するための制御を行う。
認証要求部14は、クライアントアプリに従ったCPU101からの命令によって実現され、認証サーバ40に対して認証を要求する。なお、端末10において複数のクライアントアプリがインストールされている場合、端末10には、起動したクライアントアプリ毎に認証要求部14が生成される。
pub要求部15は、クライアントアプリに従ったCPU101からの命令によって実現され、管理システム50に対してメッセージのpub要求をする。なお、クライアントアプリがsubに対応する一方でpubには対応していない場合、端末10においてpub要求部15は生成されない。また、端末10においてpubに対応した複数のクライアントアプリがインストールされている場合、端末10には、起動したクライアントアプリ毎にpub要求部15が生成される。
sub要求部16は、クライアントアプリに従ったCPU101からの命令によって実現され、管理システム50に対してメッセージのsub要求をする。なお、クライアントアプリがpubに対応する一方でsubには対応していない場合、端末10においてsub要求部16は生成されない。また、端末10においてsubに対応した複数のクライアントアプリがインストールされている場合、端末10には、起動したクライアントアプリ毎にsub要求部16が生成される。
記憶・読出部19は、CPU101からの命令及びSSD105によって実行され、又はCPU101からの命令によって実現され、記憶部1000に各種データを記憶したり、記憶部1000に記憶された各種データを抽出したりする処理を行う。
<認証サーバの機能構成>
認証サーバ40は、送受信部41、ユーザ認証部42、クライアント認証部43、認可部44、トークン発行部45、及び記憶・読出部49を有する。これら各部は、図3に示されている各構成要素のいずれかが、HD504からRAM503上に展開された認証サーバ40用のプログラムに従ったCPU501からの命令によって動作することで実現される機能である。また、認証サーバ40は、HD504により構築される記憶部4000を有している。
認証サーバ40は、送受信部41、ユーザ認証部42、クライアント認証部43、認可部44、トークン発行部45、及び記憶・読出部49を有する。これら各部は、図3に示されている各構成要素のいずれかが、HD504からRAM503上に展開された認証サーバ40用のプログラムに従ったCPU501からの命令によって動作することで実現される機能である。また、認証サーバ40は、HD504により構築される記憶部4000を有している。
(ユーザ管理テーブル)
図6(A)は、ユーザ管理テーブルを示す概念図である。記憶部4000には、ユーザ管理テーブルによってユーザ管理DB4001が構築される。ユーザ管理テーブルでは、ユーザID(identifier, identification)毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
図6(A)は、ユーザ管理テーブルを示す概念図である。記憶部4000には、ユーザ管理テーブルによってユーザ管理DB4001が構築される。ユーザ管理テーブルでは、ユーザID(identifier, identification)毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
(クライアント管理テーブル)
図6(B)は、クライアント管理テーブルを示す概念図である。記憶部4000には、クライアント管理テーブルによってクライアント管理DB4002が構築される。クライアント管理テーブルでは、クライアントID毎に、クライアント名、及びパスワードが関連付けられて管理されている。
なお、監視カメラアプリは、端末10が、管理システム50に対して撮像画像の画像データをメッセージとしてpubすることを要求するためのクライアントアプリである。監視センターアプリは、管理システム50に対して撮像画像の画像データをメッセージとしてsubすることを要求するためのクライアントアプリである。なお、監視センターアプリは、管理システム50に対してsub要求するクライアントアプリであるが、監視カメラアプリから撮像画像の管理要求を受けるサーバアプリでもある。
図6(B)は、クライアント管理テーブルを示す概念図である。記憶部4000には、クライアント管理テーブルによってクライアント管理DB4002が構築される。クライアント管理テーブルでは、クライアントID毎に、クライアント名、及びパスワードが関連付けられて管理されている。
なお、監視カメラアプリは、端末10が、管理システム50に対して撮像画像の画像データをメッセージとしてpubすることを要求するためのクライアントアプリである。監視センターアプリは、管理システム50に対して撮像画像の画像データをメッセージとしてsubすることを要求するためのクライアントアプリである。なお、監視センターアプリは、管理システム50に対してsub要求するクライアントアプリであるが、監視カメラアプリから撮像画像の管理要求を受けるサーバアプリでもある。
(サービス管理テーブル)
図6(C)は、サービス管理テーブルを示す概念図である。記憶部4000には、サービス管理テーブルによってサービス管理DB4003が構築される。サービス管理テーブルでは、サービスID毎に、サービス名が関連付けられて管理されている。一実施形態において、サービスID「S01」で識別されるサービス「伝送管理システム」は、管理システム50である。なお、管理システム50のPubSubの機能を利用する権利がリソースである。また、管理システム50を使ったPubSubサービスは、OAuth 2.0のプロトコルにおいて認可の単位となるスコープである。また、管理システム50はリソースサーバに相当する。
図6(C)は、サービス管理テーブルを示す概念図である。記憶部4000には、サービス管理テーブルによってサービス管理DB4003が構築される。サービス管理テーブルでは、サービスID毎に、サービス名が関連付けられて管理されている。一実施形態において、サービスID「S01」で識別されるサービス「伝送管理システム」は、管理システム50である。なお、管理システム50のPubSubの機能を利用する権利がリソースである。また、管理システム50を使ったPubSubサービスは、OAuth 2.0のプロトコルにおいて認可の単位となるスコープである。また、管理システム50はリソースサーバに相当する。
(サービス認可管理テーブル)
図6(D)は、サービス認可管理テーブルを示す概念図である。記憶部4000には、サービス認可管理テーブルによってサービス認可管理DB4004が構築される。サービス認可管理テーブルでは、クライアントID毎に、サービスIDが関連付けられて管理されている。これにより、サービス認可管理テーブルは、どのクライアントがどのサービスにアクセスして利用することができるかを管理することができる。図6(D)のサービス認可管理テーブルによれば、クライアントID「C01」で識別されるchatアプリは、サービスID「S01」で識別される伝送管理システム、すなわち、管理システム50にアクセスして利用することができることを示す。
図6(D)は、サービス認可管理テーブルを示す概念図である。記憶部4000には、サービス認可管理テーブルによってサービス認可管理DB4004が構築される。サービス認可管理テーブルでは、クライアントID毎に、サービスIDが関連付けられて管理されている。これにより、サービス認可管理テーブルは、どのクライアントがどのサービスにアクセスして利用することができるかを管理することができる。図6(D)のサービス認可管理テーブルによれば、クライアントID「C01」で識別されるchatアプリは、サービスID「S01」で識別される伝送管理システム、すなわち、管理システム50にアクセスして利用することができることを示す。
(認証サーバの各機能構成)
送受信部41は、CPU501からの命令、及びネットワークI/F509によって実現され、通信ネットワーク2を介して、相手側の端末、各装置又はシステム等と各種データ(または情報)の送受信を行う。
送受信部41は、CPU501からの命令、及びネットワークI/F509によって実現され、通信ネットワーク2を介して、相手側の端末、各装置又はシステム等と各種データ(または情報)の送受信を行う。
ユーザ認証部42は、CPU501からの命令によって実現され、クライアントからの要求に応じてユーザ認証を行う。
クライアント認証部43は、CPU501からの命令によって実現され、クライアントからの要求に応じてクライアント認証を行う。
認可部44は、CPU501からの命令によって実現され、サービスへのクライアントのアクセス権を指定することで認可する。
トークン発行部45は、CPU501からの命令によって実現され、クライアントがサービスへアクセスするときに、サービスで用いられる認可トークンを発行する。
記憶・読出部49は、CPU501からの命令及びHDD505によって実行され、又はCPU501からの命令によって実現され、記憶部4000に各種データを記憶したり、記憶部4000に記憶された各種データを抽出したりする処理を行う。
<管理システムの機能構成>
管理システム50は、送受信部51、トークン確認部52、pub処理部53、sub処理部54、及び記憶・読出部59を有している。これら各部は、図3に示されている各構成要素のいずれかが、HD504からRAM503上に展開された管理システム50用のプログラムに従ったCPU501からの命令によって動作することで実現される機能である。また、管理システム50は、HD504により構築される記憶部5000を有している。
管理システム50は、送受信部51、トークン確認部52、pub処理部53、sub処理部54、及び記憶・読出部59を有している。これら各部は、図3に示されている各構成要素のいずれかが、HD504からRAM503上に展開された管理システム50用のプログラムに従ったCPU501からの命令によって動作することで実現される機能である。また、管理システム50は、HD504により構築される記憶部5000を有している。
(トピック管理テーブル)
図7(A)は、トピック管理テーブルを示す概念図である。記憶部5000には、トピック管理テーブルによってトピック管理DB5001が構築される。トピック管理テーブルでは、トピックID毎に、トピック名が関連付けられて管理されている。トピックとはメッセージに関連付けられる属性である。クライアントアプリがトピックを指定してsub要求すると、管理システム50は、そのトピックに関連付けてpubされたメッセージを、要求元のクライアントアプリへ送信する。
図7(A)は、トピック管理テーブルを示す概念図である。記憶部5000には、トピック管理テーブルによってトピック管理DB5001が構築される。トピック管理テーブルでは、トピックID毎に、トピック名が関連付けられて管理されている。トピックとはメッセージに関連付けられる属性である。クライアントアプリがトピックを指定してsub要求すると、管理システム50は、そのトピックに関連付けてpubされたメッセージを、要求元のクライアントアプリへ送信する。
(クライアント認可管理テーブル)
図7(B)は、クライアント認可管理テーブルを示す概念図である。記憶部5000には、クライアント認可管理テーブルによってクライアント認可管理DB5002が構築される。クライアント認可管理テーブルでは、トピックID毎に、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。
図7(B)は、クライアント認可管理テーブルを示す概念図である。記憶部5000には、クライアント認可管理テーブルによってクライアント認可管理DB5002が構築される。クライアント認可管理テーブルでは、トピックID毎に、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。
(ユーザ認可管理テーブル)
図7(C)は、ユーザ認可管理テーブルを示す概念図である。記憶部5000には、ユーザ認可管理テーブルによってユーザ認可管理DB5003が構築される。ユーザ認可管理テーブルでは、トピックID毎に、アカウント名、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。本実施形態において、アカウント名は、認可の単位になる情報であって、ユーザ名、若しくはユーザ名に端末名を付加した形式で表される。本実施形態において、ユーザ名は、IETF(Internet Engineering Task Force)のRFC(Request for Comments)で標準化されたメールアドレス形式で表される。また、アカウント名はユーザ名に対して、端末名を付加した形式で表される。
図7(C)は、ユーザ認可管理テーブルを示す概念図である。記憶部5000には、ユーザ認可管理テーブルによってユーザ認可管理DB5003が構築される。ユーザ認可管理テーブルでは、トピックID毎に、アカウント名、クライアント名、及びpub又はsubする権限を有するか否かを示す権限情報が関連付けられて管理されている。本実施形態において、アカウント名は、認可の単位になる情報であって、ユーザ名、若しくはユーザ名に端末名を付加した形式で表される。本実施形態において、ユーザ名は、IETF(Internet Engineering Task Force)のRFC(Request for Comments)で標準化されたメールアドレス形式で表される。また、アカウント名はユーザ名に対して、端末名を付加した形式で表される。
(セッション管理テーブル)
図7(D)は、セッション管理テーブルを示す概念図である。記憶部5000には、セッション管理テーブルによってセッション管理DB5004が構築される。セッション管理テーブルでは、トピックID、アカウント名、及びクライアント名が関連付けられて管理されている。セッション管理テーブルは、現在、セッションを実行中のアカウントが、どのトピックのメッセージをsubしているかを示す。これにより、管理システム50は、トピックに対するメッセージのpub要求を受信したときに、どのアカウントにメッセージを送信すれば良いかを判断することができる。
図7(D)は、セッション管理テーブルを示す概念図である。記憶部5000には、セッション管理テーブルによってセッション管理DB5004が構築される。セッション管理テーブルでは、トピックID、アカウント名、及びクライアント名が関連付けられて管理されている。セッション管理テーブルは、現在、セッションを実行中のアカウントが、どのトピックのメッセージをsubしているかを示す。これにより、管理システム50は、トピックに対するメッセージのpub要求を受信したときに、どのアカウントにメッセージを送信すれば良いかを判断することができる。
(管理システムの各機能構成)
次に、管理システム50の各機能構成について詳細に説明する。なお、以下では、管理システム50の各機能構成を説明するにあたって、図3に示されている各構成要素のうち、管理システム50の各機能構成を実現させるための主な構成要素との関係も説明する。
次に、管理システム50の各機能構成について詳細に説明する。なお、以下では、管理システム50の各機能構成を説明するにあたって、図3に示されている各構成要素のうち、管理システム50の各機能構成を実現させるための主な構成要素との関係も説明する。
送受信部51は、CPU501からの命令、及びネットワークI/F509によって実現され、通信ネットワーク2を介して各端末、装置又はシステムと各種データ(または情報)の送受信を行う。
トークン確認部52は、CPU501からの命令によって実現され、端末10のログイン要求に含まれている認可トークンを確認する。
pub処理部53は、CPU501からの命令によって実現され、クライアントによるpub要求を受け付ける。
sub処理部54は、CPU501からの命令によって実現され、クライアントによるsub要求を受け付ける。
記憶・読出部59は、CPU501からの命令及びHDD505によって実行され、又はCPU501からの命令によって実現され、記憶部5000に各種データを記憶したり、記憶部5000に記憶された各種データを抽出したりする処理を行う。
<<処理または動作>>
続いて、通信システム1を構成する端末10、認証サーバ40、及び管理システム50の処理または動作について説明する。まずは、図8を用いて、一実施形態における認証処理について説明する。図8は、一実施形態における認証処理を示すシーケンス図である。
続いて、通信システム1を構成する端末10、認証サーバ40、及び管理システム50の処理または動作について説明する。まずは、図8を用いて、一実施形態における認証処理について説明する。図8は、一実施形態における認証処理を示すシーケンス図である。
なお、以下の処理では、端末10のユーザ認証に加えてクライアント認証が実行される処理の一例を示している。しかしながら、少なくともユーザ認証が実行されるものであれば、本発明は、以下の実施形態に限定されない。
端末10にインストールされている任意のクライアントアプリが起動すると(ステップS21)、起動したクライアントアプリにより、以下の各処理が実行される。端末10のクライアントアプリは、ユーザのユーザID、ユーザ名、及びユーザパスワードを取得する(ステップS22)。取得方法は、特に限定されないが、操作入力受付部12が、ユーザによるユーザID及びユーザパスワードの入力を受け付ける方法や、記憶・読出部19が、記憶部1000に記憶されているユーザID、ユーザ名、及びユーザパスワードを読み出す方法等が挙げられる。
端末10の認証要求部14は、送受信部11から認証サーバ40へ、認証/認可要求を送信させる(ステップS23)。認証/認可要求は、ユーザ認証要求、クライアント認証要求、及びサービス利用認可要求を含む。
ユーザ認証要求は、ステップS22で取得されるユーザID、ユーザ名、及びユーザパスワードを含む。上記のとおり、ユーザ名は、IETFのRFCで標準化されたメールアドレス形式で表される。以下、端末10a,10b,10cの共通のユーザをユーザa、ユーザaのユーザ名を、"[email protected]"と表す。
クライアント認証要求は、起動したクライアントのクライアントID及びクライアントパスワードを含む。クライアントID及びクライアントパスワードは、記憶部1000に予め記憶されている。送受信部11は、記憶部1000に記憶されているクライアントID及びクライアントパスワードを読み出して、送信用のクライアント認証要求に含める。
サービス利用認可要求は、これから利用するサービスを示すスコープとしてサービスIDを含む。以下、サービス利用認可要求に含まれるサービスIDは、管理システム50を示す「S01」であるものとする。
認証サーバ40の送受信部41は、端末10によって送信された、ユーザ認証要求、クライアント認証要求、及びサービス利用認可要求を含む認証/認可要求を受信する。認証/認可要求の受信に応じて、ユーザ認証部42は、ユーザ認証を行う。この場合、ユーザ認証部42は、ユーザ認証要求に含まれるユーザID、ユーザ名、及びユーザパスワードの組が、ユーザ管理テーブル(図6(A)参照)において管理されているか判断する。
ユーザID、ユーザ名、及びユーザパスワードの組がユーザ管理テーブルで管理されている場合には、ユーザ認証部42はユーザ認証に成功する。例えば、ユーザ認証要求に含まれるユーザ名が"[email protected]"であり、ユーザIDが"U01"であり、ユーザパスワードが"abc"である場合には、これらの組がユーザ管理テーブルにおいて管理されているのでユーザ認証に成功する。ユーザID、ユーザ名、及びユーザパスワードの組がユーザ管理テーブルにおいて管理されていない場合には、ユーザ認証部42はユーザ認証に失敗する。
ユーザ認証に成功した場合、認証サーバ40のクライアント認証部43は、クライアント認証要求に含まれるクライアントID及びクライアントパスワードの組が、クライアント管理テーブル(図6(B)参照)で管理されているか判断する。クライアント認証要求に含まれるクライアントID及びクライアントパスワードの組がクライアント管理テーブルで管理されている場合には、クライアント認証部43はクライアント認証に成功する(ステップS25)。クライアント認証要求に含まれるクライアントID及びクライアントパスワードの組がクライアント管理テーブルにおいて管理されていない場合には、クライアント認証部43はクライアント認証に失敗する。
クライアント認証に成功すると、認証サーバ40の認可部44は、クライアント認証要求に含まれるクライアントID、及びサービス利用認可要求に含まれるサービスIDの組が、サービス認可管理テーブル(図6(D)参照)で管理されているか判断する。クライアントID及びサービスIDの組がサービス認可管理テーブルで管理されている場合には、認可部44はサービス利用認可に成功する(ステップS26)。クライアントID及びサービスIDの組がサービス認可管理テーブルで管理されていない場合には、認可部44はサービス利用認可に失敗する。
ユーザ認証、クライアント認証、及びサービス利用認可の少なくとも一つに失敗した場合、送受信部41は、認証又は認可に失敗した旨を示すエラーメッセージを要求元の端末10へ送信する。
ユーザ認証、クライアント認証、及びサービス利用認可のすべてに成功した場合、認証サーバ40のトークン発行部45は、認証要求元の端末10による管理システム50へのアクセスが認可されたことを示す認可トークンを発行する。このとき、トークン発行部45は、認可トークンに、ユーザ認証要求に含まれるユーザ名、クライアント認証要求に含まれるクライアントIDに対応するクライアント名、サービス利用認可要求に含まれるサービスIDに対応するサービス名、及び認可トークンの有効期限を含める。
なお、通信システム1において、認証及び認可は、OAuth 2.0及びOpenID Connect等のプロトコルを用いて実行することもできる。この場合、ユーザID/ユーザパスワードなどの認証情報の授受の方法、認可トークンに含まれる内容は、OAuth 2.0及びOpenID Connect等の仕様によって規定されることになる。その場合、トークン自体はJWT(JSON Web Token)であっても良い。また、認可トークンがその経路上で改竄されないことを保証するため、トークン発行部45は、認可トークンに対して秘密鍵を用いて署名しても良い。秘密鍵は、RSA(Rivest, Shamir, Adleman)暗号を用いたものでも良い。なお、署名に、HMAC(Hash-based Message Authentication Code)のような公開鍵を用いても良い。認可トークンを利用する管理システム50では、認可トークンが秘密鍵で署名されているか共有鍵で署名されているかに応じて、公開鍵または共有鍵を用いて署名の確認をする。署名は例えばJWS(JSON Web Signature)といった公知の標準を用いることもできる。認可トークンは必要に応じて、例えば、JWE(JSON Web Encryption)で暗号化される。
送受信部41は、発行された認可トークン、及び認証及び認可に成功した旨の結果情報を端末10へ送信する(ステップS27)。端末10の送受信部11は、認証サーバによって送信された認可トークン、及び結果情報を受信する。続いて、端末10の送受信部11は受信した認可トークンと、アカウント名と、を含むログイン要求を管理システム50へ送信する(ステップS28)。
本実施形態において、アカウント名は、ステップS22で取得されるユーザ名に、端末10の端末名が付加された形式で表される。以下、端末10のうち端末10aの端末名は、"camera1"、端末10bの端末名は、"camera2"、端末10cの端末名は、"operator"であるものとする。なお、端末名は、端末10の記憶部1000に記憶されたものであっても、操作入力受付部12で受け付けられたものであっても良い。
ユーザ名と端末名との間は、予め定められた区切り文字で区切られている。区切り文字は、事前の取り決めによってユーザ名と端末名を一意に分割できる文字とする。たとえば、ユーザ名がemailアドレスの形式であれば、@以降のドメイン部分には+は使えないので+を区切り文字として使用する。端末10の送受信部11は、ステップS22で取得されるユーザ名に、区切り文字、及び端末名を付加することでアカウント名を生成する。例えば、ユーザaが端末10aを用いてログイン要求するときに生成されるアカウント名は、"[email protected]+camera1"である。
管理システム50の送受信部51は、端末10によって送信されたログイン要求を受信する。管理システム50のトークン確認部52は、ログイン要求に含まれる認可トークンを確認する(ステップS29)。この処理で、トークン確認部52は、認可トークンが有効であるか検証する。認可トークンの検証方法は、例えば、共有鍵、及び公開鍵による署名検証であり、認証サーバ40の提供するトークン検証API(Application Programming Interface)におけるトークンの形式や署名の方式に応じて適宜選択される。本実施形態の認可トークンには、有効期限が含まれているので、トークン確認部52は、有効期限により認可トークンが有効であるか検証しても良い。また、本実施形態の認可トークンには、サービスIDが含まれているので、トークン確認部52は、サービスIDによって示されるサービスが、自管理システムを示すものであるか確認することで、認可トークンが有効であるか検証しても良い。
検証の結果、認可トークンが有効ではない場合、トークン確認部52は、ログイン要求元による自管理システムへのログインを拒否する。
認可トークンが有効である場合、トークン確認部52は、ログイン要求元のログイン要求を許可するか判断する。図9を用いて、ログイン要求を許可するか判断する処理を詳細に説明する。図9は、ログイン要求を許可するか判断する処理を示すフロー図である。
認可トークンが有効である場合、トークン確認部52は、ログイン要求元のログイン要求を許可するか判断する。図9を用いて、ログイン要求を許可するか判断する処理を詳細に説明する。図9は、ログイン要求を許可するか判断する処理を示すフロー図である。
トークン確認部52は、ステップS28で受信されたログイン要求に含まれるアカウント名からユーザ名を抽出する(ステップS29−1)。例えば、トークン確認部52は、ログイン要求に含まれるアカウント名"[email protected]+camera1"から、区切り文字"+"より前の部分をユーザ名"[email protected]"として抽出する。なお、アカウント名からユーザ名を抽出する方法は上記に限定されず、端末10によるアカウント名の生成ルールに従うものであれば良い。例えば、先頭の3文字にユーザ名を含めるルールでアカウント名が生成される場合、ユーザ認証部42は、アカウント名から先頭の3文字をユーザ名として抽出する。或いは、ユーザ名を大文字、端末名を小文字とするルールでアカウント名が生成される場合、ユーザ認証部42は、アカウント名から大文字の部分をユーザ名として抽出する。
ログイン要求に含まれるアカウント名からユーザ名が抽出されると、トークン確認部52は、認可トークンに含まれるユーザ名と、ログイン要求に含まれるアカウント名から抽出されるユーザ名と、が一致するか判断する(ステップS29−2)。
判断の結果、ユーザ名が一致しない場合(ステップS29−2のNO)、トークン確認部52は、ログイン要求元の認証に失敗し、ログイン要求元による自管理システムへのログインを拒否する(ステップS29−4)。
ユーザ名が一致する場合(ステップS29−2のYES)、トークン確認部52は、ログイン要求元の認証に成功し、ログイン要求元による自管理システムへのログインを許可する。これにより、管理システム50の送受信部51は、端末10へ、ログインに成功した旨の結果情報をログイン要求元の端末へ送信する(ステップS30)。そして、管理システム50は、端末10との間の通信セッションを確立する。
ユーザ名が一致する場合(ステップS29−2のYES)、トークン確認部52は、ログイン要求元の認証に成功し、ログイン要求元による自管理システムへのログインを許可する。これにより、管理システム50の送受信部51は、端末10へ、ログインに成功した旨の結果情報をログイン要求元の端末へ送信する(ステップS30)。そして、管理システム50は、端末10との間の通信セッションを確立する。
セッションが確立すると管理システム50では、ログイン要求に含まれているアカウント名、認可トークンに含まれているクライアント名、及びログイン要求元の端末10のIPアドレス等を関連付けて記憶部5000において管理する。これにより、ログインした端末10が管理システム50へ情報を送信するたびに、アカウント名、及びクライアント名を通知しなくても、管理システム50では、送信元のアカウント名、及びクライアント名を把握できる。
同じユーザaが異なる端末10を利用する場合、上記のステップS21乃至S30の処理は、端末10ごとに実行される。例えば、ユーザaが利用する端末10a,10bの監視カメラアプリは、それぞれ、アカウント名"[email protected]+camera1, [email protected]+camera2"を管理システム50へ送信してログイン要求する。また、ユーザaが利用する端末10cの監視センターアプリは、アカウント名"[email protected]+operator"を管理システム50へ送信してログイン要求する。この場合でも、認証サーバは、一つのユーザ名"[email protected]"を認証名として認証することができる。
続いて、図10を用いて端末10間でメッセージを送信する処理について説明する。図10は、端末10a,10c間でメッセージを送信する処理の一例を示すシーケンス図である。端末10aは通信機能を有するカメラであり、店舗に配置されている。端末10cは、通信機能を有するPCであり、事務所に配置されている。端末10a,10cは同一の認証対象であるユーザaにより利用される。すなわち、上記のステップS21乃至S30の処理で、端末10aの監視カメラアプリ及び端末10cの監視センターアプリは、管理システム50へ、それぞれアカウント名"[email protected]+camera1, [email protected]+operator"を送信することで、それぞれ認証、及び認可される。
端末10cのsub要求部16は、監視カメラアプリが撮像した画像を受信するため、sub要求を管理システム50へ送信する(ステップS41)。sub要求には、監視カメラアプリが撮像する画像を示すトピック名"surveillance/shop_a"が含まれている。
管理システム50の送受信部51は、端末10cによって送信されたsub要求を受信する。管理システム50のsub処理部54は、sub要求元のアカウントが、sub要求に係るトピック名"surveillance/shop_a"のトピックに対しsubする権限を有するかを判断する(ステップS42)。ステップS42の処理について、図11を用いて詳細に説明する。図11は、メッセージをsubする権限を有するかを判断する処理の一例を示したフロー図である。
まず、sub処理部54は、sub要求に含まれるトピック名"surveillance/shop_a"が、トピック管理テーブル(図7(A)参照)において管理されているかを判断する(ステップS42−1)。sub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていないと判断された場合(ステップS42−1のNO)、sub処理部54は、sub要求元が、sub要求に係るトピックに対して、subする権限を有さない旨、判断する(ステップS42−6)。
sub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていると判断された場合(ステップS42−1のYES)、sub処理部54は、sub要求に含まれるトピック名"surveillance/shop_a"に対応するトピックID"T01"、sub要求元のクライアント名「監視センターアプリ」、及びsub権限有りを示す権限情報"sub"の組が、クライアント認可管理テーブルにおいて管理されているかを判断する(ステップS42−2)。
sub要求に係るトピックのトピックID、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、クライアント認可管理テーブルにおいて管理されていると判断された場合(ステップS42−2のYES)、sub処理部54は、sub要求元が、sub要求に係るトピックをsubする権限を有する旨、判断する(ステップS42−5)。ステップS42−2では、特定のクライアントによる要求であればアカウントによらずsub可能なトピックに対して、subする権限があるか判断する。
ステップS42−2においてNOと判断された場合、sub処理部54は、sub要求に係るトピックのトピックID"T01"、sub要求元のアカウント名"[email protected]+operator"、sub要求元のクライアント名「監視センターアプリ」、及びsub権限有りを示す権限情報"sub"の組が、ユーザ認可管理テーブルにおいて管理されているかを判断する(ステップS42−3)。
sub要求に含まれるトピックのトピックID、sub要求元のアカウント名、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていると判断された場合(ステップS42−3のYES)、sub処理部54は、sub要求元が、sub要求に係るトピックに対して、subする権限を有する旨、判断する(ステップS42−5)。
sub要求に係るトピックのトピックID、sub要求元のアカウント名、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていないと判断された場合(ステップS42−3のNO)、sub処理部54は、sub要求に係るトピックのトピックID、sub要求元のユーザ名、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されているか判断する(ステップS42−4)。なお、sub処理部54は、sub要求元のアカウント名から、区切り文字"+"以前の部分をユーザ名として抽出して上記の処理を行う。
sub要求に係るトピックのトピックID、sub要求元のユーザ名、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていないと判断された場合(ステップS42−4のNO)、sub処理部54は、sub要求元が、sub要求に係るトピックに対して、subする権限を有さない旨、判断する(ステップS42−6)。
sub要求に係るトピックのトピックID、sub要求元のユーザ名、sub要求元のクライアント名、及びsub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていると判断された場合(ステップS42−4のYES)、sub処理部54は、sub要求元が、sub要求に係るトピックをsubする権限を有する旨、判断する(ステップS42−5)。ステップS42−4の処理では、特定のユーザによる要求であればアカウントによらずsub可能なトピックに対して、subする権限を有するか判断する。
ステップS42−5で、sub要求元がsub権限を有する旨、判断された場合、sub処理部54は、sub要求元のアカウント名"[email protected]+operator"、クライアント名「監視センターアプリ」、及びsub要求に係るトピックのトピックID"T01"をセッション管理テーブルに関連付けて登録する(図7(D)参照)(ステップS43)。
一方、端末10aのpub要求部15は、端末10cの監視センターアプリにメッセージを送信するため、pub要求を管理システム50へ送信する(ステップS44)。pub要求には、監視カメラアプリが撮像する画像を示すトピック名"surveillance/shop_a"、及びメッセージとして自端末で撮像された画像の画像データが含まれている。
管理システム50の送受信部51は、端末10aによって送信されたpub要求を受信する。管理システム50のpub処理部53は、pub要求元のアカウントが、pub要求に係るトピック名"surveillance/shop_a"のトピックに対しpubする権限を有するかを判断する(ステップS45)。ステップS45の処理について、図12を用いて詳細に説明する。図12は、メッセージをpubする権限を有するかを判断する処理の一例を示したフロー図である。
まず、pub処理部53は、pub要求に含まれるトピック名"surveillance/shop_a"が、トピック管理テーブル(図7(A)参照)において管理されているかを判断する(ステップS45−1)。pub要求に含まれるトピック名がトピック管理テーブルにおいて管理されていないと判断された場合(ステップS45−1のNO)、pub処理部53は、pub要求元が、pub要求に係るトピックに対して、pubする権限を有さない旨、判断する(ステップS45−6)。
pub要求に係るトピック名がトピック管理テーブルにおいて管理されていると判断された場合(ステップS45−1のYES)、pub処理部53は、pub要求に含まれるトピック名"surveillance/shop_a"に対応するトピックID"T01"、pub要求元のクライアント名「監視カメラアプリ」、及びpub権限有りを示す権限情報"pub"の組が、クライアント認可管理テーブルにおいて管理されているかを判断する(ステップS45−2)。
pub要求に係るトピックのトピックID、pub要求元のクライアント名、及びpub権限有りを示す権限情報の組が、クライアント認可管理テーブルにおいて管理されていると判断された場合(ステップS45−2のYES)、pub処理部53は、pub要求元が、pub要求に係るトピックをpubする権限を有する旨、判断する(ステップS45−5)。ステップS45−2では、特定のクライアントによる要求であればアカウントによらずpub可能なトピックに対して、pubする権限があるか判断する。
ステップS45−2においてNOと判断された場合、pub処理部53は、pub要求に係るトピックのトピックID"T01"、pub要求元のアカウント名"[email protected]+camera1"、pub要求元のクライアント名「監視カメラアプリ」、及びpub権限有りを示す権限情報"pub"の組が、ユーザ認可管理テーブルにおいて管理されているかを判断する(ステップS45−3)。
pub要求に係るトピックのトピックID、pub要求元のアカウント名、pub要求元のクライアント名、及びpub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていると判断された場合(ステップS45−3のYES)、pub処理部53は、pub要求元が、pub要求に係るトピックに対して、pubする権限を有する旨、判断する(ステップS45−5)。
pub要求に係るトピックのトピックID、pub要求元のアカウント名、pub要求元のクライアント名、及びpub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていないと判断された場合(ステップS45−3のNO)、pub処理部53は、pub要求に係るトピックのトピックID"T01"、pub要求元のユーザ名"[email protected]"、pub要求元のクライアント名「監視カメラアプリ」、及びpub権限有りを示す権限情報"pub"の組が、ユーザ認可管理テーブルにおいて管理されているか判断する(ステップS45−4)。なお、pub処理部53は、pub要求元のアカウント名から、区切り文字"+"以前の部分をユーザ名として抽出して上記の処理を行う。
pub要求に係るトピックのトピックID、pub要求元のユーザ名、pub要求元のクライアント名、及びpub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていないと判断された場合(ステップS45−4のNO)、pub処理部53は、pub要求元が、pub要求に係るトピックに対して、pubする権限を有さない旨、判断する(ステップS45−6)。
pub要求に係るトピックのトピックID、pub要求元のユーザ名、pub要求元のクライアント名、及びpub権限有りを示す権限情報の組が、ユーザ認可管理テーブルにおいて管理されていると判断された場合(ステップS45−4のYES)、pub処理部53は、pub要求元が、pub要求に係るトピックをpubする権限を有する旨、判断する(ステップS45−5)。ステップS45−4の判断により、特定のユーザによる要求であればアカウントによらずpub可能なトピックに対して、pubする権限の有無を判断する。
ステップS45−5で、pub要求元がpub権限を有する旨、判断された場合、pub処理部53は、pub要求に係るトピック名"surveillance/shop_a"のトピックのトピックID"T01"を検索キーとして、セッション管理テーブルを検索し、対応するアカウント名"[email protected]+operator"及びクライアント名「監視センターアプリ」を取得する(ステップS46)。これにより、pub処理部53は、メッセージの送信先として、アカウント名"[email protected]+operator"で管理システム50へログインした端末10cの監視センターアプリを特定する。
送受信部51は、pub要求に含まれるメッセージとしての画像データ、及びpub要求元のアカウント名"[email protected]+camera1"を、上記で特定された端末10cの監視センターアプリへ送信する。これにより、端末10cの送受信部11は、メッセージとしての画像データ、及びpub要求元のアカウント名を受信する。
管理システム50は、pub要求に係るメッセージを記憶部5000において管理しても良い。これにより、pub要求時には管理システム50と接続していないクライアントが、後に管理システム50と接続したときに、管理システム50は、記憶部5000において管理されているメッセージをクライアントに送信することもできる。
<<実施形態の変形例A>>
続いて、実施形態の変形例Aについて、上記の実施例とは異なる点を説明する。
図13は、端末10cから端末10aへメッセージを送信する処理の一例を示すシーケンス図である。
続いて、実施形態の変形例Aについて、上記の実施例とは異なる点を説明する。
図13は、端末10cから端末10aへメッセージを送信する処理の一例を示すシーケンス図である。
端末10aのsub要求部16は、監視センターアプリによるコマンドを受信するため、sub要求を管理システム50へ送信する(ステップS141)。sub要求には、アカウント名"[email protected]+camera1"のアカウント宛のメッセージを示すトピック名"message_to/[email protected]+camera1"が含まれている。
管理システム50の送受信部51は、端末10aによって送信されたsub要求を受信する。管理システム50のsub処理部54は、sub要求元のアカウントが、sub要求に係るトピック名"message_to/[email protected]+camera1"のトピックに対しsubする権限を有するかを判断する(ステップS142)。
ステップS142の処理は、sub要求に含まれるトピック名が"message_to/[email protected]+camera1"に、このトピック名に対応するトピックIDが"T02"に、sub要求元のクライアント名が「監視カメラアプリ」に、sub要求元のアカウント名が"[email protected]+camera1"に、変更される点を除き、ステップS42と同様である。すなわち、ステップS142では、ステップS42−3に対応する処理で、sub要求に含まれるトピックのトピックID"T02"、sub要求元のアカウント名"[email protected]+camera1"、sub要求元のクライアント名「監視カメラアプリ」、及びsub権限有りを示す権限情報"sub"の組が、ユーザ認可管理テーブルにおいて管理されていると判断される。そして、ステップS42−5に対応する処理で、sub処理部54は、sub要求元が、sub要求に係るトピックをsubする権限を有する旨、判断する。
sub要求元がsub権限を有する旨、判断されると、sub処理部54は、sub要求元のアカウント名"[email protected]+camera1"、クライアント名「監視カメラアプリ」、sub要求に係るトピックのトピックID"T02"をセッション管理テーブルに関連付けて登録する(図7(D)参照)(ステップS143)。
一方、端末10cのpub要求部15は、ユーザaが利用中の端末10aの監視カメラアプリにメッセージとしてのコマンドを送信するため、pub要求を管理システム50へ送信する(ステップS144)。pub要求には、アカウント名"[email protected]+camera1"のアカウント宛のメッセージを示すトピック名"message_to/[email protected]+camera1"、及びメッセージとしてカメラの向きを水平方向に時計回りで30°回転させるためのコマンド"rotate(30,0,0)"が含まれている。なお、メッセージは上記のものに限定されず、例えば、ズームやフォーカスの変更、撮像を開始または終了するためのコマンドであっても良い。
管理システム50の送受信部51は、端末10cによって送信されたpub要求を受信する。管理システム50のpub処理部53は、pub要求元のアカウントが、pub要求に係るトピック名"message_to/[email protected]+camera1"のトピックに対して、pubする権限を有するかを判断する(ステップS145)。
ステップS145の処理は、pub要求に含まれるトピック名が"message_to/[email protected]+camera1"に、このトピック名に対応するトピックIDが"T02"に、pub要求元のクライアント名「監視センターアプリ」に、pub要求元のアカウント名が"[email protected]+operator"に変更される点を除き、ステップS45と同様である。すなわち、ステップS145では、ステップS45−3に対応する処理で、pub要求に含まれるトピックのトピックID"T02"、pub要求元のアカウント名"[email protected]+operator"、pub要求元のクライアント名「監視センターアプリ」、及びpub権限有りを示す権限情報"pub"の組が、ユーザ認可管理テーブルにおいて管理されていると判断される。そして、ステップS45−5に対応する処理で、pub処理部53は、pub要求元が、pub要求に係るトピックに対して、pubする権限を有する旨、判断する。
pub要求元がpub権限を有する旨、判断された場合、pub処理部53は、pub要求に係るトピック名"message_to/[email protected]+camera1"のトピックのトピックID"T02"を検索キーとして、セッション管理テーブルを検索し、対応するアカウント名"[email protected]+camera1"及びクライアント名「監視カメラアプリ」を取得する。これにより、pub処理部53は、メッセージの送信先として、アカウント名"[email protected]+camera1"で管理システム50へログインした端末10aの監視カメラアプリを特定する(ステップS146)。
送受信部51は、pub要求に含まれるメッセージとしてのコマンド"rotate(30,0,0)"、及びpub要求元のアカウント名"[email protected]+operator"を、上記で特定された端末10aの監視カメラアプリへ送信する。端末10aの送受信部11は、管理システム50によって送信されるメッセージとしてのコマンド、及びpub要求元のアカウント名を受信する。これにより、端末10aは、受信したコマンドに従って、カメラ112を30°回転させる。
<<実施形態の変形例B>>
続いて、実施形態の変形例Bについて、上記の実施形態と異なる点を説明する。
図14は、一実施形態における認証処理を示すシーケンス図である。管理システム50の記憶・読出部59は、現在、管理システム50へログインしているアカウントのアカウント名を記憶部5000へ記憶して管理する。
続いて、実施形態の変形例Bについて、上記の実施形態と異なる点を説明する。
図14は、一実施形態における認証処理を示すシーケンス図である。管理システム50の記憶・読出部59は、現在、管理システム50へログインしているアカウントのアカウント名を記憶部5000へ記憶して管理する。
管理システム50において、ステップS29の認証に成功すると、トークン確認部52は、ログイン要求元のユーザ名を検索キーとして、記憶部5000を検索し、ログイン要求元のユーザ名と同じユーザ名を含むアカウント名の数をカウントする(ステップSB1)。例えば、ログイン要求元のユーザ名が"[email protected]"である場合、トークン確認部52は、検索結果から"[email protected]"を含むアカウント名の数をカウントする。
トークン確認部52は、ログイン要求元のユーザ名と同じユーザ名を含むアカウント名の数が、所定の数(例えば、100)内であるか判断する(ステップSB1)。ログイン要求元のユーザ名と同じユーザ名を含むアカウント名の数が、所定の数を超える場合(ステップSB1のNO)、送受信部51は、ログインに失敗した旨を示す結果情報をログイン要求元に送信する(ステップSB2)。これにより、管理システム50のトークン確認部52は、同じユーザによるログインの回数が所定の数を超える場合に、ログイン要求元のログインを制限する。
ログイン要求元のユーザ名と同じユーザ名を含むアカウント名の数が所定の数内である場合(ステップSB1のYES)、トークン確認部52は、ログイン要求元によるログインを制限しない。これにより、ログイン要求元の端末10と管理システム50との間のセッションが確立される。
<<本実施形態の主な効果>>
続いて、上記の実施形態の主な効果を説明する。上記実施形態の認可方法によると、管理システム50の送受信部51(受信手段の一例)は、自管理システムの利用が認可されたユーザのユーザ名(認可された対象の識別情報の一例)を含む認可トークン(認可情報の一例)、及び、ユーザ名(認証の対象の識別情報の)に端末名(通信端末の識別情報の一例)が付加されているアカウント名(付加情報の一例)を受信する。送受信部51によるアカウント名の受信に応じて、管理システム50のトークン確認部52(認証手段の一例)は、認可トークンに含まれるユーザ名、及びアカウント名から抽出されるユーザ名が一致するかにより認証する。トークン確認部52によって認証されると、sub処理部54(認可手段の一例)は、上記のアカウント名に対応するアカウントに対して、端末10間で送信されるメッセージ(情報の一例)のsub(受信の一例)を認可する。上記実施形態によると、同じユーザの異なる端末10間の通信を行うときに、一つのユーザ名で認証できるので、認証用の情報の生成に伴う通信システム1の負荷を軽減できる。
続いて、上記の実施形態の主な効果を説明する。上記実施形態の認可方法によると、管理システム50の送受信部51(受信手段の一例)は、自管理システムの利用が認可されたユーザのユーザ名(認可された対象の識別情報の一例)を含む認可トークン(認可情報の一例)、及び、ユーザ名(認証の対象の識別情報の)に端末名(通信端末の識別情報の一例)が付加されているアカウント名(付加情報の一例)を受信する。送受信部51によるアカウント名の受信に応じて、管理システム50のトークン確認部52(認証手段の一例)は、認可トークンに含まれるユーザ名、及びアカウント名から抽出されるユーザ名が一致するかにより認証する。トークン確認部52によって認証されると、sub処理部54(認可手段の一例)は、上記のアカウント名に対応するアカウントに対して、端末10間で送信されるメッセージ(情報の一例)のsub(受信の一例)を認可する。上記実施形態によると、同じユーザの異なる端末10間の通信を行うときに、一つのユーザ名で認証できるので、認証用の情報の生成に伴う通信システム1の負荷を軽減できる。
管理システム50のトークン確認部52(制限手段の一例)は、同じユーザ名を含む異なるアカウントによるログイン数(接続数の一例)が所定数に達すると、このユーザ名を含むアカウントがログイン要求(接続要求の一例)するときに、自管理システム50へのログインを拒否することでログインを制限する。これにより、サービスの設定の自由度が向上する。
管理システム50の送受信部41は、ユーザ名、端末名、及び、ユーザ名を抽出するための区切り文字(抽出情報の一例)を含むアカウント名を受信する。これにより、管理システム50では、アカウント名からユーザ名を抽出できるようになる。
認証サーバ40(出力システムの一例)は、自管理システムの利用が認可されたユーザのユーザ名を含む認可トークンを発行する(出力の一例)する。これにより、管理システム50のトークン確認部52は、認証サーバ40によって発行された認可トークンに含まれるユーザ名と、端末10から送信されるアカウント名から抽出されるユーザ名が一致するかにより、認証することができる。
端末10は、入力されるユーザ名に、自端末の端末名を付したアカウント名を管理システム50へ送信する。これにより、端末10は、自端末の端末名を管理するだけで、ユーザごとのアカウント名を生成できるようになる。
<<実施形態の補足>>
端末10、認証サーバ40、及び管理システム50用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体(記録メディア106等)に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、CD−R(Compact Disc Recordable)、DVD(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
端末10、認証サーバ40、及び管理システム50用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体(記録メディア106等)に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、CD−R(Compact Disc Recordable)、DVD(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
また、上記実施形態の各プログラムが記憶されたCD−ROM等の記録媒体、並びに、これらプログラムが記憶されたHD504は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。
また、上記実施形態における端末10、認証サーバ40、及び管理システム50は、単一のコンピュータによって構築されてもよいし、各部(機能又は手段)を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、認証サーバ40及び管理システム50は、単一のコンピュータによって構築されていても良い。
上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路を含むプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)や従来の回路モジュール等のデバイスを含むものとする。
1 通信システム
2 通信ネットワーク
10 端末
11 送受信部
12 操作入力受付部
13 表示制御部
14 認証要求部
15 pub要求部
16 sub要求部
19 記憶・読出部
40 認証サーバ
41 送受信部
42 ユーザ認証部
43 クライアント認証部
44 認可部
45 トークン発行部
49 記憶・読出部
50 管理システム
51 送受信部
52 トークン確認部
53 pub処理部
54 sub処理部
59 記憶・読出部
1000 記憶部
4000 記憶部
4001 ユーザ管理DB
4002 クライアント管理DB
4003 サービス管理DB
4004 サービス認可管理DB
5000 記憶部
5001 トピック管理DB
5002 クライアント認可管理DB
5003 ユーザ認可管理DB
5004 セッション管理DB
2 通信ネットワーク
10 端末
11 送受信部
12 操作入力受付部
13 表示制御部
14 認証要求部
15 pub要求部
16 sub要求部
19 記憶・読出部
40 認証サーバ
41 送受信部
42 ユーザ認証部
43 クライアント認証部
44 認可部
45 トークン発行部
49 記憶・読出部
50 管理システム
51 送受信部
52 トークン確認部
53 pub処理部
54 sub処理部
59 記憶・読出部
1000 記憶部
4000 記憶部
4001 ユーザ管理DB
4002 クライアント管理DB
4003 サービス管理DB
4004 サービス認可管理DB
5000 記憶部
5001 トピック管理DB
5002 クライアント認可管理DB
5003 ユーザ認可管理DB
5004 セッション管理DB
Claims (10)
- 自管理システムの利用が認可された対象の識別情報を含む認可情報、及び、認証の対象の識別情報に通信端末の識別情報が付加されている付加情報を受信する受信手段と、
前記受信手段で受信した前記認可された対象の識別情報、及び前記受信手段で受信した前記付加情報のうち前記認証の対象の識別情報が一致するかにより認証する認証手段と、
前記認証手段によって認証されると、前記付加情報に対応するアカウントに対して、通信端末間で送信される情報の受信を認可する認可手段と、
を有する管理システム。 - 同じ前記認証の対象の識別情報を含む異なるアカウントによる自管理システムへの接続数が所定数に達すると、前記認証の対象の識別情報を含むアカウントが接続要求するときに、自管理システムへの接続を制限する制限手段を有する請求項1に記載の管理システム。
- 前記受信手段は、前記認証の対象の識別情報、前記通信端末の識別情報、及び、前記認証の対象の識別情報を抽出するための抽出情報を含む付加情報を受信する請求項1又は2に記載の管理システム。
- 前記認可情報を出力する出力システムと、
請求項1乃至3のいずれか一項に記載の管理システムと、を有し、
前記管理システムの前記認証手段は、前記出力システムによって出力される前記認可情報、及び前記通信端末によって送信される前記認証の対象の識別情報が一致するかにより認証する通信システム。 - 更に、前記付加情報を送信する通信端末を有する請求項4に記載の通信システム。
- 請求項1乃至3のいずれか一項に記載の管理システムと、
前記通信端末と、
を有する通信システム。 - 前記通信端末は、
入力される前記認証の対象の識別情報に、当該通信端末の識別情報を付加した付加情報を前記管理システムへ送信する請求項6に記載の通信システム。 - 管理システムに、
自管理システムの利用が認可された対象の識別情報を含む認可情報、及び、認証の対象の識別情報に通信端末の識別情報が付加されている付加情報を受信する処理と、
前記処理で受信した前記認可された対象の識別情報、及び前記処理で受信した前記付加情報のうち前記認証の対象の識別情報が一致するかにより認証する処理と、
前記処理によって認証されると、前記付加情報に対応するアカウントに対して、通信端末間で送信される情報の受信を認可する処理と、
を実行させる認可方法。 - 前記通信端末に、
入力される前記対象の識別情報に、当該通信端末の識別情報を付した付加情報を前記管理システムへ送信する処理を実行させる請求項8に記載の認可方法。 - 管理システムに、
自管理システムの利用が認可された対象の識別情報を含む認可情報、及び、認証の対象の識別情報に通信端末の識別情報が付加された付加情報を受信する処理と、
前記処理で受信した前記認可された対象の識別情報、及び前記処理で受信した前記付加情報のうち前記認証の対象の識別情報が一致するかにより認証する処理と、
前記処理によって認証されると、前記付加情報に対応するアカウントに対して、通信端末間で送信される情報の受信を認可する処理と、
を実行させるプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016103489A JP2017211769A (ja) | 2016-05-24 | 2016-05-24 | 管理システム、通信システム、認可方法、及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016103489A JP2017211769A (ja) | 2016-05-24 | 2016-05-24 | 管理システム、通信システム、認可方法、及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017211769A true JP2017211769A (ja) | 2017-11-30 |
Family
ID=60475577
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016103489A Pending JP2017211769A (ja) | 2016-05-24 | 2016-05-24 | 管理システム、通信システム、認可方法、及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2017211769A (ja) |
-
2016
- 2016-05-24 JP JP2016103489A patent/JP2017211769A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10484368B2 (en) | Management system, management method, and recording medium for managing use of function to terminal | |
JP2017068596A (ja) | 管理システム、通信システム、送信制御方法、及びプログラム | |
US10681094B2 (en) | Control system, communication control method, and program product | |
JP6583543B2 (ja) | 情報送信システム、情報送信方法、及びプログラム | |
US10498716B2 (en) | Management system, communication control method, and communication system | |
US9661000B2 (en) | Communication apparatus, communication system, method of controlling communication apparatus, and storage medium | |
US10305905B2 (en) | Access control device, communication system, program, and method for controlling access | |
JP6724431B2 (ja) | 通信システム、情報送信方法、及びプログラム | |
EP3261317B1 (en) | Authentication system, communication system, and authentication and authorization method | |
JP2017097652A (ja) | 管理システム、通信システム、通信制御方法、及びプログラム | |
JP2017207909A (ja) | 認証システム、通信システム、認証方法、及びプログラム | |
JP2017098780A (ja) | 管理システム、通信システム、通信制御方法、及びプログラム | |
JP6724423B2 (ja) | 通信端末、通信システム、出力方法、及びプログラム | |
US11128623B2 (en) | Service providing system, service delivery system, service providing method, and non-transitory recording medium | |
US20180183791A1 (en) | Remote communication system, remote communication method, and recording medium | |
US20180077207A1 (en) | Information processing terminal, communication system, information processing method, and recording medium | |
US10728254B2 (en) | Management system, communication system, and management method | |
JP2017211769A (ja) | 管理システム、通信システム、認可方法、及びプログラム | |
US10581936B2 (en) | Information processing terminal, management system, communication system, information processing method, and recording medium | |
US20180077204A1 (en) | Information processing terminal, communication system, information processing method, and recording medium | |
JP2013258707A (ja) | 伝送管理装置、プログラム、伝送管理システムおよび伝送管理方法 | |
JP6891569B2 (ja) | 情報端末、情報処理システム、情報処理方法及びプログラム | |
JP2022053955A (ja) | 方法、プログラム、情報処理装置、認証サーバ、および情報処理システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20180209 |