特許 5979652 サーバ・アプリケーションへの認証されたユーザ・アクセスの方法、そのようなユーザ・アクセスを提供する装置、コンピュータ・プログラム製品、およびサーバ・アプリケーションへのアクセスを容易にする方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5979652

(24)【登録日】2016年8月5日

(45)【発行日】2016年8月24日

(54)【発明の名称】サーバ・アプリケーションへの認証されたユーザ・アクセスの方法、そのようなユーザ・アクセスを提供する装置、コンピュータ・プログラム製品、およびサーバ・アプリケーションへのアクセスを容易にする方法

(51)【国際特許分類】

   G06F 21/33 20130101AFI20160817BHJP

【ＦＩ】

   G06F21/33

【請求項の数】26

【全頁数】20

(21)【出願番号】特願2014-517362(P2014-517362)

(86)(22)【出願日】2012年7月9日

(65)【公表番号】特表2014-518420(P2014-518420A)

(43)【公表日】2014年7月28日

(86)【国際出願番号】CA2012050461

(87)【国際公開番号】WO2013006967

(87)【国際公開日】20130117

【審査請求日】2014年12月24日

(31)【優先権主張番号】13/178,633

(32)【優先日】2011年7月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100108501

【弁理士】

【氏名又は名称】上野 剛史

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(72)【発明者】

【氏名】ピーサル、オルギュルト、スタニスラフ

(72)【発明者】

【氏名】マッグローイン、マーク、アレクサンダー

(72)【発明者】

【氏名】ザーコ、メアリー、エレン

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２０１０−１４０３５１（ＪＰ，Ａ）

【文献】 特開２００６−０５９２６７（ＪＰ，Ａ）

【文献】 特開２００４−１１０３３５（ＪＰ，Ａ）

【文献】 特開２０１２−０９９０１７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ２１／３０−Ｇ０６Ｆ２１／４６

(57)【特許請求の範囲】

【請求項1】

サーバ・アプリケーションへの認証されたユーザ・アクセスの方法であって、
ユーザ入力をブラウザ・ベースのクライアントで受け取って前記サーバ・アプリケーションとのウェブ・セッションを開始するステップと、
前記ブラウザ・ベースのクライアントで資格証明を受け取るステップと、
前記サーバ・アプリケーションと対話することが可能なリッチ・クライアントが実行されているかどうかを前記ウェブ・セッション中で発見するステップと、
前記リッチ・クライアントが実行されていることを発見することに応じて、前記ウェブ・セッション中で前記リッチ・クライアントに資格証明を提供するステップであって、前記資格証明は、前記ブラウザ・ベースのクライアントで受け取られた資格証明と、前記サーバ・アプリケーションから受け取られた新しい資格証明との内の１つである、前記提供するステップと、
前記リッチ・クライアントに提供された前記資格証明を前記ウェブ・セッション中で使用して、前記リッチ・クライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む、前記方法。

【請求項2】

前記リッチ・クライアントが実行されているかどうかを発見する前記ステップは、ローカルに実行している１つまたは複数のリッチ・クライアントの動作状態を判定する発見動作を開始するステップを含む、請求項１に記載の方法。

【請求項3】

サーバ・アプリケーションへの認証されたユーザ・アクセスの方法であって、
ユーザ入力をブラウザ・ベースのクライアントで受け取って前記サーバ・アプリケーションとのウェブ・セッションを開始するステップと、
前記ブラウザ・ベースのクライアントで資格証明を受け取るステップと、
前記サーバ・アプリケーションと対話することが可能なリッチ・クライアントが実行を前記ウェブ・セッション中で特定するステップであって、前記リッチ・クライアントを特定する前記ステップは、ローカルに実行している１つまたは複数のリッチ・クライアントの動作状態を判定する発見動作を開始するステップを含む、前記特定するステップと、
前記ウェブ・セッション中で前記リッチ・クライアントに資格証明を提供するステップであって、前記資格証明は、前記ブラウザ・ベースのクライアントで受け取られた資格証明と、前記サーバ・アプリケーションから受け取られた新しい資格証明との内の１つである、前記提供するステップと、
前記リッチ・クライアントに提供された前記資格証明を前記ウェブ・セッション中で使用して、前記リッチ・クライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む、前記方法。

【請求項4】

前記ローカルに実行している１つまたは複数のリッチ・クライアントを示す表示を前記ユーザに提供するステップと、
前記資格証明が提供されるリッチ・クライアントを特定する選択を前記ユーザから受け取るステップと
をさらに含む、請求項２又は３に記載の方法。

【請求項5】

前記ブラウザ・ベースのクライアントと前記リッチ・クライアントとの間に制御チャネルを確立するステップをさらに含む、請求項１〜４のいずれか一項に記載の方法。

【請求項6】

前記制御チャネルを使用して前記リッチ・クライアントに前記資格証明を提供するステップをさらに含む、請求項５に記載の方法。

【請求項7】

前記リッチ・クライアントに提供される前記資格証明は、前記サーバ・アプリケーションに関して少なくとも１つのアクセス制限を定義したポリシーに関連付けられる、請求項１〜６のいずれか一項に記載の方法。

【請求項8】

前記ポリシーはユーザによって設定されたポリシーである、請求項７に記載の方法。

【請求項9】

前記リッチ・クライアントに提供された前記資格証明を無効にするステップをさらに含む、請求項１〜８のいずれか一項に記載の方法。

【請求項10】

サーバ・アプリケーションへの認証されたユーザ・アクセスを提供する装置であって、
プロセッサと、
コンピュータ・メモリと
を備えており、前記コンピュータ・メモリは、前記プロセッサによって実行されると、
ユーザ入力をブラウザ・ベースのクライアントで受け取って前記サーバ・アプリケーションとのウェブ・セッションを開始するステップと、
前記ブラウザ・ベースのクライアントで資格証明を受け取るステップと、
前記サーバ・アプリケーションと対話することが可能なリッチ・クライアントが実行されているかどうかを前記ウェブ・セッション中で発見するステップと、
前記リッチ・クライアントが実行されていることを発見することに応じて、前記ウェブ・セッション中で前記リッチ・クライアントに資格証明を提供するステップであって、前記資格証明は、前記ブラウザ・ベースのクライアントで受け取られた資格証明と、前記サーバ・アプリケーションから受け取られた新しい資格証明との内の１つである、前記提供するステップと、
前記リッチ・クライアントに提供された前記資格証明を前記ウェブ・セッション中で使用して、前記リッチ・クライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む方法を実行するコンピュータ・プログラム命令を保持する、前記装置。

【請求項11】

前記リッチ・クライアントが実行されているかどうかを発見する前記ステップは、ローカルに実行している１つまたは複数のリッチ・クライアントの動作状態を判定する発見動作を開始するステップを含む、請求項１０に記載の装置。

【請求項12】

サーバ・アプリケーションへの認証されたユーザ・アクセスを提供する装置であって、
プロセッサと、
コンピュータ・メモリと
を備えており、前記コンピュータ・メモリは、前記プロセッサによって実行されると、
ユーザ入力をブラウザ・ベースのクライアントで受け取って前記サーバ・アプリケーションとのウェブ・セッションを開始するステップと、
前記ブラウザ・ベースのクライアントで資格証明を受け取るステップと、
前記サーバ・アプリケーションと対話することが可能なリッチ・クライアントを前記ウェブ・セッション中で特定するステップであって、前記リッチ・クライアントを特定する前記ステップは、ローカルに実行している１つまたは複数のリッチ・クライアントの動作状態を判定する発見動作を開始するステップを含む、前記特定するステップと、
前記ウェブ・セッション中で前記リッチ・クライアントに資格証明を提供するステップであって、前記資格証明は、前記ブラウザ・ベースのクライアントで受け取られた資格証明と、前記サーバ・アプリケーションから受け取られた新しい資格証明との内の１つである、前記提供するステップと、
前記リッチ・クライアントに提供された前記資格証明を前記ウェブ・セッション中で使用して、前記リッチ・クライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む方法を実行するコンピュータ・プログラム命令を保持する、前記装置。

【請求項13】

前記方法は、
前記ローカルに実行している１つまたは複数のリッチ・クライアントを示す表示を前記ユーザに提供するステップと、
前記資格証明が提供されるリッチ・クライアントを特定する選択を前記ユーザから受け取るステップと
をさらに含む、請求項１１又は１２に記載の装置。

【請求項14】

前記方法は、前記ブラウザ・ベースのクライアントと前記リッチ・クライアントとの間に制御チャネルを確立するステップをさらに含む、請求項１０〜１３のいずれか一項に記載の装置。

【請求項15】

前記方法は、前記制御チャネルを使用して前記リッチ・クライアントに前記資格証明を提供するステップをさらに含む、請求項１４に記載の装置。

【請求項16】

前記リッチ・クライアントに提供される前記資格証明は、前記サーバ・アプリケーションに関して少なくとも１つのアクセス制限を定義したポリシーに関連付けられる、請求項１０〜１５のいずれか一項に記載の装置。

【請求項17】

前記ポリシーはユーザによって設定されたポリシーである、請求項１６に記載の装置。

【請求項18】

前記方法は、前記リッチ・クライアントに提供された前記資格証明を無効にするステップをさらに含む、請求項１０〜１７のいずれか一項に記載の装置。

【請求項19】

サーバ・アプリケーションへの認証されたユーザ・アクセスを提供するためのコンピュータ・プログラムであって、データ処理システムに、請求項１〜９のいずれか一項に記載の方法の各ステップを実行させる、前記コンピュータ・プログラム。

【請求項20】

第１のクライアントによって開始されたユーザ・セッション内から第２のクライアントによるサーバ・アプリケーションへのアクセスを容易にする方法であって、前記第１のクライアントと第２のクライアントは同じ場所にあり、前記第２のクライアントは非ブラウザ・ベースのクライアントであり、前記方法は、
前記第１のクライアントと前記第２のクライアントとの間に制御チャネルを確立するステップであって、前記制御チャネルの確立によって、前記第２のクライアントはＨＴＴＰサーバを含むように変更される、前記確立するステップと、
前記ユーザ・セッションが進行中に、前記ＨＴＴＰサーバのローカルホスト接続のポートにＨＴＴＰ要求を送信することにより、前記サーバ・アプリケーションと対話するために前記第２のクライアントが実行中であるかどうかを発見するステップと、
前記第２のクライアントが実行中であることを発見することに応じて、前記第２のクライアントに資格証明を提供するステップと、
前記資格証明を使用して、前記第２のクライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む、前記方法。

【請求項21】

前記第２のクライアントに提供される前記資格証明は、前記ユーザ・セッションが開始された時に前記第１のクライアントにより取得される資格証明である、請求項２０に記載の方法。

【請求項22】

前記第２のクライアントに提供される前記資格証明は、前記サーバ・アプリケーションからの応答を受信するように前記第２のクライアントを登録することによって取得され、前記応答は前記資格証明を含む、請求項２０又は２１に記載の方法。

【請求項23】

第１のクライアントによって開始されたユーザ・セッション内から第２のクライアントによるサーバ・アプリケーションへのアクセスを容易にする装置であって、前記第１のクライアントと第２のクライアントは同じ場所にあり、前記第２のクライアントは非ブラウザ・ベースのクライアントであり、前記装置は、
プロセッサと、
コンピュータ・メモリと
を備えており、前記コンピュータ・メモリは、前記プロセッサによって実行されると、
前記第１のクライアントと前記第２のクライアントとの間に制御チャネルを確立するステップであって、前記制御チャネルの確立によって、前記第２のクライアントはＨＴＴＰサーバを含むように変更される、前記確立するステップと、
前記ユーザ・セッションが進行中に、前記ＨＴＴＰサーバのローカルホスト接続のポートにＨＴＴＰ要求を送信することにより、前記サーバ・アプリケーションと対話するために前記第２のクライアントが実行中であるかどうかを発見するステップと、
前記第２のクライアントが実行中であることを発見することに応じて、前記第２のクライアントに資格証明を提供するステップと、
前記資格証明を使用して、前記第２のクライアントを用いて前記ユーザを前記サーバ・アプリケーションに対して認証するステップと
を含む方法を実行するコンピュータ・プログラム命令を保持する、前記装置。

【請求項24】

前記第２のクライアントに提供される前記資格証明は、前記ユーザ・セッションが開始された時に前記第１のクライアントにより取得される資格証明である、請求項２３に記載の装置。

【請求項25】

前記第２のクライアントに提供される前記資格証明は、前記サーバ・アプリケーションからの応答を受信するように前記第２のクライアントを登録することによって取得され、前記応答は前記資格証明を含む、請求項２３又は２４に記載の装置。

【請求項26】

サーバ・アプリケーションへの認証されたユーザ・アクセスを提供するためのコンピュータ・プログラムであって、前記データ処理システムに、請求項２０〜２２のいずれか一項に記載の方法の各ステップを実行させる、前記コンピュータ・プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般にはアプリケーションのセキュリティに関し、詳細には、既存のウェブ・ブラウザ・セッション内から「リッチ・クライアント」の資格証明を渡す、または取得することを可能にする方法に関する。

【背景技術】

【0002】

従来技術では、ウェブ・ベースまたはクラウド・ベースのアプリケーションをいわゆる「リッチ」クライアントと統合することが知られている。「リッチ」クライアントとは、（単にウェブ・アプリケーション自体からウェブ・インタフェースをエクスポートするのではなく）独自のインタフェースをサポートする（クライアント−サーバ・アプリケーションの）クライアントである。「リッチ」クライアントは、通例はブラウザ・ベースでなく、（ブラウザ・ベースまたは「シン（thin）」クライアントに対して）「シック（thick）」クライアントと呼ばれることもある。リッチ・クライアントの例はＬｏｔｕｓ Ｎｏｔｅｓ（Ｒ）であり、これは電子メール、カレンダー機能、連絡先管理、およびインスタント・メッセージ機能を提供する。リッチ・クライアントを使用すると、ユーザに代わって、動作にアクセスし、自動的に動作を行うことができる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

この種の非ブラウザ・ベースの（リッチ）クライアント・アプリケーションの多くは、ブラウザ・ベース（シン・クライアント）のアプリケーションの相当版または機能も有する。シン・クライアントは、単純なウェブ・ブラウザやログイン・ページでありうる。エンド・ユーザが１つのワークステーションからそのような複数のクライアントを同時に使用したい場合、ユーザは権限付与サーバに別々に認証を行わなければならない。この必要性に対処する一般的な手法はパスワードの使用であり、その場合パスワードは例えばクライアントごとに１つのインタフェースなど、複数のインタフェースに入力される。この手法は、ユーザが自分のパスワードを複数回入力する必要があるため、ユーザにとって利便ではない。さらに、ユーザがパスワードを（各クライアントに）ローカルに記憶しておく場合は、複数個のコピーが記憶されることから、セキュリティ上の危険の可能性が増す。さらに、ユーザがパスワードを変更する時には、複数の場所で同様に変更しなければならない。当然ながら、ユーザがパスワードを複数回入力せざるをえない時は、ユーザは恐らくは弱いパスワードを選択する。シン・クライアントの方式で典型的であるパスワードを用いた認証に対応しないウェブ・ベースまたはクラウド・ベースのアプリケーションがシングル・サインオン・プロトコル（ＳＡＭＬやＯｐｅｎＩＤなど）を使用する場合には別の問題が生じる。そのような場合、ユーザは、シック・クライアントとシン・クライアントそれぞれに異なる種類の認証資格証明および技術を使用しなければならず、さらなる非効率性とセキュリティ上の危険性が生じる。

【0004】

ユーザがウェブ・ベースまたはクラウド・ベースのアプリケーションとのセッション中に１度のみ認証するだけで、その認証が、ユーザが発見する可能性のある関連するリッチ・クライアントに伝搬されるか、または他の形で利用可能にされる技術を提供できることが望ましい。

【課題を解決するための手段】

【0005】

本開示によると、ユーザがシン（ブラウザ・ベースの）クライアントからウェブ・ベースまたはクラウド・ベースのアプリケーションに対して認証する。クライアントは、関連付けられたリッチ・クライアントを有する。ブラウザ・ベースのクライアントからセッションが開始された（かつ資格証明が取得された）後、ユーザは、リッチ・クライアントが利用可能であることを発見し、アプリケーションに対して自動的に、すなわち追加的なユーザ入力を行わずに（リッチ・クライアントを使用して）ユーザを認証する際に使用するために上記資格証明（または新しい資格証明）をリッチ・クライアントに取得させることができる。アプリケーション・インタフェースが、リッチ・クライアントの認証動作を設定するための表示をユーザに提供し、ユーザは、実行中であることが検出された場合にリッチ・クライアントを自動的に認証するかどうか、リッチ・クライアントによるアプリケーションへのアクセスを制限するか、およびどの程度制限するか、リッチ・クライアントによるアプリケーションへのアクセスを取り消すかどうか、およびいつ取り消すか等を指定することができる。

【0006】

一実施形態では、記載した動作を容易にするために、ブラウザとリッチ・クライアントの間に制御チャネルが確立され、リッチ・クライアントはＨＴＴＰサーバを含むように変更される。ＨＴＴＰサーバとのローカルホスト接続のポートにＨＴＴＰ要求を送信することにより、ブラウザは、リッチ・クライアントが実行中であるかどうかを判定し、ブラウザ・ベースの資格証明を渡すことができる。

【0007】

代替実施形態では、制御チャネルは、標準的なオペレーティング・システム機構を使用して実装される。詳細には、リッチ・クライアントが、あるコンテンツ・タイプをオペレーティング・システムに登録し、自身をそのタイプについてのハンドラとして設定する。リッチ・クライアントの認証を開始することを要求されると、ブラウザはアプリケーションにＨＴＴＰ要求を行って新しい資格証明を要求する。ＨＴＴＰ応答は、登録されたコンテンツ・タイプと一致するｍｉｍｅタイプの資格証明を含む。そして、オペレーティング・システムを通じて新しい資格証明がリッチ・クライアントに渡され、次いでリッチ・クライアントはその資格証明を使用してアプリケーションに対して認証する。

【0008】

上記の認証方法は装置内で行うことができる。装置は、プロセッサと、実行されると上記方法を行うコンピュータ・プログラム命令を保持したコンピュータ・メモリとを備える。

【0009】

別の代替実施形態では、認証方法は、データ処理システムで使用するコンピュータ可読媒体内のコンピュータ・プログラム製品によって行われる。コンピュータ・プログラム製品は、データ処理システムによって実行されると方法を行うコンピュータ・プログラム命令を保持する。

【0010】

上記では本発明の主要な特徴の一部を概説した。これらの特徴は単に説明を目的とするものと解釈されたい。開示される本発明を別の方式で適用する、または以下で説明するように本発明に変更を加えることにより、多くの他の有益な結果を達成することができる。

【0011】

本発明およびその利点をより完全に理解するために、次いで添付図面と併せて以下の説明を参照する。

【図面の簡単な説明】

【0012】

【図1】例示実施形態の例示的態様が実施されることが可能な分散データ処理環境の例示的なブロック図である。

【図2】例示実施形態の例示的態様が実施されることが可能なデータ処理システムの例示的なブロック図である。

【図3】本開示の技術が実施されることが可能な、クライアント・アプリケーションおよびそれに関連付けられたウェブ・ベースまたはクラウド・ベースのサーバ・アプリケーションの図である。

【図4】本開示の基本的な動作シナリオを説明するプロセス流れ図である。

【図5】本開示に係る、ユーザがアクセス・ポリシーを設定するためのアプリケーション・インタフェースの表示ページの図である。

【図6】ユーザがリッチ・クライアントの認証動作を開始する、または以前に許可したアクセスを取り消すためのアプリケーション・インタフェースの表示ページの図である。

【発明を実施するための形態】

【0013】

次いで、図面、特に図１〜図２を参照すると、本開示の例示実施形態を実施することが可能なデータ処理環境の例示的な図が提供される。図１および図２は例に過ぎず、本開示の主題の態様または実施形態を実装することが可能な環境に関する何らかの限定を主張または示唆するものではないことを理解されたい。本発明の主旨および範囲から逸脱することなく、図示の環境に多くの変更を加えることができる。

【0014】

次いで図面を参照すると、図１は、例示的実施形態の態様が実施されることが可能な分散データ処理システム例の図式表現を示す。分散データ処理システム１００はコンピュータのネットワークを含むことができ、その中で例示的実施形態の態様を実施することができる。分散データ処理システム１００は少なくとも１つのネットワーク１０２を含み、ネットワーク１０２は、分散データ処理システム１００内で相互に接続された各種機器およびコンピュータ間の通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線、無線の通信リンク、または光ファイバ・ケーブルなどの接続を含むことができる。

【0015】

図の例では、サーバ１０４およびサーバ１０６は、ネットワーク１０２、そして記憶ユニット１０８に接続されている。また、クライアント１１０、１１２、および１１４もネットワーク１０２に接続されている。これらのクライアント１１０、１１２、および１１４は、例えばパーソナル・コンピュータやネットワーク・コンピュータ等である。図の例では、サーバ１０４は、ブート・ファイルなどのデータ、オペレーティング・システム・イメージ、およびアプリケーションをクライアント１１０、１１２、および１１４に提供する。クライアント１１０、１１２、および１１４は、図の例ではサーバ１０４のクライアントである。分散データ処理システム１００は、図示しないサーバ、クライアント、および他の機器をさらに含むことができる。

【0016】

図の例では、分散データ処理システム１００はインターネットであり、ネットワーク１０２は伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のプロトコル・スイートを使用して相互と通信するネットワークおよびゲートウェイの世界規模の集まりに相当する。インターネットの核となるのは、データおよびメッセージを伝送する何千もの商用、行政機関、教育機関、および他のコンピュータ・システムからなる主要ノードまたはホスト・コンピュータ間を結ぶ高速データ通信回線の基幹通信網である。言うまでもなく、分散データ処理システム１００は、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）などの複数の種々のネットワークを含むように実装することもできる。上記のように、図１は例であり、本開示の主題の各種実施形態のアーキテクチャ上の限定ではなく、したがって図１に示す特定の要素は、本発明の例示的実施形態を実施することが可能な環境に関して限定的なものと見なすべきではない。

【0017】

次いで図２を参照すると、例示実施形態の態様を実施することが可能な例示的データ処理システムのブロック図が示される。データ処理システム２００は、図１のクライアント１１０などのコンピュータの一例であり、このシステム内に、本開示の例示実施形態の処理を実施するコンピュータ使用可能コードまたは命令を置くことができる。

【0018】

次いで図２を参照すると、例示実施形態を実施することが可能なデータ処理システムのブロック図が示される。データ処理システム２００は、図１のサーバ１０４やクライアント１１０などのコンピュータの一例であり、このシステム内に、例示実施形態の処理を実施するコンピュータ使用可能プログラム・コードまたは命令を置くことができる。この例では、データ処理システム２００は通信ファブリック２０２を含み、通信ファブリック２０２は、プロセッサ・ユニット２０４、メモリ２０６、永続性記憶装置２０８、通信ユニット２１０、入出力（Ｉ／Ｏ）ユニット２１２、およびディスプレイ２１４間の通信を提供する。

【0019】

プロセッサ・ユニット２０４は、メモリ２０６にロードすることが可能なソフトウェアに対する命令を実行する働きをする。プロセッサ・ユニット２０４は、特定の実装に応じて、１つまたは複数のプロセッサのセットとしても、またはマルチプロセッサ・コアとしてもよい。さらに、プロセッサ・ユニット２０４は、単一のチップ上に主要プロセッサが副プロセッサと共に存在する１つまたは複数の異種混合プロセッサ・システムを使用して実装してもよい。別の例として、プロセッサ・ユニット２０４は、複数個の同種のプロセッサを含む対称マルチプロセッサ（ＳＭＰ）システムであってもよい。

【0020】

メモリ２０６および永続性記憶装置２０８は、記憶装置の例である。記憶装置は、一時的にまたは永続的にあるいはその両方で情報を記憶することが可能な任意のハードウェアである。本例では、メモリ２０６は、例えば、ランダム・アクセス・メモリ、または任意の他の適切な揮発性もしくは不揮発性の記憶装置であってよい。永続性記憶装置２０８は、特定の実装に応じて各種の形態をとることができる。例えば、永続性記憶装置２０８は、１つまたは複数の構成要素または機器を含むことができる。例えば、永続性記憶装置２０８は、ハード・ドライブ、フラッシュ・メモリ、書き換え可能光ディスク、書き換え可能磁気テープ、またはそれらの何らかの組み合わせでありうる。永続性記憶装置２０８で使用される媒体は取り外し可能であってもよい。例えば、取り外し可能のハード・ドライブを永続性記憶装置２０８として使用することができる。

【0021】

本例では、通信ユニット２１０は、他のデータ処理システムまたは機器との通信を可能にする。本例では、通信ユニット２１０はネットワーク・インタフェース・カードである。通信ユニット２１０は、物理的な通信リンクおよびワイヤレスの通信リンクのどちらかまたは両方を使用することにより通信を提供することができる。

【0022】

入出力ユニット２１２は、データ処理システム２００に接続される可能性のある他の機器との間のデータの入力および出力を可能にする。例えば、入出力ユニット２１２は、キーボードおよびマウスを通じたユーザ入力のための接続を提供することができる。さらに、入出力ユニット２１２は出力をプリンタに送信することができる。ディスプレイ２１４は、ユーザに情報を表示する機構を提供する。

【0023】

オペレーティング・システムおよびアプリケーションまたはプログラムに対する命令は永続性記憶装置２０８に置かれる。それらの命令は、プロセッサ・ユニット２０４による実行のためにメモリ２０６にロードすることができる。各種実施形態の処理は、メモリ２０６などのメモリに配置することが可能なコンピュータ実施命令を使用してプロセッサ・ユニット２０４により行うことができる。それらの命令は、プロセッサ・ユニット２０４内のプロセッサにより読み取り、実行することができる、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれる。各種実施形態におけるプログラム・コードは、メモリ２０６や永続性記憶装置２０８などの種々の物理的または有形のコンピュータ可読媒体で具現化することができる。

【0024】

プログラム・コード２１６は、選択的に取り外し可能であるコンピュータ可読媒体２１８に動作可能な形態で置かれ、プロセッサ・ユニット２０４で実行するためにデータ処理システム２００にロードまたは転送することができる。プログラム・コード２１６およびコンピュータ可読媒体２１８は、本例ではコンピュータ・プログラム製品２２０を形成する。一例では、コンピュータ可読媒体２１８は、例えばドライブに挿入または配置される光ディスクまたは磁気ディスクなどの有形形態、または永続性記憶装置２０８の一部であるハード・ドライブなどの記憶装置に転送するための永続性記憶装置２０８の一部である他の機器であってよい。有形形態の場合、コンピュータ可読媒体２１８は、データ処理システム２００に接続される、ハード・ドライブ、サム（thumb）・ドライブ、またはフラッシュ・メモリなどの永続性記憶装置の形をとることもできる。有形形態のコンピュータ可読媒体２１８は、コンピュータ記録可能記憶媒体とも呼ばれる。事例によっては、コンピュータ記録可能媒体２１８は取り外し可能でない場合もある。

【0025】

あるいは、プログラム・コード２１６は、コンピュータ可読媒体２１８から、通信ユニット２１０への通信リンクまたは入出力ユニット２１２への接続あるいはその両方を通じて、データ処理システム２００に転送してもよい。通信リンクまたは通信接続あるいはその両方は、説明のための例では物理的またはワイヤレスのリンクまたは接続である。コンピュータ可読媒体は、プログラム・コードを含む通信リンクやワイヤレス伝送など、非有形の媒体の形をとってもよい。データ処理システム２００に関して図示する種々の構成要素は、種々の実施を実施することが可能な方式のアーキテクチャ上の限定を意味するものではない。種々の例示実施形態は、データ処理システム２００に関して図示した構成要素に追加される構成要素、またはそれらに代わる構成要素を含むデータ処理システムで実施することができる。図２に示す他の構成要素は、図の例から変更することができる。一例として、データ処理システム２００の記憶装置は、データを記憶することが可能な任意のハードウェア装置である。メモリ２０６、永続性記憶装置２０８、およびコンピュータ可読媒体２１８は、有形形態の記憶装置の例である。

【0026】

別の例では、バス・システムを使用して通信ファブリック２０２を実装することができ、バス・システムはシステム・バスや入出力バスなどの１つまたは複数のバスからなることができる。言うまでもなく、バス・システムは、バス・システムに結合された種々の構成要素または機器間のデータ転送を提供する任意の適切な種類のアーキテクチャを使用して実装することができる。また、通信ユニットは、モデムやネットワーク・アダプタなど、データの送受信に使用される１つまたは複数の機器を含むことができる。さらに、メモリは、例えば、メモリ２０６、または通信ファブリック２０２に存在する可能性のあるインタフェースやメモリ・コントローラ・ハブに見られるキャッシュ等である。

【0027】

本発明の動作を実行するためのコンピュータ・プログラム・コードは、１つまたは複数のプログラミング言語の任意の組み合わせで書くことができ、それらの言語には、Ｊａｖａ（Ｒ）（商標）、Ｓｍａｌｌｔａｌｋ（商標）、Ｃ＋＋等のオブジェクト指向のプログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの従来の手続き型プログラミング言語が含まれる。プログラム・コードはそのすべてをユーザのコンピュータで実行しても、一部を独立したソフトウェア・パッケージとしてユーザのコンピュータで実行しても、一部をユーザのコンピュータで実行し、一部をリモート・コンピュータで実行しても、またはすべてをリモート・コンピュータもしくはサーバで実行してもよい。後者の事例では、リモート・コンピュータを、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意種のネットワークを通じてユーザのコンピュータに接続しても、または（例えば、インターネット・サービス・プロバイダを使用してインターネットにより）外部のコンピュータへの接続を行ってもよい。

【0028】

当業者は、図１および図２のハードウェアは実装によって異なりうることを理解されよう。図１および図２に示すハードウェアに加えて、またはそれに代えて、フラッシュ・メモリ、それに相当する不揮発性メモリ、または光ディスク・ドライブなどの他の内部ハードウェアまたは周辺機器を使用してよい。また、例示的実施形態の処理は、本開示の主題の主旨および範囲から逸脱することなく、上記のＳＭＰシステム以外のマルチプロセッサ・データ処理システムにも適用することができる。

【0029】

理解されるように、本明細書に記載される技術は、クライアント・マシンが、１つまたは複数のマシンのセットで実行されるインターネット・アクセス可能なウェブ・ベースのポータルと通信する、図１に示すような標準的なクライアント−サーバの枠組みで動作することができる。エンド・ユーザは、ポータルにアクセスし対話することが可能なインターネット接続可能機器（例えば、デスクトップ・コンピュータ、ノートブック・コンピュータ、インターネット機能を備えるモバイル機器等）を操作する。通例、各クライアント・マシンまたはサーバ・マシンは、ハードウェアおよびソフトウェアからなる図２に示すようなデータ処理システムであり、それらのエンティティは、インターネット、イントラネット、エクストラネット、私設ネットワーク、または任意の他の通信媒体もしくは通信リンクなどのネットワークを通じて相互と通信する。データ処理システムは通例、１つまたは複数のプロセッサ、オペレーティング・システム、１つまたは複数のアプリケーション、および１つまたは複数のユーティリティを含む。データ処理システム上のアプリケーションは、これらに限定しないが、特にＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬへのサポートを含むウェブ・サービスの固有のサポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの標準の開発および維持を担うワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手することができる。ＨＴＴＰおよびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）から入手することができる。これらの標準に精通していることを前提とする。

【0030】

よく知られるように、また追加的な背景情報として、認証は、ユーザまたはユーザの代理から提供される資格証明のセットを検証するプロセスである。認証は、ユーザが知っている事柄、ユーザの所持物、またはユーザ自身の一部、すなわちユーザについての何らかの身体的特徴が正しいものであることを確認することによって実現される。ユーザが知っている事柄は、ユーザのパスワードなどの共有される秘密を含むことができ、またはユーザの暗号鍵など特定のユーザだけに知られている事柄が正しいどうかを確認することを含む。ユーザの所持物は、スマート・カードやハードウェア・トークンを含むことができる。ユーザに関する何らかの身体的特徴には、指紋や網膜マップなどの生体認証入力がある。ユーザは通例は実際の人間であるが、必ずしもそうとは限らないことに留意されたい。すなわち、ユーザは、マシン、コンピューティング機器、または計算リソースを使用する他の種のデータ処理システムである場合もある。また、ユーザは通例は単一の一意の識別子を有するが必ずしもそうとは限らないことにも留意されたい。すなわち、事例によっては、複数の一意の識別子が１人のユーザに関連付けられることもある。

【0031】

認証資格証明は、各種の認証プロトコルで使用されるチャレンジ／レスポンス情報のセットである。例えば、ユーザ名とパスワードの組み合わせは、最も一般的な認証資格証明の形態である。他の形態の認証資格証明には、各種形態のチャレンジ／レスポンス情報、公開鍵インフラストラクチャ（ＰＫＩ）証明書、スマート・カード、生体認証等がありうる。通例、資格証明は、認証サーバまたは認証サービスとの認証プロトコル・シーケンスの一部としてユーザにより提示される。

【0032】

以下で説明するように、図３を参照すると、本開示の主題である技術は、典型的には、ウェブ・ベースまたはクラウド・ベースのアプリケーションがクライアント側コンポーネントおよびサーバ側コンポーネントを備えるシナリオで実施される。クライアント側コンポーネントは、ウェブ・ブラウザまたはそれに関連付けられたコード（例えば、ブラウザ・プラグイン、アプレット等）３００および非ブラウザ・ベースのクライアント３０２を含み、それぞれ、図２を参照して上記で説明したようなクライアント・マシン３０４で実行される。例えば、クライアント・マシン３０４は、プロセッサ３０６、コンピュータ・メモリ３０８、およびオペレーティング・システム３１０を備える。本明細書では、ブラウザ・ベースのクライアントを、「シン」クライアントと呼び、非ブラウザ・ベースのクライアントを「シック」または「リッチ」クライアントと呼ぶ場合がある。そのような各クライアント・コンポーネントは、図１に示すようなネットワーク３１４を通じて、サーバ・アプリケーション３１２を含むサーバ側コンポーネントと相互動作するように適合される。サーバ・アプリケーション３１２はウェブ・ベースであってもクラウド・ベースであってもよく、これも図２に示すような１つまたは複数のマシンで実行される。

【0033】

ブラウザ・ベースのクライアント３００は、それに関連付けられたサーバ・アプリケーション３１２との間に確立された認証機構を有する。同様に、非ブラウザ・ベースまたは「リッチ」クライアント３０２は、サーバ・アプリケーション３１２との間に確立された認証機構を有する。これらの認証機構は同じであっても異なってもよい。上記のように、「リッチ」クライアントはブラウザ・ベースではない。リッチ・クライアント・アプリケーションの例は、電子メール、カレンダー機能、連絡先管理、およびインスタント・メッセージ機能を提供するＬｏｔｕｓ Ｎｏｔｅｓ（Ｒ）であるが、リッチ・クライアントは、任意のクライアント−サーバ・アプリケーションで実施することができる。この例では、サーバ・アプリケーション３１２はＤｏｍｉｎｏ（Ｒ）データ・サーバである。無論、これらの例は本開示の主題を限定するものではなく、本開示は、任意のウェブ・ベースまたはクラウド・ベースのアプリケーションで実施することができる。

【0034】

本開示によると、制御チャネル３１６は、一方の側のブラウザ・ベースのクライアント３００と、他方の側の非ブラウザ・ベースのクライアント３０２との間に確立される。制御チャネルは、下記で説明するようにそれらの構成要素間で情報を渡すために使用される。一実施形態では、制御チャネル３１６はローカルホスト接続３１８を使用して実装され、この接続を通じて、ブラウザ・ベースのクライアント３００が、リッチ・クライアントに関連付けられたＨＴＴＰサーバ・インスタンス３２０と通信する。この実施形態のクライアント３００とクライアント３０２間の通信は典型的にはＨＴＴＰＳを通じて行われるが、これは必須事項ではない。代替実施形態では、下記で説明するように、制御チャネルは、例えば、特定のｍｉｍｅタイプのためのハンドラとしてリッチ・クライアントを登録することにより、オペレーティング・システム３１０自体を使用して実装される。制御チャネルは、例えば共有メモリ・セグメントとして、プロセス間通信（ＩＰＣ）として、ネットワーク呼び出し(network call)によって、ファイルによって等の他の方式で実装することができる。制御チャネルが他のクライアント・プロセスから観察可能な場合には、公知の技術を使用してセキュリティ保護すべきである。

【0035】

次いで、本開示の典型的な動作事例を図４の処理の流れに関して説明する。ステップ４００で、エンド・ユーザがブラウザ３００のインスタンスを開いており、典型的にはブラウザにレンダリングされるＳＳＬでセキュリティ保護されたログオン・ページでユーザ識別子（ＵＩＤ）およびパスワードを入力することにより、サーバ・アプリケーション３１２に対して認証している。その結果、ブラウザは、サーバ・アプリケーションから提供される関連付けられた資格証明３０５を取得し、記憶する。ステップ４０２に示すこの動作でユーザ・セッションまたは「ウェブ・ベースのユーザ・セッション」が確立される。その結果、ユーザは、ウェブ・ベースまたはクラウド・ベースのアプリケーションで許可される１つまたは複数の動作を行うことができる。本開示によると、ブラウザからユーザ・セッションが開始された後（すなわち既存のウェブ・セッション中）に、リッチ・クライアント３０２が発見され、好ましくは自動的に、かつエンド・ユーザが追加的な認証関連情報を入力することを必要とせずに、サーバ・アプリケーション３１２に対して認証される。すなわち、リッチ・クライアントの認証は、透過に、実質的に「表面下で（under the covers）」、しかしサーバ・アプリケーションに期待される形で行われる。しかし、エンド・ユーザは、リッチ・クライアントからの認証動作に伴う通常の作業を行う必要はない。エンド・ユーザは、（ブラウザ・ベースの手法を使用して）一度認証を行い、その認証でリッチ・クライアント・ベースの認証が可能に、または容易になる。

【0036】

好ましくは、リッチ・クライアントの自動的なログオン（自動ログオン）動作は、以下のように実現される。ユーザ（または他者）が、好ましくは下記のアプリケーション・インタフェースを使用して、特定の発見および認証動作を設定しているものとする。ステップ４０４で、ユーザがリッチ・クライアントを使用してサーバ・アプリケーションに認証することを望むかどうかを判定する検査が行われる。ユーザがサーバ・アプリケーションへの認証を望む場合は、発見ステップ４０６が行われる。発見ステップ４０６で、クライアント・マシンでリッチ・クライアントが実行されているかどうか（およびリッチ・クライアントが多数あるかどうか）を特定する。発見ステップは、例えば、ブラウザからローカルホスト接続を通じて１つまたは複数の要求を発行させ、それに対する「ステータス」応答を受信することによって能動的に行っても、または例えばそのようなステータス情報を要求時にブラウザが入手し、表示できるようにしておくことにより受動的に行ってもよい。代替法では、リッチ・クライアントが開始された時に、そのクライアントの実行状態を例えば音声や視覚等の何らかの方式でユーザに単に公開する。発見プロセスの性質は実装に依存する。使用することが考えられる他の発見技術には、リッチ・クライアントにＨＴＴＰサーバのインスタンスのポートを開かせ、その開かれたポートを見つける（これはリッチ・クライアントが実行中であることを意味する）まで利用可能なポートの組をブラウザに繰り返し探索させることが含まれる。ＩＰＣを制御チャネルとして使用する場合は、オペレーティング・システムの公開機構を使用して、リッチ・クライアントが実行中である旨を知らせる通知を提供することができる。これらの例は限定的なものではない。

【0037】

発見の後、手順はステップ４０８に進み、リッチ・クライアントが、サーバ・アプリケーションに対する実際の認証を行うための資格証明を取得する。一実施形態では、資格証明は、単にアプリケーション・サーバに対するブラウザ・ベースの認証時に取得される資格証明３０５である。この実施形態では、ブラウザは単に制御チャネルを介してリッチ・クライアントに資格証明を渡す。代替実施形態では、リッチ・クライアントが、あるｍｉｍｅコンテンツ・タイプ（例えばｘ−ａｐｐｌｉｃａｔｉｏｎ／ｒｉｃｈ−ａｕｔｈ）についてハンドラとしてローカルのオペレーティング・システムに予め登録している。ステップ４０８で、ブラウザがサーバ・アプリケーションにＨＴＴＰ要求を発行して新しい資格証明を要求する。サーバ・アプリケーションからのＨＴＴＰ応答は新しい資格証明および関連付けられたｍｉｍｅタイプを識別するヘッダを含む。リッチ・クライアントはそのｍｉｍｅタイプについてハンドラとして登録されているので、ＨＴＴＰ応答（新しい資格証明）は、オペレーティング・システム・カーネルを通じてリッチ・クライアントに伝搬され、次いでリッチ・クライアントは、ここでも明示的なユーザ入力を必要とせずに、その資格証明を使用して認証する。この代替実施形態では、制御チャネルは、標準的なＯＳ機構を使用し、したがってプラットフォームに依存しない。ステップ４１０で、リッチ・クライアントは、サーバ・アプリケーションに対する認証を完了し、処理が終了する。

【0038】

図４に示す１つまたは複数のステップは別の順序で行ってもよい。１つまたは複数のステップを組み合わせても、または置き換えを実施してもよい。

【0039】

リッチ・クライアントがサーバ・アプリケーション３１２に対して認証する特定の方式は本開示の態様ではない。そのための公知の技術には、これらに限定しないが、ＳＡＭＬを利用した認証（サーバがＳＡＭＬアサーションを発行し、次いでそれがリッチ・クライアントに転送され、リッチ・クライアントはそのアサーションで認証を行うか、またはそれを別の資格証明と交換する）、ＯＡｕｔｈを利用した認証（サーバがＯＡｕｔｈトークンを発行し、それをリッチ・クライアントが認証に使用する）、使い捨てのトークンを利用する認証（サーバがランダムのノンス（nonce）を生成してサーバ側で保持し、ユーザに関連付ける）等がある。

【0040】

ブラウザ・ベースのクライアント３００が制御チャネルを通じて直接リッチ・クライアントと通信する第１の実施形態では、サーバ・アプリケーションとローカルのＨＴＴＰサーバ（リッチ・クライアントとの関連で実行される）が異なるドメインで動作する場合がある。ローカルのＨＴＴＰサーバは、リッチ・クライアントの付属要素である場合も、またはリッチ・クライアントと一体である場合もある。したがって、公知のドメイン間通信方法（例えばスクリプトの包含）を使用してこの対話を容易にするべきである。別の変形例では、ローカルのＨＴＴＰサーバを使用するのではなく、ブラウザ・プラグインまたは署名付きアプレットを使用してアプリケーション・サーバと対話して、資格証明を取得し、リッチ・クライアントの認証を実装することができる。

【0041】

図５に、ユーザ（または他の人物もしくはエンティティ）が動作を設定することができる典型的なアプリケーション・インタフェース３２２（図３）を示す。このインタフェースは、１つまたは複数のウェブ・ページとしてブラウザにエクスポートすることができるが、これは限定ではない。典型的なページ５００は、入力欄、ＨＴＭＬ記入フォーム、ラジオ・ボタン等の設定要素のセットを公開する。したがって、例えばラジオ・ボタン５０２を選択することにより、ユーザは、ウェブ・セッションの開始時にすべての実行中のリッチ・クライアントを発見することを要求することができる。ラジオ・ボタン５０４を選択することにより、ユーザは、要求時にすべての実行中のリッチ・クライアントのステータスを更新することを選択することができる。ユーザはラジオ・ボタンを選択して、リッチ・クライアントが実行中であることが検出された際に自動的に認証されるように指定することができる。リスト５０６の利用可能な選択肢を使用して、ユーザは、リッチ・クライアントがサーバ・アプリケーションとどのように対話するかに関する制約または制限を指定することができる。したがって、例えば、リストは、例えば、アクセスを「読み出し専用」とする、アクセスを指定可能な制限された時間のみ可能にする、特定の機能またはアプリケーション・プログラミング・インタフェース（ＡＰＩ）のみを利用可能にする等の１つまたは複数の選択肢を公開することができる。これらは典型的な設定の選択肢に過ぎず、当業者は、必要に応じて他の設定の選択肢を実装してよいことを理解されよう。設定インタフェースは、選択されると、リッチ・クライアントが実行中でない場合にユーザが直接ブラウザからリッチ・クライアントを開始できるようにするコントロールを提供することもできる。このインタフェースを使用して、ユーザは、リッチ・クライアントをサーバ・アプリケーションに対してどのように認証するかを定義する「ポリシー」を設定する。デフォルト・ポリシーのセットをユーザに公開してこの選択を容易にすることができる。インタフェースの一実施形態を説明したが、例えば、コマンド・ライン・インタフェースを使用する、ポリシーをプログラム的に定義する等の１つまたは複数の代替手法を使用することができる。

【0042】

図６に、インタフェースの発見ページ６００を示す。このページは、上記のように発見ステップの後に表示される。この例では、発見動作によりクライアント・マシンで実行中の２つのリッチ・クライアント（クライアント１、およびクライアント２）が特定されており、それらのクライアントをここではアイコン６０２および６０４で表す。アイコン６０２は、アイコン６０２に関連付けられたクライアント１に資格証明がすでに発行されていることを示す表示または視覚的な手掛かりを含む。このアイコンを選択することにより、クライアント１の認証を無効にする機会を（例えば別個のダイアログを介して）エンド・ユーザに与えることができる。代替法では、アイコン６０２の選択自体によりリッチ・クライアントの認証が終了する。いずれの場合も、リッチ・クライアントからサーバ・アプリケーションへのアクセスは（資格証明を無効にすることにより）有効に取り消される。アイコン６０４を選択することにより、エンド・ユーザは、上記のように資格証明を取得するプロセスを開始することができ、その結果クライアント２はサーバ・アプリケーションにアクセスし、使用できるようになる。

【0043】

このように、この技術によると、ユーザは、リッチ・クライアントをサーバ・アプリケーションに対して自動的に、かつユーザが定義したポリシーに基づいて認証できるようにすることができる。このポリシーで、特定の期間だけに資格証明を発行できること、またはアプリケーションの一部にアクセスするためのみに資格証明を使用できること等を指定することができる。アクセスは、この場合もユーザにより設定されたポリシーに従って取り消すことが可能である。

【0044】

本開示の主題は多くの利点を有する。主要な利点の１つは、ユーザがウェブ・ベースまたはクラウド・ベースのアプリケーションとのセッション時に一度のみ（かつ一箇所で）認証すれば済むことである。記載した技術を使用すると、その認証が実際に使用されて、関連付けられたリッチ・クライアントがそのアプリケーションにアクセスできるようになる。別の利点は、リッチ・クライアントによるそのようなアクセスを、ユーザによって設定されたポリシーに従って個別設定することができ、ユーザがリッチ・クライアントによるそのようなアクセスを必要に応じて取り消せることである。ユーザは、発見機能を使用して、ローカルに実行されているリッチ・クライアントを見ることができ、サーバ・アプリケーション（または他のエンティティ）に資格証明（またはトークン等）の発行を要求することによりそのリッチ・クライアントを認証し、次いでその資格証明をリッチ・クライアントで使用してユーザをアプリケーションに対して認証する。この技術は、既存のブラウザ・ベースの資格証明をリッチ・クライアントに伝搬する、またはリッチ・クライアントが新しい資格証明を取得することを可能にするいくつかのローカルの機構を提供する。

【0045】

この技術は、リッチ・クライアントがサーバ・アプリケーションに対してどのように認証するかに関わらず、任意のリッチ・クライアントに使用することができる。

【0046】

記載される一実施形態では、この技術により、（ブラウザ・ベースの）クライアント・アプリケーションの資格証明を、そのブラウザ・アプリケーションに関連付けられた対応する非ブラウザ・プロセスに自動的に直接伝搬することが可能になる。この解決法では、ユーザは、既存のウェブ・ベースのユーザ・セッション内でリッチ・クライアントを開始したい場合にそのリッチ・クライアントにログインせずに済む。

【0047】

本明細書で使用する場合、「資格証明」は、サーバ・アプリケーションへのアクセスを容易にする、任意の資格証明、トークン、データ・セット、またはデータの意に広く解釈すべきである。上記のように、クライアント（ブラウザ・ベースまたはリッチ・クライアント）は、それに関連付けられたサーバ・アプリケーションとの間に確立された認証機構を有し、開示される本技術は、関連するセマンティクスおよび通信プロトコルを尊重する。

【0048】

本開示の自動ログインの解決法は、ブラウザ・ベースのクライアントとそれに関連付けられたリッチ・クライアント間の独自の対話を提供し、両者は好ましくはウェブ・ベースまたはクラウド・ベースのサーバ・アプリケーションに関連付けられる。この解決法では、ブラウザ・ベースのクライアントとサーバ・アプリケーションとの間の既存のユーザ・セッションが確立済みである、すなわち、エンド・ユーザがサーバ・アプリケーションにログインした時に資格証明が前もって生成されていることを前提とする。

【0049】

限定を意図するものではないが、代表的な実施形態では、サーバ・アプリケーションはアプリケーション・サーバ（ＩＢＭ（Ｒ）ＷｅｂＳｐｈｅｒｅ（Ｒ）サーバ等）を実行し、アプリケーション・サーバは、典型的にはＪ２ＥＥ準拠のサーブレットの形態である１つまたは複数のサーバ・ベースのコード機能のサポートを含む。

【0050】

上記の機能は、例えばプロセッサで実行されるソフトウェア・ベースの機能として独立型方式として実装しても、または管理されたサービス（ＳＯＡＰ／ＸＭＬインタフェースを介したウェブ・サービスを含む）として利用できるようにすることもできる。本明細書に記載される特定のハードウェアおよびソフトウェアの実装の詳細は単に説明を目的とするものであり、記載される主題の範囲を限定するものではない。

【0051】

より一般的には、本開示の主題の文脈におけるコンピューティング機器はそれぞれハードウェアおよびソフトウェアからなるデータ処理システム（図２に示すものなど）であり、それらのエンティティは、インターネット、イントラネット、エクストラネット、私設ネットワークなどのネットワーク、または他の通信媒体もしくはリンクを通じて相互と通信する。データ処理システムのアプリケーションは、これらに限定されないが、とりわけＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのサポートを含む、ウェブならびに他の公知のサービスおよびプロトコルに対する固有のサポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの標準の開発および維持を担うワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手することができる。ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）から入手することができる。これらの公知の標準およびプロトコルに精通していることを前提とする。

【0052】

本明細書に記載されるリッチ・クライアントの自動ログイン方式は、単純なｎ層アーキテクチャ、ウェブ・ポータル、フェデレーテッド（federated）・システム等を含む各種のサーバ側アーキテクチャで、またはそれらとの関連で実装することができる。アプリケーション・サーバ・コンポーネントは、１つまたは複数のバックエンド・アプリケーションのドメインと異なるドメインに置かれる場合があり、したがって本開示の技術は、疎結合されたサーバ（「クラウド」ベースを含む）環境で実施することができる。アプリケーション・サーバ自体をクラウド内にホストすることもできる。

【0053】

さらにより一般的には、本明細書に記載の主題は、完全にハードウェアによる実施形態、完全にソフトウェアによる実施形態、またはハードウェア要素とソフトウェア要素の両方を含む実施形態の形をとることができる。好ましい実施形態では、機能はソフトウェアとして実装され、ソフトウェアは、これらに限定されないがファームウェア、常駐ソフトウェア、マイクロコード等を含む。さらに、上記のように、自動ログイン機能は、コンピュータまたは任意の命令実行システムにより使用される、またはそれとの関連で使用されるプログラム・コードを提供するコンピュータ使用可能またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形をとることができる。ここでの説明では、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、または機器により使用される、またはそれとの関連で使用されるプログラムを保持または記憶することが可能な任意の装置とすることができる。媒体としては、電子、磁気、光学、電磁気、赤外線、または半導体システム（または装置または機器）とすることができる。コンピュータ可読媒体の例は、半導体または固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、剛性磁気ディスク、および光ディスクを含む。光ディスクの現在の例には、コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、読み出し／書き込み可能コンパクト・ディスク（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。コンピュータ可読媒体は有形の物品である。

【0054】

コンピュータ・プログラム製品は、本明細書に記載される機能の１つまたは複数を実施するプログラム命令（またはプログラム・コード）を有する製品とすることができる。それらの命令またはコードは、リモート・データ処理システムからネットワークを通じてダウンロードされた後にデータ処理システム内のコンピュータ可読記憶媒体に記憶することができる。あるいは、それらの命令またはコードは、サーバ・データ処理システム内のコンピュータ可読記憶媒体に記憶し、リモート・データ処理システム内部のコンピュータ可読記憶媒体で使用するためにネットワークを通じてリモート・システムにダウンロードされるように適合してもよい。

【0055】

代表的な実施形態では、記載されるクライアント・コンポーネントおよびサーバ・コンポーネントは、好ましくは１つまたは複数のプロセッサにより実行されるソフトウェアとして専用コンピュータ内に実装される。ソフトウェアは、１つまたは複数のプロセッサに関連付けられた１つまたは複数のデータ記憶装置またはメモリに保持され、ソフトウェアは、１つまたは複数のコンピュータ・プログラムとして実装することができる。それら特殊目的のハードウェアおよびソフトウェアは共に本開示のリッチ・クライアントの自動ログイン機能を提供する構成要素をなす。

【0056】

記載した機能は、既存のアプリケーション・サーバの機能または動作の付加または拡張として実施することができる。

【0057】

上記では、本発明の特定の実施形態により行われる特定順序の動作を説明したが、そのような順序は例示的なものであり、代替実施形態では、それらの動作を異なる順序で行う、特定の動作を組み合わせる、特定の動作を重複させる等が可能であることを理解されたい。本明細書における所与の実施形態の参照は、記載されるその実施形態が特定の特徴、構造、または特性を含むことが可能であるが、すべての実施形態がその特定の特徴、構造、または特性を含むとは限らないことを意味する。

【0058】

最後に、システムの所与の構成要素について別々に説明したが、当業者には、機能の一部は、所与の命令、プログラム・シーケンス、コード部分等の中で組み合わせる、または共有することが可能であることが認識されよう。

【0059】

本明細書で使用する「ブラウザ」は、任意の特定のブラウザ（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（Ｒ）、Ｓａｆａｒｉ（Ｒ）、ＦｉｒｅＦｏｘ（Ｒ）等）を指すものではなく、インターネットによりアクセス可能なリソースにアクセスし、表示することが可能な任意のクライアント側のレンダリング・エンジンを指すものと広く解釈されたい。さらに、典型的にはクライアントとサーバ間の対話はＨＴＴＰを使用して行われるが、上記のようにこれも限定ではない。クライアントとサーバ間の対話は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）に準拠するようにフォーマットされ、（公衆インターネットを介した）ＨＴＴＰやＦＴＰで伝搬されるか、または任意の他の信頼できる移送機構（企業イントラネットを通じた移送用のＩＢＭ（Ｒ）ＭＱＳｅｒｉｅｓ（Ｒ）技術やＣＯＲＢＡなど）を使用することができる。また、用語「ウェブ・サイト」または「サービス・プロバイダ」は、ウェブ・サイト（リンクが張られたウェブ・ページのセット）、所与のウェブ・サイトまたはサーバのドメイン、サーバまたはサーバのセットに関連付けられた信頼できるドメイン等を包含するものと広く解釈すべきである。「サービス・プロバイダ・ドメイン」は、ウェブ・サイトまたはウェブ・サイトの一部を含むことができる。本明細書に記載のアプリケーションまたは機能はいずれも、別のアプリケーションへのフック（hook）を提供すること、本機構をプラグインとして使用することを容易にすること、機構へのリンク等により、ネイティブ・コードとして実施することができる。

【0060】

上記のように、上記のリッチ・クライアントの自動ログイン機能は、非ブラウザ・ベースのクライアント・アプリケーションの資格証明を関連するブラウザ・プロセスに渡す必要がある、任意のシステム、機器、ポータル、サイト等で使用することができる。より一般的には、記載した技術は、所与の情報（これに限定しないが資格証明データを含む）がクライアント・アプリケーションから関連するブラウザ・プロセスまで自動的に維持されることが望まれる任意の動作環境で使用するために設計されている。

【0061】

上記の実施形態は、既存のブラウザ・セッション内からリッチ・クライアントを認証することを可能にするが、基本技術は、リッチ・クライアントがウェブ・アプリケーションに対して認証され、既存の資格証明をシン・クライアントに渡す必要がある事例でも実施することができる。この事例では、リッチ・クライアントが、シン・クライアントによる（アプリケーションへの）アクセスが許可できることを保証する手段を有する場合には、リッチ・クライアントと利用可能なブラウザ・ベースのクライアントとの間の制御チャネルが可能になる。そして、リッチ・クライアントが入手した資格証明がブラウザ・ベースのクライアントに渡されて、ユーザの認証を可能にする。

【0062】

サーバ・アプリケーションは、サービス、サーバ、アプリケーション・プログラム、プロセス、ページ（例えばｗｉｋｉやウェブ・ページ等）、ファイル、リンクが張られたオブジェクト、ディレクトリ等へのアクセスを可能にする。

【0063】

以上本発明について説明した。本発明の特許請求の範囲は添付の通りである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】