特許 7007498 例外処理を通じた認証

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

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

(11)【特許番号】

(24)【登録日】2022-01-11

(45)【発行日】2022-01-24

(54)【発明の名称】例外処理を通じた認証

(51)【国際特許分類】

   G06F 21/31 20130101AFI20220117BHJP

【ＦＩ】

G06F21/31

【請求項の数】 20

(21)【出願番号】P 2020558542

(86)(22)【出願日】2019-04-10

(65)【公表番号】

(43)【公表日】2021-08-05

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

(87)【国際公開番号】W WO2019209531

(87)【国際公開日】2019-10-31

【審査請求日】2020-10-20

(31)【優先権主張番号】15/960,321

(32)【優先日】2018-04-23

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】506332063

【氏名又は名称】セールスフォース ドット コム インコーポレイティッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ウォン，マシュー

(72)【発明者】

【氏名】ヴァンパット，アラン

(72)【発明者】

【氏名】タブス，シーン

(72)【発明者】

【氏名】ルイ，サラ

(72)【発明者】

【氏名】モーティマー，ジェイアール．，ウィリアム シー．

(72)【発明者】

【氏名】コレン，イツィク

【審査官】青木 重徳

(56)【参考文献】

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

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

【文献】米国特許出願公開第２０１２／０１４４３７４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０１７０９６３（ＵＳ，Ａ１）

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

Ｇ０６Ｆ ２１／３１

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

【請求項1】

プログラム命令を格納した非一時的コンピュータ可読媒体であって、前記プログラム命令は、コンピュータシステムに動作を実施させることができ、前記動作は、
ソフトウェア開発プラットフォームの例外ハンドラを維持するステップであって、前記例外ハンドラは、前記ソフトウェア開発プラットフォーム上で実行するアプリケーションのユーザの認証を生じる特定種類の例外を処理するために実行される、ステップと、
前記例外ハンドラにおいて、特定アプリケーションによりスローされた前記特定種類の例外の指示を受信するステップと、
前記特定種類の例外の前記指示を受信することに応答して、
前記例外ハンドラにより、前記特定アプリケーションと相互作用するウェブブラウザへ、要求を発行するステップであって、前記要求は、前記ウェブブラウザが、前記特定アプリケーションのユーザの認証を実行するよう構成される認証サーバへリダイレクトする、ステップと、
前記認証サーバから、前記実行された認証の結果を受信するステップと、
前記特定アプリケーションへ前記結果を返すステップと、
を含む、コンピュータ可読媒体。

【請求項2】

前記動作は、
前記認証に応答して、前記特定種類の例外の前記指示をスローさせる要求を再生するよう前記ウェブブラウザに指示することにより、前記ウェブブラウザを前記特定アプリケーションに戻すステップを含む、請求項１に記載に記載のコンピュータ可読媒体。

【請求項3】

前記発行するステップは、
前記特定種類の例外の前記指示をスローさせる前記要求を再生するために使用できる情報を含むＵＲＬ（uniform resource locator）を、前記ウェブブラウザに提供するステップを含む、請求項２に記載に記載のコンピュータ可読媒体。

【請求項4】

前記発行するステップは、
データベースに、前記特定種類の例外の前記指示をスローさせる前記要求に関する情報を格納するステップであって、前記格納された情報は、前記特定種類の例外の前記指示をスローさせる前記要求を再生するために使用される、請求項２に記載のコンピュータ可読媒体。

【請求項5】

前記動作は、
前記特定種類の例外の前記指示と共に受信されたスタックトレースを分析することにより、前記特定アプリケーション内の前記ウェブブラウザの戻るべき場所を決定するステップであって、前記スタックトレースは、前記特定種類の例外をスローしたアプリケーション機能の名称を識別する、ステップを含む、請求項２に記載のコンピュータ可読媒体。

【請求項6】

前記動作は、
前記特定種類の例外の前記指示と共に受信されたスタックトレースを分析するステップであって、前記スタックトレースは、前記特定種類の例外をスローしたアプリケーション機能の名称を識別する、ステップと、
前記分析に基づき、前記ウェブブラウザが認証サーバへリダイレクトする前記要求を発行するか否かを決定するステップと、
を含む、請求項１に記載のコンピュータ可読媒体。

【請求項7】

前記発行された要求は、ＨＴＴＰ（hypertext transfer protocol）リダイレクト状態コードを含む、請求項６に記載のコンピュータ可読媒体。

【請求項8】

前記認証は、二要素認証である、請求項１に記載のコンピュータ可読媒体。

【請求項9】

前記プログラム命令は、前記特定アプリケーションの開発者により提供されるプログラム命令を含み、前記開発者の提供したプログラム命令は、前記特定種類の例外をスローする、請求項１に記載のコンピュータ可読媒体。

【請求項10】

プログラム命令を格納した非一時的コンピュータ可読媒体であって、前記プログラム命令は、コンピューティングシステムに、動作を実行するアプリケーションを実装させることができ、前記動作は、
クライアント装置のウェブブラウザに、前記アプリケーションのユーザインタフェースを提示するステップと、
前記ウェブブラウザがユーザ認証を保証する前記アプリケーションの機能を要求したと決定するステップと、
ソフトウェア開発プラットフォームの例外ハンドラにより処理される特定種類の例外をスローするステップであって、前記特定種類の例外は、前記例外ハンドラに、前記ユーザ認証を実行するよう構成される認証サーバへ前記ウェブブラウザをリダイレクトさせる、ステップと、
前記実行された認証の結果に基づき、前記要求された機能の実行を許可するステップと、
を含む、コンピュータ可読媒体。

【請求項11】

前記動作は、
前記例外ハンドラに、前記ウェブブラウザのリダイレクトが保証されるか否かを決定するために、前記例外ハンドラにより使用できるコールスタックを識別するスタックトレースを提供するステップを含む、請求項１０に記載のコンピュータ可読媒体。

【請求項12】

前記動作は、
前記例外ハンドラに、前記ウェブブラウザに前記機能の要求を再提出させるために前記例外ハンドラにより使用できる前記要求された機能の名称を識別するスタックトレースを提供するステップを含む、請求項１０に記載のコンピュータ可読媒体。

【請求項13】

前記ユーザ認証は、２つ以上の要素に基づく、請求項１０に記載のコンピュータ可読媒体。

【請求項14】

前記プログラム命令は、前記例外ハンドラのプログラム命令を含む、請求項１０に記載のコンピュータ可読媒体。

【請求項15】

方法であって、
コンピューティングシステムにより、ウェブブラウザから、アプリケーションのユーザを認証するための要求を受信するステップであって、前記要求は、前記アプリケーションが、例外ハンドラに前記ウェブブラウザを前記コンピューティングシステムにリダイレクトさせる特定種類の例外をスローすることに応答して発行される、ステップと、
前記要求に応答して、前記コンピューティングシステムにより、前記ウェブブラウザへ認証ページを提供するステップと、
前記コンピューティングシステムにより、前記認証ページを介して受信された入力に基づき、前記ユーザの認証を実行するステップと、
前記コンピューティングシステムにより、前記ウェブブラウザを前記アプリケーションへリダイレクトするステップと、
を含む方法。

【請求項16】

前記リダイレクトするステップは、前記ウェブブラウザに、前記特定種類の例外をスローさせた前記アプリケーションへ要求を再生するために前記ウェブブラウザにより使用可能な情報を提供するステップを含む、請求項１５に記載の方法。

【請求項17】

前記コンピューティングシステムにより、認証するための前記受信した要求の中のＵＲＬ（uniform resource locator）に含まれた値に基づき、前記ウェブブラウザに提供すべき前記情報を決定するステップ、
を更に含む請求項１６に記載の方法。

【請求項18】

前記再生された要求は，前記提供された情報に対応する１つ以上のパラメータを含むＨＴＴＰ（hypertext transfer protocol） ＰＯＳＴ要求である、請求項１７に記載の方法。

【請求項19】

前記値は、前記１つ以上のパラメータをデータベースから取得するために使用可能である、請求項１８に記載の方法。

【請求項20】

前記認証は、２つ以上の要素に基づく、請求項１６に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、概して、コンピュータセキュリティに関し、より具体的にはユーザ認証に関する。

【背景技術】

【0002】

コンピュータネットワークは、リソースへのアクセスを望む可能性のある何人かのユーザ間で共有される複数のリソースを含んでよい。所与のユーザがリソースを悪用しないことを保証するために、ユーザは、リソースへのアクセスを与えられる前に認証されてよい。幾つかの例では、所与のリソースは、例えば、認証情報を依頼し、それをローカルに格納された認証済みユーザの認証と比較することにより、認証をローカルで処理してよい。他の例では、コンピュータネットワークは、認証情報を維持し及びユーザを認証するために信頼できる中央当局に依存してよい。中央当局は、ユーザ認証情報の一層の保護を維持し対応するのが容易であり得るので、有利である。中央当局を使用する認証方式の例は、Ｋｅｒｂｅｒｏｓ、リモート認証ダイヤルインユーザサービス（remote authentication dial－in user service(RADIUS)）、等である。

【発明の概要】

【0003】

本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。

【0004】

本開示において、異なるエンティティ（これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい）は、１つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述－［１つ以上のタスクを実行する］よう構成される［エンティティ］－は、本願明細書で、構造（つまり、電子回路のような何らかの物理的なもの）を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に１つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「ユーザの認証を実行するよう構成される認証サーバ」は、例えば、プロセッサとプログラム命令を含むメモリとを有するコンピュータシステムであって、プログラム命令は、対象となる集積回路が現在使用中でない（例えば、電源が接続されていない）場合でも動作中に機能を実行するために実行可能である、をカバーすることを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「～よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース（application programming interface(API)）のようなソフトウェアエンティティを表すために使用されない。

【0005】

用語「～よう構成される（configured to）」は、「構成可能である（configurable to」を意味しない。未設定ＦＰＧＡは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定ＦＰＧＡは、該機能を実行するよう「構成可能」であってよく、設定（プログラミング）後に該機能を実行するよう「構成され」てよい。

【0006】

添付の特許請求の範囲における、構造が１つ以上のタスクを実行するよう「構成される」という記載は、その請求項の要素について３５U.S.C.§１１２(f)fを含まないことが明確に意図される。従って、提出される本願の請求項のいずれも、手段及び機能の要素を有するものとして解釈されることが意図される。出願人が審査中に§１１２（ｆ）を含むことを意図する場合には、［機能を実行するための］「手段」の構成を用いて請求項の要素を記載する。

【0007】

本願明細書で使用されるとき、用語「第１」、「第２」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序（例えば、空間的、時間的、論理的、等）も意味しない。例えば、複数のユーザアカウントを有するコンピューティングシステムでは、用語「第１」及び「第２」ユーザアカウントは、任意のユーザを表すために使用できる。言い換えると、「第１」及び「第２」ユーザアカウントは、例えば最初の２つの生成されたユーザアカウントに限定されない。

【0008】

本願明細書で使用されるとき、用語「に基づき」は、決定に影響する１つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。語法「Ｂに基づきＡを決定する」を検討する。この語法は、ＢがＡを決定するための要素であること、又はＡの決定に影響することを指定する。この語法は、Ａの決定がＣのような何からの他の要素にも基づいてよいことを排除しない。この語法は、ＡがＢにのみ基づき決定されル一実施形態をカバーすることも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。

【図面の簡単な説明】

【0009】

【図1】例外処理を通じてユーザ認証をサポートする開発プラットフォームの一実施形態のブロック図である。

【0010】

【図2】ユーザ認証を生じる例外をスローするために実行可能な開発者コードの一例を示す図である。

【0011】

【図3】スローされた例外を処理するために実行可能な例外ハンドラの一実施形態を示すブロック図である。

【0012】

【図4A】例外処理を通じて認証する方法の実施形態を示すフロー図である。

【図4B】例外処理を通じて認証する方法の実施形態を示すフロー図である。

【0013】

【図5】例示的なコンピュータシステムの一実施形態を示すブロック図である。

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

【0014】

幾つかの例では、開発者は、アプリケーションの要求された機能を可能にする前に、ユーザを認証したいと望み得る。認証が認証サーバにより処理されている場合、開発者は，ユーザを認証サーバへリダイレクトするアプリケーション内のコード、及び要求された機能へのアクセスを与えられるためにアプリケーションへユーザを戻すことを処理するコード、を記述する責任があってよい。しかしながら、このコードを記述することは、退屈であり、誤って実装されることがある。

【0015】

本開示は、プラットフォームが、ウェブブラウザを介してクライアント装置にアクセス可能なアプリケーションサーバ上で１つ以上のアプリケーションをホストし得る実施形態を記載する。以下に種々の実施形態で更に詳述するように、プラットフォームは、ユーザ認証を実行させるためにアプリケーションによりスローできる新しい種類の例外をサポートする。本願明細書で使用されるとき、用語「例外」は、従来の理解された意味に従い解釈されるべきであり、これは、（１）（エラーの発生のような）イベントの発生に応答して返される、及び（２）イベントの発生に関連するアクションを行うために例外ハンドラにより使用可能なイベントに関する情報を含む、データ構造を含む。種々の実施形態では、特定種類の例外がスローされると、プラットフォームにより提供される例外ハンドラは、スローされた例外の指示を受信し、ユーザのウェブブラウザを、ユーザを認証するよう構成される認証サーバへリダイレクトすることを実施する。幾つかの実施形態では、例外ハンドラは、認証が実行された後に、例えば、ブラウザに特定種類の例外を初めにスローされた前の要求を再生させることにより、ユーザのブラウザをアプリケーションに戻すことも行う。

【0016】

種々の実施形態では、アプリケーションの中の特定位置でユーザを認証したいと望むアプリケーション開発者は、単に、特定種類の例外をスローする命令を記述し、ユーザ認証を促すためにプラットフォームにより提供される例外ハンドラを使用できる。多くの場合、例外をスローすることにより認証を処理できることは、単に、アプリケーションコードを記述する開発者のタスクを簡略化でき、場合によってはより多くのアプリケーション開発を奨励する。

【0017】

図１を参照すると、例外処理を通じてユーザ認証をサポートする開発プラットフォーム１０のブロック図が示される。図示の実施形態では、プラットフォーム１０は、アプリケーションサーバ１１０、クライアント装置１２０、データベース１３０、及び認証サーバ１４０を含む。アプリケーションサーバ１１０は、スロー部１１４及び例外ハンドラ１１８を含むアプリケーション１１２を含む。クライアント装置１２０は、ウェブブラウザ１２２を含む。幾つかの実施形態では、プラットフォーム１０は、図示のものと異なる方法で実装されてよい。例えば、クライアント装置１２０はプラットフォーム１０の部分でなくてよく、サーバ１１０、１３０及び／又は１４０は同じコンピュータシステムにより実装されてよく、データベース１３０は存在しなくてよい、等である。

【0018】

開発プラットフォーム１０は、種々の実施形態では、ウェブブラウザ１２２を介して１つ以上のクライアント装置１２０にアクセスしてよい、アプリケーションサーバ１１０上にアプリケーション１１２のようなアプリケーションをホスティングするような種々のサービスを提供する。幾つかの実施形態では、アプリケーションサーバ１１０は、プラットフォーム１０がクラウドを実装するために、コンピュータクラスタとして一緒に動作する複数のコンピューティングシステムのうちの１つである。幾つかの実施形態では、プラットフォーム１０は、アプリケーションデータを格納するために、アプリケーションにアクセス可能であってよいデータベース１３０を提供する。幾つかの実施形態では、プラットフォーム１０は、アプリケーション１１２のようなアプリケーションの開発を促進するサービスを提供してよい。例えば、これらのサービスは、開発者からプログラム命令を受信するためにユーザインタフェースを提供すること、アプリケーションに組み込み可能なプログラム命令を含むライブラリを提供すること、開発者コードのコンパイルを促進すること、等を含んでよい。

【0019】

アプリケーション１１２は、ユーザ認証が望まれる任意の適切なアプリケーションに対応してよい。従って、一実施形態では、アプリケーション１１２は、顧客関係管理（customer relationship management(CRM)）を促進するために実行可能である。図示のように、アプリケーション１１２は、開発者コード１１３Ａ及びプラットフォームコード１１３Ｂを含んでよい。開発者コード１１３Ａは、アプリケーション１１２の開発者により記述されたプログラム命令である。これに対して、プラットフォームコード１１３Ｂは、プラットフォーム１０により提供されるプログラム命令であり、例えば、ライブラリの組み込み、ＡＰＩ（application programmable interface）参照、基本クラスの拡張、等により、アプリケーション１１２に含まれてよい。

【0020】

上述のように、開発者は、アプリケーション１１２内の１つ以上の位置で、ユーザを認証したいと望み得る。例えば、ウェブブラウザ１２２は、アプリケーション１１２とのＨＴＴＰ（hypertext transport protocol）Ｅｘｃｈａｎｇｅ１２４に参加していてよい。この中で、ユーザは、アプリケーションのユーザインタフェースウェブページを提示される。ユーザがアプリケーション１１２と相互作用するとき、ブラウザ１２２は、（例えば、ＨＴＴＰ ＧＥＴ要求により）信用情報にアクセスすることを要求し、（例えば、ＨＴＴＰ ＰＯＳＴ要求により）重要な情報を更新するよう要求し、アプリケーション１１２内の特定の機能の実行を要求する、等をしてよい。これらの状況の間にユーザ認証を処理する開発者コード１１３Ａ内のプログラム命令を提供する代わりに、種々の実施形態では、開発者は、ユーザ認証をトリガするプログラム命令（スロー部１１４として示される）を含むことができる。

【0021】

スロー部（thrower）１１４は、図示の実施形態では、ウェブブラウザ１２２が認証を保証する動作を要求されたと決定することに応答してユーザ認証を生じる特定種類の例外（認証例外１１６として示される）をスローするために実行可能なプログラム命令（又は複数のプログラム命令）である。種々の実施形態では、認証例外１１６は、例外１１６の更なる処理を促進するために使用可能な種々の情報を含んでよい（又はそれを伴ってよい）。従って、幾つかの実施形態では、この情報は、特定種類の例外を他の種類から区別するために、特定種類の例外を識別してよい。この情報は、ＨＴＴＰ ＧＥＴ要求又はＨＴＴＰ ＰＯＳＴ要求等に関連するかに関わらず特定の動作を識別するような例外１１６が要求されているコンテキストに関する情報も含んでよい。幾つかの実施形態では、例外１１６は、例外１１６をスローした機能に関連するコールスタック（つまり、呼び出した関数の特定の順序）を識別するスタックトレースも含む（又はそれを伴う）。例えば、スタックトレースは、関数「ｍａｉｎ」が、例外１１６をスローした関数「ｂａｒ」を呼び出した（つまりスロー部１１４を含んだ）関数「ｆｏｏ」を呼び出したことを示してよい。幾つかの実施形態では、認証例外１１６は、特定の認証ポリシも識別してよい。特定の認証ポリシは、ユーザの閾値保持セキュリティレベルを識別してよく、ユーザが認証されるべき方法を識別してよい、等である。後述するように、この情報は、サーバ１４０へのリダイレクトが保証されるか否か、例外１１６をトリガした要求を再生する方法、等を決定するために使用されてよい。スロー部１１４を含む開発者コードの一例は、図２と関連して以下に詳述される。認証例外１１６がスローされると、それは、例外ハンドラ１１８によりキャッチされるまで、コールスタックを伝播してよい。

【0022】

例外ハンドラ１１８は、種々の実施形態では、スローされた認証例外１１６の指示を受信し、例外１１６を処理するために実行可能であり、認証のためにウェブブラウザ１２２を認証サーバ１４０へリダイレクトすることを含む。以下に詳述するように、幾つかの実施形態では、ハンドラ１１８は、最初に、認証が保証されるか否かを決定するために、スタックトレースのような、例外１１６に含まれる情報を分析してよい。認証が保証される場合、図示の実施形態では、例外ハンドラ１１８は、認証サーバ１４０とインタフェースするために、ウェブブラウザ１２２をリダイレクトする要求を発行する（認証リダイレクト１２６として示される）。幾つかの実施形態では、認証リダイレクト１２６は、３ＸＸ状態コード（例えばコード３０３）及び認証サーバ１４０へリダイレクトされる新しいＵＲＬ（uniform resource locator）を含むＨＴＴＰ応答である。

【0023】

認証サーバ１４０は、種々の実施形態では、プラットフォーム１０のユーザを認証するよう構成されるコンピュータシステムである。従って、サーバ１４０は、ユーザから認証情報１２８を受信するために１つ以上の入力フィールドを含む認証ウェブページを提供してよい。サーバ１４０は、次に、受信した認証情報１２８を、認証済みユーザの維持された認証と比較してよく、結果１４２をアプリケーションサーバ１１０に示してよい。アプリケーションサーバ１１０は、結果１４２をアプリケーション１１２に伝達してよい。認証サーバ１４０は、任意の適切な形式の認証をサポートしてよい。幾つかの実施形態では、サーバ１４０は、二要素認証を実行する。二要素認証では、ユーザは、例えば、（１）ユーザ名及びパスワード、並びに（２）ユーザの電話へ送信されてよいワンタイム認証コード、を提示してよい。サーバ１４０が認証を実行すると、ウェブブラウザ１２２は、アプリケーション１１２にリダイレクトされて戻されてよい。

【0024】

幾つかの実施形態では、ハンドラ１１８は、例外３１６と共に受信した種々の情報を分析し及びブラウザ１２２が認証後に戻るべき場所を決定することにより、このリダイレクトの戻り（returning redirection）を実現する。図３に関して更に詳述されるように、幾つかの実施形態では、ハンドラ１１８は、認証リダイレクト１２６の中に、アプリケーション１１２内の戻り位置を識別するリターンＵＲＬを含める。このＵＲＬを受信することに応答して、認証サーバ１４０は、認証を実行した後に、該ＵＲＬへの対応するリダイレクトを発行してよい。幾つかの実施形態では、このアプローチは、ブラウザ１２２にＨＴＴＰ ＧＥＴ要求を再生させるために、ブラウザ１２２が最初にＵＲＬを指定したＨＴＴＰ ＧＥＴ要求を送信することに応答して、例外１１６がスローされた場合に使用されてよい。幾つかの実施形態では、ハンドラ１１８は、代わりに、情報をデータベース１３０に格納し、再生を実現するために該情報を後に読み出すためにリダイレクト１２６の中の識別子を含めてよい。このような実施形態では、認証サーバ１４０は、ブラウザ１２２を別の場所へリダイレクトし、識別子をリダイレクトに含めてよい。このような実施形態では、この他の場所（図３に関して以下でハンドラ１１８として記載されるが、他の実施形態では別の場所であってよい）は、データベース１３０から格納された情報を読み出し、この情報を用いてＨＴＴＰ要求を再生するためにブラウザ１２２をリダイレクトしてよい。幾つかの実施形態では、このアプローチは、ブブラウザ１２２が最初に、種々のパラメータを指定するＨＴＴＰ ＰＯＳＴ要求を送信することに応答して、例外１１６がスローされた場合に使用されてよい。該種々のパラメータは、データベース１３０に格納され、別のＨＴＴＰ ＰＯＳＴ要求の中で再生させるために読み出されてよい。他の実施形態では、最初のＨＴＴＰ要求を再生することは、異なる方法で実行されてよい。

【0025】

図２を参照すると、スロー部１１４を含む開発者コード１１３Ａの一例が示される。本例では、アプリケーション１１２は、学生の成績平均点（grade point average(GPA)）を追跡するために実行可能である。ブラウザ１２２が学生のＧＰＡを更新する要求を発行した場合、ユーザの認証レベルが「ＨＩＧＨ＿ＡＳＳＵＲＡＮＣＥ」（本例では学校の管理者に割り当てられるレベル）に等しいか否かが決定される。認証が等しくない場合、スロー部１１４の実行が生じる。

【0026】

図示の実施形態では、スロー部１１４は、例外指示２０２、ポリシ指示２０４、及びアクション指示２０６を指定する。これらは、例外１１６がスローされると、例外ハンドラ１１８に提供されてよい。例外指示２０２は、スローされている特定種類の例外を識別する。その結果、特定種類の例外が他の種類から区別でき、適切なハンドラへルーティングできる。ポリシ指示２０４は、認証に関連する認証ポリシを識別し、例えば、要求されたアクションのために必要な認証レベルを決定するために使用されてよい。アクション指示２０６は、例外１１６をスローさせる要求されている特定のアクション（例えば、「ＧＰＡを更新する」）を識別する。他の実施形態では、スロー部１１４は、より多くの（又は少ない）情報を指定してよい。図示しないが、スタックトレースは、「スロー」演算子（operator）を呼び出すことにより返されてよい。しかしながら、留意すべきことに、スロー部１１４は、図示の実施形態では、ブラウザ１２２を送信すべき特定の場所（例えば、認証サーバ１４０へのＵＲＬ）を明示的に指定しない、又はブラウザ１２２が特定の場所に戻らなければならないことを明示的に指定しない。

【0027】

スロー部１１４が実行されると、例外ハンドラ１１８は、スローされた例外１１６の指示を受信してよい。幾つかの実施形態では、この指示は、データ構造へのポインタの形式であり、これは本例では、「ｎｅｗ」演算子を呼び出すことによりインスタンス化され、「ｔｈｒｏｗ」演算子によりスローされる。別の実施形態では、受信した指示は、例外１１６に関する情報を含むデータ構造である。（図示の例は「ＡＰＥＸ（商標）」で記述されるが、任意の適切な言語が使用されてよい）。

【0028】

図３を参照すると、例外ハンドラ１１８のブロック図が示される。図示の実施形態では、例外ハンドラ１１８は、例外分析部３１０、リダイレクト部３２０、及び再生支援部２２０を含む。幾つかの実施形態では、ハンドラ１１８は、図示のものと異なる方法で実装されてよい。例えば、再生支援部３３０は、ハンドラ１１８と別個であってよく、認証サーバ１４０に置かれ及び／又は他の場所に置かれてよい。

【0029】

例外分析部３１０は、幾つかの実施形態では、例外１１６と共に返された情報を分析し、認証が保証されるか否かを決定するために実行可能なプログラム命令のセットである。種々の実施形態では、この分析は、図２を参照して上述した種々の情報を検査するステップを含んでよい。例えば、分析部３１０は、スタックトレースの中のコールスタックに基づき、スローされた例外１１６の発生源（例えば、関数）を識別してよい。例外１１６が（開発者コード１１３Ａの中の関数ではなく）ＡＰＩ呼び出しから生じた場合には、分析部３１０は、認証が保証されないと決定してよい。分析部３１０は、ブラウザ１２２により要求されている特定の関数（例えば、例外１１６と共に返されたアクション指示２０６）を分析してもよい。認証が保証されない場合、分析部３１０は、アプリケーション１１２及び／又はブラウザ１２２へエラーメッセージを返してよい。しかしながら、認証が保証される場合、分析部３１０は、例外１１６をリダイレクト部３２０に渡してよい。

【0030】

リダイレクト部３２０は、幾つかの実施形態では、ユーザ認証の実行を生じるために、ウェブブラウザ１２２を認証サーバ１４０へリダイレクトするために実行可能なプログラム命令のセットである。上述のように、このリダイレクトは、例えば、認証サーバ１４０のアドレスと共に、ＨＴＴＰリダイレクト状態コード（例えば、３ＸＸコード）をブラウザ１２２へ送信することを含んでよい。種々の実施形態では、リダイレクト部３２０は、さらに、ブラウザ１２２がアプリケーション１１２へリターンするのを促進するために使用可能な種々の情報を収集するために実行可能である。幾つかの実施形態では、リダイレクト部３２０は、この情報を１つ以上のパラメータとして、認証リダイレクト１２６に含まれるＵＲＬに含める。例えば、ブラウザ１２２からのＨＴＴＰ ＧＥＴ要求が例外１１６をトリガした場合、リダイレクト部３２０は、ブラウザ１２２が認証により返すべき場所を識別するリターンＵＲＬ３２２を含んでよい。リターンＵＲＬ３２２を受信することに応答して、認証サーバ１４０は、ブラウザ１２２をアプリケーション１１２に戻し及び最初のＨＴＴＰ GET要求３３６を再生するために、リターンＵＲＬ３２２を再生リダイレクト３３２に含めてよい。幾つかの実施形態では、リダイレクト部３２０は、代替として、再生情報３２４をデータベース１３０に格納し、情報３２４を後に読み出すために、ＵＲＬ内の情報識別し３２６を認証リダイレクト１２６に含めてよい。例えば、ブラウザ１２２からのＨＴＴＰ ＰＯＳＴ要求が例外１１６をトリガした場合、リダイレクト部３２０は、後に読み出すために、ＨＴＴＰ ＰＯＳＴ要求の中で指定されたパラメータをデータベース１３０に格納してよい。幾つかの実施形態では、リダイレクト部３２０は、再生情報３２４を保護するために、さらに該情報を暗号化してよい。（データベース１３０はアプリケーションサーバ１１０と別個のものとして図１に示されるが、任意の適切な記憶装置が、サーバ１１０におけるローカルキャッシュのような再生情報１２４を格納するために使用されてよい）。

【0031】

再生支援部３３０は、幾つかの実施形態では、特定種類の例外の指示をスローさせる要求３３６を特定アプリケーションに戻すために実行可能なプログラム命令のセットである。図示の実施形態では、ハンドラ１１８の中に示されるが、支援部３３０は、アプリケーション１１２、認証サーバ１４０（例えば、再生リダイレクト３３２を発行するために）、等の中のような別の場所に存在してよい。再生支援部３３０の複数のインスタンスが使用されてもよい。図示の実施形態では、支援部３３０は、認証の実行に応答して、情報識別子３２６（これは、ブラウザ１２２によりリダイレクト要求の中で伝達されてよい）を認証サーバ１４０から受信する。識別子３２６を受信することに応答して、支援部３３０は、識別子３２６を使用して、前に格納された再生情報３２４をデータベース１３０から読み出し、再生リダイレクト３３４の中の情報３２４を提供して、アプリケーション１１２に戻るためにブラウザ１２２に適切なＨＴＴＰ要求３３６を再生させてよい。

【0032】

図４Ａを参照すると、例外処理を通じてユーザを認証する方法４００のフローチャートが示される。一実施形態では、方法４００は、アプリケーション１１２を実行するアプリケーションサーバ１１０のようなアプリケーションを実行するコンピューティングシステムにより実行される。

【0033】

ステップ４０５で、ソフトウェア開発プラットフォーム（例えば、プラットフォーム１０）の例外ハンドラ（例えば、例外ハンドラ１１８）が維持され、例外ハンドラは、ソフトウェア開発プラットフォーム上で実行するアプリケーション（例えば、アプリケーション１１２）のユーザの認証を生じる特定種類の例外（例えば、例外１１６）を処理するために実行可能である。

【0034】

ステップ４１０で、特定アプリケーションによりスローされた特定種類の例外の指示は、例外ハンドラで受信される。

【0035】

ステップ４１５で、特定種類の例外の指示を受信することに応答して、例外ハンドラは、特定アプリケーションと相互作用するウェブブラウザ（例えば、ブラウザ１２２）へ、ウェブブラウザを特定アプリケーションのユーザの認証を実行するよう構成される認証サーバ（例えば、サーバ１４０）へリダイレクトする要求（例えば、要求１２６）を発行する。幾つかの実施形態では、発行された要求は、ＨＴＴＰリダイレクト状態コードを含む。幾つかの実施形態では、認証は二要素認証である。幾つかの実施形態では、特定種類の例外の指示と共に受信されたスタックトレースは、分析され、スタックトレースは、特定種類の例外をスローしたアプリケーション関数の名称を識別する。分析に基づき、ウェブブラウザが認証サーバにリダイレクトする要求を発行するか否かを決定する。

【0036】

ステップ４２０で、実行された認証の結果（例えば、結果１４２）が、認証サーバから受信される。ステップ４２５で、結果が、特定アプリケーションに返される。幾つかの実施形態では、方法４００は、認証に応答して、特定種類の例外の指示をスローさせた要求（例えば、要求３３６）を再生するよう（例えば、リダイレクト部３３４を介して）ウェブブラウザに指示することにより、ウェブブラウザを特定アプリケーションに戻すことを更に含む。幾つかの実施形態では、ＵＲＬ（uniform resource locator）は、ウェブブラウザに提供され、特定種類の例外の指示をスローさせた要求を再生するために使用可能な情報（例えば、リターンＵＲＬ３２２、又は情報識別子３２６）を含む。幾つかの実施形態では、方法４００は、データベースに、特定種類の例外の指示をスローさせた要求に関する情報（例えば、再生情報３２４）を格納するステップを含む。このような実施形態では、格納された情報は、特定種類の例外の指示をスローさせた要求を再生するために使用される。幾つかの実施形態では、方法４００は、特定種類の例外の指示と共に受信されたスタックトレースを分析することにより、特定アプリケーションにおいて、ウェブブラウザを戻すべき場所を決定するステップを含み、スタックトレースは、特定種類の例外をスローしたアプリケーション関数の名称を識別する。

【0037】

図４Ｂを参照すると、例外処理を通じてユーザを認証する別の方法４５０のフローチャートが示される。一実施形態では、方法４５０は、認証サーバ１４０のような、ユーザ認証を実行するコンピューティングシステムにより実行される。

【0038】

方法は、ステップ４５５で開始し、ウェブブラウザ（例えば、ウェブブラウザ１２２）から、アプリケーションのユーザを認証するための要求を受信する。種々の実施形態では、要求は、アプリケーションが特定種類の例外（例えば、例外１１６）をスローすることに応答して、ウェブブラウザにより発行される。例外は、例外ハンドラ（例えば、例外ハンドラ１１８）に、ウェブブラウザをコンピューティングシステムへとリダイレクトさせる。ステップ４６０で、要求に応答して、認証ページがウェブブラウザに提供される。ステップ４６５で、認証ページを介して受信した入力（例えば、認証情報１２８）に基づき、ユーザの認証が実行される。ステップ４７０で、ウェブブラウザは、（例えば、再生リダイレクト３３２を介して）アプリケーションにリダイレクトされる。種々の実施形態では、リダイレクトするステップは、ウェブブラウザに、特定種類の例外をスローさせたアプリケーションへ要求を再生するためにウェブブラウザにより使用可能な情報を提供するステップを含む。幾つかの実施形態では、ウェブブラウザに提供される情報は、認証するために受信した要求の中のＵＲＬに含まれる値（例えば、情報識別子３２６）に基づき決定されル。幾つかの実施形態では、再生された要求は、提供された情報に対応する１つ以上のパラメータを含むＨＴＴＰ ＰＯＳＴ要求（例えば、要求３３６）である。一実施形態では、値は、データベース（例えば、データベース１３０）から１つ以上のパラメータを取得するために使用可能である。

【0039】

＜例示的なコンピュータシステム＞
図５を参照すると、例示的なコンピュータシステム５００のブロック図が示され、プラットフォーム１０（例えば、サーバ１１０、装置１２０、データベース１３０、又はサーバ１４０）の機能を実装してよい。コンピュータシステム５００は、相互接続５６０（例えば、システムバス）を介してシステムメモリ５２０及びＩ／Ｏインタフェース５４０に結合されるプロセッササブシステム５８０を含む。Ｉ／Ｏインタフェース５４０は、１つ以上の装置５５０に結合される。コンピュータシステム５００は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はＰＤＡ（personal data assistant）のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム５００が図５に示されるが、システム５００は、一緒に動作する２つ以上のコンピュータシステムとして実装されてもよい。

【0040】

プロセッササブシステム５８０は、１つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム５００の種々の実施形態では、プロセッササブシステム５８０の複数のインスタンスが相互接続５６０に結合されてよい。種々の実施形態では、プロセッササブシステム５８０（又は５８０内の各処理ユニット）は、キャッシュ又は他の形式のオンボードメモリを含んでよい。一実施形態では、プロセッササブシステム５８０は、上述のプロセッサ１０２を含んでよい。

【0041】

システムメモリ５２０は、プロセッササブシステム５８０により実行可能なプログラム命令を格納し、システム５００に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ５２０は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＡＭＢＵＳ ＲＡＭ、等）、読み出し専用メモリ（ＰＲＯＭ、ＥＥＰＲＯＭ、等）、等を用いて実装されてよい。コンピュータシステム５００内のメモリは、メモリ５２０のような主記憶装置に限定されない。むしろ、コンピュータシステム５００は、プロセッササブシステム５８０内のキャッシュメモリ及びＩ／Ｏ装置５５０内の２次記憶装置（例えば、ハードドライブ、ストレージアレイ、等）のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム５８０により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、上述のプリケーション１１２は、システムメモリ５２０内に格納されたプログラム命令であってよい。

【0042】

Ｉ／Ｏインタフェース５４０は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態では、Ｉ／Ｏインタフェース５４０は、フロントサイドから１つ以上のバックサイドバスへのブリッジチップ（例えば、Ｓｏｕｔｈｂｒｉｇｄｇｅ）である。Ｉ／Ｏインタフェース５４０は、１つ以上の対応するバス又は他のインタフェースを介して１つ以上のＩ／Ｏ装置５５０に結合されてよい。Ｉ／Ｏ装置５５０の例は、記憶装置（ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、ＳＡＮ、又はそれらの関連する制御部）、（例えば、ローカル又はワイドエリアネットワークへの）ネットワークインタフェース装置、又は他の装置（例えば、グラフィック、ユーザインタフェース装置、等）を含む。一実施形態では、コンピュータシステム５００は、（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、Ｅｔｈｅｒｎｅｔ、等を介して通信するよう構成される）ネットワークインタフェース５５０を介してネットワークに結合される。

【0043】

特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。

【0044】

本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合（明示的又は暗示的のいずれも）、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願（又は本願に基づく優先権を主張する出願）の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】