JP2015170319A

JP2015170319A - 通信端末、セキュアログイン方法、及びプログラム

Info

Publication number: JP2015170319A
Application number: JP2014046933A
Authority: JP
Inventors: 聡史仙波; Satoshi Senba
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2014-03-10
Filing date: 2014-03-10
Publication date: 2015-09-28
Anticipated expiration: 2034-03-10
Also published as: EP2919435B1; EP2919435A1; US9479496B2; JP6256116B2; US20150256530A1

Abstract

【課題】通信端末において、ユーザ認証に用いるデバイスを外部接続して比較的容易に認証機能を追加可能とする。
【解決手段】ネットワークを介して第１のサーバ及び第２のサーバと通信可能な通信端末において、オペレーティングシステムのインタフェースを介してホストコントローラに接続されたセンサとデータを送受信する独自認証アプリケーションを備え、ユーザIDと共にセンサが検出した照合用データを第２のサーバに送信してユーザ認証を要求し、ユーザ認証が成功した場合に第２のサーバから送信されてくるパスワードを取得し、用意されたユーザIDとパスワードを第２のサーバに送信し、認証が成功した場合に送信されてくる、第１のサーバを特定する情報を含む認証応答を、第１のサーバへ送信してログインすることで第１のサーバのサービスの提供を受ける。
【選択図】図８

Description

本発明は、通信端末、セキュアログイン方法、及びプログラムに関する。

近年、スマートフォンやタブレットなどのモバイル端末から、インターネットなどのネットワークを経由して接続されるサービスサーバへのリモートログインが行われている。リモートログインのユーザ認証には、例えばパスワードが用いられる。しかし、パスワードが第三者により不正に入手されてしまうと、第三者によるリモートログインが可能となってしまう。パスワードを長くすることでセキュリティを向上することは可能であるが、モバイル端末の画面に表示されるキーボードは小さく、デスクトップPC（Personal Computer）などに比べるとキーボードの操作性が劣るので、パスワードが長くなる程ユーザへの負荷は増大してしまう。

一方、例えば指紋、静脈、虹彩などの生体認証（または、バイオメトリクス認証）や、IC（Integrated Circuit）カードやUSB（Universal Serial Bus）トークンなどのユーザ所有物を用いたユーザ認証がある。デスクトップPCなどにおいては、ユーザ認証に用いる生体センサ、情報リーダなどのデバイスを外部接続して、このような生体認証やユーザ所有物を用いた認証を比較的容易に行うことができる。しかし、モバイル端末の場合、セキュリティやビジネスモデルの制約などの理由で、モバイル端末へのデバイスドライバの追加導入、アプリケーション間の通信に使用されるプロセス間通信によるパスワードの代行入力、ブラウザプラグインによる認証サーバへのパスワードの代行返信などの機能が制限されている場合がある。このような機能制限のあるモバイル端末において、ユーザ認証に用いるデバイスを外部接続して、生体認証やユーザ所有物を用いたユーザ認証を行うことは難しい。

特開２０１１−２２１７２９号公報特開２００４−１５１９７７号公報特開２０１３−５７９８８号公報

従来のモバイル端末では、ユーザ認証に用いるデバイスを外部接続して認証機能を追加することは難しい。

そこで、１つの側面では、ユーザ認証に用いるデバイスを外部接続して容易に認証機能を追加できる通信端末、セキュアログイン方法、及びプログラムを提供することを目的とする。

一つの案によれば、ネットワークを介して第１のサーバ及び第２のサーバと通信可能な通信端末であって、
他のアプリケーションからプロセス間通信を受けて、それを引数として子プロセスを立ち上げるブラウザと、
ホストコントローラと、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出して前記ホストコントローラを制御するオペレーティングシステムと、
前記オペレーティングシステムのインタフェースを介して前記ホストコントローラに接続された前記センサとデータを送受信する独自認証アプリケーションとを備え、
前記独自認証アプリケーションは、
ユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、前記ユーザ認証が成功した場合に前記第２のサーバから送信されてくるパスワードを取得し、
前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記第２のサーバに送信したユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバから送信されてくる、前記第１のサーバを特定する情報を含む認証応答を、リダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける通信端末が提供される。

一態様によれば、ユーザ認証に用いるデバイスを外部接続して容易に認証機能を追加できる。

モバイル端末からクラウドサービスへ接続する際の構成の一例を示す図である。モバイル端末やPCからインターネットを経由してクラウドサービスへ接続する際の構成の一例を示す図である。ユーザ認証画面の一例を示す図である。代行入力による負荷軽減方法の一例を説明する図である。プラグイン導入による負荷軽減方法の一例を説明する図である。モバイル端末でのユーザIDとパスワード入力画面の一例を示す図である。一実施例におけるセキュアログイン方法の一例を説明する図である。一実施例におけるモバイル端末、統合認証サーバ、及びサービスサーバの構成の一例を示すブロック図である。独自認証クライアントアプリの構成の一例を説明するブロック図である。一実施例におけるセキュアログイン処理の一例を説明する図である。モバイル端末に表示される画面の一例を示す図である。コンピュータの構成の一例を示すブロック図である。

以下に、開示の通信端末、セキュアログイン方法、及びプログラムの各実施例を図面と共に説明する。

プログラムを実行することでユーザに提供されるワードプロセッシング機能、スケジュール機能、メール機能、ゲーム機能などのサービスは、PCなどのクライアント上でプログラムを実行することで行われる。しかし近年、プログラムの実行の大部分を、ネットワークを介してクライアントに接続されたサーバ上で行い、クライアントではブラウザのみを実行してこのブラウザ上で表示だけを行うクラウドサービスが普及している。現在、有料及び無料の各種クラウドサービスが提供されている。

クラウドサービスでは、クライアントのキッティングが不要であり、プログラムのアップデートはサーバ側だけで行えば良く、さらに、クライアント側では表示だけを行えば良いため、比較的性能の低いクライアントでもクラウドサービスを受けることができる。このため、クラウドサービスは、スマートフォンやタブレットなどのモバイル端末など、比較的に性能の低いクライアントでの使用に好適であり、モバイル端末からのクラウドサービスが利用は増加している。

図１は、モバイル端末からクラウドサービスへ接続する際の構成の一例を示す図である。図１において、モバイル端末1は、W-CDMA（Wideband Code Division Multiple Access）などの3G（3^rd Generation）の無線アクセス方式で通信可能なクライアントの一例である。このモバイル端末１は、ブラウザ、メーラ、及びその他各種アプリケーションを有する。ブラウザ、メーラ、及び各種アプリケーションのうち、外部のサービスと連携して動作するプログラムは、このプログラムの接続先のURL（Uniform Resource Locator）を記憶している。

モバイル端末１は、通信事業者の保有する無線通信用のアンテナ２とデジタルデータのやり取りを行う。アンテナ２と接続された基地局のルータ３は、モバイル端末１から送られてくるパケットが、基地局内のサーバ４宛てか、或いは、インターネット５宛てであるかを判断し、夫々へのパケットを中継する。基地局が保有するサーバ４は、例えばモバイル端末１にIPアドレスと各種設定を送信するDHCP（Dynamic Host Configuration Protocol）サーバなどで形成され、モバイル端末１がインターネット５にを介して通信できるようにするための情報をモバイル端末１に提供する。これにより、モバイル端末１は、ルータ３を介してインターネット５に接続できる。

インターネット５には複数のルータが接続され、ルータはインターネット５を介してパケットを交換できる。クラウドサービスプロバイダのルータ、或いは、このルータに至るための中継のルータも、このインターネット５の何処かに接続されている。ルータ６は、クラウドサービスプロバイダの保有するサーバ群７で構成されたネットワークと、インターネット５とを中継する。クラウドサービスプロバイダの保有するサービスサーバ群７のうち、サービスサーバ８は、モバイル端末１の要求に応答して演算を行い、モバイル端末１に応答を返信する。

上記の如く、モバイル端末１からサービスサーバ８へ接続する場合、必ず基地局とインターネット５を経由する点で、PCからサービスサーバへ接続する場合と異なる。特に、例えば中堅以上の企業では、PCを企業のイントラネットに接続し、インターネットを経由せずに企業内のサービスサーバを使用する場合が多い。モバイル端末も、Wi-Fi（Wireless-Fidelity）を用いる場合は、このような形態になるが、2G、3G、及び4Gの無線方式で通信する場合には、必ずインターネットを経由してサービスサーバに接続する。

また、企業のファイアウォールを超えて、インターネットを経由してクラウドサービスプロバイダのサービスサーバへ接続することがある。特に、中小企業では、企業の規模とコスト上の理由から、システム管理者に十分な人数を確保することができない場合が多い。このような場合、企業内にサーバを設置せず、クラウドサービスプロバイダのサービスを有償で使用する方が安価にサービスを受けられる場合がある。このため、特に機密性の高い情報を扱わないサービスにおいては、企業外のサービスサーバを使用することがある。

さらに、個人使用のPCも、サービスサーバに接続する場合は、殆どの場合はインターネットを経由する。これは、個人でサービスサーバを家庭内に置くメリットは殆ど無く、インターネットを経由してサービスサーバに接続する方が便利であるからである。

以上のように、モバイル端末や、企業及び家庭に設置されたPCから、インターネットを経由してクラウドサービスプロバイダのサービスサーバへ接続することは、一般的に行われるようになっている。

図２は、モバイル端末や、企業及び家庭に設置されたPCから、インターネットを経由してクラウドサービスへ接続する際の構成の一例を示す図である。図２において、クラウドサービスプロバイダの保有するサーバ群２１は、ルータ２９を介してインターネット２３と接続され、プログラムを実行してユーザにサービスを提供する。モバイル端末２４と、クラウドサービスプロバイダの保有するサーバ群２１の中の１台のサービスサーバ２２とは、一対一で対応する。或いは、サービスサーバ２２が仮想化されている場合には、モバイル端末２４はサービスサーバ２２内のVM（Virtual Machine）と一対一で対応する。インターネット２３には、複数のネットワークが接続可能であり、互いにパケットを交換できる。モバイル端末２４は、通信事業者の基地局やルータを介して、インターネット２３に接続される。企業内のPC２５は、企業内のイントラネットに接続され、ファイアウォールを超えるためのプロキシサーバなどを経由してインターネット２３に接続される。ユーザの家庭に設置されているPC２６は、公衆回線(ADSL:Asymmetric Digital Subscriber Line)やFTTH（Fiber To The Home）を経由してインターネット２３に接続される。

その他の機器２７は、他のネットワークを経由してインターネット２３に接続される。インターネットプロトコル（IP: Internet Protocol）に準拠した機器２７であれば、基本的にはどこからでもインターネット２３に接続可能である。機器２７は、国境を越えたインターネット２３への接続も可能であり、機器２７の接続相手を特定することは難しい。このため、クラウドサービスプロバイダのサービスサーバ２２は、随時、不特定多数にアクセスされることを前提に設計されている。

不特定多数にアクセスされるサービスサーバ２２では、クラウドサービスが有料であるか無料であるかに関わらず、一時的、或いは、恒久的にユーザ所有のデータを所有することになる。このため、図３のような、ユーザID（User ID: User Identification）とパスワード（Password）の入力を求め、ユーザ認証を行う。図３は、モバイル端末２４及びＰＣ２５，２６に表示されるユーザ認証画面の一例を示す図である。図３は、ＡＢＣＤウェブ（Web）のメールサービス（Mail Service）へのログインを行う際のユーザ認証画面を示す。

しかし、インターネット２３に接続されるサービスサーバ２２は、ユーザ認証に用いるユーザIDとパスワードしか保持していない。従って、ユーザIDとパスワードが正しければ、第三者による不正使用が可能になってしまう。また、このように不正使用が起こり得る環境に加えて、インターネット２３に接続されるサービスサーバ２２は世界中からアクセスされ得るため、ボットネット（マルウェアに寄生された不正アクセス用PCの集合体）などにブルートフォースや辞書攻撃を受けると、不正アクセスを許してしまう可能性がある。このような不正アクセスを防ぐためには、例えば８文字以上で単語ではない文字列などの、より安全な長いパスワードを用いることが望ましい。

サービスサーバ２２に接続する際にユーザIDと長いパスワードを入力する場合、PC２５，２６からの入力は、キーボードから比較的容易に行うことができる。また、PC２５，２６の場合、生体認証やユーザ所有物認証による代行入力とプラグイン導入といった、ユーザへの負荷を軽減する手段が提供されている。

図４は、代行入力による負荷軽減方法の一例を説明する図である。図４において、PC３１は、図２のPC２５または２６に相当する。PC３１には、生体センサの一例である指紋センサ３２が接続されている。指紋センサ３２は、周知の方法でユーザの生体データの一例である指の指紋データを取得する。PC３１は、アプリケーションの一例であるブラウザ３３を有し、このブラウザ３３によりインターネット上にあるサイトのWebページを閲覧する。また、PC３１は、ブラウザ監視アプリケーション３４を有し、このブラウザ監視アプリケーション３４はPC３１の起動時に起動されてバックグラウンドで動作を続ける。ブラウザ監視アプリケーション３４は、ブラウザ３３が起動したことを確認すると、一定時間（例えば、１００msec程度)毎に、URL３５を確認する。ブラウザ３３のURL欄は、独立したWindow IDを持つウィンドウオブジェクトであるため、Windows （登録商標）API（Application Programming Interface）の呼び出しで内部のテキストを取得することができる。このように取得したURLが代行入力を行う設定になっている場合は、PC３１は認証モードに入る。

認証モードでは、PC３１はユーザにユーザIDの入力と指紋センサ３２へ指をかざすことを要求し、ユーザIDと生体データを取得する。取得した生体データは、ブラウザ監視アプリケーション３５内で、ユーザIDと関連付けられている登録生体データと比較され、一致するとPC３１は代行入力モードに入る。代行入力モードでは、ブラウザ監視アプリケーション３５内に記憶されているユーザIDとパスワードを、ブラウザ３４のUser ID欄とPassword欄に入力する。ユーザIDとパスワードは、各欄がWindow IDを持つウィンドウオブジェクトの場合、Windows APIで入力する。各欄がWindow IDを持つウィンドウオブジェクトではない場合、ユーザIDとパスワードは、キーボードエミュレーションで入力を行う。

図５は、プラグイン導入による負荷軽減方法の一例を説明する図である。図５において、ブラウザ５１は、機能を拡張するためのプラグイン導入機能を持っている。近年のPC用ブラウザは、何らかのプラグイン導入機能を有していることが多い。認証要求を受ける認証要求プラグイン５２は、Windows（登録商標）ではダイナミックリンクライブラリ、UNIX（登録商標）ではシェアードライブラリであり、いずれもライブラリの一種である。特定のフォーマットに従ってブラウザに登録すると、HTML（Hyper Text Markup Language）中のスクリプト（Javascript（登録商標）など）から、認証要求プラグイン５２を呼び出すことができる。例えば、認証要求プラグイン５２は、例えばSetCertAndRequestUserIDAndPasswordなる関数をスクリプトに公開する。この関数は、サーバ証明用の文字列を引数に渡して正しいサーバからのものであれば、ユーザIDとパスワードを入手可能とする。この関数は、ブラウザ51上のスクリプトから呼び出す。この関数が呼び出された場合、認証要求プラグイン５２の関数が実行に移される。この認証要求プラグイン５２は、スクリプトから渡されたサーバ証明用の文字列を検証し、それが正しいサーバからのものであるか否かを確認する。サーバ認証用の文字列が正しいサーバからのものであると確認できた場合、認証要求プラグイン５２は生体認証実施ライブラリ５３を呼び出す。

生体認証実施ライブラリ５３は、呼び出されると、ダイアログを表示してユーザにユーザIDの入力と、指紋センサへ指をかざすことを求める。ユーザがユーザIDをダイアログに入力し、指紋センサ３２に指をかざすと、指紋センサ３２からユーザの指紋データが取得される。生体認証実施ライブラリ５３は、予め用意した、ユーザIDと登録指紋データ及びパスワードとを対にして記録したユーザ情報データベースを、入力されたユーザIDに基づいて検索する。検索の結果、入力されたユーザIDと一致するユーザIDと対になっている登録指紋データと、指紋センサ３２から取得した指紋データが同じユーザの指から生成されたものであるかを照合する。この照合によって、ユーザの同じ指から生成された指紋データであると判定された場合、生体認証実施ライブラリ５３は、ユーザIDと、ユーザ情報データベースから検索されたユーザIDと対になっているパスワードとを認証要求プラグイン５２に返信する。

認証要求プラグイン５２は、SetCertAndRequestUserIDAndPassword関数の帰り値として、引数で示した変数にユーザIDとパスワードを格納する。この関数の返信で、ユーザＩＤとパスワードを受けたスクリプトは、SSL（Secure Socket Layer）通信を使用し、その中で、GETコマンドまたはPOSTコマンドを発行して、サーバにユーザIDとパスワードを送信する。このようにして、認証要求プラグイン５２を用いたユーザIDとパスワードの代行入力が行われる。

上記の如く、生体センサ３２を用いた認証を行い、ユーザIDとパスワードを代行入力することによって、ユーザのパスワード入力に伴う負荷をさらに軽減することができる。

このように、クラウドサービスプロバイダの保有するサービスサーバ２２に接続して、クラウドサービスの提供を受ける場合、ユーザIDと例えば８文字以上の長いパスワードによる認証が望ましい。PC２４または２５の場合、キーボードが装備されているのでユーザIDとパスワードの入力は比較的容易であり、たとえキーボード操作が苦手なユーザであっても指紋センサ３２などによる生体認証を利用したユーザIDとパスワードの代行入力が可能であるため、ユーザへの負荷が増大することはない。

しかし、モバイル端末２４でクラウドサービスを受ける場合には、特に長いパスワード入力がユーザへの負荷を増大させる。図6は、モバイル端末でのユーザIDとパスワード入力画面の一例を示す図である。図６において、パスワード入力画面８１は、モバイル端末２４のブラウザをサービスサーバ２２に接続したときに表示される画面の一例である。モバイル端末２４のブラウザの機能は、近年ではPCのブラウザの機能と同じレベルに達しているので、表示内容は同じである。パスワード入力画面８１などの画面の下部には、ソフトウェアキーボード８２が表示される。モバイル端末２４は、物理的なキーボードを備えていない場合が多く、画面の下部にソフトウェアキーボード８２を表示し、このソフトウェアキーボード８２から文字などを入力する。ソフトウェアキーボード８２の面積は、例えば４．３インチの液晶画面を有するスマートフォンで５５mm×３５mm程度、７インチの液晶画面を有するタブレットで９３mm×３５mm程度である。従って、１つのキーの大きさは、例えば５．５mm×９．０mm〜９．３mm×９．０mm程度であり、物理的なキーボードと比較すると小さい。特に、スマートフォンでは各キーが小さくなりすぎて、スマートフォンの操作に熟練したユーザであっても、文字などの誤入力をし易い。このように、モバイル端末２４では、パスワードの入力はユーザにとって非常に面倒で難しい操作になっている。

このため、モバイル端末２４では、PC２５，２６の場合以上に、生体認証と代行入力が有効な認証手段となり得るが、このような認証手段の採用を阻む問題がモバイル端末２４のオペレーティングシステム（OS: Operating System）によっては存在する。このような認証手段の採用を阻む問題が存在するOSの例には、Android（登録商標）、 iOS（登録商標）、Windows Phone 8（登録商標）、Windows RT（登録商標）などが含まれる。問題とは、モバイル端末２４のOSに存在する数々の機能制限である。PCと比較して厳しいモバイル端末２４のOSの機能制限は、例えばイントラネット上で使用することが多いPC２５，２６と比較して、常にインターネットに接続されて使用されるモバイル端末２４のセキュリティを高めるためと考えられる。また、モバイル端末２４のOSの機能制限を行って、アプリケーションの書き換えなどを防止することで、モバイル端末２４のメーカーや通信会社のビジネスモデルを守るためと考えられる。

上記機能制限の1つ目は、モバイル端末用のOSでは、プロセス間通信が行えないことである。プロセス間通信は、アプリケーション（以下、単に「アプリ」とも言う）とアプリとの間の通信や、アプリとデーモン（Daemon）などの監視アプリの間の通信に使用される。このプロセス間通信が使用できないと、図４で示したURL監視と代行入力が行えなくなる。URL監視は、例えばWindowsでは、プロセス間通信の一種を行うSendMessage関数を引数WM_GETTEXTで呼び出し、ブラウザのURLのテキストボックスのテキストを取得することで行っている。また、代行入力は、SendMessage関数を引数WM_SETTEXTでブラウザのユーザ IDやパスワードのテキストボックスにテキストを設定することで行っている。つまり、プロセス間通信が行えないと、プラウザ監視アプリケーションからブラウザに対して一切干渉できなくなり、代行入力が行えなくなる。

上記機能制限の２つ目は、モバイル端末のブラウザには、プラグインを導入できないことである。これは、第三者のプラグインの導入を許容することでこのプラグインの不具合によるセキュリティホールを作らないようにすること、及び、ビジネスモデルの観点から付属のブラウザの改造を許容したくないためと考えられる。全てのモバイル端末用OSにおいて、プラグインの使用は禁止されている。しかし、この制限により、図５に示すプラグインによるユーザIDとパスワードの代行入力ができなくなる。プラグインをブラウザに導入できなければ、ブラウザ上で実行されるスクリプトからプラグインの関数を呼び出すことができず、サーバ認証用のデータを渡すことができないため、当然のことながらユーザIDとパスワードを受取ることもできない。

上記機能制限の３つ目は、モバイル端末用OSには、デバイスドライバを追加できないことである。PCでは、USBなどのインタフェースに周辺機器を接続すると、この周辺機器用のデバイスドライバをインストールし、このデバイスドライバを介して周辺機器を制御できる。しかし、モバイル端末用OSには、デフォルトで付属している機器のデバイスドライバは搭載されているものの、後からデバイスドライバを追加することはできない。近年のスマートフォン及びタブレットなどのモバイル端末の多くは、USB OTG（On The Go）コントローラを搭載している。USB OTGコントローラは、USBのホストにもスレーブにもなれるコントローラである。このため、モバイル端末をPCの周辺機器として繋げることも、モバイル端末にキーボードやUSBストレージを繋げることもできる。モバイル端末には、USBキーボードやUSBストレージを繋げられるようにするために、USBキーボードやUSBストレージのデバイスドライバが予め搭載されている。しかし、モバイル端末には、生体センサなどの特殊な周辺機器のデバイスドライバは搭載されていない。このため、例えばUSBキーボードをモバイル端末に接続すれば、USBキーボードが正しく認識されてUSBキーボードから文字などを入力できるが、生体センサをモバイル端末に接続しても、生体センサは正しく認識されず、生体センサを使用することはできない。

モバイル端末用OSにデバイスドライバを後から追加できない理由としては、デバイスドライバは、特権コマンドを実行できる特権モードで動作させる必要があるためと考えられる。意図的にセキュリティホールがあるデバイスドライバを後から導入し、このデバイスドライバを攻撃するプログラムを作成すれば、比較的簡単にモバイル端末のroot権限を奪うことができてしまう。モバイル端末がroot権限を奪われると、通信会社などのビジネスモデルに反するプログラムの実行が可能となってしまうので、このような理由でデバイスドライバの追加ができないと考えられる。

以上のように、モバイル端末では、キーボードを有しているPCよりも、さらにアプリケーションによる代行入力やプラグインによるユーザID、パスワード代行返信が必要とされているにも関わらず、従来のPCで行われてきた代行入力や代行返信が行えない。つまり、モバイル端末では、PCで行える生体認証、生体認証と組み合わせたユーザID及びパスワードの代行入力や代理送信を行うことができない。このため、長いパスワードをソフトウェアキーボードで入力するのでは手間がかかり、ユーザへの負荷が増大してしまう。

そこで、一実施例では、SAML 2（Security Assertion Markup Language 2.0）認証と、生体認証の一例である指紋認証を用いて、クラウドサービスプロバイダのサービスサーバにログインする。

図７は、一実施例におけるセキュアログイン方法の一例を説明する図である。なお、本実施例及び後述する各実施例において、通信はSSL 3.0（Secure Socket Layer 3.0）、TLS 1.0（Transport Layer Security 1.0）、またはこれらの通信方法より高いセキュリティを提供可能な暗号化のもとで行われる。HTTP（Hyper Text Transfer Protocol）も独自通信も同様にSSL/TLS上で行われる。全ての通信がSSL/TLS上で行われるが、暗号化自体は周知であるため、その図示及び説明は省略する。

図7において、モバイル端末１０１は、W-CDMAなどの3Gの無線アクセス方式で通信可能なクライアントであり、通信端末の一例である。モバイル端末１０１は、無線WAN (Wide Area Network)などを介して無線でインターネット１０３に接続でき、さらにUSBデバイスを接続できる。無線WAN及びインターネット１０３は、モバイル端末１０１が通信可能に接続されるネットワークの一例である。生体センサの一例である指紋センサ１０２は、モバイル端末１０１にUSB接続されるUSBデバイスである。指紋センサ１０２は、モバイル端末１０１のUSBコントローラの指示に従って動作し、かざされたユーザの指の指紋データを取得する。インターネット１０３は、複数のネットワークと接続可能であり、パケット交換によって相互通信を行える。クラウドサービスプロバイダのデータセンタ１０４は、ルータ１０７を介してインターネット１０３と接続されている。モバイル端末１０１やPCなどにクラウドサービスを提供するサービスサーバ１０５は複数配置され、複数のユーザのリクエストに応じてクラウドサービスを提供する。サービスサーバ１０５は、クラウドサービスプロバイダ側のSAML2（Security Assertion Markup Language 2.0）プロトコル機能に対応している。統合認証サーバ１０６は、データセンタ１０４とは別の場所や、企業のDMZ（DeMilitarized Zone）に設置された、生体認証部及びSAML2サーバIdP（Identity Provider）部の、両方の機能を有する。生体認証部は、ユーザIDと照合用生体データをインターネット１０３を経由して受信し、照合用生体データと登録生体データが同じユーザの指から生成されたデータであうかを照合する。SAML2サーバIdP部は、IdP側のSAML 2.0プロトコル機能（以下、「SAML2サーバIdP部」とも言う）である。後述するように、サービスサーバ１０５のSAML2サーバSP（Service Provider）部と統合認証サーバ１０６のSAML2サーバIdP部は連携しており、サービスサーバ１０５のサービス使用に関する許諾は、統合認証サーバ１０６に委ねられるように、SAML2サーバSP部及びSAML2サーバIdP部が設定されている。統合認証サーバ１０６は、ルータ１０８を介してインターネット１０３と接続されている。

なお、指紋センサ１０２は、モバイル端末１０１に内蔵されていても良い。

先ず、統合認証サーバ１０６の生体認証部について説明する。生体認証部は、ユーザIDと照合用生体データ（この例では、照合用指紋データ）をモバイル端末１０１から受け取る。統合認証サーバ１０６内には、ユーザIDと登録生体データの対が登録された登録生体データデータベース（DB: Data-Base）が格納されている。生体認証部は、この登録生体データDBをユーザIDで検索し、一致したユーザIDと対になっている登録生体データ（この例では、登録指紋データ）と、受け取った照合用生体データが同じ生体（この例では、同じユーザの指）から生成されたものであるか否かを判定する。判定の結果、受け取った照合用生体データが同じユーザの指から生成されたものであると判定された場合、生体認証部は、例えば２５６ビット程度のワンタイムパスワード（以後、OTP（One Time Password）とも言う）を乱数で生成し、一時ユーザ格納部にユーザIDと対にして一時ユーザを形成して登録する。登録された一時ユーザは、統合認証サーバ１０６のSAML2サーバIdP部にとって、登録されたユーザと認識される。ただし、例えば１０分程度で、この登録された一時ユーザは消去される。生体認証部は、統合認証サーバ１０６に対してユーザIDと照合用生体データを送信してきた送信元であるモバイル端末１０１に、認証が成功したことを示す認証結果とOTPを返信する。一方、判定の結果、受け取った照合用生体データが同じユーザの指から生成されたものではないと判定された場合、或いは、ユーザIDで検索した結果、一致するユーザIDが存在しない場合には、生体認証部は認証が失敗したことを示す認証結果を送信元に返信する。

次に、統合認証サーバ１０６のSAML2サーバIdP部について説明する。SAML 2.0プロトコルは、２つのサーバと、１つのクライアントで構成される。統合認証サーバ１０６内に設置されたSAML2サーバIdP部は、自身に公開鍵方式暗号の秘密鍵を保有する。統合認証サーバ１０６は、このSAML2サーバIdP部に認証を代行させたいSAML2サーバSP部を保有するサービスサーバ１０５に、秘密鍵と対となる公開鍵を渡す。その後は、認証の代行依頼を、この公開鍵を用いて行う。

SAML2サーバIdP部は、サービスサーバ１０５内にあるSAML2サーバSP部が送信した認証代行依頼に応じて、モバイル端末１０１にユーザIDとパスワードを要求する。そして、SAML2サーバIdP部は、自身の保有するユーザIDとパスワードの対（この例では一時ユーザ格納部に格納されているユーザIDとOTPの対）と一致するか否かを判定し、判定結果をサービスサーバ１０５のSAML2サーバSP部に返信する。

サービスサーバ１０５は、SAML 2.0プロトコルに対応したSAML2サーバSP部を保有する。そして、SAML2サーバSP部は、認証の要求を受けた場合は、自身で認証を行う代わりに、公開鍵を用いて暗号化されたトークンをSAML2サーバIdP部に送信することで、SAML2サーバIdP部にユーザ認証を委譲する。このような認証の委譲は、ユーザが多くのサービスを要する場合に、その都度各サービスに対してユーザIDとパスワードを登録する必要がなくなるため、認証用ユーザデータの管理を容易にできるものであり、シングルサインオン（SSO: Single Sign On)と呼ぶ。

近年のクラウドサービスプロバイダのクラウドサービスは、多くの場合SAML2に対応をしている。このため、SAML2認証を採用することは、ユーザにとって負荷にはならない。また、上記の構成を採用することで、モバイル端末のOSに機能制限があっても、代理返信することができる。

図８は、一実施例におけるモバイル端末、統合認証サーバ、及びサービスサーバの構成の一例を示すブロック図である。図８中、ネットワーク１０３、ルータ１０７，１０８、データセンタ１０４などの図示は省略する。

図８に示すように、モバイル端末１０１は、USBホストコントローラ１３２、モバイル端末用OS１３４、ブラウザ１３７、ブラウザ１３７の子プロセス１３８（以下、単に「ブラウザの子プロセス１３８」とも言う）、及び独自認証クライアントアプリ１３９を有する。USB ホストコントローラ１３２は、キーボードやUSBストレージなどのUSB スレーブ機器を接続可能であり、本実施例では、生体センサの一例である指紋センサ１０２が接続されている。一般的なモバイル端末の場合、USBホストコントローラにも、USBスレーブコントローラにもなる、USB OTG （USB On-The-Go）コントローラが装備されていることが多い。従って、USBホストコントローラ１３２は、USB OTGコントローラにより形成可能である。指紋センサ１０２が稼働中にユーザが指紋センサ１０２に指をかざすと、ユーザの指の指紋データが検出されてUSBホストコントローラ１３２に供給される。

モバイル端末用OS１３４は、例えばAndroid（登録商標）、iOS（登録商標）、Windows RT（登録商標）などで形成可能である。モバイル端末用OS１３４は、管理者権限をユーザに渡さず、その結果、デバイスドライバの追加、プロセス間通信、ブラウザのプラグインによる拡張などが制限されている点でPC用のOSと異なる。モバイル端末用OS１３４は、デバイスドライバ１３５及びモバイル端末用OS API１３６を有する。

デバイスドライバ１３５は、周辺機器の一例であるUSBホストコントローラ１３２用のデバイスドライバであり、制御するインタフェースをAPIにより提供する。このようなデバイスドライバ１３５は、例えばAndroid（登録商標）、iOS（登録商標）などのモバイル端末用OSを採用するモバイル端末に設けられている。従って、デバイスドライバ１３５が提供するAPIを呼び出すことによって、USBホストコントローラ１３２を制御することができる。デバイスドライバ１３５が提供するAPIの中には、モバイル端末１０１に接続されているUSB機器の接続番号と機器名称を取得する関数が含まれるので、USBホストコントローラ１３２に指紋センサ１０２が接続されているか否かを確認することができる。

モバイル端末用OS１３４が、USBホストコントローラ１３２に指紋センサ１０２が接続されていることを確認した場合、接続番号にデータを書き込む関数と、その接続番号から送られて一時バッファに保存されているデータを読み込む関数とがＡＰＩとして用意されている。モバイル端末用OS１３４は、これら関数を用いて、指紋センサ１０２に指の指紋データを取得するコマンドを発行し、指紋センサ１０２が取得した指紋データをUSBホストコントローラ１３２を介して読み込むことができる。つまり、指紋センサ１０２のデバイスドライバをモバイル端末用OS１３４に追加インストールすることなく、アプリから直接指紋センサ１０２を呼び出して指紋データを取得することができる。これにより、上記３つ目の機能制限である、モバイル端末用のOSではデバイスドライバの追加が行えないという不都合を解消できる。

モバイル端末用OS API１３６は、モバイル端末用OS１３４がアプリに提供しているAPIである。モバイル端末用OS API１３６の中には、デバイスドライバ１３５が提供するAPIも含まれる。モバイル端末１０１のアプリは、モバイル端末用OS API１３６を呼び出してプログラム実行に必要なリソースや情報をモバイル端末用OS１３４から取得したり、各種表示、通信、計算などを行う。

ブラウザ１３７は、例えばモバイル端末１０１に予め用意されているブラウザアプリである。ブラウザ１３７は、例えばモバイル端末用OS１３４上に複数立ち上げられる、マルチプロセスアプリである。ブラウザ１３７は、このブラウザ１３７の立ち上げ要求に従って、ブラウザの子プロセス１３８を生成してhtmlなどの表示を行う。

モバイル端末用OS１３４に付属しているブラウザ１３７は、実行中のプロセス間通信は拒絶するが、ブラウザの子プロセス１３８の立ち上げ時には、引数として他のアプリケーションからプロセス間通信を受け付けることができる。ブラウザの引数付の子プロセス１３８の立ち上げは、プロセス間通信で行うので、これだけは例外で許可されている。このような例外は、例えばメールに書かれたURLからのブラウザ１３７の立ち上げ、アプリのサポートページへの誘導、広告付きアプリで広告をクリックした際の広告ホームページのブラウザ１３７での表示など、モバイル端末１０１のビジネスモデルに必要な機能を確保するために許可されていると考えられる。これにより、上記１つ目の機能制限である、モバイル端末１０１にプロセス間通信を行えないという不都合を解消できる。

ブラウザの子プロセス１３８は、独自認証クライアントアプリ１３９のAPI呼び出しを介して立ち上げられる、ブラウザ１３７の子プロセスである。ブラウザの子プロセス１３８は、一般的なブラウザの全ての機能を有しており、サービスサーバ１０５のクラウドサービスを実行したり表示したりする機能を有している。なお、ブラウザの子プロセス１３８は、ブラウザ１３７に含まれていても良い。これにより、プラグイン導入といった、ユーザへの負荷を軽減する手段を用いることなくユーザへの負荷を軽減できるので、上記２つ目の機能制限である、モバイル端末１０１のブラウザ１３７にはプラグインを導入できないという不都合を解消できる。

独自認証クライアントアプリ１３９は、モバイル端末用OS１３４のAPIを介してデバイスドライバ１３５を呼び出し、このデバイスドライバ１３５を介してUSBホストコントローラ１３２に接続された指紋センサ１０２に直接データを送受信することができる。このため、指紋センサ１０２に直接コマンドデータを送信することにより、指紋センサ１０２を制御することができる。また、独自認証クライアントアプリ１３９は、ユーザIDと共に照合するべき指紋データを統合認証サーバ１０６に送信してユーザ認証を求めることにより、ユーザ認証が成功した場合に統合認証サーバ１０６からOTPを入手できる。さらに、独自認証クライアントアプリ１３９は、サービスサーバ１０５に対してサービスの提供を要求し、その結果返信されてくるSAML2に準拠した認証データ（以下、「SAML2データ」とも言う）を、統合認証サーバ１０６にリダイレクトすることができる。また、これとは逆に、独自認証クライアントアプリ１３９は、統合認証サーバ１０６から送られてくるSAML2データをサービスサーバ１０５にリダイレクトすることができる。なお、独自認証クライアントアプリ１３９の詳細については後述する。

サービスサーバ１０５は、クラウドサービスプロバイダが保有する複数のサービスサーバのうちの１台である。サービスサーバ１０５とインターネット１０３との間には、例えばルータ１０７、ロードバランサなどの機器が設けられていても良い。サービスサーバ１０５は、ユーザのPCやモバイル端末のブラウザに、クラウドサービスを提供する。サービスサーバ１０５は、ユーザ認証を行うための機能も有する。サービスサーバ１０５は、図８に示すように、SAML2サーバSP部１５１、公開鍵格納部１５２、サービス提供部１５３、及びURL解析部１５４を有する。

SAML2サーバSP部１５１は、モバイル端末１０１のブラウザ１３７またはアプリからHTTPS（HyperText Transfer Protocol Secure）でサービスの提供要求を受ける。SAML2サーバSP部１５１は、サービスの提供要求を受けると、先ずサービスの提供要求のメッセージをURL解析部１５４に渡し、統合認証サーバ１０６のURLを取得する。統合認証サーバ１０６のURLは、統合認証サーバ１０６を特定する情報の一例である。次に、SAML2サーバSP部１５１は、認証要求メッセージ文字列と、長いチャレンジ・レスポンス用の乱数文字列、即ち、ナンス（Nonce）を生成する。また、SAML2サーバSP部１５１は、公開鍵格納部１５２に統合認証サーバ１０６のURLを渡してこのURLと対になる公開鍵を取得し、生成した認証要求メッセージ文字列とナンスを取得した公開鍵を用いて暗号化する。

さらに、SAML2サーバSP部１５１は、暗号化されたデータを、統合認証サーバ１０６にリダイレクトするようモバイル端末１０１にHTTPSで返信する。SAML2サーバSP部１５１は、このような通信のやり取りをブラウザ１３７やアプリを介して統合認証サーバ１０６のSAML2サーバIdP部１７１と何度か行い、SAML2サーバIdP部１７１から認証成功のメッセージを受信すると、サービス提供部１５３にサービス提供開始を通知する。サービス提供部１５３は、モバイル端末１０１のブラウザの子プロセス１３８にサービスを提供する。

公開鍵格納部１５２は、統合認証サーバ１０６に保存されている秘密鍵と対になる公開鍵を格納している。サービスサーバ１０５は、例えば多くの企業や団体に属するユーザに対応しているため、公開鍵格納部１５２は、このサービスサーバ１０５が有するSAML2サーバのURLと対で公開鍵を格納している。このため、公開鍵格納部１５２は、URLを渡されると、渡されたURLに対応した公開鍵を提供する。

サービス提供部１５３は、クラウドサービスプロバイダが提供するクラウドサービスをモバイル端末１０１に提供する。URL解析部１５４は、独自認証クライアントアプリ１３９から送信された、サービスの提供要求のメッセージを解析して、統合認証サーバ１０６のURLを計算する。サービスサーバ１０５に接続する際のURLの中には、統合認証サーバ１０６のURLが含まれている場合が多い。このような場合、URL解析部１５４は、サービスの提供要求のメッセージに対し、URLに含まれる統合認証サーバ１０６のURLをモバイル端末１０１に返信する。ユーザIDと認証サーバを関連付けるサービスサーバ１０５の場合、URL解析部１５４は、ユーザIDをキーにして検索して統合認証サーバ１０６のURLをモバイル端末１０１に返信する。

一方、統合認証サーバ１０６は、SAML2サーバ部と、生体認証部（この例では指紋認証部）の２つの機能を有する。統合認証サーバ１０６は、図８に示すように、サービスサーバ一覧提供部１７１、生体認証部１７２、SAML2サーバIdP部１７３、秘密鍵格納部１７４、一時ユーザ格納部１７５、及び登録生体データDB部１７６を有する。

サービスサーバ一覧提供部１７１は、サービスの名前と、このサービスを提供するサービスサーバ１０５のURLの一覧をモバイル端末１０１に返信する。モバイル端末１０１は、起動時にサービスサーバ一覧提供部１７１に接続し、ユーザに提供されているサービスの名前と、サービスサーバ１０５のURLの対の一覧を取得する。サービスサーバ１０５のURLは、サービスサーバ１０５を特定する情報の一例である。ユーザは、モバイル端末１０１が取得した一覧から、ユーザ自身が使いたいサービスを１つ選択する。

生体認証部１７２は、モバイル端末１０１からユーザIDと照合用生体データ（この例では照合用指紋データ）が送られてくると、ユーザIDをキーにして登録生体データDB（Data-Base）１７６を検索する。この登録生体データDB１７６に、キーに使用されたユーザIDと同じユーザIDが登録されている場合、生体認証部１７２は、登録生体データDB１７６に対になって登録されている登録生体データを生体認証部１７２に返信する。生体認証部１７２では、照合用生体データと登録生体データが、同じ生体（この例では、同じユーザの指）から生成されたデータであるかを計算により判定する。照合用生体データと登録生体データが同じユーザの指から生成されたデータであると判定された場合、生体認証部１７２は例えば２５６ビット程度のOTPを生成する。生体認証部１７２は、生成したOTPをユーザIDと共に一時ユーザ格納部１７５に格納する。一時ユーザ格納部１７５に格納されたユーザIDとOTPの対は、例えば１０分後に削除される。生体認証部１７２は、認証成功の結果と共に、OTPをモバイル端末１０１に返信する。なお、照合用生体データと登録生体データが同じユーザの指ではない判定された場合、生体認証部１７２はOTPを生成せず、認証失敗の結果をモバイル端末１０１に返信する。

SAML2サーバIdP部１７３は、サービスサーバ１０５のSAML2サーバSP部１５１からモバイル端末１０１を経由して送信されてくる暗号データを解析する。SAML2サーバIdP部１７３は、暗号データを秘密鍵格納部１７４に格納されている秘密鍵で複合化し、認証要求メッセージ文字列が正しく複合化されるのを確認する。認証要求メッセージ文字列が正しく複合化できている場合、SAML2サーバIdP部１７３はモバイル端末１０１のリダイレクトへの返信として、ユーザIDとパスワードの要求を送信する。モバイル端末１０１から要求したユーザIDとパスワードが送られてくると、SAML2サーバIdP部１７３は一時ユーザ格納部１７５を検索し、同じユーザIDとパスワードの対があるか否かを確認する。同じユーザIDとパスワードの対が存在する場合、SAML2サーバIdP部１７３はSAML認証応答メッセージを生成し、SAML認証応答メッセージを秘密鍵で暗号化する。そして、SAML2サーバIdP部１７３は、モバイル端末１０１経由でリダイレクトして、サービスサーバ１０５に暗号データが届くように返信する。なお、独自認証クライアントアプリ１３９の説明で詳細に記述するが、暗号化されたSAML認証応答メッセージをモバイル端末１０１に返信する際、独自認証クライアントアプリ１３９は指示通りにリダイレクトせず、ブラウザの子プロセス１３８を生成して、ブラウザの子プロセス１３８にリダイレクトさせる。これにより、以降の処理をブラウザの子プロセス１３８が行うことができる。暗号化されたSAML2認証応答メッセージをブラウザの子プロセス１３８から受け取ったSAML2サーバSP部１５１は、複合化の後にSAML2認証応答メッセージを確認し、正しく複合化されていればサービスの提供に移行する。

秘密鍵格納部１７４は、統合認証サーバ１０６を立ち上げた際に生成する一対の秘密鍵と公開鍵の対のうち、秘密鍵を格納する。一時ユーザ格納部１７５は、指紋認証が成功して、サービスの提供が許可されたユーザのユーザIDとパスワードの対を格納する。SAML2サーバIdP部１７３は、一時ユーザ格納部１７５を参照し、モバイル端末１０１から送られてくるユーザIDとパスワードの対が、格納されたユーザIDとパスワードの対と一致しているか否かを確認する。このような２段階の処理を行うのは、SAML2サーバIdP部１７３の改造を無くすためである。登録生体データDB部１７６は、ユーザIDと登録生体データの対を複数個格納する。登録生体データDB部１７６には、クラウドサービスの使用を許可された複数のユーザの、ユーザIDと登録指紋データが登録されている。

次に、モバイル端末１０１の独自認証クライアントアプリ１３９を、図９と共により詳細に説明する。図９は、独自認証クライアントアプリの構成の一例を示すブロック図である。図９中、図８と同一部分には同一符号を付し、その説明は省略する。

図９に示すように、独自認証クライアントアプリ１３９は、生体データ取得部２０２、ユーザIDパスワード送信部２０３、SAML2リダイレクト部２０４、サービス要求部２０５、生体認証依頼部２０６、サービスサーバ一覧取得部２０７、ユーザ情報入力部２０８、ブラウザ子プロセス生成部２１０、及びブラウザの子プロセス（以下、単に「ブラウザ子プロセス」とも言う）２１１を有する。

独自認証クライアントアプリ１３９では、最初にサービスサーバ一覧取得部２０７が統合認証サーバ１０６のサービスサーバ一覧提供部１７１に接続して、サービスの名前とサービスサーバのURLの対の一覧を取得し、サービスサーバ一覧取得部２０７のメモリに格納する。サービスサーバ一覧取得部２０７は、取得したサービスの名前一覧をユーザ情報入力部２０８に引き渡す。

ユーザ情報入力部２０８は、取得したサービスの名前一覧を表示し、ユーザにサービスの名前一覧の中から使用するサービスの選択を促す。さらに、ユーザ情報入力部２０８は、ユーザにユーザのユーザIDの入力を促す。ユーザ情報入力部２０８は、ユーザが選択したサービスの名前とユーザIDを取得すると、選択されたサービスの名前とユーザIDをユーザ情報入力部２０８のメモリに保存する。

次に、生体データ取得部２０２は、ユーザに指を指紋センサ１０２にかざすよう促す。これと同時に、生体データ取得部２０２は、モバイル端末用OS API１３６を経由して指紋センサ１０２を駆動する。生体データ取得部２０２は、ユーザの指から検出した照合用生体データの一例である指紋データを指紋センサ１０２から取得して生体データ取得部２０２のメモリに保存する。

次に、生体認証依頼部２０６は、生体データ取得部２０２のメモリに保存されている照合用生体データと、ユーザ情報入力部２０８のメモリに格納されているユーザIDを、統合認証サーバ１０６の生体認証部１７２に送信し、生体認証部１７２においてユーザIDと対となる登録生体データが検索される。生体認証部１７２は、検索された登録生体データと照合用生体データを照合する。生体認証部１７２が登録生体データと照合用生体データが同じユーザの指から生成されたデータであると判定した場合、生体認証依頼部２０６は生体認証部１７２から認証成功の通知とOTPを受信する。生体認証依頼部２０６は、受信したOTPを生体認証依頼部２０６のメモリに保存する。

生体認証依頼部２０６は、認証成功の通知を受信すると、サービス要求部２０５にサービス要求開始を通知する。サービス要求部２０５は、HTTPSでユーザに選択されたサービス名と対になっているサービスサーバ１０５のURLに向けてサービスの提供要求を行う。サービスサーバ１０５のSAML2サーバSP部１５１は、サービスの提供要求に対してSAML2プロトコルで返信する。

SAML2プロトコルは、HTTPSの上にSOAP（Simple Object Access Protocol）を乗せ、その中でSAML2に従ったデータを送信する比較的複雑なプロトコルである。しかし、モバイル端末１０１は、SAML2サーバSP部１５１からSAML2サーバIdP部１７３へのデータの中継と、その逆のSAML2サーバIdP部１７３からSAML2サーバSP部１５１へのデータの中継を行うリダイレクト処理を行うだけであり、データの中身を解析する必要は無い。リダイレクト処理自体は、SAML2リダイレクト部２０４において例えば下記の２種類の方法のいずれかに従って行える。

第１の方法では、サービスサーバ１０５へサービスの提供要求を行った際に、サービスサーバ１０５から返信されるHTTPレスポンスヘッダの中の「Location:」記述を利用する。リダイレクト処理を行う場合、HTTPレスポンスヘッダ中には、例えば次のような記述がある。
Location:
https://idp.example.com/SAML/Browser?SAMLRequest=fVFdS8MwFH0f7D%2BUvG
dNsq62oSsIQyhMESc%2B%2BJYlmRbWpObeyvz3puv2IMjyFM7HPedyK1DdsZdb%2F%2BEHf
LFfgwVMTt3RgTwzazIEJ72CFqRTnQWJWu7uH7dSLJjsg0ev%2FZFMlttiBWADtt6R%2BSyJ
r9msiRH7O70sCm31Mj%2Bo%2BC%2B1KA5GlEWeZaogSQMw2MYBKodrIhjLKONU8FdeSsZkV
r6TPr6T5M0GiHMjvWCknqZXZ2OoPxF7kGnaGOuwxZ%2Fn4L9bY8NC%2By4du1XpRXnxPcXizSZ5
8KFTeHujEWkNPZylsh9bAMYYUjO2Uiy3jCpTCMo5M1StVjmN9SO150sl9lU6RV2Dp0vsLIy
7NM7YU82r9B90PrvCf85W%2FwL8zSVQzAEAAA%3D%3D&RelayState=0043bfc1bc45110d
ae17004005b13a2b&SigAlg=http%3A%2F%2Fwww.w3.org%2F200%2F09%2Fxmldsig%23
rsasha1&Signature=NOTAREALSIGNATUREBUTTHEREALONEWOULDGOHERE
そこで、HTTPレスポンスヘッダ中に上記の如き「Location:」記述が存在する場合、httpsなので、例えばidp.example.comのドメイン名サーバの所定ポート番号に、SSL/TLSでセキュアソケットを接続する。また、残りのデータ部分が送信されるように、再度GETコマンドを発行する。具体的には、「GET /SAML/Browser?SAMLRequest=fVFdS8...... GOHERE」なるコマンドを送信する。

第２の方法では、HTTPレスポンスヘッダの後のhtml本文中のヘッダ部分「<head> </head>」で囲まれた中に存在する「<meta http-equiv="Refresh" content="0; URL=https://idp.example.com /SAML/Browser?SAMLRequest=.......GOHERE" />」というメタデータのRefresh記述を利用する。この場合、このようなHTTPレスポンスヘッダの後のhtml本文中のヘッダ部分で囲まれたメタデータのRefresh記述が存在する場合、Refresh記述の中のURL部分だけを解析し、「content=」中の「URL=」へ、SSL/TLSセキュアソケットで接続する。そして、上記第１の方法の場合と同様にGETコマンドを発行する。具体的には、「GET /SAML/Browser?SAML Request=fVFdS8...... GOHERE」なるコマンドを送信する。

以上の手順で、SAML2リダイレクト部２０４は、SAML2サーバSP部１５１とSAML2サーバIdP部１７３との間のデータを中継する。SAML2サーバSP部１５１及びSAML2サーバIdP部１７３は、夫々が保有する公開鍵と秘密鍵を用いて、相互の信頼関係を確立できる。SAML2サーバSP部１５１及びSAML2サーバIdP部１７３が相互の信頼関係が確立した後、SAML2サーバIdP部１７３は、リダイレクト処理に対するレスポンス、即ち、ユーザIDとOTPを要求する画面の表示を実施するhtmlを、SAML2リダイレクト部２０４に返信する。SAML2リダイレクト部２０４は、ユーザIDとOTPの要求画面の表示を行うhtmlを破棄し、その代わりに、ユーザIDパスワード送信部２０３にユーザIDとパスワードをSAML2サーバIdP部１７３に送信するように命令する。

ユーザIDパスワード送信部２０３は、一時ユーザ格納部１７５に保存されているユーザIDとOTPを、SAML2サーバIdP部１７３に送信する。例えば１０分以上の比較的長い時間が経過していなければ、このユーザIDとOTPの対は、必ず一時ユーザ格納部１７５に格納されている。指紋認証が終わってユーザIDとOTPの対が一時ユーザ格納部１７５に格納されてから、ユーザIDパスワード送信部２０３に制御が移るまで、時間的には例えば1秒未満程度の比較的短い時間しかかからない。このため、SAML2サーバIdP部１７３でのユーザIDとOTPの認証は必ず成功する。そして、サービスサーバ１０５へのログインを許可するための、サービスサーバ１０５のURLを含む、URL付SAML認証応答メッセージが、SAML2リダイレクト部２０４送信される。

SAML2リダイレクト部２０４は、ユーザIDパスワード送信部２０３にユーザIDとOTPを送信するよう命令した後に、最初にSAML2サーバIdP部１７３から送信されてくるSAML2通信を、自身ではリダイレクトせず、ブラウザ子プロセス生成部２１０にSAML2通信内容を渡す。ブラウザ子プロセス生成部２１０にSAML2通信内容を渡した後、SAML2リダイレクト部２０４はサービスサーバ１０５及び統合認証サーバ１０６の通信を切断する。

ブラウザ子プロセス生成部２１０は、具体的にはモバイルOS API１３６をSAML2通信内容付きで呼び出してブラウザ子プロセス２１１を生成する。例えば、Android（登録商標）などのモバイル端末用OSでは、SAML2通信内容（"https://sp.example.com/..."の部分）を引数に、new Intent命令でブラウザ子プロセス２１１を作成し、startActivity関数で活動を開始することができる。
Uri uri = Uri.parse( "https://sp.example.com/SAML/Browser?SAMLResponse=
asDCvDSf...." );
Intent browserIntent;
browserIntent = new Intent( Intent.ACTION_VIEW,uri );
startActivity( browserIntent );
ブラウザ子プロセス２１１は、startActivity関数で活動を開始し、SAML2通信内容に従ってサービスサーバ１０５のSAML2サーバSP部１５２に接続する。一般的なクライアント・サーバ通信の場合、通信を行っている最中は、サーバ及びクライアントが共にステート（状態）を保持して通信及び処理を継続する。途中で通信が途絶えた場合は、ステートはリセットされ、通信は最初からやり直しとなる。しかし、HTTPの場合、回線の不安定な状態でも通信を続けられるようにするため、クライアントとサーバでステートを持たない、ステートレスの通信と処理を行う。SAMLもHTTP上に設けられたステートレスのプロトコルであるため、ブラウザ子プロセス２１１から再度の接続があった場合、送信されたURL付SAML認証応答メッセージを解釈し、そこから処理を再開する。

URL付SAML認証応答メッセージを受け取ったSAML2サーバSP部１５２部は、サービス提供部１５３にサービス提供の許可を出し、モバイル端末１０１への応答を命令する。サービス提供部１５３は、ブラウザ子のプロセス２１１にサービスの提供を開始する。

次に、モバイル端末、サービスサーバ、及び統合認証サーバの動作シーケンスを、図１０と共に説明する。図１０は、一実施例におけるセキュアログイン処理の一例を説明する図である。図１０において、ステップ７０１，７０１Ａ，７０２，７０３，７０８Ａ，７０９，７１１，７１３の処理はモバイル端末１０１のプロセッサにより実行され、ステップ７０８Ｂ，７１４の処理はサービスサーバ１０５のプロセッサにより実行され、ステップ７０１Ｂ，７０４〜７０７，７０８，７１０，７１２の処理は統合認証サーバ１０６のプロセッサにより実行される。

モバイル端末１０１は、ステップ７０１において、独自認証クライアントアプリ１３９を起動する。モバイル端末１０１の独自認証クライアントアプリ１３９を起動されると、サービスサーバ一覧取得部２０７は、ステップ７０１Ａにおいて、統合認証サーバ１０６に接続してサービス名とサービスサーバURLの一覧を要求する。統合認証サーバ１０６のサービスサーバ一覧提供部１７１は、ステップ７０１Ｂにおいて、要求されたサービス名とサービスサーバURLの一覧をモバイル端末１０１に返信するので、モバイル端末１０１は要求したサービス名とサービスサーバURLの一覧を取得してユーザ情報入力部２０８に引き渡す。

モバイル端末１０１のユーザ情報入力部２０８は、ステップ７０２において、ユーザに対してユーザIDを入力することを促し、さらに使用するサービスの選択を促す。従って、モバイル端末１０１では、ユーザが入力したユーザIDとユーザが選択したサービスを提供する接続先のサービスサーバ１０５が決定される。

モバイル端末１０１では、ステップ７０３において、生体データ取得部２０２が指紋センサ１０２をUSBホストコントローラ１３２経由で制御してユーザの指を読み取って照合用生体データを生成し、生体認証依頼部２０６がユーザIDと照合用生体データを統合認証サーバ１０６に送信する。

統合認証サーバ１０６の生体認証部１７２は、ステップ７０４において、ユーザIDで登録生体データDB部１７６を検索し、同じユーザIDと対になっている登録生体データを取得する。統合認証サーバ１０６は、ステップ７０５において、照合用生体データと登録生体データを照合し、これらの生体データが同じユーザの指から生成された生体データであるか否かを判定する。統合認証サーバ１０６の生体認証部１７２は、ステップ７０６において、照合した照合用生体データと登録生体データが同じユーザの指から生成され生体データが一致すると判定した場合、例えば２５６ビット程度の長さのOTPを生成する。統合認証サーバ１０６の生体認証部１７２は、ステップ７０７において、OTPをユーザIDと対にして一定時間だけ一時ユーザ格納部１７５に一時的に保存する。例えば１０分程度の一定時間が経過すると、一時ユーザ格納部１７５に保存されたユーザIDとOTPの対は消去され、SAML2サーバIdP部１７３から認証用ユーザデータのデータベースとして検索される。また、統合認証サーバ１０６の生体認証部１７２は、ステップ７０８において、照合用生体データと登録生体データの照合の結果これらの生体データが一致したことを示す認証成功の通知と、OTPとをモバイル端末１０１に送信する。

モバイル端末１０１では、ステップ７０８Ａにおいて、生体認証依頼部２０６が認証成功の通知とOTPを受け取ると、サービス要求部２０５がサービスサーバURLによりサービスサーバ１０５へリソースへのアクセスを要求する（Request Target Resource）。サービスサーバ１０５のSAML2サーバSP部１５１は、ステップ７０８Ｂにおいて、最終的な到達サーバを統合認証サーバ１０６に設定して、モバイル端末１０１にリダイレクトするようにSAML認証要求メッセージを送信する。

モバイル端末１０１のSAML2リダイレクト部２０４は、ステップ７０９において、SAML認証要求メッセージのリダイレクト指示により、統合認証サーバ１０６にSAML認証要求メッセージ（Authentication Request）をリダイレクトすることで、SAML2サーバSP部１５１とSAML2サーバIdP部１７３との間のデータを中継する。

統合認証サーバ１０６のSAML2サーバIdP部１７３は、ステップ７１０において、SAML認証要求メッセージを受信すると、ユーザIDとパスワードの入力を促す（または、要求する）ページ（html）、即ち、ユーザIDとパスワードを統合認証サーバ１０６に送信するための画面を、モバイル端末１０１に送信する。

モバイル端末１０１のSAML2リダイレクト部２０４は、ステップＳ７１１において、受信したhtmlページに従った画面表示は行わず、代わりに、ユーザに入力させたユーザIDと、既に受信しているOTPを統合認証サーバ１０６に返信する。

統合認証サーバ１０６のSAML2サーバIdP部１７３は、ステップ７１２において、受信したユーザIDとOTPの対が、一時ユーザ格納部１７５に格納されているか否かを確認する。例えば１０分程度の一定時間を超える時間が経過していなければ、受信したユーザIDとOTPの対が一時ユーザ格納部１７５に格納されているので、照合されるOTP同士は一致する。照合されるOTP同士が一致する場合、統合認証サーバ１０６のSAML2サーバIdP部１７３は、ステップ７１２において、サービスサーバ１０５へリダイレクトするように、サービスサーバ１０５のURLを含む、URL付SAML2認証応答メッセージをモバイル端末１０１に返信する（Respond with Assertion）。

モバイル端末１０１では、ステップ７１３において、SAML2リダイレクト部２０４は、受信したURL付SAML2認証応答メッセージをリダイレクトせず、統合認証サーバ１０６との通信セッションを切断すると共に、ブラウザ子プロセス生成部２１０がURL付SAML2認証応答メッセージを引数としてブラウザ子プロセス２１１を起動し、以降の処理をブラウザ子プロセス２１１に行わせる。ブラウザ子プロセス２１１は、起動されるとURL付SAML2認証応答メッセージをサービスサーバ１０５へ送信する。

サービスサーバ１０５のSAML2サーバSP部１５１は、ステップ７１４において、URL付SAML認証応答メッセージを受信すると、代行認証が成功したことを認識し、オートログインを実行することでサービスサーバ１０５の持つサービス（リソースやオペレーション）をモバイル端末１０１のブラウザ子プロセス２１１へ提供する（Respond with Request Resource）。

図１１は、モバイル端末に表示される画面の一例を示す図である。図１１は、モバイル端末１０１において、独自認証クライアントアプリ１３９が表示画面１３９Ａを表示している状態を示す。例えば、図１０のステップ７０１Ｂにおいて、統合認証サーバ１０６がプルダウンメニュー１４２によりサービスサーバ名の一覧（サービスサーバURLの図示は省略）をモバイル端末１０１に表示すると、ステップ７０２において、ユーザがプルダウンメニュー１４２から選択したサービスサーバがサイト（Sites）のフィールド１４１入力され、ユーザが入力したユーザＩＤがユーザID（User ID）フィールド１４３に入力されて、ユーザIDと接続先のサービスサーバ１０５が決定される。なお、この例では、モバイル端末１０１がステップ７０３において指紋センサ１０２に読み取らせたユーザの指紋データがフィールド１４４に表示されているが、モバイル端末１０１における指紋データの表示は省略可能である。

図１２は、コンピュータの構成の一例を示すブロック図である。コンピュータ２００は、プロセッサの一例であるCPU (Central Processing Unit)２０１、記憶手段の一例である記憶部２０２、入力部の一例であるキーボード２０３、インターフェイス２０５、及び出力部の一例である表示部２０６を有しても良い。この例では、CPU２０１、記憶部２０２、キーボード２０３、インターフェイス２０５、及び表示部２０６がバス２０７により接続されているが、コンピュータ２００はバス２０７により接続された構成に限定されない。

コンピュータ２００がモバイル端末１０１を形成する場合には、インターフェイス２０５は無線通信機能を有する周知の通信部を含み、この通信部がアンテナなどを介してインターネット１０３と無線接続する。また、インターフェイス２０５は、USB接続を可能とする周知のUSB接続部を含み、指紋センサ１０２などをモバイル端末１０１に接続可能とする。なお、通信部は、USB接続部を含むインターフェイス２０５とは別体としてバス２０７に接続されていても良い。さらに、モバイル端末１０１が指紋センサ１０２を内蔵する場合には、指紋センサ１０２はバス２０７に直接接続されていても良い。

一方、コンピュータ２００がサービスサーバ１０５または統合認証サーバ１０６を形成する場合には、インターフェイス２０５は通信機能を有する周知の通信部を含み、この通信部がルータ１０７または１０８と通信可能に接続される。

記憶部２０２は、CPU２０１が実行するプログラム、各種データなどを格納する。記憶部２０２は、メモリ、HDD（Hard Disk Drive）などの記憶装置で形成しても良い。CPU２０１は、記憶部２０２に格納されたプログラムを実行することにより、コンピュータ２００全体の制御を司る。CPU２０１は、プログラムを実行することで、図１０に示すモバイル端末１０１の機能、或いは、図１０に示すサービスサーバ１０５の機能、或いは、図１０に示す統合認証サーバ１０６の機能を実現できる。プログラムがモバイル端末１０１の機能を実現する場合、このプログラムは図８に示すホストコントローラ１３２、モバイル端末用OS１３４、ブラウザ１３７、ブラウザの子プロセス１３８、及び独自認証クライアントアプリ１３９を含んでも良い。

キーボード２０３は、CPU２０１にコマンド及びデータを入力するのに用いられる。インターフェイス２０５は、コンピュータ２００と外部装置との接続に使用される。表示部２０６は、CPU２０１の制御下で、コンピュータ２００のユーザに対して各種メッセージやデータを表示する。コンピュータ２００がモバイル端末１０１を形成する場合、表示部２０６は、例えば図１１に示す画面を表示しても良い。キーボード２０３及び表示部２０６は、例えば図１１に示すタッチパネルのように一体的に設けられていても良い。

上記実施例では、ブラウザにプラグインを導入したり、プロセス間通信を行うことができず、デバイスドライバの追加も行えないモバイル端末用OSにおいて、生体データによる代行認証とログインを行うため、次の対策を取っている。

先ず、生体認証部とSAML2サーバIdP部を有する統合認証サーバを用意する。次に、クラウドサービスを提供するサービスサーバにSAML2サーバSP部を用意し、サービスサーバへの認証を統合認証サーバに代行させるようにする。クラウドサービスは、SAML2認証に対応している場合が多く、管理者自身はSAML2認証を設定するだけで良い。指紋認証などの生体認証とSAML2認証も、夫々オープンソースや製品などで提供されており、例えば企業または団体が保有する既存の設備に応じて用意できる。そこで、ユーザは、モバイル端末にUSB経由で指紋センサを接続し、指紋センサを駆動して認証を行い認証結果を元にサービスサーバへ代行ログインを実施する独自認証クライアントアプリをモバイル端末にインストールする。

この独自認証クライアントアプリは、モバイル端末用OSのAPIを通じて、USBホストコントローラのデバイスドライバを呼び出す。モバイル端末は、このデバイスドライバを経由して、USBホストコントローラに接続された指紋センサと直接データを送受信することができる。このため、指紋センサに直接コマンドデータを送信することにより、指紋センサを制御することができる。これにより、指紋センサのデバイスドライバを導入しなくても、指紋センサからユーザの照合用生体データを取得することができる。そして、ユーザIDと共に照合用生体データを統合認証サーバに送信してユーザ認証を求めることにより、ユーザ認証が成功した場合に、SAML2サーバIdP部から認証を求められた際に渡すOTPを入手できる。

さらに、独自認証クライアントアプリは、サービスサーバに用意されたSAML2サーバSP部に対してサービスの提供を要求し、返信されてくるSAML2データをSAML2サーバIdP部にリダイレクトすることができる。また、これとは逆に、独自認証クライアントアプリは、SAML2サーバIdP部から送られてくるSAML2データをSAML2サーバSP部にリダイレクトすることができる。SAML2プロトコルは、HTTPSプロトコルの上にSOAPプロトコルを乗せ、さらにSOAPプロトコルの上にSAML2プロトコルを乗せるプロトコルであるため、非常に複雑なプロトコルである。しかし、殆どの処理はSAML2サーバIdP部とSAML2サーバSP部で行われ、モバイル端末はHTTPレスポンスヘッダの中の「Location:」記述か、htmlのヘッダ部分「<head> </head>」で囲まれた中に存在する「<meta http-equiv="Refresh"」というRefresh記述に従って転送するサーバを特定し、残りの部分をデータとして送信すれば良い。これにより、独自認証クライアントアプリは、比較的少ない工数で実装することができる。

独自認証クライアントアプリは、比較的少ない工数で実装できるが、サービスサーバが提供するサービスをサービスサーバと連携して実行して表示するブラウザは、比較的多い工数の実装を必要とする。また、仮に独自認証クライアントアプリをモバイル端末用OS用のアプリとして実装したとしても、後から追加するアプリは、最初からモバイル端末のOSと一緒に用意されるデフォルトアプリと比較して、ハードウェアのネイティブな機能を直接操作することができないため、実行速度に問題を有する場合がある。

そこで、独自認証クライアントアプリは、最初にユーザIDと照合用生体データを統合認証サーバに送り、OTPを入手する。次に、独自認証クライアントアプリは、サービスサーバのSAML2サーバSP部にサービスの提供要求を出してSAML2プロトコルによる認証を開始する。独自認証クライアントアプリは、SAML2データ通信をSAML2サーバSP部とSAML2サーバIdP部の間で中継する。独自認証クライアントアプリは、統合認証サーバからユーザIDとパスワードを要求するhtmlページが送られてくると、htmlページを破棄して画面表示は行わず、代わりに予め用意してあるユーザIDとOTPを送信する。これにより、SAML2の認証は成功し、SAML2サーバIdP部からSAML2サーバSP部へ向けてサービスの使用を許可するURL付SAML認証応答メッセージが送信される。

このように、独自認証クライアントアプリは、リダイレクトせず、代わりにデフォルトアプリのブラウザの子プロセスを、URL付SAML認証応答メッセージを引数に生成する。以降のSAML2認証は、デフォルトアプリのブラウザの子プロセスによって行われる。ユーザIDとパスワードの認証は既に完了しているので、ブラウザの子アプリのSAML認証は最後まで行われ、サービスの使用許可が下りてサービスが使用できるようになる。サービスの実行は、デフォルトアプリのブラウザの子プロセスで行われているので、十分な実行速度を持った、スムーズな処理が行われる。

従って、クラウドサービスプロバイダからのサービス利用を、ユーザによるパスワード入力ではなく、生体データの照合による認証で代行することができる。さらに、SAML2関連の実装は、リダイレクト処理だけで、少なくすることができる。処理の最後でSAML2認証の処理をデフォルトアプリのブラウザの子プロセスに委譲することによって、サービスの実行をハードウェアアクセラレーションの効いた、素早い実行速度で行うことができる。

なお、上記実施例は、生体センサに指紋センサを採用しているが、生体センサに静脈センサまたは虹彩センサを採用しても、指紋センサを採用した場合と同様に静脈データまたは虹彩データなどの生体データを取得できることは言うまでもない。

また、他の実施例において、モバイル端末に接続するデバイスが生体センサではなく、ICカードやUSBトークンなどのUSBストレージであっても良い。この場合、USBストレージ内に、予め統合認証サーバがユーザ毎に乱数で発行した暗号鍵（または、署名データ）を記憶しておき、照合用生体データの代わりにUSBストレージから読み取った暗号鍵を統合認証サーバに送信し、この暗号鍵の正しさを統合認証サーバで確認することでユーザ認証を行える。統合認証サーバでは、USBストレージから読み出されたモバイル端末からの暗号鍵がユーザ毎に発行した暗号鍵であるか否か判定することで、ICカードやUSBトークンなどの所有物認証、即ち、パスワードの代わりの代行認証を行うことができる。

上記の各実施例によれば、セキュリティやビジネスモデルの制約から、デバイスドライバの追加導入、プロセス間通信によるパスワードの代行入力、ブラウザプラグインによるパスワードの代行返信などが制限されているモバイル端末において、SAML2データをリダイレクトする機能、生体認証部にパスワードを代行返信する機能、及びパスワード送信後に送られてきたSAML2データをブラウザの子プロセスに渡す機能を備えることによって、ユーザにパスワードを入力させること無く、生体認証やトークンによる代行認証を行うことができる。

上記の各実施例によれば、ユーザ認証に用いるデバイスを外部接続して比較的容易に認証機能を追加できる。

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ネットワークを介して第１のサーバ及び第２のサーバと通信可能な通信端末であって、
他のアプリケーションからプロセス間通信を受けて、それを引数として子プロセスを立ち上げるブラウザと、
ホストコントローラと、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出して前記ホストコントローラを制御するオペレーティングシステムと、
前記オペレーティングシステムのインタフェースを介して前記ホストコントローラに接続された前記センサとデータを送受信する独自認証アプリケーションとを備え、
前記独自認証アプリケーションは、
ユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、前記ユーザ認証が成功した場合に前記第２のサーバから送信されてくるパスワードを取得し、
前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記第２のサーバに送信したユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバから送信されてくる、前記第１のサーバを特定する情報を含む認証応答を、リダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを特徴とする、通信端末。
（付記２）
前記オペレーティングシステムは、デバイスドライバの追加、前記通信端末のアプリケーション間のプロセス間通信、及び前記ブラウザのプラグインによる拡張が制限されており、
前記独自認証アプリケーションは、前記第１のサーバから送信されてくる認証データを前記第２のサーバにリダイレクトすると共に、前記第２のサーバから送信されてくる認証データを前記第１のサーバにリダイレクトすることを特徴とする、付記１記載の通信端末。
（付記３）
前記独自認証アプリケーションは、
サービスを提供する複数の第１のサーバの一覧を取得するサービスサーバ一覧取得部と、
前記センサを制御して前記センサが検出したデータを取得するデータ取得部と、
サービス名と前記ユーザIDの入力をユーザに促すユーザ情報入力部と、
前記ユーザIDと前記データを前記第２のサーバに送信して前記パスワードを受け取る認証依頼部と、
前記サービス名と対となる選択された第１のサーバを特定する情報に従って前記選択された第１のサーバに対するサービスの提供要求を行うサービス要求部と、
前記選択された第１のサーバから送信されてくる前記認証データを、リダイレクト設定に従って前記第２のサーバにリダイレクトすると共に、前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記独自認証アプリケーションが前記画面に従った画面表示は行わずに予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信するデータリダイレクト部と、
前記第２のサーバから送られてくるユーザIDとパスワードの要求に対して、前記ユーザ情報入力部が取得したユーザIDと、前記認証依頼部が取得したパスワードを前記第２のサーバに送信するユーザIDパスワード送信部と、
前記ユーザIDパスワード送信部がユーザIDとパスワードを送信した後、最初に認証データを受け取った際に、認証データ中のサーバドメイン部分に従って前記選択された第１のサーバに接続し、前記認証データ中の付属の認証データ部分が渡される前記ブラウザの子プロセスを生成する子プロセス生成部
を含むことを特徴とする、付記１または２記載の通信端末。
（付記４）
前記データは、ユーザの指紋、静脈、及び虹彩のいずれかの生体データであることを特徴とする、付記１乃至３のいずれか１項記載の通信端末。
（付記５）
前記ネットワークは、インターネットを含み、
前記第１のサーバを特定する情報はURL（Uniform Resource Locator）であることを特徴とする、付記１乃至４のいずれか１項記載の通信端末。
（付記６）
前記認証データは、SAML 2（Security Assertion Markup Language 2.0）に準拠した認証データであることを特徴とする、付記１乃至５のいずれか１項記載の通信端末。
（付記７）
前記データは、ユーザの所有物認証のデータであることを特徴とする、付記１乃至３のいずれか１項記載の通信端末。
（付記８）
ネットワークを介して第１のサーバ及び第２のサーバと通信する通信端末のセキュアログイン方法であって、
他のアプリケーションからプロセス間通信を受けて、それを引数として前記通信端末の子プロセスを立ち上げ、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出してホストコントローラを制御する前記通信端末のオペレーティングシステムのインタフェースを介して、前記通信端末の独自認証アプリケーションが前記ホストコントローラに接続された前記センサとデータを送受信し、
前記独自認証アプリケーションがユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、
前記ユーザ認証が成功した場合に前記第２のサーバがパスワードを前記通信端末に送信し、
前記独自認証アプリケーションが前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記独自認証アプリケーションが予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記通信端末から送信されてくるユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバが前記第１のサーバを特定する情報を含む認証応答を前記通信端末に送信し、
前記独自認証アプリケーションが前記認証応答をリダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを特徴とする、セキュアログイン方法。
（付記９）
前記オペレーティングシステムは、デバイスドライバの追加、前記通信端末のアプリケーション間のプロセス間通信、及び前記ブラウザのプラグインによる拡張が制限されており、
前記独自認証アプリケーションが、前記第１のサーバから送信されてくる認証データを前記第２のサーバにリダイレクトすると共に、前記第２のサーバから送信されてくる認証データを前記第１のサーバにリダイレクトすることを特徴とする、付記８記載のセキュアログイン方法。
（付記１０）
前記独自認証アプリケーションは、
サービスサーバ一覧取得部によりサービスを提供する複数の第１のサーバの一覧を取得し、
データ取得部により前記センサを制御して前記センサが検出したデータを取得し、
ユーザ情報入力部によりサービス名と前記ユーザIDの入力をユーザに促し、
認証依頼部により前記ユーザIDと前記データを前記第２のサーバに送信して前記パスワードを受け取り、
サービス要求部により前記サービス名と対となる選択された第１のサーバを特定する情報に従って前記選択された第１のサーバに対するサービスの提供要求を行い、
データリダイレクト部により前記選択された第１のサーバから送信されてくる前記認証データを、リダイレクト設定に従って前記第２のサーバにリダイレクトすると共に、前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記独自認証アプリケーションが前記画面に従った画面表示は行わずに予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
ユーザIDパスワード送信部により前記第２のサーバから送られてくるユーザIDとパスワードの要求に対して、前記ユーザ情報入力部が取得したユーザIDと、前記認証依頼部が取得したパスワードを前記第２のサーバに送信し、
子プロセス生成部により前記ユーザIDパスワード送信部がユーザIDとパスワードを送信した後、最初に認証データを受け取った際に、認証データ中のサーバドメイン部分に従って前記選択された第１のサーバに接続し、前記認証データ中の付属の認証データ部分が渡される前記ブラウザの子プロセスを生成する
ことを特徴とする、付記８または９記載のセキュアログイン方法。
（付記１１）
前記生体データは、ユーザの指紋、静脈、及び虹彩のいずれかの生体データであることを特徴とする、付記８乃至１０のいずれか１項記載のセキュアログイン方法。
（付記１２）
前記ネットワークは、インターネットを含み、
前記第１のサーバを特定する情報はURL（Uniform Resource Locator）であることを特徴とする、付記８乃至１１のいずれか１項記載のセキュアログイン方法。
（付記１３）
前記認証データは、SAML 2（Security Assertion Markup Language 2.0）に準拠した認証データであることを特徴とする、付記８乃至１２のいずれか１項記載のセキュアログイン方法。
（付記１４）
前記データは、ユーザの所有物認証のデータであることを特徴とする、付記８乃至１０のいずれか１項記載のセキュアログイン方法。
（付記１５）
通信端末のプロセッサに、ネットワークを介して第１のサーバ及び第２のサーバと通信する処理を実行させるプログラムであって、
他のアプリケーションからプロセス間通信を受けて、それを引数として子プロセスを立ち上げ、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出して前記通信端末のホストコントローラを制御する前記通信端末のオペレーティングシステムのインタフェースを介して、前記通信端末の独自認証アプリケーションが前記ホストコントローラに接続された前記センサとデータを送受信するし、
前記独自認証アプリケーションが、
ユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、前記ユーザ認証が成功した場合に前記第２のサーバから送信されてくるパスワードを取得し、
前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記第２のサーバに送信したユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバから送信されてくる、前記第１のサーバを特定する情報を含む認証応答を、リダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを含む処理を前記プロセッサに実行させることを特徴とする、プログラム。
（付記１６）
前記オペレーティングシステムは、デバイスドライバの追加、前記通信端末のアプリケーション間のプロセス間通信、及び前記ブラウザのプラグインによる拡張が制限されており、
前記独自認証アプリケーションが、前記第１のサーバから送信されてくる認証データを前記第２のサーバにリダイレクトすると共に、前記第２のサーバから送信されてくる認証データを前記第１のサーバにリダイレクトすることを特徴とする、付記１５記載のプログラム。
（付記１７）
前記独自認証アプリケーションが、
サービスサーバ一覧取得部によりサービスを提供する複数の第１のサーバの一覧を取得し、
データ取得部により前記センサを制御して前記センサが検出したデータを取得し、
ユーザ情報入力部によりサービス名と前記ユーザIDの入力をユーザに促し、
認証依頼部により前記ユーザIDと前記データを前記第２のサーバに送信して前記パスワードを受け取り、
サービス要求部により前記サービス名と対となる選択された第１のサーバを特定する情報に従って前記選択された第１のサーバに対するサービスの提供要求を行い、
データリダイレクト部により前記選択された第１のサーバから送信されてくる前記認証データを、リダイレクト設定に従って前記第２のサーバにリダイレクトすると共に、前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記独自認証アプリケーションが前記画面に従った画面表示は行わずに予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
ユーザIDパスワード送信部により前記第２のサーバから送られてくるユーザIDとパスワードの要求に対して、前記ユーザ情報入力部が取得したユーザIDと、前記認証依頼部が取得したパスワードを前記第２のサーバに送信し、
子プロセス生成部により前記ユーザIDパスワード送信部がユーザIDとパスワードを送信した後、最初に認証データを受け取った際に、認証データ中のサーバドメイン部分に従って前記選択された第１のサーバに接続し、前記認証データ中の付属の認証データ部分が渡される前記ブラウザの子プロセスを生成する
ことを含む処理を前記プロセッサに実行させることを特徴とする、付記１５または１６記載のプログラム。
（付記１８）
前記生体データは、ユーザの指紋、静脈、及び虹彩のいずれかの生体データであることを特徴とする、付記１５乃至１７のいずれか１項記載のプログラム。
（付記１９）
前記ネットワークは、インターネットを含み、
前記第１のサーバを特定する情報はURL（Uniform Resource Locator）であることを特徴とする、付記１５乃至１８のいずれか１項記載のプログラム。
（付記２０）
前記認証データは、SAML 2（Security Assertion Markup Language 2.0）に準拠した認証データであることを特徴とする、付記１５乃至１９のいずれか１項記載のプログラム。

以上、開示の通信端末、セキュアログイン方法、及びプログラムを実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは言うまでもない。

１０１モバイル端末
１０２指紋センサ
１０３インターネット
１０４データセンタ
１０５サービスサーバ
１０６統合認証サーバ
１０７，１０８ルータ
１３２ USBホストコントローラ
１３４モバイル端末用OS
１３７ブラウザ
１３９独自認証クライアントアプリ
２００コンピュータ
２０１ CPU
２０２記憶部

Claims

ネットワークを介して第１のサーバ及び第２のサーバと通信可能な通信端末であって、
他のアプリケーションからプロセス間通信を受けて、それを引数として子プロセスを立ち上げるブラウザと、
ホストコントローラと、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出して前記ホストコントローラを制御するオペレーティングシステムと、
前記オペレーティングシステムのインタフェースを介して前記ホストコントローラに接続された前記センサとデータを送受信する独自認証アプリケーションとを備え、
前記独自認証アプリケーションは、
ユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、前記ユーザ認証が成功した場合に前記第２のサーバから送信されてくるパスワードを取得し、
前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記第２のサーバに送信したユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバから送信されてくる、前記第１のサーバを特定する情報を含む認証応答を、リダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを特徴とする、通信端末。
前記オペレーティングシステムは、デバイスドライバの追加、前記通信端末のアプリケーション間のプロセス間通信、及び前記ブラウザのプラグインによる拡張が制限されており、
前記独自認証アプリケーションは、前記第１のサーバから送信されてくる認証データを前記第２のサーバにリダイレクトすると共に、前記第２のサーバから送信されてくる認証データを前記第１のサーバにリダイレクトすることを特徴とする、請求項１記載の通信端末。
前記独自認証アプリケーションは、
サービスを提供する複数の第１のサーバの一覧を取得するサービスサーバ一覧取得部と、
前記センサを制御して前記センサが検出したデータを取得するデータ取得部と、
サービス名と前記ユーザIDの入力をユーザに促すユーザ情報入力部と、
前記ユーザIDと前記データを前記第２のサーバに送信して前記パスワードを受け取る認証依頼部と、
前記サービス名と対となる選択された第１のサーバを特定する情報に従って前記選択された第１のサーバに対するサービスの提供要求を行うサービス要求部と、
前記選択された第１のサーバから送信されてくる前記認証データを、リダイレクト設定に従って前記第２のサーバにリダイレクトすると共に、前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記画面に従った画面表示は行わずに予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信するデータリダイレクト部と、
前記第２のサーバから送られてくるユーザIDとパスワードの要求に対して、前記ユーザ情報入力部が取得したユーザIDと、前記認証依頼部が取得したパスワードを前記第２のサーバに送信するユーザIDパスワード送信部と、
前記ユーザIDパスワード送信部がユーザIDとパスワードを送信した後、最初に認証データを受け取った際に、認証データ中のサーバドメイン部分に従って前記選択された第１のサーバに接続し、前記認証データ中の付属の認証データ部分が渡される前記ブラウザの子プロセスを生成する子プロセス生成部
を含むことを特徴とする、請求項１または２記載の通信端末。
ネットワークを介して第１のサーバ及び第２のサーバと通信する通信端末のセキュアログイン方法であって、
他のアプリケーションからプロセス間通信を受けて、それを引数として前記通信端末の子プロセスを立ち上げ、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出してホストコントローラを制御する前記通信端末のオペレーティングシステムのインタフェースを介して、前記通信端末の独自認証アプリケーションが前記ホストコントローラに接続された前記センサとデータを送受信し、
前記独自認証アプリケーションがユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、
前記ユーザ認証が成功した場合に前記第２のサーバがパスワードを前記通信端末に送信し、
前記独自認証アプリケーションが前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、前記独自認証アプリケーションが予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記通信端末から送信されてくるユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバが前記第１のサーバを特定する情報を含む認証応答を前記通信端末に送信し、
前記独自認証アプリケーションが前記認証応答をリダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを特徴とする、セキュアログイン方法。
通信端末のプロセッサに、ネットワークを介して第１のサーバ及び第２のサーバと通信する処理を実行させるプログラムであって、
他のアプリケーションからプロセス間通信を受けて、それを引数として子プロセスを立ち上げ、
センサを制御するインタフェースを含む複数のインタフェースから１つのインタフェースを呼び出して前記通信端末のホストコントローラを制御する前記通信端末のオペレーティングシステムのインタフェースを介して、前記通信端末の独自認証アプリケーションが前記ホストコントローラに接続された前記センサとデータを送受信するし、
前記独自認証アプリケーションが、
ユーザIDと共に前記センサが検出した照合用データを前記第２のサーバに送信してユーザ認証を要求し、前記ユーザ認証が成功した場合に前記第２のサーバから送信されてくるパスワードを取得し、
前記第１のサーバに対してサービスの提供を要求した結果前記第１のサーバから送信されてくる認証データを前記第１のサーバと前記第２のサーバとの間で中継し、
前記第２のサーバからユーザIDとパスワードの入力を促す画面を受信した場合に、予め用意されたユーザIDと既に取得しているパスワードを前記第２のサーバに送信し、
前記第２のサーバに送信したユーザIDとパスワードの対が前記第２のサーバに格納されていて認証が成功した場合に前記第２のサーバから送信されてくる、前記第１のサーバを特定する情報を含む認証応答を、リダイレクトせずに前記第２のサーバとの通信を切断すると共に、前記認証応答に基づく引数で前記ブラウザの子プロセスを起動して前記認証応答を前記第１のサーバへ送信してログインすることで前記第１のサーバのサービスの提供を受ける
ことを含む処理を前記プロセッサに実行させることを特徴とする、プログラム。