JP2015184752A - 中継装置及びプログラム - Google Patents

中継装置及びプログラム Download PDF

Info

Publication number
JP2015184752A
JP2015184752A JP2014058302A JP2014058302A JP2015184752A JP 2015184752 A JP2015184752 A JP 2015184752A JP 2014058302 A JP2014058302 A JP 2014058302A JP 2014058302 A JP2014058302 A JP 2014058302A JP 2015184752 A JP2015184752 A JP 2015184752A
Authority
JP
Japan
Prior art keywords
mail
user
function execution
token
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014058302A
Other languages
English (en)
Other versions
JP6221871B2 (ja
Inventor
早川 博
Hiroshi Hayakawa
博 早川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujifilm Business Innovation Corp
Original Assignee
Fuji Xerox Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fuji Xerox Co Ltd filed Critical Fuji Xerox Co Ltd
Priority to JP2014058302A priority Critical patent/JP6221871B2/ja
Publication of JP2015184752A publication Critical patent/JP2015184752A/ja
Application granted granted Critical
Publication of JP6221871B2 publication Critical patent/JP6221871B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

【課題】ファイアウォール内にある情報処理装置がファイアウォール外のユーザからの指示を受け付けることができるようにするとともに、そのユーザが信頼できる者であるかどうかを情報処理装置が検証できるようにする。【解決手段】中間サーバ20は、ファイアウォール外のユーザPC40からのアプリケーションサーバ10宛の機能実行メールを受信すると、その機能実行メールを指す一意なメールアドレスと対応づけてその機能実行メールを保存すると共に、そのメールアドレスを宛先とするmailtoスキームをリダイレクト先としてIDプロバイダ50のURLに付加した記述を含む認証依頼を、その機能実行メールの送信元に返す。ユーザが認証依頼のURLを用いてIDプロバイダ50にアクセスして認証を受け、認証成功の場合、IDプロバイダ50は、そのmailtoスキームにそのユーザのIDトークンを付加したURLにユーザをリダイレクトする。【選択図】図1

Description

本発明は、中継装置及びプログラムに関する。
製造業において、部品設計を製品開発元が行い、部品製造を開発元以外の会社に委託する、委託開発が広く行われている。部品製造の工程では、委託先は、単に委託元から渡された設計図から部品を製造するだけでなく、設計変更を委託元に依頼し、これに応じて両者間で設計の調整が行われるケースもある。このような場面において、設計の調整のためのやりとりに電子メールが利用されることが多い。電子メールを利用したやりとりは、個々のユーザのメールクライアント内には残るが、これらはユーザが削除可能であり、確たる記録として保存されるわけではない。
ところで、OpenID Connectは、任意のアイデンティティプロバイダでの認証結果を利用してWebアプリケーションにアクセスするための標準技術である。例えば、委託先のユーザが自社のアイデンティティプロバイダで認証を行い、その結果発行されるIDトークン(認証結果とユーザの属性情報のセット)を委託元のWebアプリケーションに提示する。IDトークンを検証して信頼に足るユーザであると判断できれば、委託先のユーザはそのWebアプリケーションを利用することができる。Webアプリケーションとして、電子掲示板のような機能を持つアプリケーションを用い、委託元と委託先がそれぞれやりとり情報をそのWebアプリケーションに登録することで、両者間のやりとりをシステム上の記録として残すことができる。このとき、ユーザに対してWebアプリケーションがIDトークンの提示を求めることで、信頼できないユーザからの要求を受け付けないようにすることができる。
ここでOpenID Connectは、HTTPS(HyperText Transfer Protocol Secure)プロトコルを利用したWebアプリケーションが前提とされているため、ネットワークがファイアウォールで区切られている環境では、VPN(Virtual Private Network)により専用の通信経路を用意する必要がある。したがって、上述した委託元のWebアプリケーションに委託元・委託先間のやりとりの情報を集約するシステムを構築するには、委託先のユーザのPC(パーソナルコンピュータ)に都度VPNの設定作業をするという作業負担が生じる。また、VPN接続用のクレデンシャルを各ユーザが管理する必要があり、セキュリティ上のリスクにつながる。
また、特許文献1には、シングルサインオンシステムにおいて、認証サービス(セキュリティトークンサービス)の負荷を軽減する仕組みが開示されている。この仕組みでは、認証サービスとアプリケーションサービスプロバイダ(以下「プロバイダ」と呼ぶ)との間にプロキシサービスが設けられる。プロプロキシサービスは、認証サービスによる認証結果を保存し、一定条件の下、プロバイダから受け取った認証要求を認証サービスに転送せず、自身が保存する認証結果に基づいてクライアント認証を代行する。
また、特許文献2に開示されたシステムでは、メールサーバとメールクライアントの間に介在するプロキシサーバが、メールクライアントからの指示に応じて、メールサーバからそのメールクライアント宛の電子メールを取得する。そして、プロキシサーバは、取得した電子メールに対してそのメールクライアントに対応する設定に応じた加工を施し、加工済みの電子メールをそのメールクライアントに送信する。
特開2005−62556号公報 特開2002−63116号公報
本発明は、ファイアウォール内にある情報処理装置がファイアウォール外のユーザからの指示を受け付けることができるようにするとともに、そのユーザが信頼できる者であるかどうかを情報処理装置が検証できるようにすることを目的とする。
請求項1に係る発明は、ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段と、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザID情報プロバイダが発行したユーザID情報を抽出し、抽出したユーザID情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段と、を備える中継装置である。
請求項2に係る発明は、前記制御手段は、前記認証依頼として、前記ユーザID情報プロバイダのURLに対して前記待機メールアドレスを示すmailtoスキームをリダイレクト先パラメータとして付加したものを含んだ情報を送信する、ことを特徴とする請求項1に記載の中継装置である。
請求項3に係る発明は、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから抽出した前記ユーザID情報を、前記機能実行メールの送信元の電子メールアドレスと対応づけて記憶するID記憶手段を更に備え、前記制御手段は、前記機能実行メールを受信した場合に、前記機能実行メールの送信元のメールアドレスに対応するユーザID情報が前記ID記憶手段に記憶されていれば、前記認証依頼を送信せずに、前記ID記憶手段に記憶されているそのユーザID情報を、受信した前記機能実行メールと共に前記情報処理装置に送信する、ことを特徴とする請求項1又は2に記載の中継装置である。
請求項4に係る発明は、前記ID記憶手段は、前記待機メールアドレスを宛先とする電子メールから前記ユーザID情報の有効期限を抽出し、抽出した有効期限を当該ユーザID情報と対応づけて記憶し、前記制御手段は、前記機能実行メールの送信元のメールアドレスに対応するユーザID情報が前記ID記憶手段に記憶されていても、当該ユーザID情報に対応づけて記憶された有効期限が切れている場合は、当該ユーザID情報を前記情報処理装置に送信せず、前記認証依頼を前記機能実行メールの送信元に送信する、ことを特徴とする請求項1〜3のいずれか1項に記載の中継装置である。
請求項5に係る発明は、コンピュータを、ファイアウォール内の情報処理装置が提供する機能に対応づけられた電子メールアドレスを宛先とする電子メールである機能実行メールを受信した場合、認証待ちメール記憶手段に前記機能実行メールを保存すると共に、保存した機能実行メールを一意的に指し示す電子メールアドレスである待機メールアドレスを含んだ認証依頼を、前記機能実行メールの送信元に対して送信する制御を行う制御手段、前記待機メールアドレスを宛先とする電子メールを受信した場合に、当該電子メールから、あらかじめ定められたユーザID情報プロバイダが発行したユーザID情報を抽出し、抽出したユーザID情報を前記保存した機能実行メールと共に前記情報処理装置に送信する手段、として機能させるためのプログラムである。
請求項1又は5に係る発明によれば、ファイアウォール内にある情報処理装置がファイアウォール外のユーザからの指示(機能実行メール)を受け付けることができるようにするとともに、そのユーザが信頼できる者であるかどうかを情報処理装置が検証できるようにすることができる。
請求項2に係る発明によれば、機能実行メールを送信したユーザは、中間サーバからの認証依頼に含まれるURLを用いてユーザID情報プロバイダにアクセスして認証を受けることができるとともに、認証が成功した場合、ユーザID情報プロバイダからのリダイレクトにより、自分のユーザID情報を中間サーバに渡すことができる。
請求項3に係る発明によれば、ユーザは、中間サーバに自分のユーザID情報を渡すと、その後機能実行メールを送信した際に、再びユーザID情報プロバイダからユーザID情報を取得する必要がなくなる。
請求項4に係る発明によれば、情報処理装置がユーザID情報の検証を行う前に、そのユーザID情報の有効期限切れを中間サーバで検知し、ユーザに対してユーザID情報の再提出を依頼することができる。
本発明の一実施形態のシステムの一例を示す図である。 アプリケーションサーバの機能に対応するメールアドレスと、その機能の実行のために呼び出すAPlのURLとの対応関係の例を示す図である。 IDプロバイダによる認証及びIDトークンの発行の一例を示す図である。 中間サーバの記憶部に記憶されるデータの例を示す図である。 機能実行メールを受信した時の中間サーバの処理手順の一例を示す図である。 認証依頼メールに記載されるURL、及びIDプロバイダにおける認証が成功した場合のリダイレクト先を示すURLの構成を説明するための図である。 IDトークン送付メールを受信した時の中間サーバの処理手順の一例を示す図である。
図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等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。また、個々でいうコンピュータは、クラウドコンピューティングシステム上の仮想マシンであってもよい。
10 アプリケーションサーバ、12 IDトークン抽出部、14 IDトークン検証部、20 中間サーバ、22 認証依頼送信部、24 IDトークン付加部、30 記憶部、40 ユーザPC、42 メールクライアント、44 Webブラウザ、50 IDプロバイダ。

Claims (5)

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

JP2014058302A 2014-03-20 2014-03-20 中継装置及びプログラム Active JP6221871B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014058302A JP6221871B2 (ja) 2014-03-20 2014-03-20 中継装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014058302A JP6221871B2 (ja) 2014-03-20 2014-03-20 中継装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2015184752A true JP2015184752A (ja) 2015-10-22
JP6221871B2 JP6221871B2 (ja) 2017-11-01

Family

ID=54351258

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014058302A Active JP6221871B2 (ja) 2014-03-20 2014-03-20 中継装置及びプログラム

Country Status (1)

Country Link
JP (1) JP6221871B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10305839B2 (en) * 2015-11-17 2019-05-28 Clover Leaf Environmental Solutions, Inc. Electronic information system enabling email-based transactions with forms
CN115225306A (zh) * 2021-04-20 2022-10-21 丰田自动车株式会社 认证系统
WO2023148807A1 (ja) * 2022-02-01 2023-08-10 三菱電機株式会社 通信機器、通信システム、通信方法及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004104346A (ja) * 2002-09-06 2004-04-02 Murata Mach Ltd サーバ装置
US20070143408A1 (en) * 2005-12-15 2007-06-21 Brian Daigle Enterprise to enterprise instant messaging
JP2010157003A (ja) * 2008-12-24 2010-07-15 At System:Kk メールアドレス所有者の本人確認方法、メールアドレスに対する登録者名登録方法、及びグループ別メールアドレス登録方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004104346A (ja) * 2002-09-06 2004-04-02 Murata Mach Ltd サーバ装置
US20070143408A1 (en) * 2005-12-15 2007-06-21 Brian Daigle Enterprise to enterprise instant messaging
JP2010157003A (ja) * 2008-12-24 2010-07-15 At System:Kk メールアドレス所有者の本人確認方法、メールアドレスに対する登録者名登録方法、及びグループ別メールアドレス登録方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10305839B2 (en) * 2015-11-17 2019-05-28 Clover Leaf Environmental Solutions, Inc. Electronic information system enabling email-based transactions with forms
US11496431B2 (en) * 2015-11-17 2022-11-08 Clover Leaf Capital Llc Email-based transactions with forms
CN115225306A (zh) * 2021-04-20 2022-10-21 丰田自动车株式会社 认证系统
WO2023148807A1 (ja) * 2022-02-01 2023-08-10 三菱電機株式会社 通信機器、通信システム、通信方法及びプログラム

Also Published As

Publication number Publication date
JP6221871B2 (ja) 2017-11-01

Similar Documents

Publication Publication Date Title
JP7090800B2 (ja) 分散型文書およびエンティティ検証エンジン
JP5651112B2 (ja) デジタルidを用いたフォーム入力および自動パスワード生成
JP6929181B2 (ja) デバイスと、その制御方法とプログラム
US10375177B1 (en) Identity mapping for federated user authentication
US20130019295A1 (en) Method and system for open authentication
US10135810B2 (en) Selective authentication system
US20070244989A1 (en) Remote Automated Volume Mounting
JP2017503254A (ja) ウェブサイトにログインしている端末がモバイル端末であるかどうかを決定するための方法およびシステム
JP6064636B2 (ja) 情報処理システム、情報処理装置、認証方法及びプログラム
US20140325684A1 (en) Sensitive information leakage prevention system, sensitive information leakage prevention method, and computer-readable recording medium
US10986081B1 (en) Cross-organization registration for single sign-on
KR20110055542A (ko) 유저 인증을 관리하기 위한 장치
JP6575052B2 (ja) アクセス制御システム及びプログラム
US20150324598A1 (en) Method and System for Managing Uniquely Identifiable Bookmarklets
JP6221871B2 (ja) 中継装置及びプログラム
US20160205091A1 (en) Information processing system, control method of information processing apparatus, and storage medium
US9027107B2 (en) Information processing system, control method thereof, and storage medium thereof
JP5707204B2 (ja) 身元確認システムおよび身元確認方法
JP6178112B2 (ja) 認証サーバ、認証システム及びプログラム
JP2004046460A (ja) ファイル管理システムにおけるアクセス制御方式
JP6199506B2 (ja) 複数のサービスシステムを制御するサーバシステム及び方法
JP5417628B2 (ja) 署名サーバ、署名システム、および、署名処理方法
JP2012033042A (ja) シングルサインオンシステム及びシングルサインオン方法
JP2009093580A (ja) ユーザ認証システム
JP6848275B2 (ja) プログラム、認証システム及び認証連携システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160722

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170524

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170627

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170823

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170918

R150 Certificate of patent or registration of utility model

Ref document number: 6221871

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350