IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

<>
  • -例外処理を通じた認証 図1
  • -例外処理を通じた認証 図2
  • -例外処理を通じた認証 図3
  • -例外処理を通じた認証 図4A
  • -例外処理を通じた認証 図4B
  • -例外処理を通じた認証 図5
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-01-11
(45)【発行日】2022-01-24
(54)【発明の名称】例外処理を通じた認証
(51)【国際特許分類】
   G06F 21/31 20130101AFI20220117BHJP
【FI】
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)【参考文献】
【文献】特開2017-49745(JP,A)
【文献】特開2010-123127(JP,A)
【文献】米国特許出願公開第2012/0144374(US,A1)
【文献】米国特許出願公開第2017/0170963(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/31
(57)【特許請求の範囲】
【請求項1】
プログラム命令を格納した非一時的コンピュータ可読媒体であって、前記プログラム命令は、コンピュータシステムに動作を実施させることができ、前記動作は、
ソフトウェア開発プラットフォームの例外ハンドラを維持するステップであって、前記例外ハンドラは、前記ソフトウェア開発プラットフォーム上で実行するアプリケーションのユーザの認証を生じる特定種類の例外を処理するために実行される、ステップと、
前記例外ハンドラにおいて、特定アプリケーションによりスローされた前記特定種類の例外の指示を受信するステップと、
前記特定種類の例外の前記指示を受信することに応答して、
前記例外ハンドラにより、前記特定アプリケーションと相互作用するウェブブラウザへ、要求を発行するステップであって、前記要求は、前記ウェブブラウザが、前記特定アプリケーションのユーザの認証を実行するよう構成される認証サーバへリダイレクトする、ステップと、
前記認証サーバから、前記実行された認証の結果を受信するステップと、
前記特定アプリケーションへ前記結果を返すステップと、
を含む、コンピュータ可読媒体。
【請求項2】
前記動作は、
前記認証に応答して、前記特定種類の例外の前記指示をスローさせる要求を再生するよう前記ウェブブラウザに指示することにより、前記ウェブブラウザを前記特定アプリケーションに戻すステップを含む、請求項1に記載に記載のコンピュータ可読媒体。
【請求項3】
前記発行するステップは、
前記特定種類の例外の前記指示をスローさせる前記要求を再生するために使用できる情報を含むURL(uniform resource locator)を、前記ウェブブラウザに提供するステップを含む、請求項2に記載に記載のコンピュータ可読媒体。
【請求項4】
前記発行するステップは、
データベースに、前記特定種類の例外の前記指示をスローさせる前記要求に関する情報を格納するステップであって、前記格納された情報は、前記特定種類の例外の前記指示をスローさせる前記要求を再生するために使用される、請求項2に記載のコンピュータ可読媒体。
【請求項5】
前記動作は、
前記特定種類の例外の前記指示と共に受信されたスタックトレースを分析することにより、前記特定アプリケーション内の前記ウェブブラウザの戻るべき場所を決定するステップであって、前記スタックトレースは、前記特定種類の例外をスローしたアプリケーション機能の名称を識別する、ステップを含む、請求項2に記載のコンピュータ可読媒体。
【請求項6】
前記動作は、
前記特定種類の例外の前記指示と共に受信されたスタックトレースを分析するステップであって、前記スタックトレースは、前記特定種類の例外をスローしたアプリケーション機能の名称を識別する、ステップと、
前記分析に基づき、前記ウェブブラウザが認証サーバへリダイレクトする前記要求を発行するか否かを決定するステップと、
を含む、請求項1に記載のコンピュータ可読媒体。
【請求項7】
前記発行された要求は、HTTP(hypertext transfer protocol)リダイレクト状態コードを含む、請求項6に記載のコンピュータ可読媒体。
【請求項8】
前記認証は、二要素認証である、請求項1に記載のコンピュータ可読媒体。
【請求項9】
前記プログラム命令は、前記特定アプリケーションの開発者により提供されるプログラム命令を含み、前記開発者の提供したプログラム命令は、前記特定種類の例外をスローする、請求項1に記載のコンピュータ可読媒体。
【請求項10】
プログラム命令を格納した非一時的コンピュータ可読媒体であって、前記プログラム命令は、コンピューティングシステムに、動作を実行するアプリケーションを実装させることができ、前記動作は、
クライアント装置のウェブブラウザに、前記アプリケーションのユーザインタフェースを提示するステップと、
前記ウェブブラウザがユーザ認証を保証する前記アプリケーションの機能を要求したと決定するステップと、
ソフトウェア開発プラットフォームの例外ハンドラにより処理される特定種類の例外をスローするステップであって、前記特定種類の例外は、前記例外ハンドラに、前記ユーザ認証を実行するよう構成される認証サーバへ前記ウェブブラウザをリダイレクトさせる、ステップと、
前記実行された認証の結果に基づき、前記要求された機能の実行を許可するステップと、
を含む、コンピュータ可読媒体。
【請求項11】
前記動作は、
前記例外ハンドラに、前記ウェブブラウザのリダイレクトが保証されるか否かを決定するために、前記例外ハンドラにより使用できるコールスタックを識別するスタックトレースを提供するステップを含む、請求項10に記載のコンピュータ可読媒体。
【請求項12】
前記動作は、
前記例外ハンドラに、前記ウェブブラウザに前記機能の要求を再提出させるために前記例外ハンドラにより使用できる前記要求された機能の名称を識別するスタックトレースを提供するステップを含む、請求項10に記載のコンピュータ可読媒体。
【請求項13】
前記ユーザ認証は、2つ以上の要素に基づく、請求項10に記載のコンピュータ可読媒体。
【請求項14】
前記プログラム命令は、前記例外ハンドラのプログラム命令を含む、請求項10に記載のコンピュータ可読媒体。
【請求項15】
方法であって、
コンピューティングシステムにより、ウェブブラウザから、アプリケーションのユーザを認証するための要求を受信するステップであって、前記要求は、前記アプリケーションが、例外ハンドラに前記ウェブブラウザを前記コンピューティングシステムにリダイレクトさせる特定種類の例外をスローすることに応答して発行される、ステップと、
前記要求に応答して、前記コンピューティングシステムにより、前記ウェブブラウザへ認証ページを提供するステップと、
前記コンピューティングシステムにより、前記認証ページを介して受信された入力に基づき、前記ユーザの認証を実行するステップと、
前記コンピューティングシステムにより、前記ウェブブラウザを前記アプリケーションへリダイレクトするステップと、
を含む方法。
【請求項16】
前記リダイレクトするステップは、前記ウェブブラウザに、前記特定種類の例外をスローさせた前記アプリケーションへ要求を再生するために前記ウェブブラウザにより使用可能な情報を提供するステップを含む、請求項15に記載の方法。
【請求項17】
前記コンピューティングシステムにより、認証するための前記受信した要求の中のURL(uniform resource locator)に含まれた値に基づき、前記ウェブブラウザに提供すべき前記情報を決定するステップ、
を更に含む請求項16に記載の方法。
【請求項18】
前記再生された要求は,前記提供された情報に対応する1つ以上のパラメータを含むHTTP(hypertext transfer protocol) POST要求である、請求項17に記載の方法。
【請求項19】
前記値は、前記1つ以上のパラメータをデータベースから取得するために使用可能である、請求項18に記載の方法。
【請求項20】
前記認証は、2つ以上の要素に基づく、請求項16に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、概して、コンピュータセキュリティに関し、より具体的にはユーザ認証に関する。
【背景技術】
【0002】
コンピュータネットワークは、リソースへのアクセスを望む可能性のある何人かのユーザ間で共有される複数のリソースを含んでよい。所与のユーザがリソースを悪用しないことを保証するために、ユーザは、リソースへのアクセスを与えられる前に認証されてよい。幾つかの例では、所与のリソースは、例えば、認証情報を依頼し、それをローカルに格納された認証済みユーザの認証と比較することにより、認証をローカルで処理してよい。他の例では、コンピュータネットワークは、認証情報を維持し及びユーザを認証するために信頼できる中央当局に依存してよい。中央当局は、ユーザ認証情報の一層の保護を維持し対応するのが容易であり得るので、有利である。中央当局を使用する認証方式の例は、Kerberos、リモート認証ダイヤルインユーザサービス(remote authentication dial-in user service(RADIUS))、等である。
【発明の概要】
【0003】
本開示は、「一実施形態」又は「実施形態」への言及を含む。「一実施形態では」又は「実施形態では」の語句の出現は、必ずしも同じ実施形態を表さない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の適切な方法で結合されてよい。
【0004】
本開示において、異なるエンティティ(これは、「ユニット」、「回路」、他のコンポーネント、等のように様々に表されてよい)は、1つ以上のタスク又は動作を実行するよう「構成される」と記載され又は請求されてよい。この明確な記述-[1つ以上のタスクを実行する]よう構成される[エンティティ]-は、本願明細書で、構造(つまり、電子回路のような何らかの物理的なもの)を表すために使用される。より具体的には、この明確な記述は、この構造が動作中に1つ以上のタスクを実行するよう配置されることを示すために使用される。構造は、該構造が現在作動中でない場合でも、何らかのタスクを実行する「よう構成される」と言える。「ユーザの認証を実行するよう構成される認証サーバ」は、例えば、プロセッサとプログラム命令を含むメモリとを有するコンピュータシステムであって、プログラム命令は、対象となる集積回路が現在使用中でない(例えば、電源が接続されていない)場合でも動作中に機能を実行するために実行可能である、をカバーすることを意図する。従って、何らかのタスクを実行する「よう構成される」と記載され又は引用されるエンティティは、装置、回路、タスクを実施するために実行可能なプログラム命令を格納するメモリ、等のような何らかの物理的なものを表す。この語法は、本願明細書で、何らかの無形物を表すために使用されない。従って、「~よう構成される」構成は、本願明細書では、アプリケーションプログラミングインタフェース(application programming interface(API))のようなソフトウェアエンティティを表すために使用されない。
【0005】
用語「~よう構成される(configured to)」は、「構成可能である(configurable to」を意味しない。未設定FPGAは、例えば、何らかの特定の機能を実行するよう「構成される」と考えられない。しかしながら、未設定FPGAは、該機能を実行するよう「構成可能」であってよく、設定(プログラミング)後に該機能を実行するよう「構成され」てよい。
【0006】
添付の特許請求の範囲における、構造が1つ以上のタスクを実行するよう「構成される」という記載は、その請求項の要素について35U.S.C.§112(f)fを含まないことが明確に意図される。従って、提出される本願の請求項のいずれも、手段及び機能の要素を有するものとして解釈されることが意図される。出願人が審査中に§112(f)を含むことを意図する場合には、[機能を実行するための]「手段」の構成を用いて請求項の要素を記載する。
【0007】
本願明細書で使用されるとき、用語「第1」、「第2」、等は、それらが先行する名詞のラベルとして使用され、特に断りの無い限り、いかなる種類の順序(例えば、空間的、時間的、論理的、等)も意味しない。例えば、複数のユーザアカウントを有するコンピューティングシステムでは、用語「第1」及び「第2」ユーザアカウントは、任意のユーザを表すために使用できる。言い換えると、「第1」及び「第2」ユーザアカウントは、例えば最初の2つの生成されたユーザアカウントに限定されない。
【0008】
本願明細書で使用されるとき、用語「に基づき」は、決定に影響する1つ以上の要素を記述するために使用される。この用語は、追加要素が決定に影響し得る可能性を排除しない。つまり、決定は、特定の要素に単独で基づいて、又は特定の要素及び他の指定されていない要素に基づいてよい。語法「Bに基づきAを決定する」を検討する。この語法は、BがAを決定するための要素であること、又はAの決定に影響することを指定する。この語法は、Aの決定がCのような何からの他の要素にも基づいてよいことを排除しない。この語法は、AがBにのみ基づき決定されル一実施形態をカバーすることも意図する。本願明細書で使用されるとき、語法「に基づき」は、従って、「に少なくとも部分的に基づき」と同義である。
【図面の簡単な説明】
【0009】
図1】例外処理を通じてユーザ認証をサポートする開発プラットフォームの一実施形態のブロック図である。
【0010】
図2】ユーザ認証を生じる例外をスローするために実行可能な開発者コードの一例を示す図である。
【0011】
図3】スローされた例外を処理するために実行可能な例外ハンドラの一実施形態を示すブロック図である。
【0012】
図4A】例外処理を通じて認証する方法の実施形態を示すフロー図である。
図4B】例外処理を通じて認証する方法の実施形態を示すフロー図である。
【0013】
図5】例示的なコンピュータシステムの一実施形態を示すブロック図である。
【発明を実施するための形態】
【0014】
幾つかの例では、開発者は、アプリケーションの要求された機能を可能にする前に、ユーザを認証したいと望み得る。認証が認証サーバにより処理されている場合、開発者は,ユーザを認証サーバへリダイレクトするアプリケーション内のコード、及び要求された機能へのアクセスを与えられるためにアプリケーションへユーザを戻すことを処理するコード、を記述する責任があってよい。しかしながら、このコードを記述することは、退屈であり、誤って実装されることがある。
【0015】
本開示は、プラットフォームが、ウェブブラウザを介してクライアント装置にアクセス可能なアプリケーションサーバ上で1つ以上のアプリケーションをホストし得る実施形態を記載する。以下に種々の実施形態で更に詳述するように、プラットフォームは、ユーザ認証を実行させるためにアプリケーションによりスローできる新しい種類の例外をサポートする。本願明細書で使用されるとき、用語「例外」は、従来の理解された意味に従い解釈されるべきであり、これは、(1)(エラーの発生のような)イベントの発生に応答して返される、及び(2)イベントの発生に関連するアクションを行うために例外ハンドラにより使用可能なイベントに関する情報を含む、データ構造を含む。種々の実施形態では、特定種類の例外がスローされると、プラットフォームにより提供される例外ハンドラは、スローされた例外の指示を受信し、ユーザのウェブブラウザを、ユーザを認証するよう構成される認証サーバへリダイレクトすることを実施する。幾つかの実施形態では、例外ハンドラは、認証が実行された後に、例えば、ブラウザに特定種類の例外を初めにスローされた前の要求を再生させることにより、ユーザのブラウザをアプリケーションに戻すことも行う。
【0016】
種々の実施形態では、アプリケーションの中の特定位置でユーザを認証したいと望むアプリケーション開発者は、単に、特定種類の例外をスローする命令を記述し、ユーザ認証を促すためにプラットフォームにより提供される例外ハンドラを使用できる。多くの場合、例外をスローすることにより認証を処理できることは、単に、アプリケーションコードを記述する開発者のタスクを簡略化でき、場合によってはより多くのアプリケーション開発を奨励する。
【0017】
図1を参照すると、例外処理を通じてユーザ認証をサポートする開発プラットフォーム10のブロック図が示される。図示の実施形態では、プラットフォーム10は、アプリケーションサーバ110、クライアント装置120、データベース130、及び認証サーバ140を含む。アプリケーションサーバ110は、スロー部114及び例外ハンドラ118を含むアプリケーション112を含む。クライアント装置120は、ウェブブラウザ122を含む。幾つかの実施形態では、プラットフォーム10は、図示のものと異なる方法で実装されてよい。例えば、クライアント装置120はプラットフォーム10の部分でなくてよく、サーバ110、130及び/又は140は同じコンピュータシステムにより実装されてよく、データベース130は存在しなくてよい、等である。
【0018】
開発プラットフォーム10は、種々の実施形態では、ウェブブラウザ122を介して1つ以上のクライアント装置120にアクセスしてよい、アプリケーションサーバ110上にアプリケーション112のようなアプリケーションをホスティングするような種々のサービスを提供する。幾つかの実施形態では、アプリケーションサーバ110は、プラットフォーム10がクラウドを実装するために、コンピュータクラスタとして一緒に動作する複数のコンピューティングシステムのうちの1つである。幾つかの実施形態では、プラットフォーム10は、アプリケーションデータを格納するために、アプリケーションにアクセス可能であってよいデータベース130を提供する。幾つかの実施形態では、プラットフォーム10は、アプリケーション112のようなアプリケーションの開発を促進するサービスを提供してよい。例えば、これらのサービスは、開発者からプログラム命令を受信するためにユーザインタフェースを提供すること、アプリケーションに組み込み可能なプログラム命令を含むライブラリを提供すること、開発者コードのコンパイルを促進すること、等を含んでよい。
【0019】
アプリケーション112は、ユーザ認証が望まれる任意の適切なアプリケーションに対応してよい。従って、一実施形態では、アプリケーション112は、顧客関係管理(customer relationship management(CRM))を促進するために実行可能である。図示のように、アプリケーション112は、開発者コード113A及びプラットフォームコード113Bを含んでよい。開発者コード113Aは、アプリケーション112の開発者により記述されたプログラム命令である。これに対して、プラットフォームコード113Bは、プラットフォーム10により提供されるプログラム命令であり、例えば、ライブラリの組み込み、API(application programmable interface)参照、基本クラスの拡張、等により、アプリケーション112に含まれてよい。
【0020】
上述のように、開発者は、アプリケーション112内の1つ以上の位置で、ユーザを認証したいと望み得る。例えば、ウェブブラウザ122は、アプリケーション112とのHTTP(hypertext transport protocol)Exchange124に参加していてよい。この中で、ユーザは、アプリケーションのユーザインタフェースウェブページを提示される。ユーザがアプリケーション112と相互作用するとき、ブラウザ122は、(例えば、HTTP GET要求により)信用情報にアクセスすることを要求し、(例えば、HTTP POST要求により)重要な情報を更新するよう要求し、アプリケーション112内の特定の機能の実行を要求する、等をしてよい。これらの状況の間にユーザ認証を処理する開発者コード113A内のプログラム命令を提供する代わりに、種々の実施形態では、開発者は、ユーザ認証をトリガするプログラム命令(スロー部114として示される)を含むことができる。
【0021】
スロー部(thrower)114は、図示の実施形態では、ウェブブラウザ122が認証を保証する動作を要求されたと決定することに応答してユーザ認証を生じる特定種類の例外(認証例外116として示される)をスローするために実行可能なプログラム命令(又は複数のプログラム命令)である。種々の実施形態では、認証例外116は、例外116の更なる処理を促進するために使用可能な種々の情報を含んでよい(又はそれを伴ってよい)。従って、幾つかの実施形態では、この情報は、特定種類の例外を他の種類から区別するために、特定種類の例外を識別してよい。この情報は、HTTP GET要求又はHTTP POST要求等に関連するかに関わらず特定の動作を識別するような例外116が要求されているコンテキストに関する情報も含んでよい。幾つかの実施形態では、例外116は、例外116をスローした機能に関連するコールスタック(つまり、呼び出した関数の特定の順序)を識別するスタックトレースも含む(又はそれを伴う)。例えば、スタックトレースは、関数「main」が、例外116をスローした関数「bar」を呼び出した(つまりスロー部114を含んだ)関数「foo」を呼び出したことを示してよい。幾つかの実施形態では、認証例外116は、特定の認証ポリシも識別してよい。特定の認証ポリシは、ユーザの閾値保持セキュリティレベルを識別してよく、ユーザが認証されるべき方法を識別してよい、等である。後述するように、この情報は、サーバ140へのリダイレクトが保証されるか否か、例外116をトリガした要求を再生する方法、等を決定するために使用されてよい。スロー部114を含む開発者コードの一例は、図2と関連して以下に詳述される。認証例外116がスローされると、それは、例外ハンドラ118によりキャッチされるまで、コールスタックを伝播してよい。
【0022】
例外ハンドラ118は、種々の実施形態では、スローされた認証例外116の指示を受信し、例外116を処理するために実行可能であり、認証のためにウェブブラウザ122を認証サーバ140へリダイレクトすることを含む。以下に詳述するように、幾つかの実施形態では、ハンドラ118は、最初に、認証が保証されるか否かを決定するために、スタックトレースのような、例外116に含まれる情報を分析してよい。認証が保証される場合、図示の実施形態では、例外ハンドラ118は、認証サーバ140とインタフェースするために、ウェブブラウザ122をリダイレクトする要求を発行する(認証リダイレクト126として示される)。幾つかの実施形態では、認証リダイレクト126は、3XX状態コード(例えばコード303)及び認証サーバ140へリダイレクトされる新しいURL(uniform resource locator)を含むHTTP応答である。
【0023】
認証サーバ140は、種々の実施形態では、プラットフォーム10のユーザを認証するよう構成されるコンピュータシステムである。従って、サーバ140は、ユーザから認証情報128を受信するために1つ以上の入力フィールドを含む認証ウェブページを提供してよい。サーバ140は、次に、受信した認証情報128を、認証済みユーザの維持された認証と比較してよく、結果142をアプリケーションサーバ110に示してよい。アプリケーションサーバ110は、結果142をアプリケーション112に伝達してよい。認証サーバ140は、任意の適切な形式の認証をサポートしてよい。幾つかの実施形態では、サーバ140は、二要素認証を実行する。二要素認証では、ユーザは、例えば、(1)ユーザ名及びパスワード、並びに(2)ユーザの電話へ送信されてよいワンタイム認証コード、を提示してよい。サーバ140が認証を実行すると、ウェブブラウザ122は、アプリケーション112にリダイレクトされて戻されてよい。
【0024】
幾つかの実施形態では、ハンドラ118は、例外316と共に受信した種々の情報を分析し及びブラウザ122が認証後に戻るべき場所を決定することにより、このリダイレクトの戻り(returning redirection)を実現する。図3に関して更に詳述されるように、幾つかの実施形態では、ハンドラ118は、認証リダイレクト126の中に、アプリケーション112内の戻り位置を識別するリターンURLを含める。このURLを受信することに応答して、認証サーバ140は、認証を実行した後に、該URLへの対応するリダイレクトを発行してよい。幾つかの実施形態では、このアプローチは、ブラウザ122にHTTP GET要求を再生させるために、ブラウザ122が最初にURLを指定したHTTP GET要求を送信することに応答して、例外116がスローされた場合に使用されてよい。幾つかの実施形態では、ハンドラ118は、代わりに、情報をデータベース130に格納し、再生を実現するために該情報を後に読み出すためにリダイレクト126の中の識別子を含めてよい。このような実施形態では、認証サーバ140は、ブラウザ122を別の場所へリダイレクトし、識別子をリダイレクトに含めてよい。このような実施形態では、この他の場所(図3に関して以下でハンドラ118として記載されるが、他の実施形態では別の場所であってよい)は、データベース130から格納された情報を読み出し、この情報を用いてHTTP要求を再生するためにブラウザ122をリダイレクトしてよい。幾つかの実施形態では、このアプローチは、ブブラウザ122が最初に、種々のパラメータを指定するHTTP POST要求を送信することに応答して、例外116がスローされた場合に使用されてよい。該種々のパラメータは、データベース130に格納され、別のHTTP POST要求の中で再生させるために読み出されてよい。他の実施形態では、最初のHTTP要求を再生することは、異なる方法で実行されてよい。
【0025】
図2を参照すると、スロー部114を含む開発者コード113Aの一例が示される。本例では、アプリケーション112は、学生の成績平均点(grade point average(GPA))を追跡するために実行可能である。ブラウザ122が学生のGPAを更新する要求を発行した場合、ユーザの認証レベルが「HIGH_ASSURANCE」(本例では学校の管理者に割り当てられるレベル)に等しいか否かが決定される。認証が等しくない場合、スロー部114の実行が生じる。
【0026】
図示の実施形態では、スロー部114は、例外指示202、ポリシ指示204、及びアクション指示206を指定する。これらは、例外116がスローされると、例外ハンドラ118に提供されてよい。例外指示202は、スローされている特定種類の例外を識別する。その結果、特定種類の例外が他の種類から区別でき、適切なハンドラへルーティングできる。ポリシ指示204は、認証に関連する認証ポリシを識別し、例えば、要求されたアクションのために必要な認証レベルを決定するために使用されてよい。アクション指示206は、例外116をスローさせる要求されている特定のアクション(例えば、「GPAを更新する」)を識別する。他の実施形態では、スロー部114は、より多くの(又は少ない)情報を指定してよい。図示しないが、スタックトレースは、「スロー」演算子(operator)を呼び出すことにより返されてよい。しかしながら、留意すべきことに、スロー部114は、図示の実施形態では、ブラウザ122を送信すべき特定の場所(例えば、認証サーバ140へのURL)を明示的に指定しない、又はブラウザ122が特定の場所に戻らなければならないことを明示的に指定しない。
【0027】
スロー部114が実行されると、例外ハンドラ118は、スローされた例外116の指示を受信してよい。幾つかの実施形態では、この指示は、データ構造へのポインタの形式であり、これは本例では、「new」演算子を呼び出すことによりインスタンス化され、「throw」演算子によりスローされる。別の実施形態では、受信した指示は、例外116に関する情報を含むデータ構造である。(図示の例は「APEX(商標)」で記述されるが、任意の適切な言語が使用されてよい)。
【0028】
図3を参照すると、例外ハンドラ118のブロック図が示される。図示の実施形態では、例外ハンドラ118は、例外分析部310、リダイレクト部320、及び再生支援部220を含む。幾つかの実施形態では、ハンドラ118は、図示のものと異なる方法で実装されてよい。例えば、再生支援部330は、ハンドラ118と別個であってよく、認証サーバ140に置かれ及び/又は他の場所に置かれてよい。
【0029】
例外分析部310は、幾つかの実施形態では、例外116と共に返された情報を分析し、認証が保証されるか否かを決定するために実行可能なプログラム命令のセットである。種々の実施形態では、この分析は、図2を参照して上述した種々の情報を検査するステップを含んでよい。例えば、分析部310は、スタックトレースの中のコールスタックに基づき、スローされた例外116の発生源(例えば、関数)を識別してよい。例外116が(開発者コード113Aの中の関数ではなく)API呼び出しから生じた場合には、分析部310は、認証が保証されないと決定してよい。分析部310は、ブラウザ122により要求されている特定の関数(例えば、例外116と共に返されたアクション指示206)を分析してもよい。認証が保証されない場合、分析部310は、アプリケーション112及び/又はブラウザ122へエラーメッセージを返してよい。しかしながら、認証が保証される場合、分析部310は、例外116をリダイレクト部320に渡してよい。
【0030】
リダイレクト部320は、幾つかの実施形態では、ユーザ認証の実行を生じるために、ウェブブラウザ122を認証サーバ140へリダイレクトするために実行可能なプログラム命令のセットである。上述のように、このリダイレクトは、例えば、認証サーバ140のアドレスと共に、HTTPリダイレクト状態コード(例えば、3XXコード)をブラウザ122へ送信することを含んでよい。種々の実施形態では、リダイレクト部320は、さらに、ブラウザ122がアプリケーション112へリターンするのを促進するために使用可能な種々の情報を収集するために実行可能である。幾つかの実施形態では、リダイレクト部320は、この情報を1つ以上のパラメータとして、認証リダイレクト126に含まれるURLに含める。例えば、ブラウザ122からのHTTP GET要求が例外116をトリガした場合、リダイレクト部320は、ブラウザ122が認証により返すべき場所を識別するリターンURL322を含んでよい。リターンURL322を受信することに応答して、認証サーバ140は、ブラウザ122をアプリケーション112に戻し及び最初のHTTP GET要求336を再生するために、リターンURL322を再生リダイレクト332に含めてよい。幾つかの実施形態では、リダイレクト部320は、代替として、再生情報324をデータベース130に格納し、情報324を後に読み出すために、URL内の情報識別し326を認証リダイレクト126に含めてよい。例えば、ブラウザ122からのHTTP POST要求が例外116をトリガした場合、リダイレクト部320は、後に読み出すために、HTTP POST要求の中で指定されたパラメータをデータベース130に格納してよい。幾つかの実施形態では、リダイレクト部320は、再生情報324を保護するために、さらに該情報を暗号化してよい。(データベース130はアプリケーションサーバ110と別個のものとして図1に示されるが、任意の適切な記憶装置が、サーバ110におけるローカルキャッシュのような再生情報124を格納するために使用されてよい)。
【0031】
再生支援部330は、幾つかの実施形態では、特定種類の例外の指示をスローさせる要求336を特定アプリケーションに戻すために実行可能なプログラム命令のセットである。図示の実施形態では、ハンドラ118の中に示されるが、支援部330は、アプリケーション112、認証サーバ140(例えば、再生リダイレクト332を発行するために)、等の中のような別の場所に存在してよい。再生支援部330の複数のインスタンスが使用されてもよい。図示の実施形態では、支援部330は、認証の実行に応答して、情報識別子326(これは、ブラウザ122によりリダイレクト要求の中で伝達されてよい)を認証サーバ140から受信する。識別子326を受信することに応答して、支援部330は、識別子326を使用して、前に格納された再生情報324をデータベース130から読み出し、再生リダイレクト334の中の情報324を提供して、アプリケーション112に戻るためにブラウザ122に適切なHTTP要求336を再生させてよい。
【0032】
図4Aを参照すると、例外処理を通じてユーザを認証する方法400のフローチャートが示される。一実施形態では、方法400は、アプリケーション112を実行するアプリケーションサーバ110のようなアプリケーションを実行するコンピューティングシステムにより実行される。
【0033】
ステップ405で、ソフトウェア開発プラットフォーム(例えば、プラットフォーム10)の例外ハンドラ(例えば、例外ハンドラ118)が維持され、例外ハンドラは、ソフトウェア開発プラットフォーム上で実行するアプリケーション(例えば、アプリケーション112)のユーザの認証を生じる特定種類の例外(例えば、例外116)を処理するために実行可能である。
【0034】
ステップ410で、特定アプリケーションによりスローされた特定種類の例外の指示は、例外ハンドラで受信される。
【0035】
ステップ415で、特定種類の例外の指示を受信することに応答して、例外ハンドラは、特定アプリケーションと相互作用するウェブブラウザ(例えば、ブラウザ122)へ、ウェブブラウザを特定アプリケーションのユーザの認証を実行するよう構成される認証サーバ(例えば、サーバ140)へリダイレクトする要求(例えば、要求126)を発行する。幾つかの実施形態では、発行された要求は、HTTPリダイレクト状態コードを含む。幾つかの実施形態では、認証は二要素認証である。幾つかの実施形態では、特定種類の例外の指示と共に受信されたスタックトレースは、分析され、スタックトレースは、特定種類の例外をスローしたアプリケーション関数の名称を識別する。分析に基づき、ウェブブラウザが認証サーバにリダイレクトする要求を発行するか否かを決定する。
【0036】
ステップ420で、実行された認証の結果(例えば、結果142)が、認証サーバから受信される。ステップ425で、結果が、特定アプリケーションに返される。幾つかの実施形態では、方法400は、認証に応答して、特定種類の例外の指示をスローさせた要求(例えば、要求336)を再生するよう(例えば、リダイレクト部334を介して)ウェブブラウザに指示することにより、ウェブブラウザを特定アプリケーションに戻すことを更に含む。幾つかの実施形態では、URL(uniform resource locator)は、ウェブブラウザに提供され、特定種類の例外の指示をスローさせた要求を再生するために使用可能な情報(例えば、リターンURL322、又は情報識別子326)を含む。幾つかの実施形態では、方法400は、データベースに、特定種類の例外の指示をスローさせた要求に関する情報(例えば、再生情報324)を格納するステップを含む。このような実施形態では、格納された情報は、特定種類の例外の指示をスローさせた要求を再生するために使用される。幾つかの実施形態では、方法400は、特定種類の例外の指示と共に受信されたスタックトレースを分析することにより、特定アプリケーションにおいて、ウェブブラウザを戻すべき場所を決定するステップを含み、スタックトレースは、特定種類の例外をスローしたアプリケーション関数の名称を識別する。
【0037】
図4Bを参照すると、例外処理を通じてユーザを認証する別の方法450のフローチャートが示される。一実施形態では、方法450は、認証サーバ140のような、ユーザ認証を実行するコンピューティングシステムにより実行される。
【0038】
方法は、ステップ455で開始し、ウェブブラウザ(例えば、ウェブブラウザ122)から、アプリケーションのユーザを認証するための要求を受信する。種々の実施形態では、要求は、アプリケーションが特定種類の例外(例えば、例外116)をスローすることに応答して、ウェブブラウザにより発行される。例外は、例外ハンドラ(例えば、例外ハンドラ118)に、ウェブブラウザをコンピューティングシステムへとリダイレクトさせる。ステップ460で、要求に応答して、認証ページがウェブブラウザに提供される。ステップ465で、認証ページを介して受信した入力(例えば、認証情報128)に基づき、ユーザの認証が実行される。ステップ470で、ウェブブラウザは、(例えば、再生リダイレクト332を介して)アプリケーションにリダイレクトされる。種々の実施形態では、リダイレクトするステップは、ウェブブラウザに、特定種類の例外をスローさせたアプリケーションへ要求を再生するためにウェブブラウザにより使用可能な情報を提供するステップを含む。幾つかの実施形態では、ウェブブラウザに提供される情報は、認証するために受信した要求の中のURLに含まれる値(例えば、情報識別子326)に基づき決定されル。幾つかの実施形態では、再生された要求は、提供された情報に対応する1つ以上のパラメータを含むHTTP POST要求(例えば、要求336)である。一実施形態では、値は、データベース(例えば、データベース130)から1つ以上のパラメータを取得するために使用可能である。
【0039】
<例示的なコンピュータシステム>
図5を参照すると、例示的なコンピュータシステム500のブロック図が示され、プラットフォーム10(例えば、サーバ110、装置120、データベース130、又はサーバ140)の機能を実装してよい。コンピュータシステム500は、相互接続560(例えば、システムバス)を介してシステムメモリ520及びI/Oインタフェース540に結合されるプロセッササブシステム580を含む。I/Oインタフェース540は、1つ以上の装置550に結合される。コンピュータシステム500は、限定ではないが、サーバシステム、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ又はノードブックコンピュータ、メインフレームコンピュータシステム、タブレットコンピュータ、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、携帯電話機、音楽プレイヤ又はPDA(personal data assistant)のような消費者装置を含む、種々の種類の装置のうちのいずれであってもよい。便宜上単一のコンピュータシステム500が図5に示されるが、システム500は、一緒に動作する2つ以上のコンピュータシステムとして実装されてもよい。
【0040】
プロセッササブシステム580は、1つ以上のプロセッサ又は処理ユニットを含んでよい。コンピュータシステム500の種々の実施形態では、プロセッササブシステム580の複数のインスタンスが相互接続560に結合されてよい。種々の実施形態では、プロセッササブシステム580(又は580内の各処理ユニット)は、キャッシュ又は他の形式のオンボードメモリを含んでよい。一実施形態では、プロセッササブシステム580は、上述のプロセッサ102を含んでよい。
【0041】
システムメモリ520は、プロセッササブシステム580により実行可能なプログラム命令を格納し、システム500に本願明細書に記載の種々の動作を実行させるために使用可能である。システムメモリ520は、異なる物理メモリ媒体、例えばハードディスク記憶装置、フロッピーディスク記憶装置、取り外し可能ディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ(RAM、SRAM、EDO RAM、SDRAM、DDR、SDRAM、RAMBUS RAM、等)、読み出し専用メモリ(PROM、EEPROM、等)、等を用いて実装されてよい。コンピュータシステム500内のメモリは、メモリ520のような主記憶装置に限定されない。むしろ、コンピュータシステム500は、プロセッササブシステム580内のキャッシュメモリ及びI/O装置550内の2次記憶装置(例えば、ハードドライブ、ストレージアレイ、等)のような他の形式の記憶装置を含んでもよい。幾つかの実施形態では、これらの他の形式の記憶装置は、プロセッササブシステム580により実行可能なプログラム命令を格納してもよい。幾つかの実施形態では、上述のプリケーション112は、システムメモリ520内に格納されたプログラム命令であってよい。
【0042】
I/Oインタフェース540は、種々の実施形態に従い他の装置と結合され通信するよう構成される種々の種類のインタフェースのうちのいずれであってもよい。一実施形態では、I/Oインタフェース540は、フロントサイドから1つ以上のバックサイドバスへのブリッジチップ(例えば、Southbrigdge)である。I/Oインタフェース540は、1つ以上の対応するバス又は他のインタフェースを介して1つ以上のI/O装置550に結合されてよい。I/O装置550の例は、記憶装置(ハードドライブ、光ドライブ、取り外し可能フラッシュドライブ、記憶アレイ、SAN、又はそれらの関連する制御部)、(例えば、ローカル又はワイドエリアネットワークへの)ネットワークインタフェース装置、又は他の装置(例えば、グラフィック、ユーザインタフェース装置、等)を含む。一実施形態では、コンピュータシステム500は、(例えば、WiFi、Bluetooth、Ethernet、等を介して通信するよう構成される)ネットワークインタフェース550を介してネットワークに結合される。
【0043】
特定の実施形態が上述されたが、これらの実施形態は、単一の実施形態のみが特定の特徴に関して記載されたとしても、本開示の範囲を限定することを意図しない。本開示で提供される特徴の例は、特に断りの無い限り、限定ではなく説明を意図している。上述の説明は、本開示の利益を享受する当業者に明らかなように、このような代替、変更、及び均等物をカバーすることを意図している。
【0044】
本開示の範囲は、本願明細書で解決される問題のうちのいずれか又は全部を軽減するか否かにかかわらず、本願明細書に開示した任意の特徴又は特徴の結合(明示的又は暗示的のいずれも)、又はそれらの任意の一般化を含む。従って、新規な請求項が、任意のこのような特徴の組み合わせに対して、本願(又は本願に基づく優先権を主張する出願)の審査中に形成され得る。特に、添付の請求項を参照して、従属請求項による特徴は、独立請求項の特徴と結合されてよく、それぞれの独立請求項の特徴は、添付の請求の範囲に列挙されない特定の組み合わせではなく、任意の適切な方法で結合されてよい。
図1
図2
図3
図4A
図4B
図5