JP6064636B2 - 情報処理システム、情報処理装置、認証方法及びプログラム - Google Patents

Description

本発明は情報処理システム、情報処理装置、認証方法及びプログラムに関する。

近年、注目されているクラウドコンピューティングは、サーバがクライアントにサービスを提供する一形態である。クラウドコンピューティングでは、多くのコンピューティング・リソースを用いてデータ処理を実行し、クライアントからの要求を処理する。このようなクラウドコンピューティングを実現するクラウドコンピューティング環境上にＷｅｂサービスを実装し、多種多様なサービスを提供するベンダーも多数存在する（例えば特許文献１参照）。

ユーザは、クラウドコンピューティングにより提供される多種多様なサービスを利用するために、複数の認証を行わなければならない場合がある。なお、ユーザに対する認証の重荷を減らすための技法としてシングルサインオン（ＳＳＯ）が知られている。シングルサインオンによりユーザはサインオン動作を完了した後、すなわち認証されたあとに別の認証動作を実行する必要がなくなる（例えば特許文献２参照）。

シングルサインオンは複数のサービスで共通の認証基盤を利用し、何れかのサービスで認証を行えば、他のサービスでの認証が省略できる認証方式である。シングルサインオンでは認証・認可の情報を提供するＩｄＰ（Identity Provider）と、ＩｄＰが発行した認証・認可の情報に応じてクライアントにサービスを提供するＳＰ（Service Provider）との間で、事前に信頼関係を結んでおく必要がある。このようなＩｄＰとＳＰとの間で結ばれた信頼関係はトラストサークルと呼ばれる。ＩｄＰで認証されたユーザは、そのＩｄＰと事前に信頼関係を結んだ（同一のトラストサークルに含まれる）複数のＳＰへの認証を省略できる。

ところで、クラウドコンピューティングにより提供されるＩｄＰのサービスは複数の組織に利用される場合がある。同一のトラストサークルに含ませるＳＰは組織によって異なることが想定されるが、従来のＩｄＰにおいては対応が困難であった。

本発明の実施の形態は、上記の点に鑑みなされたもので、認証における信頼関係の設定自由度を向上できる情報処理システム、情報処理装置、認証方法及びプログラムを提供することを目的とする。

上記目的を達成するために本願請求項１は、１以上の情報処理装置を含む情報処理システムであって、外部装置からユーザ識別情報、組織識別情報を受信する受信手段と、組織識別情報に関連付けて１以上のユーザ識別情報を記憶する第１の記憶手段を用いて前記受信手段が受信した前記ユーザ識別情報、組織識別情報に対する認証を実行する認証手段と、を備え、前記認証手段は、認証済みの前記外部装置から外部サービスとの連携認証要求を受信すると、認証に関しての信頼関係を結んだ１以上の外部サービスを前記組織識別情報と関連付けて記憶する第２の記憶手段に、前記外部装置から受信した前記組織識別情報と前記連携認証要求の対象となる外部サービスとが関連付けられていれば、前記外部装置に連携認証応答を送信することを特徴とする。

本発明の実施の形態によれば、認証における信頼関係の設定自由度を向上できる。

第１の実施形態に係る情報処理システムの一例の構成図である。 サービス提供システムの他の例の構成図である。 コンピュータシステムの一例のハードウェア構成図である。 第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。 組織情報の一例のデータ構造図である。 ユーザ情報の一例の構成図である。 機器情報の一例の構成図である。 サービスプロバイダのＩＤを入力する画面の一例のイメージ図である。 サービスプロバイダ側に設定する情報を表示する画面の一例のイメージ図である。 画面遷移の一例を表した説明図である。 画面遷移の他の例を表した説明図である。 ブラウザからシングルサインオン設定済みの外部サービスにアクセスする処理手順を表した一例のシーケンス図である。 認証・認可部の処理手順を表した一例のフローチャートである。 ポータルサービスアプリの処理手順を表した一例のフローチャートである。 ブラウザからシングルサインオン設定済みの外部サービスにアクセスする処理手順を表した他の例のシーケンス図である。 エラー発生時の処理手順を表した一例のシーケンス図である。 エラー情報を合わせて表示するログイン画面の一例のイメージ図である。 サービスプロバイダＵＲＬを高速な記憶装置にキャッシュする処理の一例のフローチャートである。 ＡＰＩ連携時の処理手順を表した一例のシーケンス図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は第１の実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１０００は例えばオフィス内ネットワーク等のネットワークＮ１と、クラウドサービスに代表されるサービス提供システムのネットワークＮ２と、インターネットなどのネットワークＮ３とを有する。

ネットワークＮ１は、ファイヤウォールＦＷの内側にあるプライベートなネットワークである。ファイヤウォールＦＷはネットワークＮ１とネットワークＮ３との接点に設置され、不正なアクセスを検出及び遮断する。ネットワークＮ１にはクライアント端末１０１１、携帯端末１０１２、複合機などの画像形成装置１０１３が接続されている。

クライアント端末１０１１は端末装置の一例である。クライアント端末１０１１は一般的なＯＳなどが搭載された情報処理装置によって実現できる。クライアント端末１０１１は無線による通信の手段または有線による通信の手段を有する。クライアント端末１０１１は、タブレットＰＣ、ノートＰＣなど、ユーザが操作可能な端末である。

携帯端末１０１２は端末装置の一例である。携帯端末１０１２は、無線による通信の手段または有線による通信の手段を有している。携帯端末１０１２は、スマートフォンや携帯電話、タブレットＰＣ、ノートＰＣなど、ユーザが携帯可能な端末である。

画像形成装置１０１３は複合機などの画像形成機能を有する装置である。画像形成装置１０１３は無線による通信の手段または有線による通信の手段を有する。画像形成装置１０１３は複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板など、画像形成に係る処理を行う装置である。図１では、一例としてクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３がそれぞれ一台である例を示しているが複数台であってもよい。

ネットワークＮ２はアクセス制御装置１０２１によってネットワークＮ３に接続されている。ネットワークＮ２はアクセス制御装置１０２１によってセキュリティが保護されている。ネットワークＮ２にはプリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４が接続されている。

図１の情報処理システム１０００は、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４がサービス提供システムを実現している。プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４はプリントサービス、スキャンサービスや他サービスを提供する。

アクセス制御装置１０２１はプリントサービス提供装置１０２２が提供するプリントサービスやスキャンサービス提供装置１０２３が提供するスキャンサービスなどへのログインを制御する。

アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、一台以上の情報処理装置によって実現される。

アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は一台の情報処理装置に統合して実現してもよいし、複数の情報処理装置に分散して実現してもよい。

ネットワークＮ２側のサービスの一部はネットワークＮ２以外にあってもよい。携帯端末１０１２は、オフィス内ネットワーク等のネットワークＮ１以外にあってもよい。図１の情報処理システム１０００では携帯端末１０１２がネットワークＮ１と、ネットワークＮ３とにある例を示している。

ネットワークＮ３に接続されている外部サービス１０３１は例えばサービスをオンラインストレージなどのサービスを提供する装置である。なお、外部サービス１０３１はＩｄＰが発行した認証・認可の情報に応じてクライアントにサービスを提供するＳＰの一例である。サービス提供システムはＩｄＰ及びＳＰの一例である。

図１のサービス提供システムの構成は一例であって、図２に示すような構成によっても実現できる。図２はサービス提供システムの他の例の構成図である。図２のサービス提供システムはネットワークＮ２がファイヤウォールＦＷによってネットワークＮ３に接続されている。

ネットワークＮ２にはＳａａＳ（Software as a Service）系のサービス提供装置、共通サービス（Network Service Platform）系のサービス提供装置、ストレージ（Storage）系の記憶装置が接続されている。なお、共通サービス系のサービス提供装置はＳａａＳ系のサービス提供装置が共通で使えるサービスを提供する。

ＳａａＳ系のサービス提供装置は、例えばポータルサービス提供装置１０５１、プリントサービス提供装置１０５２、スキャンサービス提供装置１０５３など、提供するサービスに応じたサービス提供装置が含まれる。また、共通サービス系のサービス提供装置は、例えば認証サービス提供装置１０６１、データ処理サービス提供装置１０６２、一時データ保存サービス提供装置１０６３など、提供する共通サービスに応じたサービス提供装置が含まれる。ストレージ系の記憶装置は、例えば認証情報記憶装置１０７１、ジョブ情報記憶装置１０７２、一時データ記憶装置１０７３など、記憶する情報（データ）に応じた記憶装置が含まれる。

図２のサービス提供システムでは、例えばファイヤウォールＦＷ、認証サービス提供装置１０６１が提供する認証サービスによってセキュリティが保護されている。なお、図２のサービス提供システムの構成も一例であって、他の構成であってもよい。

＜ハードウェア構成＞
図１のクライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、例えば図３に示すようなハードウェア構成のコンピュータシステムにより実現される。

図２のＳａａＳ系のサービス提供装置、共通サービス系のサービス提供装置、ストレージ系の記憶装置も、例えば図３に示すようなハードウェア構成のコンピュータシステムにより実現される。

図３はコンピュータシステムの一例のハードウェア構成図である。図３のコンピュータシステム１５００は、入力装置１５０１、表示装置１５０２、外部Ｉ／Ｆ１５０３、ＲＡＭ（Random Access Memory）１５０４、ＲＯＭ（Read Only Memory）１５０５、ＣＰＵ（Central Processing Unit）１５０６、通信Ｉ／Ｆ１５０７、及びＨＤＤ（Hard Disk Drive）１５０８などを備え、それぞれがバスＢで相互に接続されている。

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

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

ＨＤＤ１５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、例えばコンピュータシステム１５００全体を制御する基本ソフトウェアであるＯＳ（Operating System）や、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。

ＨＤＤ１５０８は格納しているプログラムやデータを所定のファイルシステム及び／又はＤＢ（データベース）により管理している。外部Ｉ／Ｆ１５０３は、外部装置とのインタフェースである。外部装置には、記録媒体１５０３ａなどがある。これにより、コンピュータシステム１５００は外部Ｉ／Ｆ１５０３を介して記録媒体１５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１５０３ａにはフレキシブルディスク、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（SD Memory card）、ＵＳＢメモリ（Universal Serial Bus memory）などがある。

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

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

クライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、コンピュータシステム１５００のハードウェア構成により、後述するような各種処理を実現できる。また、図２のＳａａＳ系のサービス提供装置、共通サービス系のサービス提供装置、ストレージ系の記憶装置も、コンピュータシステム１５００のハードウェア構成により、後述するような各種処理を実現できる。なお、図１に示した画像形成装置１０１３、ファイヤウォールＦＷのハードウェア構成については説明を省略する。

＜ソフトウェア構成＞
《サービス提供システム》
第１の実施形態に係るサービス提供システムは例えば図４に示す処理ブロックにより実現される。図４は第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。

サービス提供システム１１００はプログラムを実行することにより、アプリケーション１１０１、共通サービス１１０２、データベース（ＤＢ）１１０３及びプラットフォームＡＰＩ（Application Programming Interface）１１０４を実現している。

アプリケーション１１０１は、ポータルサービスアプリ１１１１、スキャンサービスアプリ１１１２、プリントサービスアプリ１１１３を一例として有する。

ポータルサービスアプリ１１１１は、ポータルサービスを提供するアプリケーションである。ポータルサービスは、サービス提供システム１１００を利用するための入り口となるサービスを提供する。スキャンサービスアプリ１１１２はスキャンサービスを提供するアプリケーションである。プリントサービスアプリ１１１３はプリントサービスを提供するアプリケーションである。アプリケーション１１０１には、その他のサービスアプリが含まれていてもよい。

プラットフォームＡＰＩ１１０４はポータルサービスアプリ１１１１、スキャンサービスアプリ１１１２、プリントサービスアプリ１１１３などのアプリケーション１１０１が共通サービス１１０２を利用するためのインタフェースである。プラットフォームＡＰＩ１１０４はアプリケーション１１０１からの要求を共通サービス１１０２が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。

プラットフォームＡＰＩ１１０４は、サービス提供システム１１００が複数の情報処理装置で構成される場合、ネットワーク経由で利用可能な例えばＷｅｂ ＡＰＩにより実現できる。

共通サービス１１０２は、認証・認可部１１２１、組織管理部１１２２、ユーザ管理部１１２３、ライセンス管理部１１２４、機器管理部１１２５、一時画像保存部１１２６、画像処理ワークフロー制御部１１２７、ログ収集部１１２８を有する。

また、画像処理ワークフロー制御部１１２７はメッセージキュー１１３１、１つ以上のワーカー（Ｗｏｒｋｅｒ）１１３２を有する。ワーカー１１３２は画像変換や画像送信などの機能を実現する。

認証・認可部１１２１は、クライアント端末１０１１や画像形成装置１０１３などのオフィス機器からのログイン要求に基づいて認証・認可を実行する。オフィス機器はクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３などの総称である。

認証・認可部１１２１は、例えば後述するユーザ情報記憶部１１４３、ライセンス情報記憶部１１４４などにアクセスしてユーザを認証・認可する。また、認証・認可部１１２１は例えば後述する組織情報記憶部１１４２、ライセンス情報記憶部１１４４、機器情報記憶部１１４５などにアクセスして画像形成装置１０１３などを認証する。

組織管理部１１２２は後述する組織情報記憶部１１４２に記憶されている組織情報を管理する。ユーザ管理部１１２３は、後述するユーザ情報記憶部１１４３に記憶されているユーザ情報を管理する。

ライセンス管理部１１２４は後述するライセンス情報記憶部１１４４に記憶されているライセンス情報を管理する。機器管理部１１２５は後述する機器情報記憶部１１４５に記憶されている機器情報を管理する。一時画像保存部１１２６は後述する一時画像記憶部１１４６への一時画像の保存、一時画像記憶部１１４６からの一時画像の取得を行う。

画像処理ワークフロー制御部１１２７はアプリケーション１１０１からの要求に基づいて画像処理に関するワークフローを制御する。メッセージキュー１１３１は処理の種類に対応するキューを有する。画像処理ワークフロー制御部１１２７は処理（ジョブ）に係るリクエストのメッセージを、そのジョブの種類に対応するキューに投入する。

ワーカー１１３２は対応するキューを監視している。キューにメッセージが投入されるとワーカー１１３２は、対応するジョブの種類に応じた画像変換や画像送信などの処理を行う。なお、キューに投入されたメッセージはワーカー１１３２が主体的に読み出す（Ｐｕｌｌ）ようにしてもよいし、キューからワーカー１１３２に提供する（Ｐｕｓｈ）ようにしてもよい。

データベース１１０３は、ログ情報記憶部１１４１、組織情報記憶部１１４２、ユーザ情報記憶部１１４３、ライセンス情報記憶部１１４４、機器情報記憶部１１４５、一時画像記憶部１１４６、ジョブ情報記憶部１１４７、アプリケーション固有の設定情報記憶部１１４８を有する。

ログ情報記憶部１１４１は、ログ情報を記憶する。組織情報記憶部１１４２は、後述の組織情報を記憶する。ユーザ情報記憶部１１４３は、後述のユーザ情報を記憶する。ライセンス情報記憶部１１４４は、ライセンス情報を記憶する。機器情報記憶部１１４５は後述の機器情報を記憶する。

一時画像記憶部１１４６は一時画像を記憶する。一時画像は、例えばワーカー１１３２が処理するスキャン画像などのファイルやデータである。ジョブ情報記憶部１１４７は処理（ジョブ）に係るリクエストの情報（ジョブ情報）を記憶する。アプリケーション固有の設定情報記憶部１１４８はアプリケーション１１０１に固有の設定情報を記憶する。

サービス提供システム１１００は、認証・認可や画像処理に関するワークフローなどの共通サービスを提供する統合基盤と、統合基盤の機能を利用してスキャンサービス、プリントサービス、ポータルサービス等のアプリサービスを提供するサービス群と、して機能する。統合基盤は例えば共通サービス１１０２、ＤＢ１１０３及びプラットフォームＡＰＩ１１０４によって構成される。サービス群は例えばアプリケーション１１０１によって構成される。

図４に示したサービス提供システム１１００はサービス群と統合基盤とを分離した構成により、プラットフォームＡＰＩ１１０４を利用するアプリケーション１１０１を容易に開発できる。

なお、図４に示したサービス提供システム１１００の処理ブロックの分類形態は一例であり、アプリケーション１１０１、共通サービス１１０２、ＤＢ１１０３が図４に示されるような階層で分類されていることが必須ではない。第１の実施形態に係るサービス提供システム１１００の処理を実施できるのであれば、図４に示される階層関係などは特定のものに限定されない。

図５は組織情報の一例のデータ構造図である。図５の組織情報は組織、トラストサークル、ＳＰ、ＩｄＰが紐付けられた情報である。図５の組織情報に含まれる組織は、組織ＩＤ、組織名表示言語、タイムゾーン、状態、国などを項目として有する。図５の組織情報に含まれるトラストサークルは、トラストサークル名などを項目として有する。図５の組織情報に含まれるサービスプロバイダ（ＳＰ）はサービスプロバイダ名、サービスプロバイダＵＲＬ及びＡＣＳ（Assertion Consumer Service）などを項目として有する。ＡＣＳは後述のＳＡＭＬ（Secure Assertion Markup Language）レスポンスをＰＯＳＴする宛先である。また、図５の組織情報に含まれる認証プロバイダ（ＩｄＰ）は認証プロバイダ名、ログインＵＲＬ、ログアウトＵＲＬ、パスワード変更ＵＲＬ、署名鍵などを項目として有する。

なお、組織ＩＤは企業、部署などのグループを特定する情報である。組織ＩＤは組織という言語に限定されるものではなく、例えば契約を識別する情報であってもよい。組織ＩＤは一意である。

組織名表示言語は企業、部署などのグループの名称を表示する言語を表している。タイムゾーンは企業、部署などのグループが利用する標準時を表している。状態は企業、部署などのグループの状態を表している。国は企業、部署などのグループの属する国名を表している。

図５に示すように後述のシングルサインオン設定は組織情報として保管される。図５に示す組織情報により、サービス提供システム１１００は組織に紐付くトラストサークルを設定できるので、複数の組織に対応したＳＡＭＬベースのシングルサインオンを実現することができる。

図６はユーザ情報の一例の構成図である。ユーザ情報は、項目として組織ＩＤ、ユーザ名、パスワード、アドレス情報などを有する。ユーザ名、パスワードはユーザを特定する情報である。したがって、ユーザ名はユーザＩＤ等であってもよい。また、パスワードは必須でない。同じ組織ＩＤで管理されるユーザ名、パスワードは一意であるが、組織ＩＤが異なれば重複していてもよい。アドレス情報は、例えばユーザのメールアドレスを表している。

さらに、ユーザ名はユーザが所持する電子媒体（例えばＩＣカード）を識別する情報を用いてもよい。ユーザが所持する電子媒体としてはＩＣカード、携帯電話、タブレット端末、電子書籍端末等を利用できる。電子媒体を識別する情報としては、カードＩＤ、シリアルＩＤ、携帯電話の電話番号、端末のプロフィール情報などを利用できる。電子媒体を識別する情報は組み合わせて利用してもよい。

図７は機器情報の一例の構成図である。図７の機器情報は項目として組織ＩＤ、デバイス認証情報、事業所情報、ケーパビリティなどを有する。デバイス認証情報はオフィス機器が特定の条件を備えていることを判別するデバイス認証のための情報である。デバイス認証情報はオフィス機器に特定のアプリケーションが搭載されていることを示すＩＤや特定のオフィス機器であることを示す機器番号などであってもよい。事業所情報は例えばオフィス機器が設置されている事業所を表している。ケーパビリティは例えばオフィス機器の能力を表している。

＜処理の詳細＞
《シングルサインオン設定》
サービス提供システム１１００と外部サービス１０３１などのサービスプロバイダとの間でシングルサインオンを利用する場合は、管理者などがサービス提供システム１１００とサービスプロバイダとの間で信頼関係を結んでおく必要がある。例えば管理者は導入時に、サービス提供システム１１００のシングルサインオン設定と、外部サービス１０３１のシングルサインオン設定と、を行う。

まず、サービス提供システム１１００のシングルサインオン設定には、外部サービス１０３１などのサービスプロバイダのＩＤの入力が必要である。図８はサービスプロバイダのＩＤを入力する画面の一例のイメージ図である。管理者はシングルサインオンを利用するサービスプロバイダのＩＤ（ドメイン名、ＵＲＬなど）として、例えば外部サービス１０３１に登録したドメイン名を図８の画面に入力する。図８の画面に入力したドメイン名は外部サービス１０３１側において、サービス提供システム１１００の組織ＩＤと同様な役目を担う。

ポータルサービスアプリ１１１１はサービスプロバイダ側に設定する情報の一例として外部サービス１０３１に設定する情報を例えば図９に示すように表示する。図９はサービスプロバイダ側に設定する情報を表示する画面の一例のイメージ図である。サービスプロバイダ側に設定する情報は、例えばログイン、ログアウト及びパスワード変更のためのＵＲＬ、署名検証用の公開鍵証明書（検証証明書）などである。

なお、図９におけるログインのためのＵＲＬ（サインインページＵＲＬ）は後述するＳＡＭＬ連携におけるリダイレクト先のＵＲＬである。管理者は外部サービス１０３１の管理者ページを表示し、外部サービス１０３１のシングルサインオン設定を行う。管理者は図９に表示されたサービスプロバイダ側に設定する情報を参考にして、外部サービス１０３１の管理者ページに外部サービス１０３１のシングルサインオン設定を行う。

このように、外部サービス１０３１の管理者ページに外部サービス１０３１のシングルサインオン設定を行うことで、管理者はサービス提供システム１１００と外部サービス１０３１との間で信頼関係を結んでおくことができる。

前述したようなサービス提供システム１１００及び外部サービス１０３１のシングルサインオン設定を行うことにより、ポータルサービスアプリ１１１は図５に示す組織情報のトラストサークルに、サービスプロバイダの一例としての外部サービス１０３１を追加できる。

《画面遷移》
図１のオフィス機器に搭載されたブラウザは、例えばアクセス先として外部サービス１０３１のＵＲＬを入力又はブックマークから選択されることにより、図１０に示すような遷移により外部サービス１０３１にアクセスできる。なお、ここではシングルサインオン設定済みの外部サービス１０３１にアクセスする例を表している。

図１０は画面遷移の一例を表した説明図である。図１０に示すように、図１のオフィス機器に搭載されたブラウザは、例えばアクセス先として外部サービス１０３１のＵＲＬを入力又はブックマークから選択されると、ポータルサービスアプリ１１１１のログイン画面２０００にリダイレクトされる。

ポータルサービスアプリ１１１１のログイン画面２０００においてログインに成功することにより、図１のオフィス機器に搭載されたブラウザは外部サービス１０３１のページ２０１０にリダイレクトされる。

また、図１のオフィス機器に搭載されたブラウザは、例えばアクセス先としてポータルサービスアプリ１１１１のＵＲＬを入力又はブックマークから選択されることにより、図１１に示すような遷移により外部サービス１０３１にアクセスできる。なお、ここではシングルサインオン設定済みの外部サービス１０３１にアクセスする例を表している。

図１１は画面遷移の他の例を表した説明図である。図１のオフィス機器に搭載されたブラウザは、例えばアクセス先としてポータルサービスアプリ１１１１のＵＲＬを入力又はブックマークから選択されると、ポータルサービスアプリ１１１１のログイン画面２０２０にリダイレクトされる。

ポータルサービスアプリ１１１１のログイン画面２０２０においてログインに成功することにより、図１のオフィス機器に搭載されたブラウザはアプリランチャ画面２０３０を表示する。ユーザはアプリランチャ画面２０３０から外部サービス１０３１のアイコン２０３１を例えばクリックする。

ログイン画面２０２０においてログイン済みであるため、図１のオフィス機器に搭載されたブラウザは、ログイン画面２０２０にリダイレクトされることなく、外部サービス１０３１のページ２０４０にリダイレクトされる。

このように、外部サービス１０３１にアクセスするときの画面遷移はポータルサービスアプリ１１１１へのログイン済みであるか否かによって異なる。次に、図１０又は図１１に示した画面遷移が行われるときの情報処理システム１０００における処理手順について説明する。

《図１０の画面遷移に対応する処理手順》
図１２はブラウザからシングルサインオン設定済みの外部サービスにアクセスする処理手順を表した一例のシーケンス図である。

ステップＳ１０において、図１のオフィス機器に搭載されたブラウザ１０１４はユーザから例えばアクセス先として外部サービス１０３１のＵＲＬを入力又はブックマークから選択されると、外部サービス１０３１にアクセスする。

ステップＳ１１、Ｓ１２において、ブラウザ１０１４はシングルサインオン設定によりログインのためのＵＲＬとして設定されたＵＲＬ（サインインページＵＲＬ）にリダイレクトされる。リダイレクトにより、ブラウザ１０１４は認証・認可部１１２１にＳＡＭＬ連携を要求する。なお、ＳＡＭＬ連携にはＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅが含まれる。ＲｅｌａｙＳｔａｔｅはＳＡＭＬ標準仕様であり、ＳＡＭＬレスポンスを送信する先の外部サービスの情報（状態）を表す。ステップＳ１２の処理後、認証・認可部１１２１は図１３に示すような処理を行う。

図１３は認証・認可部の処理手順を表した一例のフローチャートである。ステップＳ５１において、認証・認可部１１２１はステップＳ１２のＳＡＭＬ連携に認証チケットがあるか無いかを確認する。ステップＳ５２において、認証・認可部１１２１は認証チケットがあると判定すると、ステップＳ５３に進み、ＳＡＭＬレスポンスを生成する。ステップＳ５２において、認証・認可部１１２１は認証チケットが無いと判定すると、ステップＳ５４に進み、ブラウザ１０１４をポータルサービスアプリ１１１１のログイン画面にリダイレクトさせる。

なお、ステップＳ５４においてリダイレクトさせるポータルサービスアプリ１１１１のログイン画面のＵＲＬは、例えば認証・認可部１１２１が保持している。ここではポータルサービスアプリ１１１１のログイン画面にリダイレクトされた例について説明する。

図１２のステップＳ１３、Ｓ１４において、ブラウザ１０１４はポータルサービスアプリ１１１１のログイン画面にリダイレクトされる。リダイレクトにより、ブラウザ１０１４はポータルサービスアプリ１１１１にログイン画面を要求する。なお、ログイン画面の要求には組織ＩＤ、ＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅが含まれる。

ステップＳ１５において、ポータルサービスアプリ１１１１はＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅをｈｉｄｄｅｎタイプのｉｎｐｕｔタグでＨＴＭＬに埋め込んだログイン画面をブラウザ１０１４に送信する。ブラウザ１０１４は図１０に示したようなログイン画面２０００を表示する。

ユーザはログイン画面２０００に組織ＩＤ、ユーザ名、パスワードを入力してログインボタン２００１を押下する。なお、組織ＩＤはログイン画面の要求に含まれるものを利用すればユーザによる入力を省略できる。ログインボタン２００１が押下されると、ブラウザ１０１４はステップＳ１６に進み、ポータルサービスアプリ１１１１にログインを要求する。なお、ログインの要求には組織ＩＤ、ユーザ名、パスワード、ＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅが含まれる。

ステップＳ１７において、ポータルサービスアプリ１１１１は認証・認可部１１２１にブラウザ１０１４からのログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードによるログインを要求する。認証・認可部１１２１はポータルサービスアプリ１１１１からのログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードの組みが、図６に示すようなユーザ情報としてユーザ情報記憶部１１４３に記憶されているか確認する。

ログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードの組みが、ユーザ情報記憶部１１４３に記憶されていれば、ステップＳ１８において、認証・認可部１１２１はポータルサービスアプリ１１１１に認証チケットを返す。ポータルサービスアプリ１１１１はステップＳ１８の処理後、図１４に示すような処理を行う。

図１４はポータルサービスアプリの処理手順を表した一例のフローチャートである。ステップＳ６１において、ポータルサービスアプリ１１１１はステップＳ１６のログインの要求にＳＡＭＬリクエストがあるか無いかを確認する。ステップＳ６２において、ポータルサービスアプリ１１１１はＳＡＭＬリクエストがあると判定すると、ステップＳ６３に進み、ブラウザ１０１４をサインインページＵＲＬ（ＳＡＭＬ連携ＵＲＬ）にリダイレクトさせる。ステップＳ６２において、ポータルサービスアプリ１１１１はＳＡＭＬリクエストが無いと判定すると、ステップＳ６４に進み、ポータル画面を生成する。

ここではブラウザ１０１４がサインインページＵＲＬ（ＳＡＭＬ連携ＵＲＬ）にリダイレクトされた例について説明する。図１２のステップＳ１９、Ｓ２０において、ブラウザ１０１４はＳＡＭＬ連携ＵＲＬにリダイレクトされる。リダイレクトにより、ブラウザ１０１４は認証・認可部１１２１にＳＡＭＬ連携を要求する。なお、ＳＡＭＬ連携にはＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅの他、認証チケットが含まれる。

ステップＳ２０の処理後、認証・認可部１１２１は前述した図１３に示すような処理を行う。認証チケットがあるため、認証・認可部１１２１はステップＳ５３においてＳＡＭＬレスポンスを生成する。なお、認証・認可部１１２１は、同一の組織に紐付くトラストサークルに入っている外部サービス１０３１からのＳＡＭＬリクエストに対して、ＳＡＭＬレスポンスを生成するものとする。

ここでは認証・認可部１１２１においてＳＡＭＬレスポンスが生成された例について説明する。図１２のステップＳ２１において、認証・認可部１１２１はＳＡＭＬレスポンスを生成する。ステップＳ２２、Ｓ２３において、認証・認可部１１２１はＳＡＭＬレスポンスをＰＯＳＴする外部サービスの宛先を指定してブラウザ１０１４に自動ＰＯＳＴさせる。ステップＳ２４において、外部サービス１０３１はＳＡＭＬレスポンスを確認し、対応するユーザのサービス画面をブラウザ１０１４に表示させる。

図１２のシーケンス図に表した処理によれば、同一の組織に紐付くトラストサークルに入っている外部サービス１０３１からのＳＡＭＬリクエストに対して、ＳＡＭＬレスポンスを生成できる。したがって、第１の実施形態に係る情報処理システム１０００では組織毎にトラストサークルを設定できるので、複数の組織に対応したＳＡＭＬベースのシングルサインオンを実現できる。結果として、第１の実施形態に係る情報処理システム１０００は認証における信頼関係の設定自由度を向上させることができる。

また、図１２のシーケンス図に表した処理によれば、ポータルサービスアプリ１１１１のログイン画面に未ログインの場合、ＳＡＭＬ連携の要求の対し、ブラウザ１０１４にログイン画面を表示させることができる。

また、図１２のシーケンス図に表した処理によれば、ブラウザ１０１４からのログインの要求に対し、ＳＡＭＬリクエストか通常のログインの要求かを判断し、ＳＡＭＬリクエストであればＳＡＭＬレスポンスを返すことができる。

《図１１の画面遷移に対応する処理手順》
図１５はブラウザからシングルサインオン設定済みの外部サービスにアクセスする処理手順を表した他の例のシーケンス図である。

ステップＳ８１において、図１のオフィス機器に搭載されたブラウザはユーザから例えばアクセス先としてポータルサービスアプリ１１１１のＵＲＬを入力又はブックマークから選択されると、ポータルサービスアプリ１１１１にアクセスする。

ステップＳ８２において、ポータルサービスアプリ１１１１はログイン画面をブラウザ１０１４に送信する。ブラウザ１０１４は図１１に示したようなログイン画面２０２０を表示する。なお、図１１に示したログイン画面２０２０のＵＲＬと、図１０に示したログイン画面２０００のＵＲＬとは、異なっている。

ユーザはログイン画面２０２０に組織ＩＤ、ユーザ名、パスワードを入力してログインボタン２０２１を押下する。組織ＩＤは予め設定しておいたものを利用すれば、ユーザによる入力を省略できる。ログインボタン２０２１が押下されると、ブラウザ１０１４はステップＳ８３に進み、ポータルサービスアプリ１１１１にログインを要求する。ログインの要求には組織ＩＤ、ユーザ名、パスワードが含まれる。

ステップＳ８４において、ポータルサービスアプリ１１１１は認証・認可部１１２１にブラウザ１０１４からのログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードによるログインを要求する。認証・認可部１１２１はポータルサービスアプリ１１１１からのログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードの組みが、図６に示すようなユーザ情報としてユーザ情報記憶部１１４３に記憶されているか確認する。

ログインの要求に含まれていた組織ＩＤ、ユーザ名、パスワードの組みが、ユーザ情報記憶部１１４３に記憶されていれば、ステップＳ８５において、認証・認可部１１２１はポータルサービスアプリ１１１１に認証チケットを返す。

ポータルサービスアプリ１１１１はステップＳ８５の処理後、前述した図１４に示すような処理を行う。ＳＡＭＬリクエストが無いため、ポータルサービスアプリ１１１１はステップＳ６４においてポータル画面を生成する。

ステップＳ８６において、ポータルサービスアプリ１１１１はポータル画面をブラウザ１０１４に送信する。ブラウザ１０１４は図１１に示したようなアプリランチャ画面２０３０を含むポータル画面を表示する。

ユーザはポータル画面のアプリランチャ画面２０３０から外部サービス１０３１のアイコン２０３１を例えばクリックする。ステップＳ９１において、ブラウザ１０１４は外部サービス１０３１にアクセスする。

ステップＳ９２、Ｓ９３において、ブラウザ１０１４はシングルサインオン設定によりログインのためのＵＲＬとして設定されたＵＲＬ（サインインページＵＲＬ）にリダイレクトされる。リダイレクトにより、ブラウザ１０１４は認証・認可部１１２１にＳＡＭＬ連携を要求する。なお、ＳＡＭＬ連携にはＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅの他、認証チケットが含まれる。

ステップＳ９３の処理後、認証・認可部１１２１は前述した図１３に示すような処理を行う。認証チケットがあるため、認証・認可部１１２１はステップＳ５３においてＳＡＭＬレスポンスを生成する。なお、認証・認可部１１２１は、同一の組織に紐付くトラストサークルに入っている外部サービス１０３１からのＳＡＭＬリクエストに対して、ＳＡＭＬレスポンスを生成するものとする。

ステップＳ９５、Ｓ９６において、認証・認可部１１２１はステップＳ９４で生成したＳＡＭＬレスポンスをＰＯＳＴする外部サービスの宛先を指定してブラウザ１０１４に自動ＰＯＳＴさせる。ステップＳ９７において、外部サービス１０３１はＳＡＭＬレスポンスを確認し、対応するユーザのサービス画面をブラウザ１０１４に表示させる。

図１５のシーケンス図に表した処理によれば、ポータルサービスアプリ１１１１のログイン画面にログイン済みの場合、ＳＡＭＬ連携の要求の対し、ブラウザ１０１４にログイン画面を表示させずにＳＡＭＬレスポンスを返すことができる。

また、図１５のシーケンス図に表した処理によれば、ブラウザ１０１４からのログインの要求に対し、ＳＡＭＬリクエストか通常のログインの要求かを判断し、通常のログインの要求であればポータル画面を返すことができる。

《エラー発生時の処理手順》
図１６はエラー発生時の処理手順を表した一例のシーケンス図である。図１６は、図１２のステップＳ２１においてエラーが発生したとき、又は、図１５のステップＳ９４においてエラーが発生したとき、にエラーが発生したときの処理手順を表している。

ステップＳ１０１において、ブラウザ１０１４はＳＡＭＬ連携ＵＲＬにリダイレクトされる。リダイレクトによりブラウザ１０１４は認証・認可部１１２１にＳＡＭＬ連携を要求する。なお、ＳＡＭＬ連携にはＳＡＭＬリクエスト及びＲｅｌａｙＳｔａｔｅの他、認証チケットが含まれる。

ステップＳ１０２において、認証・認可部１１２１はＳＡＭＬレスポンスを生成する際にエラーが発生したものとする。例えばエラーは処理できないＳＡＭＬリクエストを受信した場合などに発生する。

ステップＳ１０３、Ｓ１０４において、ブラウザ１０１４はポータルサービスアプリ１１１１のエラー画面にリダイレクトされる。リダイレクトにより、ブラウザ１０１４はエラー画面をポータルサービスアプリ１１１１に要求する。なお、エラー画面の要求にはエラー情報が含まれる。

ステップＳ１０５において、ポータルサービスアプリ１１１１はエラー画面をブラウザ１０１４に送信する。ブラウザ１０１４はエラー画面を表示する。エラー画面は専用の画面であってもよいし、図１７に示すようにログイン画面にエラー情報を合わせて表示するようにしてもよい。

《ポータル画面のアプリランチャ画面２０３０》
シングルサインオンに対応した外部サービス１０３１の中には、非シングルサインオンでアクセスするＵＲＬと、シングルサインオンでアクセスするＵＲＬ（組織ＩＤごとに異なる）とを提供している場合がある。このような非シングルサインオンでアクセスするＵＲＬ及びシングルサインオンでアクセスするＵＲＬを別々に提供する外部サービス１０３１のアプリランチャ画面２０３０の生成は、以下のように行う。

例えば図１１のアプリランチャ画面２０３０では外部サービス１０３１にアクセスするためのリンクをアイコン２０３１で表している。このような外部サービス１０３１にアクセスするためのリンクを含むアプリランチャ画面２０３０を生成するときは、外部サービス１０３１のシングルサインオン設定の有無を確認し、リンクのＵＲＬを変える。

図５の組織情報を参照し、ポータルサービスアプリ１１１１はリンクの対象となる外部サービス１０３１を含むトラストサークルが存在するか確認する。存在する場合、ポータルサービスアプリ１１１１は図５の組織情報のサービスプロバイダに含まれるサービスプロバイダＵＲＬを用いる。なお、存在しない場合、ポータルサービスアプリ１１１１は外部サービス１０３１が提供する非シングルサインオンでアクセスするＵＲＬ（固定）を用いる。

このように、ポータルサービスアプリ１１１１はシングルサインオン設定済みである場合に、ポータル画面のアプリランチャ画面２０３０に含まれるリンクを、トラストサークルに入っている外部サービス１０３１のＵＲＬに切り替えることができる。

図１１のアプリランチャ画面２０３０を生成するとき、組織情報記憶部１１４２に記憶されている複雑なデータ構造を辿ってサービスプロバイダＵＲＬを取得する為には時間を要する。そこで、外部サービス１０３１のサービスプロバイダＵＲＬを高速な記憶装置にキャッシュすることで、第１の実施形態に係るサービス提供システム１１００はページの表示までの時間を短縮する。なお、高速な記憶装置としては、Ｋｅｙ−Ｖａｌｕｅストアやｍｅｍｃａｃｈｅ等がある。

図１８はサービスプロバイダＵＲＬを高速な記憶装置にキャッシュする処理の一例のフローチャートである。図１８は、図８の画面にシングルサインオンを利用するサービスプロバイダのＩＤが入力されたあとの処理を表している。

ステップＳ１５１において、組織管理部１１２２は組織情報記憶部１１４２に記憶されている組織情報（データベース）からサービスプロバイダの情報を取得する。ステップＳ１５２において、組織管理部１１２２は高速な記憶装置にキャッシュされているサービスプロバイダの情報を更新する。

ステップＳ１５３において、組織管理部１１２２は管理者により入力されたサービスプロバイダのＩＤと、現在設定されているサービスプロバイダのＩＤとが等しいか否かを判定する。等しければ、組織管理部１１２２は図１８の処理を終了する。なお、等しくなければ、組織管理部１１２２はステップＳ１５４において、組織に紐付くトラストサークルを削除する。ステップＳ１５５において、組織管理部１１２２は入力値が空であるか否かを判定する。

入力値が空であれば、組織管理部１１２２は図１８の処理を終了する。なお、入力値が空でなければ、組織管理部１１２２はステップＳ１５６において、図５に示す組織情報のトラストサークルを作成する。ステップＳ１５７において、組織管理部１１２２はサービスプロバイダの情報を更新する。

図１８のフローチャートに表した処理によれば、サービスプロバイダの情報を高速な記憶装置にキャッシュすることで、ページの表示までの時間を短縮できる。また、サービスプロバイダの情報が設定済みである場合は設定処理を省略できる。

《ＡＰＩ連携》
外部サービス１０３１は、ＳＡＭＬ連携による認証に基づいて利用可能なＡＰＩを提供している場合も考えられる。この場合は、ジョブ実行時にＳＡＭＬリクエスト／ＳＡＭＬレスポンスを生成して、図５の組織情報に含まれるサービスプロバイダのＡＣＳのＵＲＬにＰＯＳＴすることにより、外部サービス１０３１にログインし、その結果を用いてＡＰＩを実行できる。

図１９はＡＰＩ連携時の処理手順を表した一例のシーケンス図である。図１９は、画像形成装置１０１３がスキャンしたファイルをサービス提供システム１１００が外部サービス１０３１に登録する処理を一例として表している。ユーザは画像形成装置１０１３を操作してサービス提供システム１１００へのログインを要求する。

ステップＳ２０１において、画像形成装置１０１３はサービス提供システム１１００の認証・認可部１１２１にログインする。ログインは組織ＩＤ、ユーザＩＤ及びパスワードが利用される。ログインが成功すると、ステップＳ２０２において、認証・認可部１１２１は認証チケットを画像形成装置１０１３に返す。

ステップＳ２０３において、ユーザはスキャンしたファイルを外部サービス１０３１に登録するジョブの実行を、画像形成装置１０１３に要求する。画像形成装置１０１３はステップＳ２０３において、スキャンを実行する。ステップＳ２０４において、画像形成装置１０１３は認証チケットを添付して、スキャンサービスアプリ１１１２に、スキャンしたファイルのアップロードを行う。

ステップＳ２０５において、スキャンサービスアプリ１１１２は認証チケットを添付して外部サービス１０３１へのログインを認証・認可部１１２１に要求する。外部サービス１０３１の指定は例えばサービスプロバイダ名により行う。

認証・認可部１１２１は、ステップＳ２０６においてＳＡＭＬリクエストを生成し、ステップＳ２０７においてＳＡＭＬレスポンスを生成する。ステップＳ２０８において、認証・認可部１１２１はＡＣＳにＳＡＭＬレスポンスをＰＯＳＴする。外部サービス１０３１はステップＳ２０９において外部サービス１０３１の認証チケットを返す。

ステップＳ２１０において、認証・認可部１１２１はスキャンサービスアプリ１１１２に外部サービス１０３１の認証チケットを返す。そして、スキャンサービスアプリ１１１２はステップＳ２１１において、外部サービス１０３１の認証チケットを添付して、外部サービス１０３１に、ファイルの登録を行う。ステップＳ２１２において、外部サービス１０３１はファイルの登録結果をスキャンサービスアプリ１１１２に返す。ステップＳ２１３において、画像形成装置１０１３はスキャンサービスアプリ１１１２からファイルの登録結果を受け取る。

（まとめ）
第１の実施形態に係るサービス提供システム１１００によれば組織毎にトラストサークルを設定できるので、複数の組織に対応したＳＡＭＬベースのシングルサインオンを実現できる。したがって、第１の実施形態に係る情報処理システム１０００は認証における信頼関係の設定自由度を向上させることができる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

なお、特許請求の範囲に記載した受信手段はポータルサービスアプリ１１１１に相当する。認証手段は認証・認可部１１２１に相当する。外部装置はブラウザ１０１４が搭載されるオフィス機器に相当する。第１の記憶手段はユーザ情報記憶部１１４３に相当する。第２の記憶手段は組織情報記憶部１１４２に相当する。

連携認証要求（応答）はＳＡＭＬリクエスト（レスポンス）に相当する。認証済みであることを示す認証の情報は認証チケットに相当する。アクセス可能な前記外部サービスの情報を含む画面はポータル画面に相当する。ユーザ識別情報はユーザ名に相当する。組織識別情報は組織ＩＤに相当する。内部サービスはアプリケーション１１０１に相当する。

１０００ 情報処理システム
１０１１ クライアント端末
１０１２ 携帯端末
１０１３ 画像形成装置
１０１４ ブラウザ
１０２１ アクセス制御装置
１０２２ プリントサービス提供装置
１０２３ スキャンサービス提供装置
１０２４ 他サービス提供装置
１０３１ 外部サービス
１０５１ ポータルサービス提供装置
１０５２ プリントサービス提供装置
１０５３ スキャンサービス提供装置
１０６１ 認証サービス提供装置
１０６２ データ処理サービス提供装置
１０６３ 一時データ保存サービス提供装置
１０７１ 認証情報記憶装置
１０７２ ジョブ情報記憶装置
１０７３ 一時データ記憶装置
１１００ サービス提供システム
１１０１ アプリケーション
１１０２ 共通サービス
１１０３ データベース
１１０４ プラットフォームＡＰＩ（Application Programming Interface）
１１１１ ポータルサービスアプリ
１１１２ スキャンサービスアプリ
１１１３ プリントサービスアプリ
１１２１ 認証・認可部
１１２２ 組織管理部
１１２３ ユーザ管理部
１１２４ ライセンス管理部
１１２５ 機器管理部
１１２６ 一時画像保存部
１１２７ 画像処理ワークフロー制御部
１１２８ ログ収集部
１１３１ メッセージキュー
１１３２ ワーカー
１１４１ ログ情報記憶部
１１４２ 組織情報記憶部
１１４３ ユーザ情報記憶部
１１４４ ライセンス情報記憶部
１１４５ 機器情報記憶部
１１４６ 一時画像記憶部
１１４７ ジョブ情報記憶部
１１４８ アプリケーション固有の設定情報記憶部
１５００ コンピュータシステム
１５０１ 入力装置
１５０２ 表示装置
１５０３ 外部Ｉ／Ｆ
１５０３ａ 記録媒体
１５０４ ＲＡＭ
１５０５ ＲＯＭ
１５０６ ＣＰＵ
１５０７ 通信Ｉ／Ｆ
１５０８ ＨＤＤ
Ｂ バス
ＦＷ ファイヤウォール
Ｎ１〜Ｎ３ ネットワーク

特開２０１２−２２６７００号公報 特開２００６−３１７１４号公報

Claims (11)

1. １以上の情報処理装置を含む情報処理システムであって、
   外部装置からユーザ識別情報、組織識別情報を受信する受信手段と、
   組織識別情報に関連付けて１以上のユーザ識別情報を記憶する第１の記憶手段を用いて前記受信手段が受信した前記ユーザ識別情報、組織識別情報に対する認証を実行する認証手段と、を備え、
   前記認証手段は、認証済みの前記外部装置から外部サービスとの連携認証要求を受信すると、認証に関しての信頼関係を結んだ１以上の外部サービスを前記組織識別情報と関連付けて記憶する第２の記憶手段に、前記外部装置から受信した前記組織識別情報と前記連携認証要求の対象となる外部サービスとが関連付けられていれば、前記外部装置に連携認証応答を送信する
   ことを特徴とする情報処理システム。
2. 前記認証手段は、認証済みでない前記外部装置から前記連携認証要求を受信すると、前記連携認証要求の情報を添付した上で、前記受信手段に、前記外部装置からユーザ識別情報、組織識別情報を受信するように要求すること
   を特徴とする請求項１記載の情報処理システム。
3. 前記受信手段は、前記外部装置から受信した前記ユーザ識別情報、前記組織識別情報に前記連携認証要求の情報が添付されていれば、前記認証手段により認証済みであることを示す認証の情報を前記外部装置に送信し、
   前記認証手段は、前記認証の情報が添付された前記連携認証要求を前記外部装置から受信したときに、認証済みの前記外部装置から外部サービスとの連携認証要求を受信したと判定すること
   を特徴とする請求項２記載の情報処理システム。
4. 前記受信手段は、前記外部装置から受信した前記ユーザ識別情報、前記組織識別情報に前記連携認証要求の情報が添付されていなければ、アクセス可能な前記外部サービスの情報を含む画面を、前記外部装置に表示させること
   を特徴とする請求項２又は３記載の情報処理システム。
5. 前記認証手段は、前記連携認証応答の生成にエラーが発生したとき、エラー情報を含む画面を、前記外部装置に表示させるように前記受信手段に要求すること
   を特徴とする請求項１乃至４何れか一項記載の情報処理システム。
6. 前記受信手段は、前記外部サービスが前記認証に関しての信頼関係を結んだ前記外部装置からのアクセス先と前記外部サービスが前記認証に関しての信頼関係を結んでいない前記外部装置からのアクセス先とを分けて提供している場合に、前記アクセス可能な前記外部サービスの情報を含む画面の前記外部サービスのアクセス先を、前記第２の記憶手段に基づいて切り替えること
   を特徴とする請求項４記載の情報処理システム。
7. 前記アクセス可能な前記外部サービスの情報を記憶する、前記第２の記憶手段よりも高速な読み出しが可能な第３の記憶手段を更に有し、
   前記受信手段は、前記第３の記憶手段から読み出した前記外部サービスの情報に基づいて前記アクセス可能な前記外部サービスの情報を含む画面を生成すること
   を特徴とする請求項４記載の情報処理システム。
8. 前記認証手段は、認証済みの前記外部装置から処理の要求を受けた内部サービスから前記外部サービスへのログイン要求を受信すると、前記第２の記憶手段に、前記外部装置から受信した前記組織識別情報と前記ログイン要求の対象となる外部サービスとが関連付けられていれば、前記外部サービスに連携認証応答を送信して取得した前記外部サービスの認証の情報を前記内部サービスに提供し、前記内部サービスに前記外部サービスを利用する前記処理の要求に基づく処理を実行させること
   を特徴とする請求項１記載の情報処理システム。
9. 外部装置からユーザ識別情報、組織識別情報を受信する受信手段と、
   組織識別情報に関連付けて１以上のユーザ識別情報を記憶する第１の記憶手段を用いて前記受信手段が受信した前記ユーザ識別情報、組織識別情報に対する認証を実行する認証手段と、を備え、
   前記認証手段は、認証済みの前記外部装置から外部サービスとの連携認証要求を受信すると、認証に関しての信頼関係を結んだ１以上の外部サービスを前記組織識別情報と関連付けて記憶する第２の記憶手段に、前記外部装置から受信した前記組織識別情報と前記連携認証要求の対象となる外部サービスとが関連付けられていれば、前記外部装置に連携認証応答を送信する
   ことを特徴とする情報処理装置。
10. コンピュータを、請求項９記載の情報処理装置として機能させるためのプログラム。
11. １以上の情報処理装置を含む情報処理システムが実行する認証方法であって、
    外部装置からユーザ識別情報、組織識別情報を受信するステップと、
    組織識別情報に関連付けて１以上のユーザ識別情報を記憶する第１の記憶手段を用いて、前記受信した前記ユーザ識別情報、組織識別情報に対する認証を実行するステップと、
    認証済みの前記外部装置から外部サービスとの連携認証要求を受信するステップと、
    認証に関しての信頼関係を結んだ１以上の外部サービスを前記組織識別情報と関連付けて記憶する第２の記憶手段に、前記外部装置から受信した前記組織識別情報と前記連携認証要求の対象となる外部サービスとが関連付けられていれば、前記外部装置に連携認証応答を送信するステップと
    を有することを特徴とする認証方法。

Images