(57)【特許請求の範囲】
【請求項１】
情報処理装置であって、
複数種類の認証方法を用いてユーザ認証のための処理を実行することが可能な認証手段と、
前記認証手段がユーザを認証することによって生成されるクレデンシャルを管理する管理手段と、
前記管理手段が管理するクレデンシャルを前記情報処理装置が有する機能の実行のために利用することを許可するか否かを、前記認証手段が有する前記複数種類の認証方法のうち少なくとも一つの認証方法に対して設定する設定手段と、
前記認証手段が特定の認証方法を用いてユーザを認証し、当該ユーザが前記情報処理装置が有する機能の実行を指示した場合、前記設定手段が設定した設定内容に従って、当該機能が前記クレデンシャルを利用するか否かを決定する決定手段と、
前記決定手段が前記クレデンシャルを利用することを許可すると決定した場合、前記クレデンシャルを用いて前記機能を実行するよう制御し、前記決定手段が前記クレデンシャルを利用することを許可しないと決定した場合、前記ユーザにユーザ認証を促すよう制御する制御手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記特定の認証方法は、セキュリティドメインを限定できない認証方法であることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記セキュリティドメインを限定できない認証方法はローカル認証であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記セキュリティドメインを限定できない認証方法はＬＤＡＰ認証であることを特徴とする請求項２に記載の情報処理装置。
【請求項５】
前記認証手段が前記特定の認証方法を用いてユーザを認証したことに基づいて生成されるクレデンシャルは、ドメイン情報を含まないことを特徴とする請求項１に記載の情報処理装置。
【請求項６】
前記認証手段が前記特定の認証方法を用いてユーザを認証したことに基づいて生成されるクレデンシャルは、プレーンテキストの情報であることを特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記機能はデータを外部のサーバへ送信する送信機能であり、
前記送信機能は、前記外部のサーバにアクセスするために必要なユーザ認証を、前記クレデンシャル、あるいは前記ユーザが入力した認証情報を用いて要求することを特徴とする請求項１に記載の情報処理装置。
【請求項８】
前記管理手段は、生成されたクレデンシャルを記憶手段に記憶し、前記ユーザが認証状態を解除されたら前記記憶手段に記憶された前記クレデンシャルを破棄することを特徴とする請求項１に記載の情報処理装置。
【請求項９】
前記決定手段が前記クレデンシャルを利用することを許可しないと決定した場合、前記制御手段は、操作画面にユーザ認証のために必要な情報を入力するための画面を表示するよう制御することを特徴とする請求項１に記載の情報処理装置。
【請求項１０】
情報処理装置の制御方法であって、
前記情報処理装置が実行可能な複数種類の認証方法のうち何れかを用いてユーザ認証のための処理を実行することが可能な認証工程と、
前記認証工程でユーザを認証することによって生成されるクレデンシャルを管理する管理工程と、
前記管理工程で管理するクレデンシャルを前記情報処理装置が有する機能の実行のために利用することを許可するか否かを、前記認証工程で実行可能な前記複数種類の認証方法のうち少なくとも一つの認証方法に対して設定する設定工程と、
前記認証工程で特定の認証方法を用いてユーザを認証し、当該ユーザが前記情報処理装置が有する機能の実行を指示した場合、前記設定工程で設定した設定内容に従って、当該機能が前記クレデンシャルを利用するか否かを決定する決定工程と、
前記決定工程で前記クレデンシャルを利用することを許可すると決定した場合、前記クレデンシャルを用いて前記機能を実行するよう制御し、前記決定工程で前記クレデンシャルを利用することを許可しないと決定した場合、前記ユーザにユーザ認証を促すよう制御する制御工程と
を有することを特徴とする情報処理装置の制御方法。
【請求項１１】
コンピュータに、
前記コンピュータが実行可能な複数種類の認証方法のうち何れかを用いてユーザ認証のための処理を実行する認証手順と、
前記認証手順においてユーザを認証することによって生成されるクレデンシャルを管理する管理手順と、
前記管理手順において管理するクレデンシャルを前記コンピュータが有する機能の実行のために利用することを許可するか否かを、前記認証手順において実行可能な前記複数種類の認証方法のうち少なくとも一つの認証方法に対して設定する設定手順と、
前記認証手順において特定の認証方法を用いてユーザを認証し、当該ユーザが前記コンピュータが有する機能の実行を指示した場合、前記設定手順において設定した設定内容に従って、当該機能が前記クレデンシャルを利用するか否かを決定する決定手順と、
前記決定手順において前記クレデンシャルを利用することを許可すると決定した場合、前記クレデンシャルを用いて前記機能を実行するよう制御し、前記決定手順において前記クレデンシャルを利用することを許可しないと決定した場合、前記ユーザにユーザ認証を促すよう制御する制御手順とを実行させるためのプログラム。
【請求項１２】
シングルサインオン機能を有する画像処理装置であって、
前記画像処理装置にログインするユーザを認証する認証手段と、
前記認証手段によるユーザ認証の際に使用された認証情報を含むユーザクレデンシャルと、該ユーザクレデンシャルに関連する認証プロトコルを示す情報とを関連付けて保存する保存手段と、
原稿から画像を読み取る読取手段と、
前記画像処理装置に通信可能に接続された外部装置へ前記読取手段によって読み取った原稿の画像データを送信する指示をユーザから受け付けると、前記保存手段に保存されている当該ユーザの前記ユーザクレデンシャルと前記認証プロトコルを示す情報とに基づき、該ユーザクレデンシャルを用いて該外部装置へアクセス可能か否かを判定する判定手段と、
前記判定手段によって前記ユーザクレデンシャルを用いて前記外部装置へのアクセスが可能でないと判定されると、該外部装置へアクセス可能なアカウントの入力を促し、前記判定手段によって前記ユーザクレデンシャルを用いて前記外部装置へのアクセスが可能であると判定されると、該外部装置へ前記読取手段によって読み取った原稿の画像データを送信する制御手段と、
を備え、
前記判定手段は、前記認証プロトコルがセキュリティドメインを限定することが可能な認証プロトコルであれば前記ユーザクレデンシャルを用いて外部装置へのアクセスが可能であると判定し、前記認証プロトコルがセキュリティドメインを限定することが不可能な認証プロトコルであれば前記ユーザクレデンシャルを用いて外部装置へのアクセスが可能でないと判定することを特徴とする画像処理装置。
【請求項１３】
前記認証プロトコルの種別毎に前記ユーザクレデンシャルの共有を禁止するか否かを設定する設定手段をさらに備え、
前記判定手段は、前記認証プロトコルがセキュリティドメインを限定することが不可能な認証プロトコルである場合において、当該認証プロトコルにおける前記ユーザクレデンシャルの共有を禁止する設定が前記設定手段によって行われていれば前記ユーザクレデンシャルを用いて外部装置へのアクセスが可能でないと判定し、当該認証プロトコルにおける前記ユーザクレデンシャルの共有を禁止する設定が前記設定手段によって行われていなければ前記ユーザクレデンシャルを用いて外部装置へのアクセスが可能であると判定する
ことを特徴とする請求項１２に記載の画像処理装置。
【請求項１４】
前記認証手段は、認証するユーザから、アカウント、パスワード、及び認証先を示す情報を認証情報として受け付け、
前記保存手段は、前記認証先を示す情報に関連する認証プロトコルを、前記ユーザクレデンシャルに関連する認証プロトコルを示す情報として保存することを特徴とする請求項１２に記載の画像処理装置。
【請求項１５】
前記セキュリティドメインを限定することが可能な認証プロトコルは、特定のノードだけが解釈可能な暗号化された認証データを使用する認証プロトコル、デジタル署名を含む認証データを使用する認証プロトコル、及びドメインと関係する情報を含む認証データを使用する認証プロトコルのいずれかであることを特徴とする請求項１２に記載の画像処理装置。
【請求項１６】
前記セキュリティドメインを限定することが可能な認証プロトコルは、Ｋｅｒｂｅｒｏｓ認証であることを特徴とする請求項１２に記載の画像処理装置。
【請求項１７】
前記セキュリティドメインを限定することが不可能な認証プロトコルは、ローカルアカウントを使用する認証、及びＬＤＡＰのＳｉｍｐｌｅ Ｂｉｎｄのいずれかであることを特徴とする請求項１２に記載の画像処理装置。
【請求項１８】
前記ユーザクレデンシャルと関連する認証プロトコルが前記画像処理装置にとって未知の認証プロトコルである場合には、前記セキュリティドメインを限定することが不可能な認証プロトコルとして扱うことを特徴とする請求項１２に記載の画像処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、その制御方法、プログラム、及び画像処理装置に関するものである。
【背景技術】
【０００２】
現行の複写機やＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）などの画像処理装置には、デバイスにログインした時のアカウントを用いて外部サーバにアクセスすることができる。このようなシングルサインオンを実現するために、特許文献１では、アプリケーション間でユーザクレデンシャルを共有可能な仕組みを提供する。例えば、ユーザがデバイスにログインする際に取得したユーザクレデンシャルをキャッシュして共有することにより、外部サーバアクセス時にユーザに対して再びアカウントやパスワードの入力を求めないようにしている。これにより、ユーザは何度も同じアカウント、パスワードの入力を行う必要がない。
【０００３】
また、特許文献２には、シングルサインオンを実現するために、ローカルコンピュータにログインした時のデータを用いて、独立ネットワークのリソースにアクセスを試みるようにしたネットワークプロバイダを提案している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−２５８０００号公報
【特許文献２】特開平８−２６３４１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来技術には以下に記載する問題がある。例えば、企業におけるオフィス環境には、デバイスにログインした時のアカウントを用いて外部サーバにアクセスするシングルサインオン機能を利用するのに適した環境と適さない環境、或いはその混在環境が存在する。シングルサインオン機能の利用に適さない環境において、シングルサインオン機能を有効にした場合には企業内におけるセキュリティが低下するという問題がある。また、上記従来技術のシステムでは、シングルサインオン機能の利用に適した環境と適さない環境の混在環境が考慮されておらず、企業におけるオフィス環境を考慮したきめ細かいシングルサインオン機能の利用設定ができないという問題がある。ここで、シングルサインオン機能の利用に適した環境とは、企業内のＩＴ管理者が、コンピュータやデバイスのアクセスアカウントを一元管理している環境を示す。このような環境では、オフィスのスタッフは同じアカウントを用いてネットワーク上のどのノードに対してもアクセス可能である。また、シングルサインオン機能の利用に適さない環境とは、企業内のＩＴ管理者がノードのアクセスアカウントを一元管理していない環境を示す。また、シングルサインオン機能の利用に適した環境と適さない環境の混在環境とは、ＩＴ管理者がアクセスアカウントを一元管理しているノードやネットワークと、一元管理していないノードやネットワークが混在する環境を示す。例えば、ノードへのアクセスアカウントとしてドメインアカウントとローカルアカウントの両方が利用可能になっている環境において、ＩＴ管理者がドメインアカウントは管理しているが、ローカルアカウントは管理していないケースなども混在環境に相当する。
【０００６】
また、セキュリティドメインを限定することが可能なユーザクレデンシャルを利用する認証プロトコルと、セキュリティドメインを限定することが不可能なユーザクレデンシャルを利用する認証プロトコルがある。シングルサインオン機能の利用に適さない環境において、セキュリティドメインを限定することが不可能な認証プロトコルを利用して、デバイスから他のノードにシングルサインオンを試みた場合には次のような問題が発生する。例えば、デバイスは、アクセス先のノードのアクセスアカウントが一元管理されているかどうか判断することなくアクセスし、アクセス先のノードにデバイスログイン時の認証データと同一の認証データが偶然存在した場合に不正にアクセスできてしまう。シングルサインオン機能の利用に適さない環境では、このような問題を解決するためにシングルサインオン機能を一律で利用禁止にするだけでよい。しかしながら、シングルサインオン機能の利用に適した環境と適さない環境の混在環境では、上述のような方法では上記問題を解決することができない。
【０００７】
本発明は、上述の問題に鑑みて行われたものであり、シングルサインオン機能の利用に適した環境と適さない環境の混在環境であっても、認証データの偶然の一致による不正アクセスを防止しつつ、シングルサインオン機能を好適に実現するユーザクレデンシャル共有の仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、情報処理装置であって、複数種類の認証方法を用いてユーザ認証のための処理を実行することが可能な認証手段と、前記認証手段がユーザを認証することによって生成されるクレデンシャルを管理する管理手段と、前記管理手段が管理するクレデンシャルを前記情報処理装置が有する機能の実行のために利用することを許可するか否かを、前記認証手段が有する前記複数の認証方法のうち少なくとも一つの認証方法に対して設定する設定手段と、前記認証手段が特定の認証方法を用いてユーザを認証し、当該ユーザが前記情報処理装置が有する機能の実行を指示した場合、前記設定手段が設定した設定内容に従って、当該機能が前記クレデンシャルを利用するか否かを決定する決定手段と、前記決定手段が前記クレデンシャルを利用することを許可すると決定した場合、前記クレデンシャルを用いて前記機能を実行するよう制御し、前記決定手段が前記クレデンシャルを利用することを許可しないと決定した場合、前記ユーザにユーザ認証を促すよう制御する制御手段とを有することを特徴とする情報処理装置。
【発明の効果】
【０００９】
本発明は、シングルサインオン機能の利用に適した環境と適さない環境の混在環境であっても、認証データの偶然の一致による不正アクセスを防止しつつ、シングルサインオン機能を好適に実現するユーザクレデンシャル共有の仕組みを提供できる。
【図面の簡単な説明】
【００１０】
【図１】ネットワーク上のノード構成とユーザリポジトリの配置を示す概略図。
【図２】ＭＦＰのハードウェア構成を示す図。
【図３】ＭＦＰのソフトウェア構成を示す図。
【図４】アプリケーションを管理する為のユーザインタフェースを示す図。
【図５】ログインアプリケーションが備えるユーザインタフェース（ログイン画面と認証サーバ登録画面）を示す図。
【図６】ユーザクレデンシャル共有サービスが備えるＡＰＩを示す図。
【図７】ユーザクレデンシャル共有サービスが保存するユーザクレデンシャルを示す図。
【図８】ユーザクレデンシャル共有サービスのユーザインタフェースを示す図。
【図９】送信アプリケーションのユーザインタフェースを示す図。
【図１０】ＭＦＰ操作時の一連のシーケンスを示す図。
【図１１】ユーザクレデンシャル共有サービスの詳細な処理フローを示す図。
【図１２】ユーザクレデンシャルと接続先のファイル共有サーバの組み合わせを表す図。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１２】
＜システム構成＞
以下では、図１乃至図１２を参照して、本発明の実施例について説明する。本実施例では、情報処理装置（画像処理装置）の一例としてＭＦＰを使用した例を示す。まず、図１を参照して、本実施例におけるネットワーク上のノード構成とユーザリポジトリの配置について説明する。本実施例では、ユーザ認証に使用するアカウントの保存領域を総称してユーザリポジトリと称する。
【００１３】
本実施例に係るユーザクレデンシャル共有システム１００は、ＭＦＰ１０１、ドメインコントローラ１０８、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）サーバ１１３、社内システム認証サーバ１１６、ファイル共有サーバ（外部装置）１１０、１１１、１１５、１１８、及びルータ１０７を備える。各コンポーネントは、企業内のローカルネットワークであるＬＡＮ１０３、１０４、１０５、１０６及びルータ１０７を介して通信可能に接続されているものとする。本実施例において、ＭＦＰ１０１は、企業内のローカルネットワークＬＡＮ１０３に接続されているものとする。ＭＦＰ１０１は、ＭＦＰ１０１のノード内にアカウントを登録するためのユーザリポジトリ１０２を備える。
【００１４】
ＬＡＮ１０３には、ドメインコントローラ１０８、及びファイル共有サーバ１１０が接続される。ドメインコントローラ１０８は、ドメイン名がＣＯＭＰＡＮＹという名前のＣＯＭＰＡＮＹドメインを構成するものとする。ドメインコントローラ１０８は、ドメインコントローラが管轄するノードへアクセスするユーザを登録するためのユーザリポジトリ１０９を備える。例えば、Ｗｉｎｄｏｗｓ（登録商標）ＯＳの機能を使用してドメインコントローラを構築した場合は、ユーザリポジトリとして、ＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ（登録商標）を使用することができる。Ｗｉｎｄｏｗｓ（登録商標）及びＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ（登録商標）はマイクロソフト社の登録商標である。ドメインコントローラ１０８は、Ｋｅｒｂｅｒｏｓのキー配布センター（ＫＤＣ：Key Distribution Center）の機能も備えるものとする。ファイル共有サーバ１１０は、ＣＯＭＰＡＮＹドメインに参加するように構成する。ファイル共有サーバ１１０は、ＳＭＢ（Server Message Block）プロトコルでアクセス可能なネットワーク共有フォルダを公開する。ファイル共有サーバ１１０が公開するネットワーク共有フォルダのアクセス時は、ユーザリポジトリ１０９に登録のアカウントでのみアクセス可能なように予め設定されている。ＳＭＢの接続にはＫｅｒｂｅｒｏｓ認証を使用する。Ｋｅｒｂｅｒｏｓ認証とは、インターネットのような公開されているネットワーク環境において、接続するユーザを正しく認証するための、ネットワーク認証プロトコルの名称であり、ＲＦＣ１５１０で定義されている。Ｋｅｒｂｅｒｏｓ認証では、ＫＤＣでパスワードが管理されている。ＫＤＣは認証サーバとして、ユーザから受け取ったパスワードを認証し、正しいユーザにはチケット保証チケット（Ticket Granting Ticket）を発行する。認証されたユーザは、発行されたチケットを利用して各種のネットワークサービスを利用することができる。
【００１５】
ＬＡＮ１０４は、ファイル共有サーバ１１１が接続される。ファイル共有サーバ１１１は、ＳＭＢプロトコルでアクセス可能なネットワーク共有フォルダを公開する。ファイル共有サーバ１１１のネットワーク共有フォルダへのアクセスは、ファイル共有サーバ１１１が備えるユーザリポジトリ１１２に登録されたアカウントでのみアクセス可能なように予め設定されている。ＳＭＢの接続にはＮＴＬＭ（Windows（登録商標） NT LAN Manager authentication）認証データを使用する。
【００１６】
ＬＡＮ１０５には、ＬＤＡＰサーバ１１３とファイル共有サーバ１１５が接続される。ＬＤＡＰサーバ１１３は、ユーザリポジトリ１１４を備え、外部からＬＤＡＰ Ｓｉｍｐｌｅ Ｂｉｎｄの接続要求を受けてユーザ認証を行うことが可能なように予め設定されている。ＬＤＡＰサーバ１１３は、例えば、Ｌｉｎｕｘ（登録商標）ＯＳとＯｐｅｎＬＤＡＰを使用してユーザリポジトリとユーザ認証機構を構築することができる。ファイル共有サーバ１１５は、ＷｅｂＤＡＶプロトコルでファイルの読み書きが可能なＷｅｂＤＡＶサーバとして機能する。ファイル共有サーバ１１５のＷｅｂＤＡＶへのアクセスは、ＬＤＡＰサーバ１１３のユーザリポジトリ１１４に登録されたアカウントでのみアクセス可能なように予め設定されている。ＷｅｂＤＡＶサーバは、例えば、Ｌｉｎｕｘ（登録商標）ＯＳとＡｐａｃｈｅを使用して構築することができる。ＷｅｂＤＡＶへの接続にはＨＴＴＰのＢａｓｉｃ認証を使用する。
【００１７】
ＬＡＮ１０６には、社内システム認証サーバ１１６と、ファイル共有サーバ１１８が接続される。社内システム認証サーバ１１６は、ユーザリポジトリ１１７を備え、社内システムにアクセスするための認証サービスとして機能する。例えば、社内システム認証サーバ１１６は、独自プロトコルのユーザ認証機構とＳＱＬなどのデータベースからなるユーザリポジトリ１１７を備える。ファイル共有サーバ１１８は、ＷｅｂＤＡＶプロトコルでファイルの読み書きが可能なＷｅｂサービスを公開する。ＷｅｂＤＡＶへの接続にはＨＴＴＰのＢａｓｉｃ認証を使用する。ファイル共有サーバ１１８は、社内システム認証サーバ１１６と連携してユーザ認証を行うためのエージェントプログラムが組み込まれており、ユーザリポジトリ１１７に登録されたアカウントでのみアクセス可能なように予め設定されている。企業内のローカルネットワークには上記以外に不図示の複数のパーソナルコンピュータやＭＦＰが接続されているものとする。
【００１８】
＜シングルサインオン＞
以下では、デバイス（例えば、ＭＦＰ１０１）にログインした時のアカウントを用いて外部サーバにアクセスすることができるシングルサインオンについて説明する。企業におけるオフィス環境には、デバイスにログインした時のアカウントを用いて外部サーバにアクセスするシングルサインオン機能を利用するのに適した環境と適さない環境、或いはその混在環境が存在する。
【００１９】
シングルサインオン機能の利用に適した環境とは、企業内のＩＴ管理者が、コンピュータやデバイスのアクセスアカウントを一元管理している環境を示す。このような環境では、オフィスのスタッフは同じアカウントを用いてネットワーク上のどのノードに対してもアクセス可能である。例えば、下記のような環境がある。
・ＩＴ管理者がドメインコントローラをネットワーク上に配置し、ネットワーク上のノードをドメインに参加させている環境。
・ＩＴ管理者がＬＤＡＰサーバを認証サーバとしてネットワーク上に配置し、各ノードへのアクセスを必ずＬＤＡＰサーバの認証を受けるように設定している環境。
・デバイスやコンピュータのアクセスアカウントはノード毎にローカルアカウントとして登録されているが、ＩＴ管理者が全てのノードに対して同一のアカウント、パスワードを登録することによって一元管理している環境。
【００２０】
また、シングルサインオン機能の利用に適さない環境とは、企業内のＩＴ管理者がノードのアクセスアカウントを一元管理していない環境を示す。例えば以下のような環境がある。
・コンピュータやデバイスのアクセスアカウントを管理するＩＴ管理者がいない環境。
・各オフィスのスタッフがネットワークからアクセス可能なノードを自由に構築したり、各ノードに自由にアカウントを登録することをＩＴ管理者が許可している環境。
【００２１】
また、シングルサインオン機能の利用に適した環境と適さない環境の混在環境とは、ＩＴ管理者がアクセスアカウントを一元管理しているノードやネットワークと、一元管理していないノードやネットワークが混在する環境を示す。例えば、ノードへのアクセスアカウントとしてドメインアカウントとローカルアカウントの両方が利用可能になっている環境において、ＩＴ管理者がドメインアカウントは管理しているが、ローカルアカウントは管理していないケースなども混在環境に相当する。
【００２２】
また、セキュリティドメインを限定することが可能なユーザクレデンシャルを利用する認証プロトコルと、セキュリティドメインを限定することが不可能なユーザクレデンシャルを利用する認証プロトコルがある。例えば、セキュリティドメインを限定することが可能なユーザクレデンシャルを利用する認証プロトコルには、以下のようなものがある。
・特定のノードだけが解釈可能な暗号化された認証データを使用する認証プロトコル、Ｋｅｒｂｅｒｏｓなどがこれに該当する。
・デジタル署名を施したＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの認証トークンを使用する認証プロトコル。
・ドメインと関係する情報を含む認証データを使用する認証プロトコル。
【００２３】
また、セキュリティドメインを限定することが不可能な認証プロトコルには、以下のようなものがある。
・ドメイン情報を含まない認証データ。
・プレーンテキストのアカウントとパスワード。
・一般的に使われているアルゴリズムでのパスワードのハッシュ値。
【００２４】
シングルサインオン機能の利用に適さない環境において、セキュリティドメインを限定することが不可能な認証プロトコルを利用して、デバイスから他のノードにシングルサインオンを試みた場合、次のような問題が発生する。デバイスは、アクセス先のノードのアクセスアカウントが一元管理されているかどうか判断することなく、アクセスを試みる。アクセスを試みた結果、アクセス先のノードにデバイスログイン時の認証データと同一の認証データが偶然存在した場合に不正にアクセスできてしまう。
【００２５】
シングルサインオン機能の利用に適さない環境では、上記問題を解決するためにシングルサインオン機能を一律で利用禁止にするだけで良かった。一方、シングルサインオン機能の利用に適した環境と適さない環境の混在環境では、認証データの偶然の一致による不正アクセスを防止しつつ、シングルサインオン機能を使用したい。そこで、本実施例に係るユーザクレデンシャル共有システム１００では上記問題を解決する。以下で詳細に説明する。
【００２６】
＜ＭＦＰのハードウェア構成＞
次に、図２を参照して、ＭＦＰ１０１のハードウェア構成について説明する。２０１はＭＦＰ全体の制御を司るＣＰＵであり、２０２はＣＰＵ２０１が実行するソフトウェアプログラムやフォントデータを格納するＲＯＭである。２０３はＣＰＵ２０１のワークエリア、受信バッファ、画像描画に使用されるＲＡＭである。２０４は、ソフトウェアのプログラムコードや、ユーザ認証情報などのデータを記録するハードディスクドライブ（ＨＤＤ）である。ＨＤＤ２０４の一部は、図１で示したユーザリポジトリ１０２の領域としても利用される。２０５は各種スイッチやボタン、並びにメッセージ表示用の液晶表示部で構成される操作パネルである。２０６は、ネットワークに接続するためのネットワークインタフェースである。２０７は記録紙に印刷を行うプリンタある。２０８は、印刷されたドキュメントなどの原稿を読み取って画像データに変換するスキャナ（読取手段）である。
【００２７】
＜ＭＦＰ１０１のソフトウェア構成＞
次に、図３を参照して、ＭＦＰ１０１のソフトウェア構成について説明する。下記のソフトウェアの実行プログラムは、ＣＰＵ２０１によって、ＲＯＭ２０２やＨＤＤ２０４からＲＡＭ２０３にコピーされ、実行される。デバイスドライバ群３０１は、上記各種ハードウェアを制御するためのデバイスドライバ群である。３０２は、オペレーティングシステムである。３０３は、ＭＦＰ１０１の組み込みアプリケーションをインストール／アンインストール、起動／停止などを制御するためのアプリケーションプラットフォームである。例えば、アプリケーションプラットフォーム３０３は、ＪＡＶＡ（登録商標）プラットフォームや、ＯＳＧｉフレームワークを含む形で構成することができる。ＪＡＶＡ（登録商標）は、オラクル社の登録商標である。ＯＳＧｉフレームワークは、ＯＳＧｉ Ａｌｌｉａｎｃｅ（標準化団体）が定義したＪＡＶＡ（登録商標）ベースのサービスプラットフォームである。アプリケーションプラットフォーム３０３には、ＭＦＰ１０１が工場出荷時から備えるアプリケーションに加えて、ユーザが追加でアプリケーションをインストールすることができる。例えば、アプリケーションプラットフォーム３０３は、アプリケーションを管理するためのユーザインタフェース（図６）を備えるサーブレットをユーザに提供する。ＭＦＰ１０１の管理者は、ネットワークを介して、アプリケーションの実行ファイル（ＪＡＲファイル）を指定して、アプリケーションの追加インストールを実施することができる。図４は、アプリケーションプラットフォーム３０３が提供するアプリケーションのインストール／アンインストール、起動／停止などを制御するための画面を示す。アプリケーションプラットフォーム３０３は、図４に示す画面を介して入力されたユーザ指示に基づいてアプリケーションを管理することができる。
【００２８】
ここで、アプリケーションプラットフォーム３０３の上で動作するアプリケーションの種別について説明する。特にアプリケーションの種別を限定しない場合は、単にアプリケーションと記載する。
・システムアプリケーション
ＭＦＰ１０１が工場出荷時から備えるアプリケーション。
・ログインアプリケーション
ＭＦＰ１０１にログインするユーザを認証するため特別なアプリケーションである。
・一般アプリケーション
ログインアプリケーション以外のユーザがインストール／アンインストール可能なアプリケーション。
【００２９】
ユーザクレデンシャル共有サービス３０４は、システムアプリケーションとして動作する。ログインアプリケーション３０５は、操作パネル上にログイン画面５０１を表示してユーザ認証を行う。ログイン画面５０１の詳細については図５を用いて後述する。送信アプリケーション３０６は、スキャンした画像を外部に送信する機能を備える一般アプリケーションである。３０７、３０８は、その他の一般アプリケーションを示す。
【００３０】
＜ユーザクレデンシャル＞
本実施例では、ユーザ認証に使用する情報や、ユーザ認証後に生成されるユーザを証明する情報を総称してユーザクレデンシャルと称する。ユーザクレデンシャルには、例えば以下のようなものが含まれる。
・プレーンテキストのアカウント、パスワード。
・プレーンテキストのアカウントとパスワードのハッシュ値。
・ＫｅｒｂｅｒｏｓのＴＧＴ（Ticket Granting Ticket）、ＴＧＳ（Ticket Granting Server）が発行するチケット。
・ＳＡＭＬなどの認証トークン。
【００３１】
＜ユーザクレデンシャル共有サービス３０４＞
ユーザクレデンシャル共有サービス３０４は、複数のアプリケーション間でユーザクレデンシャルの共有を可能にするサービスである。ここで、図６を参照して、ユーザクレデンシャル共有サービス３０４が備える、アプリケーションから利用可能なＡＰＩ群について説明する。ＡＰＩ６０１は、アプリケーションに指定されたユーザクレデンシャルを認証プロトコルやユーザクレデンシャルデータの型に関する情報と関連付けてＲＡＭ２０３に保存する。ＡＰＩで使用する認証プロトコルには、Ｋｅｒｂｅｒｏｓ、Ｌｏｃａｌ、ＬＤＡＰ  Ｓｉｍｐｌｅ  Ｂｉｎｄの文字列が予め規定されている。アプリケーションがこれ以外の認証プロトコルを使用する場合には、任意の文字列を指定することも可能とする。例えば、図７の７０１〜７０４に示すデータのいずれか、或いは複数のデータを保存する。
【００３２】
ＡＰＩ６０２は、ＲＡＭ２０３に保存したユーザクレデンシャル全て取得して、アプリケーションに返却する。ＡＰＩ６０３は、引数で指定された認証プロトコルと関連付いたユーザクレデンシャルを取得して、アプリケーションに返却する。ユーザクレデンシャル共有サービス３０４は、ユーザのログアウトや、ＭＦＰ１０１のシャットダウンを検知すると、ＲＡＭ２０３に保存したユーザクレデンシャルデータを破棄する。ユーザクレデンシャル共有サービス３０４は、ＭＦＰ１０１の管理者が、ユーザクレデンシャル共有サービス３０４の動作設定を行うためのユーザインタフェースを備える。ここで、図８を参照して、当該ユーザインタフェースについて説明する。図８に示すように、チェックボックス８０１は、認証プロトコルＬｏｃａｌと関連するユーザクレデンシャルの返却を行わないように変更するスイッチである。チェックボックス８０２は、ＬＤＡＰ  Ｓｉｍｐｌｅ  Ｂｉｎｄと関連するユーザクレデンシャルの返却を行わないように変更するスイッチである。チェックボックス８０３は、予め規定されていない認証プロトコル（Ｋｅｒｂｅｒｏｓ、Ｌｏｃａｌ、ＬＤＡＰ  Ｓｉｍｐｌｅ  Ｂｉｎｄ以外の認証プロトコル）と関連するユーザクレデンシャルの返却を行わないように変更するスイッチである。ＭＦＰ１０１の管理者が、チェックボックスにチェックを入れて、設定更新ボタン８０４を押下した場合にスイッチを有効にする。つまり、ＭＦＰ１０１の管理者は、図８に示すユーザインタフェースを用いて、認証プロトコルの種別毎にユーザクレデンシャルの共有を禁止する設定を行うことができる。
【００３３】
＜ログインアプリケーション３０５＞
次に、図５を参照して、ログインアプリケーション３０５について説明する。ログインアプリケーション３０５は、操作パネル２０５にログイン画面５０１を表示し、ＭＦＰ１０１にログインするユーザを認証する。ログイン画面５０１は、アカウント、パスワードを入力するテキストボックス５０２に加えて認証先を選択するためのドロップダウンリスト５０３を備える。ここで選択された認証先に基づいて、ユーザクレデンシャルに関連する認証プロトコルが決定されてもよい。また、画面５０１において、ユーザに対してさらに認証プロトコルの入力を促すような構成としてもよい。ログインアプリケーション３０５は、ユーザリポジトリ１０２に、アカウントを予め登録するためのユーザインタフェースを備える。更に、ログインアプリケーション３０５は、外部の認証サーバが管理するユーザリポジトリ１０９、１１４、１１７のアカウントを使ったユーザ認証機能を備える。ログインアプリケーション３０５は、外部の認証サーバと連携するための情報をＭＦＰ１０１のＨＤＤ２０４に記憶させるための認証サーバ登録画面５０５備える。認証サーバ登録画面５０５は、一般のウェブブラウザを使ってデバイスの管理者だけがアクセス可能なＷｅｂページとして構成する。
【００３４】
例えば、認証サーバ登録画面５０５では、図５に示すように、以下のような情報の登録を可能とする。
・ログイン画面５０１の認証先を示すドロップダウンリスト５０３に表示する表示名
・サーバ名
・サーバのネットワークアドレス
・ドメイン名
・ユーザの認証に使用する認証プロトコル
本実施例では、ドメインコントローラ１０８、ＬＤＡＰサーバ１１３、社内システム認証サーバ１１６が認証サーバとして登録可能である。ドロップダウンリスト５０３には、ＬｏｃａｌＨｏｓｔが表示されている。ＬｏｃａｌＨｏｓｔはＭＦＰ１０１自身が有するユーザリポジトリ１０２を用いる認証であるので、画面５０５に登録されていなくてもドロップダウンリスト５０３に表示される。ログインアプリケーション３０５は、認証サーバの登録状態に応じて、認証先に表示名を表示する。
【００３５】
ログインアプリケーション３０５は、ログインボタン５０４の押下を検知すると、テキストボックス５０２に入力されたアカウント、パスワードと認証先（ドロップダウンリスト５０３で選択された値）を取得する。次に、認証先と関連するユーザリポジトリ、認証サーバ、認証プロトコルなどの情報を用いてユーザ認証を試みる。ユーザ認証が成功した場合は、ＡＰＩ６０１を介して、認証プロトコル情報と共にユーザクレデンシャルの保存をユーザクレデンシャル共有サービス３０４に依頼する。本実施例における認証先（ドロップダウンリスト５０３）に表示される文字列とユーザリポジトリ、認証サーバ、認証プロトコル、認証成功時にユーザクレデンシャル共有サービス３０４に保存するユーザクレデンシャルの関係を以下で説明する。
【００３６】
＜認証先：ＬｏｃａｌＨｏｓｔ＞
ＬｏｃａｌＨｏｓｔは、ユーザリポジトリ１０２と関連付けられる。認証プロトコルは、Ｌｏｃａｌと関連付けられる。ログインアプリケーション３０５は、テキストボックス５０２から取得したアカウント、パスワードと、ユーザリポジトリ１０２に登録されたデータを照合してユーザ認証を行う。ユーザ認証が成功すると、ＡＰＩ６０１を介してプレーンテキストのアカウント、パスワードの保存をユーザクレデンシャル共有サービス３０４に依頼する。ＡＰＩ６０１の認証プロトコルを示す引数にはＬｏｃａｌを指定する。
【００３７】
＜認証先：ＣＯＭＰＡＮＹドメイン＞
ＣＯＭＰＡＮＹドメインは、ユーザリポジトリ１１２を管理するドメインコントローラ１０８と関連付けられる。認証プロトコルはＫｅｒｂｅｒｏｓと関連づけられる。ログインアプリケーション３０５は、テキストボックス５０２から取得したアカウント、パスワードと、事前登録されたドメイン名（ｃｏｍｐａｎｙ．ｃｏｍ）を使用し、ドメインコントローラ１０８に対してＫｅｒｂｅｒｏｓプロトコルでユーザ認証を試みる。ログインアプリケーション３０５は、ユーザ認証が成功すると、Ｋｅｒｂｅｒｏｓ認証時に取得したＴＧＴを、ユーザクレデンシャルとして、ユーザクレデンシャル共有サービス３０４に保存を依頼する。ＡＰＩ６０１の認証プロトコルを示す引数にはＫｅｒｂｅｒｏｓを指定する。
【００３８】
＜認証先：ＬＤＡＰサーバ＞
ＬＤＡＰサーバは、ユーザリポジトリ１１４を管理するＬＤＡＰサーバ１１３と関連付けられる。認証プロトコルはＬＤＡＰ Ｓｉｍｐｌｅ Ｂｉｎｄと関連付けられる。ログインアプリケーション３０５は、テキストボックス５０２から取得したアカウント、パスワードを使用し、ＬＤＡＰサーバ１１３に対してＬＤＡＰ Ｓｉｍｐｌｅ Ｂｉｎｄでユーザ認証を試みる。ログインアプリケーション３０５は、ユーザ認証が成功するとＡＰＩ６０１を介してプレーンテキストのアカウント、パスワードの保存をユーザクレデンシャル共有サービス３０４に依頼する。ＡＰＩ６０１の認証プロトコルを示す引数にはＬＤＡＰ Ｓｉｍｐｌｅ Ｂｉｎｄを指定する。
【００３９】
＜認証先：社内システム＞
社内システムは、ユーザリポジトリ１１７を管理する社内システム認証サーバ１１６と関連付けられる。ログインアプリケーション３０５は、テキストボックス５０２から取得したアカウント、パスワードを使用し、社内システム認証サーバ１１６に対して社内システム認証サーバ１１６が実装する独自プロトコルでユーザ認証を試みる。ログインアプリケーション３０５は、ユーザ認証が成功するとＡＰＩ６０１を介してプレーンテキストのアカウント、パスワードの保存をユーザクレデンシャル共有サービス３０４に依頼する。ＡＰＩ６０１の認証プロトコルを示す引数にはＣｕｓｔｏｍを指定する。
【００４０】
＜送信アプリケーション３０６＞
送信アプリケーション３０６は、スキャナ２０８から読み込まれたドキュメントの電子データをファイル共有サーバ（外部装置）に送信することができるアプリケーションである。送信アプリケーション３０６は、図９のようなユーザインタフェースを備える。ユーザは、画面９０１において、スキャナ２０８から読み込んだ電子データのファイルフォーマット（ＰＤＦやＪＰＥＧなど）や、予めＭＦＰ１０１の管理者によって登録された送信先のファイル共有サーバなどを指定することができる。送信アプリケーション３０６は、ユーザクレデンシャル共有サービス３０４のＡＰＩ６０２、６０３を介して、ＭＦＰ１０１にログイン中のユーザのユーザクレデンシャルを取得することができる。取得したユーザクレデンシャルは、ファイル共有サーバアクセス時のユーザ認証に使用する。当該ユーザ認証が成功すると、送信アプリケーション３０６は、スキャナ２０８から読み込んだ電子データのファイルフォーマットを認証されたファイル共有サーバに送信し、格納する。
【００４１】
＜ユーザクレデンシャル共有サービスの動作＞
次に、図１０及び図１１を参照して、本実施例に係るユーザクレデンシャル共有サービスの動作について説明する。図１０は、ユーザがＭＦＰ１０１にログインして送信アプリケーション３０６を利用してドキュメント送信を行うまでの一連のシーケンスを示す。図１１は、図１０のＳ１００６におけるユーザクレデンシャル共有サービスの詳細な処理フローを示す。なお、以下で説明する処理は、ＭＦＰ１０１のＣＰＵ２０１がＲＯＭ２０２やＨＤＤ２０４に格納された制御プログラムをＲＡＭ２０３に読み出して実行することによって実現される。
【００４２】
まずＳ１００１において、ログインアプリケーション３０５は、ログイン画面５０１を介したユーザのログイン操作を検知して、Ｓ１００２においてユーザ認証を行う。認証先が外部サーバを示す場合は、Ｓ１００２のユーザ認証処理において外部の認証サーバにアクセスする。続いて、Ｓ１００３において、ログインアプリケーション３０５は、ユーザ認証が成功すると、ＡＰＩ６０１を介してユーザクレデンシャルの保存をユーザクレデンシャル共有サービス３０４に依頼する。ユーザクレデンシャルの保存要求を受けたユーザクレデンシャル共有サービス３０４は、ＡＰＩ６０１を介して取得したユーザクレデンシャルをＲＡＭ２０３に保存する。Ｓ１００３の処理が終了すると、ユーザは、送信アプリケーション３０６の操作が可能となる。Ｓ１００４において、送信アプリケーション３０６は、ユーザの画面９０１を介したドキュメント送信操作を検知すると、Ｓ１００５に進む。Ｓ１００５において、送信アプリケーション３０６は、ＡＰＩ６０２又はＡＰＩ６０３を介してユーザクレデンシャル共有サービス３０４にログインユーザのユーザクレデンシャルの取得要求を送信する。
【００４３】
Ｓ１００６において、ユーザクレデンシャル共有サービス３０４は、ユーザクレデンシャルの取得要求を受信すると、取得要求のＡＰＩの引数等を解析し、応答情報を生成する。Ｓ１００６の詳細な処理については、図１１を参照して後述する。続いて、Ｓ１００７において、ユーザクレデンシャル共有サービス３０４は、送信アプリケーション３０６に対して、Ｓ１００６で生成したユーザクレデンシャルの応答情報に従って取得応答を返す。
【００４４】
次に、Ｓ１００８において、送信アプリケーション３０６は、Ｓ１００７で返却されたユーザクレデンシャルを使用して、ファイル共有サーバにアクセスし、ドキュメントを送信する。一方、Ｓ１００７でユーザクレデンシャルが取得できなかった場合や取得したユーザクレデンシャルでファイル共有サーバにアクセスできなかった場合は、図９に示す画面９０２を表示してユーザにファイル共有サーバにアクセス可能なアカウントの入力を促すことができる。
【００４５】
＜Ｓ１００６の詳細フロー＞
次に、図１１を参照して、Ｓ１００６の詳細な処理フローについて説明する。Ｓ１１０１において、ユーザクレデンシャル共有サービス３０４は、ユーザクレデンシャルの取得要求を受信すると処理を開始する。Ｓ１００２において、ユーザクレデンシャル共有サービス３０４は、ＲＡＭ２０３に保存したユーザクレデンシャルを取得する。この際、ＡＰＩ６０３の引数で認証プロトコルが指定されていた場合は、指定された認証プロトコルと関連するユーザクレデンシャルのみを取得し、認証プロトコルの指定が無かった場合は、保存した全てのユーザクレデンシャルを取得する。
【００４６】
次に、Ｓ１１０３において、ユーザクレデンシャル共有サービス３０４は、取得したユーザクレデンシャルと関連する認証プロトコルの種別を確認する。例えば、認証プロトコルがＫｅｒｂｅｒｏｓであった場合は、ユーザクレデンシャルを利用するセキュリティドメインを限定することが可能な認証プロトコルと判断し、Ｓ１１０４でユーザクレデンシャルリストに追加する。一方、認証プロトコルがＫｅｒｂｅｒｏｓ以外の認証プロトコルの場合は、ユーザクレデンシャルを利用するセキュリティドメインを限定することが不可能な認証プロトコルと判断し、Ｓ１１０５の処理に進む。Ｋｅｒｂｅｒｏｓ以外の認証プロトコルとは、ドメイン情報を含まないプレーンテキストのアカウントとパスワードを使用するような認証プロトコルを示す。例えば、セキュリティドメインを限定することが不可能な認証プロトコルは、ローカルアカウントを使用する認証や、ＬＤＡＰのＳｉｍｐｌｅ Ｂｉｎｄを含む。
【００４７】
セキュリティドメインを限定することが可能なプロトコルと、セキュリティドメインを限定することが不可能な認証プロトコルの情報は、予めユーザクレデンシャル共有サービス３０４が規定しているものとする。認証プロトコルが、図６に示すＡＰＩに規定されておらず、ユーザクレデンシャル共有サービス３０４にとって未知の認証プロトコルであった場合も同様にＳ１１０５の処理に進む。
【００４８】
Ｓ１１０５において、ユーザクレデンシャル共有サービス３０４は、取得したユーザクレデンシャルと関連する認証プロトコルの共有可否設定を取得し、Ｓ１１０６で共有可否を判定する。設定値は、チェックボックス８０１〜８０３に対して、図８に示すユーザインタフェースを介してＨＤＤ２０４に予め記録された値である。ユーザクレデンシャル共有サービス３０４にとって未知の認証プロトコルは、その他の認証プロトコルに分類し、チェックボックス８０３で設定された値を参照する。設定値が共有許可を示す場合はＳ１１０４に進み、関連するユーザクレデンシャルをユーザクレデンシャルリストに追加する。設定値が共有不可を示す場合はＳ１１０７に進み、ユーザクレデンシャルは返却しないものと判断する。最後に、Ｓ１１０８において、ユーザクレデンシャル共有サービス３０４は、Ｓ１１０４で作成したユーザクレデンシャルのリストをＳ１００５の応答として返却する。返却可能なユーザクレデンシャルが無かった場合は、ＮＵＬＬを返却する。これにより、ＭＦＰ管理者は、オフィス環境に応じて、ユーザクレデンシャル共有サービスの設定（図８）を行うことにより、適切にシングルサインオン機能の利用を制御することができる。
【００４９】
＜ユースケース＞
次に、図１２を参照して、本実施例に係るユースケースと設定例について説明する。まず図１２の表の列について説明する。列１２０１は、ＭＦＰ１０１のログインに使用するアカウントの管理元のユーザリポジトリを示す。列１２０２は、ＭＦＰ１０１のログイン後にユーザクレデンシャル共有サービス３０４に保存されるユーザクレデンシャルを示す。列１２０３は、ドキュメント送信先時の接続先であるファイル共有サーバを示す。列１２０４は、ファイル共有サーバにアクセスするために必要なアカウントの管理元のユーザリポジトリを示す。列１２０５は、ファイル共有サーバの接続に使用する認証プロトコルを示す。
【００５０】
列１２０６は、ファイル共有サーバが存在するＬＡＮを示す。列１２０６は、シングルサインオンの可否を示す。値の×は、ユーザクレデンシャル共有サービスから取得したユーザクレデンシャルを使用したとしても、接続できないことを示す。例えば、１２０２のユーザクレデンシャルが１２０５の認証プロトコルに使用できない、又は、ファイル共有サーバ側の認証処理で認証エラーにすることが可能なケースである。値の○は、ユーザクレデンシャル共有サービスの設定とは関係なく、常にユーザクレデンシャル共有サービスから取得したユーザクレデンシャルを使用して接続可能なことを示す。値の△は、１２０１のユーザリポジトリと、１２０４のユーザリポジトリが同じであるため、ユーザクレデンシャル共有サービスの設定（図８）で１２０２が示すユーザクレデンシャルの共有を許可に設定した場合には接続可能なことを示す。値の□は、１２０１のユーザリポジトリと、１２０４のユーザリポジトリが異なるが、意図的に同一のアカウント、パスワードが登録されていれば、ユーザクレデンシャル共有サービスから取得したユーザクレデンシャルを利用して接続可能なことを示す。
【００５１】
次に、表ａが示すユースケースを説明する。本ユースケースでは、以下の条件を想定する。
・ルータ１０７の設定により、ＭＦＰ１０１は、ＬＡＮ１０３とＬＡＮ１０４に接続可能で、ＬＡＮ１０５とＬＡＮ１０６には接続できない。
・ＭＦＰ１０１のログインに使用する認証先は、ＬｏｃａｌＨｏｓｔと、ＣＯＭＰＡＮＹドメインが利用可能なように予め設定されている。
上記の条件では、行１２０８、１２１０、１２１１が示す組み合わせは、ユーザクレデンシャル共有サービスの設定（図８）の有無に関わらず接続の可否が決定する。ＭＦＰ１０１の管理者は、行１２０９が示す組み合わせにのみ着目して、ユーザクレデンシャル共有サービスの設定（図８）を行えばよい。つまり、ログイン時のユーザリポジトリ１０２と、接続先のユーザリポジトリ１１２に意図的に同一のアカウント、パスワードが登録されているようであれば、Ｌｏｃａｌと関係するユーザクレデンシャルの共有を許可にする。同一のアカウント、パスワードを登録することが意図されていない場合は、偶然の一致による不正アクセスを防止するため、Ｌｏｃａｌと関係するユーザクレデンシャルの共有を禁止にする。
【００５２】
次に、表ｂが示すユースケースを説明する。本ユースケースでは、以下の条件を想定する。
・ルータ１０７の設定により、ＭＦＰ１０１は、ＬＡＮ１０３とＬＡＮ１０５に接続可能で、ＬＡＮ１０４とＬＡＮ１０６には接続できない。
・ＭＦＰ１０１のログインに使用する認証先は、ＣＯＭＰＡＮＹドメインとＬＤＡＰサーバが利用可能なように予め設定されている。
上記の条件では、行１２１２、１２１３、１２１４が示す組み合わせは、ユーザクレデンシャル共有サービスの設定の有無に関わらず接続の可否が決定する。一方、行１２１５が示す組み合わせでは共に使用されるユーザリポジトリが１１４で同じであるため、ＭＦＰ１０１の管理者は、ユーザクレデンシャルの共有を禁止に設定する必要はない。
【００５３】
次に表ｃが示すユースケースを説明する。本ユースケースでは、以下の条件を想定する。
・ルータ１０７の設定により、ＭＦＰ１０１は、ＬＡＮ１０３とＬＡＮ１０４、ＬＡＮ１０６に接続可能で、ＬＡＮ１０５には接続できない。
・ＭＦＰ１０１のログインに使用する認証先は、ＬｏｃａｌＨｏｓｔと、ＣＯＭＰＡＮＹドメイン、社内システムが利用可能なように予め設定されている。
上記の条件では、行１２１６、１２１９、１２２０、１２２１、１２２２が示す組み合わせは、ユーザクレデンシャル共有サービスの設定の有無に関わらず接続の可否が決定する。ＭＦＰ１０１の管理者は、行１２１７、１２１８、１２２３が示す組み合わせにのみ着目して、ユーザクレデンシャル共有サービスの設定（図８）を行えばよい。つまり、ユーザリポジトリ１０２、１１２、１１７に意図的に同一のアカウント、パスワードが登録されているか否かに着目する。
【００５４】
ユーザリポジトリ１０２、１１２、１１７全てに意図的に同一のアカウント、パスワードが登録されている場合は、ユーザクレデンシャルの共有を禁止する必要はない。ユーザリポジトリ１０２、１１２に意図的に同一のアカウント、パスワードが登録されており、１１７は異なる場合は、行１２１８、１２２３が示す組み合わせは、認証データの偶然の一致による不正アクセスを防止する必要がある。この場合は、図８の８０１、８０３の設定を用いて、ＬｏｃａｌおよびＣｕｓｔｏｍと関連するユーザクレデンシャルの共有を禁止する。ユーザリポジトリ１１２、１１７に意図的に同一のアカウント、パスワードが登録されており、１０２は異なる場合は、行１２１７、１２１８が示す組み合わせは、認証データの偶然の一致による不正アクセスを防止する必要がある。この場合は、図８の８０１の設定を用いて、Ｌｏｃａｌと関連するユーザクレデンシャルの共有を禁止する。Ｃｕｓｔｏｍと関連するユーザクレデンシャルの共有は許可のままでよい。
【００５５】
以上説明したように、本実施例に係る情報処理装置（画像処理装置）は、セキュリティドメインを限定することが不可能な認証プロトコルに関して、ユーザクレデンシャルの共有を禁止する。これにより、認証データの偶然の一致による不正アクセスが発生することを防止することができる。更に、ログインに使用する認証プロトコル単位で、ユーザクレデンシャルの共有可否の設定を行うユーザインタフェースを設けた。これにより、シングルサインオン機能の利用に適した環境と適さない環境の混在環境であっても、認証データの偶然の一致による不正アクセスを防止させつつ、一部のシングルサインオン機能の利用を可能にした。
【００５６】
また、ユーザクレデンシャルと関連する認証プロトコルがセキュリティドメインを限定することが可能な認証プロトコルか否かをユーザクレデンシャル共有サービス３０４が判断するように構成した。これにより、認証プロトコルの知識が無いＭＦＰ１０１の管理者に対して、セキュリティドメインを限定することが不可能な認証プロトコルと関連するユーザクレデンシャルの共有可否設定を促すことができるという効果が得られる。また、ユーザクレデンシャル共有サービス３０４のＡＰＩ（図６）に規定していない認証プロトコルに対する共有可否（８０３）を設定可能にした。これにより、ユーザクレデンシャル共有サービス３０４にとって未知の認証プロトコルを実装したログインアプリケーションがＭＦＰ１０１上で稼働しても、ユーザクレデンシャル共有可否の制御を行うことができるという効果が得られる。
【００５７】
上記、本発明を実施することより、以下の利点のあるユーザクレデンシャル共有システムを提供することが可能となる。
・デバイスの管理者がオフィス環境を考慮してユーザクレデンシャルの共有設定を行うことがきるため、デバイスにおけるシングルサインオン機能の利用を適切にコントロールすることができる。
・アカウントが一元管理されていない環境において、認証データの偶然の一致による不正アクセスを防止することができる。
・セキュリティドメインを限定することが不可能な複数の認証プロトコルを同時に使用するような環境であっても、認証プロトコル毎にシングルサインオンの機能の利用可否を設定し、部分的にシングルサインオンの機能を利用することができる。
【００５８】
＜変形例＞
上記実施例においては、ユーザクレデンシャル共有サービス３０４を利用してＫｅｒｂｅｒｏｓのＴＧＴ、アカウント、パスワードを共有する例を示した。しかしながら、本発明は様々な変形が可能である。例えば、その他のユーザクレデンシャルとして、パスワードのハッシュ値、ＳＡＭＬなどのチケットなどを、ユーザクレデンシャル共有サービス３０４を利用して共有可能にしてもよい。
【００５９】
＜その他の実施例＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
0005968077.tif 000002
【図２】
0005968077.tif 000003
【図３】
0005968077.tif 000004
【図４】
0005968077.tif 000005
【図５】
0005968077.tif 000006
【図６】
0005968077.tif 000007
【図７】
0005968077.tif 000008
【図８】
0005968077.tif 000009
【図９】
0005968077.tif 000010
【図１０】
0005968077.tif 000011
【図１１】
0005968077.tif 000012
【図１２】
0005968077.tif 000013