JP6221871B2

JP6221871B2 - 中継装置及びプログラム

Info

Publication number: JP6221871B2
Application number: JP2014058302A
Authority: JP
Inventors: 早川　博; 博早川
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2014-03-20
Filing date: 2014-03-20
Publication date: 2017-11-01
Anticipated expiration: 2034-03-20
Also published as: JP2015184752A

Description

本発明は、中継装置及びプログラムに関する。

製造業において、部品設計を製品開発元が行い、部品製造を開発元以外の会社に委託する、委託開発が広く行われている。部品製造の工程では、委託先は、単に委託元から渡された設計図から部品を製造するだけでなく、設計変更を委託元に依頼し、これに応じて両者間で設計の調整が行われるケースもある。このような場面において、設計の調整のためのやりとりに電子メールが利用されることが多い。電子メールを利用したやりとりは、個々のユーザのメールクライアント内には残るが、これらはユーザが削除可能であり、確たる記録として保存されるわけではない。

ところで、OpenID Connectは、任意のアイデンティティプロバイダでの認証結果を利用してＷｅｂアプリケーションにアクセスするための標準技術である。例えば、委託先のユーザが自社のアイデンティティプロバイダで認証を行い、その結果発行されるＩＤトークン（認証結果とユーザの属性情報のセット）を委託元のＷｅｂアプリケーションに提示する。ＩＤトークンを検証して信頼に足るユーザであると判断できれば、委託先のユーザはそのＷｅｂアプリケーションを利用することができる。Ｗｅｂアプリケーションとして、電子掲示板のような機能を持つアプリケーションを用い、委託元と委託先がそれぞれやりとり情報をそのＷｅｂアプリケーションに登録することで、両者間のやりとりをシステム上の記録として残すことができる。このとき、ユーザに対してＷｅｂアプリケーションがＩＤトークンの提示を求めることで、信頼できないユーザからの要求を受け付けないようにすることができる。

ここでOpenID Connectは、ＨＴＴＰＳ（HyperText Transfer Protocol Secure）プロトコルを利用したＷｅｂアプリケーションが前提とされているため、ネットワークがファイアウォールで区切られている環境では、ＶＰＮ(Virtual Private Network)により専用の通信経路を用意する必要がある。したがって、上述した委託元のＷｅｂアプリケーションに委託元・委託先間のやりとりの情報を集約するシステムを構築するには、委託先のユーザのＰＣ（パーソナルコンピュータ）に都度ＶＰＮの設定作業をするという作業負担が生じる。また、ＶＰＮ接続用のクレデンシャルを各ユーザが管理する必要があり、セキュリティ上のリスクにつながる。

また、特許文献１には、シングルサインオンシステムにおいて、認証サービス（セキュリティトークンサービス）の負荷を軽減する仕組みが開示されている。この仕組みでは、認証サービスとアプリケーションサービスプロバイダ（以下「プロバイダ」と呼ぶ）との間にプロキシサービスが設けられる。プロプロキシサービスは、認証サービスによる認証結果を保存し、一定条件の下、プロバイダから受け取った認証要求を認証サービスに転送せず、自身が保存する認証結果に基づいてクライアント認証を代行する。

また、特許文献２に開示されたシステムでは、メールサーバとメールクライアントの間に介在するプロキシサーバが、メールクライアントからの指示に応じて、メールサーバからそのメールクライアント宛の電子メールを取得する。そして、プロキシサーバは、取得した電子メールに対してそのメールクライアントに対応する設定に応じた加工を施し、加工済みの電子メールをそのメールクライアントに送信する。

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

本発明は、ファイアウォール内にある情報処理装置がファイアウォール外のユーザからの指示を受け付けることができるようにするとともに、そのユーザが信頼できる者であるかどうかを情報処理装置が検証できるようにすることを目的とする。

請求項１に係る発明は、ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段と、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザＩＤ情報プロバイダが発行したユーザＩＤ情報を抽出し、抽出したユーザＩＤ情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段と、を備える中継装置である。

請求項２に係る発明は、前記制御手段は、前記認証依頼として、前記ユーザＩＤ情報プロバイダのＵＲＬに対して前記待機メールアドレスを示すmailtoスキームをリダイレクト先パラメータとして付加したものを含んだ情報を送信する、ことを特徴とする請求項１に記載の中継装置である。

請求項３に係る発明は、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから抽出した前記ユーザＩＤ情報を、前記機能実行メールの送信元の電子メールアドレスと対応づけて記憶するＩＤ記憶手段を更に備え、前記制御手段は、前記機能実行メールを受信した場合に、前記機能実行メールの送信元のメールアドレスに対応するユーザＩＤ情報が前記ＩＤ記憶手段に記憶されていれば、前記認証依頼を送信せずに、前記ＩＤ記憶手段に記憶されているそのユーザＩＤ情報を、受信した前記機能実行メールと共に前記情報処理装置に送信する、ことを特徴とする請求項１又は２に記載の中継装置である。

請求項４に係る発明は、前記ＩＤ記憶手段は、前記待機メールアドレスを宛先とする電子メールから前記ユーザＩＤ情報の有効期限を抽出し、抽出した有効期限を当該ユーザＩＤ情報と対応づけて記憶し、前記制御手段は、前記機能実行メールの送信元のメールアドレスに対応するユーザＩＤ情報が前記ＩＤ記憶手段に記憶されていても、当該ユーザＩＤ情報に対応づけて記憶された有効期限が切れている場合は、当該ユーザＩＤ情報を前記情報処理装置に送信せず、前記認証依頼を前記機能実行メールの送信元に送信する、ことを特徴とする請求項３に記載の中継装置である。

請求項５に係る発明は、コンピュータを、ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザＩＤ情報プロバイダが発行したユーザＩＤ情報を抽出し、抽出したユーザＩＤ情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段、として機能させるためのプログラムである。

請求項１又は５に係る発明によれば、ファイアウォール内にある情報処理装置がファイアウォール外のユーザからの指示（機能実行メール）を受け付けることができるようにするとともに、そのユーザが信頼できる者であるかどうかを情報処理装置が検証できるようにすることができる。

請求項２に係る発明によれば、機能実行メールを送信したユーザは、中間サーバからの認証依頼に含まれるＵＲＬを用いてユーザＩＤ情報プロバイダにアクセスして認証を受けることができるとともに、認証が成功した場合、ユーザＩＤ情報プロバイダからのリダイレクトにより、自分のユーザＩＤ情報を中間サーバに渡すことができる。

請求項３に係る発明によれば、ユーザは、中間サーバに自分のユーザＩＤ情報を渡すと、その後機能実行メールを送信した際に、再びユーザＩＤ情報プロバイダからユーザＩＤ情報を取得する必要がなくなる。

請求項４に係る発明によれば、情報処理装置がユーザＩＤ情報の検証を行う前に、そのユーザＩＤ情報の有効期限切れを中間サーバで検知し、ユーザに対してユーザＩＤ情報の再提出を依頼することができる。

本発明の一実施形態のシステムの一例を示す図である。アプリケーションサーバの機能に対応するメールアドレスと、その機能の実行のために呼び出すＡＰｌのＵＲＬとの対応関係の例を示す図である。ＩＤプロバイダによる認証及びＩＤトークンの発行の一例を示す図である。中間サーバの記憶部に記憶されるデータの例を示す図である。機能実行メールを受信した時の中間サーバの処理手順の一例を示す図である。認証依頼メールに記載されるＵＲＬ、及びＩＤプロバイダにおける認証が成功した場合のリダイレクト先を示すＵＲＬの構成を説明するための図である。ＩＤトークン送付メールを受信した時の中間サーバの処理手順の一例を示す図である。

図１に、本発明の一実施形態のシステムを例示する。図１に例示するシステムは、アプリケーションサーバ１０、中間サーバ２０、ユーザＰＣ４０及びＩＤプロバイダ５０を含む。

アプリケーションサーバ１０及び中間サーバ２０は、ファイアウォールによりインターネットから隔てられた組織Ａの内部ネットワーク内に設けられている。また、ユーザＰＣ（パーソナルコンピュータ）４０及びＩＤプロバイダ５０は、ファイアウォールによりインターネットから隔てられた、組織Ａとは異なる組織Ｂの内部ネットワーク内に設けられている。

組織Ａ及び組織Ｂは、企業、学校、各種団体等といった様々な形態の組織のいずれであってもよい。組織ＡとＢとは何らかの協力関係にあり、組織Ａのアプリケーションサーバ１０は、組織Ａ内のユーザに対してそのユーザの権限に応じた機能を提供すると共に、組織Ｂ内のユーザにもいくつかの機能を提供する。実際の運用例をイメージしやすくするために具体例を挙げると、例えば組織Ａは委託元の企業、組織Ｂは委託先の企業である。

アプリケーションサーバ１０及び中間サーバ２０は、それぞれ別々のコンピュータ装置上に実装してもよいし、同一のコンピュータ装置で実行される別々のプログラムとして実装してもよい。なお、アプリケーションサーバ１０及び中間サーバ２０は、１台のコンピュータ装置に限られるものではない。複数台のコンピュータ装置が連携してそれら各サーバの機能を実現する構成であってもよい。

アプリケーションサーバ１０は、ユーザに対してアプリケーションソフトウエアの機能を提供するサーバである。

例えば、アプリケーションサーバ１０がＷｅｂアプリケーションサービスを提供するものである場合、そのサービスを利用しようとするユーザは、ＨＴＴＰ（HyperText Transfer Protocol）を用いてアプリケーションサーバ１０にアクセスする必要がある。ここで、組織Ａのファイアウォールがインターネット側からのＨＴＴＰリクエストを遮断する設定となっていれば、組織Ａ内のユーザはアプリケーションサーバ１０のサービスを利用できるが、組織Ｂ内のユーザはＨＴＴＰ経由ではそのサービスを利用することはできない。ただし、これでは組織ＡとＢが協業する場合などにアプリケーションサーバ１０をその道具として用いることができない。
そこで、本実施形態のアプリケーションサーバ１０は、当該サーバが提供する機能のうちの少なくとも１つについて、その機能の実行の指示を電子メールで受け付けることができるよう構成されている。一般にファイアウォールは電子メールを遮断しないので、電子メールを用いることで、組織Ｂ内のユーザがファイアウォールを越えて組織Ａ内のアプリケーションサーバ１０に指示を送ることが可能となる。

アプリケーションサーバ１０が提供するアプリケーションサービスとしては、これに限定されるわけではないが、例えば電子掲示板サービスがある。電子掲示板サービスを提供する場合、アプリケーションサーバ１０は、電子掲示板サービスに関する諸機能のうち例えば記事の投稿や新たなスレッド（話題、トピック、タスクとも呼ばれる）の作成等といった少なくとも１つの機能についての実行指示を、一般的なＨＴＴＰリクエストの形だけでなく、電子メールの形でも受け付けることができる。このようにすることで、組織Ｂのユーザは、電子掲示板システム上の組織Ａのあるプロジェクトの掲示板（又はスレッド）への投稿を指示する電子メールをアプリケーションサーバ１０に送ることで、組織Ａのそのプロジェクトのメンバと連絡を取ることが可能になり、かつその連絡事項が掲示板に記録されることとなる。

電子メールによる機能実行指示は、例えば、その機能に対応するあらかじめ定められた電子メールアドレス（以下「メールアドレス」という）に対してユーザが電子メールを送ることで実現される。例えば電子掲示板への投稿は、投稿記事の見出し及び本文をそれぞれ件名及び本文とする電子メールを、アプリケーションサーバ１０の投稿受付機能のメールアドレス宛に送ることにより実現される。このように、アプリケーションサーバ１０の提供する機能に対応するメールアドレスを宛先とした電子メールのことを、以下では機能実行メールと呼ぶことにする。

機能実行メールによる指示の受付の仕組みとしては、例えば、図２に例示するように、機能に対応するメールアドレスとその機能のＡＰＩ（Application Programming Interface）との対応関係の情報を用いる方式がある。アプリケーションサーバ１０は、その対応関係の情報を参照可能であり、受信した機能実行メールの宛先メールアドレスに対応するＡＰＩをその対応関係から求め、求めたＡＰＩを実行することで、ユーザが指示する機能を実行する。

さて、このようにアプリケーションサーバ１０が機能実行の指示を電子メールで受付できるようにした場合、情報セキュリティ上、アクセスを認めるものとしてあらかじめ定めた組織（この例では組織Ｂ）に属さないユーザが電子メールでその機能を利用することがないようにするために、一種のアクセス制御が必要となる。本実施形態では、このようなアクセス制御のために、ＩＤプロバイダ５０が発行するＩＤトークンを利用する。

ＩＤプロバイダ５０は、ユーザのアイデンティティ（ＩＤ）を証明する情報（すなわちＩＤトークン）を提供するプロバイダである。ＩＤプロバイダ５０は、ユーザを認証し、その認証が成功した場合に、そのユーザのＩＤ情報を含んだＩＤトークンを発行する。ＩＤプロバイダ５０の具体例は、例えばOpenID Connectに準拠したOpenID Providerである。

図示例では、ＩＤプロバイダ５０は組織Ｂ内に設けられており、組織Ｂに属するユーザのＩＤを証明するＩＤトークンを発行する。組織Ａ内のアプリケーションサーバ１０及び中間サーバ２０にはＩＤプロバイダ５０が「信頼できるＩＤプロバイダ」としてあらかじめ登録されており、アプリケーションサーバ１０及び中間サーバ２０はそのＩＤプロバイダ５０が発行したＩＤトークンを信用する。例えばアプリケーションサーバ１０は、組織Ｂ内のユーザＰＣ４０から到来した機能実行メールにＩＤプロバイダ５０が発行したＩＤトークンが付加されている場合、その機能実行メールがそのＩＤトークンの示すユーザからのものであると認識する。例えば、記事の投稿を指示する機能実行メールを受け取った場合、そのメールに含まれる記事内容を、そのメールに付加されたＩＤトークンが示すユーザからの投稿として電子掲示板に登録する。

アプリケーションサーバ１０が有するＩＤトークン抽出部１２は、機能実行メールからＩＤトークンを抽出する。ＩＤトークン検証部１４は、抽出したＩＤトークンに付されたＩＤプロバイダ５０の電子署名やＩＤトークンの有効期限などの検証を行う。ＩＤトークンの検証は、そのＩＤトークンが準拠しているOpenID Connect等のアイデンティティシステム標準に従って行われる。

中間サーバ２０は、組織Ａの内部ネットワーク上に配置された中継装置であり、インターネット側からのアプリケーションサーバ１０宛の機能実行メールを代理受信し、アプリケーションサーバ１０へと中継する。この中継の際、中間サーバ２０は、その機能実行メールに対して、ＩＤプロバイダ（組織Ｂ内のユーザからのメールの場合、ＩＤプロバイダ５０）が発行したそのユーザのＩＤトークンを付加する。この処理を担うのがＩＤトークン付加部２４である。

ここで、例えば組織Ｂ内のユーザからの機能実行メールにＩＤトークンを付加するためには、ＩＤプロバイダ５０からそのユーザのＩＤトークンを取得する必要がある。このために中間サーバ２０は、組織Ｂ内のユーザに対して、ＩＤプロバイダ５０から自分（そのユーザ）のＩＤトークンを取得するよう誘導するための処理を行う。この処理を担うのが認証依頼送信部２２である。認証依頼送信部２２は、認証依頼メールと呼ぶ電子メールを作成し、これをユーザ側に送ることで、ユーザがＩＤプロバイダ５０からＩＤトークンを取得するように誘導する。認証依頼送信部２２及びＩＤトークン付加部２４の詳細については後で詳しく説明する。

記憶部３０は、中間サーバ２０の処理のために必要な情報を記憶する装置である。記憶部３０は、中間サーバ２０内に設けられてもよいし、ネットワーク上の中間サーバ２０からアクセス可能な場所に設けられてもよい。

ユーザＰＣ４０は、組織Ｂのファイアウォール内の内部ネットワーク上に設置されたパーソナルコンピュータである。ユーザＰＣ４０は、メールクライアント４２とＷｅｂブラウザ４４を有する。

メールクライアント４２は電子メールの送受信を行うクライアントアプリケーションである。本実施形態では、組織Ｂのユーザは、組織Ａ内のアプリケーションサーバ１０に対してある機能の実行を指示しようとする場合、メールクライアント４２を操作してその機能に対応するあらかじめ定められたメールアドレスを宛先とする機能実行メールを作成し、送信する。図１の例では、メールクライアント４２は、Ｓ／ＭＩＭＥ（Secure / Multipurpose Internet Mail Extensions）に従った電子メールを組織Ａ側とやり取りする。ただし、Ｓ／ＭＩＭＥを用いることは一例に過ぎない。またメールクライアント４２は、中間サーバ２０から認証依頼メールを受け取ったり、この認証依頼メールに誘導されたＩＤトークン取得処理によりＩＤプロバイダ５０から取得したＩＤトークンを中間サーバ２０に送信したりする。メールクライアント４２は、特別なものである必要はなく、通常のＰＣにインストールされている既存のものでよい。また、ユーザＰＣ４０にインストールされているメールクライアント４２の代わりに、Ｗｅｂアプリケーションとして提供されるメールクライアントをＷｅｂブラウザ４４から利用する形でもよい。

Ｗｅｂブラウザ４４は、World Wide Webを利用するために用いられるアプリケーションである。本実施形態では、Ｗｅｂブラウザ４４は、ＩＤプロバイダ５０からユーザ認証を受け、ＩＤトークンを取得するために用いられる。Ｗｅｂブラウザ４４も、特別なものである必要はなく、通常のＰＣにインストールされている既存のものでよい。

ＩＤプロバイダ５０は、認証依頼メールをトリガとして発せられるユーザＰＣ４０からの要求に応じて、そのユーザを証するＩＤトークンを発行する。以下の例では、ＩＤプロバイダ５０はOpenID Connect Implicit Client Profileの仕様に準拠しているものとする。

ＩＤプロバイダ５０は、例えば図３に例示するテーブル群を用いて、ＩＤトークンの発行処理を行う。図３において、パスワードテーブル５２は、認証対象の各ユーザのパスワード情報を保持するテーブルである。パスワードテーブル５２の項目「識別子」は、このテーブルの各エントリの識別情報であり、ユーザ毎の一意な値である。「パスワードハッシュ」及び「ソルト」は、ユーザが入力したパスワードが正しいか否かの判定に用いる情報である。パスワードハッシュ及びソルトを用いたパスワード検証方法は周知であるし、またパスワードハッシュ等を用いた検証はＩＤプロバイダ５０が用いるユーザ認証方法のあくまで一例としてあげるに過ぎないので、これ以上の説明は省略する。ユーザ属性テーブル５４は、認証対象の各ユーザの属性情報を保持するテーブルである。図３には、ユーザの属性情報として、従業員ＩＤ、メールアドレス、所属部署名等を例示している。ユーザ属性テーブル５４の「識別子」は、パスワードテーブル５２で用いられる「識別子」と同じものであり、両テーブルで識別子の値が同一のエントリは同一のユーザについてのものである。属性変換テーブル５６は、ユーザ属性テーブル５４内の各属性項目をＩＤトークンに組み込むときのパラメータ名を保持するテーブルである。例えば「従業員ＩＤ」の値は、「employeeID」というパラメータの値としてＩＤトークンに組み込まれる。

ＩＤプロバイダ５０は、例えばユーザに従業員ＩＤ又はメールアドレスとパスワードとの入力を求め、これに応じて入力されたパスワードがその従業員ＩＤ又はメールアドレスに対応するパスワードであることがパスワードハッシュ等により検証できれば、そのユーザが正当なユーザであると判定する。この場合、ＩＤプロバイダ５０は、そのユーザのアイデンティティ情報（例えばメールアドレス）や指定されたその他のユーザ属性情報を含んだＩＤトークンを発行する。なお図４に例示したテーブル群はあくまで一具体例に過ぎない。ＩＤプロバイダ５０は、準拠するアイデンティティシステム標準に定められた情報を保持していればよく、その情報に従ってユーザ認証やＩＤトークンの発行等の処理を行う。

図１では、組織Ｂのユーザを認証するＩＤプロバイダ５０が組織Ｂの内部ネットワーク内にあるが、これは必須のことではない。

次に、図４を参照して、中間サーバ２０の処理のために記憶部３０に記憶される情報の例を説明する。図示のように、記憶部３０は、ＩＤプロバイダテーブル３２、ＩＤトークンテーブル３４及び認証待ちテーブル３６を記憶する。

ＩＤプロバイダテーブル３２は、中間サーバ２０及びアプリケーションサーバ１０が信頼するＩＤプロバイダ５０の情報を保持する。ＩＤプロバイダテーブル３２が保持する情報は、ドメインとそのドメインに対応するＩＤプロバイダのエンドポイントＵＲＬ（Uniform Resource Locator）である。例えばユーザがこのエンドポイントＵＲＬに対してアクセスすると、そのＵＲＬに対応するＩＤプロバイダから、ユーザ認証のためにＷｅｂページがユーザに返される。中間サーバ２０は、ＩＤプロバイダテーブル３２のある「ドメイン」内のメールアドレスから送信された機能実行メールに対して、認証のために、その「ドメイン」に対応する「エンドポイントＵＲＬ」のＩＤプロバイダが発行したＩＤトークンを要求する。

ＩＤトークンテーブル３４は、（例えば認証依頼メールをトリガとする認証処理の結果）ユーザから提出されたＩＤトークンを保持するテーブルである。このテーブルには、ユーザのメールアドレスと、ＩＤプロバイダ５０が発行したそのユーザのＩＤトークンとが互いに対応づけて登録される。なお、ＩＤプロバイダ５０が、ユーザ認証に応じて、ＩＤトークンに加え、そのユーザに関する他のパラメータ（例えばユーザの属性情報、ＩＤトークンの有効期限）も併せて発行する場合は、それら他のパラメータもＩＤトークンテーブル３４に登録する。中間サーバ２０は、ユーザがＩＤトークンを提出した後、そのＩＤトークンが有効な間は、そのユーザからの電子メールにＩＤトークンが付加されていなければ、ＩＤトークンテーブル３４に記憶したそのユーザのＩＤトークンをその電子メールに付加してアプリケーションサーバ１０に渡す。

認証待ちテーブル３６は、ＩＤトークンを未提出のユーザから機能実行メールを受信した場合に、そのユーザがＩＤトークンを提出するまでその機能実行メールを保留しておくために用いる。認証待ちテーブル３６の項目「機能実行メール」にはその機能実行メールのデータを記憶する。認証待ちテーブル３６の項目「リダイレクトＵＲＬ」は、そのようにして保留した「機能実行メール」を一意に識別する識別情報として機能するＵＲＬである。リダイレクトＵＲＬは、「mailto:」スキームのＵＲＬであり、図示例では、以下の形式の文字列である。

mailto:${一意性のあるランダム文字列}@${アプリケーションサーバ１０で規定されたドメイン名}

このリダイレクトＵＲＬは、「:${一意性のあるランダム文字列}@${アプリケーションサーバ１０で規定されたドメイン名}」が表すメールアドレスに対して電子メールを送信するようメールクライアントに指示するＵＲＬである。リダイレクトＵＲＬのうち一意性のあるランダム文字列の部分は、保留した機能実行メールを識別する識別情報として機能する。またアプリケーションサーバ１０で規定されたドメイン名の部分は、保留した機能実行メールがそのアプリケーションサーバ１０に宛てたものであることを示す。したがって、ユーザが、例えば、あるＷｅｂページ上の、そのリダイレクトＵＲＬがＨＲＥＦ属性として設定されたアンカー要素（Ａ要素）をクリックすると、Ｗｅｂブラウザはメールクライアントを起動する。起動されたメールクライアントは、そのリダイレクトＵＲＬ中の、保留メールの識別情報とアプリケーションサーバ１０に対応するドメイン名からなるメールアドレスを宛先に設定した電子メールの作成画面を表示する。ユーザがそのメール作成画面で作成中の電子メールの送信を指示すると、そのメールアドレスに対して送信される。このメールアドレスはアプリケーションサーバ１０に対応するドメイン内のものなので、中間サーバ２０により受信されることとなる。なお、詳しくは後で説明するが、このリダイレクトＵＲＬを用いて送信される電子メールは、組織Ｂ内のユーザがＩＤプロバイダ５０から取得した自分のＩＤトークンを中間サーバ２０（ひいてはアプリケーションサーバ１０）に提出するために用いられる。ＩＤプロバイダ５０からＩＤトークンの取得及び中間サーバへの提出のための処理（いわば中間サーバ２０からみたそのユーザの認証処理）にユーザを誘導するために、中間サーバ２０の認証依頼送信部２２はそのユーザ宛に認証依頼メールを送るが、リダイレクトＵＲＬはその認証依頼メールに組み込まれる。

次に、図５を参照して、機能実行メールを受信した際の、中間サーバ２０の処理手順の一例を説明する。受信した電子メールが機能実行メールであるか否かは、その電子メールの宛先のメールアドレスが、アプリケーションサーバ１０の機能（図２の例ではＡＰＩ）に対応するメールアドレスであるか否かにより判定される。

受信した電子メールが機能実行メールであった場合、中間サーバ２０は、その電子メールから送信元メールアドレスを抽出し（Ｓ１０）、その送信元メールアドレスに対応する有効なＩＤトークンがＩＤトークンテーブル３４内にあるか否かを調べる（Ｓ１２）。ここで有効なＩＤトークンとは、設定されている有効期限がすぎていないＩＤトークンのことである。中間サーバ２０は、例えば、その送信元メールアドレスに対応するＩＤトークンがＩＤトークンテーブル３４にあるかどうかを調べ、ある場合には、そのＩＤトークンの有効期限が切れていないかをチェック（必要ならＩＤプロバイダ５０に有効期限を確認する）し、有効期限が切れていなければそのＩＤトークンが有効であると判定する。すなわち、Ｓ１２の判定結果はＹｅｓとなる。送信元メールアドレスに対応するＩＤトークンがＩＤトークンテーブル３４にないか、あってもその有効期限が切れている場合は、Ｓ１２の判定結果はＮｏとなる。

Ｓ１２の判定結果がＹｅｓの場合、中間サーバ２０のＩＤトークン付加部２４が、その機能実行メールに対してその有効なＩＤトークンを付加し（Ｓ１４）、ＩＤトークン付加済みの機能実行メールをアプリケーションサーバ１０に送信する（Ｓ１６）。機能実行メールに対するＩＤトークンの付加は、例えば、その機能実行メールのヘッダ部に対して行う。

Ｓ１２の判定結果がＮｏの場合、認証依頼送信部２２が呼び出される。呼び出された認証依頼送信部２２はリダイレクトＵＲＬを生成する（Ｓ１８）。生成されたリダイレクトＵＲＬは、その機能実行メールを一意に識別する識別情報（例えば乱数値）を含む。リダイレクトＵＲＬについては上で説明したので、ここではこれ以上の説明は省略する。次に認証依頼送信部２２は、当該機能実行メールを、そのリダイレクトＵＲＬに対応づけて認証待ちテーブル３６に格納する（Ｓ２０）。そして、そのリダイレクトＵＲＬを含んだ認証依頼メールを生成し、その認証依頼メールを機能実行メールの送信元のメールアドレスに対して返信する（Ｓ２２）。

ここで、認証依頼送信部２２がその送信元に返信する認証依頼メールは、アプリケーションサーバ１０の機能を利用するには認証が必要であることを説明する文面を含む。また、リダイレクトＵＲＬは、その送信元のドメインに対応するＩＤプロバイダ５０のエンドポイントＵＲＬに対してパラメータとして含まれ、そのエンドポイントＵＲＬが認証依頼メールに組み込まれる。送信元のドメインに対応するＩＤプロバイダ５０のエンドポイントＵＲＬは、ＩＤプロバイダテーブル３２から取得できる、このようにリダイレクトＵＲＬをパラメータとして含んだＩＤプロバイダ５０のエンドポイントＵＲＬのことを、以下では「認証誘導ＵＲＬ」と呼ぶ。

認証依頼メールに組み込まれる認証誘導ＵＲＬの例を、図６の（Ａ）に示す。図示のように、この認証誘導ＵＲＬは、ＩＤプロバイダ５０のエンドポイントＵＲＬの後に、パラメータとしてリダイレクトＵＲＬ、及びその他のパラメータ（もしあれば）が、クエリ文字列の形で付加されて構成されたものである。リダイレクトＵＲＬは、「redirect_uri」という変数名で示されている。パラメータ「redirect_uri」は、OpenID Connectに規定されるパラメータであり、認証後のリダイレクト先（すなわち認証結果の応答の宛先）のＵＲＩ（Uniform Resource Identifier）を示す。このパラメータに、前述のリダイレクトＵＲＬの値が設定される。また、その他のパラメータとして図に例示している「response_type」もOpenID Connectに規定されるパラメータの１つであり、使用されるべき認証処理フローを規定する値を示す。図示された「response_type」の値「id_token」は、認証処理フローとしてImplicit Client Profileに規定されたImplicit Flow（インプリシット・フロー）を用いることを示す。

認証依頼メールを受け取ったユーザは、メールクライアント４２上で、その認証依頼メールの本文内に含まれる認証誘導ＵＲＬをクリックする。すると、Ｗｅｂブラウザ４４が起動され、その認証誘導ＵＲＬ（ＩＤプロバイダ５０のエンドポイントを指している）にアクセスする。このとき、認証誘導ＵＲＬに含まれる「redirect_uri」等のパラメータがＩＤプロバイダ５０に伝達される。このアクセスに応じ、ユーザは、そのＩＤプロバイダ５０の認証方式でユーザ認証を行う。例えば、ＩＤプロバイダ５０は、認証用のＷｅｂページをＷｅｂブラウザ４４に返し、ユーザは、その認証用Ｗｅｂページに対して、ＩＤプロバイダ５０が要求する認証情報、例えばユーザＩＤ（メールアドレス等）とパスワードの組、等を入力し、入力結果をＩＤプロバイダ５０に送信する。ＩＤプロバイダ５０は、Ｗｅｂブラウザ４４から受け取った認証情報によりユーザ認証を行う。このユーザ認証が成功した場合、ＩＤプロバイダ５０は、認証誘導ＵＲＬに対するアクセス時にＷｅｂブラウザ４４から伝達された「redirect_uri」パラメータが示すリダイレクトＵＲＬに対してパラメータを付加し、ユーザからの上記アクセスをパラメータ付加後のリダイレクトＵＲＬにリダイレクトする。ここでリダイレクトＵＲＬに付加するパラメータは、例えばOpenID Connectの「End-User Grants Authorization」の仕様に準拠したパラメータであり、例えば認証誘導ＵＲＬに対するアクセス時に伝達された「他のパラメータ」により決まるパラメータを含んでもよい。例えば、図６（Ａ）に例示した認証誘導ＵＲＬは、「response_type」として「id_token」を指定しているので、ＩＤプロバイダ５０は、ユーザ認証が成功した場合、そのＵＲＬへのアクセスを、当該ユーザのＩＤトークンをパラメータとして含んだリダイレクトＵＲＬにリダイレクトする。

ユーザに対する認証が成功した後の、パラメータが設定されたリダイレクトＵＲＬの例を図６の（Ｂ）に示す。このＵＲＬは、認証誘導ＵＲＬ（図６（Ａ））に含まれるリダイレクトＵＲＬの後に、そのユーザのＩＤトークン（パラメータ名「id_token」）と、他のパラメータ（もしあれば）とが、クエリ文字列の形で付加される形で構成されている。図では、他のパラメータとしてＩＤトークンのタイプを示す「token_type」及びそのＩＤトークンの有効期限を示す「expire」等が示されている。

認証成功後のリダイレクト先はmailtoスキームなので、Ｗｅｂブラウザ４４からメールクライアント４２が起動され、起動されたメールクライアント４２のメール作成画面に、リダイレクトＵＲＬ内のメールアドレスを宛先とし、当該ユーザのメールアドレスを送信元とする電子メールが表示される。この電子メールのヘッダには、ＩＤプロバイダ５０がリダイレクトＵＲＬに付加したパラメータ（ＩＤトークンなど）が組み込まれる。この電子メールを、ＩＤトークン送付メールと呼ぶ。ユーザが、そのメール作成画面に対して送信操作を行うと、そのＩＤトークン送付メールがその宛先へと送信される。その宛先は、前述のリダイレクトＵＲＬの説明に示したとおり、アプリケーションサーバ１０に規定されるドメイン内のものなので、中間サーバ２０により受信される。

次に、ＩＤトークン送付メールを受信した場合の中間サーバ２０の処理手順の例を、図７を参照して説明する。なお、中間サーバ２０は、受信したアプリケーションサーバ１０宛の電子メールが機能実行メール（すなわち特定の機能に対応するあらかじめ定められたメールアドレス宛のメール）でなければ、その電子メールはＩＤトークン送付メールであると仮定して図７の処理を進める。

この手順では、まず中間サーバ２０は、そのＩＤトークン送付メールから宛先メールアドレスを抽出し（Ｓ３０）、その宛先メールアドレスに対応する機能実行メールが認証待ちテーブル３６内に存在するかどうかを調べる（Ｓ３２）。存在すれば（Ｓ３２の判定結果がＹｅｓ）、ＩＤトークン付加部２４がその機能実行メールを認証待ちテーブル３６から取り出し、ＩＤトークン送付メールに含まれるＩＤトークン及びその他のパラメータ（もしあれば）をその機能実行メール（の例えばヘッダ）に付加する（Ｓ３４）。なお、そのＩＤトークン送付メールがＩＤトークンを含んでいなければ、Ｓ３４の処理はエラーとなり、所定のエラー処理が行われる。そして、ＩＤトークン付加部２４は、ＩＤトークン付加済みの機能実行メールを、アプリケーションサーバ１０に渡す（Ｓ３６）。また、中間サーバ２０は、そのＩＤトークン送付メールに含まれるＩＤトークン及びその他のパラメータを、ＩＤトークン送付メールの送信元メールアドレス（これは、対応する機能実行メールの送信元と同じ）と対応づけて、ＩＤトークンテーブル３４に格納する（Ｓ３８）。そのＩＤトークンが有効な間にそのユーザから別の機能実行メールが来た場合、中間サーバ２０は、認証依頼メールを送ることなく、ＩＤトークンテーブル３４に格納されたそのＩＤトークンを自動的にその機能実行メールに付加することとなる（図５のＳ１４）。

なお、Ｓ３２の判定結果がＮｏになるのは例外的なケースであり、この場合中間サーバ２０はエラーメッセージを提示し（Ｓ３９）、処理を終了する。エラーの提示は、例えばその電子メールの送信元に対して電子メールの形で行う。

図７のＳ３２の判定がＹｅｓとなった後、ＩＤトークン送付メールからＩＤトークンの情報が取り出せた場合、中間サーバ２０が、その情報に含まれるユーザ（そのＩＤトークンが身元証明する対象のユーザ）のメールアドレスと、そのＩＤトークン送付メールの送信元メールアドレスが一致するかどうかを検証してもよい。一致する場合はＳ３４に進み、一致しない場合はエラーとする。この検証により、そのメールが、そのＩＤトークンが証明するユーザのメールアドレスから送信されたものである場合にのみ、そのＩＤトークンがアプリケーションサーバ１０に渡されることとなる。なお、この検証のためには、ＩＤプロバイダ５０は、ユーザ認証の結果としてリダイレクトするリダイレクト先のＵＲＬのパラメータに、認証したユーザのＩＤトークンに加え、そのユーザのメールアドレスを含めればよい。

以上、本実施形態のシステム構成及び処理内容について説明した。次に、アプリケーションサーバ１０からみて未認証のユーザがアプリケーションサーバ１０に対して機能の実行を要求する場合、本実施形態のシステムの処理がどうなるのかを、図１の（１）〜（１１）の符号で示した情報の流れに沿って説明していく。なお、ここでいう「ユーザが未認証である」とは、そのユーザが自分のＩＤトークンを（ＩＤトークン送付メールにより）中間サーバ２０に一度も提出していない、又はそのユーザが過去に提出したＩＤトークンが全て期限切れとなっていることを指す。

（０）（事前準備）
ＩＤプロバイダ５０とアプリケーションサーバ１０の間で、ＩＤトークンの署名検証のためのネゴシエーション（具体的な処理内容は、OpenID Connectの仕様に従う）をしておく。また、ＩＤプロバイダテーブル３２に、ＩＤプロバイダ５０が認証するユーザのメールアドレスのドメインと、ＩＤプロバイダ５０のエンドポイントＵＲＬとを対応付けて保存しておく。

（１）ユーザは、アプリケーションサーバ１０に実行させたい機能に対応するメールアドレスを宛先とする機能実行メールを作成し、送信する。

（２）中間サーバ２０は、機能実行メールを受信し、送信元メールアドレスに対応するＩＤトークンをＩＤトークンテーブル３４から検索する。

（３）この状況（ユーザが未認証）では、上記（２）の検索で有効なＩＤトークンは見つからない。この場合、リダイレクトＵＲＬを発行し、そのリダイレクトＵＲＬに紐づけて、その機能実行メールを認証待ちテーブル３６に保存する。

（４）次に認証依頼送信部２２が、認証依頼メールを作成し、これをその機能実行メールの送信元メールアドレスに返信する。この認証依頼メールには、認証誘導ＵＲＬが含まれる。認証誘導ＵＲＬは、その送信元メールアドレスのドメインに対応するＩＤプロバイダ５０のエンドポイントＵＲＬ（これはＩＤプロバイダテーブル３２から取得される）に、上記（３）で発行したリダイレクトＵＲＬをパラメータとして付加したものである。

（５）ユーザは、受信した認証依頼メールをメールクライアント４２で閲覧し、その中に含まれる認証誘導ＵＲＬをクリックする。これに応じて起動したＷｅｂブラウザ４４が、認証誘導ＵＲＬにアクセスする。

（６）ユーザは、ＩＤプロバイダ５０の要求する認証方式でユーザ認証を行う。

（７）ＩＤプロバイダ５０は、Ｗｅｂブラウザ４４からのアクセスの際に取得したリダイレクトＵＲＬに、ＩＤトークン等のパラメータを付加し、パラメータ付加後のリダイレクトＵＲＬにリダイレクトする。このＵＲＬはmailtoスキームなので、メールクライアント４２が起動し、メール送信画面が表示されることとなる。この送信画面で送信対象として表示されるメール（ＩＤトークン送付メール）のヘッダには、リダイレクトＵＲＬに含まれているＩＤトークン等のパラメータが設定される。

（８）ユーザは、メール送信画面に表示されているＩＤトークン送付メールの送信操作を行う。

（９）中間サーバ２０は、ＩＤトークン送付メールを受信し、ＩＤトークン送付メールの宛先をキーに、認証待ちテーブル３６中の機能実行メールを検索する。この例では、認証待ちテーブル３６には、上記（３）でその宛先に対応する機能実行メールが保存されているので、検索によりその機能実行メールが見つかる。中間サーバ２０は、認証待ちテーブル３６からその機能実行メールを取り出す。この取り出しの後、認証待ちテーブル３６からその機能実行メールのエントリが削除される。

（１０）次にＩＤトークン付加部２４が、その機能実行メールのヘッダに、ＩＤトークン送付メール中のＩＤトークンを付加し、アプリケーションサーバ１０に送信する。また、そのＩＤトークンを、ＩＤトークン送付メールの送信元メールアドレスに対応付けて、ＩＤトークンテーブル３４に保存する。

（１１）アプリケーションサーバ１０は、ＩＤトークンが負荷された機能実行メールを受信する。この場合、ＩＤトークン抽出部１２が、その機能実行メールからＩＤトークンを抽出する。そして、ＩＤトークン検証部１４が、そのＩＤトークンを検証する。この検証のための処理は本実施形態のシステムが準拠するアイデンティティシステム標準に従ったものであり、準拠する標準がOpenID Connectであれば、OpenID Connectの仕様に従った検証が行われる。そのＩＤトークンが正当であり有効であると確認できると、アプリケーションサーバ１０は、その機能実行メールが、そのＩＤトークンの示す正当なユーザからのものであると認識する。そして、そのユーザが、その機能実行メールに対応する機能を利用する権限がある場合その機能を実行する。そのユーザがその機能を実行する権限があるか否かは、例えば、ＩＤトークンに付随するパラメータ（例えばユーザの属性情報）に基づき判定すればよい。

次に、認証済み状態のユーザがアプリケーションサーバ１０に対して機能の実行を要求する場合の処理の流れを説明する。ここでの「認証済み状態」とは、認証依頼メールにより誘導される操作により自分のアイデンティティを証明するＩＤトークンを中間サーバ２０に提出済みであり、そのＩＤトークンの有効期限がまだ切れていない状態をいう。

この流れでは、ユーザが機能実行メールを送信（図１の（１））すると、中間サーバ２０がそれを受信し、受信した機能実行メールの送信元メールアドレスに対応するＩＤトークンをＩＤトークンテーブル３４から検索する（図１の（２））。このケースでは、ＩＤトークンテーブル３４から有効なＩＤトークンが検索される。これに応じ、ＩＤトークン付加部２４が、そのＩＤトークンを機能実行メールに付加し、付加後の機能実行メールをアプリケーションサーバ１０に送信する（図１の（１０））。アプリケーションサーバ１０は、受信した機能実行メールからＩＤトークンを抽出し、検証する。そして、検証が成功すると、その機能実行メールがそのＩＤトークンの示す正当なユーザからのものであると認識し、そのメールに対応する機能がそのユーザの権限内であれば、その機能を実行する（図１の（１１））。

以上の実施形態において、例えば、ＩＤプロバイダ５０が、発行するＩＤトークンと共に、そのＩＤトークンの有効期限の情報をリダイレクトＵＲＬのパラメータに設定する場合（図６（Ｂ）のパラメータ「expire」）を考える。この場合、その有効期限の情報はＩＤトークンともども、ＩＤトークン送付メールに含まれることとなる。したがって、中間サーバ２０は、受信したＩＤトークン送付メールを解析することで、そのＩＤトークン送付メールに含まれるＩＤトークンの有効期限を求めることができる。中間サーバ２０は、このようにして求めたＩＤトークンの有効期限を、ＩＤトークンと対応づけてＩＤトークンテーブル３４に登録するようにしてもよい。この場合、中間サーバ２０は、ユーザから受信した機能実行メールに対応するＩＤトークンをＩＤトークンテーブル３４から検索した際、そのＩＤトークンの有効期限を同時に取得できる。したがって、中間サーバ２０は、そのＩＤトークンの有効期限が切れていないかどうか、その時点で判定できる。このとき、そのＩＤトークンの有効期限が切れていれば、中間サーバ２０は、その機能実行メールの送信元メールアドレスに認証依頼メールを返信することで、送信元に対してＩＤトークンの再取得を依頼する。ＩＤトークンの有効期限切れは、ＩＤトークンを受け取ったアプリケーションサーバ１０による、標準に準拠した検証によっても判定できるが、この例のように中間サーバ２０で判定できるようにすれば、アプリケーションサーバ１０がＩＤトークンを検証するのを待つ必要がないので効率がよい。

以上に説明した実施形態では、アプリケーションサーバ１０及びＩＤプロバイダ５０等がOpenID Connect のImplicit Client Profileに準拠する場合（すなわちImplicit Flowを用いる場合）の例を説明したが、本発明は、このような特定の標準に直接依存するものではない。Implicit Flowの代わりにAuthorization Code Flowを用いる場合にも、またOpenID Connect以外の他のアイデンティティシステム標準を用いる場合にも、上記実施形態の方式は適用可能である。ＩＤトークンは、OpenID Connectにおけるユーザのアイデンティティ情報を表すデータであるが、別の標準に準拠したシステムを用いる場合はその標準でのアイデンティティ情報を用いればよい。

以上に例示したアプリケーションサーバ１０、中間サーバ２０、ＩＤプロバイダ５０は、例えば、汎用のコンピュータに当該装置の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで言うコンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）、フラッシュメモリ等の二次記憶を制御する二次記憶コントローラ、各種Ｉ／Ｏ（入出力）インタフェース、無線又は有線のネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤ、ブルーレイディスクなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、フラッシュメモリ等の二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。また、個々でいうコンピュータは、クラウドコンピューティングシステム上の仮想マシンであってもよい。

１０アプリケーションサーバ、１２ＩＤトークン抽出部、１４ＩＤトークン検証部、２０中間サーバ、２２認証依頼送信部、２４ＩＤトークン付加部、３０記憶部、４０ユーザＰＣ、４２メールクライアント、４４Ｗｅｂブラウザ、５０ＩＤプロバイダ。

Claims

ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段と、
前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザＩＤ情報プロバイダが発行したユーザＩＤ情報を抽出し、抽出したユーザＩＤ情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段と、
を備える中継装置。
前記制御手段は、前記認証依頼として、前記ユーザＩＤ情報プロバイダのＵＲＬに対して前記待機メールアドレスを示すmailtoスキームをリダイレクト先パラメータとして付加したものを含んだ情報を送信する、ことを特徴とする請求項１に記載の中継装置。
前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから抽出した前記ユーザＩＤ情報を、前記機能実行メールの送信元の電子メールアドレスと対応づけて記憶するＩＤ記憶手段を更に備え、
前記制御手段は、前記機能実行メールを受信した場合に、前記機能実行メールの送信元のメールアドレスに対応するユーザＩＤ情報が前記ＩＤ記憶手段に記憶されていれば、前記認証依頼を送信せずに、前記ＩＤ記憶手段に記憶されているそのユーザＩＤ情報を、受信した前記機能実行メールと共に前記情報処理装置に送信する、
ことを特徴とする請求項１又は２に記載の中継装置。
前記ＩＤ記憶手段は、前記待機メールアドレスを宛先とする電子メールから前記ユーザＩＤ情報の有効期限を抽出し、抽出した有効期限を当該ユーザＩＤ情報と対応づけて記憶し、
前記制御手段は、前記機能実行メールの送信元のメールアドレスに対応するユーザＩＤ情報が前記ＩＤ記憶手段に記憶されていても、当該ユーザＩＤ情報に対応づけて記憶された有効期限が切れている場合は、当該ユーザＩＤ情報を前記情報処理装置に送信せず、前記認証依頼を前記機能実行メールの送信元に送信する、
ことを特徴とする請求項３に記載の中継装置。
コンピュータを、
ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段、
前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザＩＤ情報プロバイダが発行したユーザＩＤ情報を抽出し、抽出したユーザＩＤ情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段、
として機能させるためのプログラム。