(57)【要約】【課題】認証サーバは、特定のアプリケーションサーバに特化した権限管理を行えないため、アプリケーションサーバが提供するサービスに適した権限管理が行えない。【解決手段】権限管理システムは第１の情報処理装置（アプリケーションサーバ）と第２の情報処理装置（認証サーバ）を有する。アプリケーションサーバはサービスの利用者毎に、プロバイダとサービスに対してプロバイダに設定された役割を対応づけて管理し、プロバイダからいずれかの利用者に対するアクセスがあった場合に、該利用者に対応して管理されている情報を認証サーバに送って、権限検証を依頼する。認証サーバは、プロバイダとサービスに対するプロバイダの権限とを対応づけて管理し、アプリケーションサーバからの依頼に応じて、認証サーバに管理されている情報を、受信した情報に変更し、当該変更した情報に基づいて、該役割に対する権限が存在するかどうかを検証する。【選択図】  図３
2017182238.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供する第１の情報処理装置と、権限検証を行なう第２の情報処理装置とを備える権限管理システムであって、
前記第１の情報処理装置は、
前記サービスの利用者毎に、前記サービスのプロバイダと、前記サービスに対して前記プロバイダに設定された役割とを対応づけて管理する管理手段と、
前記プロバイダから前記利用者のいずれかに対するアクセスがあった場合に、前記利用者に対応して前記管理手段に管理されている前記プロバイダと前記役割に関する情報を前記第２の情報処理装置に送って、権限検証を依頼する検証依頼手段を有し、
前記第２の情報処理装置は、
前記プロバイダと、前記サービスに対する前記プロバイダの権限とを対応づけて管理する権限管理手段と、
前記第１の情報処理装置の前記検証依頼手段からの依頼に応じて、前記権限管理手段により管理されている情報を、前記検証依頼手段から受信した前記情報に変更し、前記変更した情報に基づいて、前記役割に対する権限が存在するかどうかを検証する検証手段を有する
ことを特徴とする権限管理システム。
【請求項２】
前記第１の情報処理装置は、前記第２の情報処理装置の権限管理手段により管理されている前記情報の一時的な変更を認可する権限を示す認証情報を記憶する記憶手段をさらに有し、前記検証依頼手段は前記認証情報に基づいて前記権限検証を依頼することを特徴とする、請求項１に記載の権限管理システム。
【請求項３】
前記第１の情報処理装置は、前記記憶手段に記憶される前記認証情報に基づいて、前記第２の情報処理装置に対して、アクセスを認可する認可情報の発行を依頼する発行依頼手段をさらに有し、前記第２の情報処理装置は、前記発行依頼手段からの依頼に応じて前記認可情報を発行する発行手段をさらに有し、
前記第１の情報処理装置の前記検証依頼手段は前記発行手段により発行された前記認可情報に基づいて前記権限検証を依頼することを特徴とする、請求項２に記載の権限管理システム。
【請求項４】
前記第１の情報処理装置の前記管理手段において、前記プロバイダがどの利用者にも対応づけられていない場合は、前記第２の情報処理装置の前記検証手段は、前記権限管理手段により管理されている情報に基づいて、前記役割に対する権限が存在するかどうかを検証することを特徴とする、請求項１〜３のいずれか１項に記載の権限管理システム。
【請求項５】
サービスを提供する第１の情報処理装置と、権限検証を行なう第２の情報処理装置とを備える権限管理システムにおいて、
前記第１の情報処理装置は、
前記サービスの利用者毎に、前記サービスのプロバイダと、前記サービスに対して前記プロバイダに設定された役割とを対応づけて管理する管理手段と、
前記プロバイダから前記利用者のいずれかに対するアクセスがあった場合に、前記利用者に対応して前記管理手段に管理されている前記プロバイダと前記役割に関する情報を前記第２の情報処理装置に送って、権限検証を依頼する検証依頼手段を有し、
前記第２の情報処理装置は、
前記プロバイダと、前記サービスに対する前記プロバイダの権限とを対応づけて管理する権限管理手段と、
前記第１の情報処理装置の前記検証依頼手段からの依頼に応じて、前記権限管理手段により管理されている情報を、前記検証依頼手段から受信した前記情報に変更し、前記変更した情報に基づいて、前記役割に対する権限が存在するかどうかを検証する検証手段を有する
ことを特徴とする第１の情報処理装置。
【請求項６】
前記第１の情報処理装置は、前記第２の情報処理装置の権限管理手段により管理されている前記情報の一時的な変更を認可する権限を示す認証情報を記憶する記憶手段をさらに有し、前記検証依頼手段は前記認証情報に基づいて前記権限検証を依頼することを特徴とする、請求項５に記載の第１の情報処理装置。
【請求項７】
前記第１の情報処理装置は、前記記憶手段に記憶される前記認証情報に基づいて、前記第２の情報処理装置に対して、アクセスを認可する認可情報の発行を依頼する発行依頼手段をさらに有し、前記第２の情報処理装置は、前記発行依頼手段からの依頼に応じて前記認可情報を発行する発行手段をさらに有し、
前記第１の情報処理装置の前記検証依頼手段は前記発行手段により発行された前記認可情報に基づいて前記権限検証を依頼することを特徴とする、請求項６に記載の第１の情報処理装置。
【請求項８】
前記第１の情報処理装置の前記管理手段において、前記プロバイダがどの利用者にも対応づけられていない場合は、前記第２の情報処理装置の前記検証手段は、前記権限管理手段により管理されている情報に基づいて、前記役割に対する権限が存在するかどうかを検証することを特徴とする、請求項５〜７のいずれか１項に記載の第１の情報処理装置。
【請求項９】
サービスを提供する第１の情報処理装置と、権限検証を行なう第２の情報処理装置とを備える権限管理システムにおいて、
前記第１の情報処理装置は、
前記サービスの利用者毎に、前記サービスのプロバイダと、前記サービスに対して前記プロバイダに設定された役割とを対応づけて管理する管理手段と、
前記プロバイダから前記利用者のいずれかに対するアクセスがあった場合に、前記利用者に対応して前記管理手段に管理されている前記プロバイダと前記役割に関する情報を前記第２の情報処理装置に送って、権限検証を依頼する検証依頼手段を有し、
前記第２の情報処理装置は、
前記プロバイダと、前記サービスに対する前記プロバイダの権限とを対応づけて管理する権限管理手段と、
前記第１の情報処理装置の前記検証依頼手段からの依頼に応じて、前記権限管理手段により管理されている情報を、前記検証依頼手段から受信した前記情報に変更し、前記変更した情報に基づいて、前記役割に対する権限が存在するかどうかを検証する検証手段を有する
ことを特徴とする第２の情報処理装置。
【請求項１０】
前記第１の情報処理装置は、前記第２の情報処理装置の権限管理手段により管理されている前記情報の一時的な変更を認可する権限を示す認証情報を記憶する記憶手段をさらに有し、前記検証依頼手段は前記認証情報に基づいて前記権限検証を依頼することを特徴とする、請求項９に記載の第２の情報処理装置。
【請求項１１】
前記第１の情報処理装置は、前記記憶手段に記憶される前記認証情報に基づいて、前記第２の情報処理装置に対して、アクセスを認可する認可情報の発行を依頼する発行依頼手段をさらに有し、前記第２の情報処理装置は、前記発行依頼手段からの依頼に応じて前記認可情報を発行する発行手段をさらに有し、
前記第１の情報処理装置の前記検証依頼手段は前記発行手段により発行された前記認可情報に基づいて前記権限検証を依頼することを特徴とする、請求項１０に記載の第２の情報処理装置。
【請求項１２】
前記第１の情報処理装置の前記管理手段において、前記プロバイダがどの利用者にも対応づけられていない場合は、前記第２の情報処理装置の前記検証手段は、前記権限管理手段により管理されている情報に基づいて、前記役割に対する権限が存在するかどうかを検証することを特徴とする、請求項９〜１１のいずれか１項に記載の第２の情報処理装置。
【請求項１３】
サービスを提供する第１の情報処理装置と、権限検証を行なう第２の情報処理装置とを備える権限管理システムにおいて実行される権限管理方法であって、
前記第１の情報処理装置において、前記サービスのプロバイダから前記サービスの利用者に対するアクセスがあった場合に、予め利用者毎に前記プロバイダと前記サービスに対して前記プロバイダに設定された役割とを対応づけて管理する情報に基づいて、前記利用者に対応して管理されている前記プロバイダと前記役割に関する情報を前記第２の情報処理装置に送り、
前記第２の情報処理装置において、前記第２の情報処理装置で前記プロバイダと前記サービスに対する前記プロバイダの権限とを対応づけて管理する情報を、前記第１の情報処理装置から受信した前記情報に変更し、前記変更した情報に基づいて、前記役割に対する権限が存在するかどうかを検証する
ことを特徴とする権限管理方法。
【請求項１４】
コンピュータを、請求項１〜４のいずれか１項に記載の権限管理システムに記載の各手段として機能させるためのプログラム。
【請求項１５】
コンピュータを、請求項５〜８のいずれか１項に記載の第１の情報処理装置に記載の各手段として機能させるためのプログラム。
【請求項１６】
コンピュータを、請求項９〜１２のいずれか１項に記載の第２の情報処理装置に記載の各手段として機能させるためのプログラム。
【請求項１７】
請求項１４〜１６のいずれか１項に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケションサービスの権限管理を行なうシステム、装置、方法、およびプログラムに関する。
【背景技術】
【０００２】
従来から、ユーザにサービスを提供するＳＰ（Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ、サービスプロバイダ）と、サービスを利用するユーザの認証と認可を提供するＩｄＰ（Ｉｄｅｎｔｉｔｙ  Ｐｒｏｖｉｄｅｒ、アイデンティティプロバイダ）がある。ＩｄＰは、ＳＰを利用するユーザと、ＳＰの利用範囲についての権限を定義する。そして、ＳＰからの要求に応じて、正しいユーザであるかどうかを認証し、ＳＰが提供するサービスを利用してよいかどうかを検証し、認可する。しかし、一般にＩｄＰは複数のＳＰから利用されるため、特定のＳＰに特化した仕様で権限管理することが難しい。そのため、ＩｄＰに定義する権限の単位と、ＳＰで機能制限したい権限の単位が一致しない場合がある。例えば、ユーザ単位にＳＰの機能を制限できるＩｄＰに対し、顧客のデバイス管理をアウトソーシングするようなサービスでは、同じユーザであっても登録された顧客単位に機能制限を行いたい場合がある。
【０００３】
特許文献１には、ユーザに複数のアクセス権限を割り当てて、アクセス権限の切り替え指示により、権限検証に使用するアクセス権限を切り替える技術が開示されている。これにより、ＳＰの機能制限を行いたい単位でアクセス権限を切り替えれば、ユーザはログオフすることなく、権限を検証することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１２３１２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１ではＳＰの権限を変更する度に、ＳＰのユーザが都度権限を切り替える必要があり、操作性が良くない。本発明は上記の課題を解決するためになされたもので、ユーザの操作なくＳＰの機能制限したい単位でＩｄＰに定義された権限を変えて、ＳＰに特化した仕様で権限管理できる方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明はサービスを提供する第１の情報処理装置と、権限検証を行なう第２の情報処理装置とを備える権限管理システムを提供する。第１の情報処理装置は、サービスの利用者毎に、前記サービスのプロバイダと前記サービスに対して前記プロバイダに設定された役割とを対応づけて管理する管理手段と、前記プロバイダから前記利用者のいずれかに対するアクセスがあった場合に、前記利用者に対応して前記管理手段に管理されている前記プロバイダと前記役割に関する情報を前記第２の情報処理装置に送って、権限検証を依頼する検証依頼手段を有する。第２の情報処理装置は、前記プロバイダと、前記サービスに対する前記プロバイダの権限とを対応づけて管理する権限管理手段と、第１の情報処理装置の前記検証依頼手段からの依頼に応じて、前記権限管理手段により管理されている情報を、前記検証依頼手段から受信した前記情報に変更し、前記変更した情報に基づいて、前記役割に対する権限が存在するかどうかを検証する検証手段を有する。
【発明の効果】
【０００７】
ユーザの操作なくＳＰの機能制限したい単位でＩｄＰに定義された権限を変えて、ＳＰに特化した仕様で権限管理する方法が可能となる。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施形態に係る権限管理システムのシステム構成を示す図である。
【図２】本発明の実施形態に係る権限管理システムのハードウェア構成を示す図である。
【図３】本発明の実施形態に係るアプリケーションサーバ、認証サーバのソフトウェア構成を示す図である。
【図４】本発明の実施形態に係るアプリケーションサーバの機能毎に必要な権限定義の一例である。
【図５】本発明の実施形態に係るロール管理部のデータ構造図の一例である。
【図６】本発明の実施形態に係るユーザとロールの紐付け情報管理部のデータ構造図の一例である。
【図７】本発明の実施形態に係る新しいロールの作成画面の画面例である。
【図８】本発明の実施形態に係るユーザへのロール設定画面の画面例である。
【図９】本発明の実施形態に係るデバイス管理サービスのカスタマ選択画面の画面例である。
【図１０】本発明の実施形態に係るカスタマ別ロール管理部のデータ構造図の一例である。
【図１１】本発明の実施形態に係るカスタマ毎の権限設定画面の画面例である。
【図１２】本発明の実施形態に係るロール操作権限の移譲画面の画面例である。
【図１３】本発明の実施形態に係るカスタマの委託設定画面の画面例である。
【図１４】本発明の実施形態に係る委託管理部のデータ構造図の一例である。
【図１５】本発明の実施形態に係るカスタマの委託承認画面の画面例である。
【図１６】本発明の実施形態に係るアプリケーションサーバの権限検証依頼の処理フローチャートである。
【図１７】本発明の実施形態に係る認証サーバの権限検証の処理フローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の記述において、「ロール」とは業務上の役割を示すものとする。
【００１０】
図１に示すように、本発明の実施形態に係る権限管理システムは、アプリケーションサーバ１０１（第１の情報処理装置）と認証サーバ１０２（第２の情報処理装置）を含み、各装置はネットワーク１００を介して接続される。本システムには、ネットワーク１００を介して接続される第２のアプリケーションサーバ１０３とクライアント端末１０４をさらに含んでも良い。
【００１１】
アプリケーションサーバ１０１は、ＳＰ（Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ、サービスプロバイダ）としてサービスを提供するためのサーバである。アプリケーションサーバ１０３は、アプリケーションサーバ１０１とは異なるサービスを提供するアプリケーションサーバである。認証サーバ１０２は、ＩｄＰ（Ｉｄｅｎｔｉｔｙ  Ｐｒｏｖｉｄｅｒ、アイデンティティプロバイダ）として、ＳＰのサービスを利用するユーザを認証し、ＳＰのサービスを利用できるか否かを検証し、認可する。図１では認証と認可を１つの認証サーバ１０２で行なうものとしているが、認証と認可をそれぞれ別のサーバで行なってもよい。クライアント端末１０４は、ＳＰのサービスを利用するための端末である。クライアント端末１０４はパーソナルコンピュータに限定するものではなく、同機能を持つ携帯端末やタブレット端末などでもよい。ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線であり、インタネット、イントラネットの種別や、有線・無線は問わない。
【００１２】
次に、権限管理システムを構成する各装置のハードウェア構成について説明する。図２は、アプリケーションサーバ１０１、１０３、認証サーバ１０２、クライアント端末１０４のハードウェア構成を示す図である。ＣＰＵ２０１は各種プログラムを実行し、さまざまな機能を実現するユニットである。メモリ２０２は各種情報を一時的に記憶するユニットであり、ハードディスク２０３に記憶されているプログラムをメモリ２０２にロードしプログラムを実行する。また、メモリ２０２はＣＰＵ２０１の一時的な作業記憶領域としても利用される。ハードディスク２０３は各種データを記憶するユニットである（フラッシュメモリなどの同機能を持つ他のハードウェアでもよい）。ユーザインタフェース２０４はユーザからの処理依頼を受け付けたり、ユーザに対して画面を出力するためのユニットである。ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）２０５は、アプリケーションサーバ１０１、１０３、認証サーバ１０２、クライアント端末１０４をネットワーク１００に接続するためのユニットである。図２は、アプリケーションサーバ１０１、１０３、認証サーバ１０２、クライアント端末１０４の代表的なハードウェア構成を例示するものであり、この構成に限定しないことは当業者には明白であろう。
【００１３】
本実施形態では、アプリケーションサーバ１０１のサービス例として、利用者（以下、「顧客」または「カスタマ」と呼ぶ）のデバイス（複写機やプリンタ）の機器管理、改善提案などをアウトソーシングで行うデバイス管理サービスを挙げる。また、アプリケーションサーバ１０３のサービス例として、オンラインプリントサービスを挙げる。デバイス管理サービスには、プロバイダとカスタマという概念がある。プロバイダはデバイス管理のアウトソーシングを行う側であり、カスタマのデバイスをデバイス管理サービスに登録し、機器管理、障害対応、レポート作成による改善提案を行う。デバイス管理サービスを主に利用するのはプロバイダのユーザであり、登録された複数のカスタマから処理対象のカスタマを選択し、デバイス管理サービスの機能（機器登録やレポート作成）を実行する。デバイス管理サービスでは、同じプロバイダユーザ（以下、「プロバイダ」または「ユーザ」とも呼ぶ）であっても、処理対象のカスタマによって機能制限する必要がある。例えば、ｕｓｅｒＢ＠ｘｘｘ．ｃｏｍというプロバイダユーザが、あるカスタマに対しては管理者として担当し、あるカスタマに対しては副管理者として担当し、それぞれ業務上の役割（ロール）が異なる場合である。
【００１４】
図３は、権限管理システムを構成するアプリケーションサーバ１０１、認証サーバ１０２のソフトウェア構成を示している。図３に示されている各ソフトウェア構成の機能を実現するプログラムは、各装置のハードディスク２０３に記憶されており、ＣＰＵ２０１がメモリ２０２にプログラムをロードし実行することで、これらの機能は実現される。
【００１５】
最初に、アプリケーションサーバ１０１を構成するソフトウェアについて説明する。アプリケーションサーバ１０１の中で、各プロバイダ、各カスタマはそれぞれプロバイダテナント３０２、カスタマテナント３０１というマルチテナントのアーキテクチャで管理される。マルチテナントアーキテクチャでは、各テナントのデータはそれぞれ完全に独立して管理される。プロバイダの管理するデータはプロバイダテナント３０２の中で管理され、カスタマの機器情報等のデータはカスタマテナントで管理される。テナント間アクセス制御部３０３は、プロバイダテナントのユーザが管理対象のカスタマテナントに適切にアクセスするためのアクセス制御を行う。例えば、アクセス制御のためのソフトウェアのレイヤを作成し、プロバイダがアクセス権のあるカスタマ以外にはアクセス出来ないように制御する。
【００１６】
カスタマ別ロール管理部３０４は、利用者毎（カスタマ毎）にプロバイダユーザの権限を管理するためのものであり、図１０を用いて詳細を後述する。ロール変更用クレデンシャル管理部３０５は、カスタマ毎にプロバイダユーザの権限を一時的に変更する際に使用するクレデンシャル情報（ユーザ等の認証に用いる認証情報）を管理するためのもので、図１２を用いて詳細を後述する。
【００１７】
権限検証依頼部３０６は、ユーザからデバイス管理サービスの機能実行の指示があった際に、当該ユーザに機能を実行する権限が存在するかを認証サーバ１０２に問い合わせる。権限検証依頼部３０６で管理する、デバイス管理サービスが提供する機能毎に必要な権限の定義例を図４に示す。図４の例では、https://xxx/device.htmlのＨＴＭＬを取得するためにはＲ＿ｄｅｖｉｃｅという権限が必要となる。また、https://xxx/deviceというＲＥＳＴ ＡＰＩへＰＵＴメソッドを実行するためにはＷ＿ｄｅｖｉｃｅという権限、ＧＥＴメソッドを実行するためにはＲ＿ｄｅｖｉｃｅという権限が必要となる。本実施形態ではＪＳＯＮ形式で定義をしているが、管理方法を限定しないことは当業者には明白であろう。
【００１８】
アクセストークン発行依頼部３０７は、ロール変更用クレデンシャル管理部３０５で管理するクレデンシャル情報を使って、認証サーバ１０２にアクセストークン（アクセスを認可する認可情報）の発行を依頼する。委託管理部３０８は、プロバイダが管理するカスタマを別のプロバイダに業務委託する時に、委託関係の情報や委託する機能を管理する。
【００１９】
次に、認証サーバ１０２を構成するソフトウェアについて説明する。認証サーバ１０２においても、プロバイダ、カスタマの情報はマルチテナントアーキテクチャ３２１で管理される。ユーザ情報管理部３２２は、アプリケーションサーバ１０１やアプリケーションサーバ１０３で使用するユーザ情報を管理する。ロール管理部３２３は、権限定義をグループ化したロール情報（役割情報）を管理する。ユーザとロールの紐付け情報管理部３２４は、ユーザ情報管理部３２２で管理するユーザ情報と、ロール管理部３２３で管理するロール情報の紐付けを管理する。権限検証部３２５は、アプリケーションサーバ１０１からの権限検証依頼に対して、機能を実行する権限が存在するかを検証するためのものである。アクセストークン発行部３２６は、アプリケーションサーバ１０１からのアクセストークン発行依頼に対して、依頼を検証し、アクセストークンを発行する。
【００２０】
図５は、認証サーバ１０２のハードディスク２０３で管理するロール管理部３２３のデータ構造の一例を示す図である。テナントＩＤ５０１は、マルチテナントアーキテクチャの中で、データを管理するテナントを識別する情報である。テナントＩＤはテナント毎に一意に発番され、本実施形態では、あるプロバイダテナントのＩＤとして１２３４ＡＡが付番されている。サービスＩＤ５０２は、認証サーバ１０２と連携するサービスを識別する情報である。本実施形態では、アプリケーションサーバ１０１が提供するデバイス管理サービス（ＤｅｖｉｃｅＭａｎａｇｅｍｅｎｔ）、アプリケーションサーバ１０３が提供するオンラインプリントサービス（ＯｎｌｉｎｅＰｒｉｎｔ）を管理する。また、認証サーバ１０２自身も認証サービス（ＡｕｔｈＳｅｒｖｉｃｅ）として管理する。
【００２１】
ロールＩＤ５０３はロールを一意に識別する情報である。ロール名５０４はロールに対して設定したロール名であり、例えば図７のロール作成画面で設定した名前を管理する。ロールの説明５０５は、ロールに対して設定された説明であり、例えば図７のロール作成画面で設定した説明を管理する。権限定義５０６は、ロールに含まれる権限情報である。例えば、ロールＩＤが１００１のデバイス管理者というロールには、Ｒ＿ｄｅｖｉｃｅ、Ｗ＿ｄｅｖｉｃｅ、Ｒ＿ｒｅｐｏｒｔ、Ｗ＿ｒｅｐｏｒｔの権限が含まれていることを表す。ロール管理部３２３には、サービスごとに予め定義されたロールと、図７のロール作成画面でユーザにより新しく定義されたロールが存在する。
【００２２】
図６は、認証サーバ１０２のハードディスク２０３で管理するユーザとロールの紐付け情報管理部３２４のデータ構造の一例を示す図である。テナントＩＤ６０１は、マルチテナントアーキテクチャの中で、データを管理するテナントを識別する情報である。ユーザＩＤ６０２は、ユーザ情報管理部３２２で管理するユーザを一意に識別する情報である。ロールＩＤ６０３はユーザＩＤ６０２に対して紐づくロール情報を識別する情報である。１ユーザに対してロールは複数紐付けることができ、複数紐付けた場合はユーザには複数のロールの論理和の権限が付与される。例えば、ｕｓｅｒＡ＠ｘｘｘ.ｃｏｍのユーザには、デバイス管理者（ロールＩＤ：１００１）と、認証認可の管理者（ロールＩＤ：３００１）が紐付いており、両方の権限を持っていることを表す。
【００２３】
図７は、クライアント端末１０４が認証サーバ１０２から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する新しいロールの作成画面の一例である。本画面を表示、操作するための権限を、認証サーバ１０２では図４と同様に定義しており、本実施形態ではロール情報を操作可能なことを示すＷ＿ｒｏｌｅの権限が必要である。
【００２４】
ログインユーザ表示部７０１は、認証サーバ１０２で認証されたユーザ情報を表示する。図７のユーザｕｓｅｒＡ＠ｘｘｘ.ｃｏｍは、図５と図６に示すようにＷ＿ｒｏｌｅの権限を持っているため、本画面を表示することができる。対象サービス選択部７０２は、ロールを定義する対象のサービスを選択するものである。ロール名入力部７０３は、新しいロールの名前を入力するためのものである。ロール説明入力部７０４は、新しいロールの説明を入力するためのものである。権限定義設定部７０５は、新しいロールに付与する権限を選択するものである。認証サーバ１０２は、サービス毎に権限定義の設定項目を保持しており、対象サービス選択部７０２で選択されたサービスごとに、権限定義設定部７０５の設定項目を変更する。ＯＫボタンが押下されると、認証サーバ１０２は一意なロールＩＤを発番してロール管理部３２３に登録する。図７の状態で登録されたロール情報は、図５のロールＩＤが１００３のデータとなる。
【００２５】
図８は、クライアント端末１０４が認証サーバ１０２から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、ユーザに対してロールを設定する画面の一例である。本画面を表示、操作するための権限として、ロール情報を操作可能なことを示すＷ＿ｒｏｌｅと、自分以外のユーザを操作可能なことを示すＷ＿ｕｓｅｒの権限が必要である。
【００２６】
ログインユーザ表示部８０１は、認証サーバ１０２で認証されたユーザ情報を表示する。図８のユーザｕｓｅｒＡ＠ｘｘｘ.ｃｏｍは、図５と図６に示すようにＷ＿ｒｏｌｅとＷ＿ｕｓｅｒの権限を持っているため、本画面を表示することができる。ユーザ選択部８０２は、認証サーバ１０２に登録されているユーザを検索し、ロールの設定対象のユーザを指定するためのものである。ロール選択部８０３は、設定対象のユーザに対してロールを選択するためのものである。本実施形態では、サービスごとに登録されたロール情報を表示して選択させている。ＯＫボタンが押下されると、認証サーバ１０２は選択されたユーザとロールの紐付けをユーザとロールの紐付け情報管理部３２４に登録する。図８の状態で登録されたロール情報は、図６のｕｓｅｒＢ＠ｘｘｘ.ｃｏｍのデータとなる。
【００２７】
図９は、クライアント端末１０４がアプリケーションサーバ１０１から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、デバイス管理サービスのカスタマ選択画面の一例である。プロバイダユーザは、本画面から機能を実行する対象のカスタマを選択し、選択したカスタマに対してアウトソーシングされたデバイス管理業務を行う。
【００２８】
ログインユーザ表示部９０１は認証サーバ１０２で認証されたユーザ情報を表示する。カスタマ表示部９０２は、プロバイダの顧客として登録されているカスタマの一覧を表示する。カスタマもマルチテナントアーキテクチャで管理しているため、カスタマ毎にも上述したテナントＩＤが発番されている。処理選択部９０３は、選択したカスタマに対して実行する機能を選択するためのものである。処理を選択すると当該処理に応じた画面に遷移し、それぞれの機能を実行する。また、これらの処理を実行するためには図４に示す権限が必要となる。先述したように、デバイス管理サービスでは同じユーザであっても、カスタマによって実行可能な権限を変える必要がある。例えば図９で、ｕｓｅｒＢ＠ｘｘｘ.ｃｏｍのユーザは○○株式会社というカスタマに対しては管理者として担当しているため、デバイス情報の参照、編集やレポートの作成や参照を行う必要がある。一方で、同ユーザは○○不動産に対しては副担当者として担当しているため、レポートの作成は実行できない、といった業務の役割に合わせた権限制御が必要である。認証サーバ１０２ではユーザに対してロールが紐付けられているが、同じユーザであっても処理の対象によって権限を変更する必要がある。
【００２９】
図１０は、アプリケーションサーバ１０１のハードディスク２０３で管理するカスタマ別ロール管理部３０４のデータ構造の一例を示す図である。プロバイダテナントＩＤ１００１は、マルチテナントアーキテクチャの中で、プロバイダのテナントを識別する情報である。カスタマテナントＩＤ１００２は、プロバイダの顧客として登録されているカスタマを一意に識別する情報である。ユーザＩＤ１００３はユーザ情報管理部３２２で管理するユーザを一意に識別する情報で、図１０ではプロバイダのユーザ情報である。ロールＩＤ１００４は、ロール管理部３２３で管理するロールを一意に識別する情報である。図１０の例では、ｕｓｅｒＢ＠ｘｘｘ.ｃｏｍのユーザがカスタマテナントＩＤ：１００ＢＢ（○○株式会社）に対してはロールＩＤ：１００１（デバイス管理者）という権限が割り当てられている。一方、同じｕｓｅｒＢ＠ｘｘｘ.ｃｏｍのユーザが、カスタマテナントＩＤ：２００ＢＢ（○○不動産）に対してはロールＩＤ：１００３（（カスタム）副管理者）という権限が割り当てられている。このように、デバイス管理サービスに適した権限設定を、サービスを提供するアプリケーションサーバ１０１で管理する。また、５行目のユーザＩＤ：＊は、１２３４ＡＡに所属するすべてのユーザが、カスタマ３００ＢＢに対してロールＩＤ：１００４（（委託）自動００１）のロールで権限制御されることを表す。
【００３０】
図１１は、クライアント端末１０４がアプリケーションサーバ１０１から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、カスタマ毎の権限設定画面の一例である。本画面には、図９のデバイス管理サービスのカスタマ選択画面で処理対象のカスタマ毎のロール設定メニューを選択することで遷移する。
【００３１】
ログインユーザ表示部１１０１は、認証サーバ１０２で認証されたユーザ情報を表示する。本画面を表示、操作するための権限を、図４でＲ＿ｒｏｌｅ、Ｗ＿ｒｏｌｅと定義しており、図１１のユーザｕｓｅｒＡ＠ｘｘｘ.ｃｏｍは、図５と図６よりＲ＿ｒｏｌｅ、Ｗ＿ｒｏｌｅの権限を持っているため、本画面を表示することができる。選択カスタマ表示部１１０２は、図９のデバイス管理サービスのカスタマ選択画面で選択した処理対象のカスタマ名を表示する。ユーザ選択部１１０３は、認証サーバ１０２に登録されているユーザを検索し、ロールの設定対象のプロバイダユーザを指定するためのものである。ロール選択部１１０４は、設定対象のカスタマとユーザの組み合わせに対してロールを選択するためのものである。ＯＫボタンが押下されると、アプリケーションサーバ１０１は選択されたカスタマ、プロバイダユーザ、ロールの紐付けをカスタマ別ロール管理部３０４に登録する。本画面により、図１０で先述したｕｓｅｒＢ＠ｘｘｘ.ｃｏｍというプロバイダユーザに対して、カスタマに応じて異なるロールを紐付けることができる。本実施形態では、カスタマ別ロール管理部３０４はカスタマとプロバイダユーザ、ロールの紐付けを管理するが、カスタマグループやプロバイダユーザグループを介してもよく、上記に限定しないことは当業者には明白であろう。
【００３２】
一方で、認証サーバ１０２ではユーザとロールの紐付け情報管理部３２４で管理する紐付け情報をもとに権限検証部３２５で権限の有無を検証する。そのため、アプリケーションサーバ１０１は、ユーザとロールの紐付け情報管理部３２４で管理する紐付け情報を図１０の紐付け情報に変更した上で、認証サーバ１０２に権限検証してもらう必要がある。認証サーバ１０２の紐付けを変更するためには、紐付けを変更する権限が必要となり、本実施形態ではロール情報を操作可能なことを示すＷ＿ｒｏｌｅの権限を持つアクセストークンを使用することで可能となる。
【００３３】
図１２は、クライアント端末１０４がアプリケーションサーバ１０１から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、ロール操作権限の移譲画面の一例である。本画面は、プロバイダユーザが図１１のカスタマ毎の権限設定画面を初めて表示するときに、図１１のカスタマ毎の権限設定画面からリダイレクトされて表示される。
【００３４】
ログインユーザ表示部１２０１は認証サーバ１０２で認証されたユーザ情報を表示する。図１２では、Ｗ＿ｒｏｌｅの権限を持つｕｓｅｒＡ＠ｘｘｘ.ｃｏｍが表示されている。許可ボタン１２０２を押下するとログインユーザであるｕｓｅｒＡ＠ｘｘｘ.ｃｏｍのＷ＿ｒｏｌｅ権限でアクセストークンを発行するためのクレデンシャル情報を生成し、ロール変更用クレデンシャル管理部３０５に保存する。本実施形態ではＯＡｕｔｈ２．０（http://oauth.net/）でアクセストークンの発行時に必要なクライアントクレデンシャルを管理する。カスタマ毎にプロバイダユーザのロールを変更する場合は、このクレデンシャル情報で認証サーバ１０２のロールを変更するためのアクセストークンを認証サーバ１０２に発行させる。これにより認証サーバ１０２に権限検証を依頼する。拒否ボタン１２０３を押下すると、ログインユーザのクレデンシャル情報の発行をキャンセルする。キャンセルされた場合は認証サーバ１０２のロールを変更するためのアクセストークンを発行できないため、図１１のカスタマ毎の権限設定機能は使うことができない。
【００３５】
ロール変更用クレデンシャル変更情報は、認証サーバ１０２のロールを変更するための認可に必要な情報を管理するためのもので、ＯＡｕｔｈ２．０やクライアントクレデンシャルに限定しないことは当業者には明白であろう。また、本実施形態ではログインユーザの権限を移譲することでアクセストークンを発行しているが、ユーザのアクセストークンに限定しない。例えば、システム外で予め発行されたクレデンシャル情報をロール変更用クレデンシャル管理部３０５で管理する方法であってもよい。
【００３６】
また、デバイス管理サービスでは、プロバイダが管理するカスタマの一部のデバイス管理業務を、別のプロバイダへ業務委託するケースがある。例えば、カスタマに対するレポート作成業務だけを、レポート作成や分析業務に特化したプロバイダに委託するような場合である。この場合、特定のカスタマに対して委託先のプロバイダは委託された機能だけを実行できるように権限制御する必要がある。
【００３７】
図１３は、クライアント端末１０４がアプリケーションサーバ１０１から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、カスタマの委託設定画面の一例である。
【００３８】
ログインユーザ表示部１３０１は、認証サーバ１０２で認証されたユーザ情報を表示する。図１３では、委託元のプロバイダ（５６７８ＡＢ）のｕｓｅｒＺ＠ｘｘｘ.ｃｏｍが表示されている。委託対象カスタマ設定部１３０２は、委託元のカスタマリストから、別のプロバイダに委託するカスタマを選択する。委託先プロバイダ設定部１３０３は、委託先のプロバイダテナントを設定する。本実施形態では、委託先のプロバイダのテナントＩＤと、予めシステム外で取り交わした合言葉に該当する委託コードを入力することで委託先のプロバイダテナントを指定する。委託機能選択部１３０４は、委託先プロバイダに委託する機能を選択する。図１３の場合は、デバイス情報の管理については委託せず、レポート機能について委託する。つまり、デバイス情報の管理に関する機能については実行できないように権限制御する必要がある。ＯＫボタンが押下されると、委託管理部３０８は委託機能選択部１３０４で選択された機能を実行するために必要な権限定義を保存する。
【００３９】
図１４は、アプリケーションサーバ１０１のハードディスク２０３で管理する委託管理部３０８のデータ構造の一例を示す図である。委託元テナントＩＤ１４０１は委託元のプロバイダテナントを一意に識別する情報である。委託先テナントＩＤ１４０２は、委託先のプロバイダテナントを一意に識別する情報である。委託対象テナントＩＤ１４０３は、委託元テナントが委託対象に選択したカスタマテナントを一意に識別する情報である。委託機能の権限定義１４０４は、委託元テナントが選択した委託機能を実行するために必要な権限定義である。図１３の委託機能選択部１３０４で選択された機能と、図４の機能ごとの権限定義から設定する。
【００４０】
図１５は、クライアント端末１０４がアプリケーションサーバ１０１から表示情報を受信した時に、クライアント端末１０４のユーザインタフェース２０４に表示する、カスタマの委託承認画面の一例である。
【００４１】
ログインユーザ表示部１５０１は、認証サーバ１０２で認証されたユーザ情報を表示する。図１５では、委託先のプロバイダ（１２３４ＡＢ）のｕｓｅｒＡ＠ｘｘｘ.ｃｏｍが表示されている。本画面を表示、操作するための権限を、図４でＷ＿ｒｏｌｅと定義しており、図１５のユーザｕｓｅｒＡ＠ｘｘｘ.ｃｏｍは、図５と図６に示すようにＷ＿ｒｏｌｅの権限を持っているため、本画面を表示することができる。委託内容表示部１５０２は、図１３で委託元のプロバイダテナントが設定し、委託管理部３０８で管理している内容を表示する。ＯＫボタンを押下すると、テナント間アクセス制御部３０３が委託先テナントと委託対象のカスタマ間のアクセスを許可し、委託先テナントのカスタマリストに委託対象のカスタマが表示される。また、ＯＫボタンが押下された際に、委託管理部の委託機能の権限定義１４０４で管理された権限定義で、認証サーバ１０２のロール管理部３２３に、委託された機能に制限するためのロールを自動で生成する（図５のロールＩＤ：１００４のレコード）。また、カスタマ別ロール管理部３０４に、委託対象の顧客に対して、すべてのユーザを表す「＊」と、作成したロールの組み合わせでレコードを作成する（図１０の５行目）。さらに、ロール変更用クレデンシャル管理部３０５に、ロールを変更するためのクレデンシャル情報が存在しない場合は、図１２と同様にクレデンシャル情報を発行し、保存する。上記の処理により、委託先のプロバイダが委託された顧客に機能を提供する際に、カスタマ別ロール管理部３０４で委託先のすべてのユーザが、委託時に自動生成されたロールで機能制限することができる。
【００４２】
また、上記の情報は、委託先のテナントＩＤに紐付けてロール管理部３２３、カスタマ別ロール管理部３０４、ロール変更用クレデンシャル管理部３０５に登録する必要がある。マルチテナントアーキテクチャでは、ログインユーザのテナント以外にはアクセスできないため、委託承認時に上記の情報を委託先のデータとして登録している。
【００４３】
図１６は、アプリケーションサーバ１０１がプロバイダユーザによってカスタマに対する処理の実行要求を受信した時に行う権限検証のフローチャートである。以下の処理は、図２に示すハードウェア構成において、アプリケーションサーバ１０１のＣＰＵ２０１が各プログラムを実行することにより実現される。
【００４４】
Ｓ１６０１で、アプリケーションサーバ１０１はプロバイダユーザからアクセスされると、認証サーバ１０２のユーザ認証画面（不図示）へリダイレクトする。認証サーバ１０２はユーザ認証画面で入力されたユーザ情報でプロバイダユーザを認証し、認証された証明情報を付与したログイン状態でアプリケーションサーバ１０１のアクセス元画面へリダイレクトする。Ｓ１６０２で、アプリケーションサーバ１０１は図９のカスタマリスト画面を表示し、プロバイダユーザから選択されたカスタマに対する機能実行要求を受信する。Ｓ１６０３で、カスタマ別ロール管理部３０４は、選択されたカスタマとログインユーザの組み合わせでロールが設定されているかどうかを確認する。なお、選択されたカスタマに対してすべてのユーザを表す「＊」が設定されている場合は、ロールが設定されていると判断する。
【００４５】
Ｓ１６０３で該当ロールが設定されている場合、Ｓ１６０４でアクセストークン発行依頼部３０７は、認証サーバ１０２のアクセストークン発行部３２６に対してアクセストークンの発行を依頼して取得する。この発行依頼は、ロール変更用クレデンシャル管理部３０５に予め記憶されているクレデンシャル情報を使用して行なわれる。次に、Ｓ１６０５で、権限検証依頼部３０６は認証サーバ１０２の権限検証部３２５に対して、「ユーザに紐付くロールを使用しない権限検証」（ロール指定ありの権限検証）を依頼する。本実施形態では、当該権限検証のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）は以下の４つのパラメータを受け付ける。
（Ａ）ログインユーザの認証された証明情報
（Ｂ）アプリケーションサーバの機能実行に必要とする権限
（Ｃ）ロール操作権限が付与されたアクセストークン
（Ｄ）ロール情報
【００４６】
権限検証依頼部３０６は、（Ａ）にＳ１６０１で認証サーバ１０２に付与された証明情報を、（Ｃ）にＳ１６０４で生成されたアクセストークンを、（Ｄ）にＳ１６０３でカスタマ別ロール管理部３０４に設定されたロール情報を指定する。また、権限検証依頼部３０６は、要求された機能に対して図４で定義した必要な権限を取得し、（Ｂ）に指定する。このように、予めカスタマ毎に設定されたロールを、ユーザ操作なく自動で切り替えることで、操作性のよい権限制御が行える。
【００４７】
一方、Ｓ１６０３でカスタマとログインユーザの組み合わせでロールが設定されていない場合、権限検証依頼部３０６はＳ１６０８で権限検証部３２５に対して、認証サーバ１０２に「ユーザに紐付くロールを使用した権限検証」を依頼する。本実施例では、当該権限検証のＡＰＩは以下の２つのパラメータを受け付ける。各パラメータは上述した内容と同じである。
（Ａ）ログインユーザの認証された証明情報
（Ｂ）アプリケーションサーバの機能実行に必要とする権限
【００４８】
このようにカスタマ別ロール管理部３０４でカスタマとログインユーザの組み合わせに対してロールが設定されていない場合は、ユーザに紐づくロールを使用する。これにより、カスタマ毎に権限制御を行う必要が無い場合は設定の手間をなくすことができる。
【００４９】
Ｓ１６０６で認証サーバ１０２から権限検証成功の結果を受信すると、Ｓ１６０７でアプリケーションサーバ１０１は選択されたカスタマに対して要求された機能を実行する。Ｓ１６０６で認証サーバ１０２から権限検証失敗の結果を受信した場合は、Ｓ１６０９でアプリケーションサーバ１０１は不図示のエラー画面にエラー内容を表示し、機能の実行をキャンセルする。
【００５０】
図１７は認証サーバ１０２がアプリケーションサーバ１０１から権限検証依頼を受信した時に行う権限検証のフローチャートである。以下の処理は、図２に示すハードウェア構成において、認証サーバ１０２のＣＰＵ２０１が各プログラムを実行することにより実現される。
【００５１】
Ｓ１７０１で、権限検証部３２５はアプリケーションサーバ１０１から図１６を用いて前述した権限検証依頼を受信する。次にＳ１７０２で、権限検証部３２５は受信した権限検証依頼が前述した「ユーザに紐付くロールを使用しない権限検証」 （ロール指定ありの権限検証）であるかどうか判断する。「ユーザに紐付くロールを使用しない権限検証」であると判断した場合、Ｓ１７０３で権限検証部３２５はＡＰＩのパラメータに指定された（Ｃ）のアクセストークンを検証する。Ｓ１７０４で権限検証部３２５はアクセストークンにＷ＿ｒｏｌｅの権限が付与されているかどうかを判断する。
【００５２】
Ｓ１７０４でアクセストークンにＷ＿ｒｏｌｅの権限が付与されていない場合、権限検証部３２５はＳ１７１０で権限検証のエラーを返却する。Ｗ＿ｒｏｌｅの権限が付与されている場合は、権限検証部３２５は、Ｓ１７０５でＡＰＩのパラメータに指定された（Ｄ）のロール情報に対応する権限定義がロール管理部３２３に存在するかどうかを確認する。この時、（Ｃ）のアクセストークンからテナントＩＤ、サービスＩＤを識別し、アクセストークンのテナントＩＤ、サービスＩＤ内にロールが存在するかどうかを確認する。これにより、別のテナントで定義されたロールや、別のサービスで定義されたロールと区別することができる。該当ロールが存在する場合はＳ１７０６で権限検証部３２５はロール管理部３２３から権限定義を取得する。該当ロールが存在しない場合、あるいはロール管理部３２３から権限定義が取得できない場合、権限検証部３２５はＳ１７１０で不正なロールとしてエラーを返却する。
【００５３】
上記のように、「ユーザに紐付くロールを使用しない権限検証」の場合は、検証依頼されたユーザとロールの紐付け情報は変更しない。変更しないことで、同時に「ユーザに紐付くロールを使用した権限検証」の依頼が来た場合にも、タイミングによって紐付け情報が変更されてしまうことを防ぐ。
【００５４】
一方、Ｓ１７０２で、権限検証部３２５は受信した権限検証依頼が前述した「ユーザに紐付くロールを使用した権限検証」であると判断した場合、Ｓ１７０９でユーザとロールの紐付け情報管理部３２４から（Ａ）のユーザに紐付けられたロール情報を取得する。そして、Ｓ１７０６でロールに対応する権限定義を取得する。
【００５５】
次に、Ｓ１７０７で権限検証部３２５はＳ１７０６で取得した権限定義の中に、ＡＰＩのパラメータに指定された（Ｂ）のアプリケーションサーバ１０１の機能実行に必要とする権限が含まれているかどうかを確認する。権限検証部３２５は、Ｓ１７０７で当該権限が含まれていないと判断した場合、Ｓ１７１０で権限検証のエラーを返却し、Ｓ１７０７で当該権限が含まれていると判断した場合、Ｓ１７０８で権限検証成功を返却する。
【００５６】
このように、認証サーバ１０２が提供するロールの紐付け以外に、アプリケーションサーバ１０１に適したロールの紐付けで柔軟な権限検証が可能となる。また、ロール操作が可能なアクセストークンを検証することで、ロール操作を認可したサービスやユーザに対してのみ、上記の柔軟な検証を提供することができる。
【００５７】
本実施形態に記載したデータ構造、画面例は一例であり、データ構造、画面例をこれらに限定しないことは当業者には明白であろう。また、本実施形態ではアプリケーションサーバ１０１はカスタマとユーザの組み合わせでロールを管理したが、アプリケーションサーバ１０１の業務要件に適した組み合わせでロールを管理すればよく、これに限定しないことは当業者には明白であろう。
【００５８】
本発明は、上述の実施形態の１以上の機能を実現するプログラムをシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。この場合、プログラムはネットワーク又はコンピュータ読み取り可能な記録媒体を介して供給される。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５９】
符号  特許請求の範囲中の用語（実施例中の用語）
１０１  第１の情報処理装置（アプリケーションサーバ）
１０２  第２の情報処理装置（認証サーバ）
３０４  管理手段（カスタマ別ロール管理部）
３０５  記憶手段（ロール変更用クレデンシャル管理部）
３０６  検証依頼手段（権限検証依頼部）
３０７  発行依頼手段（アクセストークン発行依頼部）
３２４  権限管理手段（ユーザとロールの紐付け情報管理部）
３２５  検証手段（権限検証部）
３２６  発行手段（アクセストークン発行部）
【図１】
2017182238.tif 000003
【図２】
2017182238.tif 000004
【図３】
2017182238.tif 000005
【図４】
2017182238.tif 000006
【図５】
2017182238.tif 000007
【図６】
2017182238.tif 000008
【図７】
2017182238.tif 000009
【図８】
2017182238.tif 000010
【図９】
2017182238.tif 000011
【図１０】
2017182238.tif 000012
【図１１】
2017182238.tif 000013
【図１２】
2017182238.tif 000014
【図１３】
2017182238.tif 000015
【図１４】
2017182238.tif 000016
【図１５】
2017182238.tif 000017
【図１６】
2017182238.tif 000018
【図１７】
2017182238.tif 000019