図1に、本発明の一実施形態のシステムを例示する。図1に例示するシステムは、アプリケーションサーバ10、中間サーバ20、ユーザPC40及びIDプロバイダ50を含む。
アプリケーションサーバ10及び中間サーバ20は、ファイアウォールによりインターネットから隔てられた組織Aの内部ネットワーク内に設けられている。また、ユーザPC(パーソナルコンピュータ)40及びIDプロバイダ50は、ファイアウォールによりインターネットから隔てられた、組織Aとは異なる組織Bの内部ネットワーク内に設けられている。
組織A及び組織Bは、企業、学校、各種団体等といった様々な形態の組織のいずれであってもよい。組織AとBとは何らかの協力関係にあり、組織Aのアプリケーションサーバ10は、組織A内のユーザに対してそのユーザの権限に応じた機能を提供すると共に、組織B内のユーザにもいくつかの機能を提供する。実際の運用例をイメージしやすくするために具体例を挙げると、例えば組織Aは委託元の企業、組織Bは委託先の企業である。
アプリケーションサーバ10及び中間サーバ20は、それぞれ別々のコンピュータ装置上に実装してもよいし、同一のコンピュータ装置で実行される別々のプログラムとして実装してもよい。なお、アプリケーションサーバ10及び中間サーバ20は、1台のコンピュータ装置に限られるものではない。複数台のコンピュータ装置が連携してそれら各サーバの機能を実現する構成であってもよい。
アプリケーションサーバ10は、ユーザに対してアプリケーションソフトウエアの機能を提供するサーバである。
例えば、アプリケーションサーバ10がWebアプリケーションサービスを提供するものである場合、そのサービスを利用しようとするユーザは、HTTP(HyperText Transfer Protocol)を用いてアプリケーションサーバ10にアクセスする必要がある。ここで、組織Aのファイアウォールがインターネット側からのHTTPリクエストを遮断する設定となっていれば、組織A内のユーザはアプリケーションサーバ10のサービスを利用できるが、組織B内のユーザはHTTP経由ではそのサービスを利用することはできない。ただし、これでは組織AとBが協業する場合などにアプリケーションサーバ10をその道具として用いることができない。
そこで、本実施形態のアプリケーションサーバ10は、当該サーバが提供する機能のうちの少なくとも1つについて、その機能の実行の指示を電子メールで受け付けることができるよう構成されている。一般にファイアウォールは電子メールを遮断しないので、電子メールを用いることで、組織B内のユーザがファイアウォールを越えて組織A内のアプリケーションサーバ10に指示を送ることが可能となる。
アプリケーションサーバ10が提供するアプリケーションサービスとしては、これに限定されるわけではないが、例えば電子掲示板サービスがある。電子掲示板サービスを提供する場合、アプリケーションサーバ10は、電子掲示板サービスに関する諸機能のうち例えば記事の投稿や新たなスレッド(話題、トピック、タスクとも呼ばれる)の作成等といった少なくとも1つの機能についての実行指示を、一般的なHTTPリクエストの形だけでなく、電子メールの形でも受け付けることができる。このようにすることで、組織Bのユーザは、電子掲示板システム上の組織Aのあるプロジェクトの掲示板(又はスレッド)への投稿を指示する電子メールをアプリケーションサーバ10に送ることで、組織Aのそのプロジェクトのメンバと連絡を取ることが可能になり、かつその連絡事項が掲示板に記録されることとなる。
電子メールによる機能実行指示は、例えば、その機能に対応するあらかじめ定められた電子メールアドレス(以下「メールアドレス」という)に対してユーザが電子メールを送ることで実現される。例えば電子掲示板への投稿は、投稿記事の見出し及び本文をそれぞれ件名及び本文とする電子メールを、アプリケーションサーバ10の投稿受付機能のメールアドレス宛に送ることにより実現される。このように、アプリケーションサーバ10の提供する機能に対応するメールアドレスを宛先とした電子メールのことを、以下では機能実行メールと呼ぶことにする。
機能実行メールによる指示の受付の仕組みとしては、例えば、図2に例示するように、機能に対応するメールアドレスとその機能のAPI(Application Programming Interface)との対応関係の情報を用いる方式がある。アプリケーションサーバ10は、その対応関係の情報を参照可能であり、受信した機能実行メールの宛先メールアドレスに対応するAPIをその対応関係から求め、求めたAPIを実行することで、ユーザが指示する機能を実行する。
さて、このようにアプリケーションサーバ10が機能実行の指示を電子メールで受付できるようにした場合、情報セキュリティ上、アクセスを認めるものとしてあらかじめ定めた組織(この例では組織B)に属さないユーザが電子メールでその機能を利用することがないようにするために、一種のアクセス制御が必要となる。本実施形態では、このようなアクセス制御のために、IDプロバイダ50が発行するIDトークンを利用する。
IDプロバイダ50は、ユーザのアイデンティティ(ID)を証明する情報(すなわちIDトークン)を提供するプロバイダである。IDプロバイダ50は、ユーザを認証し、その認証が成功した場合に、そのユーザのID情報を含んだIDトークンを発行する。IDプロバイダ50の具体例は、例えばOpenID Connectに準拠したOpenID Providerである。
図示例では、IDプロバイダ50は組織B内に設けられており、組織Bに属するユーザのIDを証明するIDトークンを発行する。組織A内のアプリケーションサーバ10及び中間サーバ20にはIDプロバイダ50が「信頼できるIDプロバイダ」としてあらかじめ登録されており、アプリケーションサーバ10及び中間サーバ20はそのIDプロバイダ50が発行したIDトークンを信用する。例えばアプリケーションサーバ10は、組織B内のユーザPC40から到来した機能実行メールにIDプロバイダ50が発行したIDトークンが付加されている場合、その機能実行メールがそのIDトークンの示すユーザからのものであると認識する。例えば、記事の投稿を指示する機能実行メールを受け取った場合、そのメールに含まれる記事内容を、そのメールに付加されたIDトークンが示すユーザからの投稿として電子掲示板に登録する。
アプリケーションサーバ10が有するIDトークン抽出部12は、機能実行メールからIDトークンを抽出する。IDトークン検証部14は、抽出したIDトークンに付されたIDプロバイダ50の電子署名やIDトークンの有効期限などの検証を行う。IDトークンの検証は、そのIDトークンが準拠しているOpenID Connect等のアイデンティティシステム標準に従って行われる。
中間サーバ20は、組織Aの内部ネットワーク上に配置された中継装置であり、インターネット側からのアプリケーションサーバ10宛の機能実行メールを代理受信し、アプリケーションサーバ10へと中継する。この中継の際、中間サーバ20は、その機能実行メールに対して、IDプロバイダ(組織B内のユーザからのメールの場合、IDプロバイダ50)が発行したそのユーザのIDトークンを付加する。この処理を担うのがIDトークン付加部24である。
ここで、例えば組織B内のユーザからの機能実行メールにIDトークンを付加するためには、IDプロバイダ50からそのユーザのIDトークンを取得する必要がある。このために中間サーバ20は、組織B内のユーザに対して、IDプロバイダ50から自分(そのユーザ)のIDトークンを取得するよう誘導するための処理を行う。この処理を担うのが認証依頼送信部22である。認証依頼送信部22は、認証依頼メールと呼ぶ電子メールを作成し、これをユーザ側に送ることで、ユーザがIDプロバイダ50からIDトークンを取得するように誘導する。認証依頼送信部22及びIDトークン付加部24の詳細については後で詳しく説明する。
記憶部30は、中間サーバ20の処理のために必要な情報を記憶する装置である。記憶部30は、中間サーバ20内に設けられてもよいし、ネットワーク上の中間サーバ20からアクセス可能な場所に設けられてもよい。
ユーザPC40は、組織Bのファイアウォール内の内部ネットワーク上に設置されたパーソナルコンピュータである。ユーザPC40は、メールクライアント42とWebブラウザ44を有する。
メールクライアント42は電子メールの送受信を行うクライアントアプリケーションである。本実施形態では、組織Bのユーザは、組織A内のアプリケーションサーバ10に対してある機能の実行を指示しようとする場合、メールクライアント42を操作してその機能に対応するあらかじめ定められたメールアドレスを宛先とする機能実行メールを作成し、送信する。図1の例では、メールクライアント42は、S/MIME(Secure / Multipurpose Internet Mail Extensions)に従った電子メールを組織A側とやり取りする。ただし、S/MIMEを用いることは一例に過ぎない。またメールクライアント42は、中間サーバ20から認証依頼メールを受け取ったり、この認証依頼メールに誘導されたIDトークン取得処理によりIDプロバイダ50から取得したIDトークンを中間サーバ20に送信したりする。メールクライアント42は、特別なものである必要はなく、通常のPCにインストールされている既存のものでよい。また、ユーザPC40にインストールされているメールクライアント42の代わりに、Webアプリケーションとして提供されるメールクライアントをWebブラウザ44から利用する形でもよい。
Webブラウザ44は、World Wide Webを利用するために用いられるアプリケーションである。本実施形態では、Webブラウザ44は、IDプロバイダ50からユーザ認証を受け、IDトークンを取得するために用いられる。Webブラウザ44も、特別なものである必要はなく、通常のPCにインストールされている既存のものでよい。
IDプロバイダ50は、認証依頼メールをトリガとして発せられるユーザPC40からの要求に応じて、そのユーザを証するIDトークンを発行する。以下の例では、IDプロバイダ50はOpenID Connect Implicit Client Profileの仕様に準拠しているものとする。
IDプロバイダ50は、例えば図3に例示するテーブル群を用いて、IDトークンの発行処理を行う。図3において、パスワードテーブル52は、認証対象の各ユーザのパスワード情報を保持するテーブルである。パスワードテーブル52の項目「識別子」は、このテーブルの各エントリの識別情報であり、ユーザ毎の一意な値である。「パスワードハッシュ」及び「ソルト」は、ユーザが入力したパスワードが正しいか否かの判定に用いる情報である。パスワードハッシュ及びソルトを用いたパスワード検証方法は周知であるし、またパスワードハッシュ等を用いた検証はIDプロバイダ50が用いるユーザ認証方法のあくまで一例としてあげるに過ぎないので、これ以上の説明は省略する。ユーザ属性テーブル54は、認証対象の各ユーザの属性情報を保持するテーブルである。図3には、ユーザの属性情報として、従業員ID、メールアドレス、所属部署名等を例示している。ユーザ属性テーブル54の「識別子」は、パスワードテーブル52で用いられる「識別子」と同じものであり、両テーブルで識別子の値が同一のエントリは同一のユーザについてのものである。属性変換テーブル56は、ユーザ属性テーブル54内の各属性項目をIDトークンに組み込むときのパラメータ名を保持するテーブルである。例えば「従業員ID」の値は、「employeeID」というパラメータの値としてIDトークンに組み込まれる。
IDプロバイダ50は、例えばユーザに従業員ID又はメールアドレスとパスワードとの入力を求め、これに応じて入力されたパスワードがその従業員ID又はメールアドレスに対応するパスワードであることがパスワードハッシュ等により検証できれば、そのユーザが正当なユーザであると判定する。この場合、IDプロバイダ50は、そのユーザのアイデンティティ情報(例えばメールアドレス)や指定されたその他のユーザ属性情報を含んだIDトークンを発行する。なお図4に例示したテーブル群はあくまで一具体例に過ぎない。IDプロバイダ50は、準拠するアイデンティティシステム標準に定められた情報を保持していればよく、その情報に従ってユーザ認証やIDトークンの発行等の処理を行う。
図1では、組織Bのユーザを認証するIDプロバイダ50が組織Bの内部ネットワーク内にあるが、これは必須のことではない。
次に、図4を参照して、中間サーバ20の処理のために記憶部30に記憶される情報の例を説明する。図示のように、記憶部30は、IDプロバイダテーブル32、IDトークンテーブル34及び認証待ちテーブル36を記憶する。
IDプロバイダテーブル32は、中間サーバ20及びアプリケーションサーバ10が信頼するIDプロバイダ50の情報を保持する。IDプロバイダテーブル32が保持する情報は、ドメインとそのドメインに対応するIDプロバイダのエンドポイントURL(Uniform Resource Locator)である。例えばユーザがこのエンドポイントURLに対してアクセスすると、そのURLに対応するIDプロバイダから、ユーザ認証のためにWebページがユーザに返される。中間サーバ20は、IDプロバイダテーブル32のある「ドメイン」内のメールアドレスから送信された機能実行メールに対して、認証のために、その「ドメイン」に対応する「エンドポイントURL」のIDプロバイダが発行したIDトークンを要求する。
IDトークンテーブル34は、(例えば認証依頼メールをトリガとする認証処理の結果)ユーザから提出されたIDトークンを保持するテーブルである。このテーブルには、ユーザのメールアドレスと、IDプロバイダ50が発行したそのユーザのIDトークンとが互いに対応づけて登録される。なお、IDプロバイダ50が、ユーザ認証に応じて、IDトークンに加え、そのユーザに関する他のパラメータ(例えばユーザの属性情報、IDトークンの有効期限)も併せて発行する場合は、それら他のパラメータもIDトークンテーブル34に登録する。中間サーバ20は、ユーザがIDトークンを提出した後、そのIDトークンが有効な間は、そのユーザからの電子メールにIDトークンが付加されていなければ、IDトークンテーブル34に記憶したそのユーザのIDトークンをその電子メールに付加してアプリケーションサーバ10に渡す。
認証待ちテーブル36は、IDトークンを未提出のユーザから機能実行メールを受信した場合に、そのユーザがIDトークンを提出するまでその機能実行メールを保留しておくために用いる。認証待ちテーブル36の項目「機能実行メール」にはその機能実行メールのデータを記憶する。認証待ちテーブル36の項目「リダイレクトURL」は、そのようにして保留した「機能実行メール」を一意に識別する識別情報として機能するURLである。リダイレクトURLは、「mailto:」スキームのURLであり、図示例では、以下の形式の文字列である。
mailto:${一意性のあるランダム文字列}@${アプリケーションサーバ10で規定されたドメイン名}
このリダイレクトURLは、「:${一意性のあるランダム文字列}@${アプリケーションサーバ10で規定されたドメイン名}」が表すメールアドレスに対して電子メールを送信するようメールクライアントに指示するURLである。リダイレクトURLのうち一意性のあるランダム文字列の部分は、保留した機能実行メールを識別する識別情報として機能する。またアプリケーションサーバ10で規定されたドメイン名の部分は、保留した機能実行メールがそのアプリケーションサーバ10に宛てたものであることを示す。したがって、ユーザが、例えば、あるWebページ上の、そのリダイレクトURLがHREF属性として設定されたアンカー要素(A要素)をクリックすると、Webブラウザはメールクライアントを起動する。起動されたメールクライアントは、そのリダイレクトURL中の、保留メールの識別情報とアプリケーションサーバ10に対応するドメイン名からなるメールアドレスを宛先に設定した電子メールの作成画面を表示する。ユーザがそのメール作成画面で作成中の電子メールの送信を指示すると、そのメールアドレスに対して送信される。このメールアドレスはアプリケーションサーバ10に対応するドメイン内のものなので、中間サーバ20により受信されることとなる。なお、詳しくは後で説明するが、このリダイレクトURLを用いて送信される電子メールは、組織B内のユーザがIDプロバイダ50から取得した自分のIDトークンを中間サーバ20(ひいてはアプリケーションサーバ10)に提出するために用いられる。IDプロバイダ50からIDトークンの取得及び中間サーバへの提出のための処理(いわば中間サーバ20からみたそのユーザの認証処理)にユーザを誘導するために、中間サーバ20の認証依頼送信部22はそのユーザ宛に認証依頼メールを送るが、リダイレクトURLはその認証依頼メールに組み込まれる。
次に、図5を参照して、機能実行メールを受信した際の、中間サーバ20の処理手順の一例を説明する。受信した電子メールが機能実行メールであるか否かは、その電子メールの宛先のメールアドレスが、アプリケーションサーバ10の機能(図2の例ではAPI)に対応するメールアドレスであるか否かにより判定される。
受信した電子メールが機能実行メールであった場合、中間サーバ20は、その電子メールから送信元メールアドレスを抽出し(S10)、その送信元メールアドレスに対応する有効なIDトークンがIDトークンテーブル34内にあるか否かを調べる(S12)。ここで有効なIDトークンとは、設定されている有効期限がすぎていないIDトークンのことである。中間サーバ20は、例えば、その送信元メールアドレスに対応するIDトークンがIDトークンテーブル34にあるかどうかを調べ、ある場合には、そのIDトークンの有効期限が切れていないかをチェック(必要ならIDプロバイダ50に有効期限を確認する)し、有効期限が切れていなければそのIDトークンが有効であると判定する。すなわち、S12の判定結果はYesとなる。送信元メールアドレスに対応するIDトークンがIDトークンテーブル34にないか、あってもその有効期限が切れている場合は、S12の判定結果はNoとなる。
S12の判定結果がYesの場合、中間サーバ20のIDトークン付加部24が、その機能実行メールに対してその有効なIDトークンを付加し(S14)、IDトークン付加済みの機能実行メールをアプリケーションサーバ10に送信する(S16)。機能実行メールに対するIDトークンの付加は、例えば、その機能実行メールのヘッダ部に対して行う。
S12の判定結果がNoの場合、認証依頼送信部22が呼び出される。呼び出された認証依頼送信部22はリダイレクトURLを生成する(S18)。生成されたリダイレクトURLは、その機能実行メールを一意に識別する識別情報(例えば乱数値)を含む。リダイレクトURLについては上で説明したので、ここではこれ以上の説明は省略する。次に認証依頼送信部22は、当該機能実行メールを、そのリダイレクトURLに対応づけて認証待ちテーブル36に格納する(S20)。そして、そのリダイレクトURLを含んだ認証依頼メールを生成し、その認証依頼メールを機能実行メールの送信元のメールアドレスに対して返信する(S22)。
ここで、認証依頼送信部22がその送信元に返信する認証依頼メールは、アプリケーションサーバ10の機能を利用するには認証が必要であることを説明する文面を含む。また、リダイレクトURLは、その送信元のドメインに対応するIDプロバイダ50のエンドポイントURLに対してパラメータとして含まれ、そのエンドポイントURLが認証依頼メールに組み込まれる。送信元のドメインに対応するIDプロバイダ50のエンドポイントURLは、IDプロバイダテーブル32から取得できる、このようにリダイレクトURLをパラメータとして含んだIDプロバイダ50のエンドポイントURLのことを、以下では「認証誘導URL」と呼ぶ。
認証依頼メールに組み込まれる認証誘導URLの例を、図6の(A)に示す。図示のように、この認証誘導URLは、IDプロバイダ50のエンドポイントURLの後に、パラメータとしてリダイレクトURL、及びその他のパラメータ(もしあれば)が、クエリ文字列の形で付加されて構成されたものである。リダイレクトURLは、「redirect_uri」という変数名で示されている。パラメータ「redirect_uri」は、OpenID Connectに規定されるパラメータであり、認証後のリダイレクト先(すなわち認証結果の応答の宛先)のURI(Uniform Resource Identifier)を示す。このパラメータに、前述のリダイレクトURLの値が設定される。また、その他のパラメータとして図に例示している「response_type」もOpenID Connectに規定されるパラメータの1つであり、使用されるべき認証処理フローを規定する値を示す。図示された「response_type」の値「id_token」は、認証処理フローとしてImplicit Client Profileに規定されたImplicit Flow(インプリシット・フロー)を用いることを示す。
認証依頼メールを受け取ったユーザは、メールクライアント42上で、その認証依頼メールの本文内に含まれる認証誘導URLをクリックする。すると、Webブラウザ44が起動され、その認証誘導URL(IDプロバイダ50のエンドポイントを指している)にアクセスする。このとき、認証誘導URLに含まれる「redirect_uri」等のパラメータがIDプロバイダ50に伝達される。このアクセスに応じ、ユーザは、そのIDプロバイダ50の認証方式でユーザ認証を行う。例えば、IDプロバイダ50は、認証用のWebページをWebブラウザ44に返し、ユーザは、その認証用Webページに対して、IDプロバイダ50が要求する認証情報、例えばユーザID(メールアドレス等)とパスワードの組、等を入力し、入力結果をIDプロバイダ50に送信する。IDプロバイダ50は、Webブラウザ44から受け取った認証情報によりユーザ認証を行う。このユーザ認証が成功した場合、IDプロバイダ50は、認証誘導URLに対するアクセス時にWebブラウザ44から伝達された「redirect_uri」パラメータが示すリダイレクトURLに対してパラメータを付加し、ユーザからの上記アクセスをパラメータ付加後のリダイレクトURLにリダイレクトする。ここでリダイレクトURLに付加するパラメータは、例えばOpenID Connectの「End-User Grants Authorization」の仕様に準拠したパラメータであり、例えば認証誘導URLに対するアクセス時に伝達された「他のパラメータ」により決まるパラメータを含んでもよい。例えば、図6(A)に例示した認証誘導URLは、「response_type」として「id_token」を指定しているので、IDプロバイダ50は、ユーザ認証が成功した場合、そのURLへのアクセスを、当該ユーザのIDトークンをパラメータとして含んだリダイレクトURLにリダイレクトする。
ユーザに対する認証が成功した後の、パラメータが設定されたリダイレクトURLの例を図6の(B)に示す。このURLは、認証誘導URL(図6(A))に含まれるリダイレクトURLの後に、そのユーザのIDトークン(パラメータ名「id_token」)と、他のパラメータ(もしあれば)とが、クエリ文字列の形で付加される形で構成されている。図では、他のパラメータとしてIDトークンのタイプを示す「token_type」及びそのIDトークンの有効期限を示す「expire」等が示されている。
認証成功後のリダイレクト先はmailtoスキームなので、Webブラウザ44からメールクライアント42が起動され、起動されたメールクライアント42のメール作成画面に、リダイレクトURL内のメールアドレスを宛先とし、当該ユーザのメールアドレスを送信元とする電子メールが表示される。この電子メールのヘッダには、IDプロバイダ50がリダイレクトURLに付加したパラメータ(IDトークンなど)が組み込まれる。この電子メールを、IDトークン送付メールと呼ぶ。ユーザが、そのメール作成画面に対して送信操作を行うと、そのIDトークン送付メールがその宛先へと送信される。その宛先は、前述のリダイレクトURLの説明に示したとおり、アプリケーションサーバ10に規定されるドメイン内のものなので、中間サーバ20により受信される。
次に、IDトークン送付メールを受信した場合の中間サーバ20の処理手順の例を、図7を参照して説明する。なお、中間サーバ20は、受信したアプリケーションサーバ10宛の電子メールが機能実行メール(すなわち特定の機能に対応するあらかじめ定められたメールアドレス宛のメール)でなければ、その電子メールはIDトークン送付メールであると仮定して図7の処理を進める。
この手順では、まず中間サーバ20は、そのIDトークン送付メールから宛先メールアドレスを抽出し(S30)、その宛先メールアドレスに対応する機能実行メールが認証待ちテーブル36内に存在するかどうかを調べる(S32)。存在すれば(S32の判定結果がYes)、IDトークン付加部24がその機能実行メールを認証待ちテーブル36から取り出し、IDトークン送付メールに含まれるIDトークン及びその他のパラメータ(もしあれば)をその機能実行メール(の例えばヘッダ)に付加する(S34)。なお、そのIDトークン送付メールがIDトークンを含んでいなければ、S34の処理はエラーとなり、所定のエラー処理が行われる。そして、IDトークン付加部24は、IDトークン付加済みの機能実行メールを、アプリケーションサーバ10に渡す(S36)。また、中間サーバ20は、そのIDトークン送付メールに含まれるIDトークン及びその他のパラメータを、IDトークン送付メールの送信元メールアドレス(これは、対応する機能実行メールの送信元と同じ)と対応づけて、IDトークンテーブル34に格納する(S38)。そのIDトークンが有効な間にそのユーザから別の機能実行メールが来た場合、中間サーバ20は、認証依頼メールを送ることなく、IDトークンテーブル34に格納されたそのIDトークンを自動的にその機能実行メールに付加することとなる(図5のS14)。
なお、S32の判定結果がNoになるのは例外的なケースであり、この場合中間サーバ20はエラーメッセージを提示し(S39)、処理を終了する。エラーの提示は、例えばその電子メールの送信元に対して電子メールの形で行う。
図7のS32の判定がYesとなった後、IDトークン送付メールからIDトークンの情報が取り出せた場合、中間サーバ20が、その情報に含まれるユーザ(そのIDトークンが身元証明する対象のユーザ)のメールアドレスと、そのIDトークン送付メールの送信元メールアドレスが一致するかどうかを検証してもよい。一致する場合はS34に進み、一致しない場合はエラーとする。この検証により、そのメールが、そのIDトークンが証明するユーザのメールアドレスから送信されたものである場合にのみ、そのIDトークンがアプリケーションサーバ10に渡されることとなる。なお、この検証のためには、IDプロバイダ50は、ユーザ認証の結果としてリダイレクトするリダイレクト先のURLのパラメータに、認証したユーザのIDトークンに加え、そのユーザのメールアドレスを含めればよい。
以上、本実施形態のシステム構成及び処理内容について説明した。次に、アプリケーションサーバ10からみて未認証のユーザがアプリケーションサーバ10に対して機能の実行を要求する場合、本実施形態のシステムの処理がどうなるのかを、図1の(1)〜(11)の符号で示した情報の流れに沿って説明していく。なお、ここでいう「ユーザが未認証である」とは、そのユーザが自分のIDトークンを(IDトークン送付メールにより)中間サーバ20に一度も提出していない、又はそのユーザが過去に提出したIDトークンが全て期限切れとなっていることを指す。
(0)(事前準備)
IDプロバイダ50とアプリケーションサーバ10の間で、IDトークンの署名検証のためのネゴシエーション(具体的な処理内容は、OpenID Connectの仕様に従う)をしておく。また、IDプロバイダテーブル32に、IDプロバイダ50が認証するユーザのメールアドレスのドメインと、IDプロバイダ50のエンドポイントURLとを対応付けて保存しておく。
(1)ユーザは、アプリケーションサーバ10に実行させたい機能に対応するメールアドレスを宛先とする機能実行メールを作成し、送信する。
(2)中間サーバ20は、機能実行メールを受信し、送信元メールアドレスに対応するIDトークンをIDトークンテーブル34から検索する。
(3)この状況(ユーザが未認証)では、上記(2)の検索で有効なIDトークンは見つからない。この場合、リダイレクトURLを発行し、そのリダイレクトURLに紐づけて、その機能実行メールを認証待ちテーブル36に保存する。
(4)次に認証依頼送信部22が、認証依頼メールを作成し、これをその機能実行メールの送信元メールアドレスに返信する。この認証依頼メールには、認証誘導URLが含まれる。認証誘導URLは、その送信元メールアドレスのドメインに対応するIDプロバイダ50のエンドポイントURL(これはIDプロバイダテーブル32から取得される)に、上記(3)で発行したリダイレクトURLをパラメータとして付加したものである。
(5)ユーザは、受信した認証依頼メールをメールクライアント42で閲覧し、その中に含まれる認証誘導URLをクリックする。これに応じて起動したWebブラウザ44が、認証誘導URLにアクセスする。
(6)ユーザは、IDプロバイダ50の要求する認証方式でユーザ認証を行う。
(7)IDプロバイダ50は、Webブラウザ44からのアクセスの際に取得したリダイレクトURLに、IDトークン等のパラメータを付加し、パラメータ付加後のリダイレクトURLにリダイレクトする。このURLはmailtoスキームなので、メールクライアント42が起動し、メール送信画面が表示されることとなる。この送信画面で送信対象として表示されるメール(IDトークン送付メール)のヘッダには、リダイレクトURLに含まれているIDトークン等のパラメータが設定される。
(8)ユーザは、メール送信画面に表示されているIDトークン送付メールの送信操作を行う。
(9)中間サーバ20は、IDトークン送付メールを受信し、IDトークン送付メールの宛先をキーに、認証待ちテーブル36中の機能実行メールを検索する。この例では、認証待ちテーブル36には、上記(3)でその宛先に対応する機能実行メールが保存されているので、検索によりその機能実行メールが見つかる。中間サーバ20は、認証待ちテーブル36からその機能実行メールを取り出す。この取り出しの後、認証待ちテーブル36からその機能実行メールのエントリが削除される。
(10)次にIDトークン付加部24が、その機能実行メールのヘッダに、IDトークン送付メール中のIDトークンを付加し、アプリケーションサーバ10に送信する。また、そのIDトークンを、IDトークン送付メールの送信元メールアドレスに対応付けて、IDトークンテーブル34に保存する。
(11)アプリケーションサーバ10は、IDトークンが負荷された機能実行メールを受信する。この場合、IDトークン抽出部12が、その機能実行メールからIDトークンを抽出する。そして、IDトークン検証部14が、そのIDトークンを検証する。この検証のための処理は本実施形態のシステムが準拠するアイデンティティシステム標準に従ったものであり、準拠する標準がOpenID Connectであれば、OpenID Connectの仕様に従った検証が行われる。そのIDトークンが正当であり有効であると確認できると、アプリケーションサーバ10は、その機能実行メールが、そのIDトークンの示す正当なユーザからのものであると認識する。そして、そのユーザが、その機能実行メールに対応する機能を利用する権限がある場合その機能を実行する。そのユーザがその機能を実行する権限があるか否かは、例えば、IDトークンに付随するパラメータ(例えばユーザの属性情報)に基づき判定すればよい。
次に、認証済み状態のユーザがアプリケーションサーバ10に対して機能の実行を要求する場合の処理の流れを説明する。ここでの「認証済み状態」とは、認証依頼メールにより誘導される操作により自分のアイデンティティを証明するIDトークンを中間サーバ20に提出済みであり、そのIDトークンの有効期限がまだ切れていない状態をいう。
この流れでは、ユーザが機能実行メールを送信(図1の(1))すると、中間サーバ20がそれを受信し、受信した機能実行メールの送信元メールアドレスに対応するIDトークンをIDトークンテーブル34から検索する(図1の(2))。このケースでは、IDトークンテーブル34から有効なIDトークンが検索される。これに応じ、IDトークン付加部24が、そのIDトークンを機能実行メールに付加し、付加後の機能実行メールをアプリケーションサーバ10に送信する(図1の(10))。アプリケーションサーバ10は、受信した機能実行メールからIDトークンを抽出し、検証する。そして、検証が成功すると、その機能実行メールがそのIDトークンの示す正当なユーザからのものであると認識し、そのメールに対応する機能がそのユーザの権限内であれば、その機能を実行する(図1の(11))。
以上の実施形態において、例えば、IDプロバイダ50が、発行するIDトークンと共に、そのIDトークンの有効期限の情報をリダイレクトURLのパラメータに設定する場合(図6(B)のパラメータ「expire」)を考える。この場合、その有効期限の情報はIDトークンともども、IDトークン送付メールに含まれることとなる。したがって、中間サーバ20は、受信したIDトークン送付メールを解析することで、そのIDトークン送付メールに含まれるIDトークンの有効期限を求めることができる。中間サーバ20は、このようにして求めたIDトークンの有効期限を、IDトークンと対応づけてIDトークンテーブル34に登録するようにしてもよい。この場合、中間サーバ20は、ユーザから受信した機能実行メールに対応するIDトークンをIDトークンテーブル34から検索した際、そのIDトークンの有効期限を同時に取得できる。したがって、中間サーバ20は、そのIDトークンの有効期限が切れていないかどうか、その時点で判定できる。このとき、そのIDトークンの有効期限が切れていれば、中間サーバ20は、その機能実行メールの送信元メールアドレスに認証依頼メールを返信することで、送信元に対してIDトークンの再取得を依頼する。IDトークンの有効期限切れは、IDトークンを受け取ったアプリケーションサーバ10による、標準に準拠した検証によっても判定できるが、この例のように中間サーバ20で判定できるようにすれば、アプリケーションサーバ10がIDトークンを検証するのを待つ必要がないので効率がよい。
以上に説明した実施形態では、アプリケーションサーバ10及びIDプロバイダ50等がOpenID Connect のImplicit Client Profileに準拠する場合(すなわちImplicit Flowを用いる場合)の例を説明したが、本発明は、このような特定の標準に直接依存するものではない。Implicit Flowの代わりにAuthorization Code Flowを用いる場合にも、またOpenID Connect以外の他のアイデンティティシステム標準を用いる場合にも、上記実施形態の方式は適用可能である。IDトークンは、OpenID Connectにおけるユーザのアイデンティティ情報を表すデータであるが、別の標準に準拠したシステムを用いる場合はその標準でのアイデンティティ情報を用いればよい。
以上に例示したアプリケーションサーバ10、中間サーバ20、IDプロバイダ50は、例えば、汎用のコンピュータに当該装置の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで言うコンピュータは、例えば、ハードウエアとして、CPU等のマイクロプロセッサ、ランダムアクセスメモリ(RAM)およびリードオンリメモリ(ROM)等のメモリ(一次記憶)、HDD(ハードディスクドライブ)やSSD(ソリッドステートドライブ)、フラッシュメモリ等の二次記憶を制御する二次記憶コントローラ、各種I/O(入出力)インタフェース、無線又は有線のネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばI/Oインタフェース経由で、CDやDVD、ブルーレイディスクなどの可搬型ディスク記録媒体に対する読み取り及び/又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び/又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク等の通信手段経由で、フラッシュメモリ等の二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがRAMに読み出されCPU等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。また、個々でいうコンピュータは、クラウドコンピューティングシステム上の仮想マシンであってもよい。