JP6287213B2 - 代行ログイン装置、端末、制御方法およびプログラム - Google Patents

Description

本発明は、あるユーザの権限を他のユーザに委譲する技術に関する。

例えば、あるユーザ（以下、「第１のユーザ」と記載する）と、当該ユーザとは別のユーザ（以下、「第２のユーザ」と記載する）とが、社内アプリケーションを利用して共に業務を遂行する状況を想定する。社内アプリケーションには、社内の端末からでないとログインできない状況を想定する。

第１のユーザは、社内の端末を介して、第１のユーザの識別情報および認証情報を用いてアプリケーションにログインする。これにより、第１のユーザは第１のユーザの権限によってアプリケーションにログインすることになる。第２のユーザは、社内の端末を介して、第２のユーザの識別情報および認証情報を用いてアプリケーションにログインする。これにより、第２のユーザは第２のユーザの権限によってアプリケーションにログインすることになる。

ここで例えば、第２のユーザが急病等で急遽出社できなくなり、当該アプリケーションにログインすることができなくなった場合を想定する。第２のユーザの権限でなければ遂行できない急ぎの業務がある場合、例えば、第２のユーザの識別情報および認証情報を第１のユーザに開示し、第１のユーザが第２のユーザの権限で当該アプリケーションにログインして、第２のユーザの代わりに業務を継続することが考えられる。

しかし、あるユーザの認証情報を他のユーザに対して開示することは、セキュリティ上の問題がある。

このような問題を解決するため、あるユーザの権限を他のユーザに安全に委譲する技術が知られている。特許文献１はこのような技術の一例を開示する。特許文献１が開示する技術によれば、権限を委譲する側のユーザ（第２のユーザ）が権限を委譲される側のユーザ（第１のユーザ）に対して「代理人許可チケット」を送信する。第２のユーザから代行人許可チケットを受け取った第１のユーザは、当該チケットに基づいて、第２のユーザの権限を用いてアプリケーションにログインする。

特開２０１２−２３８０３６

特許文献１が開示する技術を用いて権限委譲を実現する場合、権限を委譲する側のユーザが、権限を委譲される側のユーザに対して、あらかじめ代行人許可チケットを送信しておく必要がある。例えば上述した例において、第１のユーザ（権限を委譲される側のユーザ）が第２のユーザ（権限を委譲する側のユーザ）から権限を委譲して欲しいと考えた場合、第２のユーザが第１のユーザにあらかじめ代行人許可チケットを送信していなければ、第１のユーザは第２のユーザから適切に権限を委譲してもらうことができない。しかし、第２のユーザが急病等で急遽出社できなくなった場合などを想定すると、あらかじめ第２のユーザが第１のユーザに対して代行人許可チケットを送信しておくことは現実的でない。

本発明は、権限を委譲する側（以下、「ログインを代行される側」と記載する）のユーザの認証情報を、権限を委譲される側（以下、「ログインを代行する側」と記載する）のユーザに対して開示することなしに、権限委譲を実現することを一つの目的とする。

また本発明は、ログインを代行する側のユーザがログインを代行される側のユーザに権限の委譲を要求したことに応じて、権限が迅速に委譲されるような技術を提供することを一つの目的とする。

本発明の第１の側面は、第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付ける受付手段と、前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼する承認依頼手段と、前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする代行ログイン手段と、を備える代行ログイン装置である。

本発明の第２の側面は、コンピュータが、第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付け、前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼し、前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする、制御方法である。

本発明の第３の側面は、コンピュータに、第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付ける処理と、前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼する処理と、前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする処理と、を実行させるプログラムである。

また、本発明の目的は、上記のプログラムが格納されたコンピュータ読み取り可能な記録媒体によっても達成される。

本発明は、ログインを代行される側のユーザの認証情報を、ログインを代行する側のユーザに対して開示することなしに、権限委譲を実現することができる。また本発明は、ログインを代行する側のユーザがログインを代行される側のユーザに権限の委譲を要求したことに応じて、権限が迅速に委譲されるような技術を提供することができる。

本発明における、第１の実施形態にかかる代行ログインシステム１０００の概要を説明する図である。 本発明における、第１の実施形態にかかる代行ログインシステム１０００の動作を説明するシーケンス図である。 本発明における、第１の実施形態にかかる代行ログインシステム１０００の動作を説明するシーケンス図である。 本発明における、第１の実施形態にかかる代行ログイン装置３００の構成を示すブロック図である。 本発明における、第１の端末１００に表示される受付画面の一例を示す図である。 本発明における、第１の実施形態にかかる認証情報管理テーブル３１１が記憶する情報の一例を示す図である。 本発明における、第１の実施形態にかかる端末情報テーブル３２１が記憶する情報の一例を示す図である。 本発明における、第１の実施形態にかかるＡＰ認証情報管理テーブル３４１が記憶する情報の一例を示す図である。 本発明における、第１の実施形態にかかる第２の端末２００の構成を示すブロック図である。 本発明における、表示部２１０に表示される承認依頼画面の一例を示す図である。 本発明における、代行ログイン装置３００のハードウェア構成の一例を示す図である。 本発明における、第２の端末２００のハードウェア構成の一例を示す図である。 本発明における、第２の実施形態にかかる代行ログインシステム１０００Ａの概要を説明する図である。 本発明における、第２の実施形態にかかる第１の端末１００に表示される受付画面の一例を示す図である。 本発明における、第２の実施形態にかかる表示部２１０に表示される承認依頼画面の一例を示す図である。 本発明における、第３の実施形態にかかる代行ログインシステム１０００Ｂの概要を説明する図である。 本発明における、第３の実施形態にかかるセッション管理テーブル３５１が記憶する情報の一例を示す図である。 本発明における、第３の実施形態にかかる代行ログイン装置３００Ｂの動作を説明するフローチャートである。 本発明における、第３の実施形態にかかる代行ログイン装置３００Ｂの動作を説明するフローチャートである。 本発明における、第４の実施形態にかかる代行ログインシステム１０００Ｃの概要を説明する図である。

以下、本発明の実施形態について図面を参照して詳細に説明する。

＜第１の実施形態＞
第１のユーザが、アプリケーション４１０に第２のユーザの権限でログインする場合を例に、第１の実施形態にかかる代行ログインシステム１０００の詳細を説明する。第１のユーザとは、アプリケーション４１０へのログインを代行する側のユーザである。第２のユーザとは、アプリケーション４１０へのログインを代行される側のユーザである。

（構成の概略の説明）
図１は、第１の実施形態にかかる代行ログインシステム１０００の概要を説明するブロック図である。図１に示すように、代行ログインシステム１０００は、第１の端末１００と、第２の端末２００と、代行ログイン装置３００と、情報処理装置４００とを含む。

第１の端末１００および第２の端末２００は、通信ネットワーク（以下「ネットワーク」と記載する）を介して代行ログイン装置３００と通信可能に接続される。また、情報処理装置４００は、ネットワークを介して代行ログイン装置３００と通信可能に接続される。

第１の端末１００は、第１のユーザが操作する端末である。第２の端末２００は、第２のユーザが操作する端末である。理解を容易にするため、第１の端末１００は、例えば第１のユーザが社内で用いる端末と考えるとわかりやすい。第２の端末２００は、例えば第２のユーザが操作する携帯端末と考えるとわかりやすい。当然、第１の端末１００および第２の端末２００はこれらの具体例には限定されない。

情報処理装置４００は、一つまたは複数のアプリケーション（ＡＰ）４１０を提供する。以下、複数のアプリケーション４１０を互いに区別する必要がある場合は、アプリケーション４１０Ａ、アプリケーション４１０Ｂ・・・と記載する。

アプリケーション４１０は、第１のユーザの識別情報および認証情報を受け付けた場合、
第１のユーザのログイン処理を行う。アプリケーション４１０は、第２のユーザの識別情報および認証情報を受け付けた場合、第２のユーザのログイン処理を行う。

（動作の概略の説明）
代行ログインシステム１０００の動作の概略を、図２および図３を用いて説明する。図２は、第１のユーザが、アプリケーション４１０に第２のユーザの権限によってログインする際の、代行ログインシステム１０００の動作を説明するシーケンス図である。

第１の端末１００は、第１のユーザの識別情報、第１のユーザの認証情報および第２のユーザの識別情報の入力を第１のユーザから受け付ける（ステップＳ１０１）。第１の端末１００は、ステップＳ１０１において受け付けた情報を代行ログイン装置３００に送信する（ステップＳ１０２）。

代行ログイン装置３００は、第１の端末１００から、第１のユーザの識別情報、第１のユーザの認証情報および第２のユーザの識別情報を受信する。代行ログイン装置３００は、第２の端末２００宛に「承認依頼」のリクエストを送信する（ステップＳ１０３）。「承認依頼」とは、第１のユーザが第２のユーザの代わりにアプリケーション４１０にログインすることについて、第２のユーザの承認を求めることである。言い換えると、「承認依頼」とは、第１のユーザがアプリケーション４１０に第２のユーザの権限によってログインすることについて、第２のユーザの承認を求めることである。

第２の端末２００は、代行ログイン装置３００からの承認依頼を受けて、第２の端末２００が備えるディスプレイ（不図示）に、承認依頼画面を表示する（ステップＳ１０４）。第２のユーザは、第２の端末２００に表示された承認依頼画面を見て、依頼された内容を承認するか否かを判断する。すなわち第２のユーザは、第１のユーザが自身（第２のユーザ）の権限によってアプリケーション４１０にログインしてよいか否かを判断する。第２の端末２００は、承認結果の入力を第２のユーザから受け付ける（ステップＳ１０５）。第２の端末２００は、第２のユーザから受け付けた承認結果を、代行ログイン装置３００に送信する（ステップＳ１０６）。

代行ログイン装置３００は、第２の端末２００から承認結果を受信する。代行ログイン装置３００は、第２の端末２００から「依頼を承認する」旨を表す承認結果を受信した場合、第２のユーザの識別情報および第２のユーザの認証情報を用いて、アプリケーション４１０にログインする（ステップＳ１０７）。第２のユーザの識別情報および第２のユーザの認証情報は、あらかじめ代行ログイン装置３００の内部に記憶されていてもよいし、代行ログイン装置３００からアクセス可能な記憶媒体に記憶されていてもよい。

図３は、第１のユーザが、アプリケーション４１０に第２のユーザの権限によってログインした後の、代行ログインシステム１０００の動作を説明するシーケンス図である。第１の端末１００は、アプリケーション４１０に対するリクエストを代行ログイン装置３００に送信する（ステップＳ２０１）。代行ログイン装置３００は、第１の端末１００から受信したリクエストをアプリケーション４１０に転送する（ステップＳ２０２）。アプリケーション４１０はリクエストに対するレスポンスを代行ログイン装置３００に送信する（ステップＳ２０３）。代行ログイン装置３００は、アプリケーション４１０から受信したレスポンスを第１の端末１００に転送する（ステップＳ２０４）。

（構成の詳細な説明）
次に、第１の実施形態にかかる代行ログインシステム１０００の詳細な構成を説明する。図４は、図１に示す代行ログイン装置３００の詳細を説明するブロック図である。図４に示すように、代行ログイン装置３００は、受付部３１０と、承認依頼部３２０と、承認受付部３３０と、代行ログイン部３４０と、を備える。代行ログイン装置３００はさらに、認証情報管理テーブル３１１と、端末情報テーブル３２１と、ＡＰ認証情報管理テーブル３４１と、を備える。各テーブルは、代行ログイン装置３００からアクセス可能な外部装置に実装されていてもよい。

受付部３１０は、第１の端末１００に表示される受付画面を介して、第１のユーザの識別情報、第１のユーザの認証情報および第２のユーザの識別情報の入力を受け付ける。図５は、受付画面の一例を示す図である。図５に示す画面を第１の端末１００のディスプレイ（不図示）に表示させる機能は、第１の端末１００側に実装されていてもよいし、受付部３１０の機能として実装されていてもよい。

第１のユーザは、第１のユーザの識別情報、第１のユーザの認証情報、および、第２のユーザの識別情報を図５に示す画面に入力する。第１のユーザは、ログインしたいアプリケーション４１０の名称を図５に示す画面に入力してもよい。図５に示す「ログインユーザＩＤ」は、第１のユーザの識別情報に相当する情報である。図５に示す「パスワード」は、第１のユーザの認証情報に相当する情報である。図５に示す「代行対象ユーザのＩＤ（Identifier）」は、第２のユーザの識別情報に相当する情報である。図５に示す「アプリケーション名」は、ログインしたいアプリケーション４１０の名称に相当する情報である。

図４を参照する説明に戻る。受付部３１０は、第１のユーザの識別情報および第１のユーザの認証情報に基づいて、第１のユーザの代行ログイン装置３００に対するログイン処理を実行する。以下、受付部３１０が実行するログイン処理について説明する。受付部３１０は、第１のユーザの識別情報に基づいて、認証情報管理テーブル３１１を参照する。受付部３１０は、受け付けた第１のユーザの認証情報と、認証情報管理テーブル３１１に記憶されている第１のユーザの認証情報とを比較することにより、第１のユーザのログイン処理を行う。

図６は、認証情報管理テーブル３１１が記憶する情報の一例を説明する図である。図６に示すように、認証情報管理テーブル３１１は、ユーザの識別情報と、当該ユーザの認証情報とを関連付けて記憶する。認証情報管理テーブル３１１が記憶する識別情報は、代行ログイン装置３００がユーザを識別するための情報である。認証情報管理テーブル３１１が記憶する認証情報は、代行ログイン装置３００がユーザを認証するための情報である。

図４を参照する説明に戻る。承認依頼部３２０は、第２のユーザの識別情報に基づいて、端末情報テーブル３２１を参照し、第２の端末にアクセスするためのアドレスを取得する。
承認依頼部３２０は、第１のユーザが、アプリケーション４１０に第２のユーザの権限によってログインすることについての承認依頼を、当該アドレス宛に送信する。

図７は、端末情報テーブル３２１が記憶する情報の一例を示す図である。図７に示すように、端末情報テーブル３２１は、ユーザの識別情報と、当該ユーザが操作する端末にアクセスするための情報とを関連付けて記憶する。「ユーザが操作する端末にアクセスするための情報」は、例えば、当該端末のＩＰ（Internet Protocol）アドレス、ＵＲＬ(Uniform Resource Locator)、ユーザのメールアドレスまたはユーザの電話番号などである。端末情報テーブル３２１は、端末の名称を併せて記憶していてもよい。図７に示す「デバイス名」は、端末の名称に相当する情報である。図７に示す「アクセスＵＲＬ」は、「ユーザが操作する端末にアクセスするための情報」に相当する情報である。

図４を参照する説明に戻る。承認受付部３３０は、第２の端末２００から、承認依頼に対する返信を受信する。

代行ログイン部３４０は、承認受付部３３０が「依頼を承認する」旨の承認結果を受信した場合、ＡＰ認証情報管理テーブル３４１を参照し、第２のユーザがアプリケーション４１０にログインするための、第２のユーザの識別情報および第２のユーザの認証情報を取得する。代行ログイン部３４０は、取得した第２のユーザの識別情報および第２のユーザの認証情報を用いて、アプリケーション４１０にログインリクエストを送信する。代行ログイン部３４０は、承認受付部３３０が「依頼を承認しない」旨を表す承認結果を受信した場合、アプリケーション４１０にログインリクエストを送信することはしない。

図８は、ＡＰ認証情報管理テーブル３４１が記憶する情報の一例を示す図である。図８に示すように、ＡＰ認証情報管理テーブル３４１は、代行ログイン装置３００においてユーザを識別するための情報と、アプリケーション４１０の名前と、アプリケーション４１０においてユーザを識別するための情報と、アプリケーション４１０においてユーザを認証するための情報と、を関連付けて記憶する。

代行ログイン部３４０は、例えば識別情報「B-00001」で識別されるユーザ（ユーザＢ）の識別情報および認証情報を用いてアプリケーション４１０Ｂにログインする場合、アプリケーション４１０ＢにログインするためのユーザＢの識別情報「qwerty」と、アプリケーション４１０ＢにログインするためのユーザＢの認証情報「passw0rd」とを取得する。

なお、代行ログイン装置３００においてユーザを識別または認証するための情報と、アプリケーション４１０においてユーザを識別または認証するための情報とは、互いに同一であっても異なっていてもよい。

図９は、図１に示す第２の端末２００の詳細を説明するブロック図である。図９に示すように、第２の端末２００は、表示部２１０と、操作受付部２２０と、承認結果送信部２３０とを備える。

表示部２１０は、承認依頼部３２０からの承認依頼を受けて、第２の端末２００のディスプレイに承認依頼画面を表示する。図１０は、承認依頼画面の一例を示す図である。

図１０に示すように、承認依頼画面は、第１のユーザが、アプリケーション４１０に第２のユーザの権限によってログインすることについて、第２のユーザに対して承認を依頼する画面である。承認依頼画面は、少なくとも、第１のユーザを識別する情報を表示する。承認依頼画面は、ログイン対象のアプリケーション４１０の名称を表示してもよい。

図１０に示す画面を表示部２１０に表示させる機能は、第２の端末２００に実装されていてもよいし、承認依頼部３２０の機能として実装されていてもよい。

第２のユーザは、図１０に示す承認依頼画面を見て、第１のユーザが自分（第２のユーザ）の権限によってアプリケーション４１０にログインすることを、承認するか否かを判断する。第２のユーザは、判断した結果（承認結果）を承認依頼画面に入力する。操作受付部２２０は、第２のユーザから承認結果の入力（すなわち、承認するか、承認しないか）を受け付ける。

承認結果送信部２３０は操作受付部２２０が受け付けた承認結果を承認受付部３３０に送信する。

（代行ログイン装置３００を実現するハードウェア構成の一例）
図１１は、代行ログイン装置３００を実現するハードウェア構成の一例を示すブロック図である。代行ログイン装置３００を構成するハードウェアは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１、メモリ３２、記憶装置３３、通信インターフェース（Ｉ／Ｆ）３４を備える。代行ログイン装置３００は、入力装置３５または出力装置３６を備えていてもよい。代行ログイン装置３００の機能は、例えばＣＰＵ３１が、メモリ３２に読み出されたコンピュータプログラム（ソフトウェアプログラム、以下単に「プログラム」と記載する）を実行することにより実現される。実行に際して、ＣＰＵ３１は、通信インターフェース３４、入力装置３５および出力装置３６を適宜制御する。

尚、本実施形態および後述する各実施形態を例として説明される本発明は、係るプログラムが格納されたコンパクトディスク等の不揮発性の記憶媒体３８によっても構成される。記憶媒体３８が格納するプログラムは、例えばドライブ装置３７により読み出される。

代行ログイン装置３００が実行する通信は、例えばＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が提供する機能を使ってアプリケーションプログラムが通信インターフェース３４を制御することによって実現される。代行ログイン装置３００は、２つ以上の物理的に分離した装置が有線または無線で接続されることによって構成されていてもよい。

図１１に示すハードウェア構成例は、後述する各実施形態にも適用可能である。なお、代行ログイン装置３００は専用の装置であってもよい。なお、代行ログイン装置３００およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

（第２の端末２００を実現するハードウェア構成の一例）
図１２は、第２の端末２００を実現するハードウェア構成の一例を示すブロック図である。第２の端末２００を構成するハードウェアは、例えば、ＣＰＵ２１、メモリ２２、記憶装置２３、通信インターフェース（Ｉ／Ｆ）２４、入力装置３５および出力装置３６を備える。第２の端末２００の機能は、例えばＣＰＵ２１が、メモリ２２に読み出されたコンピュータプログラム（ソフトウェアプログラム、以下単に「プログラム」と記載する）を実行することにより実現される。実行に際して、ＣＰＵ２１は、通信インターフェース２４、入力装置２５および出力装置２６を適宜制御する。

第２の端末２００が実行する通信は、例えばＯＳが提供する機能を使ってアプリケーションプログラムが通信インターフェース２４を制御することによって実現される。入力装置２５は、例えばキーボード、マウスまたはタッチパネルである。出力装置２６は、例えばディスプレイである。

図１２に示すハードウェア構成例は、後述する各実施形態にも適用可能である。ななお、第２の端末２００およびその各機能ブロックのハードウェア構成は、上述の構成に限定されない。

（第１の実施形態の効果）
第１の実施形態にかかる代行ログイン装置３００によれば、第２のユーザの認証情報を、第１のユーザに開示することなしに、第２のユーザの権限を第１のユーザに委譲することができる。その理由は、第２のユーザの認証情報はＡＰ認証情報管理テーブル３４１に格納されており、第１のユーザはＡＰ認証情報管理テーブル３４１が記憶する第２のユーザの認証情報を参照することはできないからである。

また、第１の実施形態にかかる代行ログイン装置３００によれば、第１のユーザが第２のユーザに対して権限の委譲を要求したことに応じて、第２のユーザの権限は第１のユーザに迅速に委譲される。その理由は、代行ログインシステム１０００が以下のように構成されるからである。すなわち、第１のユーザが代行ログイン装置３００を経由して第２のユーザに対して承認依頼を求め、第２のユーザが当該依頼された内容を承認すると、代行ログイン装置３００が第２のユーザの権限によってアプリケーション４１０にログインするよう構成されるからである。

更に、第１の実施形態にかかる代行ログイン装置３００によれば、第１のユーザは自身がアプリケーション４１０にアカウントを持っていなくても、第２のユーザの代わりにアプリケーション４１０に代行ログインできる。

更に、第１の実施形態にかかる代行ログイン装置３００によれば、アプリケーション４１０側は何ら特別な処理を実行しなくてもよい。言い換えると、代行ログイン装置３００と連携するための特別な機能をアプリケーション４１０が有していなくても、代行ログイン装置３００とアプリケーション４１０とが互いに連携して動作することができる。これにより、任意のアプリケーション４１０に対して代行ログイン装置３００を利用することができる。その理由は、代行ログイン装置３００は第２のユーザの識別情報および認証情報を用いてアプリケーション４１０にログインするため、アプリケーション４１０から見ると、実際に第２のユーザがログインしているようにしか見えないからである。すなわち、アプリケーション４１０は、第２のユーザのログインが代行ログインであることを意識しなくてよい。

＜第２の実施形態＞
次に、上述した第１の実施形態を基本とする第２の実施形態について説明する。図１１は、第２の実施形態にかかる代行ログインシステム１０００Ａの構成を説明するブロック図である。図１または図４に示した構成と実質的に同一の構成については、同様の符号を付与し、説明を省略する。

図１３に示すように、代行ログインシステム１０００Ａは、第１の実施形態における代行ログインシステム１０００と比較して、代行ログイン装置３００に代えて代行ログイン装置３００Ａを備える。

図１１に示すように、第２の実施形態にかかる代行ログイン装置３００Ａは、第１の実施形態にかかる代行ログイン装置３００と比較して、受付部３１０に代えて受付部３１０Ａを備え、承認依頼部３２０に代えて承認依頼部３２０Ａを備える。

（受付部３１０Ａの説明）
受付部３１０Ａは、第１の受付処理または第２の受付処理を実行する。第１のユーザは、受付部３１０Ａに第１の受付処理を実行させるかあるいは第２の受付処理を実行させるかを選択する。

（第１の受付処理の説明）
第１の受付処理は、第１の実施形態において既に説明した処理である。第１のユーザが受付部３１０Ａに第１の受付処理を実行させることを選択した場合、第１の端末１００には例えば図５に示す画面が表示される。第１の受付処理においては、受付部３１０Ａは、図５に示す画面を介して、第１のユーザの識別情報、第１のユーザの認証情報および第２のユーザの識別情報の入力を受け付ける。受付部３１０は、第１のユーザの識別情報および第１のユーザの認証情報に基づいて、第１のユーザの代行ログイン装置３００に対するログイン処理を実行する。以上、第１の受付処理について説明した。

（第２の受付処理の説明）
第２の受付処理は、第１の受付処理とは異なる受付処理である。第１のユーザが受付部３１０Ａに第２の受付処理を実行させることを選択した場合、第１の端末１００には例えば図１４に示す画面が表示される。図１４は、第２の受付処理において第１の端末１００に表示される画面の一例を示す図である。なお、図１４に示す画面を第１の端末１００のディスプレイに表示させる機能は、第１の端末１００側に実装されていてもよいし、受付部３１０Ａの機能として実装されていてもよい。

受付部３１０Ａは、図１４に示す画面を介して、第１のユーザのユーザ名等、および、第２のユーザの識別情報を受け付ける。受付部３１０Ａは、代行ログインしたいアプリケーション４１０の指定を受け付けてもよい。図１４に示す「ログインユーザ名」は、第１のユーザのユーザ名等に相当する情報である。ユーザ名は、例えば第１のユーザの本名であってもよいし、任意の文字列であってもよい。

図１４に示す「代行対象ユーザのＩＤ」は、第２のユーザの識別情報に相当する情報である。図１４に示す「アプリケーション名」は、ログインしたいアプリケーション４１０の名称に相当する情報である。また、受付部３１０Ａは図１４に示す画面を介して、テキストによる第１のユーザからのコメント等を受け付けてもよい。この場合、第１のユーザは、自身（第１のユーザ）と第２のユーザとの間でしか知り得ないような文言、すなわち自分を証明するような文言をコメントとして入力することが好ましい。

第２の受付処理においては、受付部３１０Ａは第１のユーザの代行ログイン装置３００に対するログイン処理は実行しない。以上、第２の受付処理について説明した。

（承認依頼部３２０Ａの説明）
承認依頼部３２０Ａは、受付部３１０Ａが第１の受付処理を実行したか、あるいは、第２の受付処理を実行したかに応じて、互いに異なる態様で、第２の端末２００に承認依頼を送信する。

承認依頼部３２０Ａは、第１のユーザが、代行ログイン装置３００により認証されたユーザであるか否かが、第２のユーザにとって認識可能な態様で、第２の端末２００に承認依頼を送信することが好ましい。

まずは、受付部３１０Ａが第１の受付処理を実行した場合の承認依頼部３２０Ａの動作を説明する。この場合、第１のユーザは、代行ログイン装置３００が認証したユーザである。すなわち、第１のユーザが不審なユーザではないことが保障されている。受付部３１０Ａが第１の受付処理を実行した場合、例えば図１０に示すような承認依頼画面が、表示部２１０に表示される。

次に、受付部３１０Ａが第２の受付処理を実行した場合の承認依頼部３２０Ａの動作を説明する。この場合、第１のユーザは、第１のユーザは認証されていないユーザということになる。すなわち、第１のユーザが不審な人物である危険性が否定できない。この場合、第２のユーザは、代行ログインを承認するか否かを注意して判断するべきである。受付部３１０Ａが第２の受付処理を実行した場合、例えば図１５に示すような承認依頼画面が、表示部２１０に表示される。

図１５に示す例では、第１のユーザ（Suzuki Taro）が代行ログイン装置３００により認証されたユーザではないことが画面に明示されている。表示部２１０は、図１５に示す画面において、受付部３１０Ａが図１４に示す画面にて第１のユーザから受け付けたコメントを併せて表示してもよい。図１５に示す画面を表示部２１０に表示させる機能は、第２の端末２００に実装されていてもよいし、承認依頼部３２０Ａの機能として実装されていてもよい。

承認依頼部３２０Ａは、受付部３１０Ａが第１の受付処理を実行した場合と第２の受付処理を実行した場合とで、例えば、承認依頼画面の文字の色を変える、着信音を変える、または、着信の際のバイブレーションのリズムを変える、などのように動作してもよい。このように承認依頼部３２０Ａは、受付部３１０Ａが第１の受付処理を実行した場合と第２の受付処理を実行した場合との違いを、第２のユーザが認識可能な態様で、承認依頼を送信する。

（第２の実施形態の効果）
第２の実施形態にかかる代行ログイン装置３００Ａによれば、第１のユーザが代行ログイン装置３００にアカウントを有していなくても、第２のユーザに対して承認依頼を送信することができる。

第２の実施形態にかかる代行ログイン装置３００Ａによれば、第２のユーザは、第１のユーザが不審な人物でないかどうかを注意しながら、依頼された内容を承認するか拒否するかを判断することができる。その理由は、受付部３１０Ａが第１の受付処理を実行した場合（すなわち、第１のユーザが認証されている場合）と、受付部３１０Ａが第２の受付処理を実行した場合（すなわち、第１のユーザが認証されていない場合）とで、承認依頼部３２０Ａは、互いに異なる態様で承認依頼のためのリクエストを送信するからである。第２のユーザは、例えば承認依頼画面を確認することで、第１のユーザが認証されたユーザであるのか認証されていないユーザであるのかを認識することができる。第２のユーザは、第１のユーザが認証されていないユーザである場合、例えば承認依頼画面に表示された第１のユーザのコメント等を確認することにより、第１のユーザが不審なユーザでないかどうかを判断してもよい。

＜第３の実施形態＞
次に、上述した第１の実施形態または第２の実施形態を基本とする第３の実施形態について説明する。図１６は、第３の実施形態にかかる代行ログインシステム１０００Ｂの構成を説明するブロック図である。図１、図４または図１３に示した構成と実質的に同一の構成については、同様の符号を付与し、説明を省略する。

図１６に示すように、代行ログインシステム１０００Ｂは、第１の実施形態における代行ログインシステム１０００と比較して、代行ログイン装置３００に代えて代行ログイン装置３００Ｂを備える。

図１６に示すように、代行ログイン装置３００Ｂは、第１の実施形態にかかる代行ログイン装置３００と比較して、セッション管理部３５０Ｂと、セッション管理テーブル３５１Ｂとを更に備える。

セッション管理部３５０Ｂは、受付部３１０がアプリケーション４１０から受信したレスポンスを第１の端末１００に転送する際、アプリケーション４１０が発行した第２のユーザのセッション情報を第１のユーザのセッション情報に置換する。セッション管理部３５０は、受付部３１０が第１の端末１００から受信したリクエストをアプリケーション４１０に転送する際、第１のユーザのセッション情報を第２のユーザのセッション情報に置換する。

セッション管理部３５０は、セッションのタイムアウト時間を、アプリケーション４１０が管理するセッションタイムアウト時間とは別に管理してもよい。第２のユーザが第１のユーザにアプリケーション４１０にログインする権限を委譲した場合、第１のユーザが無制限にアプリケーション４１０にログインできてしまうとセキュリティ上の問題がある。そこで例えば、アプリケーション４１０が管理するセッションタイムアウト時間よりも短いセッションタイムアウト時間をセッション管理部３５０に設定する。こうすることにより、第１のユーザが第２のユーザの権限によってアプリケーション４１０を操作できる時間を代行ログイン装置３００が独自に管理することができる。

なお、セッション管理部３５０が管理するセッションタイムアウト時間は、第２のユーザが指定してもよい。例えば表示部２１０に表示される承認依頼画面を介して、第２のユーザからセッションタイムアウト時間の指定を受け付けてもよい。

また、代行ログイン装置３００は、第１のユーザが第２のユーザの権限によってアプリケーション４１０を操作できる時間を、セッション以外の方法で管理してもよい。例えば、第１のユーザがアプリケーション４１０にログインしてから所定時間経過した後は、受付部３１０がリクエストおよびレスポンスを転送しないようにするように構成されていてもよい。

図１７は、セッション管理テーブル３５１が記憶する情報の一例を示す図である。図１７に示すように、セッション管理テーブル３５１は、第１のユーザの識別情報と、アプリケーション４１０が発行したセッション情報と、代行セッション情報と、第１のユーザの最終アクセス時刻と、を関連付けて記憶する。

次に、第３の実施形態にかかる代行ログイン装置３００Ｂの動作の一例を図１８および図１９を用いて説明する。図１８および図１９は、代行ログイン装置３００Ｂの動作の一例を説明するフローチャートである。

受付部３１０は、第１の端末１００から第１のユーザの識別情報、第１のユーザの認証情報および第２のユーザの識別情報の入力を受け付ける（ステップＳ１０１）。セッション管理部３５０Ｂは、セッション管理テーブル３５１を参照して、第１のユーザのセッション情報があるかどうかを確認する（ステップＳ１０２）。

第１のユーザのセッション情報がない場合（ステップＳ１０２においてＮＯ）、受付部３１０は第１のユーザの認証処理を実行する（ステップＳ１０３）。

図１９は、受付部３１０が実行する認証処理の詳細を説明するフローチャートである。受付部３１０は、認証情報管理テーブル３１１を参照する（ステップＳ２０１）。受付部３１０が受け付けた第１のユーザの識別情報が認証情報管理テーブル３１１に記憶されている場合（ステップＳ２０２においてＹＥＳ）、受付部３１０は、受け付けた第１のユーザの認証情報と、認証情報管理テーブル３１１に記憶されている第１のユーザの認証情報とを比較する（ステップＳ２０３）。両者が一致する場合（ステップＳ２０３においてＹＥＳ）、受付部３１０は第１の受付処理の実行を終了し、ステップＳ１０４に進む。受付部３１０が受け付けた第１のユーザの識別情報が記憶されていない場合（ステップＳ２０２においてＮＯ）、受付部３１０は第２の受付処理を終了し、ステップＳ１０４に進む。受け付けた第１のユーザの認証情報と、認証情報管理テーブル３１１に記憶されている第１のユーザの認証情報とが一致しない場合（ステップＳ２０３においてＮＯ）、代行ログイン処理は失敗したとして処理を終了する（ステップＳ２０４）。

承認依頼部３２０は、受付部３１０から第２のユーザの識別情報を取得する（ステップＳ１０４）。承認依頼部３２０は、第２のユーザの識別情報に基づいて端末情報テーブル３２１を参照し、第２の端末２００のアドレスを取得する（ステップＳ１０５）。承認依頼部３２０が第２の端末２００のアドレスを取得できない場合（ステップＳ１０５においてＮＯ）、代行ログインに失敗したとして処理を終了する（ステップＳ１１２）。承認依頼部３２０が第２の端末２００のアドレスを取得できた場合（ステップＳ１０５においてＹＥＳ）、承認依頼部３２０は、第２の端末２００に対して承認依頼を行う（ステップＳ１０６）。承認受付部３３０が第２の端末２００から承認する旨の返答を受け付けた場合（ステップＳ１０７においてＹＥＳ）、代行ログイン部３４０は第２のユーザの識別情報および第２のユーザの認証情報を用いてアプリケーション４１０にログインする（ステップＳ１０８）。承認受付部３３０が第２の端末２００から承認しない旨の返答を受け付けた場合（ステップＳ１０７においてＮＯ）、代行ログインに失敗したとして処理を終了する（ステップＳ１１２）。

受付部３１０は、アプリケーション４１０からレスポンスを受信する。セッション管理部３５０Ｂは、アプリケーション４１０が発行したセッション情報を第１のユーザのセッション情報に置換する。受付部３１０は、レスポンスを第１の端末１００に転送する（ステップＳ１０９）。

第１のユーザのセッション情報がある場合（ステップＳ１０２においてＹＥＳ）、セッション管理部３５０Ｂは、セッション管理テーブル３５１が記憶する最終アクセス時刻と、セッションタイムアウト時間とに基づいて、セッションタイムアウト時間が経過しているか否かを確認する（ステップＳ１１０）。セッションタイムアウト時間が経過している場合（ステップＳ１１０においてＹＥＳ）、セッション管理部３５０Ｂは、第１の端末１００のディスプレイに、セッションタイムアウトが発生した旨を示す画面を表示するとともに、ログイン画面（図５または図１４）を表示する。セッションタイムアウト時間が経過していない場合（ステップＳ１１０においてＮＯ）、セッション管理部３５０Ｂは、リクエストのセッション情報を第１のユーザのセッション情報から第２のユーザのセッション情報に置換して、リクエストをアプリケーション４１０に転送する（ステップＳ１０９）。

（第３の実施形態の効果）
第３の実施形態にかかる代行ログイン装置３００Ｂは、第１または第２の実施形態にかかる代行ログイン装置３００と比較して、更に安全な代行ログイン装置を提供することができる。その理由は、代行ログイン装置３００Ｂは、第１のユーザが第２のユーザの権限によってアプリケーション４１０を操作できる期間を、代行ログイン装置３００Ｂ自身で管理することができるからである。

＜第４の実施形態＞
図２０は、第４の実施形態にかかる代行ログイン装置３００Ｃの構成を示すブロック図である。図２０に示すように、代行ログイン装置３００Ｃは、受付部３１０Ｃと、承認依頼部３２０Ｃと、代行ログイン部３４０Ｃとを備える。

受付部３１０Ｃは、第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付ける。

承認依頼部３２０Ｃは、前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼する。

代行ログイン部３４０Ｃは、前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする。

＜その他の実施形態＞
第１の端末１００と代行ログイン装置３００とは、同一の端末であってもよい。例えば、代行ログイン装置３００に相当する機能が、代行ログインアプリケーションとして第１の端末１００にインストールされていてもよい。この場合、認証情報管理テーブル３１１、端末情報テーブル３２１およびＡＰ認証情報管理テーブル３４１は、第１の端末１００と通信可能に接続された外部の記憶装置に実装されることが好ましい。また、情報処理装置４００と代行ログイン装置３００とが同一の端末であってもよい。

第２の端末２００は、例えば、携帯電話、スマートホンまたはタブレット端末等の携帯端末であってもよい。第２の端末２００は、例えば、指紋認証つきスマートデバイスであってもよい。こうすることで、第２の端末２００を操作するユーザが必ずデバイスの所有者本人（第２のユーザ）あることが保障され、成りすましを防ぐことができる。これにより、代行ログインシステム１０００のセキュリティを強化することができる。

認証情報はパスワードには限定されない。認証情報は、例えば指紋等の情報であってもよい。

代行ログインシステム１０００は、第２のユーザの識別情報とアプリケーション４１０を指定する情報とをあらかじめ関連付けて管理していてもよい。これにより、受付部３１０が第２のユーザの識別情報を受け付けた際に、受付部３１０がアプリケーション４１０を指定する情報を受け付けなくても、代行ログインシステム１０００は、どのアプリケーション４１０に代行ログインすべきかを決定することができる。

上述した各実施の形態は、適宜組み合わせて実施されることが可能である。

各ブロック図に示したブロック分けは、説明の便宜上から表された構成である。各実施形態を例に説明された本発明は、その実装に際して、各ブロック図に示した構成には限定されない。

また、動作の説明においては、複数の動作を順番に説明したが、その複数の動作の順番は支障のない範囲で変更してもよい。また、これら複数の動作は、それぞれ別々のタイミングで実行されるとは限らない。たとえば、ある動作の実行中に他の動作が発生したり、ある動作と他の動作との実行タイミングが部分的にないし全部において重複したりしてもよい。

さらに、各動作の説明においては、発明の理解を容易にするため、ある動作が他の動作の契機になるように記載したが、その記載はある動作と他の動作の関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障のない範囲で変更してもよい。

以上、本発明を実施するための形態について説明したが、上記実施の形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更、改良され得ると共に、本発明にはその等価物も含まれる。

本発明は、あるユーザの権限を他のユーザに委譲する技術に応用することができる。例えば日々の業務の中で、ウェブサービスを利用して作業をしていたある担当者が急遽出社できなくなったが、作業は継続させたい、といったような場合がある。しかしながら、ウェブサービスの利用においては、作業の進捗や個人に紐づいているデータを参照するためには、その担当者アカウントでの認証処理が必要となる。従来、こういったケースで作業継続を行うための一般的な手段としては、継続作業を行う者へアカウント情報を開示する必要があり、セキュリティ面で危険が伴っていた。

大規模災害が発生した際、インフルエンザのパンデミックが発生した際などに、本発明を利用することで、該当事象に巻き込まれたユーザから安全に認証情報を委譲できる。

例えば本発明は、代行機能を持たないグループウェアを利用している企業で、他者のスケジュールを代行入力したいというような場合に利用できる。

２１ ＣＰＵ
２２ メモリ
２３ 記憶装置
２４ 通信インターフェース
２５ 入力装置
２６ 出力装置
２７ ドライブ装置
２８ 記憶媒体
３１ ＣＰＵ
３２ メモリ
３３ 記憶装置
３４ 通信インターフェース
３５ 入力装置
３６ 出力装置
３７ ドライブ装置
３８ 記憶媒体
１００ 第１の端末
２００ 第２の端末
２１０ 表示部
２２０ 操作受付部
２３０ 承認結果送信部
３００ 代行ログイン装置
３１０ 受付部
３２０ 承認依頼部
３３０ 承認受付部
３４０ 代行ログイン部
３５０ セッション管理部
４００ 情報処理装置
４１０ アプリケーション
１０００ 代行ログインシステム

Claims (10)

1. 第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付ける受付手段と、
   前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼する承認依頼手段と、
   前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする代行ログイン手段と、
   を備える代行ログイン装置。
2. 前記代行ログイン手段が前記アプリケーションにログインすることに成功した後、
   前記受付手段は、
   前記第１のユーザから前記第１の端末を介して、前記アプリケーションに対するリクエストを受け付けるのに応じて、前記リクエストを前記アプリケーションに転送し、
   前記リクエストに対するレスポンスを前記アプリケーションから受け付けるのに応じて、前記レスポンスを前記第１の端末に転送する、
   請求項１に記載の代行ログイン装置。
3. セッション管理手段を更に備え、
   前記セッション管理手段は、
   前記受付手段が、前記アプリケーションから前記第１の端末へと前記レスポンスを転送する際、前記アプリケーションが発行した第２のユーザのセッション情報を他のセッション情報に置換し、
   前記受付手段が、前記第１の端末から前記アプリケーションへと前記リクエストを転送する際、前記他のセッション情報を前記第２のユーザのセッション情報に置換する、
   請求項２に記載の代行ログイン装置。
4. 前記受付手段は、所定のタイミングから所定時間が経過した以降は、前記リクエストおよびレスポンスの転送を行わず、
   前記所定時間は、前記アプリケーションに設定されるセッションタイムアウト時間よりも短い時間である、
   請求項２または３に記載の代行ログイン装置。
5. 前記受付手段は、前記代行ログイン装置に対する前記第１のユーザのログイン処理を行う第１の受付処理を実行するか、あるいは、前記代行ログイン装置に対する前記第１のユーザのログイン処理を行わない第２の受付処理を実行し、
   前記承認依頼手段は、前記受付手段が前記第１の受付処理を実行して前記ログイン処理に成功した場合と、前記受付手段が前記第２の受付処理を実行した場合とで、互いに異なる態様にて、前記第２の端末を介して前記第２のユーザに対して前記承認を依頼する、
   請求項１から４のいずれかに記載の代行ログイン装置。
6. 前記承認依頼手段は、
   前記受付手段が前記第２の受付処理を実行した場合には、前記第２のユーザに前記承認を依頼する際、前記第２の端末の画面に、前記第１のユーザが前記代行ログイン装置にログインしていないユーザである旨を示す情報を表示するよう前記第２の端末を制御する
   請求項５に記載の代行ログイン装置。
7. コンピュータが、
   第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付け、
   前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼し、
   前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする、
   制御方法。
8. コンピュータに、
   第１のユーザが操作する第１の端末を介して第２のユーザの識別情報の入力を受け付ける処理と、
   前記第２のユーザの識別情報に基づいて、前記第２のユーザに対して前記第２のユーザが操作する第２の端末を介して、情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて、承認を依頼する処理と、
   前記承認の依頼について許可を表す返答を前記第２のユーザから受け付けた場合に、前記アプリケーションに前記第２のユーザがログインするための認証情報を用いて、前記アプリケーションにログインする処理と、
   を実行させるプログラム。
9. 請求項５に記載の代行ログイン装置と通信可能に接続された前記第２の端末であって、
   表示手段と、操作受付手段と、承認結果送信手段とを備え、
   前記表示手段は、前記受付手段が前記第１の受付処理を実行することによって前記ログイン処理に成功した場合と、前記受付手段が前記第２の受付処理を実行した場合とで、前記情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて承認を依頼されている旨の情報を、互いに異なる態様にて表示し、
   前記操作受付手段は、前記表示手段に表示された情報に基づく、前記第２のユーザから前記依頼された内容を許可するか否かを表す承認結果の入力を、受け付け、
   前記承認結果送信手段は、前記承認結果を前記代行ログイン装置に送信する、
   前記第２の端末。
10. 請求項５に記載の代行ログイン装置と通信可能に接続された前記第２の端末に、
    前記受付手段が前記第１の受付処理を実行することによって前記ログイン処理に成功した場合と、前記受付手段が前記第２の受付処理を実行した場合とで、前記情報処理装置により提供されるアプリケーションに前記第２のユーザの代わりに前記第１のユーザがログインすることについて承認を依頼されている旨の情報を、表示手段に、互いに異なる態様にて表示する処理と、
    前記表示手段に表示された情報に基づく、前記第２のユーザから前記依頼された内容を許可するか否かを表す承認結果の入力を、受け付ける処理と、
    前記承認結果を前記代行ログイン装置に送信する処理と、
    を実行させるプログラム。
    
    

Images