JP2017228059A - 情報処理システム及び認可方法 - Google Patents

Abstract

【課題】ユーザの利便性を損ねることなくデバイス装置において認可を実現する情報処理システムを提供すること。【解決手段】デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムであって、前記認証認可装置は、前記デバイス装置に割り当てられているデバイスユーザの情報を記憶するデバイス情報記憶手段と、前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行手段と、前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置に割り当てられている前記デバイスユーザから認可要求を受け付けたものとして前記デバイスユーザに権限を委譲する権限委譲手段と、を有することで上記課題を解決する。【選択図】 図１

Description

本発明は情報処理システム及び認可方法に関する。

近年、インターネット上に展開された所謂クラウドサービスと呼ばれるＷｅｂサービスの利用が拡大している。クラウドサービスは各々がＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開しており、他のアプリケーションやクラウドサービスからＡＰＩを介してサービスを利用させることが可能となっている。

このようなクラウドサービス間の連携やアクセス制御を行う方法としては、例えばＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法が既に知られている（例えば特許文献１参照）。

ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法では、各サービスが利用可能な操作を制限できる。しかしながら、ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法では、ユーザが各サービスに対して明示的に認可を行わなければならず、ユーザの利便性を損ねていた。

本発明の実施の形態は、上記の点に鑑みなされたものであり、ユーザの利便性を損ねることなくデバイス装置において認可を実現する情報処理システムを提供することを目的とする。

上記した課題を達成するために本願請求項１は、デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムであって、前記認証認可装置は、前記デバイス装置に割り当てられているデバイスユーザの情報を記憶するデバイス情報記憶手段と、前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行手段と、前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置に割り当てられている前記デバイスユーザから認可要求を受け付けたものとして前記デバイスユーザに権限を委譲する権限委譲手段と、を有することを特徴とする。

本発明の実施の形態によれば、ユーザの利便性を損ねることなくデバイス装置において認可を実現する情報処理システムを提供できる。

本実施形態に係る情報処理システムの一例の構成図である。 コンピュータの一例のハードウェア構成図である。 画像形成装置の一例のハードウェア構成図である。 本実施形態に係るデバイス装置の一例の処理ブロック図である。 本実施形態に係る認証認可サーバ装置の一例の処理ブロック図である。 機器認証チケット情報の一例の構成図である。 テナント情報の一例の構成図である。 アプリ情報の一例の構成図である。 ユーザ情報の一例の構成図である。 デバイス情報の一例の構成図である。 認可コード情報の一例の構成図である。 アクセストークン情報の一例の構成図である。 リフレッシュトークン情報の一例の構成図である。 ＯＡｕｔｈプロバイダの基本的なデータモデルの一例の説明図である。 ユーザのログイン無しにクライアントアプリへ権限を委譲する処理手順の一例を示した説明図である。 本実施形態に係るＯＡｕｔｈプロバイダのデータモデルの一例の説明図である。 本実施形態におけるスコープ設定の一例の構成図である。 本実施形態に係る情報処理システムの一例のシーケンス図である。 本実施形態に係るＯＡｕｔｈプロバイダのデータモデルの他の例の説明図である。 本実施形態におけるスコープ設定の他の例の構成図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は本実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１は、デバイス装置１０、アプリサーバ装置１２、認証認可サーバ装置１４及びＡＰＩサーバ装置１６が、インターネットなどのネットワーク１８により接続された構成である。

デバイス装置１０はユーザが操作する電子機器である。デバイス装置１０は複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板などの電子機器である。デバイス装置１０は後述の機器認証を行う機能を有している。また、デバイス装置１０はクライアントアプリを実行する。

アプリサーバ装置１２は、一般的なＯＳなどが搭載されたコンピュータによって実現することができる。アプリサーバ装置１２は、デバイス装置１０にアプリケーション（Ｗｅｂアプリ）を提供する。アプリサーバ装置１２からデバイス装置１０に提供されるアプリケーションは、認可を取得してＡＰＩサーバ装置１６が提供するＡＰＩを利用するクライアントアプリである。

認証認可サーバ装置１４は一般的なＯＳなどが搭載されたコンピュータによって実現することができる。認証認可サーバ装置１４はＯＡｕｔｈサービスプロバイダであり、認可コード、アクセストークン、リフレッシュトークンを発行する。認可コードは、ＡＰＩへのアクセス許可を表し、アクセストークン及びリフレッシュトークンを得るために使用される。

アクセストークンは、クライアントアプリが認証済みリクエストを行うために使用されるトークンである。また、リフレッシュトークンはクライアントアプリが新しいアクセストークンを得るために使用されるトークンである。

ＡＰＩサーバ装置１６は一般的なＯＳなどが搭載されたコンピュータによって実現することができる。ＡＰＩサーバ装置１６はＡＰＩに対するリクエストをクライアントアプリから受け付け、クライアントアプリにレスポンスを返す。ＡＰＩサーバ装置１６が提供するＡＰＩはＯＡｕｔｈに対応したＡＰＩであり、利用する場合、通常のパラメータに加えて認可のアクセストークンを付加する必要がある。

図１の情報処理システム１の構成は一例であって、様々な構成が考えられる。例えば認証認可サーバ装置１４とＡＰＩサーバ装置１６とは、一体化されていてもよい。

＜ハードウェア構成＞
《コンピュータ》
図１のアプリサーバ装置１２、認証認可サーバ装置１４及びＡＰＩサーバ装置１６は例えば図２に示すようなハードウェア構成のコンピュータにより実現される。

図２はコンピュータの一例のハードウェア構成図である。図２のコンピュータ５００は入力装置５０１、表示装置５０２、外部Ｉ／Ｆ５０３、ＲＡＭ５０４、ＲＯＭ５０５、ＣＰＵ５０６、通信Ｉ／Ｆ５０７及びＨＤＤ５０８などを備え、それぞれがバスＢで相互に接続されている。なお、入力装置５０１及び表示装置５０２は必要なときに接続して利用する形態であってもよい。

入力装置５０１はキーボードやマウス、タッチパネルなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置５０２はディスプレイ等を含み、コンピュータ５００による処理結果を表示する。

通信Ｉ／Ｆ５０７はコンピュータ５００を各種ネットワークに接続するインタフェースである。これにより、コンピュータ５００は通信Ｉ／Ｆ５０７を介してデータ通信を行うことができる。

また、ＨＤＤ５０８は、プログラムやデータを格納している不揮発性の記憶装置の一例である。格納されるプログラムやデータには、コンピュータ５００全体を制御する基本ソフトウェアであるＯＳ、及びＯＳ上において各種機能を提供するアプリケーションソフトウェア（以下、単にアプリケーションと呼ぶ）などがある。なお、コンピュータ５００はＨＤＤ５０８に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。

外部Ｉ／Ｆ５０３は、外部装置とのインタフェースである。外部装置には、記録媒体５０３ａなどがある。これにより、コンピュータ５００は外部Ｉ／Ｆ５０３を介して記録媒体５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体５０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリなどがある。

ＲＯＭ５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）の一例である。ＲＯＭ５０５にはコンピュータ５００の起動時に実行されるＢＩＯＳ、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ５０４はプログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）の一例である。

ＣＰＵ５０６は、ＲＯＭ５０５やＨＤＤ５０８などの記憶装置からプログラムやデータをＲＡＭ５０４上に読み出し、処理を実行することで、コンピュータ５００全体の制御や機能を実現する演算装置である。

アプリサーバ装置１２、認証認可サーバ装置１４及びＡＰＩサーバ装置１６は例えば図２に示すコンピュータ５００のハードウェア構成により、後述するような各種処理を実現できる。

《画像形成装置》
図１のデバイス装置１０の一例である画像形成装置６００は、例えば図３に示すハードウェア構成のコンピュータにより実現される。図３は画像形成装置の一例のハードウェア構成図である。図３の画像形成装置６００はコントローラ６０１、操作パネル６０２、外部Ｉ／Ｆ６０３、通信Ｉ／Ｆ６０４、プリンタ６０５及びスキャナ６０６などを備える。

コントローラ６０１はＣＰＵ６１１、ＲＡＭ６１２、ＲＯＭ６１３、ＮＶＲＡＭ６１４及びＨＤＤ６１５などを備える。ＲＯＭ６１３は、各種プログラムやデータが格納されている。ＲＡＭ６１２はプログラムやデータを一時保持する。ＮＶＲＡＭ６１４は、例えば設定情報等が格納されている。また、ＨＤＤ６１５は各種プログラムやデータが格納されている。

ＣＰＵ６１１は、ＲＯＭ６１３やＮＶＲＡＭ６１４、ＨＤＤ６１５などからプログラムやデータ、設定情報等をＲＡＭ６１２上に読み出し、処理を実行することで、画像形成装置６００全体の制御や機能を実現する。

操作パネル６０２はユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部Ｉ／Ｆ６０３は外部装置とのインタフェースである。外部装置には、記録媒体６０３ａなどがある。これにより、画像形成装置６００は外部Ｉ／Ｆ６０３を介して記録媒体６０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体６０３ａにはＩＣカード、フレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。

通信Ｉ／Ｆ６０４は、画像形成装置６００をネットワーク１８に接続させるためのインタフェースである。これにより、画像形成装置６００は通信Ｉ／Ｆ６０４を介してデータ通信を行うことができる。プリンタ６０５は印刷データを被搬送物に印刷するための印刷装置である。例えば被搬送物は紙、コート紙、厚紙、ＯＨＰ、プラスチックフィルム、プリプレグ、銅箔など、紙に限定されない。スキャナ６０６は、原稿から画像データ（電子データ）を読み取るための読取装置である。

＜ソフトウェア構成＞
《デバイス装置》
本実施形態に係るデバイス装置１０は例えば図４に示すような処理ブロックにより実現される。図４は本実施形態に係るデバイス装置の一例の処理ブロック図である。デバイス装置１０はクライアントアプリを実行することで、図４に示すような処理ブロックを実現する。デバイス装置１０は、機器認証チケット取得部２０、認可要求部２１、認可コード取得部２２、トークン取得部２３、ＡＰＩ利用部２４、アプリ処理実行部２５を実現している。

機器認証チケット取得部２０は機器認証により認証認可サーバ装置１４から機器認証チケットを取得する。認可要求部２１は取得した機器認証チケットで認証認可サーバ装置１４に対してリソースへのアクセスの認可要求を行う。認可コード取得部２２はリソースへのアクセスが許可された場合に、認証認可サーバ装置１４から認可コードを取得する。

トークン取得部２３は取得した認可コードを使用して認証認可サーバ装置１４からアクセストークン、リフレッシュトークンを取得する。また、トークン取得部２３はリフレッシュトークンを使用して認証認可サーバ装置１４から新しいアクセストークンを取得する。

ＡＰＩ利用部２４はアクセストークンを使用してＡＰＩサーバ装置１６のＡＰＩにアクセスする。アプリ処理実行部２５は、アクセスしたＡＰＩを使用して何らかの処理を実行する。

《認証認可サーバ装置》
本実施形態に係る認証認可サーバ装置１４は、例えば図５に示す処理ブロックにより実現される。図５は本実施形態に係る認証認可サーバ装置の一例の処理ブロック図である。

認証認可サーバ装置１４はプログラムを実行することで、例えば図５に示すような処理ブロックを実現する。認証認可サーバ装置１４は、機器認証チケット発行部３０、認可要求受付部３１、デバイスユーザ取得部３２、認可コード発行部３３、トークン要求受付部３４、トークン発行部３５を実現している。また、認証認可サーバ装置１４は、機器認証チケット情報保存部３６、テナント情報保存部３７、アプリ情報保存部３８、ユーザ情報保存部３９、デバイス情報保存部４０、認可コード情報保存部４１、アクセストークン情報保存部４２、リフレッシュトークン情報保存部４３を有している。

機器認証チケット発行部３０は機器認証によりクライアントアプリに機器認証チケットを発行する。認可要求受付部３１は、クライアントアプリから機器認証チケットを使用した認可要求を受け付ける。デバイスユーザ取得部３２は、機器認証チケットに対応したデバイス装置１０に割り当てられている仮想ユーザ（デバイスユーザ）のユーザＩＤを取得する。

認可コード発行部３３は、機器認証チケットを使用した認可要求であれば、クライアントアプリに割り当てられたデバイスユーザが認可を許可したものとして処理を進める。認可コード発行部３３はデバイスユーザが認可を許可した場合に、認可コードを発行し、認可コードと共にリダイレクトＵＲＬにリダイレクトを行う。発行した認可コードに関する認可コード情報は認可コード情報保存部４１に保存しておく。

また、トークン要求受付部３４はクライアントアプリから認可コードを使用したアクセストークン要求を受け付ける。トークン発行部３５は認可コードに応じたアクセストークン及びリフレッシュトークンを発行する。

なお、発行したアクセストークンに関するアクセストークン情報はアクセストークン情報保存部４２に保存する。発行したリフレッシュトークンに関するリフレッシュトークン情報はリフレッシュトークン情報保存部４３に保存する。トークン発行部３５は発行したアクセストークン及びリフレッシュトークンをアクセストークン要求元のクライアントアプリに返す。

機器認証チケット情報保存部３６はクライアントアプリに発行した機器認証チケットの情報を保存している。テナント情報保存部３７は登録されているテナントの情報を保存している。アプリ情報保存部３８はテナントに登録されているクライアントアプリの情報を保存している。

ユーザ情報保存部３９はテナントに登録されているユーザ及びデバイスユーザの情報を保存している。デバイス情報保存部４０はテナントに登録されているデバイス装置１０の情報を保存している。認可コード情報保存部４１はクライアントアプリに発行された認可コードの情報を保存している。アクセストークン情報保存部４２はクライアントアプリに発行されたアクセストークンの情報を保存している。リフレッシュトークン情報保存部４３はクライアントアプリに発行されたリフレッシュトークンの情報を保存している。

《情報》
図６は機器認証チケット情報の一例の構成図である。図６の機器認証チケット情報は項目としてシリアルＩＤ及びチケット値を有する。シリアルＩＤはデバイス装置１０を識別する識別情報の一例である。チケット値は発行した機器認証チケットの値である。

図７はテナント情報の一例の構成図である。図７のテナント情報は項目としてテナントＩＤを有している。テナントＩＤは、登録されているテナントを識別する識別情報の一例である。テナントは、企業、学校、団体、部門などの組織（グループ）である。テナント情報はアプリ情報、ユーザ情報、デバイス情報などをグループ化する為に利用される。

図８はアプリ情報の一例の構成図である。図８のアプリ情報は項目として、テナントＩＤ、アプリＩＤ及びリダイレクトＵＲＬを有している。アプリＩＤはクライアントアプリを識別する識別情報の一例である。テナントＩＤはクライアントアプリが登録されている組織の識別情報である。リダイレクトＵＲＩはＯＡｕｔｈの認可の際に利用するリダイレクトＵＲＩである。

図９はユーザ情報の一例の構成図である。図９のユーザ情報は項目としてテナントＩＤ及びユーザＩＤを有している。ユーザＩＤはユーザ及びデバイスユーザを識別する識別情報の一例である。テナントＩＤはユーザ及びデバイスユーザが登録されている組織の識別情報である。

図１０はデバイス情報の一例の構成図である。図１０のデバイス情報は項目としてテナントＩＤ、シリアルＩＤ及びユーザＩＤを有している。シリアルＩＤはデバイス装置１０を識別する識別情報の一例である。テナントＩＤはデバイス装置１０が登録されている組織の識別情報である。また、ユーザＩＤはデバイス装置１０に割り当てられているデバイスユーザの識別情報である。

図１１は認可コード情報の一例の構成図である。図１１の認可コード情報は項目としてテナントＩＤ、ユーザＩＤ、アプリＩＤ、リダイレクトＵＲＬ、コード値、スコープを有している。

テナントＩＤはデバイス装置１０が登録されている組織の識別情報である。ユーザＩＤはデバイス装置１０に割り当てられているデバイスユーザの識別情報である。アプリＩＤはクライアントアプリを識別する識別情報の一例である。リダイレクトＵＲＬはＯＡｕｔｈの認可の際に利用するリダイレクトＵＲＩである。コード値は認可コードの一例である一時コードの値を示している。スコープは利用可能なＡＰＩの範囲である。

図１２はアクセストークン情報の一例の構成図である。図１２のアクセストークン情報は項目として、テナントＩＤ、ユーザＩＤ、アプリＩＤ、トークン値、スコープ及びリフレッシュトークンを有している。

テナントＩＤはデバイス装置１０が登録されている組織の識別情報である。ユーザＩＤはデバイス装置１０に割り当てられているデバイスユーザの識別情報である。アプリＩＤはクライアントアプリを識別する識別情報の一例である。トークン値はアクセストークンの値を示している。スコープは利用可能なＡＰＩの範囲である。リフレッシュトークンはリフレッシュトークンの値を示している。

図１３はリフレッシュトークン情報の一例の構成図である。リフレッシュトークン情報は項目としてテナントＩＤ、ユーザＩＤ、アプリＩＤ、トークン値及びスコープを有している。

テナントＩＤは、デバイス装置１０が登録されている組織の識別情報である。ユーザＩＤはデバイス装置１０に割り当てられているデバイスユーザの識別情報である。アプリＩＤは、クライアントアプリを識別する識別情報の一例である。トークン値はリフレッシュトークンの値を示している。スコープは利用可能なＡＰＩの範囲である。

＜処理の詳細＞
以下では、本実施形態に係る情報処理システム１の認可処理について説明する。

《ＯＡｕｔｈプロバイダの基本的なデータモデル》
図１４はＯＡｕｔｈプロバイダの基本的なデータモデルの一例の説明図である。図１４ではユーザがクライアントアプリに権限を委譲することで、クライアントアプリがＡＰＩサーバ装置１６のＡＰＩを利用できるようになることを示している。なお、権限の実体はアクセストークン及びリフレッシュトークンである。

《機器認証を利用したＯＡｕｔｈの認可》
図１４に示したデータモデルではクライアントアプリに権限を委譲するためにユーザのログインが必要となる。図１５はユーザのログイン無しにクライアントアプリへ権限を委譲する処理手順の一例を示した説明図である。図１５ではデバイス装置１０の機番などのシリアルＩＤを利用した機器認証により、ユーザのログイン無しにクライアントアプリへの権限の委譲を実現している。

ステップＳ１に進み、デバイス装置１０のクライアントアプリは認証認可サーバ装置１４に機器認証を要求する。ステップＳ１の機器認証は暗黙的に行われるため、ユーザ操作を必要としない。

ステップＳ２に進み、デバイス装置１０のクライアントアプリはＯＡｕｔｈの認可を認証認可サーバ装置１４に要求する。ステップＳ３において、デバイス装置１０のクライアントアプリは認証認可サーバ装置１４からアクセストークンを取得する。ステップＳ４においてデバイス装置１０のクライアントアプリはアクセストークンを使用することでＡＰＩサーバ装置１６のＡＰＩが利用できるようになる。

《デバイスユーザへの権限の割り当て》
本実施形態では、デバイス装置１０に仮想ユーザ（デバイスユーザ）を割り当て、機器認証により得た権限をデバイスユーザへ割り当てる。図１６は本実施形態に係るＯＡｕｔｈプロバイダのデータモデルの一例の説明図である。そして図１６では機器認証チケットを使用した認可要求を行うことにより、ユーザのログイン無しにクライアントアプリへの権限の委譲を実現している。

図１６のデータモデルの場合、デバイス装置１０では機器認証後にデバイスユーザでログインしている状態となる。認証認可サーバ装置１４は機器認証チケットを使用した認可要求を受け付けた場合に、デバイスユーザが認可を許可したものと判断して処理を進めることができる。なお、デバイスユーザはデバイス装置１０の登録時に作成される。

図１６に示すように、本実施形態のＯＡｕｔｈプロバイダのデータモデルは図１４に示したデータモデルを一部修正したものであり、内部ロジックも基本的な構成をそのまま利用できる。

ただし、本実施形態では認可したのがユーザでなくデバイスユーザであるため、利用可能なＡＰＩの範囲（スコープ）を例えば図１７に示すように制限する。図１７は本実施形態におけるスコープ設定の一例の構成図である。図１７では、利用可能な主体者（ユーザロール）によりスコープを制限している。

図１７では、一般ユーザ及びデバイスユーザが企業情報取得権限を有し、利用可能なＡＰＩが「企業情報を取得する」であることを表している。また、図１７では企業管理者が企業情報更新権限を有し、利用可能なＡＰＩが「企業情報を取得する」と「企業情報を更新する」であることを表している。このように本実施形態ではデバイスユーザが認可した場合に、企業管理者が認可した場合よりもスコープを制限できる。

図１８は本実施形態に係る情報処理システムの一例のシーケンス図である。ステップＳ２１に進み、デバイス装置１０のブラウザ５０はユーザからＡＰＩサーバ装置１６のＡＰＩを利用する要求を受け付ける。ステップＳ２２に進み、ブラウザ５０はクライアントアプリ５２にＡＰＩサーバ装置１６のＡＰＩの利用を要求する。

ステップＳ２３において、クライアントアプリ５２は認証認可サーバ装置１４に機器認証を要求する。機器認証に成功すると、クライアントアプリ５２は認証認可サーバ装置１４から機器認証チケットを取得する。

ステップＳ２４に進み、クライアントアプリ５２は取得した機器認証チケットと図１７に示したようなスコープで認証認可サーバ装置１４に対してリソースへのアクセスの認可要求を行う。ステップＳ２５に進み、認証認可サーバ装置１４のデバイスユーザ取得部３２は機器認証チケットと対応付けられたシリアルＩＤを図６の機器認証チケット情報から取得する。そして、デバイスユーザ取得部３２は取得したシリアルＩＤと対応付けられたデバイスユーザＩＤを図１０のデバイス情報から取得する。

ステップＳ２６に進み、認可コード発行部３３は認可コードとして一時コードを発行すると共に、発行した一時コードと対応付けて、デバイスユーザＩＤと図１７に示したようなスコープとを認可コード情報に保存する。認可コード発行部３３は一時コードと共にリダイレクトＵＲＬにリダイレクトを行う。

ステップＳ２７に進み、クライアントアプリ５２は取得した一時コードを使用して認証認可サーバ装置１４にアクセストークン取得を要求する。認証認可サーバ装置１４は一時コードを使用したアクセストークン取得の要求を受け付ける。

ステップＳ２８に進み、認証認可サーバ装置１４のトークン発行部３５は取得した一時コードと対応付けられたデバイスユーザＩＤ及びスコープを図１１の認可コード情報から取得する。そして、ステップＳ２９に進み、トークン発行部３５はアクセストークン及びリフレッシュトークンを発行する。

トークン発行部３５は、発行したアクセストークンをデバイスユーザＩＤ及びスコープと対応付けて図１２のアクセストークン情報に保存する。また、トークン発行部３５は発行したリフレッシュトークンをデバイスユーザＩＤ及びスコープと対応付けて図１３のリフレッシュトークン情報に保存する。ステップＳ３０に進み、トークン発行部３５は発行したアクセストークン及びリフレッシュトークンをアクセストークン要求元のクライアントアプリに返す。そして、ステップＳ３１に進み、クライアントアプリ５２は取得したアクセストークンを使用してＡＰＩサーバ装置１６のＡＰＩにアクセスすることができるようになる。

＜まとめ＞
本実施形態によれば、ユーザのログイン無しに、デバイス装置１０においてＯＡｕｔｈの認可が可能となる。このように、本実施形態ではデバイス装置１０の操作パネルにアカウント情報を入力することなく、ＯＡｕｔｈの標準仕様に従ったＡＰＩを、ユーザに簡単に提供できる。
［他の実施形態］
第１の実施形態では、デバイス装置１０にデバイスユーザを割り当て、機器認証により得た権限をデバイスユーザへ割り当てていた。機器認証により得た権限はデバイス装置１０に割り当てるようにしてもよい。

図１９は、本実施形態に係るＯＡｕｔｈプロバイダのデータモデルの他の例の説明図である。図１９のデータモデルは、図１６のデータモデルと比べて構成が簡単になるがシリアルＩＤと権限とを対応付ける情報が必要となる。また、図１９のデータモデルの場合も認可したのがユーザでなくデバイスであるため、スコープを例えば図２０に示すように制限する。

図２０は本実施形態におけるスコープ設定の他の例の構成図である。図２０では主体者別に利用可能な種別を制限している。図２０では利用可能な主体者がユーザ及びデバイスであり、企業管理者、一般ユーザ及びＲ社のＭＦＰが企業情報取得権限を有し、利用可能なＡＰＩが「企業情報を取得する」であることを表している。

また、図２０では、利用可能な主体者がユーザであり、企業管理者が企業情報更新権限を有し、利用可能なＡＰＩが「企業情報を取得する」と「企業情報を更新する」であることを表している。このように本実施形態ではデバイスが認可した場合に、企業管理者が認可した場合よりもスコープを制限できる。

このように、本実施形態によれば、ユーザの利便性を損ねることなくデバイス装置において認可を実現できる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。認証認可サーバ装置１４は特許請求の範囲に記載した認証認可装置の一例である。デバイス情報保存部４０はデバイス情報記憶手段の一例である。機器認証チケット発行部３０は機器認証チケット発行手段の一例である。認可コード発行部３３、トークン要求受付部３４及びトークン発行部３５は権限委譲手段の一例である。

１ 情報処理システム
１０ デバイス装置
１２ アプリサーバ装置
１４ 認証認可サーバ装置
１６ ＡＰＩサーバ装置
１８ ネットワーク
２０ 機器認証チケット取得部
２１ 認可要求部
２２ 認可コード取得部
２３ トークン取得部
２４ ＡＰＩ利用部
２５ アプリ処理実行部
３０ 機器認証チケット発行部
３１ 認可要求受付部
３２ デバイスユーザ取得部
３３ 認可コード発行部
３４ トークン要求受付部
３５ トークン発行部
３６ 機器認証チケット情報保存部
３７ テナント情報保存部
３８ アプリ情報保存部
３９ ユーザ情報保存部
４０ デバイス情報保存部
４１ 認可コード情報保存部
４２ アクセストークン情報保存部
４３ リフレッシュトークン情報保存部
５０ ブラウザ
５２ クライアントアプリ
５００ コンピュータ
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ ＲＡＭ
５０５ ＲＯＭ
５０６ ＣＰＵ
５０７ 通信Ｉ／Ｆ
５０８ ＨＤＤ
６００ 画像形成装置
６０１ コントローラ
６０２ 操作パネル
６０３ 外部Ｉ／Ｆ
６０３ａ 記録媒体
６０４ 通信Ｉ／Ｆ
６０５ プリンタ
６０６ スキャナ
６１１ ＣＰＵ
６１２ ＲＡＭ
６１３ ＲＯＭ
６１４ ＮＶＲＡＭ
６１５ ＨＤＤ
Ｂ バス

特開２０１５−９５０５６号公報

Claims (7)

1. デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムであって、
   前記認証認可装置は、
   前記デバイス装置に割り当てられているデバイスユーザの情報を記憶するデバイス情報記憶手段と、
   前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行手段と、
   前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置に割り当てられている前記デバイスユーザから認可要求を受け付けたものとして前記デバイスユーザに権限を委譲する権限委譲手段と、
   を有する情報処理システム。
2. 前記権限委譲手段は、前記デバイスユーザに委譲する権限の範囲を制限すること
   を特徴とする請求項１記載の情報処理システム。
3. 前記デバイスユーザはデバイス情報の前記認証認可装置への登録時に前記デバイス情報記憶手段に記憶されること
   を特徴とする請求項１又は２記載の情報処理システム。
4. デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムであって、
   前記認証認可装置は、
   前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行手段と、
   前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置から認可要求を受け付けたものとして前記デバイス装置に権限を委譲する権限委譲手段と、
   を有する情報処理システム。
5. 前記権限委譲手段は、前記デバイス装置に委譲する権限の範囲を前記デバイス装置の種別により制限すること
   を特徴とする請求項４記載の情報処理システム。
6. デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムにおいて実行される認可方法であって、
   前記デバイス装置に割り当てられているデバイスユーザの情報をデバイス情報記憶部に記憶する記憶ステップと、
   前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行ステップと、
   前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置に割り当てられている前記デバイスユーザから認可要求を受け付けたものとして前記デバイスユーザに権限を委譲する権限委譲ステップと、
   を有する認可方法。
7. デバイス装置と、前記デバイス装置に対する認証認可を行う認証認可装置と、を有する情報処理システムにおいて実行される認可方法であって、
   前記デバイス装置からの機器認証要求を受け付け、前記デバイス装置に対して機器認証チケットを発行する機器認証チケット発行ステップと、
   前記デバイス装置から前記機器認証チケットを使用した認可要求を受け付けた場合に前記デバイス装置から認可要求を受け付けたものとして前記デバイス装置に権限を委譲する権限委譲ステップと、
   を有する認可方法。

Images