ユーザ認証システム、ユーザ認証方法およびコンピュータが実行するためのプログラム
【課題】アプリケーションのユーザが外部サービスで必要とされる認証を考慮せずに、ユーザのログイン操作の中で自動的に認証手続きが実施され、利用が可能となる。
【解決手段】ログイン処理が開始されると、アクセス制御部１１は、設定されたデータフローのフロー定義情報を取り出す。チェックしていない外部サービスが存在する場合は、フロー定義で利用する外部サービス情報を一つ取り出し、その外部サービスが第２の認証を要求している場合は、認証先として第２の認証をマークする。チェックしていない外部サービスが存在しない場合は、ログイン画面を表示し、ユーザが認証情報を入力すると第１の認証を実施する。第１の認証が成功すると、他に第２の認証部２１がある場合は、認証を試みる。その認証が成功し、他に認証先が無い場合は、アプリケーション１０を使って外部サービス２０を利用する。
【解決手段】ログイン処理が開始されると、アクセス制御部１１は、設定されたデータフローのフロー定義情報を取り出す。チェックしていない外部サービスが存在する場合は、フロー定義で利用する外部サービス情報を一つ取り出し、その外部サービスが第２の認証を要求している場合は、認証先として第２の認証をマークする。チェックしていない外部サービスが存在しない場合は、ログイン画面を表示し、ユーザが認証情報を入力すると第１の認証を実施する。第１の認証が成功すると、他に第２の認証部２１がある場合は、認証を試みる。その認証が成功し、他に認証先が無い場合は、アプリケーション１０を使って外部サービス２０を利用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ認証システム、ユーザ認証方法およびプログラムに関し、詳細には、外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証システム、ユーザ認証方法およびプログラムに関する。
【背景技術】
【０００２】
従来、外部サービスを利用することが前提となっているアプリケーションにおいて、外部サービスが要求するユーザ認証の機構をそのまま使い、アプリケーション自身のアクセス制御も行えるならば、利用者にとってもアプリケーション自身にとっても都合が良く、一般的にＳＳＯ（シングル・サイン・オン）機能という形で利用されている。
【０００３】
ところが、現状では、外部サービスが、一般的なＩＤとパスワードにより認証を行う汎用的なユーザ認証手段（本明細書中では第１の認証手段という）ではなく、外部サービスの一部に組み込まれた認証手段（本明細書中では第２の認証手段という）を提供していることが多い。しかしながら、この第２の認証手段は、外部サービス以外で利用することを必ずしも想定していない。例えば、外部サービスを利用するアプリケーションには、認証結果として誰であるとして特定されたのかが伝達されず、認証に成功したのか失敗したのかしか伝達されないものもある。その結果、アプリケーション側には、認証に成功したユーザか否かの情報しか得られず、認証結果に基づいてきめ細かいアクセス制御機能を実現することは難しい。
【０００４】
また、アプリケーション側でアクセス制御を行うためには、あらかじめ管理者がユーザに対して権限を割り当てておく必要がある。このような機能を実現するためには、候補となるユーザの一覧を取得し、そこからユーザを選んで権限を付与するという手順が必要となる。しかし、外部サービスにはユーザの一覧を提供する機能を持たない認証手段も存在する。
【０００５】
この種の従来例としては、例えば下記に示す特許文献１〜３などがある。
【０００６】
【特許文献１】特開２００２−３３３９２８号公報
【特許文献２】特開２００４−８６４９０号公報
【特許文献３】特開２０００−１０６５５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、このようなユーザ認証システムにあっては、ユーザ認証機構を有し、それに基づいてアクセス制御機能を提供する外部サービスがあったとしても、そのセキュリティ機能が、その装置内に閉じた機能しか提供されない場合には、十分なセキュリティと利便性とを確保することが難しいという問題がある。
【０００８】
また、このような場合、認証手続きとサービス利用手続きとが組み合わさって不可分になっていることが多い。このため、複数の外部サービスを組み合わせて利用する場合には、手続きを「認証」と「サービスの利用」に分離して抽象化して扱えるならば、保守や機能拡張などの面で有利となる。しかし、上記したように個別に最適化された手続きになっている場合は、抽象化が阻害されてしまい、サービス毎に個別の対応が必要になってくるという問題がある。
【０００９】
本発明は、上記に鑑みてなされたものであって、アプリケーションのユーザが外部サービスで必要とされる認証を考慮することなく、ユーザの最低限のログイン操作の中で自動的に必要な認証手続きが実施されて利用することができるユーザ認証システム、ユーザ認証方法、およびコンピュータが実行するためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備える端末装置と、前記端末装置に関するアクセス制御を行うアクセス制御手段と、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証手段と、前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第１の認証手段と前記第２の認証手段の認証を行い、両方の認証が成功した場合に前記アプリケーションの利用を可能とし、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証手段の結果得られた第１の認証子を利用することを特徴とする。
【００１１】
また、請求項２にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証手段を抽出する抽出手段をさらに備え、前記アプリケーションの利用開始時の認証処理において、前記抽出手段で抽出された全ての認証手段に対して認証を試みることを特徴とする。
【００１２】
また、請求項３にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を作成する際に、設定に従った動作を行うのに必要な認証手段を抽出する抽出手段と、該抽出した認証手段と設定情報と対応付けて記録する記録手段とをさらに備え、前記アプリケーションの利用開始時の認証処理において、前記記録手段に記録されている全ての認証手段に対して認証を試みることを特徴とする。
【００１３】
また、請求項４にかかる発明は、請求項１〜３のいずれか一つに記載のユーザ認証システムであって、前記第２の認証手段のうち、機能を実行するために必須の認証を必須認証手段とし、オプショナルな機能に関する認証をオプショナル認証手段として分類し、前記必須認証手段に関する認証が失敗すると認証に関わる処理を停止させるが、前記オプショナル認証手段に関する認証が失敗しても認証に関わる処理をスキップするだけで処理全体を停止させないようにすることを特徴とする。
【００１４】
また、請求項５にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記設定情報をカスタマイズする際に、管理者によって指定できるようにしたことを特徴とする。
【００１５】
また、請求項６にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記外部サービスの属性によって決定されることを特徴とする。
【００１６】
また、請求項７にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記アプリケーションが定義する外部サービスに対して与えられる役割によって決定することを特徴とする。
【００１７】
上述した課題を解決し、目的を達成するために、請求項８にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備える端末装置と、前記端末装置に関するアクセス制御を行うアクセス制御手段と、前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、ユーザ属性が格納されたディレクトリサービスと、前記ディレクトリサービスを検索して、前記外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する属性情報取得手段と、を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第２の認証手段の認証を行い、認証が成功すると前記認証情報を使って前記属性情報取得手段により前記ディレクトリサービスを検索し、前記外部サービス機器へのアクセス制御に必要なユーザ属性を取得してアクセス制御を行うことを特徴とする。
【００１８】
また、請求項９にかかる発明は、請求項８に記載のユーザ認証システムであって、前記第２の認証手段による認証の結果得られた第２の認証子と、前記ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、前記アプリケーションは前記第２および第３の認証子を利用することを特徴とする。
【００１９】
また、請求項１０にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記第１の認証手段と前記第２の認証手段の認証を行って両方の認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記第１の認証手段による認証の結果得られた第１の認証子とを組み合わせて第４の認証子を生成し、前記端末装置のアプリケーションは、該第４の認証子を利用することを特徴とする。
【００２０】
また、請求項１１にかかる発明は、請求項８に記載のユーザ認証システムであって、前記アクセス制御手段は、前記第２の認証手段の認証を行って認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記属性情報取得手段により前記ディレクトリサービスを検索した結果得られた前記外部サービス機器へのアクセス制御に必要なユーザ属性とを組み合わせて第５の認証子を生成し、前記端末装置のアプリケーションは、該第５の認証子を利用することを特徴とする。
【００２１】
上述した課題を解決し、目的を達成するために、請求項１２にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証方法であって、前記端末装置のアクセス制御手段は、ユーザの入力した認証情報に基づいて、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証とを行うステップと、前記第１の認証と前記第２の認証の両方が成功した場合に前記アプリケーションの利用を可能とするステップと、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証の結果得られた第１の認証子を利用するステップと、を含むことを特徴とする。
【００２２】
上述した課題を解決し、目的を達成するために、請求項１３にかかる発明は、請求項１２に記載のユーザ認証方法の各ステップをコンピュータに実行させることを特徴とするコンピュータが実行するためのプログラムである。
【発明の効果】
【００２３】
本発明によれば、端末装置に外部サービスを利用することを前提としたアプリケーションを備え、アクセス制御手段により端末装置に関するアクセス制御を行い、第１の認証手段が端末装置のアプリケーションに対するアクセス制御の認証を行い、外部サービス機器は、端末装置のアプリケーションが利用する外部サービスを提供し、第２の認証手段は外部サービス機器の一部に組み込まれていて、外部サービスの利用時に認証を要求する。アクセス制御手段は、ユーザが入力した認証情報に基づいて第１の認証手段と第２の認証手段の認証を行い、両方の認証が成功するとアプリケーションの利用を可能とする。アプリケーション自身のアクセス制御には、第１の認証手段の結果得られた第１の認証子を利用する。このように、アプリケーションのユーザは、認証情報を入力すると、これに基づいてアクセス制御手段が第１の認証手段と第２の認証手段の認証を行い、両方の認証が成功するとアプリケーションの利用が可能になる。このため、外部サービスで要求される認証を考慮することなく、最低限のログイン操作を行うだけで自動的に必要な手続きが実施され、利用が可能になるという効果を奏する。特に、複数の外部サービスを利用する場合、あるいは使用される外部サービスが動的に変わる場合であっても、その対応を利用者の負担無しに行えるため、管理の手間や設定ミスなどを削減することができる。
【００２４】
また、本発明によれば、端末装置に外部サービスを利用することを前提としたアプリケーションを備え、アクセス制御手段により端末装置に関するアクセス制御を行い、外部サービス機器は、端末装置のアプリケーションが利用する外部サービスを提供し、第２の認証手段は外部サービス機器の一部に組み込まれていて、ユーザ属性が格納されたディレクトリサービスを検索し、属性情報取得手段により外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する。このように、アプリケーションは、ユーザに認証情報を入力させて、外部サービス機器の一部に組み込まれた第２の認証手段に対する認証を行い、認証に成功すると、同じ認証情報を使ってディレクトリサービスへユーザ属性の検索を行い、アプリケーション自身のアクセス制御を行う。これにより、外部サービス機器の第２の認証手段にユーザ認証機能を委ねることで、ユーザを一元管理することができ、認証機能に不足があってもユーザ属性をディレクトリサービスから取得することで、補うことができるという効果を奏する。
【発明を実施するための最良の形態】
【００２５】
以下に添付図面を参照して、この発明にかかるユーザ認証システム、ユーザ認証方法およびコンピュータが実行するためのプログラムの最良な実施の形態を詳細に説明する。
【００２６】
（第１の実施の形態）
図１は、本発明のユーザ認証システムの概略構成を示すブロック図である。図１に示すユーザ認証システムは、プリンタ機能といった外部サービスの利用を前提としたアプリケーション１０を備える端末装置と、その端末装置に関するアクセス制御を行うアクセス制御部１１と、端末装置のアプリケーション１０に対するアクセス制御の認証を行う認証サーバなどの第１の認証部３０と、端末装置のアプリケーション１０が利用する外部サービス２０を提供する外部サービス機器と、外部サービス機器の一部に組み込まれ、外部サービス２０の利用時に認証を要求する第２の認証部２１と、外部サービス２０に関するアクセス制御を行うアクセス制御部２２などによって構成されている。
【００２７】
アプリケーション１０は、事前に設定された設定情報に基づいて端末装置を利用するユーザに対し機能を提供するものである。その際の設定情報としては、外部サービス２０を利用して機能を提供するように指定することが可能である。
【００２８】
アクセス制御部１１は、ユーザがアプリケーション１０にアクセスするためのログイン処理の制御を行うものである。このアクセス制御部１１の特徴は、ユーザの入力した認証情報に基づいて第１の認証部３０と第２の認証部２１の認証手続きが自動的に行われ、両方の認証が成功した場合は、アプリケーション１０へのアクセスは勿論のこと、アプリケーション１０を使って外部サービスの利用も可能となる。また、利用したい外部サービスが複数ある場合であっても、ユーザには最低限のログイン操作で利用できるようになる。
【００２９】
外部サービス２０は、端末装置のアプリケーション１０が利用することを前提としているサービスであり、外部サービス機器により提供される。例えば、プリンタアプリケーションに対するプリンタであり、プリントサービスを提供する場合などが考えられる。
【００３０】
第２の認証部２１は、外部サービス２０の一部として組み込まれた認証手段であって、通常は外部サービス以外で利用することを想定していない。このため、第２の認証部２１は、認証機能を提供するものであるが、そのセキュリティ機能がその装置内に閉じた機能しか提供されない場合、十分なセキュリティ機能と利便性の両方を確保することは難しい。しかし、本発明では、ユーザの入力した認証情報に基づいてアクセス制御部１１が第１の認証部３０と第２の認証部２１の認証手続きを自動的に行い、両方の認証が成功した場合にアプリケーション１０へのアクセスと、アプリケーション１０を使った外部サービス２０の利用を可能とするため、セキュリティ機能と利便性の両方を確保することができる。
【００３１】
アクセス制御部２２は、外部サービス２０にアクセスするためのログイン処理を制御するものである。本発明では、アプリケーション１０のユーザが入力した認証情報に基づいてアクセス制御部１１が第１の認証部３０と第２の認証部２１に対する認証手続きを行い、両方の認証が成功すると、アクセス制御部２２はアプリケーション１０から外部サービスへのアクセスを許可し、アプリケーションが外部サービスを利用することができる。
【００３２】
第１の認証部３０は、認証サーバなどで構成され、ユーザがユーザＩＤやパスワードを入力したユーザ情報に基づいて認証を行う汎用的な認証手段である。本発明では、アプリケーション１０のユーザが入力した認証情報に基づいて第１の認証部３０と第２の認証部２１に対する認証手続きを行い、両方の認証が成功すると、ユーザがアプリケーション１０へアクセスできると共に、そのアプリケーション１０を使い外部サービス２０を利用することができる。ユーザがアプリケーション１０へアクセスする場合は、第１の認証部３０による認証の結果得られた第１の認証子を利用する。
【００３３】
図３は、図１の端末装置のアプリケーションにおける管理画面例を示す図である。第１の実施の形態におけるアプリケーションは、ユーザに一連の機能を提供するため、複数の外部サービスを組み合わせて利用するものである。このため、図３に示す管理画面では、アプリケーション１０が実行するデータフローを簡単に表している。ここでは、例えば、文書データを管理画面のメインフロー上を左から投入すると（Svr(1)Input）、右に流れる過程で様々な処理が行われて必要な情報が付加され（Svr(7)OCR、Svr(8)Search）、最後に外部へ出力される（Svr(2)Output）。
【００３４】
図４は、図３のように設定されたデータフローで参照される外部サービスの一覧表を示す図である。図３のようなデータフローを定義する場合は、図４の一覧表に登録されているサービスの中から選択するだけで、データフローを定義することができる。この外部サービスの一覧表には、外部サービスの名前、機能、接続先ＵＲＬ、認証方式、認証サービスのＵＲＬなどを関連付けられている。
【００３５】
図５は、予め生成しておくユーザ認証システム内の認証方式のリスト例を示す図であり、処理フロー名や認証サービスのＵＲＬと関連づけられている。この認証方式のリストは予め生成しておき、図１のアクセス制御部１１がアプリケーション１０の機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証方式をリストから抽出する抽出手段としての抽出部（図示省略）をさらに備えている。このように、アプリケーション１０の利用開始時に認証処理を行う場合、前記抽出部で抽出された全ての認証方式に対して認証を試みることができるので、利用したい外部サービスが複数あってもユーザは最低限度のログイン操作を行うだけで利用できるようになる。
【００３６】
また、アクセス制御部１１は、アプリケーション１０の機能および動作をカスタマイズする設定情報を検査し、その設定に必要な認証方式をリストから抽出する前記抽出部に加え、その抽出された認証方式と設定情報とを対応付けて記録する記録手段としての記録部（図示省略）をさらに備えていてもよい。このように、アプリケーションの設定によって使用される外部サービスが動的に変わるアプリケーションの場合、必要な認証方式も変化する。しかし、ここでは設定に従った動作を行うのに必要な認証方式を抽出部で抽出し、抽出した認証方式と設定情報とを対応付けて記録部に記録し、その記録部に記録されている全ての認証方式に対して認証を試みるので、利用者の負担無しに行うことが可能となり、管理の手間や設定ミスなどを削減することができる。
【００３７】
図２は、第１の実施の形態にかかる動作を説明するフローチャートである。アプリケーション１０のユーザがログイン処理を開始すると、図２に示す手順で処理が自動的に実行され、その結果として、図２のログイン処理が成功してアプリケーションの利用を開始するか、ログイン失敗かが判明する。端末装置のユーザが外部サービス２０の利用を前提としたアプリケーション１０にアクセスする場合、ログイン処理が行われる。ログイン処理が開始されると、アクセス制御部１１は、図３のように設定されたデータフローのフロー定義情報を図４の一覧表から取り出す（ステップＳ１００）。
【００３８】
ここで、チェックしていない外部サービスが存在するか否かを判断し（ステップＳ１０１）、外部サービスが存在する場合はフロー定義で利用する外部サービス情報を一つ取り出し（ステップＳ１０２）、その外部サービスが第２の認証を要求しているか否かを判断する（ステップＳ１０３）。第２の認証を要求している場合は、認証先として第２の認証をマークし（ステップＳ１０４）、第２の認証を要求していない場合はそのままの状態でステップＳ１０１に戻る。
【００３９】
ステップＳ１０１において、チェックしていない外部サービスが存在しないか、認証先として全てマークし終わった場合は、不図示の端末装置の操作画面にログイン画面を表示する（ステップＳ１０５）。ここで、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第１の認証部３０に対して第１の認証を実施する（ステップＳ１０６）。この第１の認証により得られた第１の認証子は、ユーザがアプリケーションに対してアクセス制御を行う場合に利用する。
【００４０】
第１の認証が成功した場合は（ステップＳ１０７）、ステップＳ１０８に移行して、他に第２の認証部２１などの認証先がマークされているか否かを判断する。他に認証先がある場合は、マークされた認証サービスに対して認証を試みる（ステップＳ１０９）。その結果認証が成功すると（ステップＳ１１０）、ステップＳ１０８に戻り、それ以外に認証先がマークされていないかを判断する。他に認証先が無く、実施すべき認証が全て成功している場合は、アプリケーション１０を使って外部サービス２０を利用することができる
。
【００４１】
しかし、ステップＳ１０７において、第１の認証部３０における認証がエラーになるか、第１の認証が成功しても第２の認証部２１、あるいはそれ以外にマークされた認証部における認証がエラーになった場合は（ステップＳ１１０）、ログイン失敗として処理される。
【００４２】
このように、第１の実施の形態によれば、アプリケーションに対するアクセス制御の認証を行う第１の認証部と、外部サービス機器の一部に組み込まれ、外部サービス利用時に認証を要求する第２の認証部とがあった場合でも、ユーザは最低限のログイン操作を行うだけで両方の認証処理が自動的に行われ、両方の認証が成功した場合にアプリケーションを使って外部サービスを利用することができる。
【００４３】
また、第１の実施の形態によれば、アプリケーションのアクセス制御部は、機能および動作をカスタマイズする設定情報を検査して認証方式のリストを作成し、設定に応じて必要とする認証方式をリストから抽出し、その抽出された全ての認証方式に対して認証を試みるので、利用したい外部サービスが複数あったとしても、ユーザは最低限度のログイン操作を行うだけで利用できるようになる。
【００４４】
さらに、第１の実施の形態によれば、アプリケーションのアクセス制御部は、設定に応じて必要とする認証方式をリストから抽出し、その抽出された認証方式と設定情報とを対応付けて記録するため、設定によって使用される外部サービスが動的に変わるアプリケーションであっても、認証方式と設定情報とが対応付けられ記録された全ての認証方式に対して認証を試みるので、利用者の負担無しに行うことが可能となり、管理の手間や設定ミスなどを削減することができる。
【００４５】
（第２の実施の形態）
第２の実施の形態の特徴は、図１に示した第２の認証部２１をアプリケーションの機能を実行するために必須の認証を行う必須認証手段としての必須認証部と、オプショナルな機能に関する認証を行うオプショナル認証手段としてのオプショナル認証部との２つに分類して処理する点にある。この必須認証部とオプショナル認証部とは、図１には図示していないが、第２の認証部２１内に設けられ、必須認証部に関する認証が失敗した場合は、認証処理を停止させるが、オプショナル認証部に関する認証が失敗したとしても認証処理をスキップさせるだけで、認証処理全体は停止させないようにする。
【００４６】
図６は、第２の実施の形態にかかる動作を説明するフローチャートである。図６のフローチャートは、図２のフローチャートの第２の認証処理動作に関する部分を変更したものである。すなわち、図６のステップＳ２００〜ステップＳ２０３は、図２のステップＳ１０５〜ステップＳ１０８に対応しているが、その後のステップＳ２０４〜ステップＳ２０７における処理が異なっている。
【００４７】
図７は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした管理画面例を示す図である。例えば、管理者は、文書データを入力したり（Svr(1)Input）、最後に外部へ出力したりするサービス（Svr(2)Output）の認証は必須と判断し、入力された文書データを光学読み取りしたり（Svr(7)OCR）、その読み取ったデータに基づいて検索したりする付加的なサービス（Svr(8)Search）については、オプショナルな機能に関する認証と判断したとする。その場合、管理者は、データフローを設計する際に、図７に示すような管理画面上でオプショナルな機能に対しては「Optional」と記入し、それ以外は必須の認証サービスとして明示することができる。
【００４８】
また、図８は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした別の管理画面例を示す図である。図８に示すように、データフローの左右の端点を構成するサービス（Svr(1)Input、Svr(2)Output）については、これを省略することが不可能なため、（×）マークを入れることで必須の認証であることを表し、それ以外のフローの途中に位置するデータ加工などを受け持つサービス（Svr(7)OCR、Svr(8)Search）についてはオプショナルな機能に関する認証として、（×）マークを記入しないことで明示することができる。
【００４９】
さらに、図９は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを外部サービスの持つ属性情報を判定基準として分類した外部サービスの一覧表を示す図である。図９の一覧表では、外部サービスの持つ属性情報を判定基準として必須の認証かオプショナルな機能に関する認証なのかを判定している。判定基準の一例としては、サービスの機能やサービスタイプなどで省略が可能なサービスであるか、省略すると機能が成立しなくなる必須のサービスなのかを判定することで分類することができる。ここでは、サービスの機能とサービスタイプに基づき、基幹サービスである（Svr(1)Input、Svr(2)Output、Svr(9)Output）は必須の認証であり、フィルターである（Svr(7)OCR、Svr(8)Search）はオプショナルな機能に関する認証であると判定される。
【００５０】
そこで、図６のフローチャートを用いて第２の実施の形態にかかる動作を説明する。図６は、図２のステップＳ１０１に続いている。不図示の端末装置の操作画面にログイン画面が表示され（ステップＳ２００）、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第１の認証部３０に対して第１の認証を実施する（ステップＳ２０１）。この第１の認証により得られた第１の認証子は、ユーザがアプリケーションに対してアクセス制御を行う場合に利用される。
【００５１】
第１の認証が成功した場合は（ステップＳ２０２）、ステップＳ２０３に移行して、他に第２の認証部２１などの認証先があるか否かを判断する。他に認証先がある場合は、指定された認証サービスに対して認証を試みる（ステップＳ２０４）。その結果、認証が成功すると（ステップＳ２０５）、ステップＳ２０３に戻り、他に第２の認証先があるか否かが判断される。他に認証先が無く、実施すべき認証が全て成功している場合は、アプリケーション１０を使って外部サービス２０を利用する。
【００５２】
また、ステップＳ２０４において、指定された認証サービスに対して認証を試みた結果、認証エラーになると（ステップＳ２０５）、ステップＳ２０６に移行して第２の認証が必須の認証か否かを判定する。ここで、図７に示すように、管理者によって指定された分類結果、図８に示すように、データフローのどの位置を構成するサービスかといった外部サービスの役割りによる分類結果、あるいは、図９に示すように、サービスの機能やサービスタイプといった外部サービスの持つ属性（カテゴリ情報等）による分類結果などに基づいて判定される。ステップＳ２０６において、必須の認証において認証エラーが生じた場合は、ログイン失敗となり、認証処理を中止する。また、ステップＳ２０２において、第１の認証処理で認証エラーとなった場合も同様にログイン失敗となり、認証処理を中止する。
【００５３】
また、ステップＳ２０６において、オプショナルな機能に関する認証で認証エラーが生じた場合は、認証処理全体をエラーにするのではなく、当該認証に対応したサービスだけを使用しないようにスキップさせ、該当サービスに利用不可マークを記録して、ステップＳ２０３に戻る。
【００５４】
このように、第２の実施の形態によれば、第２の認証がエラーになった場合に一律に認証処理を中止するのではなく、第２の認証が必須の認証であった場合は、認証処理を停止するが、オプショナルな機能に関する認証の場合は、その認証に関わる処理をスキップして認証処理全体は停止させないようにする。このため、複数の外部サービスを利用してユーザに機能を提供するアプリケーションにおいて、全ての外部サービスに権限を持たないと、アプリケーションを全く使えないという不便を解消することができる。また、一部のサービスに関する権限さえ持っていれば、基本的な機能だけは利用できるといった使い方も可能になる。
【００５５】
（第３の実施の形態）
第３の実施の形態の特徴は、第２の認証を要求する外部サービスを利用するアプリケーションがユーザの入力した認証情報に基づいて第２の認証を行い、ログインに成功した場合に、その認証情報に基づいてディレクトリサービスを検索し、ユーザ属性を取得して、そのユーザ属性に基づいてアプリケーション自身のアクセス制御を行う点にある。
【００５６】
図１０は、第３の実施の形態にかかる動作を説明するフローチャートである。図１０のフローチャートは、図２のフローチャートのログイン画面表示後の動作を変更したものである。すなわち、図１０のステップＳ３００は、図２のステップＳ１０５に対応しており、その後のステップＳ３０１〜ステップＳ３０５における処理が異なっている。
【００５７】
第３の実施の形態において、ユーザ属性が格納されたディレクトリサービスは、図１のアプリケーション１０内に持っている。また、属性情報取得手段としてのアクセス制御部１１は、ユーザの入力した認証情報に基づいてディレクトリサービス内を検索し、ユーザの認証情報に対応したユーザ属性が検索できなかった場合は、ログインが失敗となる。外部サービス２０へのアクセス制御に必要なユーザ属性を取得すると、このユーザ属性に基づいてアプリケーション自身のアクセス制御が行われる。
【００５８】
また、第２の認証の結果得られた第２の認証子と、ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、アプリケーションはこの第２および第３の認証子を利用するようにする。
【００５９】
図１１は、第３の認証子の一例を示す図である。図１１に示すように、外部サービス２０に関連した認証結果は、外部認証情報として、新しく作られる認証子の一部として包含されている。その他には、例えば、組織情報、社員区分、メンバーとして登録されている管理グループ名の一覧などが、認証子に含まれているが、これらは、別途ディレクトリサービスから取得することができる。これらはユーザの権限レベルなどを判定するための情報として、認証子から取り出してアプリケーション内部で利用することができる。
【００６０】
そこで、図１０のフローチャートを用いて第３の実施の形態にかかる動作を説明する。図１０は、図２のステップＳ１０１に続いている。不図示の端末装置の操作画面にログイン画面が表示され（ステップＳ３００）、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第２の認証部２１に対して第２の認証を実施する（ステップＳ３０１）。
【００６１】
第２の認証が成功した場合は（ステップＳ３０２）、ステップＳ３０３に移行して、ユーザが入力した認証情報を使いユーザ属性が格納されているディレクトリサービスを検索する（ステップＳ３０３）。検索の結果、アクセス制御に必要なユーザ属性情報が取得できた場合は（ステップＳ３０４でＮＯ）、第２の認証の結果得られた第２の認証子と、ディレクトリサービスの検索結果とを融合させて新たな第３の認証子を作成する（ステップＳ３０５）。アプリケーションは、この第２および第３の認証子を使って利用を開始する。
【００６２】
上記第２の認証の結果がエラーとなった場合（ステップＳ３０２）、およびディレクトリサービスを検索した結果、検索エラーが出た場合は（ステップＳ３０４）、ログイン失敗として認証処理を停止する。
【００６３】
このように、第３の実施の形態によれば、外部サービス２０の第２の認証部２１にユーザ認証機能を委ねることによって、ユーザを一元管理し、その認証機能に不足があった場合でも、ディレクトリサービスを使ってユーザ属性を取得することにより、認証機能の不足を補うことができる。
【００６４】
また、第３の実施の形態によれば、第２の認証結果とユーザの身元情報（ユーザ属性）とを新たな第３の認証子としてまとめることによって、認証機構の機能に違いが生じたとしても、その結果を利用する際に、その差を意識することなく活用することができる。
【００６５】
（第４の実施の形態）
第４の実施の形態の特徴は、上記第１の実施の形態と同様に第１の認証と第２の認証とを行い、両方の認証が成功した後、第２の認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、第１の認証の結果得られた第１の認証子とを融合させて第４の認証子を生成し、アプリケーションはその第４の認証子を利用するようにした点にある。
【００６６】
また、第４の実施の形態の特徴は、上記第３の実施の形態と同様に第２の認証を行って認証が成功した後、第２の認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、属性情報取得手段によってディレクトリサービスを検索した結果得られた外部サービスへのアクセス制御に必要なユーザ情報とを組み合わせて第５の認証子を生成し、アプリケーションはその第５の認証子を利用するようにした点にある。
【００６７】
このように、第４の実施の形態では、認証手続きの結果得られる認証子を用いて、外部サービスを利用したり、ユーザ情報を取得したりするようにする。認証に成功した後、アプリケーションが受け取る認証子（認証証明書）に、認証結果としてアプリケーションが必要とする全ての情報をまとめるようにする。アプリケーションが必要とする情報には、外部サービスへの接続情報やユーザ自身の身元情報などが含まれる。このように、アプリケーションが外部サービスを利用する場合、あるいは、アプリケーション自身でアクセス制御を行う場合には、常に認証子に含まれている情報を利用するよう処理を統一する。
【００６８】
図１２は、外部サービスでユーザ認証機能が提供される場合の提供機能形態をパターン毎に分類した図である。基本機能としては、まずユーザ認証を行い、成功すると実際のサービス機能が利用できるようになるものであり、この点は共通しているが、具体的な設計結果としては色々なパターンで実装されている。
【００６９】
図１２の右側には正規化された機能分割が示され、左側には外部サービスの機能分割の例が示されている。ここでは、左側に示すサービスインターフェイスを右側に示すようなサービスインターフェイスに変換可能であることを示している。アプリケーションは常に、この正規化されたサービスインターフェイスを使えるようになる。
【００７０】
まず、個々のサービスインターフェイスの機能について説明する。login(userName, password) ⇒ Credentialについては、「ユーザが入力した認証情報」と「本人である事を確認できる情報」とを照合して、利用者の識別を行う。この結果得られるCredentialとは、識別された利用者情報の証明書であり、後でアプリケーションなどが利用者情報を利用する際に、その内容が正しいことを確認することができる。
【００７１】
startSession(Credential) ⇒ sessionIdについては、アプリケーションがサービスを繰り返し利用するような場合に、その都度利用者の身元確認をするのは効率が悪いため、最初に身元確認を行った後、サービスがアプリケーションに対して有効期限付きのSessionIdを発行する。サービスは、アプリケーションから提示されたSessionIdの確認だけ行えばよく、ユーザの身元確認を最初から行う必要は無くなる。また、適切に実装を行えばセキュリティ上の脆弱性も生じない。
【００７２】
useService(SessionId, otherParameters)については、サービスが本来提供する機能を代表している。呼び出した結果や、得られる情報はさまざまなので特に個々には記述していない。パラメータとしてSessionIdなどを渡すようになっているが、この部分は、認証を必要とするか、サービスとの間でSessionを使って通信を行っているかで変化する。
【００７３】
続いて、各パターン毎の変換方法について説明する。パターン１では、ユーザ認証を行い、次にその結果（Credential）を持ってアプリケーションとサービスとの間でSessionを確立し、その後、本来のサービス機能が利用できるようになる。これは、最も基本的な機能提供形態であり、認証機能とそれ以外の提供機能が完全に分かれているため、独立した認証サービスを利用する場合（第１の認証）も、このような実装になっていることが多い。正規化されたサービスインターフェイスでは、セッションに関してはインターフェイス上に明確に現れていないが、SessionIdをCredential内に含めてしまうことにより、アプリケーションからSessionを隠蔽して、正規化パターンに合わせることが可能である。
【００７４】
パターン２は、Sessionをベースにしたサービスインターフェイスであるが、認証とセッション開始要求が一つの機能として融合している。このパターンと、正規化パターンとを比較すると、形の上では、やり取りするデータをCredentialからSessionIdに置き換えただけの違いとなっている。しかし、ここで示したCredentialの本来の機能は、認証結果を示すだけであり（改ざん対策などは施す）、そのデータ自体で完結したものである。しかし、SessionIdの方は、サービス側に一時的に記録されたユーザ接続情報への参照情報を意味しているため、データを破棄する際にはサービス側にもそれを伝えて、サービス側のデータも破棄する必要がある。そのため、正規化パターンではlogoutを呼び出してサービス側に伝達するようにしている。
【００７５】
パターン３は、パターン２と呼び出しメソッド名が異なるのみで内容は同じものであるため重複説明を省略する。
【００７６】
パターン４は、サービスとアプリケーションとの間にセッションを持たないインターフェイスとなっている。サービスの提供する機能によってはわざわざセッションを生成する必要の無いケースもある。正規化パターンでは、logoutを呼び出すようになっているが、このパターンのサービスに対しては、logoutに対応して情報を伝達する必要はない。
【００７７】
パターン５は、サービスインターフェイスの仕様として、先にセッションを確立して、その後、ユーザの確認を行う順序となっている。匿名セッションでのサービス利用がある（身元を明かさないでサービスの提供を受ける）場合には、このような手順で機能を提供する場合がある。このような場合でも、SessionIDとCredentialを融合して、正規化を行う事が可能である。
【００７８】
パターン６は、サービスインターフェイスの仕様として、独立した認証機能もSessionの概念も無く、サービス利用時に利用者の身元情報を提示するインターフェイスも考えられる。この場合には、Credential＝認証情報と見なして、インターフェイスの違いを隠蔽することが可能である。logoutに関しては、上記パターン４と同様にサービスに対しては特に伝達する情報はない。
【００７９】
このように、第４の実施の形態によれば、各種外部サービスとその認証機能を利用する際に、認証機能に関する利用方法を統一して扱えるようになったため、アプリケーションは認証に関する共通の手続きを実行することにより、未知の外部アプリケーションであっても同様の手続きにより利用することができる。
【図面の簡単な説明】
【００８０】
【図１】本発明のユーザ認証システムの概略構成を示すブロック図である。
【図２】第１の実施の形態にかかる動作を説明するフローチャートである。
【図３】図１の端末装置のアプリケーションにおける管理画面例を示す図である。
【図４】図３のように設定されたデータフローで参照される外部サービスの一覧表を示す図である。
【図５】予め生成しておくユーザ認証システム内の認証方式のリスト例を示す図である。
【図６】第２の実施の形態にかかる動作を説明するフローチャートである。
【図７】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした管理画面例を示す図である。
【図８】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした別の管理画面例を示す図である。
【図９】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを外部サービスの持つ属性情報を判定基準として分類した外部サービスの一覧表を示す図である。
【図１０】第３の実施の形態にかかる動作を説明するフローチャートである。
【図１１】第３の認証子の一例を示す図である。
【図１２】外部サービスでユーザ認証機能が提供される場合の提供機能形態をパターン毎に分類した図である。
【符号の説明】
【００８１】
１０ アプリケーション
１１ アクセス制御部
２０ 外部サービス
２１ 第２の認証部
２２ アクセス制御部
３０ 第１の認証部
【技術分野】
【０００１】
本発明は、ユーザ認証システム、ユーザ認証方法およびプログラムに関し、詳細には、外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証システム、ユーザ認証方法およびプログラムに関する。
【背景技術】
【０００２】
従来、外部サービスを利用することが前提となっているアプリケーションにおいて、外部サービスが要求するユーザ認証の機構をそのまま使い、アプリケーション自身のアクセス制御も行えるならば、利用者にとってもアプリケーション自身にとっても都合が良く、一般的にＳＳＯ（シングル・サイン・オン）機能という形で利用されている。
【０００３】
ところが、現状では、外部サービスが、一般的なＩＤとパスワードにより認証を行う汎用的なユーザ認証手段（本明細書中では第１の認証手段という）ではなく、外部サービスの一部に組み込まれた認証手段（本明細書中では第２の認証手段という）を提供していることが多い。しかしながら、この第２の認証手段は、外部サービス以外で利用することを必ずしも想定していない。例えば、外部サービスを利用するアプリケーションには、認証結果として誰であるとして特定されたのかが伝達されず、認証に成功したのか失敗したのかしか伝達されないものもある。その結果、アプリケーション側には、認証に成功したユーザか否かの情報しか得られず、認証結果に基づいてきめ細かいアクセス制御機能を実現することは難しい。
【０００４】
また、アプリケーション側でアクセス制御を行うためには、あらかじめ管理者がユーザに対して権限を割り当てておく必要がある。このような機能を実現するためには、候補となるユーザの一覧を取得し、そこからユーザを選んで権限を付与するという手順が必要となる。しかし、外部サービスにはユーザの一覧を提供する機能を持たない認証手段も存在する。
【０００５】
この種の従来例としては、例えば下記に示す特許文献１〜３などがある。
【０００６】
【特許文献１】特開２００２−３３３９２８号公報
【特許文献２】特開２００４−８６４９０号公報
【特許文献３】特開２０００−１０６５５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、このようなユーザ認証システムにあっては、ユーザ認証機構を有し、それに基づいてアクセス制御機能を提供する外部サービスがあったとしても、そのセキュリティ機能が、その装置内に閉じた機能しか提供されない場合には、十分なセキュリティと利便性とを確保することが難しいという問題がある。
【０００８】
また、このような場合、認証手続きとサービス利用手続きとが組み合わさって不可分になっていることが多い。このため、複数の外部サービスを組み合わせて利用する場合には、手続きを「認証」と「サービスの利用」に分離して抽象化して扱えるならば、保守や機能拡張などの面で有利となる。しかし、上記したように個別に最適化された手続きになっている場合は、抽象化が阻害されてしまい、サービス毎に個別の対応が必要になってくるという問題がある。
【０００９】
本発明は、上記に鑑みてなされたものであって、アプリケーションのユーザが外部サービスで必要とされる認証を考慮することなく、ユーザの最低限のログイン操作の中で自動的に必要な認証手続きが実施されて利用することができるユーザ認証システム、ユーザ認証方法、およびコンピュータが実行するためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備える端末装置と、前記端末装置に関するアクセス制御を行うアクセス制御手段と、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証手段と、前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第１の認証手段と前記第２の認証手段の認証を行い、両方の認証が成功した場合に前記アプリケーションの利用を可能とし、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証手段の結果得られた第１の認証子を利用することを特徴とする。
【００１１】
また、請求項２にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証手段を抽出する抽出手段をさらに備え、前記アプリケーションの利用開始時の認証処理において、前記抽出手段で抽出された全ての認証手段に対して認証を試みることを特徴とする。
【００１２】
また、請求項３にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を作成する際に、設定に従った動作を行うのに必要な認証手段を抽出する抽出手段と、該抽出した認証手段と設定情報と対応付けて記録する記録手段とをさらに備え、前記アプリケーションの利用開始時の認証処理において、前記記録手段に記録されている全ての認証手段に対して認証を試みることを特徴とする。
【００１３】
また、請求項４にかかる発明は、請求項１〜３のいずれか一つに記載のユーザ認証システムであって、前記第２の認証手段のうち、機能を実行するために必須の認証を必須認証手段とし、オプショナルな機能に関する認証をオプショナル認証手段として分類し、前記必須認証手段に関する認証が失敗すると認証に関わる処理を停止させるが、前記オプショナル認証手段に関する認証が失敗しても認証に関わる処理をスキップするだけで処理全体を停止させないようにすることを特徴とする。
【００１４】
また、請求項５にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記設定情報をカスタマイズする際に、管理者によって指定できるようにしたことを特徴とする。
【００１５】
また、請求項６にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記外部サービスの属性によって決定されることを特徴とする。
【００１６】
また、請求項７にかかる発明は、請求項４に記載のユーザ認証システムであって、前記必須認証手段と前記オプショナル認証手段との区別は、前記アプリケーションが定義する外部サービスに対して与えられる役割によって決定することを特徴とする。
【００１７】
上述した課題を解決し、目的を達成するために、請求項８にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備える端末装置と、前記端末装置に関するアクセス制御を行うアクセス制御手段と、前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、ユーザ属性が格納されたディレクトリサービスと、前記ディレクトリサービスを検索して、前記外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する属性情報取得手段と、を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第２の認証手段の認証を行い、認証が成功すると前記認証情報を使って前記属性情報取得手段により前記ディレクトリサービスを検索し、前記外部サービス機器へのアクセス制御に必要なユーザ属性を取得してアクセス制御を行うことを特徴とする。
【００１８】
また、請求項９にかかる発明は、請求項８に記載のユーザ認証システムであって、前記第２の認証手段による認証の結果得られた第２の認証子と、前記ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、前記アプリケーションは前記第２および第３の認証子を利用することを特徴とする。
【００１９】
また、請求項１０にかかる発明は、請求項１に記載のユーザ認証システムであって、前記アクセス制御手段は、前記第１の認証手段と前記第２の認証手段の認証を行って両方の認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記第１の認証手段による認証の結果得られた第１の認証子とを組み合わせて第４の認証子を生成し、前記端末装置のアプリケーションは、該第４の認証子を利用することを特徴とする。
【００２０】
また、請求項１１にかかる発明は、請求項８に記載のユーザ認証システムであって、前記アクセス制御手段は、前記第２の認証手段の認証を行って認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記属性情報取得手段により前記ディレクトリサービスを検索した結果得られた前記外部サービス機器へのアクセス制御に必要なユーザ属性とを組み合わせて第５の認証子を生成し、前記端末装置のアプリケーションは、該第５の認証子を利用することを特徴とする。
【００２１】
上述した課題を解決し、目的を達成するために、請求項１２にかかる発明は、外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証方法であって、前記端末装置のアクセス制御手段は、ユーザの入力した認証情報に基づいて、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証とを行うステップと、前記第１の認証と前記第２の認証の両方が成功した場合に前記アプリケーションの利用を可能とするステップと、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証の結果得られた第１の認証子を利用するステップと、を含むことを特徴とする。
【００２２】
上述した課題を解決し、目的を達成するために、請求項１３にかかる発明は、請求項１２に記載のユーザ認証方法の各ステップをコンピュータに実行させることを特徴とするコンピュータが実行するためのプログラムである。
【発明の効果】
【００２３】
本発明によれば、端末装置に外部サービスを利用することを前提としたアプリケーションを備え、アクセス制御手段により端末装置に関するアクセス制御を行い、第１の認証手段が端末装置のアプリケーションに対するアクセス制御の認証を行い、外部サービス機器は、端末装置のアプリケーションが利用する外部サービスを提供し、第２の認証手段は外部サービス機器の一部に組み込まれていて、外部サービスの利用時に認証を要求する。アクセス制御手段は、ユーザが入力した認証情報に基づいて第１の認証手段と第２の認証手段の認証を行い、両方の認証が成功するとアプリケーションの利用を可能とする。アプリケーション自身のアクセス制御には、第１の認証手段の結果得られた第１の認証子を利用する。このように、アプリケーションのユーザは、認証情報を入力すると、これに基づいてアクセス制御手段が第１の認証手段と第２の認証手段の認証を行い、両方の認証が成功するとアプリケーションの利用が可能になる。このため、外部サービスで要求される認証を考慮することなく、最低限のログイン操作を行うだけで自動的に必要な手続きが実施され、利用が可能になるという効果を奏する。特に、複数の外部サービスを利用する場合、あるいは使用される外部サービスが動的に変わる場合であっても、その対応を利用者の負担無しに行えるため、管理の手間や設定ミスなどを削減することができる。
【００２４】
また、本発明によれば、端末装置に外部サービスを利用することを前提としたアプリケーションを備え、アクセス制御手段により端末装置に関するアクセス制御を行い、外部サービス機器は、端末装置のアプリケーションが利用する外部サービスを提供し、第２の認証手段は外部サービス機器の一部に組み込まれていて、ユーザ属性が格納されたディレクトリサービスを検索し、属性情報取得手段により外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する。このように、アプリケーションは、ユーザに認証情報を入力させて、外部サービス機器の一部に組み込まれた第２の認証手段に対する認証を行い、認証に成功すると、同じ認証情報を使ってディレクトリサービスへユーザ属性の検索を行い、アプリケーション自身のアクセス制御を行う。これにより、外部サービス機器の第２の認証手段にユーザ認証機能を委ねることで、ユーザを一元管理することができ、認証機能に不足があってもユーザ属性をディレクトリサービスから取得することで、補うことができるという効果を奏する。
【発明を実施するための最良の形態】
【００２５】
以下に添付図面を参照して、この発明にかかるユーザ認証システム、ユーザ認証方法およびコンピュータが実行するためのプログラムの最良な実施の形態を詳細に説明する。
【００２６】
（第１の実施の形態）
図１は、本発明のユーザ認証システムの概略構成を示すブロック図である。図１に示すユーザ認証システムは、プリンタ機能といった外部サービスの利用を前提としたアプリケーション１０を備える端末装置と、その端末装置に関するアクセス制御を行うアクセス制御部１１と、端末装置のアプリケーション１０に対するアクセス制御の認証を行う認証サーバなどの第１の認証部３０と、端末装置のアプリケーション１０が利用する外部サービス２０を提供する外部サービス機器と、外部サービス機器の一部に組み込まれ、外部サービス２０の利用時に認証を要求する第２の認証部２１と、外部サービス２０に関するアクセス制御を行うアクセス制御部２２などによって構成されている。
【００２７】
アプリケーション１０は、事前に設定された設定情報に基づいて端末装置を利用するユーザに対し機能を提供するものである。その際の設定情報としては、外部サービス２０を利用して機能を提供するように指定することが可能である。
【００２８】
アクセス制御部１１は、ユーザがアプリケーション１０にアクセスするためのログイン処理の制御を行うものである。このアクセス制御部１１の特徴は、ユーザの入力した認証情報に基づいて第１の認証部３０と第２の認証部２１の認証手続きが自動的に行われ、両方の認証が成功した場合は、アプリケーション１０へのアクセスは勿論のこと、アプリケーション１０を使って外部サービスの利用も可能となる。また、利用したい外部サービスが複数ある場合であっても、ユーザには最低限のログイン操作で利用できるようになる。
【００２９】
外部サービス２０は、端末装置のアプリケーション１０が利用することを前提としているサービスであり、外部サービス機器により提供される。例えば、プリンタアプリケーションに対するプリンタであり、プリントサービスを提供する場合などが考えられる。
【００３０】
第２の認証部２１は、外部サービス２０の一部として組み込まれた認証手段であって、通常は外部サービス以外で利用することを想定していない。このため、第２の認証部２１は、認証機能を提供するものであるが、そのセキュリティ機能がその装置内に閉じた機能しか提供されない場合、十分なセキュリティ機能と利便性の両方を確保することは難しい。しかし、本発明では、ユーザの入力した認証情報に基づいてアクセス制御部１１が第１の認証部３０と第２の認証部２１の認証手続きを自動的に行い、両方の認証が成功した場合にアプリケーション１０へのアクセスと、アプリケーション１０を使った外部サービス２０の利用を可能とするため、セキュリティ機能と利便性の両方を確保することができる。
【００３１】
アクセス制御部２２は、外部サービス２０にアクセスするためのログイン処理を制御するものである。本発明では、アプリケーション１０のユーザが入力した認証情報に基づいてアクセス制御部１１が第１の認証部３０と第２の認証部２１に対する認証手続きを行い、両方の認証が成功すると、アクセス制御部２２はアプリケーション１０から外部サービスへのアクセスを許可し、アプリケーションが外部サービスを利用することができる。
【００３２】
第１の認証部３０は、認証サーバなどで構成され、ユーザがユーザＩＤやパスワードを入力したユーザ情報に基づいて認証を行う汎用的な認証手段である。本発明では、アプリケーション１０のユーザが入力した認証情報に基づいて第１の認証部３０と第２の認証部２１に対する認証手続きを行い、両方の認証が成功すると、ユーザがアプリケーション１０へアクセスできると共に、そのアプリケーション１０を使い外部サービス２０を利用することができる。ユーザがアプリケーション１０へアクセスする場合は、第１の認証部３０による認証の結果得られた第１の認証子を利用する。
【００３３】
図３は、図１の端末装置のアプリケーションにおける管理画面例を示す図である。第１の実施の形態におけるアプリケーションは、ユーザに一連の機能を提供するため、複数の外部サービスを組み合わせて利用するものである。このため、図３に示す管理画面では、アプリケーション１０が実行するデータフローを簡単に表している。ここでは、例えば、文書データを管理画面のメインフロー上を左から投入すると（Svr(1)Input）、右に流れる過程で様々な処理が行われて必要な情報が付加され（Svr(7)OCR、Svr(8)Search）、最後に外部へ出力される（Svr(2)Output）。
【００３４】
図４は、図３のように設定されたデータフローで参照される外部サービスの一覧表を示す図である。図３のようなデータフローを定義する場合は、図４の一覧表に登録されているサービスの中から選択するだけで、データフローを定義することができる。この外部サービスの一覧表には、外部サービスの名前、機能、接続先ＵＲＬ、認証方式、認証サービスのＵＲＬなどを関連付けられている。
【００３５】
図５は、予め生成しておくユーザ認証システム内の認証方式のリスト例を示す図であり、処理フロー名や認証サービスのＵＲＬと関連づけられている。この認証方式のリストは予め生成しておき、図１のアクセス制御部１１がアプリケーション１０の機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証方式をリストから抽出する抽出手段としての抽出部（図示省略）をさらに備えている。このように、アプリケーション１０の利用開始時に認証処理を行う場合、前記抽出部で抽出された全ての認証方式に対して認証を試みることができるので、利用したい外部サービスが複数あってもユーザは最低限度のログイン操作を行うだけで利用できるようになる。
【００３６】
また、アクセス制御部１１は、アプリケーション１０の機能および動作をカスタマイズする設定情報を検査し、その設定に必要な認証方式をリストから抽出する前記抽出部に加え、その抽出された認証方式と設定情報とを対応付けて記録する記録手段としての記録部（図示省略）をさらに備えていてもよい。このように、アプリケーションの設定によって使用される外部サービスが動的に変わるアプリケーションの場合、必要な認証方式も変化する。しかし、ここでは設定に従った動作を行うのに必要な認証方式を抽出部で抽出し、抽出した認証方式と設定情報とを対応付けて記録部に記録し、その記録部に記録されている全ての認証方式に対して認証を試みるので、利用者の負担無しに行うことが可能となり、管理の手間や設定ミスなどを削減することができる。
【００３７】
図２は、第１の実施の形態にかかる動作を説明するフローチャートである。アプリケーション１０のユーザがログイン処理を開始すると、図２に示す手順で処理が自動的に実行され、その結果として、図２のログイン処理が成功してアプリケーションの利用を開始するか、ログイン失敗かが判明する。端末装置のユーザが外部サービス２０の利用を前提としたアプリケーション１０にアクセスする場合、ログイン処理が行われる。ログイン処理が開始されると、アクセス制御部１１は、図３のように設定されたデータフローのフロー定義情報を図４の一覧表から取り出す（ステップＳ１００）。
【００３８】
ここで、チェックしていない外部サービスが存在するか否かを判断し（ステップＳ１０１）、外部サービスが存在する場合はフロー定義で利用する外部サービス情報を一つ取り出し（ステップＳ１０２）、その外部サービスが第２の認証を要求しているか否かを判断する（ステップＳ１０３）。第２の認証を要求している場合は、認証先として第２の認証をマークし（ステップＳ１０４）、第２の認証を要求していない場合はそのままの状態でステップＳ１０１に戻る。
【００３９】
ステップＳ１０１において、チェックしていない外部サービスが存在しないか、認証先として全てマークし終わった場合は、不図示の端末装置の操作画面にログイン画面を表示する（ステップＳ１０５）。ここで、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第１の認証部３０に対して第１の認証を実施する（ステップＳ１０６）。この第１の認証により得られた第１の認証子は、ユーザがアプリケーションに対してアクセス制御を行う場合に利用する。
【００４０】
第１の認証が成功した場合は（ステップＳ１０７）、ステップＳ１０８に移行して、他に第２の認証部２１などの認証先がマークされているか否かを判断する。他に認証先がある場合は、マークされた認証サービスに対して認証を試みる（ステップＳ１０９）。その結果認証が成功すると（ステップＳ１１０）、ステップＳ１０８に戻り、それ以外に認証先がマークされていないかを判断する。他に認証先が無く、実施すべき認証が全て成功している場合は、アプリケーション１０を使って外部サービス２０を利用することができる
。
【００４１】
しかし、ステップＳ１０７において、第１の認証部３０における認証がエラーになるか、第１の認証が成功しても第２の認証部２１、あるいはそれ以外にマークされた認証部における認証がエラーになった場合は（ステップＳ１１０）、ログイン失敗として処理される。
【００４２】
このように、第１の実施の形態によれば、アプリケーションに対するアクセス制御の認証を行う第１の認証部と、外部サービス機器の一部に組み込まれ、外部サービス利用時に認証を要求する第２の認証部とがあった場合でも、ユーザは最低限のログイン操作を行うだけで両方の認証処理が自動的に行われ、両方の認証が成功した場合にアプリケーションを使って外部サービスを利用することができる。
【００４３】
また、第１の実施の形態によれば、アプリケーションのアクセス制御部は、機能および動作をカスタマイズする設定情報を検査して認証方式のリストを作成し、設定に応じて必要とする認証方式をリストから抽出し、その抽出された全ての認証方式に対して認証を試みるので、利用したい外部サービスが複数あったとしても、ユーザは最低限度のログイン操作を行うだけで利用できるようになる。
【００４４】
さらに、第１の実施の形態によれば、アプリケーションのアクセス制御部は、設定に応じて必要とする認証方式をリストから抽出し、その抽出された認証方式と設定情報とを対応付けて記録するため、設定によって使用される外部サービスが動的に変わるアプリケーションであっても、認証方式と設定情報とが対応付けられ記録された全ての認証方式に対して認証を試みるので、利用者の負担無しに行うことが可能となり、管理の手間や設定ミスなどを削減することができる。
【００４５】
（第２の実施の形態）
第２の実施の形態の特徴は、図１に示した第２の認証部２１をアプリケーションの機能を実行するために必須の認証を行う必須認証手段としての必須認証部と、オプショナルな機能に関する認証を行うオプショナル認証手段としてのオプショナル認証部との２つに分類して処理する点にある。この必須認証部とオプショナル認証部とは、図１には図示していないが、第２の認証部２１内に設けられ、必須認証部に関する認証が失敗した場合は、認証処理を停止させるが、オプショナル認証部に関する認証が失敗したとしても認証処理をスキップさせるだけで、認証処理全体は停止させないようにする。
【００４６】
図６は、第２の実施の形態にかかる動作を説明するフローチャートである。図６のフローチャートは、図２のフローチャートの第２の認証処理動作に関する部分を変更したものである。すなわち、図６のステップＳ２００〜ステップＳ２０３は、図２のステップＳ１０５〜ステップＳ１０８に対応しているが、その後のステップＳ２０４〜ステップＳ２０７における処理が異なっている。
【００４７】
図７は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした管理画面例を示す図である。例えば、管理者は、文書データを入力したり（Svr(1)Input）、最後に外部へ出力したりするサービス（Svr(2)Output）の認証は必須と判断し、入力された文書データを光学読み取りしたり（Svr(7)OCR）、その読み取ったデータに基づいて検索したりする付加的なサービス（Svr(8)Search）については、オプショナルな機能に関する認証と判断したとする。その場合、管理者は、データフローを設計する際に、図７に示すような管理画面上でオプショナルな機能に対しては「Optional」と記入し、それ以外は必須の認証サービスとして明示することができる。
【００４８】
また、図８は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした別の管理画面例を示す図である。図８に示すように、データフローの左右の端点を構成するサービス（Svr(1)Input、Svr(2)Output）については、これを省略することが不可能なため、（×）マークを入れることで必須の認証であることを表し、それ以外のフローの途中に位置するデータ加工などを受け持つサービス（Svr(7)OCR、Svr(8)Search）についてはオプショナルな機能に関する認証として、（×）マークを記入しないことで明示することができる。
【００４９】
さらに、図９は、管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを外部サービスの持つ属性情報を判定基準として分類した外部サービスの一覧表を示す図である。図９の一覧表では、外部サービスの持つ属性情報を判定基準として必須の認証かオプショナルな機能に関する認証なのかを判定している。判定基準の一例としては、サービスの機能やサービスタイプなどで省略が可能なサービスであるか、省略すると機能が成立しなくなる必須のサービスなのかを判定することで分類することができる。ここでは、サービスの機能とサービスタイプに基づき、基幹サービスである（Svr(1)Input、Svr(2)Output、Svr(9)Output）は必須の認証であり、フィルターである（Svr(7)OCR、Svr(8)Search）はオプショナルな機能に関する認証であると判定される。
【００５０】
そこで、図６のフローチャートを用いて第２の実施の形態にかかる動作を説明する。図６は、図２のステップＳ１０１に続いている。不図示の端末装置の操作画面にログイン画面が表示され（ステップＳ２００）、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第１の認証部３０に対して第１の認証を実施する（ステップＳ２０１）。この第１の認証により得られた第１の認証子は、ユーザがアプリケーションに対してアクセス制御を行う場合に利用される。
【００５１】
第１の認証が成功した場合は（ステップＳ２０２）、ステップＳ２０３に移行して、他に第２の認証部２１などの認証先があるか否かを判断する。他に認証先がある場合は、指定された認証サービスに対して認証を試みる（ステップＳ２０４）。その結果、認証が成功すると（ステップＳ２０５）、ステップＳ２０３に戻り、他に第２の認証先があるか否かが判断される。他に認証先が無く、実施すべき認証が全て成功している場合は、アプリケーション１０を使って外部サービス２０を利用する。
【００５２】
また、ステップＳ２０４において、指定された認証サービスに対して認証を試みた結果、認証エラーになると（ステップＳ２０５）、ステップＳ２０６に移行して第２の認証が必須の認証か否かを判定する。ここで、図７に示すように、管理者によって指定された分類結果、図８に示すように、データフローのどの位置を構成するサービスかといった外部サービスの役割りによる分類結果、あるいは、図９に示すように、サービスの機能やサービスタイプといった外部サービスの持つ属性（カテゴリ情報等）による分類結果などに基づいて判定される。ステップＳ２０６において、必須の認証において認証エラーが生じた場合は、ログイン失敗となり、認証処理を中止する。また、ステップＳ２０２において、第１の認証処理で認証エラーとなった場合も同様にログイン失敗となり、認証処理を中止する。
【００５３】
また、ステップＳ２０６において、オプショナルな機能に関する認証で認証エラーが生じた場合は、認証処理全体をエラーにするのではなく、当該認証に対応したサービスだけを使用しないようにスキップさせ、該当サービスに利用不可マークを記録して、ステップＳ２０３に戻る。
【００５４】
このように、第２の実施の形態によれば、第２の認証がエラーになった場合に一律に認証処理を中止するのではなく、第２の認証が必須の認証であった場合は、認証処理を停止するが、オプショナルな機能に関する認証の場合は、その認証に関わる処理をスキップして認証処理全体は停止させないようにする。このため、複数の外部サービスを利用してユーザに機能を提供するアプリケーションにおいて、全ての外部サービスに権限を持たないと、アプリケーションを全く使えないという不便を解消することができる。また、一部のサービスに関する権限さえ持っていれば、基本的な機能だけは利用できるといった使い方も可能になる。
【００５５】
（第３の実施の形態）
第３の実施の形態の特徴は、第２の認証を要求する外部サービスを利用するアプリケーションがユーザの入力した認証情報に基づいて第２の認証を行い、ログインに成功した場合に、その認証情報に基づいてディレクトリサービスを検索し、ユーザ属性を取得して、そのユーザ属性に基づいてアプリケーション自身のアクセス制御を行う点にある。
【００５６】
図１０は、第３の実施の形態にかかる動作を説明するフローチャートである。図１０のフローチャートは、図２のフローチャートのログイン画面表示後の動作を変更したものである。すなわち、図１０のステップＳ３００は、図２のステップＳ１０５に対応しており、その後のステップＳ３０１〜ステップＳ３０５における処理が異なっている。
【００５７】
第３の実施の形態において、ユーザ属性が格納されたディレクトリサービスは、図１のアプリケーション１０内に持っている。また、属性情報取得手段としてのアクセス制御部１１は、ユーザの入力した認証情報に基づいてディレクトリサービス内を検索し、ユーザの認証情報に対応したユーザ属性が検索できなかった場合は、ログインが失敗となる。外部サービス２０へのアクセス制御に必要なユーザ属性を取得すると、このユーザ属性に基づいてアプリケーション自身のアクセス制御が行われる。
【００５８】
また、第２の認証の結果得られた第２の認証子と、ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、アプリケーションはこの第２および第３の認証子を利用するようにする。
【００５９】
図１１は、第３の認証子の一例を示す図である。図１１に示すように、外部サービス２０に関連した認証結果は、外部認証情報として、新しく作られる認証子の一部として包含されている。その他には、例えば、組織情報、社員区分、メンバーとして登録されている管理グループ名の一覧などが、認証子に含まれているが、これらは、別途ディレクトリサービスから取得することができる。これらはユーザの権限レベルなどを判定するための情報として、認証子から取り出してアプリケーション内部で利用することができる。
【００６０】
そこで、図１０のフローチャートを用いて第３の実施の形態にかかる動作を説明する。図１０は、図２のステップＳ１０１に続いている。不図示の端末装置の操作画面にログイン画面が表示され（ステップＳ３００）、ユーザはログインに必要なユーザＩＤとパスワードを入力すると、アクセス制御部１１は、この入力情報を使って第２の認証部２１に対して第２の認証を実施する（ステップＳ３０１）。
【００６１】
第２の認証が成功した場合は（ステップＳ３０２）、ステップＳ３０３に移行して、ユーザが入力した認証情報を使いユーザ属性が格納されているディレクトリサービスを検索する（ステップＳ３０３）。検索の結果、アクセス制御に必要なユーザ属性情報が取得できた場合は（ステップＳ３０４でＮＯ）、第２の認証の結果得られた第２の認証子と、ディレクトリサービスの検索結果とを融合させて新たな第３の認証子を作成する（ステップＳ３０５）。アプリケーションは、この第２および第３の認証子を使って利用を開始する。
【００６２】
上記第２の認証の結果がエラーとなった場合（ステップＳ３０２）、およびディレクトリサービスを検索した結果、検索エラーが出た場合は（ステップＳ３０４）、ログイン失敗として認証処理を停止する。
【００６３】
このように、第３の実施の形態によれば、外部サービス２０の第２の認証部２１にユーザ認証機能を委ねることによって、ユーザを一元管理し、その認証機能に不足があった場合でも、ディレクトリサービスを使ってユーザ属性を取得することにより、認証機能の不足を補うことができる。
【００６４】
また、第３の実施の形態によれば、第２の認証結果とユーザの身元情報（ユーザ属性）とを新たな第３の認証子としてまとめることによって、認証機構の機能に違いが生じたとしても、その結果を利用する際に、その差を意識することなく活用することができる。
【００６５】
（第４の実施の形態）
第４の実施の形態の特徴は、上記第１の実施の形態と同様に第１の認証と第２の認証とを行い、両方の認証が成功した後、第２の認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、第１の認証の結果得られた第１の認証子とを融合させて第４の認証子を生成し、アプリケーションはその第４の認証子を利用するようにした点にある。
【００６６】
また、第４の実施の形態の特徴は、上記第３の実施の形態と同様に第２の認証を行って認証が成功した後、第２の認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、属性情報取得手段によってディレクトリサービスを検索した結果得られた外部サービスへのアクセス制御に必要なユーザ情報とを組み合わせて第５の認証子を生成し、アプリケーションはその第５の認証子を利用するようにした点にある。
【００６７】
このように、第４の実施の形態では、認証手続きの結果得られる認証子を用いて、外部サービスを利用したり、ユーザ情報を取得したりするようにする。認証に成功した後、アプリケーションが受け取る認証子（認証証明書）に、認証結果としてアプリケーションが必要とする全ての情報をまとめるようにする。アプリケーションが必要とする情報には、外部サービスへの接続情報やユーザ自身の身元情報などが含まれる。このように、アプリケーションが外部サービスを利用する場合、あるいは、アプリケーション自身でアクセス制御を行う場合には、常に認証子に含まれている情報を利用するよう処理を統一する。
【００６８】
図１２は、外部サービスでユーザ認証機能が提供される場合の提供機能形態をパターン毎に分類した図である。基本機能としては、まずユーザ認証を行い、成功すると実際のサービス機能が利用できるようになるものであり、この点は共通しているが、具体的な設計結果としては色々なパターンで実装されている。
【００６９】
図１２の右側には正規化された機能分割が示され、左側には外部サービスの機能分割の例が示されている。ここでは、左側に示すサービスインターフェイスを右側に示すようなサービスインターフェイスに変換可能であることを示している。アプリケーションは常に、この正規化されたサービスインターフェイスを使えるようになる。
【００７０】
まず、個々のサービスインターフェイスの機能について説明する。login(userName, password) ⇒ Credentialについては、「ユーザが入力した認証情報」と「本人である事を確認できる情報」とを照合して、利用者の識別を行う。この結果得られるCredentialとは、識別された利用者情報の証明書であり、後でアプリケーションなどが利用者情報を利用する際に、その内容が正しいことを確認することができる。
【００７１】
startSession(Credential) ⇒ sessionIdについては、アプリケーションがサービスを繰り返し利用するような場合に、その都度利用者の身元確認をするのは効率が悪いため、最初に身元確認を行った後、サービスがアプリケーションに対して有効期限付きのSessionIdを発行する。サービスは、アプリケーションから提示されたSessionIdの確認だけ行えばよく、ユーザの身元確認を最初から行う必要は無くなる。また、適切に実装を行えばセキュリティ上の脆弱性も生じない。
【００７２】
useService(SessionId, otherParameters)については、サービスが本来提供する機能を代表している。呼び出した結果や、得られる情報はさまざまなので特に個々には記述していない。パラメータとしてSessionIdなどを渡すようになっているが、この部分は、認証を必要とするか、サービスとの間でSessionを使って通信を行っているかで変化する。
【００７３】
続いて、各パターン毎の変換方法について説明する。パターン１では、ユーザ認証を行い、次にその結果（Credential）を持ってアプリケーションとサービスとの間でSessionを確立し、その後、本来のサービス機能が利用できるようになる。これは、最も基本的な機能提供形態であり、認証機能とそれ以外の提供機能が完全に分かれているため、独立した認証サービスを利用する場合（第１の認証）も、このような実装になっていることが多い。正規化されたサービスインターフェイスでは、セッションに関してはインターフェイス上に明確に現れていないが、SessionIdをCredential内に含めてしまうことにより、アプリケーションからSessionを隠蔽して、正規化パターンに合わせることが可能である。
【００７４】
パターン２は、Sessionをベースにしたサービスインターフェイスであるが、認証とセッション開始要求が一つの機能として融合している。このパターンと、正規化パターンとを比較すると、形の上では、やり取りするデータをCredentialからSessionIdに置き換えただけの違いとなっている。しかし、ここで示したCredentialの本来の機能は、認証結果を示すだけであり（改ざん対策などは施す）、そのデータ自体で完結したものである。しかし、SessionIdの方は、サービス側に一時的に記録されたユーザ接続情報への参照情報を意味しているため、データを破棄する際にはサービス側にもそれを伝えて、サービス側のデータも破棄する必要がある。そのため、正規化パターンではlogoutを呼び出してサービス側に伝達するようにしている。
【００７５】
パターン３は、パターン２と呼び出しメソッド名が異なるのみで内容は同じものであるため重複説明を省略する。
【００７６】
パターン４は、サービスとアプリケーションとの間にセッションを持たないインターフェイスとなっている。サービスの提供する機能によってはわざわざセッションを生成する必要の無いケースもある。正規化パターンでは、logoutを呼び出すようになっているが、このパターンのサービスに対しては、logoutに対応して情報を伝達する必要はない。
【００７７】
パターン５は、サービスインターフェイスの仕様として、先にセッションを確立して、その後、ユーザの確認を行う順序となっている。匿名セッションでのサービス利用がある（身元を明かさないでサービスの提供を受ける）場合には、このような手順で機能を提供する場合がある。このような場合でも、SessionIDとCredentialを融合して、正規化を行う事が可能である。
【００７８】
パターン６は、サービスインターフェイスの仕様として、独立した認証機能もSessionの概念も無く、サービス利用時に利用者の身元情報を提示するインターフェイスも考えられる。この場合には、Credential＝認証情報と見なして、インターフェイスの違いを隠蔽することが可能である。logoutに関しては、上記パターン４と同様にサービスに対しては特に伝達する情報はない。
【００７９】
このように、第４の実施の形態によれば、各種外部サービスとその認証機能を利用する際に、認証機能に関する利用方法を統一して扱えるようになったため、アプリケーションは認証に関する共通の手続きを実行することにより、未知の外部アプリケーションであっても同様の手続きにより利用することができる。
【図面の簡単な説明】
【００８０】
【図１】本発明のユーザ認証システムの概略構成を示すブロック図である。
【図２】第１の実施の形態にかかる動作を説明するフローチャートである。
【図３】図１の端末装置のアプリケーションにおける管理画面例を示す図である。
【図４】図３のように設定されたデータフローで参照される外部サービスの一覧表を示す図である。
【図５】予め生成しておくユーザ認証システム内の認証方式のリスト例を示す図である。
【図６】第２の実施の形態にかかる動作を説明するフローチャートである。
【図７】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした管理画面例を示す図である。
【図８】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを明示的に分類できるようにした別の管理画面例を示す図である。
【図９】管理者がデータフローを設計する際に必須の認証かオプショナルな機能に関する認証かを外部サービスの持つ属性情報を判定基準として分類した外部サービスの一覧表を示す図である。
【図１０】第３の実施の形態にかかる動作を説明するフローチャートである。
【図１１】第３の認証子の一例を示す図である。
【図１２】外部サービスでユーザ認証機能が提供される場合の提供機能形態をパターン毎に分類した図である。
【符号の説明】
【００８１】
１０ アプリケーション
１１ アクセス制御部
２０ 外部サービス
２１ 第２の認証部
２２ アクセス制御部
３０ 第１の認証部
【特許請求の範囲】
【請求項１】
外部サービスを利用することを前提としたアプリケーションを備える端末装置と、
前記端末装置に関するアクセス制御を行うアクセス制御手段と、
前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証手段と、
前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、
前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、
を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第１の認証手段と前記第２の認証手段の認証を行い、両方の認証が成功した場合に前記アプリケーションの利用を可能とし、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証手段の結果得られた第１の認証子を利用することを特徴とするユーザ認証システム。
【請求項２】
前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証手段を抽出する抽出手段をさらに備え、
前記アプリケーションの利用開始時の認証処理において、前記抽出手段で抽出された全ての認証手段に対して認証を試みることを特徴とする請求項１に記載のユーザ認証システム。
【請求項３】
前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を作成する際に、設定に従った動作を行うのに必要な認証手段を抽出する抽出手段と、該抽出した認証手段と設定情報と対応付けて記録する記録手段とをさらに備え、
前記アプリケーションの利用開始時の認証処理において、前記記録手段に記録されている全ての認証手段に対して認証を試みることを特徴とする請求項１に記載のユーザ認証システム。
【請求項４】
前記第２の認証手段のうち、機能を実行するために必須の認証を必須認証手段とし、オプショナルな機能に関する認証をオプショナル認証手段として分類し、
前記必須認証手段に関する認証が失敗すると認証に関わる処理を停止させるが、前記オプショナル認証手段に関する認証が失敗しても認証に関わる処理をスキップするだけで処理全体を停止させないようにすることを特徴とする請求項１〜３のいずれか一つに記載のユーザ認証システム。
【請求項５】
前記必須認証手段と前記オプショナル認証手段との区別は、前記設定情報をカスタマイズする際に、管理者によって指定できるようにしたことを特徴とする請求項４に記載のユーザ認証システム。
【請求項６】
前記必須認証手段と前記オプショナル認証手段との区別は、前記外部サービスの属性によって決定されることを特徴とする請求項４に記載のユーザ認証システム。
【請求項７】
前記必須認証手段と前記オプショナル認証手段との区別は、前記アプリケーションが定義する外部サービスに対して与えられる役割によって決定することを特徴とする請求項４に記載のユーザ認証システム。
【請求項８】
外部サービスを利用することを前提としたアプリケーションを備える端末装置と、
前記端末装置に関するアクセス制御を行うアクセス制御手段と、
前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、
前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、
ユーザ属性が格納されたディレクトリサービスと、
前記ディレクトリサービスを検索して、前記外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する属性情報取得手段と、
を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第２の認証手段の認証を行い、認証が成功すると前記認証情報を使って前記属性情報取得手段により前記ディレクトリサービスを検索し、前記外部サービス機器へのアクセス制御に必要なユーザ属性を取得してアクセス制御を行うことを特徴とするユーザ認証システム。
【請求項９】
前記第２の認証手段による認証の結果得られた第２の認証子と、前記ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、
前記アプリケーションは前記第２および第３の認証子を利用することを特徴とする請求項８に記載のユーザ認証システム。
【請求項１０】
前記アクセス制御手段は、前記第１の認証手段と前記第２の認証手段の認証を行って両方の認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記第１の認証手段による認証の結果得られた第１の認証子とを組み合わせて第４の認証子を生成し、
前記端末装置のアプリケーションは、該第４の認証子を利用することを特徴とする請求項１に記載のユーザ認証システム。
【請求項１１】
前記アクセス制御手段は、前記第２の認証手段の認証を行って認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記属性情報取得手段により前記ディレクトリサービスを検索した結果得られた前記外部サービス機器へのアクセス制御に必要なユーザ属性とを組み合わせて第５の認証子を生成し、
前記端末装置のアプリケーションは、該第５の認証子を利用することを特徴とする請求項８に記載のユーザ認証システム。
【請求項１２】
外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証方法であって、
前記端末装置のアクセス制御手段は、ユーザの入力した認証情報に基づいて、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証とを行うステップと、
前記第１の認証と前記第２の認証の両方が成功した場合に前記アプリケーションの利用を可能とするステップと、
前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証の結果得られた第１の認証子を利用するステップと、
を含むことを特徴とするユーザ認証方法。
【請求項１３】
請求項１２に記載のユーザ認証方法の各ステップをコンピュータに実行させることを特徴とするコンピュータが実行するためのプログラム。
【請求項１】
外部サービスを利用することを前提としたアプリケーションを備える端末装置と、
前記端末装置に関するアクセス制御を行うアクセス制御手段と、
前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証手段と、
前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、
前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、
を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第１の認証手段と前記第２の認証手段の認証を行い、両方の認証が成功した場合に前記アプリケーションの利用を可能とし、前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証手段の結果得られた第１の認証子を利用することを特徴とするユーザ認証システム。
【請求項２】
前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を検査し、その設定において必要な認証手段を抽出する抽出手段をさらに備え、
前記アプリケーションの利用開始時の認証処理において、前記抽出手段で抽出された全ての認証手段に対して認証を試みることを特徴とする請求項１に記載のユーザ認証システム。
【請求項３】
前記アクセス制御手段は、前記アプリケーションの機能および動作をカスタマイズする設定情報を作成する際に、設定に従った動作を行うのに必要な認証手段を抽出する抽出手段と、該抽出した認証手段と設定情報と対応付けて記録する記録手段とをさらに備え、
前記アプリケーションの利用開始時の認証処理において、前記記録手段に記録されている全ての認証手段に対して認証を試みることを特徴とする請求項１に記載のユーザ認証システム。
【請求項４】
前記第２の認証手段のうち、機能を実行するために必須の認証を必須認証手段とし、オプショナルな機能に関する認証をオプショナル認証手段として分類し、
前記必須認証手段に関する認証が失敗すると認証に関わる処理を停止させるが、前記オプショナル認証手段に関する認証が失敗しても認証に関わる処理をスキップするだけで処理全体を停止させないようにすることを特徴とする請求項１〜３のいずれか一つに記載のユーザ認証システム。
【請求項５】
前記必須認証手段と前記オプショナル認証手段との区別は、前記設定情報をカスタマイズする際に、管理者によって指定できるようにしたことを特徴とする請求項４に記載のユーザ認証システム。
【請求項６】
前記必須認証手段と前記オプショナル認証手段との区別は、前記外部サービスの属性によって決定されることを特徴とする請求項４に記載のユーザ認証システム。
【請求項７】
前記必須認証手段と前記オプショナル認証手段との区別は、前記アプリケーションが定義する外部サービスに対して与えられる役割によって決定することを特徴とする請求項４に記載のユーザ認証システム。
【請求項８】
外部サービスを利用することを前提としたアプリケーションを備える端末装置と、
前記端末装置に関するアクセス制御を行うアクセス制御手段と、
前記端末装置のアプリケーションが利用する外部サービスを提供する外部サービス機器と、
前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証手段と、
ユーザ属性が格納されたディレクトリサービスと、
前記ディレクトリサービスを検索して、前記外部サービス機器に対するアクセス制御に必要なユーザ属性を取得する属性情報取得手段と、
を備え、前記アクセス制御手段は、ユーザの入力した認証情報に基づいて前記第２の認証手段の認証を行い、認証が成功すると前記認証情報を使って前記属性情報取得手段により前記ディレクトリサービスを検索し、前記外部サービス機器へのアクセス制御に必要なユーザ属性を取得してアクセス制御を行うことを特徴とするユーザ認証システム。
【請求項９】
前記第２の認証手段による認証の結果得られた第２の認証子と、前記ディレクトリサービスを検索した結果得られたユーザ属性とを組み合わせて第３の認証子を新たに作成し、
前記アプリケーションは前記第２および第３の認証子を利用することを特徴とする請求項８に記載のユーザ認証システム。
【請求項１０】
前記アクセス制御手段は、前記第１の認証手段と前記第２の認証手段の認証を行って両方の認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記第１の認証手段による認証の結果得られた第１の認証子とを組み合わせて第４の認証子を生成し、
前記端末装置のアプリケーションは、該第４の認証子を利用することを特徴とする請求項１に記載のユーザ認証システム。
【請求項１１】
前記アクセス制御手段は、前記第２の認証手段の認証を行って認証が成功した後、前記第２の認証手段による認証の結果得られた第２の認証子と、認証後のセッション確立手続きで得られた外部サービスへの接続情報と、前記属性情報取得手段により前記ディレクトリサービスを検索した結果得られた前記外部サービス機器へのアクセス制御に必要なユーザ属性とを組み合わせて第５の認証子を生成し、
前記端末装置のアプリケーションは、該第５の認証子を利用することを特徴とする請求項８に記載のユーザ認証システム。
【請求項１２】
外部サービスを利用することを前提としたアプリケーションを備えた端末装置のユーザ認証方法であって、
前記端末装置のアクセス制御手段は、ユーザの入力した認証情報に基づいて、前記端末装置のアプリケーションに対するアクセス制御の認証を行う第１の認証と、前記外部サービス機器の一部に組み込まれ、外部サービスの利用時に認証を要求する第２の認証とを行うステップと、
前記第１の認証と前記第２の認証の両方が成功した場合に前記アプリケーションの利用を可能とするステップと、
前記アプリケーション自身のアクセス制御を行う場合に前記第１の認証の結果得られた第１の認証子を利用するステップと、
を含むことを特徴とするユーザ認証方法。
【請求項１３】
請求項１２に記載のユーザ認証方法の各ステップをコンピュータに実行させることを特徴とするコンピュータが実行するためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−２２３７３９（Ｐ２００９−２２３７３９Ａ）
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願番号】特願２００８−６８９８７（Ｐ２００８−６８９８７）
【出願日】平成２０年３月１８日（２００８．３．１８）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２１年１０月１日（２００９．１０．１）
【国際特許分類】
【出願日】平成２０年３月１８日（２００８．３．１８）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]