(57)【要約】【課題】  第三者のセキュア・サービスを集約するワークフローのためのセキュリティ・モデルのための方法、システム、およびコンピュータ・プログラムを提供する。【解決手段】  一実施形態では、ワークフロー言語で記述されたワークフロー・モデルが提供され、２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。方法は、少なくとも１つのセキュア・サーバ・コンピュータ上で実行する認証サービスを提供することも組み込む。認証サービスは、ワークフロー言語に従って少なくとも１つのホスト・サーバ・コンピュータ上で実行している複合アプリケーションに代わって、外部ネットワーク・リソースで保護されたデータにアクセスするために、ユーザの認証および認可を実施するように構成される。【選択図】  図１
2013538380.tif 000002
【特許請求の範囲】
【請求項１】
データにアクセスするための方法であって、
ワークフロー言語で記述され、２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフロー・モデルを受取ることであって、前記複合アプリケーションは、前記ワークフロー・モデルに従って少なくとも１つのホスト・サーバ・コンピュータ上で実行される、前記受取ること、および
少なくとも１つのセキュア・サーバ・コンピュータ上で認証サービスを実行することであって、前記認証サービスは、前記複合アプリケーションのために、前記外部ネットワーク・リソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実施するように構成される、前記実行すること、
を含む、データにアクセスするための方法。
【請求項２】
前記サーバ・コンピュータは、前記ユーザによって信頼されたエンティティによって制御される、請求項１に記載のデータにアクセスするための方法。
【請求項３】
前記ワークフロー言語は拡張可能ワークフロー言語である、請求項１に記載のデータにアクセスするための方法。
【請求項４】
前記２つまたはそれ以上の外部ネットワーク・リソースのうちの１つに関するプロトコル情報を取り出すことをさらに含む、請求項１に記載のデータにアクセスするための方法。
【請求項５】
前記複合アプリケーションから前記認証サービスに接続することをさらに含む、請求項１に記載のデータにアクセスするための方法。
【請求項６】
前記認証サービスから前記２つまたはそれ以上の外部ネットワーク・リソースのうちの１つに接続することをさらに含む、請求項１に記載のデータにアクセスするための方法。
【請求項７】
前記認証サービスによってユーザ証明を取得すること、および
前記外部ネットワーク・リソースで前記保護されたデータにアクセスするために、前記ユーザの認証および認可を実施するための前記ユーザ証明を使用すること、
をさらに含む、請求項１に記載のデータにアクセスするための方法。
【請求項８】
データにアクセスするためのシステムであって、
２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフロー言語で記述されたワークフロー・モデルであって、前記複合アプリケーションは、前記ワークフロー言語に従って少なくとも１つのホスト・サーバ・コンピュータ上で実行する、ワークフロー・モデルと、
少なくとも１つのセキュア・サーバ・コンピュータ上で実行する認証サービスであって、前記複合アプリケーションのために、前記外部ネットワーク・リソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実施するように構成される、認証サービスと、
を備える、データにアクセスするためのシステム。
【請求項９】
ユーザ証明は、前記認証サービス上に記憶される、請求項８に記載のデータにアクセスするためのシステム。
【請求項１０】
前記複合アプリケーションは、
前記認証サービスと通信するための少なくとも１つのセキュリティ・ハンドラであって、前記セキュリティ・ハンドラは、セキュリティ・プロトコルを使用して前記認証サービスと通信するように構成される、少なくとも１つのセキュリティ・ハンドラと、
前記ワークフロー・モデルのワークフロー・インスタンスと、
をさらに備える、請求項８に記載のデータにアクセスするためのシステム。
【請求項１１】
前記セキュリティ・プロトコルはＯＡｕｔｈである、請求項１０に記載のデータにアクセスするためのシステム。
【請求項１２】
前記セキュリティ・プロトコルはＨＴＴＰ  Ｂａｓｉｃ認証である、請求項１０に記載のデータにアクセスするためのシステム。
【請求項１３】
前記ワークフロー・インスタンスは、前記複合アプリケーションが前記認証サービスと通信する場合、その実行の状態を維持する、請求項１０に記載のデータにアクセスするためのシステム。
【請求項１４】
前記認証サービスを介して取得されたユーザ証明のセットは、前記ワークフロー・インスタンス中に使用するために前記セキュリティ・ハンドラ内に記憶される、請求項１０に記載のデータにアクセスするためのシステム。
【請求項１５】
具体化されたコンピュータ読み取り可能プログラム・コードを有するコンピュータ読み取り可能記憶媒体を備え、前記コンピュータ読み取り可能プログラム・コードは、
２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフロー言語で記述されたワークフロー・モデルを受取ること、および
前記ワークフロー言語に従って前記複合アプリケーションのために、前記外部ネットワーク・リソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実行する旨の要求を、少なくとも１つのセキュア・サーバ・コンピュータ上で実行する認証サービスに対して発行すること、
を、実行するように構成される、コンピュータ・プログラム。
【請求項１６】
前記認証サービスに対する前記要求は、証明を要求するために、ユーザを前記複合アプリケーションから前記認証サービスへとリダイレクトする、請求項１５に記載のコンピュータ・プログラム。
【請求項１７】
前記コンピュータ読み取り可能プログラム・コードは、非同期メッセージング・サービスを介してユーザに接触するようにさらに構成される、請求項１５に記載のコンピュータ・プログラム。
【請求項１８】
前記非同期メッセージング・サービスは電子メールである、請求項１７に記載のコンピュータ・プログラム。
【請求項１９】
前記非同期メッセージング・サービスはインスタント・メッセージング・サービスである、請求項１７に記載のコンピュータ・プログラム。
【請求項２０】
前記コンピュータ読み取り可能プログラム・コードは、前記認証サービスから保護されたデータを受信するようにさらに構成される、請求項１５に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に記載された様々な実施形態は、一般にシステムに関し、より具体的には、第三者のセキュア・サービスを集約するワークフローのためのセキュリティ・モデルに関する。
【背景技術】
【０００２】
マッシュアップとは、異質なウェブ・ソースからのコンテンツ、提示、およびアプリケーション機能を組み合わせて、新しいウェブ・アプリケーションを作成する方法のことである。これらには、ＲＥＳＴまたはＳＯＡＰサービス、フィード（ＲＳＳまたはＡＴＯＭ）、あるいはプレーンなＸＭＬまたはＨＴＭＬソースなどの、いくつかのサービスおよびソースをまとめて「マッシュ」することが含まれる。
【０００３】
現時点では、コンシューマ・マッシュアップおよびエンタープライズ・マッシュアップという、２つの異なるタイプのマッシュアップが有力である。コンシューマ・マッシュアップはほとんどが私用であり、いくつかのリソースからのデータを共通のインターフェースを使用して一本化することによって組み合わせる。エンタープライズ・マッシュアップは、企業環境において、少なくとも１つのリソースからの異なるソースを組み合わせる。エンタープライズ・マッシュアップは、開発コストを削減するための開発、および、より短期間での新しいソリューションの提供を介して、アセンブリを促進することによる、非常に大きな可能性を有する。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ｆｒａｎｃｉｓｃｏ  Ｃｕｒｂｅｒａ、Ｍａｔｔｈｅｗ  Ｄｕｆｔｌｅｒ、Ｒａｎｉａ  Ｋｈａｌａｆ、Ｄｏｕｇｌａｓ  Ｌｏｖｅｌｌによる、２００７年９月１７〜２０日、オーストリア、ウィーンでの、Ｂｉｔｅ：Ｗｏｒｋｆｌｏｗ  Ｃｏｍｐｏｓｉｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ｗｅｂ，  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  （ＩＣＳＯＣ  ２００７）、Ｓｐｒｉｎｇｅｒ  ＬＮＣＳ
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の例示的実施形態は、データにアクセスするための方法である。この方法は、ワークフロー言語で記述されたワークフロー・モデルを受信することを含む。ワークフロー・モデルは、２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。この方法は、少なくとも１つのセキュア・サーバ・コンピュータ上で認証サービスを実行すること組み込む。認証サービスは、ワークフロー言語に従って少なくとも１つのホスト・サーバ・コンピュータ上で実行している複合アプリケーションに代わって、外部ネットワーク・リソースで保護されたデータにアクセスするために、ユーザの認証および認可を実施するように構成される。
【課題を解決するための手段】
【０００６】
本発明の他の例示的実施形態は、データにアクセスするためのシステムを含む。このシステムは、ワークフロー言語で記述されたワークフロー・モデルを含む。ワークフロー・モデルは、２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。このシステムは、少なくとも１つのセキュア・サーバ・コンピュータ上で実行する認証サービスも含む。認証サービスは、ワークフロー言語に従って少なくとも１つのホスト・サーバ・コンピュータ上で実行している複合アプリケーションに代わって、外部ネットワーク・リソースで保護されたデータにアクセスするために、ユーザの認証および認可を実施するように構成される。
【０００７】
本発明のさらに他の例示的実施形態は、データにアクセスするためのコンピュータ・プログラム製品である。このコンピュータ・プログラム製品は、ワークフロー言語で記述されたワークフロー・モデルを受信することを含む。ワークフロー・モデルは、２つまたはそれ以上の外部ネットワーク・リソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。コンピュータ・プログラム製品は、ワークフロー言語に従って複合アプリケーションに代わって外部ネットワーク・リソースで保護されたデータにアクセスするために、ユーザの認証および認可を実行する旨の要求を、少なくとも１つのセキュア・サーバ・コンピュータ上で実行する認証サービスに対して発行するように構成されたコードも含む。
【０００８】
本発明に関する主題は、本明細書の末尾の特許請求の範囲で、具体的に指摘および明確に請求されている。本発明の前述および他の目的、特徴、および利点は、添付の図面に関連した以下の詳細な説明から明らかとなろう。
【図面の簡単な説明】
【０００９】
【図１】本発明によって企図される、データにアクセスするためのシステム例を示す図である。
【図２】本発明によって企図される、データにアクセスするための方法例を示す流れ図である。
【図３】本発明によって企図される、データにアクセスするためのシステムおよび方法の使用のシナリオ例を示す図である。
【図４】図３のシナリオ例からのワークフロー・モデルのリスト例を示す図である。
【図５】図３に示される本発明の例示的実施形態を実装する、セキュリティ・ソリューションの概要を示す図である。
【図６】例示的セキュリティ拡張要素の図３のシナリオ例からのワークフロー・モデルのリスト例を示す図である。
【図７】図３のシナリオ例からの、セキュア認可サービスへリダイレクトされた場合の、ユーザのブラウザのウェブ・ページの例を示す図である。
【図８】図３のシナリオ例からの、ユーザのブラウザの認可ウェブ・ページの例を示す図である。
【発明を実施するための形態】
【００１０】
本発明について、本発明の実施形態を参照しながら説明する。本発明の説明全体にわたって、図１〜図８が参照される。
【００１１】
本発明の態様は、第三者のセキュア・サービスを集約するマッシュアップのためのセキュリティ・モデルに関する。現行のエンタープライズ・マッシュアップ・ツールには、認証および認可に関してまったく異なるセキュリティ要件を有する場合に、セキュアな方法でマッシュアップにおいて異なるサービスを消費および統合する機能が欠如している。したがって、多くのマッシュアップ・ツールは、セキュリティなしのサービスおよびデータ・ソースまたはハードコード認証データのみを統合することができる。ユーザは自分の認証情報を第三者に提供したがらず（実際、企業ポリシーがそれを禁止している場合さえある）、リソースは、通常、カスタム・セキュリティ要件を有するため、これは企業環境において問題である。さらに、集約されたセキュア・サービスは、異なるプロトコルを介して異なるユーザから異なる証明（ｃｒｅｄｅｎｔｉａｌ）を必要とする。リソースは、ＨＴＴＰ  Ｂａｓｉｃ認証などのいくつかの認証プロトコル、カスタム・アプリケーション・キー、またはそれ以上のＯｐｅｎＩＤおよびＯＡｕｔｈなどのＷｅｂ  ２．０のようなプロトコルのうちのいずれかを、サポートすることができる。
【００１２】
本発明の実施形態は、ユーザがネットワーク上のセキュアおよび非セキュアの両方のリソースからのデータを集約することが可能な、エンタープライズ・マッシュアップに関するサポートを提供し、セキュアなリソースは、それぞれ潜在的に異なるセキュリティ・プロトコルを使用している。
【００１３】
図１は、本発明によって企図される、データにアクセスするためのシステム１００の例を示す。図に示されたシステム１００は、本発明の様々な配置構成のうちの単なる一例であり、本発明をいずれの特定の構成にも限定するものと解釈されるべきでないことを理解されたい。
【００１４】
一実施形態では、システム１００は、ホスト・サーバ・コンピュータ１０２およびセキュア・サーバ・コンピュータ１１０を含む。ホスト・サーバ・コンピュータ１０２上では、複合アプリケーション１０４が実行されている。ワークフロー言語で記述されたワークフロー・モデル１０６は、２つまたはそれ以上の外部リソース１１６により保護されたデータ１１８を統合する複合アプリケーション１０４の、セキュリティ要件を宣言するように構成される。したがってワークフローは、マッシュアップを提示／実体化および実行するための方法である。
【００１５】
ホスト・サーバ・コンピュータ１０２上で実行可能な複合アプリケーション１０４は、ワークフロー・モデル１０６を含むことができる。複合アプリケーション１０４は、ワークフロー言語を含むコンパイル済みまたはインタプリタ言語で作成可能である。ワークフロー言語は、ＢｉｔｅまたはＢｉｔｅ言語の拡張バージョンを含む、ＸＭＬベース言語を含むことが可能な、コンパイル済みまたはインタプリタ言語とすることができる。Ｂｉｔｅ言語に関する詳細な情報については、Ｆｒａｎｃｉｓｃｏ  Ｃｕｒｂｅｒａ、Ｍａｔｔｈｅｗ  Ｄｕｆｔｌｅｒ、Ｒａｎｉａ  Ｋｈａｌａｆ、Ｄｏｕｇｌａｓ  Ｌｏｖｅｌｌによる、２００７年９月１７〜２０日、オーストリア、ウィーンでの、Ｂｉｔｅ：Ｗｏｒｋｆｌｏｗ  Ｃｏｍｐｏｓｉｔｉｏｎ  ｆｏｒ  ｔｈｅ  Ｗｅｂ，  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｓｅｒｖｉｃｅ  Ｏｒｉｅｎｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  （ＩＣＳＯＣ  ２００７）、Ｓｐｒｉｎｇｅｒ  ＬＮＣＳを参照されたい。複合アプリケーション１０４の他の実施形態は、セキュリティ・ハンドラ１０８を含む。セキュリティ・ハンドラ１０８は、認証サービス１１２と対話する複合アプリケーション１０４におけるモジュールとすることができる。セキュリティ・ハンドラ１０８は、ターゲット・サービスで異なるセキュリティ・メカニズムに関するサポートを提供するために、ＯＡｕｔｈ、ＨＴＴＰ  Ｂａｓｉｃ認証、およびＡｐｐＩＤを含むがこれらに限定されない、いくつかの認証プロトコルを介して、認証サービス１１２と対話することができる。
【００１６】
本発明の実施形態では、複合アプリケーション１０４はワークフロー・モデル１０６の少なくとも１つのワークフロー・インスタンスを含む。ワークフローは、ワークフロー言語で作成可能である。本発明の実施形態では、ワークフロー・インスタンスは、複合アプリケーション１０４が認証サービス１１２と対話する間、その実行状態を維持する。
【００１７】
セキュア・サーバ１１０は、認証およびアクセス制御規則によって保護された信頼できる環境に配置されなければならない。セキュア・サーバ・コンピュータ１１０上では、認証サービス１１２が実行している。認証サービス１１２は、複合アプリケーション１０４に代わって、外部リソース１１６上で保護されたデータ１１８にアクセスするために、ユーザの認証および認可を実施するように構成される。外部リソース１１６は、セキュアまたは非セキュアのいずれかの外部コンピュータ上で使用可能な、任意のリソースを含む。保護されたデータ１１８は、ＲＳＳまたはＡｔｏｍなどのフィード、ＲＥＳＴまたはＳＯＡＰなどのサービス、ＨＴＭＬまたはＸＭＬソース、あるいは、画像または文書などのコンピュータ・アクセス可能ファイルを含む。
【００１８】
一実施形態では、ユーザ証明１１４は認証サービス１１２内に記憶される。ユーザ証明１１４は、パスワード、ユーザ名、または識別情報を記憶するトークンを含むことができる。
【００１９】
ホスト・サーバ・コンピュータ１０２は、ネットワーク１２０を介してセキュア・サーバ・コンピュータ１１０に接続される。ネットワーク１２０は、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、有線または無線あるいはその両方のネットワークを含む、当分野で知られた様々なタイプのネットワークのうちのいずれかとすることができる。ネットワーク１２０は、たとえば、ＴＣＰ／ＩＰ、Ｗｉ−Ｆｉ（Ｒ）、Ｂｌｕｅｔｏｏｔｈ（Ｒ）、ピコネット、トークン・リング、光およびマイクロ波を含むがこれらに限定されない、当分野で知られた様々な構成を使用することができる。Ｗｉ−Ｆｉはテキサス州オースティンにあるＷｉ−Ｆｉ  Ａｌｌｉａｎｃｅの登録商標である。Ｂｌｕｅｔｏｏｔｈはワシントン州ベルビューにあるＢｌｕｅｔｏｏｔｈ  ＳＩＧ，Ｉｎｃ．の登録商標である。
【００２０】
図２は、本発明によって企図される、データにアクセスするための方法の流れ図２００の例を示す。各ワークフロー・アクティビティは、セキュリティを必要とする場合に、動作２０４〜２１８を実行することができる。すなわちこれら動作は、ワークフロー・アクティビティがセキュリティ要素を含む場合で、外部アクセスを必要とする（アウトバウンドである）場合に、実行されても良い。データにアクセスするための方法はブロック２０２で開始され、２つまたはそれ以上の外部ネットワーク・リソースにより保護されたデータを統合する複合アプリケーションの、セキュリティ要件を宣言するために、ワークフロー言語を受取ることを含む。セキュリティ要件を宣言する際に、ワークフロー言語でセキュリティ拡張要素を使用しても良い。
【００２１】
ブロック２０４で、方法は、ワークフロー言語に従ってホスト・サーバ・コンピュータ上で実行している複合アプリケーションのために、外部ネットワーク・リソースで保護されたデータにアクセスし、ユーザの認証および認可を実施するための認証サービスを提供することを含む。
【００２２】
方法は、ブロック２０５で、複合アプリケーションから認証サービスに接続することを含む。これは、ＯＡｕｔｈプロトコルなどの共通セキュリティ・プロトコルを使用することによって実施可能である。
【００２３】
ＯＡｕｔｈは、ウェブベースのアプリケーションに関する、十分理解されますます普及してきたプロトコルであり、コンシューマとプロバイダとの間での認証および認可を処理するシームレスな方法を実装する。このシナリオでは、コンシューマはＢｉｔｅエンジンでありプロバイダはＳＡＳそれ自体である。ＯＡｕｔｈプロバイダは、（１）要求トークンＵＲＬ（相対ＵＲＬ／ｒｅｑｕｅｓｔ  ｔｏｋｅｎ）、（２）ユーザ認可ＵＲＬ（／ａｕｔｈｏｒｉｚｅ）、および（３）アクセス・トークンＵＲＬ（／ａｃｃｅｓｓ  ｔｏｋｅｎ）の、３つの異なる要求ＵＲＬを提供しなければならない。典型的なＯＡｕｔｈ認証および認可は、以下のように処理される。第１に、コンシューマは、コンシューマアプリケーション、タイムスタンプ、ナンス、署名などを識別するための事前に交渉されたコンシューマキーなどの、いくつかのＯＡｕｔｈ特有のパラメータを送信することによって、要求トークンＵＲＬ（１）を使用して要求トークンを要求する。すべてのパラメータが正しくかつ検証可能である場合、サービス・プロバイダは未認可の要求トークンを発行する。要求トークンがコンシューマによって受信された場合、ユーザのブラウザは、認証および認可を取得するためにサービス・プロバイダへリダイレクトすることができる。この認可により、ブラウザの背後にいるユーザは、コンシューマのウェブ・アプリケーションが、代理としてサービス・プロバイダのリソースへのアクセスを許可されたことを明示的に保証する。認可が実行されると、サービス・プロバイダは、（コールバックＵＲＬを使用して）ユーザをコンシューマアプリケーションへと再度リダイレクトすることができる。最後にコンシューマは、サービス・プロバイダ側で、アクセス・トークンに関する要求トークンを交換しなければならない。これは典型的には、ユーザが前のステップで認証および認可を正常に実行した場合に付与される。このアクセス・トークンは、あらゆる他の要求と共に、保護されたサービス（とりわけ、コンシューマキー、タイムスタンプ、署名など）へと送信されなければならない、ＯＡｕｔｈパラメータのうちの１つである。
【００２４】
方法は、ブロック２０６で、複合アプリケーションに代わって認証サービスに要求を発行することを含む。この要求は、複合アプリケーションが第三者リソース上で保持されているデータを必要とする場合に発行可能である。さらにこのデータは、保護可能である。要求は、複合アプリケーション内のセキュリティ・ハンドラ・モジュールを使用することによって発行可能である。
【００２５】
ブロック２０８で、方法は、２つまたはそれ以上の外部ネットワーク・リソースのうちの１つに関するプロトコル情報を取り出すことを含む。プロトコル情報は、外部リソースにプロトコル情報を要求すること、またはセキュリティ・ハンドラ・モジュールまたは認証サービス内にセキュリティ情報をハード・コーディングすることによって、取り出すことができる。
【００２６】
ブロック２１０で、方法は、証明を要求するために、ユーザを複合アプリケーションから認証サービスへとリダイレクトすることを含む。このステップは、プロトコルに応じて変化する。プロトコルがＨＴＴＰ  Ｂａｓｉｃ認証またはＡｐｐＩＤの場合、ＳＡＳはユーザ証明を収集するための書式を表示し、これらの証明をＳＡＳでセキュアに記憶する。第三者サービス用のプロトコルがＯＡｕｔｈである場合、ＳＡＳは第三者サービスを用いてＯＡｕｔｈプロトコルを実行し、ユーザはＳＡＳによって第三者サービスへとリダイレクトされることになるため、結果として、ユーザ証明は第三者サービスでのみ入力され、ＳＡＳに記憶されることはない。
【００２７】
ブロック２１０は、ユーザのブラウザを認証サービスのウェブ・ページにリダイレクトすることによって、現在複合アプリケーションと対話しているユーザをリダイレクトすることをさらに含むことができる。本発明の実施形態では、これは、ユーザが現在複合アプリケーションに接続されていない場合、非同期メッセージング・サービスを介してユーザに接触することによって実施可能である。非同期メッセージング・サービスは、たとえば、電子メール、インスタント・メッセージ、または携帯電話のテキスト・メッセージを含むことができる。
【００２８】
ＳＡＳのＯＡｕｔｈインターフェースを介して異なる第三者サービスのセキュアな認証および認可をトランスペアレントにサポートするためには、ＯＡｕｔｈプロトコルの拡張が必要である。これによって、ＳＡＳは、様々な他の認証プロトコルに関する「セキュア・プロキシ」として動作することができる。そのために、ＳＡＳは、少なくともターゲット・サービスのＵＲＬおよび認証タイプが必要である。この情報は、Ｂｉｔｅフロー中のアクティビティ指定およびセキュリティ拡張（たとえば、図４の１８〜２３行）で使用可能であるため、トランスペアレントな第三者サービス認証を実行可能にするために、ＳＡＳに送信するだけでよい。したがって、ＢｉｔｅエンジンがＳＡＳで要求トークンを要求した場合、いくつかの要求パラメータが追加される。
【００２９】
ブロック２１４で、方法は、認証サービスによってユーザ証明を取得することを含む。これは、証明を依頼するために、ユーザを第三者サービスへとリダイレクトすることによって実施可能である。しかしながら、前述のように、第三者サービス用のプロトコルがＯＡｕｔｈである場合、ＳＡＳは第三者サービスを用いてＯＡｕｔｈプロトコルを実行し、ユーザはＳＡＳによって第三者サービスへとリダイレクトされることになるため、結果として、ユーザ証明は第三者サービスでのみ入力され、ＳＡＳに記憶されることはない。
【００３０】
ブロック２１６で、方法は、認証サービスから２つまたはそれ以上の外部ネットワーク・リソースのうちの１つに接続することを提供する。認証サービスはユーザ証明を有することが可能であり、第三者リソースによって使用される特定のセキュリティ・プロトコルのメカニズムに従うことが可能である。加えて、ブロック２１８で、方法は、認証サービスから保護されたデータを受信することを含む。認証サービスは、データならびにセキュリティのための仲介として動作することができる。
【００３１】
図３は、本発明によって企図される、データにアクセスするためのシステムおよび方法の使用のシナリオ例を示す。エンタープライズ・マッシュアップ・シナリオは、問題および概念を示すために使用される。このシナリオでは、Ａｃｍｅ  Ｉｎｃの採用マネージャ（左）は、新規ポジションに対する採用を行っている。彼はエンタープライズ・マッシュアップを使用して、候補者（右下）との面接をスケジューリングし、その履歴書を入手する。そのためにマッシュアップは、第１に、Ｇｏｏｇｌｅカレンダを介して使用可能な採用マネージャのカレンダを呼び出す。次にこれが分岐する。下の分岐では、最初のコール
に返信し、上の分岐では、利用可能な時間をＡｃｍｅの面接スケジューリング・サービスにポストし、そのサービスによって戻された最終スロット、および、プロセスを完了するためにたどらなければならないリンクを、候補者に電子メールで送信する。候補者がリンクをクリックすると、自分の個人情報を記入して履歴書を添付する書式が表示される。最終的に、マッシュアップは、オンライン共同ソリューションであるＬｏｔｕｓＬｉｖｅ  Ｅｎｇａｇｅ内の「Ｆｉｌｅｓ」ファイル共有サービス内に、履歴書を配置する。
【００３２】
複数のセキュアな第三者サービスとの対話には、証明および認証プロトコルの様々なセットが必要である。たとえば、ＧｏｏｇｌｅカレンダはＯＡｕｔｈプロトコルを使用し、Ａｃｍｅのスケジューリング・サービスはＨＴＴＰ  Ｂａｓｉｃ認証を使用し、Ｆｉｌｅｓサービスは、アプリケーション・キーおよびファイルが追加されることになるストアのユーザを必要とする。Ｇｏｏｇｌｅカレンダの呼び出しおよびＦｉｌｅｓサービスの呼び出しには、どちらも、おそらくはユーザがもはやシステムにログインしていない場合に、マッシュアップがユーザに代わってそれらと対話することが必要である。
【００３３】
図４は、図３のシナリオ例からのワークフロー・モデルのリスト例である。ビジネス・マッシュアップ・プラットフォーム（ＢＭＰ）は、状況に応じたビジネス・プロセスまたはエンタープライズ・マッシュアップの迅速な開発のために、ホスト開発環境を提供する。グラフィカル・マッシュアップ環境は、ブラウザ・ベースであり、ＢＰＭＮスタイル・エディタを活用する、書式デザイナおよびパレット内のデザイナに提供される拡張アクティビティのカタログである。マッシュアップが完全に指定されると、ＢＭＰは、即時呼び出しが可能な、マッシュアップの１クリック展開が可能となる。バックエンドでは、Ｂｉｔｅコードが生成され、サーバ上で実行される。
【００３４】
Ｂｉｔｅは、軽量かつ拡張可能なワークフローの実装を容易にするように設計された、ＸＭＬベースのＲＥＳＴ中心の複合言語である。プロセス・モデルは、アトミック・アクション（アクティビティ）を含むフラット・グラフ（ｆｌａｔ  ｇｒａｐｈ）（ループを除く）からなり、それらをリンクする、ＷＳ−ＢＰＥＬ実行セマンティクスのサブセットを実装する。ループは、他のアクティビティを含むことができる唯一の構成である、専用のｗｈｉｌｅループ（ｗｈｉｌｅ  ｌｏｏｐ）・アクティビティを使用して作成することができる。グラフ実行論理は、アクティビティ間の条件付き移行リンク内に符号化される。エラー処理は、エラー処理アクティビティへの特別なエラー・リンクによって提供される。Ｂｉｔｅは、組み込みアクティビティの小セットである、（１）ＨＴＴＰ要求（ｒｅｃｅｉｖｅＧＥＴ｜ＰＯＳＴ、ｒｅｐｌｙＧＥＴ｜ＰＯＳＴ、ｒｅｃｅｉｖｅ−ｒｅｐｌｙＧＥＴ｜ＰＯＳＴ）を受信およびこれに返信するため、ならびに外部サービスに対してＨＴＴＰ要求（ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ）を実行するための、基本ＨＴＴＰ通信プリミティブ、（２）ローカル・コードを待機または呼び出すためのユーティリティ・アクティビティ、（３）外部選択およびループなどの制御ヘルパー、を提供する。
【００３５】
Ｂｉｔｅワークフローは、外部サービスを呼び出すこと、およびサービスとしてそれ自体を提供することの、両方を行う。ＨＴＴＰ  ＰＯＳＴ要求をワークフローの基本ＵＲＬに送信すると、結果として、新しいインスタンスＵＲＬに割り当てられる新しいワークフロー・インスタンスが作成される。このインスタンスＵＲＬは、応答のＨＴＴＰロケーション・ヘッダ・フィールドで戻される。インスタンスＵＲＬは、そのワークフローへの後続の要求の相関に使用される、ワークフローＩＤを含む。
【００３６】
各ワークフロー・インスタンスは、複数のエントリ・ポイントに対応する複数の受信アクティビティを定義することができる。これらのアクティビティは、インスタンスのネストされたリソースの論理アドレスとして、追加のＵＲＬを公開する。これらのＵＲＬに向けて送られるＰＯＳＴ要求は、アクティビティのＵＲＬ属性で定義された相対ＵＲＬを使用して、ワークフロー・モデル内の個々の受信アクティビティにディスパッチされる。このメカニズムによって、ワークフローと対話するための複数のエントリ・ポイントを有する対話型ワークフローを構築することができる。この挙動は、ビジネス・マッシュアップ・プラットフォーム（ＢＭＰ）によるマッシュアップ作成の一部として設計されるウェブ書式などの、様々なアクティビティによって活用される。
【００３７】
Ｂｉｔｅの概念は、Ｂｉｔｅ拡張アクティビティを作成し、それらをＢｉｔｅエンジンに登録することによって、開発者コミュニティが最上の様式で追加の機能を提供できるようにする、拡張可能設計である。この設計により、言語およびそのランタイムを非常に小規模に維持することが可能であり、開発者は他の必要なアクティビティを拡張として実装することができる。拡張アクティビティは、Ｊａｖａ  Ｓｃｒｉｐｔｉｎｇ  ＡＰＩ（たとえばＧｒｏｏｖｙ、Ｒｕｂｙ、Ｐｙｔｈｏｎなど）によってサポートされる、Ｊａｖａまたは任意のスクリプト言語を使用して作成可能である。
【００３８】
図４は、図３の採用サンプルに関する（省略された）Ｂｉｔｅコードを示す。各マッシュアップは、プロセスと呼ばれるルート要素を有する（第１行）。新しいワークフロー・インスタンスは、ＨＴＴＰ  ＰＯＳＴ要求を初期ｒｅｃｅｉｖｅＰＯＳＴの相対ＵＲＬ／採用に送信することによって作成される（第２行）。ＰＯＳＴ要求に関連付けられたデータは、すべての従属アクティビティに出力される変数ｈｒＩｎｐｕｔで暗黙的に使用可能である。この場合、変数はすべてのＰＯＳＴパラメータのマップを含む。ｈｒＩｎｐｕｔアクティビティが完了すると、ｇｃａｌアクティビティが起動される（第５〜１０行）。アクティビティ間の移行は、制御要素によって表される（第６行）。第１２〜１５行から、マッシュアップは、選択された面接日を伴う電子メールを受信することになる旨を通知する、採用マネージャからの初期のＨＴＴＰ  ＰＯＳＴに返信する。面接スケジューリングは、第１８〜２３行で、ＨＴＴＰ  ＰＯＳＴ呼び出しを発行することによって実行される。次に、たとえば、どちらもＢｉｔｅ拡張アクティビティとして実装される（簡潔にするためにリスト内には表示せず）、ｓｅｎｄＭａｉｌアクティビティを使用して電子メールを送信すること、および、書式アクティビティを使用して候補者書式を作成することなどの、他の残りのステップが実行される。最後に、ｓｈａｒｅＦｉｌｅ拡張アクティビティ（第２８〜３７行）が、収集された候補日をＬｏｔｕｓＬｉｖｅにアップロードする。
【００３９】
発信されるＨＴＴＰ  ＧＥＴおよびＰＯＳＴ呼び出し（ｇｃａｌおよびｓｃｈｅｄｕｌｅＩｎｔｅｒｖｉｅｗ）ならびにｓｈａｒｅＦｉｌｅアクティビティは、マッシュアップを正常に実行するために必要な異なるセキュリティ証明を必要とする。
【００４０】
図５は、図３に示される本発明の例示的実施形態を実装する、セキュリティ・ソリューションの概要である。以下で詳細に示すように、ＳＡＳは、複数のユーザがマッシュアップと対話できるようにし、マッシュアップが各ユーザに代わってサービスにアクセスできるようにする。
【００４１】
エンタープライズ・マッシュアップ・プラットフォームにセキュリティを提供するために、（ｉ）第三者サービスでのユーザの認証（すなわち、ユーザの請求された識別の検証）、および（ｉｉ）Ｂｉｔｅエンジンがユーザに代わってタスクを実行することをユーザが認可しなければならないという意味での認可に対処する。加えて、２つの態様が区別される。第１に、セキュリティ問題をＢｉｔｅ言語に統合するために、言語レベルでセキュリティに対処する。これは、言語拡張を最小限に維持し、シームレスなユーザ中心の方法で様々な認証プロトコルに関する拡張可能なサポートを提供するために、有利な可能性がある。第２に、拡張可能メカニズムは、異なる認証プロトコルを有する信頼されるサービスの認証および認可を実現するために有益である。このプロセスは、ＯＡｕｔｈインターフェースを提供するセキュア認証サービス（ＳＡＳ）によって、トランスペアレントに処理される。
【００４２】
図５では、セキュリティ・ソリューションの基本的概要が示される。実行可能ワークフローを含むＢｉｔｅエンジンが左側に示されている（図３の例の再アセンブリング）。白色のサービスは認証を必要としないサービスを構築し、灰色は認証を必要とする。中央は、企業ネットワークがワークフローの実行中に証明を管理する場合に、内部のセキュアな信頼される領域で動作しなければならないＳＡＳである。右側には、実行時に呼び出される第三者サービスが示されている。ＳＡＳを信頼される位置に配置するために有用である。いくつかのオプションは、第三者プロバイダまたは各サービス・プロバイダでのＳＡＳのいずれかを含む。エンタープライズ・マッシュアップに焦点が置かれているため、ＳＡＳは、ユーザとプロキシ・インフラストラクチャとの間の信頼に関する問題点を少なくする、企業自体によって提供されるサービスであることが可能である。
【００４３】
ユーザが、ウェブ書式の（または他のアプリケーションからの）ＨＴＴＰ  ＰＯＳＴ要求を使用することによって、ワークフローの実行をトリガした場合、マッシュアップが実行され、第１の「セキュアな」第三者サービス（図４のｇｃａｌアクティビティ）に到達するとすぐに、Ｂｉｔｅエンジンはセキュリティ・ハンドラを使用して、ユーザのターゲット・サービスでの認証を可能にする。ハンドラは、ＳＡＳと対話することによってこれを実行する。ＳＡＳは、ターゲット・サービスでの様々なセキュリティ・メカニズムのサポートを提供するために、ＯＡｕｔｈ、ＨＴＴＰ  Ｂａｓｉｃ認証、およびＡｐｐＩＤなどの、複数の異なるセキュリティ・モジュールへのプラグインを可能にする。認証および認可を実行するための手順には、同期認証および非同期認証の２つのケースがある。
【００４４】
同期認証：このケースでは、ユーザはすでにウェブ・アプリケーションを介してワークフローと対話しているため、単にＳＡＳにリダイレクトすることで、ターゲット・サービスでの認証を実行することができる。ワークフローにおいて、これは、ｒｅｃｅｉｖｅＧＥＴ｜ＰＯＳＴが、対応するｒｅｐｌｙＧＥＴ｜ＰＯＳＴアクティビティに到達することなく、処理されたことを意味する。たとえばこれは、ｒｅｃｅｉｖｅＰＯＳＴとｒｅｐｌｙＰＯＳＴとの間にある、図４（第５〜１０行）からのｇｃａｌアクティビティの場合である。
【００４５】
非同期認証：このケースでは、ｒｅｐｌｙＧＥＴ｜ＰＯＳＴアクティビティを実行することによって、ワークフローはすでにユーザに戻っている。別の方法として、ｒｅｃｅｉｖｅ−ｒｅｐｌｙＧＥＴ｜ＰＯＳＴと呼ばれるアクティビティを使用して、着信要求の受信および即時返信が実行される。したがってユーザは、もはやワークフローと対話しておらず、ＳＡＳにリダイレクト可能な接続は存在しない。たとえば、図４の第１８行以降のすべてのアクティビティ（すなわち、ｓｃｈｅｄｕｌｅＩｎｔｅｒｖｉｅｗ、ｅｍａｉｌＣａｎｄｉｄａｔｅ、ｃｏｌｌｅｃｔＣａｎｄｉｄａｔｅＤａｔａ、およびｓｔｏｒｅＡｐｐｌｉｃａｔｉｏｎ）である。可能な解決策は、非同期技法を使用してユーザに接触し、第三者サービスで認証するように要求することである。これは、電子メールおよびインスタント・メッセージングを介して達成可能である。
【００４６】
ＢｉｔｅエンジンとＳＡＳとの間の通信は、ＯＡｕｔｈプロトコルのやや拡張されたバージョンを使用して、ウェブ・アプリケーション（当方のケースでは、ＢｉｔｅエンジンおよびＳＡＳ）間の認証および認可の処理をシームレスに実施する。
【００４７】
図６は、例示的セキュリティ拡張要素の図３のシナリオ例からのワークフロー・モデルのリスト例である。Ｂｉｔｅ内でのセキュリティを可能にするために、言語を拡張して、認証および認可などのセキュリティ要件を捕捉することができる。目標は、こうした言語拡張を最小限に維持することであってよい。マッシュアップの実行を希望するユーザの認証および認可は、インバウンド・セキュリティと呼ばれる。すなわち、インバウンド・セキュリティは、メッセージがマッシュアップに送信されるケースである（すなわち、このケースではマッシュアップはセキュア・サービスである）。インバウンド・セキュリティは、ランタイム・レベルで実行され、それによってユーザは、ＯｐｅｎＩＤ、または外部認証サービスを伴う同様のプロトコルを使用して認証し、認証されたユーザは、受信アクティビティ（ｒｅｃｅｉｖｅＧＥＴ−ＰＯＳＴ）に関するユーザの制約に照らしてチェック可能なプロセス・コンテキストに注入される。ユーザが受信にアクセス可能な場合、アクティビティが起動し、メッセージおよびユーザ情報を適切な変数内に記憶して、完了する。アクセス可能でない場合、エラーがユーザに返信され、受信アクティビティは起動されない。ユーザと対話するすべてのアクティビティに関するユーザ情報は、提供される場合、ランタイム時に暗黙変数［ａｃｔｉｖｉｔｙ  ｎａｍｅ］Ｕｓｅｒ内に記憶されることに留意されたい。したがって後続のアクティビティは、この変数を使用して、特定のユーザを逆に参照する。
【００４８】
セキュリティの特徴およびアクティビティの要件を定義するために、セキュリティ拡張要素が提供され、ＧＥＴ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、および、認証も必要とする可能性のあるカスタム挙動を実装するすべての拡張アクティビティなどの、すべてのアウトバウンド通信アクティビティに対してオプションとされる。
【００４９】
図４は、ワークフロー内に３つのセキュリティ要素（第９、２２、および３１〜３６行）を有する。図６に、セキュリティ要素構文が提示されている。
【００５０】
属性記述：セキュリティ要素に使用可能な属性は以下の通りである。
【００５１】
ａｕｔｈｔｙｐｅ：ターゲット・サービスでユーザを認証するための認証タイプを指定する。ＯＡｕｔｈ、ＨＴＴＰ  Ｂａｓｉｃ認証、および、様々なサービス・プロバイダによって単一または複数のＧＥＴまたはＰＯＳＴパラメータの形で頻繁に使用されるカスタマイズされたアプリケーションＩＤが、サポートされる。これらの認証タイプの処理は、セキュア認証サービス（ＳＡＳ）によってトランスペアレントにサポートされる。
【００５２】
ｕｓｅｒ：その代理として特定のサービスが実行される、ユーザの名前を（文字列または式として）定義する。このｕｓｅｒ属性は、特に、「代理」セマンティクスをサポートする拡張アクティビティに関連する。たとえば、図４からの採用ワークフローは、ＬｏｔｕｓＬｉｖｅを使用してファイルのアップロードおよび共有を行う。このアプリケーションは、Ｂｉｔｅワークフロー内でｕｓｅｒ属性によって示される、文書を誰がアップロードしたかを明示的に定義することによって、「代理」セマンティクスをサポートする（このユーザ名は、その後、ＬｏｔｕｓＬｉｖｅのファイル共有サービスで、アップロードされた文書の所有者として使用される）。
【００５３】
ｒｏｌｅ：ユーザが有することのできる役割を、コンマで区切られた文字列の形で定義する。ｒｏｌｅが使用される場合、ｒｏｌｅ定義をランタイムに提供することができる。
【００５４】
ｎｏｔｉｆｉｃａｔｉｏｎ：ｎｏｔｉｆｉｃａｔｉｏｎは、サービスが認証を必要とする旨をどのようにユーザに通知すべきであるかを定義する。同期認証の場合、認証および認可を要求するためにＳＡＳにリダイレクトすることによって、ｈｔｔｐを使用することができる。非同期の場合、認証を要求するためにワークフローをユーザに戻さなければならない。これは、セキュリティを要求するアクティビティをブロックすること、ユーザに電子メールを送信すること（属性値ｅｍａｉｌ）、または、ユーザをＳＡＳに指示するインスタント・メッセージングを使用すること（属性値ｓａｍｅｔｉｍｅ）、および、認証／認可が完了した時点でアクティビティを再開することによって、実行することができる。手法の１つはＬｏｔｕｓ  Ｓａｍｅｔｉｍｅを使用し、他のプロトコルは容易に追加可能である。
【００５５】
ｎｏｔｉｆｉｃａｔｉｏｎＲｅｃｅｉｖｅｒ：この属性は、通知タイプの電子メールまたはｓａｍｅｔｉｍｅを使用する場合、連絡先の詳細（たとえば電子メール・アドレスまたはｓａｍｅｔｉｍｅ連絡先）を有する必要があるため、こうした場合にのみ必要である。ｈｔｔｐの場合、ユーザは依然としてブラウザ内でワークフローと対話しており、認証を実行するためにＳＡＳにリダイレクトされるため、これは不要である。
【００５６】
ｓｃｏｐｅ：ｓｃｏｐｅは、アクティビティのセキュリティ証明が、再使用のために他のアクティビティに伝搬されるかどうかを定義する。属性値がｗｏｒｋｆｌｏｗである場合、証明が伝搬され、これによって、同じユーザに関するワークフロー内で複数回呼び出されるサービスへの証明の再使用によるログインの反復が避けられる。属性値がａｃｔｉｖｉｔｙの場合、証明は伝搬されない。
【００５７】
Ｂｉｔｅ言語の実行セマンティクスに対するセキュリティ要素の効果は、以下の通りである。セキュリティ要素を有するアクティビティがワークフロー内に達すると、セキュリティ要素の属性の値が評価され、セキュリティ・コンテキストに記憶され、ワークフロー・インスタンスに関する実行の状態を維持するプロセス・コンテキストにそれ自体が記憶される。この情報を使用して、ハンドラ・レジストリ内の対応するセキュリティ・ハンドラがルックアップされる。セキュリティ・コンテキストおよびメッセージ・ペイロードが、必要な認証および認可を提供するためにＳＡＳと対話する、このハンドラに提供される。使用可能な証明がない場合、ハンドラは、それらをＳＡＳに送信しているユーザに接触する。その後、ハンドラはセキュアな呼び出しを実行して、その結果をアクティビティ実施に戻し、これをその出力変数内に記憶する。ｓｃｏｐｅ属性値がａｃｔｉｖｉｔｙに設定された場合、セキュリティ・ハンドラは、必要なセキュリティ処理を続行するために、そのＯＡｕｔｈインターフェースを介してＳＡＳに接触し、ＯＡｕｔｈ接続トークンは認証後に破棄される。ｗｏｒｋｆｌｏｗに設定された場合、これらのＯＡｕｔｈトークンはプロセス・コンテキストに記憶され、同じサービスが同じユーザに関するワークフロー内で再度呼び出される場合に、再使用することができる。ＳＡＳに接続するために同じＯＡｕｔｈトークンを再使用することで、代理として所与の第三者サービスを呼び出すために、ユーザが以前にＢｉｔｅを認証および認可したかどうかを判別することができる。
【００５８】
非同期のケースはこれ以上ワークフロー・セマンティクスに影響を与えないが、同期（ｈｔｔｐ）のケースは、証明が使用できない場合、ユーザに接触し、ユーザをＳＡＳにリダイレクトした後、ワークフローに戻るために、ワークフロー・インスタンスのオープン接続のうちの１つを再使用する必要があることから、より深く関与している。Ｂｉｔｅは、いくつかの受信アクティビティを同時にオープンに（すなわち、まだ返信されていない状態に）することができる。したがって、正しいオープン接続を識別しなければならない。そのために、ワークフロー・インスタンスにおけるオープンな受信アクティビティが、「ユーザ（Ｕｓｅｒ）」変数値と、処理されているセキュリティ要素内のものとの一致に関してチェックされる。一致する受信アクティビティの「返信状況（ｒｅｐｌｙ  ｓｔａｔｕｓ）」が「リダイレクト待機（ａｗａｉｔｉｎｇ  ｒｅｄｉｒｅｃｔ）」に設定され、ＳＡＳからワークフローへのリダイレクト・バックを一致させることが可能な、これに関するキーが作成される。返信は、ユーザをＳＡＳにリダイレクトする受信のオープン接続に送信される。ユーザがＳＡＳとの作業を完了すると、クライアント側のリダイレクトがユーザをワークフローに返送する。また、一致した受信アクティビティ・インスタンスがキーを使用して見つけられ、その返信状況が「オープン（ｏｐｅｎ）」にリセットされる。
【００５９】
オープンな受信間に一致が見つからない場合、「返信待機（ａｗａｉｔｉｎｇ  ｒｅｐｌｙ）」受信が、最終的に「オープン」になり、その時点で使用可能な場合にチェックされる。オープンまたはリダイレクト待機の受信間に一致が見つからない場合、非同期のケースで、接触情報がセキュリティ要素定義に提供されるのと同様に、ユーザに接触する。そうでない場合、障害が投じられる。
【００６０】
「リダイレクト待機」の受信に対する返信アクティビティは、受信の応答状況が再度「オープン」となり、他のセキュリティ・リダイレクトがその受信に対して保留中となるまで、待機しなければならず、その後その応答を送信することができる。
【００６１】
セキュア認証サービス（ＳＡＳ）は、様々な認証タイプの異なるセキュアなウェブベースの、たとえばＲＥＳＴｆｕｌサービスを、トランスペアレントに処理することが可能な、プロキシを提供する責務を負う。したがってＳＡＳは、異なるセキュリティ・メカニズムをサポートし、ＯＡｕｔｈインターフェース、ウェブベースのＡＰＩ間で認証および認可を管理するための普及プロトコルを使用して、それ自体を公開する。本明細書では、これを「ＯＡｕｔｈプロトコルは、ユーザが自分のサービス・プロバイダ証明をコンシューマに開示する必要なしに、ウェブサイトまたはアプリケーション（コンシューマ）が、ウェブ・サービス（サービス・プロバイダ）からＡＰＩを介して保護されたリソースにアクセスできるようにする」と定義する。
【００６２】
ＯＡｕｔｈは、ＳＡＳとの通信に関するプロトコルとして使用する場合に、以下のような２つの利点を有する。ＯＡｕｔｈは、ウェブベースのアプリケーションに関する十分理解されますます普及してきたプロトコルであり、コンシューマとプロバイダとの間での認証および認可を処理するシームレスな方法を実装する。このシナリオでは、コンシューマはＢｉｔｅエンジンでありプロバイダはＳＡＳそれ自体である。ＯＡｕｔｈプロバイダは、（１）要求トークンＵＲＬ（相対ＵＲＬ／ｒｅｑｕｅｓｔ  ｔｏｋｅｎ）、（２）ユーザ認可ＵＲＬ（／ａｕｔｈｏｒｉｚｅ）、および（３）アクセス・トークンＵＲＬ（／ａｃｃｅｓｓ  ｔｏｋｅｎ）の、３つの異なる要求ＵＲＬを提供しなければならない。典型的なＯＡｕｔｈ認証および認可は、以下のように処理される。第１に、コンシューマは、コンシューマアプリケーション、タイムスタンプ、ナンス、署名などを識別するための事前に交渉されたコンシューマキーなどの、いくつかのＯＡｕｔｈ特有のパラメータを送信することによって、要求トークンＵＲＬ（１）を使用して要求トークンを要求する。すべてのパラメータが正しくかつ検証可能である場合、サービス・プロバイダは未認可の要求トークンを発行する。要求トークンがコンシューマによって受信された場合、ユーザのブラウザは、認証および認可を取得するためにサービス・プロバイダへリダイレクトすることができる。この認可により、ブラウザの背後にいるユーザは、コンシューマのウェブ・アプリケーションが、代理としてサービス・プロバイダのリソースへのアクセスを許可されたことを明示的に保証する。認可が実行されると、サービス・プロバイダは、（コールバックＵＲＬを使用して）ユーザをコンシューマアプリケーションへと再度リダイレクトすることができる。最後にコンシューマは、サービス・プロバイダ側で、アクセス・トークンに関する要求トークンを交換しなければならない。これは典型的には、ユーザが前のステップで認証および認可を正常に実行した場合に付与される。このアクセス・トークンは、あらゆる他の要求と共に、保護されたサービス（とりわけ、コンシューマキー、タイムスタンプ、署名など）へと送信されなければならない、ＯＡｕｔｈパラメータのうちの１つである。
【００６３】
ＳＡＳのＯＡｕｔｈインターフェースを介して異なる第三者サービスのセキュアな認証および認可をトランスペアレントにサポートするためには、ＯＡｕｔｈプロトコルの拡張が必要である。これによってＳＡＳは、様々な他の認証プロトコルに対する「セキュア・プロキシ」として動作することができる。そのために、ＳＡＳは、少なくともターゲット・サービスのＵＲＬおよび認証タイプが必要である。この情報は、Ｂｉｔｅワークフローにおけるアクティビティ指定およびセキュリティ拡張（たとえば、図４の第１８〜２３行）で使用可能であるため、トランスペアレントな第三者サービスの認証を可能にするために、ＳＡＳに送信するだけでよい。したがって、以下で考察されるように、ＢｉｔｅエンジンがＳＡＳの要求トークンを要求する場合、いくつかの要求パラメータが追加される。
【００６４】
ＨＴＴＰ  Ｂａｓｉｃ認証は、ＳＳＬを使用しない限りそれほどセキュアではないが、実際には幅広く使用されている。これは、ＨＴＴＰ  Ｂａｓｉｃにａｕｔｈｔｙｐｅを設定することによって、指定可能である（たとえば、図４の第２２行）。ランタイム時に、Ｂｉｔｅエンジンは、以下の拡張ＯＡｕｔｈ要求を送信することによって要求トークンを要求することで、ＳＡＳに接触する。
【００６５】
【表１】
2013538380.tif 000003
【００６６】
パラメータｘ−ｏａｕｔｈ＿ｓｅｒｖｉｃｅｕｒｌおよびｘ−ｏａｕｔｈ＿ａｕｔｈｔｙｐｅは、図４からのｓｃｈｅｄｕｌｅＩｎｔｅｒｖｉｅｗアクティビティからの、セキュアな第三者サービスのターゲットＵＲＬおよびその認証タイプを示す（これはＨＴＴＰヘッダ拡張の共通パターンであるため、拡張はｘ−でプレフィックスされている）。同期認証のケースでは、ユーザはＳＡＳウェブ・インターフェースにリダイレクトされ、その他の場合（非同期のケースでは）、ｎｏｔｉｆｉｃａｔｉｏｎＲｅｃｅｉｖｅｒ属性に指定されたユーザＩＤは、認証に使用されるリンク（基本的に、同期のケースでＢｉｔｅのリダイレクト先と同じである）を受信する。
【００６７】
これらの２つの拡張属性は、ｉｆｒａｍｅにおけるターゲットＵＲＬへの発信呼び出しを実行するために、ＳＡＳによって使用される。これはユーザに、ターゲット・サービスの証明についてのプロンプトを発行する。認証が成功した場合、ターゲット・サービスのＨＴＴＰ認可ヘッダは、ＳＡＳのプロキシ・メカニズムによって遮断される。ＳＡＳでのトランスペアレントなプロキシを達成するために、単純なプロキシ・サーブレット（／ｐｒｏｘｙ）が使用される。ターゲット・サービスの応答はＳＡＳでキューに入れられ、そうでない場合、１回は認証用、１回は最初のサービス呼び出し用の２回、サービスを呼び出すことになる。最初の「実際の」サービス呼び出しが実行された場合、ＳＡＳは、認証プロセス中にキューに入れられた応答を戻すことになる。
【００６８】
カスタム・アプリケーションＩＤをサポートするには、ＳＡＳで動的にレンダリングされるウェブ書式においてアプリケーションＩＤがユーザからどのように照会されるか、および、このデータが（たとえば、ＨＴＴＰヘッダあるいはＧＥＴまたはＰＯＳＴパラメータ内で）どのようにターゲット・サービスに送信されるかに関する、詳細を符号化する、ｘ−ｏａｕｔｈ  ａｐｐｉｄマッピングと呼ばれる、他のＯＡｕｔｈ拡張パラメータを追加する必要がある。したがって、Ｂｉｔｅワークフロー内のセキュリティ拡張要素が、マッピング要素を定義する（図４、第３１〜３６行）。より具体的に言えば、このマッピングは、ターゲット・サービスが正常な認証に関して、（この拡張アクティビティは内部でＰＯＳＴを使用するため）ＨＴＴＰ  ＰＯＳＴパラメータとして追加する必要のある２つのパラメータ、ｐａｒおよびｋｅｙを有する旨を提示する。加えて、各要素は、動的にレンダリングされる認証書式において、ＨＴＭＬ入力要素に対してラベルとして使用されるｌａｂｅｌ属性を定義する。
【００６９】
こうしたアプリケーションＩＤベース・サービスの実行時に、Ｂｉｔｅエンジンは、前述のＯＡｕｔｈ拡張を使用してＳＡＳに転送される、単純なテキストベース書式へのＢｉｔｅ  ＸＭＬマッピングをシリアル化する。その後、アプリケーションＩＤに関するプロンプトを発行するために、動的にレンダリングされる認証書式が表示される。
【００７０】
ＯＡｕｔｈに関するサポートは、ＳＡＳによってもトランスペアレントにサポートされる。このケースでは、ＳＡＳは、いずれの情報も記憶することなく、Ｂｉｔｅとターゲット・サービス・プロバイダとの間の他の層のリダイレクトを追加するだけである。ＯＡｕｔｈベースのサービスを直接消費するために、（Ｂｉｔｅは、すでにＳＡＳに対するＯＡｕｔｈコンシューマであるため）カスタマイズされたセキュリティ・ハンドラを実装することが可能となる。しかしながら、ＯＡｕｔｈベースのサービスを消費する場合、ＳＡＳを経由することは、Ｂｉｔｅエンジンに対して複数のセキュリティ・メカニズムをトランスペアレントに処理する利点を有する。
【００７１】
ＢｉｔｅおよびＳＡＳは、Ｊａｖａ  １．６で実装されている。Ｂｉｔｅは、サーブレット・コンテナまたはＷｅｂＳｈｐｅｒｅ  ｓＭａｓｈサーバのいずれかで実行可能である。ＳＡＳの実装は、異なるエンドポイントに複数のサーブレットを提供する（要求トークン、アクセス・トークンなど）ＧｏｏｇｌｅのＪａｖａ  ＯＡｕｔｈ実装に基づく。これらのサーブレットは、前述のセキュリティ・プロトコルをトランスペアレントにサポートするように拡張されている。Ｂｉｔｅエンジンは、セキュリティ要素を用いてアクティビティからサービスを呼び出す際に、特定のセキュリティ・ハンドラを使用することによって（ＳＡＳＳｅｃｕｒｉｔｙＨａｎｄｌｅｒ）、ＯＡｕｔｈクライアントを実装する。他のすべての呼び出しは、ＳＡＳを含まないＮｕｌｌＳｅｃｕｒｉｔｙＨａｎｄｌｅｒを使用する。
【００７２】
図７は、図３のシナリオ例からの、ＳＡＳへリダイレクトされた場合の、ユーザのブラウザのウェブ・ページの例である。図８は、図３のシナリオ例からの、ユーザのブラウザの認可ウェブ・ページの例である。図７および図８は、カスタム・アプリケーションＩＤを「セキュリティ」メカニズムとして使用する、図４からのｓｈａｒｅＦｉｌｅアクティビティ（第２８〜３７行）に関する認証および認可のためのＳＡＳのウェブ・インターフェースを示す。図７は、Ｂｉｔｅでの指定に基づいて動的にレンダリングされる認証書式を示す。ユーザのブラウザがＳＡＳにリダイレクトされた場合、ユーザには、図に示されるようなウェブ・ページが示される。リンクをクリックすることで、認証ボックスがポップアップし、ユーザは証明を入力する。証明をサブミットした後、ユーザは、代理でサービスを呼び出すことをＢｉｔｅに明示的に認可しなければならない（図８）。ユーザがＢｉｔｅを認可した場合、ワークフローはその実行を続行し、ユーザはワークフロー・アプリケーションにリダイレクト・バックされ（同期のケースで）、認可しない場合、エラーが投じられる。ＨＴＴＰ  Ｂａｓｉｃ認証にも同じユーザ経験が使用可能であるが、ダイアログ・ボックスは動的にレンダリングされず、ブラウザ特有である。
【００７３】
ＳＡＳに基づく提案された手法は、（本発明のケースでのＢｉｔｅなどの）コンシューマアプリケーションに対する証明の開示の必要なしに、第三者サービスの認証および認可の両方を、効果的にサポートする。
【００７４】
当業者であれば理解されるように、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することができる。したがって、本発明の態様は、完全にハードウェア実施形態、完全にソフトウェア実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、あるいは、本明細書ではすべてが全体として「回路」、「モジュール」、または「システム」と呼ばれることのあるソフトウェアおよびハードウェアの態様を組み合わせた実施形態の、形を取ることができる。さらに、本発明の態様は、その上に具体化されたコンピュータ読み取り可能プログラム・コードを有する、１つまたは複数のコンピュータ読み取り可能媒体内で具体化される、コンピュータ・プログラム製品の形を取ることができる。
【００７５】
１つまたは複数のコンピュータ読み取り可能媒体の任意の組み合わせを使用することができる。コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体またはコンピュータ読み取り可能記憶媒体とすることができる。コンピュータ読み取り可能記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、あるいはそれらの任意の好適な組み合わせとすることができるが、これらに限定されるものではない。コンピュータ読み取り可能記憶媒体のより具体的な例（非網羅的リスト）は、１本または複数本のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、あるいは、それらの任意の好適な組み合わせを含むものである。本書との関連において、コンピュータ読み取り可能記憶媒体は、命令実行のシステム、装置、またはデバイスによって、あるいはそれらと関連して使用するためのプログラムを、含むかまたは記憶することが可能な、任意の有形媒体とすることができる。
【００７６】
コンピュータ読み取り可能信号媒体は、たとえば、ベースバンド内、または搬送波の一部として、内部にコンピュータ読み取り可能プログラム・コードが具体化された、伝搬データ信号を含むことができる。こうした伝搬信号は、電磁、光、またはそれらの任意の好適な組み合わせを含むが、これらに限定されない、多様な形のうちのいずれかを取ることができる。コンピュータ読み取り可能信号媒体は、コンピュータ読み取り可能記憶媒体でなく、命令実行のシステム、装置、またはデバイスによって、あるいはそれらと関連して使用するためのプログラムを、通信、伝搬、または移送することが可能な、任意のコンピュータ読み取り可能媒体とすることができる。
【００７７】
コンピュータ読み取り可能媒体上に具体化されるプログラム・コードは、ワイヤレス、ワイヤライン、光ファイバ・ケーブル、ＲＦなど、またはそれらの任意の好適な組み合わせを含むが、それらに限定されない、任意の適切な媒体を使用して伝送可能である。
【００７８】
本発明の態様に関する動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などの、オブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語または同様のプログラミング言語などの、従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成可能である。プログラム・コードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン型ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上および部分的にリモート・コンピュータ上で、あるいは、完全にリモート・コンピュータまたはサーバ上で、実行可能である。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意のタイプのネットワークを介して、ユーザのコンピュータに接続することができるか、あるいは、（たとえば、インターネット・サービス・プロバイダを使用し、インターネットを介して）外部コンピュータに接続することができる。
【００７９】
本発明の態様について、本発明の実施形態に従った方法、装置（システム）、およびコンピュータ・プログラム製品の、流れ図またはブロック図あるいはその両方を参照しながら、以下で説明する。流れ図またはブロック図あるいはその両方の各ブロック、および、流れ図またはブロック図あるいはその両方におけるブロックの組み合わせは、コンピュータ・プログラム命令によって実装可能であることを理解されよう。これらのコンピュータ・プログラム命令は、機械を製造するために、汎用コンピュータ、特定用途向けコンピュータ、または他のプログラマブル・データ処理装置のプロセッサに提供可能であり、結果として、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行する命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するための手段を作成する。
【００８０】
これらのコンピュータ・プログラム命令は、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスに対して、特定の様式で機能するように命じることが可能な、コンピュータ読み取り可能媒体内に記憶することも可能であり、結果として、コンピュータ読み取り可能媒体内に記憶された命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装する命令を含む製品を製造する。
【００８１】
コンピュータ・プログラム命令は、コンピュータ実装プロセスを生成するために、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上で一連の動作ステップを実行させるように、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードすることも可能であり、結果として、コンピュータまたは他のプログラマブル装置上で実行する命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するためのプロセスを提供する。
【００８２】
図面内の流れ図およびブロック図は、本発明の様々な実施形態に従ったシステム、方法、およびコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能、および動作を図示している。この点において、流れ図またはブロック図内の各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。いくつかの代替の実装では、ブロック内に記載された機能は、図面内に示された順序以外で発生可能であることにも留意されたい。たとえば、連続して示された２つのブロックは、実際にはほぼ同時に実行可能であるか、またはブロックは、関連する機能に応じて時には逆の順序で実行可能である。ブロック図または流れ図あるいはその両方の各ブロック、および、ブロック図または流れ図あるいはその両方におけるブロックの組み合わせは、指定された機能または動作、あるいは特定用途向けハードウェアおよびコンピュータ命令の組み合わせを実行する、特定用途向けハードウェアベースのシステムによって実装可能であることにも留意されよう。
【００８３】
以上、本発明の好ましい実施形態について説明してきたが、当業者であれば、現在および将来のどちらにおいても、以下の特許請求の範囲の範囲内に入る様々な改良および機能強化を実行可能であることを理解されよう。したがって、特許請求の範囲は、最初に説明された本発明に関する適切な保護を維持するものと解釈されたい。
【図１】
2013538380.tif 000004
【図２】
2013538380.tif 000005
【図３】
2013538380.tif 000006
【図４】
2013538380.tif 000007
【図５】
2013538380.tif 000008
【図６】
2013538380.tif 000009
【図７】
2013538380.tif 000010
【図８】
2013538380.tif 000011
2013538380.tif 000012
2013538380.tif 000013
2013538380.tif 000014
2013538380.tif 000015
2013538380.tif 000016
2013538380.tif 000017
2013538380.tif 000018
2013538380.tif 000019
【国際調査報告】
2013538380.tif 000020