JP6609086B1 - フェデレーテッド・シングル・サインオン（ｓｓｏ）のための非侵入型セキュリティの実施 - Google Patents

Abstract

【解決手段】サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入的にセキュリティを実行すること、ユーザがＳＰにログインするときに生成されるアサーションを転送するために、ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬに代えて、プロキシＵＲＬを使用するようにＩＤＰを構成すること、アサーションをＳＰに転送するためにＳＰのＡＣＳ−ＵＲＬを使用するように、プロキシＵＲＬにおいてアサーション・プロキシを構成すること、アサーションをＳＰのＡＣＳ−ＵＲＬに転送することによって、ユーザのクライアントとＳＰのＡＣＳの間にアサーション・プロキシを挿入し、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）の認証されたセッションを確立することに関する。【選択図】 図１

Description

他の出願の相互参照

本出願は、２０１６年１１月４日出願の「クラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ）のための非侵入型セキュリティの実施」と題する米国仮特許出願第６２／４１７，９３９号（代理人事件整理番号：ＮＳＫＯ １００６−１）に対する優先権及びその利益を主張する。該優先仮出願は、すべての目的のために参照により組み込まれる。

本出願は、２０１７年１０月２７日出願の「フェデレーテッド・シングル・サインオン（ＳＳＯ）のための非侵入型セキュリティの実施」と題する米国特許出願第１５／７９５，９５７号（代理人事件整理番号：ＮＳＫＯ １００６−２）に対する優先権及びその利益を主張する。該優先仮出願は、すべての目的のために参照により組み込まれる。

本出願は、２０１４年３月５日出願の「ネットワーク配信サービス」と題する米国特許出願第１４／１９８，４９９号（代理人事件整理番号：ＮＳＫＯ １０００−２）（現在は２０１６年７月１９日発行の米国特許第９，３９８，１０２号）を参照により組み込む。

本出願は、２０１５年８月２５日出願の「クラウドコンピューティングサービス（ＣＣＳ）に格納された企業情報を監視及び制御するシステム及び方法」と題する米国特許出願第１４／８３５，６４０号（代理人事件整理番号：ＮＳＫＯ １００１−２）を参照により組み込む。

本出願は、２０１６年３月１１日出願の「クラウド・コンピューティング・サービスのデータ欠損トランザクションにおいてマルチパート・ポリシーを実施するシステム及び方法」と題する米国仮特許出願第６２／３０７，３０５号（代理人事件整理番号：ＮＳＫＯ １００３−１）を参照により組み込む。

開示される技術は、一般にネットワーク配信サービスのセキュリティに関し、特に、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を保持することによるフェデレーテッド（認証連携した）・シングル・サインオン（ＳＳＯ）中の非侵入型のセキュリティ実施に関する。

本項で議論される主題は、本項におけるその言及の結果、単に従来技術であると仮定すべきではない。同様に、本項で述べた問題または背景技術として提供された主題に関連する問題は、従来技術内で既に認識されたものと仮定すべきではない。本項の主題は単に様々なアプローチを示しているに過ぎず、また、それ自体または自発的に、請求項に記載の技術の実施に対応し得る。

開示される技術は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入的にセキュリティを実行することに関する。特に、ユーザがＳＰにログインするときに生成されるアサーションを転送するために、前記ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬに代えて、プロキシＵＲＬを使用するようにＩＤＰを構成することに関する。また、アサーションをＳＰに転送するためにＳＰのＡＣＳ−ＵＲＬを使用するために、プロキシＵＲＬにおいてアサーション・プロキシを構成することに関する。更に、アサーションをＳＰのＡＣＳ−ＵＲＬに転送することによって、ユーザのクライアントとＳＰのＡＣＳの間にアサーション・プロキシを挿入し、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）の認証されたセッションを確立することに関する。

クラウド・アプリケーション、特に、ソフトウェア・アズ・ア・サービス（ＳａａＳ）アプリケーションの爆発的な成長は、組織のビジネス方法を変えた。メンテナンス費用の削減、稼働時間の増加、機能の迅速な導入、現場でのハードウェアの必要性の低減は、クラウドベースのＳａａＳソリューションが以前は自社ＩＴスタッフだけで支配されていたタスクに深く迅速に浸透している理由の一部です。

しかしながら、ＳａａＳアプリケーション上のユーザ・アイデンティティ管理（ＵＩＭ）は、困難で時間がかかり、高価である。ＳａａＳアプリケーションに加入している多くの企業は、ＵＩＭの課題とコストに対処するために、通常複数のプラットフォームに及び、頻繁に変化し得るＳａａＳアプリケーションのサブスクリプションのポートフォリオ全体に亘りユーザ・アイデンティティを簡単に作成及び管理するアイデンティティ・アズ・ア・サービス（ＩＤａａＳ）ソリューションを始めている。

ＩＤａａＳソリューションは、組織の全てのＳａａＳアプリケーションのサブスクリプションに亘って、ユーザにフェデレーテッド・シングル・サインオン（ＳＳＯ）機能またはフェデレーテッド・アイデンティティを提供する。ＳＳＯによって、組織のユーザは単一の場所で単一のアカウントで認証でき、幅広いＳａａＳアプリケーションにアクセスできる。ＳＳＯを使用すると、ユーザは様々なアプリケーションを呼び出すために何度もサイン・オンする必要はなく、同じセッションで以前のアプリケーションの認証済みステータスを再利用できる。ＳＳＯを使用する利点は、人的エラーを減らし、同じアイデンティティに対して異なるＳａａＳアプリケーションでの認証に費やす時間を節約できることである。多数のメカニズムが、ＩＤａａＳプロバイダと複数のＳａａＳアプリケーションとの間でＳＳＯを実行する。例えば、ＳＳＯは、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）によって容易となる。 ＳＡＭＬは、ユーザ・アイデンティティを提供するエンティティ、つまりアイデンティティ・プロバイダ（ＩＤａａＳ等）と、ユーザがログインする必要があるサービスを提供するエンティティ、つまりサービス・プロバイダ（ＳａａＳアプリケーション等）間でセキュリティ情報（認証及び認可データ）を通信するための拡張マークアップ言語（ＸＭＬ）ベースのオープン標準データ形式である。ＳＳＯ実行メカニズムの他の例には、ＷＳフェデレーション、ＯＡｕｔｈ、ＯｐｅｎＩＤ、ＬＤＡＰ、Ｋｅｒｂｅｒｏｓ、ＳｅｃｕｒｅＩＤ、Ｓｈｉｂｂｏｌｅｔｈ Ｓｙｓｔｅｍ、拡張アクセス・コントロール・マークアップ言語（ＸＡＣＭＬ）、サービス・プロビジョニング・マークアップ言語（ＳＰＭＬ）等がある。

ＳＳＯに加えて、組織は、いわゆるクラウド・アクセス・セキュリティ・ブローカ（ＣＡＳＢ）を介して、加入したＳａａＳアプリケーションへのアクセスを監視し、モデレートし、抑制するための要件を有する。しかし、殆どの組織では、ＩＤａａＳプロバイダとＳａａＳアプリケーション間の直接通信による信頼関係の確立を必要とするＳＳＯを実行するＩＤａａＳソリューションと、ＳＳＯに必要な直接通信を中断して信頼関係を変更するＣＡＳＢサーバの両方を効果的に使用できていない。

企業によるＳａａＳの採用が拡大し続けるにつれて、ＳａａＳアプリケーションへのアクセスを監視し、モデレートし、管理する必要性も増している。既存のＣＡＳＢサーバの限られた機能には、組織のＩＤａａＳサブスクリプションとＳａａＳアプリケーション・サブスクリプション間の信頼関係を変更することなく、クラウド・セキュリティを非侵入的に強化する改良されたＣＡＳＢサーバの設定が必要である。

従って、既存のＣＡＳＢの上述の限界を克服するために、強化されたＣＡＳＢの開発の機会が生じる。

図面において、同様の参照符号は一般的に異なる図を通して同様の部品を指す。また、図面は必ずしも一定の縮尺ではなく、代わりに、開示された技術の原理を図解することに一般的に重点が置かれている。以下の説明では、以下の図面を参照して、開示された技術の様々な実施態様が説明される。

開示された技術の実施態様によるシステムのアーキテクチャ・レベルの概略図を示す。

サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を確立する一実施態様を示す。

図２で確立された信頼に基づくフェデレーテッド・シングル・サインオン（ＳＳＯ）のメッセージ交換チャートの一実施態様を示す。

サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更する一実施態様を示す。

図４で変更された信頼に基づくフェデレーテッド・シングル・サインオン（ＳＳＯ）のメッセージ交換チャートの一実施態様を示す。

ポリシー実行のための非管理デバイスからネットワーク・セキュリティ・システムへのトラフィックをルーティングするリバース・プロキシの一実施態様を示す。

Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）によるフェデレーテッドＳＳＯセッション中の信頼関係保持の一実施態様を示す。

ポリシー実行のために非管理デバイスからネットワーク・セキュリティ・システムへトラフィックをルーティングするリバース・プロキシの別実施態様を示す。

Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）によるフェデレーテッドＳＳＯセッション中の信頼関係保持の別実施態様を示す。

Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）によるフェデレーテッドＳＳＯセッション中の信頼関係保持の一実施態様を示す。

フェデレーテッド・シングル・サインオン（ＳＳＯ）認証のための非侵入型セキュリティ実施の代表的な方法を示す。

サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更せずにフェデレーテッド・シングル・サインオン（ＳＳＯ）認証中にセキュリティを非侵入的に実行する方法を示すフローチャートである。

サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更せずにフェデレーテッド・シングル・サインオン（ＳＳＯ）認証中にセキュリティを非侵入的に実行するする方法を示すフローチャートである。

開示された技術を実施するために使用できるコンピュータ・システムの簡略ブロック図である。

以下の説明は、当業者が開示された技術を製作し使用することを可能にするために提示され、特定の用途及びその要件に即して提供される。開示された実施態様に対する様々な修正は、当業者には容易に明らかであり、本明細書で定義される一般原則は、開示される技術の精神及び範囲から逸脱することなく、他の実施態様及び用途に適用され得る。従って、開示された技術は、示された実施態様に限定されることを意図するものではなく、本明細書に開示された原理及び特徴と一致する最も広い範囲が与えられるべきである。

説明は以下のように構成されている。先ず、説明を通して使用される用語の説明が提供される。次に、様々な実施態様によって対処された技術的問題の幾つかを説明する序論が提示される。次に、一実施態様の高レベルの説明がアーキテクチャ・レベルで議論される。最後に、システムを実施するためのより詳細なアーキテクチャとその方法について説明する。
［用語］

サービス・プロバイダ（ＳＰ）：本明細書で使用されるように、ユーザがサインインしようとしているアプリケーションまたはウェブサイトは、「サービス・プロバイダ」と呼ばれる。ＳＰは、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）、Ｂｏｘ（商標）、Ｄｒｏｐｂｏｘ（商標）、Ｇｏｏｇｌｅ Ａｐｐｓ（商標）、Ａｍａｚｏｎ ＡＷＳ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ ３６５（商標）、Ｗｏｒｋｄａｙ（商標）、Ｏｒａｃｌｅ ｏｎ Ｄｅｍａｎｄ（商標）、Ｔａｌｅｏ（商標）、Ｙａｍｍｅｒ（商標）、Ｃｏｎｃｕｒ（商標）等のソフトウェア・アズ・ア・サービス（ＳａａＳ）アプリケーションである。ＳＰは、Ｗｅｂアーキテクチャのアプリケーションまたはクラウド配信レガシー・サービスとして提供され得る。また、ＳＰは、オンプレミス・サービスとしても運用可能である。

ソフトウェア・アズ・ア・サービス（ＳａａＳ）アプリケーション：本明細書で使用されるように、クラウドベースのＳＰ、ホストされたサービス、クラウド・サービス、クラウド・アプリケーション、クラウド・ストレージ・プロバイダ、クラウド・ストレージ・アプリケーション、または、クラウド・コンピューティング・サービス（ＣＣＳ）は、「ＳａａＳアプリケーション」と呼ばれ、及びその逆も同様である。また、本明細書においては、クラウド・コンピューティング・サービス（ＣＣＳ）、ホストされたサービス、または、クラウド・アプリケーションとして時々呼ばれるクラウド・サービスは、ネットワーク・クラウド・サービスまたはアプリケーション、ウェブベース（例えば、統合リソース・ロケータ（ＵＲＬ）を介してアクセスされる）または同期クライアント等のネイティブと呼ばれる。実施例は、ＵＲＬを介して公開される内部の企業アプリケーションと同様に、ＳａａＳの提供、プラットフォーム・アズ・ア・サービス（ＰａａＳ）の提供、及び、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）の提供を含む。今日一般的なＳａａＳアプリケーションの実施例は、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）、Ｂｏｘ（商標）、Ｄｒｏｐｂｏｘ（商標）、Ｇｏｏｇｌｅ Ａｐｐｓ（商標）、Ａｍａｚｏｎ ＡＷＳ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ ３６５（商標）、Ｗｏｒｋｄａｙ（商標）、Ｏｒａｃｌｅ ｏｎ Ｄｅｍａｎｄ（商標）、Ｔａｌｅｏ（商標）、Ｙａｍｍｅｒ（商標）、及び、Ｃｏｎｃｕｒ（商標）を含む。ＳａａＳアプリケーションは、単純なウェブサイト及び電子商取引サイトの提供とは対照的に、クラウド内で実行される機能であって、例えば、ログイン、ドキュメント編集、大量データのダウンロード、得意先情報の読み出し、支払勘定への入力、ドキュメント消去、等のポリシーの目標である機能を、ユーザに提供する。ここで留意すべきは、Ｆａｃｅｂｏｏｋ（商標）及びＹａｍｍｅｒ（商標）等のソーシャルネットワークを提供する幾つかの消費者対応ウェブサイトは、ここで考えられるＳａａＳアプリケーションのタイプである点である。グーグルのＧｍａｉｌ（商標）等の幾つかのＳａａＳアプリケーションは、幾つかの自由なユーザが該アプリケーションを一般的に使用すると同時に、他の企業がそれを企業のサブスクリプションとして使用するハイブリッドなものも可能である。ここで留意すべきは、ＳａａＳアプリケーションは、ＵＲＬベースのアプリケーション・プログラミング・インターフェイス（ＡＰＩ）を使用するウェブ・ブラウザ・クライアント及びアプリケーション・クライアントの両方によってサポートされ得る点である。従って、一例としてＤｒｏｐｂｏｘ（商標）を用いて、Ｄｒｏｐｂｏｘ（商標）ウェブサイト上のユーザ活動、並びにコンピュータ上のＤｒｏｐｂｏｘ（商標）クライアントの活動を監視し得る。

アイデンティティ・プロバイダ（ＩＤＰ）：本明細書で使用されるように、ユーザを実際に認証するエンティティは、「アイデンティティ・プロバイダ」と呼ばれる。 ＩＤＰはまた、ユーザのアイデンティティを提供し、氏名、ジョブコード、電話番号、住所等のユーザに関する追加情報を含むユーザのプロファイルも含む。アプリケーションによっては、或るＩＤＰは、非常に単純なプロファイル（例えば、ユーザネーム、電子メール）を必要とし、他のＩＤＰは、ユーザデータ（例えば、ジョブコード、部門、住所、場所、マネージャ等）のより豊富な集合を必要とする場合がある。ＩＤＰは、アイデンティティ・アズ・ア・サービス（ＩＤａａＳ）としても機能する。

アイデンティティ・アズ・ア・サービス（ＩＤａａＳ）：本明細書で使用されるように、対象のＳＰに一連のアイデンティティ及びアクセス管理機能を提供するクラウドベースのＩＤＰは、「ＩＤａａＳ」と呼ばれる。 ＩＤａａＳ機能には、対象のＳＰが保持するアイデンティティをプロビジョニングする機能を含むアイデンティティのガバナンスと管理（ＩＧＡ）が含まれる。また、ＩＤａａＳは、ユーザ認証、ＳＳＯ、及び、承認の実行を提供する。今日の一般的なＩＤａａＳプロバイダの例には、Ｏｋｔａ（商標）、Ｐｉｎｇ Ｉｄｅｎｔｉｔｙ（商標）、Ｗｉｎｄｏｗｓ Ａｚｕｒｅ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（商標）、ＥｍｐｏｗｅｒＩＤ（商標）、ＯｎｅＬｏｇｉｎ（商標）、Ｂｉｔｉｕｍ（商標）、Ｃｅｎｔｒｉｆｙ（商標）、Ｉｄｅｎｔａｃｏｒ（商標）、ＬａｓｔＰａｓｓ（商標）等が含まれる。

信頼関係：本明細書で使用されるように、ＳＰとＩＤＰ間の信頼関係は、ディジタル証明書及び／または暗号鍵を使用して確立される。証明書または鍵は、信頼できる証明機関によって発行され、ディジタルトランザクションの両端にインストールされる。証明書または鍵は、ＩＤＰによってＳＰに配信される情報が真正で妥協のないことを保証する。 ＩＤＰがアサーションをＳＰに配信すると、証明書または鍵はその情報が信頼できることを保証する。信頼関係は、ＳＰにおいてＩＤＰ−ＵＲＬを構成し、ＩＤＰにおいてＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）のＵＲＬを構成することによって確立される。

信頼関係の変更：本明細書で使用されるように、ＳＰとＩＤＰ間の信頼関係の変更は、ＳＰが、ＩＤＰ自体を直接信頼するのではなく、ＳＰとＩＤＰの間に位置する中間エンティティを信頼する必要があることを指す。信頼関係は、中間エンティティがＣＡＳＢまたはリバース・プロキシの場合に変更される。その場合、ＳＰにおいてＩＤＰのディジタル証明書または鍵を設定する代わりに、ＣＡＳＢまたはリバース・プロキシのディジタル証明書または鍵がＳＰで設定される。信頼関係は、ＳＰにおいてアサーションを検証するために使用される公開鍵が、ＳＰとＩＤＰ間で共有されるのではなく、ＣＡＳＢまたはリバース・プロキシとＳＰの間で共有される場合にも変更される。信頼関係は、ＳＰがＩＤＰ−ＵＲＬではなくＣＡＳＢ−ＵＲＬまたはリバース・プロキシＵＲＬに認証要求を転送するように構成されている場合にも変更される。信頼関係は、ＩＤＰによって生成されたアサーションの内容がＣＡＳＢやリバース・プロキシ等の中間物によって変更された場合にも変更される。

Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ（Ｎ−ＣＡＳＢ）：本明細書で使用されるように、「Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ」は、クラウドベースのセキュリティ装置またはオンプレミス・ポリシー実行ポイントとして機能するネットワーク・セキュリティ・システムであり、ＳａａＳアプリケーションがアクセスされるときにエンタープライズ・セキュリティ・ポリシーを統合し、差し挟むために、ユーザとＳａａＳアプリケーションの間に配置される。Ｎ−ＣＡＳＢは、複数のタイプのセキュリティ・ポリシーの実行を統合する。セキュリティ・ポリシーの例には、認証、フェデレーテッド・シングル・サインオン（ＳＳＯ）、認可、資格マッピング、デバイス・プロファイリング、暗号化、トークン化、データ漏洩防止（ＤＬＰ）、ロギング、アラート、マルウェア検出／防止等が含まれる。Ｎ−ＣＡＳＢは、ＡＰＩを使用してアプリケーション層のトラフィックを分析し、リアルタイムでＳａａＳアプリケーションのトランザクションを深く検査する。Ｎ−ＣＡＳＢに関する追加情報については、例えば、同一出願人の米国特許出願第１４／１９８，４９９号、第１４／１９８，５０８号、第１４／８３５，６４０号、第１４／８３５，６３２号、及び、第６２／３０７，３０５号； チェン、イタール、ナラヤナスワミー、及びマルムスコッグ、「ダミーのためのクラウド・セキュリティ、ネットスコープ・スペシャルエディション、Ｊｏｈｎ Ｗｉｌｅｙ＆Ｓｏｎｓ，Ｉｎｃ．２０１５； ネットスコープ，インクの「ネットスコープ内観」； ネットスコープ，インクの「クラウドにおけるデータ損失防止と監視」； ネットスコープ，インクの「クラウド・データ損失防止参照アーキテクチャ」； ネットスコープ，インクの「クラウド信頼への５つのステップ」； ネットスコープ，インクの「ネットスコープ・アクティブ・プラットフォーム」； ネットスコープ，インクの「ネットスコープの利点：クラウド・アクセス・セキュリティ・ブローカのための３つの“必携”要件」； ネットスコープ，インクの「重要な１５のＣＡＳＢ使用事例」； ネットスコープ，インクの「ネットスコープ・アクティブ・クラウドＤＬＰ」； ネットスコープ，インクの「クラウド・データ侵害の衝突コースを修復する」； ネットスコープ，インクの「Ｎｅｔｓｋｏｐｅ Ｃｌｏｕｄ Ｃｏｎｆｉｄｅｎｃｅ Ｉｎｄｅｘ（商標）」を参照されたい。

更に、既存のＣＡＳＢとは異なり、Ｎ−ＣＡＳＢは、ＩＤＰまたはＩＤａａＳとＳＰまたはＳａａＳアプリケーションとの間の信頼関係を保持するアサーション・プロキシとして動作する。Ｎ−ＣＡＳＢは、ＩＤＰからアサーションを受信するアサーション・コンシューマ・サービス（ＡＣＳ）としても機能し得る。Ｎ−ＣＡＳＢは、ＩＤＰから受信したアサーションを（例えば、ＳＰまたはＳａａＳ公開鍵を使用して）暗号化し、暗号化されたアサーションをＳＰに転送する。

非管理デバイス：本明細書で使用されるように、「非管理デバイス」は、トラフィックがポリシー実行サーバを介してトンネリングされていない個人保有デバイスの持ち込み（ＢＹＯＤ）、及び／または、オフ・ネットワーク・デバイスと呼ばれる。Ｎ−ＣＡＳＢは、着信トラフィックを分析して、ＳａａＳアプリケーションのトランザクションが企業ネットワークの範囲内で行われているか、セキュリティ・エージェントまたはセキュリティプロファイルがインストールされているデバイスから行われているか否かを判断する。デバイスは、エンドポイント・ルーティング・エージェント（ＥＲＣ）によって収集された特定のデバイス特性に基づいて、非管理デバイスまたは管理デバイスとして分類できる。デバイスのタイプによっては、ＥＲＣは、オンデマンドＶＰＮや証明書ベースの認証を使用するアプリケーション別ＶＰＮ等の仮想プライベート・ネットワーク（ＶＰＮ）であり得る。例えば、ｉＯＳ（商標）デバイスの場合、それは、アプリケーション別ＶＰＮでも、ドメインベースのＶＰＮプロファイルの集合でも良い。 Ａｎｄｒｏｉｄ（商標）デバイスの場合、それは、クラウド・ディレクタ・モバイル・アプリであり得る。Ｗｉｎｄｏｗｓ（商標）デバイスの場合、それは、アプリケーション別ＶＰＮでも、ドメインベースのＶＰＮプロファイルの集合でも良い。ＥＲＣは、電子メールを使用してダウンロードされたか、または、ＣｏｎｆｉｇＭｇｒ（商標）、Ａｌｔｒｉｓ（商標）、及びＪａｍｆ（商標）等の大量展開ツールを使用して、サイレントインストールされたエージェントでもあり得る。

ＥＲＣは、レジストリキー、アクティブ・ディレクトリ（ＡＤ）、メンバーシップ、プロセスの存在、オペレーティング・システム・タイプ、ファイルの存在、ＡＤドメイン、暗号化チェック、ＯＰＳＷＡＴチェック、メディア・アクセス・コントロール（ＭＡＣ）アドレス、ＩＭＥＩ番号、及び、デバイスのシリアル番号等のデバイス情報を収集する。。収集されたデバイス情報に基づいて、ＥＲＣはデバイスを非管理デバイスまたは管理デバイスとして分類する。追加または異なるカテゴリを使用して、デバイスを半管理デバイスカテゴリまたは未知のデバイスカテゴリ等に分類することができる。

Ｎ−ＣＡＳＢが、着信トラフィックが管理デバイスまたは非管理デバイスからルーティングされるか否かを決定する方法に関する追加情報については、例えば、同一出願人の米国特許出願第１４／１９８，４９９号、 第１４／１９８，５０８号、第１４／８３５，６４０号、第１４／８３５，６３２号、及び、第６２／３０７，３０５号を参照されたい。

ポリシー：本明細書で使用されるように、ポリシー規定、ポリシー・データ、または、コンテント・ポリシーとして時々呼ばれる用語「ポリシー」は、ＳａａＳアプリケーションに対するフロー・コントロール及びコンテンツ・コントロール要求の機械可読表現を指す。典型的に、ポリシーは、企業または他のエンティティにおいて１以上の管理者によって規定され、当該企業またはエンティティ内でユーザに対して実行される。個人が当該個人に対して実行される当該個人自身の使用のためのポリシーを規定することも可能であるが、企業利用がより一般的である。また、ＳａａＳアプリケーションのビジターまたは顧客に対して、ポリシーを実行することも可能であり、その場合、例えば、企業がＳａａＳアプリケーションをホストし、或いは、に加入し、訪れる顧客、ユーザ、または、従業員に対して使用のためのポリシーを順守するように要求する。特に留意すべきは、ここで考えられるポリシーは、ＳａａＳアプリケーションの意味に対して敏感であり得る、つまり、ポリシーは、ＳａａＳアプリケーションにログインすることと、ＳａａＳアプリケーション上のドキュメントを編集することを区別することができる。

使用を理解するのに文脈は重要である。エンティティに対して、数十または数百の個別のポリシー（例えば、大量ダウンロードの記録、サービス上のドキュメントの編集禁止、「副社長」グループ内のユーザに対してのみ大量ダウンロードを許可）は、特に、１つのポリシーまたは１つのポリシー規定と呼ばれる。従って、複数のエンティティをサポートするシステムは、一般的に、エンティティ当たり、数十または数百の個別のフロー・コントロール及びコンテンツ・コントロール・ポリシーからなる１つのポリシーを有するであろう。同様に、個々のコンピュータに転送されるポリシーは、完全な企業ポリシーの一部、例えば、フロー・コントロール及び／またはコンテンツ操作を記述する各ＵＲＬに対する完全なポリシーの仕様ではなく、単に関心のあるＵＲＬの機械可読表現だけとすることができる。

マルチパート・ポリシー：本明細書で使用されるように、「マルチパート・ポリシー」は、トランザクションに関する少なくとも１つの条件が満たされたときに、少なくとも１つのセキュリティ処置のトリガを指定するポリシーを指す。マルチパート・ポリシーは、単一のトランザクションに適用されるが、マルチパート・ポリシーの少なくとも１つのポリシー条件は、単一トランザクションで利用できないデータまたはメタデータの評価を必要とする。また、マルチパート・ポリシーは、単一のトランザクションに適用されるが、マルチパート・ポリシーの少なくとも１つのポリシー条件は、外部データまたはメタデータストアで利用可能なデータまたはメタデータの評価を必要とする。更に、マルチパート・ポリシーは、単一のトランザクションに適用されるが、マルチパート・ポリシーの少なくとも１つのポリシー条件は、外部エンジンによって生成されるデータまたはメタデータの評価を必要とする。マルチパート・ポリシーは、アクティブな分析中にリアルタイムで適用されるが、マルチパート・ポリシーの少なくとも１つのポリシー条件は、延期中または非リアルタイム検査で収集されたデータまたはメタデータの評価を必要とする。マルチパート・ポリシーの例には、「ユーザが異常検出によって指摘されたリスクにある場合に、ユーザのフォームのアップロード／ダウンロードを防止する」、「ファイルが機密の場合、ファイルの共有を防止する」、「デバイスがマルウェア検出エンジンによって指摘されたリスクにある場合、デバイスへのファイルのダウンロードを防止する」、「仮想マシンが重要なサーバである場合は、仮想マシンの削除を防止する」等が含まれる。

アプリケーション・プログラミング・インターフェイス（ＡＰＩ）：本明細書で使用されるように、「アプリケーション・プログラミング・インターフェイス」は、そのインターフェイスタイプを含む一連のクラスに属するコード・ライブラリ、ルーチン、プロトコル・メソッド、及び、フィールドのパッケージ化されたコレクションを指す。ＡＰＩは、関連するクラスをインポートし、クラスをインスタンス化して、それらのメソッドとフィールドを呼び出す命令文を記述するだけで、開発者とプログラマが独自のソフトウェア開発にクラスを使用できる方法を規定する。ＡＰＩは、ソフトウェア・コンポーネントが互いに通信するためのインターフェイスとして使用されることを意図したソースコード・ベースの仕様である。ＡＰＩには、ルーチン、データ構造、オブジェクト・クラス、及び、変数の仕様を含めることができる。基本的に、ＡＰＩは、開発者とプログラマがオンライン・ソーシャル・ネットワークの基本的なプラットフォームの機能と特徴にアクセスするためのインターフェイスを提供する。開示される技術には、ＳＯＡＰ、Ｂｕｌｋ、ＸＭＬ−ＲＰＣ、及び、ＪＳＯＮ−ＲＰＣ等のＨＴＴＰまたはＨＴＴＰベースのＡＰＩや、ＲＥＳＴ ＡＰＩ（例えば、Ｆｌｉｃｋｒ（商標）、Ｇｏｏｇｌｅ Ｓｔａｔｉｃ Ｍａｐｓ（商標）、Ｇｏｏｇｌｅ Ｇｅｏｌｏｃａｔｉｏｎ（商標））等のＷｅｂサービスＡＰＩ、ＷｅｂソケットＡＰＩ、ＪａｖａＳｃｒｉｐｔ（登録商標）及びＴＷＡＩＮ（例えば、Ｇｏｏｇｌｅ Ｍａｐｓ（商標）、ＪａｖａＳｃｒｉｐｔ ＡＰＩ、Ｄｒｏｐｂｏｘ（商標）、ＪａｖａＳｃｒｉｐｔデータストアＡＰＩ、Ｔｗｉｌｉｏ（商標）ＡＰＩ、Ｏｒａｃｌｅ Ｃａｌｌ Ｉｎｔｅｒｆａｃｅ（ＯＣＩ））等のライブラリ・ベースのＡＰＩ、Ｊａｖａ ＡＰＩやＡｎｄｒｏｉｄ ＡＰＩ（例えば、Ｇｏｏｇｌｅ Ｍａｐｓ（商標）、Ａｎｄｒｏｉｄ ＡＰＩ、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ用ＭＳＤＮクラスライブラリ、Ｊａｖａ（登録商標）とＣ＃用Ｔｗｉｌｉｏ（商標）ＡＰＩ）等のクラス・ベースのＡＰＩ、ファイル・システムへのアクセスやユーザ・インターフェイスへのアクセス等のＯＳ関数とルーチン、ＣＯＲＢＡや．ＮＥＴ Ｒｅｍｏｔｉｎｇ等のオブジェクト・リモーティングＡＰＩ、及び、ビデオ・アクセラレーション、ハードディスク・ドライブ、ＰＣＩバス等のハードウェアＡＰＩを含む様々なタイプのＡＰＩを使用する。開示される技術によって使用されるＡＰＩの他の例には、Ａｍａｚｏｎ ＥＣ２ ＡＰＩ（商標）、Ｂｏｘ Ｃｏｎｔｅｎｔ ＡＰＩ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｇｒａｐｈ（商標）、Ｄｒｏｐｂｏｘ ＡＰＩ（商標）、Ｄｒｏｐｂｏｘ ＡＰＩ ｖ２（商標）、Ｄｒｏｐｂｏｘ Ｃｏｒｅ ＡＰＩ（商標）、Ｄｒｏｐｂｏｘ Ｃｏｒｅ ＡＰＩ ｖ２（商標）、Ｆａｃｅｂｏｏｋ Ｇｒａｐｈ ＡＰＩ（商標）、Ｆｏｕｒｓｑｕａｒｅ ＡＰＩ（商標）、Ｇｅｏｎａｍｅｓ ＡＰＩ（商標）、Ｆｏｒｃｅ．ｃｏｍ ＡＰＩ（商標）、Ｆｏｒｃｅ．ｃｏｍ Ｍｅｔａｄａｔａ ＡＰＩ（商標）、Ａｐｅｘ ＡＰＩ（商標）、Ｖｉｓｕａｌｆｏｒｃｅ ＡＰＩ（商標）、Ｆｏｒｃｅ．ｃｏｍ Ｅｎｔｅｒｐｒｉｓｅ ＷＳＤＬ（商標）、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ Ｓｔｒｅａｍｉｎｇ ＡＰＩ（商標）、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ Ｔｏｏｌｉｎｇ ＡＰＩ（商標）、Ｇｏｏｇｌｅ Ｄｒｉｖｅ ＡＰＩ（商標）、Ｄｒｉｖｅ ＲＥＳＴ ＡＰＩ（商標）、ＡｃｃｕＷｅａｔｈｅｒ ＡＰＩ（商標）、ＣｌｏｕｄＲａｉｌ（商標）ＡＰＩ等の集約型単一ＡＰＩ等がある。

モバイル及びタブレット対コンピュータ：明細書の一部では、ＳａａＳアプリケーションにアクセスするためにユーザによって使用される２つのタイプのクライアント・デバイスを区別する。主な区別は、クライアント・デバイスをＮ−ＣＡＳＢに接続するためのメカニズムの違いである。クライアント・デバイスに関して、「コンピュータ」という用語は、Ｎ−ＣＡＳＢがソフトウェアをより直接的にインストールし、ネットワーキング・スタックを変更できる、よりオープンなシステムを指す。同様に、クライアント・デバイスに関して、「モバイル」または「タブレット」という用語は、ネットワーク・スタックを変更するためのネットワーク・セキュリティ・システムのオプションがより限定されている、より閉じたシステムを指す。この用語は、Ｍａｃ ＯＳ Ｘ、Ｗｉｎｄｏｗｓデスクトップ・バージョン、Ａｎｄｒｏｉｄ、及び／または、Ｌｉｎｕｘ（登録商標）上で動作するコンピュータ・クライアント・デバイスが、ｉＯＳ及び／またはＷｉｎｄｏｗｓ Ｍｏｂｉｌｅ上で動作するモバイルデバイスまたはタブレットデバイスよりも簡単に変更できるという今日の状況を反映している。従って、この用語は、クライアント・デバイスのタイプ間の基本的な技術的な違いとは対照的に、ネットワーク・セキュリティ・システムへのアクセスを提供するためにサードパーティのオペレーティング・システム・ベンダの制限がどのように対処されるかを参考にする。更に、モバイルＯＳベンダがシステムを更にオープンにした場合、クライアント・デバイスのより多くクラスにおいて、当該区別をなくせる可能性がある。更に、組織内の特定のサーバ・コンピュータ及び他のコンピューティング・デバイスが、マシン間通信をカバーするためにクライアントをインストールできる場合があり得る。

密接に関連する点は、一部のクライアントがＮ−ＣＡＳＢに異なる方法でインターフェイスすることである。例えば、ブラウザ・アドオン・クライアントは、ブラウザを明示的なプロキシにリダイレクトする。ポリシーを適用するために必要なトラフィックのみがルート変更され、アプリケーション内でトラフィックがルート変更される。Ｎ−ＣＡＳＢに到着するトラフィックは、データ内にまたは安全なトンネル・ヘッダ内に埋め込まれたユーザ・アイデンティティ、例えば、追加のヘッダまたはＳＳＬクライアント側の証明書を有することができる。他のクライアントは、透過プロキシを通じて選択されたネットワーク・トラフィックをリダイレクトする。これらの接続では、ポリシーで必要とされる要求を超えるトラフィックがＮ−ＣＡＳＢにルーティングされる可能性がある。更に、ユーザ・アイデンティティ情報は、一般にデータそのもの中にはなく、Ｎ−ＣＡＳＢへの安全なトンネルを設定する際にクライアントによって確立される。

ユーザ・アイデンティティ：本明細書で使用されるように、「ユーザ・アイデンティティ」または「ユーザ識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）」は、クライアント・デバイスに提供されるインジケータを指す。これは、トークン、ＵＵＩＤ等の一意の識別子、公開鍵証明書等の形式を取り得る。ユーザ・アイデンティティを特定のユーザ及び特定のデバイスにリンクすることができる。従って、同じ個人が、自分の携帯電話とコンピュータとで異なるユーザ・アイデンティティを持つことができる。ユーザ・アイデンティティは、エントリまたはユーザＩＤのコーポレート・アイデンティティ・ディレクトリにリンクできるが、それとは区別される。暗号証明書がユーザ・アイデンティティとして使用される。ユーザ・アイデンティティは、ユーザにのみ固有であり、デバイス間で同一とすることもできる。

［序論］
既存のＣＡＳＢの限界を克服する目的で、改良されたＣＡＳＢがネットスコープ，インクによって開発された。この改善されたＣＡＳＢは、本明細書では「Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ（Ｎ−ＣＡＳＢ）」と呼ばれ、その特徴及び実施態様が以下に説明される。

既存のＣＡＳＢサーバは、ＳＰとＩＤＰの間の信頼できる認証会話の途中に自身を挿入する侵入的プロキシとして動作する。開示された技術は、改善されたＣＡＳＢ（Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ（Ｎ−ＣＡＳＢ）と呼ばれる）がアサーション・プロキシとして動作し、ＳＰとＩＤＰの間の信頼関係を保持するシステム及び方法を提案する。このように、Ｎ−ＣＡＳＢは、ＩＤＰがＳａａＳアプリケーションによるフェデレーテッドＳＳＯ認証用に提供するセキュリティとユーザ・アイデンティティ管理（ＵＩＤ）を妨げずに、ＳａａＳアプリケーションへのアクセスを管理するという本来の目的のために使用することができる。

［信頼関係］
図２は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）との間の信頼関係を確立する一実施態様を示す。図２に対して補完的に、図３は、図２で確立された信頼に基づくフェデレーテッド・シングル・サインオン（ＳＳＯ）のメッセージ交換チャートの一実施態様を示す。

ＳＳＯ認証方法が機能できる前に、ユーザに代って、組織、会社、または企業が、図２に示す別個のオフラインまたは帯域外プロセスでＩＤＰ２０８と信頼関係を確立する。これは、ＳＰ２０２においてＩＤＰ公開鍵を構成することによって行われる。同様に、ＳＰ２０２は、ＩＤＰ２０８と独立した信頼関係を有する。ＳＳＯ認証方法は、ＩＤＰ２０８及び複数のＳａａＳアプリケーションに対し、１対１の関係を動的に確立できる機能を提供する。簡単に説明すると、ＩＤＰ２０８とＳＰ２０２が互いに信頼する方法は、それらが暗号化と復号化のための鍵を共有することであり、その場合、ＳＳＯの実施態様が図２において最初に設定された時に、当該鍵が確立される。

図２は、ＳＰ２０２、ＩＤＰ２０８、及び組織の信頼関係確立器２２６を含む。ＳＰ ２０２、ＩＤＰ２０８、及び確立器２２６は、ネットワーク１１５等のネットワークを介して接続される。ＳＰ２０２及びＩＤＰ２０８は、ワークステーション、サーバ、コンピューティングクラスタ、ブレードサーバ、サーバファーム、または任意の他のデータ処理システムもしくはコンピューティング・デバイスとすることができる。幾つかの実施態様では、ＳＰ２０２はＳａａＳアプリケーションであり、ＩＤＰ２０８はＩＤａａＳプロバイダである。一実施態様では、ＳＰ２０２は、ＡＣＳ−ＵＲＬによってアクセス可能なアサーション・コンシューマ・サービス（ＡＣＳ）を含む。別の実施態様では、ＩＤＰ２０８は、ＩＤＰ−ＵＲＬによってアクセス可能である。

図２において、確立器２２６は、ＳＰ２０２とＩＤＰ２０８との間の信頼関係を確立するために使用される。実施態様では、組織、企業、または企業は、ＳａａＳアプリケーション・サブスクリプションのポートフォリオを有する。一実施態様では、組織は、ＩＤＰ ２０８としてＩＤａａＳプロバイダを使用して、ＳａａＳアプリケーション・サブスクリプションのポートフォリオ全体にわたってユーザ・アイデンティティ管理（ＵＩＤ）を実行する。図２において、ＳＰ２０２は、明確にするために、１つのＳａａＳアプリケーションのみを表す。他の実施態様では、確立器２２６は、複数のＳａａＳアプリケーションとＩＤＰ２０８との間の信頼関係を確立することができる。

ある実施態様では、ＳＰ２０２とＩＤＰ２０８との間の信頼関係は、ＳＰ２０２でＩＤＰ−ＵＲＬを構成し、ＩＤＰ２０８でＳＰのＡＣＳ−ＵＲＬを構成することによって確立される。他の実施態様では、信頼関係は、ＩＤＰ２０８の公開鍵またはディジタル証明書をＳＰ２０２で構成することによって確立される。図２では、図示のように、確立器２２６を使用して、ＳＰ２０２におけるＩＤＰ−ＵＲＬ及びＩＤＰ公開鍵、並びにＩＤＰ ２０８におけるＳＰのＡＣＳ−ＵＲＬを構成することができる。

図３は、図２で確立された信頼に基づくフェデレーテッドＳＳＯ認証のメッセージ交換チャートの一実施態様を示す。図３に示す例では、ＳＳＯはＳＡＭＬを用いて実現される。ＳＡＭＬフェデレーテッド認証は、「アイデンティティ・プロバイダ始動」または「サービス・プロバイダ始動」とすることができる。更に他の実施態様では、ＷＳフェデレーション、ＯＡｕｔｈ、ＯｐｅｎＩＤ、ＳｅｃｕｒｅＩＤ、ＬＤＡＰ、Ｋｅｒｂｅｒｏｓ、ＳｅｃｕｒｅＩＤ、Ｓｈｉｂｂｏｌｅｔｈ Ｓｙｓｔｅｍ、拡張アクセス・コントロール・マークアップ言語 （ＸＡＣＭＬ）、及びサービス・プロビジョニング・マークアップ言語（ＳＰＭＬ）等の様々なＳＳＯ技術が使用できる。

ＳＡＭＬに関して、ＳＡＭＬは、ＳａａＳアプリケーションであってもよいサービス・プロバイダ（例えば、ＳＰ２０２）と、ＩＤａａＳプロバイダであってもよいアイデンティティ・プロバイダ（例えば、ＩＤＰ２０８）との間でユーザセキュリティ情報を交換するための安全なＸＭＬベースのソリューションを提供する。ＳＡＭＬ ２．０ の記述は、Ｗｅｂ の＜ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＳＡＭＬ＿２．０＞； ＜ｈｔｔｐ：／／ｓａｍｌ．ｘｍｌ．ｏｒｇ／ｓａｍｌ−ｓｐｅｃｉｆｉｃａｔｉｏｎｓ＞； 及び＜ｈｔｔｐ：／／ｄｏｃｓ．ｏａｓｉｓ−ｏｐｅｎ．ｏｒｇ／ｓｅｃｕｒｉｔｙ／ｓａｍｌ／Ｐｏｓｔ２．０／ｓｓｔｃ−ｓａｍｌ−ｔｅｃｈ−ｏｖｅｒｖｉｅｗ−２．０．ｈｔｍｌ＞ にある。ＳＡＭＬを用いたＳＳＯの別の記述は、＜ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ／ｐａｇｅ／Ｓｉｎｇｌｅ＿Ｓｉｇｎ−Ｏｎ＿ｗｉｔｈ＿ＳＡＭＬ＿ｏｎ＿Ｆｏｒｃｅ．ｃｏｍ＞で見つけることができる。

図３において、ＩＤＰ２０８はアサートパーティであり、ＳＰ２０２はアサーションに依存するパーティであり、ブラウザ３３６でクライアントを操作するユーザ３２６はアサーションの対象である。ＩＤＰ２０８は、ユーザのアイデンティティを確認する情報を提供する権限システムである。ＳＰ２０２は、アイデンティティ・プロバイダのユーザ情報を信頼し、この情報を使用してＳａａＳアプリケーションへのアクセスを提供するシステムである。ＩＤＰ２０８からＳＰ２０２へのトランザクションは、ＳＡＭＬアサーションと呼ばれる。ＳＡＭＬアサーションの構造は、構造化情報標準促進協会（ＯＡＳＩＳ）のＳＡＭＬ規格によって指定されるＸＭＬスキーマによって定義される。ＳＡＭＬアサーションは、ヘッダ情報と、開始ＵＲＬ及びログアウトＵＲＬ等の属性及び条件の形式で、サブジェクトに関するステートメントとを含む。ＷｅｂブラウザＳＳＯは、ＳＡＭＬの最も広く使用されている機能であり、典型的には、ハイパーテキスト転送プロトコル（ＨＴＴＰ） ＰＯＳＴバインディング及び認証要求プロトコルと共に使用される。ウェブブラウザＳＳＯは、ユーザのセッションが確立されていない場合、ＩＤＰ２０８によって、またはＳＰ２０２によって開始することができる。アサーションはまた、ＩＤＰ２０８によってディジタル署名される。

図３において、ＳＰ２０２とＩＤＰ２０８との間の全ての通信は、ブラウザ３３６を介して行われる。交換１では、ユーザ３２６は、ＳＰ２０２によって表されるＳａａＳアプリケーション、または、ＳＰ２０２によってホストまたは提供される任意の他のリソースまたはサービスにログインしようと試みる。しかし、ユーザ３２６がＳＰ２０２によって提供されるサービスを使用することができる前に、ユーザ３２６の「アイデンティティ」は、ＩＤＰ２０８によって提供され、ＳＰ２０２によって認証され、受け入れられなければならない。これが、「認証」の意味するところである。「アイデンティティ」は、ＩＤＰ２０８がユーザ３２６のアイデンティティを確認すると、ＩＤＰ２０８がユーザ３２６に提供する「アサーション」である。これはＩＤＰ２０８とＳＰ２０２によってホストされたＳａａＳアプリケーションとの間の信頼関係を形成する。なぜなら、ユーザ３２６は、ＩＤＰ２０８によって提供されたアサーションを受け取り、認証のためにＳＰ２０２に別のクレデンシャルセットで再度ログインしなければならないのではなく、それを認証としてＳａａＳアプリケーションにアクセスするために使用するからである。一実施態様では、ＳＡＭＬ ２．０プロトコルは、他のＳａａＳアプリケーションが、認証検査がすでにＩＤＰ２０８によって成功裏に実行されたことの証拠として、提供されたアサーションを受け入れるので、認証信頼関係が確立され、実現される処理及び規格を提供し、ユーザ３２６がＩＤＰ２０８に対して一度認証し、次いで、セッション中に再認証する必要なく、アサーションを使用してＳａａＳアプリケーションにアクセスすることを可能にする。

それに応答して、交換２において、ＳＰ２０２は、ＩＤＰ２０８からの認証を要求するための認証要求、すなわち「ＳＡＭＬ要求」を生成する。交換３において、ＳＰ２０２は、ブラウザ３３６をＩＤＰ−ＵＲＬにリダイレクトする。他の実施態様では、リダイレクトは、ユーザ３２６のアプリケーションプログラムからのＡＰＩ呼び出しを介して行われる。交換４において、ＩＤＰ２０８は、例えば、ＩＤＰ２０８がより大きな信頼関係の一部であり、ユーザ３２６が別のＩＤＰからそれに提供されたアサーションを既に有する、マルチファクタ認証機構または以前のＩＤＰ認証セッションによって、ユーザ３２６を認証する。

ユーザ３２６の認証が成功すると、ＩＤＰ２０８は、ＸＭＬペイロードの形で交換５で「アサーション」または「ＳＡＭＬアサーション」を生成してブラウザ３３６に戻し、ユーザ３２６は、例えばＳＰ２０２によってホストされるアプリケーション等のＳａａＳアプリケーションにアクセスするために使用することができる。ユーザ３２６は、別のタイプの認証（例えば、ユーザ名／パスワードログイン）を実行する代わりに、アサーションをサービス・プロバイダ（例えば、ＳＰ２０２）に提示することができる。従って、交換６において、ＩＤＰ２０８は、アサーションをブラウザ３３６を介してＳＰ２０２のＡＣＳに送信し、ブラウザ３３６は、アサーションをＡＣＳ−ＵＲＬにポストする。

アサーション自体は、ＸＭＬ文書の形態の実際のアサーションと、本質的にＸＭＬ文書の暗号化されたバージョンであるアサーション署名との２つのコンポーネントを含む。署名は暗号化されているので、ＳＰ２０２は、図２に示すように、信頼関係の初期構成中に鍵を与えられていなければならない。交換７で、ＳＰ２０２のＡＣＳは、信頼関係の別個のオフラインまたは帯域外での確立中にＳＰ２０２で構成されたＩＤＰ公開鍵を使用してアサーションを検証する。一実施態様では、ＳＰ２０２は、アサーション文書を開き、クリアテキストＸＭＬコンポーネントと、一方向ハッシュ型署名であるため暗号化されていないディジタルＸＭＬ署名とを見る。ＸＭＬ署名構文及び処理に関する詳細を提供するドキュメントは、＜ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌｄｓｉｇ−ｃｏｒｅ／＞ にある。ディジタルＸＭＬ署名は、クリアテキストＸＭＬ コンテンツをハッシュし、得られた署名をディジタルＸＭＬ署名と比較することによって検証される。ブラウザ３３６は、実際には、ＸＭＬ署名生成に使用される鍵を有していない。ブラウザ３３６は、アサーションと共にＳＡＭＬ認証要求及びＳＡＭＬ応答を送信するが、署名または認証のために鍵を使用しない。ブラウザ３３６は、単なる経路であり、ＩＤＰ２０８からＳＰ２０２に署名されたアサーション応答を転送するだけである。

交換１〜７を通じた成功した進行の後、ＳＰ２０２内の要求されたリソースは、交換８において、ＳＰ２０２にログインしているユーザ３２６に返される。交換１〜７は、ユーザ３２６のための完全なＩＤＰ認証セッションを構成する。ユーザがＩＤＰ２０８に対して認証され、アサーションが提供されると、ユーザ３２６は、このアサーションを繰り返し使用することができる。幾つかの実施態様では、様々なサービス・プロバイダ及びＳａａＳアプリケーションが、暗号化公開鍵の共有によって、同じＩＤＰ２０８からのアサーションを受け入れるようにすでに構成されている場合、ユーザ３２６は、当該サービス・プロバイダ及びＳａａＳアプリケーションと共に該アサーションを使用することができる。
［信頼関係の修正］

フェデレーテッドＳＳＯに即して理解される信頼関係の確立を用いて、次に、既存のＣＡＳＢがこの信頼関係をどのように変更するかについて議論する。

上述したように、既存のＣＡＳＢは、図２及び図３で説明したように、ＩＤＰ暗号鍵を構成するのではなく、ＳＰにおいてＣＡＳＢまたはリバース・プロキシ暗号鍵を構成することによって、ＳＰとＩＤＰとの間の信頼関係を変更する。その結果、アサーションは、ＳＰとＩＤＰとの間で共有されるのではなく、ＳＰとＣＡＳＢまたはリバース・プロキシとの間で共有されるディジタル証明書または鍵を使用して、ＳＰにおいて検証される。

サービス・プロバイダとアイデンティティ・プロバイダとの間の信頼関係の既存のＣＡＳＢの修正は、様々な理由でほとんどの組織にとって望ましくない。例えば、信頼の修正は、現存するＣＡＳＢがアサーションのコンテンツにアクセスし、しばしばそれを修正するので、セキュリティ侵害の危険性を増大させる。アサーションは、ユーザクレデンシャル等の機密データを含むので、組織は、そのような機密データがＣＡＳＢに公開されることを好まない。開示されたテクノロジは、ＩＤＰにおいてアサーションを暗号化し、Ｎ−ＣＡＳＢがアサーションのコンテンツを変更することもアクセスすることも防止することによって、フェデレーテッドＳＳＯ認証セキュリティギャップを閉じる。

また、多くの場合、組織は、フェデレーテッドＳＳＯを容易にする、ＩＤａａＳプロバイダ等のアイデンティティ・プロバイダとのサービスレベルアグリーメント（ＳＬＡ）を有す。必然的に、ＳＬＡの技術的要件は、組織が、ＩＤａａＳプロバイダとそのＳａａＳアプリケーション・サブスクリプションとの間の直接的な信頼関係を確立し、維持することである。組織のＳａａＳアプリケーション・サブスクリプションとＩＤａａＳプロバイダとの間にそれらを挿入し、信頼関係を変更することによって、既存のＣＡＳＢは、当事者にそれらのＳＬＡの条件に違反させる。開示された技術は、図７−１４において以下に詳細に説明されるように、ＩＤＰとＳＰとの間の信頼関係を保持し、従って、ＳＬＡのコンプライアンスを実施することによって、この技術的問題を克服する。

図４では、このＳＳＯ認証方法が機能する前に、組織、会社、または企業は、ユーザの代わりに、ＩＤＰ公開鍵を構成する代わりに、ＳＰ４０２でＣＡＳＢ公開鍵を構成することによって、別個のオフラインまたは帯域外プロセスでＳＰ４０２とＩＤＰ４０８との間の信頼関係を変更する。幾つかの実施態様では、ＩＤＰ４０８のＵＲＬではなく、ＳＰ４０２でＣＡＳＢのＩＤＰ−ＵＲＬが構成され、それによってＳＰ４０２が認証リクエストをＩＤＰ４０８ではなくＣＡＳＢのＩＤＰに転送するので、信頼関係も変更される。図４に示す例では、信頼関係は変更子４２６を使用して変更される。従って、ＳＰ４０２は、ＩＤＰ４０８との独立した信頼関係をもはや有さない。

図４を補足すると、図５は、ＳＰ４０２とＩＤＰ４０８との間の信頼できる認証会話の途中に挿入されたインラインＣＡＳＢによって図４で修正された信頼に基づくフェデレーテッド・シングル・サインオン（ＳＳＯ）のメッセージ交換チャートの一実施態様を示す。図５に示す例では、ＳＰ４０２はＣＡＳＢ公開鍵とＣＡＳＢのＩＤＰ−ＵＲＬで構成され、ＩＤＰ４０８はＣＡＳＢのＡＣＳ−ＵＲＬで構成されている。従って、ＳＰ４０２は、ＩＤＰ４０８の代わりにＣＡＳＢのＩＤＰ５４８を信頼する。また、ＩＤＰ４０８は、ＳＰ４０２の代わりにＣＡＳＢのＳＰ５４２を信頼する。

図５において、ＳＰ４０２とＩＤＰ４０８との間の全ての通信は、ブラウザ３３６を介して行われる。交換１では、ユーザ３２６は、ＳＰ４０２によって表されるＳａａＳアプリケーション、または、ＳＰ４０２によってホストまたは提供される任意の他のリソースまたはサービスにログインしようと試みる。しかし、ユーザ３２６がＳＰ４０２によって提供されるサービスを使用することができる前に、ユーザ３２６の「アイデンティティ」は、ＩＤＰ４０８によって提供され、ＳＰ４０２によって認証され、受け入れられなければならない。これが、「認証」の意味するところである。これに応答して、交換２において、ＳＰ４０２は認証要求、すなわち「ＳＡＭＬ要求」を生成し、これはＩＤＰ−ＵＲＬではなくＣＡＳＢのＩＤＰ−ＵＲＬに転送される。交換３において、ＳＰ４０２は、ブラウザ３３６をＣＡＳＢのＩＤＰ−ＵＲＬにリダイレクトする。交換４において、ＣＡＳＢ ＩＤＰ ５４８は、ブラウザ３３６をＩＤＰ−ＵＲＬにリダイレクトする。他の実施態様では、リダイレクトは、ユーザ３２６のアプリケーションプログラムからのＡＰＩ呼び出しを介して行われる。

交換５において、ＩＤＰ４０８は、例えば、ＩＤＰ４０８がより大きな信頼関係の一部であり、ユーザ３２６が別のＩＤＰからそれに提供されたアサーションを既に有する、マルチファクタ認証機構または以前のＩＤＰ認証セッションによって、ユーザ３２６を認証する。ユーザ３２６の認証が成功すると、ＩＤＰ４０８は、ＸＭＬペイロードの形で交換６で「アサーション」または「ＳＡＭＬアサーション」を生成してブラウザ３３６に戻し、ユーザ３２６は、それを、例えばＳＰ４０２によってホストされるアプリケーション等のＳａａＳアプリケーションにアクセスするために使用することができる。ユーザ３２６は、別のタイプの認証（例えば、ユーザ名／パスワードログイン）を実行する代わりに、アサーションをサービス・プロバイダ（例えば、ＳＰ４０２）に提示することができる。従って、交換７において、ＩＤＰ４０８は、アサーションを、ＳＰ４０２のＡＣＳではなく、ブラウザ３３６を介してＣＡＳＢ ＳＰ５４２のＡＣＳに送信する。

交換８において、ＩＤＰ公開鍵で構成されるＣＡＳＢ ＳＰ５４２は、ＩＤＰ公開鍵を使用してアサーションを検証し、ＣＡＳＢ秘密鍵を使用してアサーションを再認証する。また、交換８において、ＣＡＳＢはトラフィックを評価して、トラフィックが管理デバイスからルーティングされているか、非管理デバイスからルーティングされているかを判定する。トラフィックが管理デバイスからルーティングされる場合、交換９において、ＣＡＳＢ ＳＰ５４２は、ブラウザ３３６を介してＳＰのＡＣＳ−ＵＲＬに再認証されたアサーションをポストする。次に、交換１０において、ＳＰのＡＣＳは、ＣＡＳＢ公開鍵を使用して再認証されたアサーションを検証する。アサーションがＳＰ４０２によって検証されると、ユーザは交換１１でＳａａＳアプリケーションにログインする。

対照的に、交換８において、トラフィックが非管理デバイスからルーティングされているとＣＡＳＢが判定した場合、交換１２において、ＣＡＳＢ ＳＰ５４２は、再認証されたアサーションを、ＳＰのＡＣＳ−ＵＲＬにポストする代わりに、ブラウザ３３６を介してリバース・プロキシ６０２にポストする。一実施態様では、これは、リバース・プロキシ・ドメインを、再認証されたアサーションがポストされるべきであったＳＰのＡＣＳ−ＵＲＬまたはＳａａＳアプリケーションＵＲＬ（ＳＰ４０２によって提供される）に追加することによって行われる。例えば、ＳａａＳアプリケーションＵＲＬが「ｌｏｇｉｎ．ｓａａｓａｐｐｌｉｃａｔｉｏｎ．ｃｏｍ」である場合、再認証されたアサーションは、「ｌｏｇｉｎ．ｓａａｓａｐｐｌｉｃａｔｉｏｎ．ｃｏｍ／ｒｅｖｅｒｓｅｐｒｏｘｙｄｏｍｉａｎ」にポストされる。

図６は、ポリシー実施のための、非管理デバイスからネットワーク・セキュリティ・システムへのリバース・プロキシルーティングトラフィックの一実施態様を示す。ネットワーク・セキュリティ・システムは、フォワード・プロキシまたはプロキシ・サーバとしても機能することができる。リバース・プロキシの一般的な使用法の一覧は、＜ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｒｅｖｅｒｓｅ＿ｐｒｏｘｙ＞にある。

交換１３では、リバース・プロキシ（ＲＰ）６０２は、復号化されたアサーションを伴う検証トークンを検証した後、再認証されたアサーションのＳＰのＡＣＳ−ＵＲＬからリバース・プロキシ・ドメインを取り除き、交換１４で再認証されたアサーションをネットワーク・セキュリティ・システムまたはフォワード・プロキシ（ＦＰ）６０４に転送する。検証トークンは、クッキー、変更されたＵＲＬに埋め込まれたパラメータ、及び／または要求において識別されたヘッダであってもよい。ＦＰ ６０４は、交換１５において、ＳＰ４０２へのアクセスを制御するために、ルーティングされたトラフィックにセキュリティ・ポリシーを実行する。ルーティングされたトラフィックが、ネットワーク・セキュリティ・システムまたはフォワード・プロキシ６０４によって、ブロッキングまたはセキュリティ・ポリシーに基づく別のセキュリティ・アクションに適格でないと判定された場合、再認証されたアサーションは、交換１６でＳＰ４０２に送信される。

交換１７において、ＳＰ４０２のＡＣＳは、管理されたデバイスの場合に交換１０において有するように、ＣＡＳＢ公開鍵を使用してアサーションを検証する。更に、交換１８でＳＰ４０２によって返されるページは、複数のＵＲＬを含み、これらのＵＲＬは、交換機１９でネットワーク・セキュリティ・システムまたはフォワード・プロキシ６０４によってリバース・プロキシ６０２に転送される。リバース・プロキシ６０２は、ユーザ３２６がＵＲＬをクリックすると、ユーザが直接ＳＰ４０２に行く代わりに、ポリシー実施のためにネットワーク・セキュリティ・システムまたはフォワード・プロキシ６０４を介してユーザがトンネリングされるように、これらのＵＲＬを書き換える。このようにして、非管理デバイスからの任意の後続のトラフィックは、ネットワーク・セキュリティ・システムまたはフォワード・プロキシ６０４を介して強制的にルーティングされる。
［システム概要］

フェデレーテッドＳＳＯ認証に即して理解される信頼関係の修正を用いて、ここで、開示されるＮ−ＣＡＳＢが、どのようにして、サービス・プロバイダとアイデンティティ・プロバイダとの間の信頼関係または信頼チェーンまたは信頼会話を保持するかについて議論する。

サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）の間のフェデレーテッドＳＳＯのために確立された信頼関係を保持し、ＳＰを含むトランザクションにネットワークセキュリティ・ポリシーを実行するためのシステムと様々な実施態様について述べた。本システムは、図１を参照して説明され、本実施態様によるシステムのアーキテクチャ・レベルの概略図を示す。図１はアーキテクチャ図であるので、説明の明確さを改善するために、特定の詳細は意図的に省略される。図１の説明は以下のように構成される。最初に、図の要素が説明され、その後にそれらの相互接続が続く。次に、システムにおける要素の使用をより詳細に説明する。最後に、プロセスを図７−１３に示す。

図１は、ＳＰ１０２（１または複数の ＳａａＳアプリケーションをホストする）及びＩＤＰ１０８（ＩＤａａＳを表す）を含む。このシステムは、Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ（Ｎ−ＣＡＳＢ）１６０、アサーション・プロキシ１７０、リバース・プロキシ１８０、及びネットワーク・セキュリティ・システム１９０も含む。幾つかの実施態様では、プロキシ１７０、１８０、及び１９０は、Ｎ−ＣＡＳＢ１６０の結合されたユニット部分として一緒にホストされる。他の実施態様では、それらは別々にホストされる。一実施態様では、アサーション・プロキシ１７０及びリバース・プロキシ１８０は、アサーション・プロキシ１７０及びリバース・プロキシ１８０の両方の機能を実行する単一のプロキシに結合される。幾つかの実施態様では、プロキシ１７０、１８０、及び１９０は、クラウドベースのプロキシである。他の実施態様では、プロキシ１７０、１８０、及び１９０は、オンプレミス・プロキシである。ネットワーク・セキュリティ・システム１９０は、とりわけ、コンテンツポリシー１９１、コンテンツプロファイル１９２、コンテンツ検査ルール１９３、企業データ１９４、及びユーザ・アイデンティティ１９６を格納する。幾つかの実施態様では、ネットワーク・セキュリティ・システム１９０は、１または複数のテナントからの情報を共有データベース画像のテーブルに格納して、オンデマンドデータベースサービス（ＯＤＤＳ）を形成することができ、これは、マルチテナントデータベースシステム（ＭＴＤＳ）等の多くの方法で実施することができる。データベース画像は、１または複数のデータベースオブジェクトを含むことができる。他の実装形態では、データベースは、リレーショナル・データベース管理システム（ＲＤＢＭＳ）、オブジェクト指向データベース管理システム（ＯＯＤＢＭＳ）、分散ファイル・システム（ＤＦＳ）、ノースキーマデータベース、または任意の他のデータ記憶システムもしくはコンピューティング・デバイスとすることができる。クライアント・デバイス１５０は、モバイル１５２及びコンピュータ１５４を含む。

実施態様では、図１に示されるシステムは、ログベースディスカバリ、ディープＡＰＩ検査（ＤＡＰＩＩ）、イントロスペクション、インラインエージェントレスステアリング、インラインシンエージェントまたはモバイルプロファイルステアリング等の様々な機構及びコンポーネントを使用してＳａａＳアプリケーションへのアクセスを制御しながら、ＳＰ１０２とＩＤＰ１０８との間の信頼関係を保持する、本明細書では「Ｎｅｔｓｋｏｐｅ−ＣＡＳＢ」と呼ばれる改良されたＣＡＳＢ、リバース・プロキシ１８０、ネットワーク・セキュリティ・システム１９０、モニタ１２０、アクティブアナライザ１３０、検査アナライザ１４０、抽出エンジン１２１、分類エンジン１２２、セキュリティエンジン１２３、マネジメントプレーン１２４、及びデータプレーン１２５を含む。Ｎ−ＣＡＳＢ１６０の機能性に関する追加の情報については、例えば、同一出願人の米国特許出願第１４／１９８，４９９号、第１４／１９８，５０８号、第１４／８３５，６４０号、第１４／８３５，６３２号、及び、第６２／３０７，３０５号； チェン、イタール、ナラヤナスワミー、及びマルムスコッグ、「ダミーのためのクラウド・セキュリティ、ネットスコープ・スペシャルエディション、Ｊｏｈｎ Ｗｉｌｅｙ＆Ｓｏｎｓ，Ｉｎｃ．２０１５； ネットスコープ，インクの「ネットスコープ内観」； ネットスコープ，インクの「クラウドにおけるデータ損失防止と監視」； ネットスコープ，インクの「クラウド・データ損失防止参照アーキテクチャ」； ネットスコープ，インクの「クラウド信頼への５つのステップ」； ネットスコープ，インクの「ネットスコープ・アクティブ・プラットフォーム」； ネットスコープ，インクの「ネットスコープの利点：クラウド・アクセス・セキュリティ・ブローカのための３つの“必携”要件」； ネットスコープ，インクの「重要な１５のＣＡＳＢ使用事例」； ネットスコープ，インクの「ネットスコープ・アクティブ・クラウドＤＬＰ」； ネットスコープ，インクの「クラウド・データ侵害の衝突コースを修復する」； ネットスコープ，インクの「Ｎｅｔｓｋｏｐｅ Ｃｌｏｕｄ Ｃｏｎｆｉｄｅｎｃｅ Ｉｎｄｅｘ（商標）」を参照されたい。

次に、図１に示すシステムの要素の相互接続について説明する。ネットワーク１１５は、モバイル１５２、コンピュータ１５４、ＳＰ１０２、ＩＤＰ１０８、及びＮ−ＣＡＳＢ１６０を通信可能に結合する（実線で示す）。実際の通信経路は、公衆及び／またはプライベート・ネットワーク上のポイントツーポイントであり得る。通信の全ては、様々なネットワーク、例えば、プライベート・ネットワーク、ＶＰＮ、ＭＰＬＳ回路、またはインターネットを介して行うことができ、適切なＡＰＩ及びデータ交換フォーマット、例えば、ＲＥＳＴ、ＪＳＯＮ、ＸＭＬ、ＳＯＡＰ、及び／またはＪＭＳを使用することができる。全ての通信を暗号化することができる。この通信は、一般に、ＬＡＮ （ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話ネットワーク（公衆交換電話ネットワーク（ＰＳＴＮ））、セッション開始プロトコル（ＳＩＰ）、無線ネットワーク、ポイントツーポイントネットワーク、星型ネットワーク、トークンリング型ネットワーク、ハブ型ネットワーク、インターネット等のネットワークを通して行われる。尚、インターネットは、ＥＤＧＥ、３Ｇ、４ＧＬＴＥ、Ｗｉ−Ｆｉ、及びＷｉＭＡＸ等のプロトコルを介するモバイルインターネットを含む。更に、ユーザ名／パスワード、ＯＡｕｔｈ、Ｋｅｒｂｅｒｏｓ、ＳｅｃｕｒｅＩＤ、ディジタル証明書等の様々な承認及び認証技術を使用して、通信を保護することができる。

モニタ１２０及びネットワーク・セキュリティ・システム１９０は、互いに通信するように結合された１または複数のコンピュータ及びコンピュータ・システムを含むことができる。また、それらは、１または複数の仮想コンピューティング及び／または記憶リソースであってもよい。例えば、モニタ１２０は、１または複数ののＡｍａｚｏｎ ＥＣ２インスタンスとすることができ、ネットワーク・セキュリティ・システム１９０は、Ａｍａｚｏｎ Ｓ３ストレージとすることができる。直接物理コンピュータまたは従来の仮想マシン上でＮ−ＣＡＳＢ１６０を実装するのではなく、Ｓａｌｅｓｆｏｒｃｅ（商標）のＦｏｒｃｅ．Ｃｏｍ（商標）、Ｒａｃｋｓｐａｃｅ（商標）、またはＨｅｒｏｋｕ（商標）等の他のコンピューティング・アズ・サービス・プラットフォームを、使用することができる。更に、Ｎ−ＣＡＳＢ１６０の機能を実施するために、１または複数のエンジンを使用することができ、１または複数の ポイント・オブ・プレゼンス（ＰＯＰ）を確立することができる。エンジンは、ワークステーション、サーバ、コンピューティング・クラスタ、ブレード・サーバ、サーバ・ファーム、または任意の他のデータ処理システムもしくはコンピューティング・デバイスを含む様々なタイプのものとすることができる。該エンジンは、異なるネットワーク接続を介してデータベースに通信可能に接続し得る。例えば、抽出エンジン１２１は、ネットワーク１１５（例えば、インターネット）を介して結合することができ、分類エンジン１２２は、直接ネットワークリンクを介して結合することができ、セキュリティエンジン１２３は、更に異なるネットワーク接続によって結合することができる。他の例では、データプレーン１２５のＰＯＰは、地理的に分散されることができ、及び／または特定のクラウド・サービス及び共同ホストされることができる。同様に、管理プレーン１２４のＰＯＰは、地理的に分散することができる。２つのタイプのＰＯＰは、別々にホストすることも、共同ホストすることもできる。

図１の要素及びそれらの相互接続を説明したので、図の要素をここでより詳細に説明する。Ｎ−ＣＡＳＢ１６０は、管理プレーン１２４及びデータプレーン１２５を介して様々な機能を提供する。データプレーン１２５は、一実施態様によれば、抽出エンジン１２１、分類エンジン１２２、及びセキュリティエンジン１２３を含む。他の機能、例えば、制御プレーンを提供することもできる。これらの機能は、集合的に、クライアント・デバイス１５０によるＳＰ１０２との安全なインターフェイスを提供する。ネットワーク・セキュリティ・システムという用語を使用してＮ−ＣＡＳＢ１６０を説明するが、より一般的には、システムは、アプリケーションの視認性及び制御機能並びにセキュリティを提供する。

一実施態様によれば、ネットワーク・セキュリティ・システム１９０は、コンテンツポリシー１９１を定義し管理するためにＮ−ＣＡＳＢ１６０によって提供される安全なウェブ配信インターフェイスを有するウェブブラウザを有する複数のコンピュータデバイスを含む。幾つかの実施態様によれば、Ｎ−ＣＡＳＢ１６０は、マルチテナントシステムであるので、管理クライアントのユーザは、自分の組織に関連するコンテンツポリシー１９１のみを変更することができる。幾つかの実装形態では、ポリシーをプログラムで定義及び／または更新するためにＡＰＩを提供することができる。そのような実施態様では、ネットワーク・セキュリティ・システム１９０は、コンテンツポリシー１９１に対する更新のためのプル要求に応答する、例えば、マイクロソフトアクティブディレクトリ等の企業ＩＤディレクトリ等の１または複数のサーバを含むことができる。両システムは共存できる。例えば、幾つかの会社は、組織内のユーザの要求に対してポリシーを調整するためのウェブインターフェイスを用いるとともに、組織内のユーザの識別を自動化する企業ＩＤディレクトリを用いることもできる。管理クライアントには役割が割り当てられており、ネットワーク・セキュリティ・システム１９０のデータへのアクセスは、読み出し専用、対、読み出し書き込み等の役割に基づいて制御される。

Ｎ−ＣＡＳＢ１６０がどのように機能するかの一般的な考えが提供された。ＳａａＳアプリケーションの使用をより安全にすることを望む企業、またはより一般的には任意の個人またはエンティティは、Ｎ−ＣＡＳＢ１６０に契約する。ウェブベースのインターフェイス及びコンピュータ装置を使用して、企業は、ユーザのためのコンテンツポリシー１９１内にポリシーを確立することができる。コンテンツの操作を伴う各アクティビティについて、１または複数のコンテンツ検査ルールがＮ−ＣＡＳＢ１６０によってコンテンツに適用される。コンテンツがコンテンツ制御の対象である、すなわち機密データであると判定された場合、コンテンツに含まれる機密データの漏洩または侵害を防止するために、１または複数のセキュリティ・アクションが起動される。さて、これらのアプローチは、両方ともより詳細に議論される。

図１に示されるシステムは、特定のブロックを参照して本明細書で説明されるが、ブロックは、説明の便宜のために定義され、コンポーネント部品の特定の物理的配置を必要とすることを意図しないことを理解されたい。更に、ブロックは、物理的に異なるコンポーネントに対応する必要はない。物理的に異なるコンポーネントが使用される限り、（例えば、データ通信のための）コンポーネント間の接続は、必要に応じて有線及び／または無線とすることができる。異なる要素またはコンポーネントは、単一のソフトウェア・モジュールに組み合わせることができ、複数のソフトウェア・モジュールは、同じハードウェア上で実行することができる。
［信頼関係の保持］

図７は、Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）１７０によるフェデレーテッドＳＳＯセッション中の信頼関係保持の一実施態様を示す。特に、図７は、ＳＡＭＬに基づくフェデレーテッドＳＳＯのメッセージ交換チャートの一実施態様を示す。Ｎ−ＣＡＳＢのＡＰ１７０を有するＳＡＭＬフェデレーテッド認証方法としての「サービス・プロバイダ始動」ログイン方法だけの詳細な記述が、開示された技術の一実施態様で開示されているが、「アイデンティティ・プロバイダ始動」ログインを含む他のタイプのＳＡＭＬ認証方法が、本開示から容易に導出され、開示された技術の範囲内であることを理解されたい。代替のメッセージ交換及びシーケンスも可能である。例えば、「アイデンティティ・プロバイダ始動」ログインでは、初期ログインはアイデンティティ・プロバイダ（その公開鍵はサービス・プロバイダで構成される）に向けられ、アイデンティティ・プロバイダはアサーションをＮ−ＣＡＳＢのＡＰ１７０に転送する。他の実施態様では、ＷＳフェデレーション、ＯＡｕｔｈ、ＯｐｅｎＩＤ、ＳｅｃｕｒｅＩＤ、ＬＤＡＰ、Ｋｅｒｂｅｒｏｓ、ＳｅｃｕｒｅＩＤ、Ｓｈｉｂｂｏｌｅｔｈ Ｓｙｓｔｅｍ、ｅＸｔｅｎｓｉｂｌｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＡＣＭＬ）、及びサービス・プロビジョニング・マークアップ言語（ＳＰＭＬ）等の様々なフェデレーテッドＳＳＯ技術が使用できる。

図７は、サービス・プロバイダ（ＳＰ）７０２及びアイデンティティ・プロバイダ（ＩＤ）７０８を含む。図３に示す構成と同様に、別個のオフラインまたは帯域外プロセスにおいて、ＳＰ７０２は、ＩＤＰ７０８の公開鍵及びＩＤＰ７０８のＵＲＬで構成される。また、別個のオフラインまたは帯域外プロセスでは、ＩＤＰ７０８は、ＳＰ７０２のＡＣＳ−ＵＲＬ、Ｎ−ＣＡＳＢのＡＰ１７０のＵＲＬ、及びＮ−ＣＡＳＢのＡＰ１７０の公開鍵で構成される。

一実施態様では、開示された技術は、ＳＰ７０２とＩＤＰ７０８との間の信頼チェーンではなく、ＳＰ７０２とＩＤＰ７０８との間のアサーション転送チェーンにＮ−ＣＡＳＢのＡＰ１７０を挿入することによって、フェデレーテッドＳＳＯ中にＳＰ７０２とＩＤＰ ７０８との間の信頼関係を保持する。

別の実施態様では、開示された技術は、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０のディジタル証明書または鍵を構成する代わりに、ＳＰ７０２においてＩＤＰ７０８のディジタル証明書または鍵を構成し、ＳＰ７０２において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０の公開鍵を使用するのではなく、ＩＤＰ７０８の公開鍵を使用してＩＤＰ７０８によって生成されたアサーションを検証することによって、フェデレーテッドＳＳＯ中にＳＰ７０２とＩＤＰ７０８との間の信頼関係を保持する。

更に別の実施態様では、開示された技術は、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０のＵＲＬではなく、ＩＤＰ７０８のＵＲＬに認証リクエストを転送するようにＳＰ７０２を構成することによって、フェデレーテッドＳＳＯ中にＳＰ７０２とＩＤＰ ７０８との間の信頼関係を保持する。

さらなる実施態様では、開示された技術は、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０が、ＩＤＰ７０８によって生成されるアサーションのコンテンツにアクセスし、それを変更することを防止することによって、フェデレーテッドＳＳＯ中にＳＰ７０２とＩＤＰ７０８との間の信頼関係を保持する。

図７において、ＳＰ７０２とＩＤＰ７０８との間の全ての通信は、ブラウザ３３６を介して行われる。交換１では、ユーザ３２６は、ＳＰ７０２によって表されるＳａａＳアプリケーション、またはＳＰ７０２によってホストされるかまたは提供される任意の他のリソースまたはサービスにログインしようと試みる。しかし、ユーザ３２６がＳＰ７０２によって提供されるサービスを使用することができる前に、ユーザ３２６の「アイデンティティ」は、ＩＤＰ７０８によって提供され、ＳＰ７０２によって認証され、受け入れられなければならない。これが、「認証」の意味するところである。これに応答して、交換２において、ＳＰ７０２は認証要求、すなわち「ＳＡＭＬ要求」を生成し、これはＩＤＰ７０８のＵＲＬに転送される。交換３において、ＳＰ７０２は、ブラウザ３３６をＩＤＰ７０８のＵＲＬにリダイレクトする。他の実施態様では、リダイレクトは、ユーザ３２６のアプリケーションプログラムからのＡＰＩ呼び出しを介して行われる。

交換４において、ＩＤＰ７０８は、例えば、ＩＤＰ７０８がより大きな信頼関係の一部であり、ユーザ３２６が別のＩＤＰからそれに提供されたアサーションを既に有する、マルチファクタ認証機構または以前のＩＤＰ認証セッションによって、ユーザ３２６を認証する。ユーザ３２６の認証が成功すると、ＩＤＰ７０８は、交換５で「アサーション」または「ＳＡＭＬアサーション」を生成する。

アサーション自体の中で、ＩＤＰ７０８は宛先／受信者ＵＲＬを識別する。ＩＤＰ７０８は、宛先／受信者ＵＲＬをＳＰ７０２のＡＣＳ−ＵＲＬとして識別するように構成される。このようなＩＤＰ及びアサーション構成は、アサーション内の宛先／受信者ＵＲＬを、ＳＰのＡＣＳ−ＵＲＬではなく、ＣＡＳＢ−ＵＲＬまたはリバース・プロキシＵＲＬに変更または修正する、既存のＣＡＳＢによって実施されるＩＤＰ及びアサーション構成とは異なる。幾つかの実施態様によれば、開示された技術は、Ｎ−ＣＡＳＢ１６０及び／またはＮ−ＣＡＳＢのＡＰ１７０が、ＩＤＰ７０８によって生成されたアサーションのコンテンツ（例えば、アサーションの宛先／受信者ＵＲＬ）にアクセスし、それを変更することを防止することによって、これを達成する。

生成されると、ＩＤＰ７０８は、ＩＤＰ秘密鍵を使用してアサーションを証明し、Ｎ−ＣＡＳＢのＡＰ１７０の公開鍵を使用して証明されたアサーションを暗号化する。Ｎ−ＣＡＳＢのＡＰ１７０またはＮ−ＣＡＳＢ１６０が暗号化されたアサーションを復号化しなければ、ユーザ３２６は暗号化されたアサーションを使用してＳＰ７０２にアクセスすることができないので、暗号化は、ユーザ３２６がＮ−ＣＡＳＢのＡＰ１７０またはＮ−ＣＡＳＢ １６０をバイパスすることができないことを保証する。

交換６において、ＩＤＰ７０８は、暗号化され証明されたアサーションをＮ−ＣＡＳＢのＡＰ１７０に転送する。暗号化され証明されたアサーションのＮ−ＣＡＳＢのＡＰ１７０へのポスティングは、ＩＤＰ７０８によって生成されたアサーションのコンテンツにアクセスまたは変更することなく達成されることに留意されたい。特に、ポスティングは、アサーションの宛先／受信者ＵＲＬを変更または修正することなく行われる。一実施態様では、これは、上述のように、Ｎ−ＣＡＳＢのＡＰ１７０のＵＲＬを有するＩＤＰ７０８のオフラインまたは帯域外構成によって達成される。この構成は、暗号化され証明されたアサーションがＮ−ＣＡＳＢのＡＰ１７０にポストされることを確実にし、従って、アサーション内の宛先／受信者ＵＲＬを変更または修正する必要を未然に回避する。

交換７において、Ｎ−ＣＡＳＢのＡＰ１７０は、Ｎ−ＣＡＳＢのＡＰ１７０の秘密鍵を使用して暗号化されたアサーションを復号化する。また、交換７において、Ｎ−ＣＡＳＢ １６０またはＮ−ＣＡＳＢのＡＰ１７０は、トラフィックを評価して、トラフィックが管理されたデバイスからルーティングされているか、または非管理デバイスからルーティングされているかを判定する。トラフィックが管理デバイスからルーティングされる場合、交換８において、Ｎ−ＣＡＳＢのＡＰ１７０は、アサーション内で識別されたＳＰ７０２のＡＣＳ−ＵＲＬに、復号化されたアサーションをポストする。次に、交換１０において、ＳＰ７０２のＡＣＳは、ＩＤＰ公開鍵を使用して、復号化されたアサーションを検証する。これは、フェデレーテッドＳＳＯ認証の場合、ＩＤＰ公開鍵の代わりにＣＡＳＢ公開鍵を使用し、その結果、ＳＰとＩＤＰとの間の信頼関係を変更する既存のＣＡＳＢとは対照的である。

アサーションがＳＰ７０２によって検証されると、ユーザは交換１０でＳａａＳアプリケーションにログインする。

対照的に、交換７において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０が、トラフィックが非管理デバイスからルーティングされていると判定した場合、交換１０において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０は、復号化されたアサーションを、ＳＰ７０２のＡＣＳにポストする代わりに、ブラウザ３３６を介してリバース・プロキシ１８０にポストする。一実施態様では、これは、リバース・プロキシ・ドメインを、ＳＰ７０２のＡＣＳ−ＵＲＬに、または復号化されたアサーションがポストされるべきであったＳａａＳアプリケーションＵＲＬ（ＳＰ７０２によって提供される）に追加することによって行われる。例えば、ＳａａＳアプリケーションＵＲＬが「ｌｏｇｉｎ．ｓａａｓａｐｐｌｉｃａｔｉｏｎ．ｃｏｍ」である場合、復号化されたアサーションは、「ｌｏｇｉｎ．ｓａａｓａｐｐｌｉｃａｔｉｏｎ．ｃｏｍ／ｒｅｖｅｒｓｅｐｒｏｘｙｄｏｍｉａｎ」にポストされる。

図８は、ポリシー実行のための、非管理デバイスからネットワーク・セキュリティ・システムへのリバース・プロキシルーティングトラフィックの別の実施態様を示す。リバース・プロキシの一般的な使用法の一覧は、＜ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｒｅｖｅｒｓｅ＿ｐｒｏｘｙ＞にある。

交換１２において、リバース・プロキシ（ＲＰ）１８０は、復号化されたアサーションのＳＰ７０２のＡＣＳ−ＵＲＬからリバース・プロキシ・ドメインを取り除き、復号化されたアサーションを交換１３のネットワーク・セキュリティ・システムまたはフォワード・プロキシ（ＦＰ）１９０に転送する。ＦＰ１９０は、交換１４において、図１の説明で上述したように、ＳＰ７０２へのアクセスを制御するために、ルーティングされたトラフィックにセキュリティ・ポリシーを実施する。ルーティングされたトラフィックが、ネットワーク・セキュリティ・システム１９０によって、セキュリティ・ポリシーに基づいてブロッキングまたは別のセキュリティ・アクションに適格でないと判定された場合、復号化されたアサーションは、交換１５でＳＰ７０２に送信される。

交換１６で、ＳＰ７０２のＡＣＳは、管理デバイスの場合に交換９で有するように、ＩＤＰ７０８の公開鍵を使用してアサーションを検証する。更に、交換１７でＳＰ７０２によって返されるページは、交換１８でネットワーク・セキュリティ・システム１９０によってリバース・プロキシ１８０に転送される複数のＵＲＬを含む。リバース・プロキシ６０２は、ユーザ３２６がＵＲＬをクリックすると、ユーザが直接ＳＰ７０２に行く代わりに、ポリシー実行のためにネットワーク・セキュリティ・システム１９０を介してトンネリングされるように、これらのＵＲＬを書き換える。このようにして、非管理デバイスからの任意の後続のトラフィックは、ネットワーク・セキュリティ・システム１９０を介して強制的にルーティングされる。

図９は、Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）１７０によるフェデレーテッドＳＳＯセッション中の信頼関係保持の別の実施態様を示す。特に、図９は、ＷＳフェデレーション・プロトコルに基づくフェデレーテッドＳＳＯのメッセージ交換チャートの一実施態様を示す。幾つかの実施態様では、ＷＳ−フェデレーションは、Ｏｆｆｉｃｅ ３６５（商標）のようなＭｉｃｒｏｓｏｆｔ製品で使用されるフェデレーテッドＳＳＯ認証方法である。

図９において、サービス・プロバイダ、アイデンティティ・プロバイダ、Ｎ−ＣＡＳＢ、及びＮ−ＣＡＳＢのＡＰ１７０の構成は、図７のＳＰ７０２、ＩＤＰ７０８、Ｎ−ＣＡＳＢ１６０、及びＮ−ＣＡＳＢ１７０の構成とよく似ており、その結果、サービス・プロバイダとアイデンティティ・プロバイダとの間の信頼関係は、上述のように保持される。従って、交換１〜５及び交換７〜２０は、図７−８において、それぞれの交換１〜５及び交換７〜２０に直接対応する。しかし、ＷＳ−フェデレーション・プロトコルに従い、図９の交換６において、ＩＤＰ７０８は、ブラウザ３３６にリダイレクトすることなく、認証され暗号化されたアサーションをＮ−ＣＡＳＢのＡＰ１７０に直接提供する。これは、認証され暗号化されたアサーションがブラウザ３３６を介してＮ−ＣＡＳＢのＡＰ１７０に提供されるＳＡＭＬプロトコルとは異なる。

図１０は、Ｎ−ＣＡＳＢアサーション・プロキシ（ＡＰ）１７０によるフェデレーテッドＳＳＯセッション中の信頼関係保持の一実施態様を示す。特に、図１０は、アイデンティティ・プロバイダがサービス・プロバイダの公開鍵を使用してアサーションを暗号化するように構成される、ＳＡＭＬに基づくフェデレーテッドＳＳＯのメッセージ交換チャートの一実施態様を示す。斯かる構成は、Ｂｏｘ（商標）等の特定のＳａａＳアプリケーションにおいて一般的である。開示された技術は、ＩＤＰがＳＰ公開鍵の代わりにＮ−ＣＡＳＢ公開鍵を使用して第１のアサーション暗号化を実行し、Ｎ−ＣＡＳＢのＡＰ１７０がＩＤＰで構成された同じＳＰ公開鍵を使用して第２のアサーション暗号化を実行する「二重暗号化」技術を使用することによって、そのような構成を処理する。第２のアサーション暗号化の前に、Ｎ−ＣＡＳＢのＡＰ１７０は、Ｎ−ＣＡＳＢのＡＰ秘密鍵を使用してアサーションを復号化する。

図１０は、サービス・プロバイダ（ＳＰ）１００２及びアイデンティティ・プロバイダ（ＩＤ）１００８を含む。別個のオフラインまたは帯域外プロセスでは、ＳＰ１００２は、ＩＤＰ１００８の公開鍵及びＩＤＰ１００８のＵＲＬで構成される。これらのステップは、請求項７０のシステムの構成手段において具現化される。また、別途のオフラインまたは帯域外プロセスにおいて、ＩＤＰ１００８は、ＳＰ１００２のＡＣＳ−ＵＲＬ、Ｎ−ＣＡＳＢのＡＰ１７０のＵＲＬ、ＳＰ１００２の公開鍵、及びＮ−ＣＡＳＢのＡＰ１７０の公開鍵で構成される。また、別個のオフラインまたは帯域外プロセスでは、Ｎ−ＣＡＳＢ１７０は、ＳＰ１００２の同じ公開鍵をＩＤＰ１００８と共有するように構成される。

図１０において、ＳＰ１００２とＩＤＰ１００８との間の全ての通信は、ブラウザ３３６を介して行われる。交換１では、ユーザ３２６は、ＳＰ１００２によって表されるＳａａＳアプリケーション、または、ＳＰ１００２によってホストまたは提供される任意の他のリソースまたはサービスにログインしようと試みる。しかし、ユーザ３２６がＳＰ１００２によって提供されるサービスを使用することができる前に、ユーザ３２６の「アイデンティティ」は、ＩＤＰ１００８によって提供され、ＳＰ１００２によって認証され、受け入れられなければならない。これが、「認証」の意味するところである。これに応答して、交換２において、ＳＰ１００２は認証要求、すなわち「ＳＡＭＬ要求：」を生成し、該要求はＩＤＰ１００８のＵＲＬに転送される。交換３において、ＳＰ１００２は、ブラウザ３３６をＩＤＰ１００８のＵＲＬにリダイレクトする。他の実施態様では、リダイレクトは、ユーザ３２６のアプリケーションプログラムからのＡＰＩ呼び出しを介して行われる。

交換４において、ＩＤＰ１００８は、例えば、ＩＤＰ１００８がより大きな信頼関係の一部であり、ユーザ３２６が別のＩＤＰからそれに提供されたアサーションを既に有する、マルチファクタ認証機構または以前のＩＤＰ認証セッションによって、ユーザ３２６を認証する。ユーザ３２６の認証が成功すると、ＩＤＰ１００８は、交換５で「アサーション」または「ＳＡＭＬアサーション」を生成する。

アサーション自体の中で、ＩＤＰ１００８は、宛先／受信者ＵＲＬを識別する。ＩＤＰ１００８は、宛先／受信者ＵＲＬをＳＰ１００２のＡＣＳ−ＵＲＬとして識別するように構成される。このＩＤＰ及びアサーション構成は、アサーション内の宛先／受信者ＵＲＬを、ＳＰのＡＣＳ−ＵＲＬではなく、ＣＡＳＢ ＵＲＬまたはリバース・プロキシＵＲＬに変更または修正する、既存のＣＡＳＢによって実装されるＩＤＰ及びアサーション構成とは異なる。幾つかの実施態様によれば、開示されるテクノロジは、アサーションの宛先／受信者ＵＲＬを変更する等、Ｎ−ＣＡＳＢ１６０及び／またはＮ−ＣＡＳＢのＡＰ１７０が、ＩＤＰ１００８によって生成されるアサーションのコンテンツにアクセスし、それを変更することを防止することによって、これを達成する。

生成されると、ＩＤＰ１００８は、ＩＤＰ秘密鍵を使用してアサーションを証明し、ＳＰ１００８の構成された公開鍵を使用する代わりに、Ｎ−ＣＡＳＢのＡＰ１７０の構成された公開鍵を使用して証明されたアサーションを暗号化する。

交換６において、ＩＤＰ１００８は、暗号化され証明されたアサーションをＮ−ＣＡＳＢのＡＰ１７０に転送する。暗号化され証明されたアサーションのＮ−ＣＡＳＢのＡＰ １７０へのポスティングは、ＩＤＰ１００８によって生成されたアサーションのコンテンツにアクセスまたは変更することなく達成されることに留意されたい。特に、ポスティングは、アサーションの宛先／受信者ＵＲＬを変更または修正することなく行われる。一実施態様では、これは、上述のように、Ｎ−ＣＡＳＢのＡＰ１７０のＵＲＬを有するＩＤＰ１００８のオフラインまたは帯域外構成によって達成される。この構成は、暗号化され証明されたアサーションがＮ−ＣＡＳＢのＡＰ１７０にポストされることを確実にし、よって、アサーション内の宛先／受信者ＵＲＬを変更または修正する必要をなくす。

交換７において、Ｎ−ＣＡＳＢのＡＰ１７０は、Ｎ−ＣＡＳＢのＡＰ１７０の秘密鍵を使用して暗号化されたアサーションを復号化し、ＩＤＰ１００８と共有するＳＰ１００２の同じ公開鍵を使用してアサーションを再暗号化する。これらのステップは、それぞれ、請求項６９に記載のシステムの復号器及び請求項７０に記載のシステムの再暗号器において具現化される。また、交換７において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０は、トラフィックを評価して、トラフィックが管理デバイスからルーティングされているか、または非管理デバイスからルーティングされているかを判定する。トラフィックが管理デバイスからルーティングされる場合、交換８において、Ｎ−ＣＡＳＢのＡＰ１７０は、アサーション内で識別されたＳＰ１００２のＡＣＳ−ＵＲＬに、復号化されたアサーションをポストする。次に、交換１０において、ＳＰ１００２のＡＣＳは、ＩＤＰ公開鍵を使用して、復号化されたアサーションを検証する。これは、フェデレーテッドＳＳＯ認証のため、ＩＤＰ公開鍵に代えてＣＡＳＢ公開鍵を使用し、その結果、ＳＰとＩＤＰとの間の信頼関係を変更する既存のＣＡＳＢとは対照的である。

アサーションがＳＰ１００２によって検証されると、ユーザは交換１０でＳａａＳアプリケーションにログインする。

対照的に、交換７において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０が、トラフィックが非管理デバイスからルーティングされていると判定した場合、交換１０において、Ｎ−ＣＡＳＢ１６０またはＮ−ＣＡＳＢのＡＰ１７０は、復号されたアサーションを、ＳＰ１００２のＡＣＳにポストする代わりに、ブラウザ３３６を介してリバース・プロキシ１８０にポストする。再暗号化されたアサーションのさらなる処理は、図８のそれぞれの交換１１〜２０に直接対応する。
［アサーション・プロキシでのセキュリティ実行］

幾つかの実施態様、１または複数のセキュリティ・ポリシーは、アサーション・プロキシで実行することができる。一例では、アイデンティティ・プロバイダ（ＩＤａａＳ）によって提供されるアサーションに含まれる情報に基づいて、要求されたサービス・プロバイダ（ＳａａＳアプリケーション）へのアクセスを許可または阻止することを含む。実施態様において、アサーション・プロキシは、受信されたアサーションが許可されたアイデンティティ・プロバイダによって発行されたか、または許可されていない、潜在的に悪意のある中間者（ＭＩＴＭ）によって発行されたかを検証するために、アイデンティティ・プロバイダの公開鍵を用いて構成することができる。アイデンティティ・プロバイダの公開鍵に基づいて検証されると、アサーション・プロキシは、検証されたアサーションを使用して、要求されたＳａａＳアプリケーションへのアクセスを許可または阻止することができる。
［処理］

図１１は、フェデレーテッド・シングル・サインオン（ＳＳＯ）認証のための非侵入型セキュリティ実行の代表的な方法を示す。一部の実施態様では、認証はクラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ）である。図１１のフローチャートは、例えば、情報を受信または検索し、情報を処理し、結果を格納し、結果を送信するように構成された１または複数のプロセッサによって、コンピュータまたは他のデータプロセッシングシステムを用いて少なくとも部分的に実施することができる。他の実施態様は、異なる順序で、及び／または図１１に示されたものとは異なる、より少ない、または追加のアクションで、アクションを実行することができる。幾つかの実施態様では、複数のアクションを組み合わせることができる。便宜上、このフローチャートは、方法を実行するシステムを参照して説明される。システムは、必ずしも方法の一部ではない。

図１１は、ユーザがサービス・プロバイダ（ＳＰ）にログインするときに生成されるアサーションを、ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）−ＵＲＬの代わりに転送するために、プロキシ統合リソースロケータ（ＵＲＬ）を使用し、プロキシ公開鍵を使用してアサーションを暗号化するようにアイデンティティ・プロバイダ（ＩＤＰ）を構成することによって、アクション１１１０で始まるプロセスを含む。これらのステップは、請求項６９に記載のシステムのＩＤＰ構成手段において具現化される。

ＳＰとＩＤＰは、ＳＰにおいてＩＤＰのＳＳＯ統合リソースロケータ（ＵＲＬ）及び公開鍵を構成し、ＩＤＰにおいてＳＰのＡＣＳ−ＵＲＬを構成し、ＩＤＰ署名を使用して生成されたアサーションをディジタル的に証明することによって確立された信頼関係にある。ＳＰとＩＤＰとの間の信頼関係は、フェデレーテッドＳＳＯ認証セッションを確立するために、生成されたアサーションのＩＤＰ署名ベースのディジタル証明書を維持し、ＩＤＰの公開鍵を使用して、ＳＰにおいて復号化されたアサーションを検証することにより保持される。

一実施態様では、ＳＰは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）アプリケーションである。別の実施態様では、ＩＤＰは、ＳＰに対するフェデレーテッドＳＳＯ認証のためにエンティティによって使用されるサードパーティのアイデンティティ・アズ・ア・サービス（ＩＤａａＳ）である。

アクション１１２０で、アサーション・プロキシがプロキシＵＲＬで構成される。アサーション・プロキシは、転送のためにＳＰのＡＣＳ−ＵＲＬを使用する。一実施態様では、アサーション・プロキシは、クラウド・アクセス・セキュリティ・ブローカ（ＣＡＳＢ）によってホストされるクラウド・サービスである。別の実施態様では、アサーション・プロキシは、エンティティを前提としてＣＡＳＢによってホストされるローカル・プロキシである。更に別の実施態様では、アサーション・プロキシは、ＩＤＰとは異なり、ＩＤＰをホストするＩＤａａＳとは別のＣＡＳＢによってホストされる。

アクション１１３０で、暗号化されたアサーションがアサーション・プロキシで受信され、補完的プロキシ秘密鍵で復号化される。

アクション１１４０で、アサーション・プロキシは、復号化されたアサーションをＳＰのＡＣＳ−ＵＲＬに転送することによって、ユーザのクライアントとＳＰのＡＣＳとの間に挿入され、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）認証セッションを確立する。幾つかの実施態様では、挿入されたアサーション・プロキシを介して、クラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ）認証セッションが確立される。

開示された技術の本セクション及び他のセクションに記載される方法は、以下の特徴及び／または開示される追加の方法に関連して記載される特徴の内の１つ以上を含み得る。説明の簡潔のために、本出願で開示される特徴の組み合わせは個別に列挙されず、特徴の各基本集合を用いて繰り返されない。読者は、本方法で特定された特徴が、用語、序論、及びシステムの概要等の実施態様として特定された基本特徴のセットとどのように容易に組み合わせることができるかを理解するであろう。

一実施態様では、ユーザのクライアントが非管理デバイスであると判定したことに応じて、ＳＰのＡＣＳ−ＵＲＬは、挿入されたアサーション・プロキシにおいて追加されたリバース・プロキシ・ドメインで符号化され、復号化されたアサーションは、ユーザのクライアントを介してリバース・プロキシに転送される。幾つかの実施態様では、非管理デバイスは、トラフィックがポリシー実行サーバを介してトンネリングされていない個人保有デバイスの持ち込み（ＢＹＯＤ）及び／またはオフ・ネットワーク・デバイスである。更に、リバース・プロキシは、リバース・プロキシ・ドメインを取り除き、復号化されたアサーションをネットワーク・セキュリティ・システムに転送する。ネットワーク・セキュリティ・システムは、１以上のセキュリティ・ポリシーに基づいて復号されたアサーションを評価し、評価されたアサーションをＳＰのＡＣＳに転送する。次に、リバース・プロキシでは、ＳＰによってサービスされるページに含まれるＵＲＬが、リバース・プロキシを介してフェデレーテッドＳＳＯ認証セッション中にユーザのクライアントから後続のトラフィックをリダイレクトする書き換えられたＵＲＬで書き換えられる。

一実施態様では、アサーション・プロキシ及びリバース・プロキシは、単一のプロキシとして組み合わされ、ホストされる。

幾つかの実施態様では、ユーザのクライアントが非管理デバイスであると判定されたことに応じて、ユーザのクライアントのＳＰへのアクセス許可がブロックされる。他の実施態様では、ユーザのクライアントが管理されているという判定に応じて、復号化されたアサーションは、フェデレーテッドＳＳＯ認証セッションを確立するために、ネットワーク・セキュリティ・システムを介して、挿入されたアサーション・プロキシからＳＰのＡＣＳに転送される。更に他の実施態様では、復号化されたアサーションは、１または複数のセキュリティ・ポリシーに基づいてリバース・プロキシで評価され、評価されたアサーションは、ＳＰのＡＣＳに転送される。

ＩＤＰがセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）プロトコルを使用する一実施態様では、暗号化されたアサーションは、ユーザのクライアントを介してアサーション・プロキシで受信される。ＩＤＰがアクティブ認証のためにウェブ・サービス（ＷＳ）−フェデレーション・プロトコルを使用する別の実施態様では、暗号化されたアサーションは、アサーション・プロキシにおいてＩＤＰから受信される。そのような実施態様では、ＩＤＰは、アクティブ・ディレクトリ・フェデレーション・サービス（ＡＤＦＳ）である。

幾つかの実施態様、１または複数のＩＤＰは、複数のＳＰのＡＣＳ−ＵＲＬの代わりにプロキシＵＲＬを使用し、プロキシ公開鍵を使用してアサーションを暗号化するように構成される。

幾つかの実施態様では、ＩＤＰは、ＳＰ公開鍵の代わりに、アサーションを暗号化するためにプロキシ公開鍵を使用するように構成される。また、暗号化されたアサーションは、補完的プロキシ秘密鍵を使用してアサーション・プロキシで復号化され、復号化されたアサーションは、ＳＰ公開鍵を使用してアサーション・プロキシで再暗号化される。次に、再暗号化されたアサーションがＳＰのＡＣＳに転送される。

このセクションで説明される方法の他の実施態様は、上述の方法の何れかを実行するためにプロセッサによって実行可能である、命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。このセクションで説明される方法の更に別の実施態様は、上述の方法の何れかを実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。

図１２は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）との間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）認証中にセキュリティを非侵入的に実行する方法を示すフローチャートである。幾つかの実施態様では、認証はクラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ） である。図１２のフローチャートは、例えば、情報を受信または検索し、情報を処理し、結果を格納し、結果を送信するように構成された１または複数のプロセッサによって、コンピュータまたは他のデータプロセッシングシステムを用いて少なくとも部分的に実施することができる。他の実施態様は、異なる順序で、及び／または図１２に示されるものとは異なる、より少ない、または追加のアクションで、アクションを実行することができる。幾つかの実施態様では、複数のアクションを組み合わせることができる。便宜上、このフローチャートは、方法を実行するシステムを参照して説明される。システムは、必ずしも方法の一部ではない。

図１２は、ＳＰにおいてＩＤＰのＳＳＯ統合リソースロケータ（ＵＲＬ）及び公開鍵を構成し、ＩＤＰにおいてＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）−ＵＲＬを構成することによって、ＳＰとＩＤＰとの間に信頼関係が確立されるアクション１２１０で始まるプロセスを含む。

アクション１２２０において、この方法は、ユーザがＳＰにログインするときにＩＤＰにおいてアサーションを生成することと、生成されたアサーションにおいてＳＰのＡＣＳ−ＵＲＬを識別することと、ＩＤＰ証明書を使用して生成されたアサーションにディジタル署名することとを含む。

アクション１２３０において、この方法は、アサーション・プロキシのプロキシ公開鍵を使用して署名されたアサーションを暗号化し、ＳＰのＡＣＳ−ＵＲＬではなくアサーション・プロキシのプロキシＵＲＬに暗号化されたアサーションを転送するようにＩＤＰを構成することを含む。

アクション１２４０において、この方法は、アサーション・プロキシにおける暗号化されたアサーションを、補完的プロキシ秘密鍵で復号化することと、復号化されたアサーションにおいて識別されたＳＰのＡＣＳ−ＵＲＬを使用して、復号化されたアサーションをＳＰのＡＣＳに転送することとを含む。

アクション１２５０において、この方法は、アサーション・プロキシを介してフェデレーテッドＳＳＯ認証セッションを確立するために、ＩＤＰの公開鍵を使用して、ＳＰにおいて復号化されたアサーションを検証することによって、ＳＰとＩＤＰとの間の信頼関係を保持することを含む。

開示された技術の本セクション及び他のセクションに記載された方法は、１または複数の以下の特徴及び／または開示された追加の方法に関連して記載された特徴を含むことができる。説明の簡潔のために、本出願で開示される特徴の組み合わせは個別に列挙されず、特徴の各基本集合を用いて繰り返されない。読者は、本方法で特定された特徴が、用語、序論、及びシステムの概要等の実施態様として特定された基本特徴のセットとどのように容易に組み合わせることができるかを理解するであろう。

一実施態様では、ユーザのクライアントが非管理デバイスであると判定したことに応じて、ＳＰのＡＣＳ−ＵＲＬは、挿入されたアサーション・プロキシにおいて追加されたリバース・プロキシ・ドメインで符号化され、復号化されたアサーションは、ユーザのクライアントを介してリバース・プロキシに転送される。幾つかの実施態様では、非管理デバイスは、トラフィックがポリシー実行サーバを介してトンネリングされていない個人保有デバイスの持ち込み（ＢＹＯＤ）及び／またはオフ・ネットワーク・デバイスである。更に、リバース・プロキシは、リバース・プロキシ・ドメインを取り除き、復号化されたアサーションをネットワーク・セキュリティ・システムに転送する。ネットワーク・セキュリティ・システムは、１以上のセキュリティ・ポリシーに基づいて復号化されたアサーションを評価し、評価されたアサーションをＳＰのＡＣＳに転送する。次に、リバース・プロキシでは、ＳＰによってサービスされるページに含まれるＵＲＬが、リバース・プロキシを介してフェデレーテッドＳＳＯ認証セッション中にユーザのクライアントから後続のトラフィックをリダイレクトする書き換えられたＵＲＬで書き換えられる。

一実施態様では、アサーション・プロキシ及びリバース・プロキシは、単一のプロキシとして組み合わされ、ホストされる。

幾つかの実施態様では、ユーザのクライアントが非管理デバイスであると判定されたことに応じて、ユーザのクライアントのＳＰへのアクセス許可がブロックされる。他の実施態様では、ユーザのクライアントが管理されるという決定に応じて、復号化されたアサーションは、フェデレーテッドＳＳＯ認証セッションを確立するために、ネットワーク・セキュリティ・システムを介して、挿入されたアサーション・プロキシからＳＰのＡＣＳに転送される。更に他の実施態様では、復号化されたアサーションは、１または複数のセキュリティ・ポリシーに基づいてリバース・プロキシで評価され、評価されたアサーションは、ＳＰのＡＣＳに転送される。

ＩＤＰがセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）プロトコルを使用する一実施態様では、暗号化されたアサーションは、ユーザのクライアントを介してアサーション・プロキシで受信される。ＩＤＰがアクティブ認証のためにウェブ・サービス（ＷＳ）−フェデレーション・プロトコルを使用する別の実施態様では、暗号化されたアサーションは、アサーション・プロキシにおいてＩＤＰから受信される。そのような実施態様では、ＩＤＰは、アクティブディレクトリフェデレーションサービス（ＡＤＦＳ）である。

幾つかの実施態様、１または複数のＩＤＰは、複数のＳＰのＡＣＳ−ＵＲＬの代わりにプロキシＵＲＬを使用し、プロキシ公開鍵を使用してアサーションを暗号化するように構成される。

幾つかの実施態様では、ＩＤＰは、ＳＰ公開鍵の代わりに、アサーションを暗号化するためにプロキシ公開鍵を使用するように構成される。また、暗号化されたアサーションは、補完的プロキシ秘密鍵を使用してアサーション・プロキシで復号化され、復号化されたアサーションは、ＳＰ公開鍵を使用してアサーション・プロキシで再暗号化される。次に、再暗号化されたアサーションがＳＰのＡＣＳに転送される。

このセクションで説明される方法の他の実施態様は、上述の方法の何れかを実行するためにプロセッサによって実行可能である、命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。このセクションで説明される方法の更に別の実施態様は、上述の方法の何れかを実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。

図１３は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更せずにフェデレーテッド・シングル・サインオン（ＳＳＯ）認証中にセキュリティを非侵入的に実行するする方法を示すフローチャートである。一部の実施態様では、認証はクラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ） である。図１３のフローチャートは、少なくとも部分的に、コンピュータ、または、例えば、情報を受信または検索し、情報を処理し、結果を保存し、該結果を送信するように構成された１以上のプロセッサ等による他のデータ処理システムにより実施できる。他の実施態様では、図１３に図示したものと異なる順序で、及び／または、異なるまたは少ないまたは追加の処置とともに、該処置を実施してもよい。幾つかの実施態様では、複数の処置を合体することができる。便宜上、該フローチャートは、方法を実行するシステムを参照して説明される。該システムは、必ずしも、該方法の一部ではない。

図１３は、ＳＰとＩＤＰとの間に信頼関係が確立されるアクション１３１０で始まるプロセスを含む。

アクション１３２０で、ユーザがＳＰにログインする時に生成されたアサーションを、ＳＰのアサーション・コンシューマ・サービスに代えて、アサーション・プロキシに転送するよう、ＩＤＰが構成されている。

アクション１３３０で、アサーション・プロキシを用いて１以上のセキュリティ・ポリシーと対照してアサーションを評価し、評価したアサーションをＳＰに転送する。

アクション１３４０で、アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、ＩＤＰの証明書を用いてＳＰにおいて評価されたアサーションを検証することによりＳＰとＩＤＰ間の信頼関係が保持される。

このセクションで説明される方法の他の実施態様は、上述の方法の何れかを実行するためにプロセッサによって実行可能である、命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。このセクションで説明される方法の更に別の実施態様は、上述の方法の何れかを実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。
［特定の実施態様］

フェデレーテッド・シングル・サインオン（ＳＳＯ）中の非侵入型のセキュリティ実施することによるサービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を維持する様々な実施態様について述べる。幾つかの実施態様では、認証はクラウドベースのフェデレーテッド・シングル・サインオン（ＳＳＯ）である。

開示された技術は、システム、方法、または製品として実施することができる。実施態様の１つ以上の機能を基本実施態様と組み合わせることができる。互いに排他的ではない実施態様は組み合わせ可能であると教示される。実施態様の１つ以上の機能を他の実施態様と組み合わせることができる。この開示は、定期的にこれらのオプションをユーザに想起させる。これらのオプションを繰り返す記述の幾つかの実施態様からの省略は、前節で教示された組み合わせを限定するものとして解釈されるべきではない。これらの記載は、以下の実施態様のそれぞれに参考として援用される。

開示された技術のシステムの実施態様は、メモリと接続した１以上のプロセッサを含む。メモリには、プロセッサ上で実行されると、フェデレーテッド・シングル・サインオン（ＳＳＯ）認証中に非侵入型のセキュリティ実施を引き起こすコンピュータ命令がロードされている。システムはアサーション・プロキシを含む。

ユーザがサービス・プロバイダ（ＳＰ）にログインする時にアサーションが生成される。システムは、アサーションを転送するために、ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬに代えて、プロキシ統合リソース・ロケータ（ＵＲＬ）を用いるよう、アイデンティティ・プロバイダ（ＩＤＰ）を構成する。また、ＩＤＰはプロキシ公開鍵を用いてアサーションを暗号化するよう構成されている。これらのステップは、請求項６９に記載のシステムのＩＤＰ構成手段において具現化される。

プロキシＵＲＬで、システムは、転送のためにＳＰのＡＣＳ−ＵＲＬを使用するようアサーション・プロキシを構成する。アサーション・プロキシは、クラウド・アクセス・セキュリティ・ブローカ（ＣＡＳＢ）によってホストされるクラウド・サービスであり得る。アサーション・プロキシはまた、エンティティを前提としてＣＡＳＢによってホストされるローカル・プロキシであり得る。実施態様では、アサーション・プロキシは、ＩＤＰとは異なり、ＩＤＰをホストするＩＤａａＳとは別のＣＡＳＢによってホストされる。

次に、アサーション・プロキシが、暗号化されたアサーションを受信し、暗号化されたアサーションを補完的プロキシ秘密鍵で復号化する。システムは、アサーション・プロキシを、復号化されたアサーションをＳＰのＡＣＳ−ＵＲＬに転送することによって、ユーザのクライアントとＳＰのＡＣＳとの間に挿入し、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）認証セッションを確立する。

本システムの実施態様と開示された他のシステムは、以下の特徴の内の１つ以上を任意に含み得る。システムはまた、開示された方法に関連する特徴を含み得る。説明の簡潔のために、本出願で開示される特徴の別の組み合わせは個別に列挙されない。システム、方法、そして製品に適用可能な特徴は、基本特徴の各法定クラスセットに対して繰り返されない。読者は、本セクションで特定された特徴が、他の法定クラスにおける基本特徴とどのように容易に組み合わせることができるかを理解するであろう。

ＳＰは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）アプリケーションであり得る。ＳＰの例には、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）、Ｂｏｘ（商標）、Ｄｒｏｐｂｏｘ（商標）、Ｇｏｏｇｌｅ Ａｐｐｓ（商標）、Ａｍａｚｏｎ ＡＷＳ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ ３６５（商標）、Ｗｏｒｋｄａｙ（商標）、Ｏｒａｃｌｅ ｏｎ Ｄｅｍａｎｄ（商標）、Ｔａｌｅｏ（商標）、Ｙａｍｍｅｒ（商標）、Ｃｏｎｃｕｒ（商標）等が含まれる。ＩＤＰは、ＳＰに対するフェデレーテッドＳＳＯ認証のためにエンティティによって使用されるサードパーティのアイデンティティ・アズ・ア・サービス（ＩＤａａＳ）であり得る。ＩＤＰの例には、Ｏｋｔａ（商標）、Ｐｉｎｇ Ｉｄｅｎｔｉｔｙ（商標）、Ｗｉｎｄｏｗｓ Ａｚｕｒｅ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（商標）、ＥｍｐｏｗｅｒＩＤ（商標）、ＯｎｅＬｏｇｉｎ（商標）、Ｂｉｔｉｕｍ（商標）、Ｃｅｎｔｒｉｆｙ（商標）、Ｉｄｅｎｔａｃｏｒ（商標）、ＬａｓｔＰａｓｓ（商標）等が含まれる。

ユーザのクライアントは、トラフィックがポリシー実行サーバを介してトンネリングされていない個人保有デバイスの持ち込み（ＢＹＯＤ）、及び／または、オフ・ネットワーク・デバイスといった非管理デバイスであり得る。ユーザのクライアントが非管理デバイスであるとシステムが判断した際、ＳＰのＡＣＳ−ＵＲＬが、挿入されたアサーション・プロキシにおいて追加されたリバース・プロキシ・ドメインを用いて符号化され、復号化されたアサーションが、検証トークンと共にユーザのクライアントを介してリバース・プロキシに転送され得る。検証トークンが検証された後、リバース・プロキシにおいてリバース・プロキシ・ドメインが取り除かれ、復号化されたアサーションがネットワーク・セキュリティ・システムに転送される得る。

その後、１以上のセキュリティ・ポリシーに基づいたネットワーク・セキュリティ・システムにおいて復号化されたアサーションが評価され、評価されたアサーションがＳＰのＡＣＳに転送され得る。最後に、リバース・プロキシは、リバース・プロキシを介したフェデレーテッドＳＳＯの認証されたセッションの間、ユーザのクライアントから後続のトラフィックをリダイレクトする書き換えられたＵＲＬを用いて、ＳＰにより供給されたページ内に含まれるＵＲＬを書き換えることができる。

更に、ユーザのクライアントが非管理デバイスであると判定されたことに応じて、システムは、ユーザのクライアントのＳＰへのアクセス許可をブロックできる。

ユーザのクライアントが管理されているという判定に応じて、復号化されたアサーションが、フェデレーテッドＳＳＯ認証セッションを確立するために、ネットワーク・セキュリティ・システムを介して、挿入されたアサーション・プロキシからＳＰのＡＣＳに転送され得る。

復号化されたアサーションは、１または複数のセキュリティ・ポリシーに基づいてリバース・プロキシで評価され、ＳＰのＡＣＳに転送され得る。

アサーション・プロキシ及びリバース・プロキシは、幾つかの実施態様によると、単一のプロキシとして組み合わされ、ホストされ得る。

セキュリティ・ポリシーは、リバース・プロキシに加えて、またはリバース・プロキシに代えて、アサーション・プロキシで実行することができる。このような実施態様は、リバース・プロキシの必要性を除去する。セキュリティ実行は、アサーション・プロキシにおいて構成されたＩＤＰの公開鍵に従ったアサーション・プロキシによるＩＤＰのアイデンティティのアサーション及びベリフィケーションにおけるＩＤＰの提供された情報に基づいて、ＳＰへのアクセスを許可または阻止することを含む。

ＩＤＰはセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）プロトコルを使用することができる。このような実施態様では、暗号化されたアサーションは、幾つかの実施態様によると、ユーザのクライアントを介してアサーション・プロキシで受信される。ＩＤＰはまた、アクティブ認証のためにウェブ・サービス（ＷＳ）−フェデレーション・プロトコルを使用することができる。このような実施態様では、暗号化されたアサーションは、ユーザのクライアントを迂回してアサーション・プロキシにおいてＩＤＰから受信され得る。ＩＤＰは、アクティブ・ディレクトリ・フェデレーション・サービス（ＡＤＦＳ）も使用することができる。

ＳＰとＩＤＰとの間の信頼関係は、ＳＰにおいてＩＤＰのＳＳＯ統合リソースロケータ（ＵＲＬ）及び公開鍵を構成し、ＩＤＰにおいてＳＰのＡＣＳ−ＵＲＬを構成し、ＩＤＰ署名を使用して生成されたアサーションをディジタル的に証明することによって確立され得る。ＳＰとＩＤＰとの間の信頼関係は、フェデレーテッドＳＳＯ認証セッションを確立するために、生成されたアサーションのＩＤＰ署名ベースのディジタル証明書を維持し、ＩＤＰの公開鍵を使用して、ＳＰにおいて復号化されたアサーションを検証することにより保持され得る。

このシステムは、１または複数のＩＤＰを、複数のＳＰのＡＣＳ−ＵＲＬの代わりにプロキシＵＲＬを使用し、更に、プロキシ公開鍵を使用してアサーションを暗号化するように構成することができる。

このシステムは、ＳＰの公開鍵を用いてアサーション・プロキシにおいて復号化されたアサーションを再暗号化し、再暗号化されたアサーションをＳＰのＡＣＳに転送することができる。

他の実施態様は、上述のシステムの機能を実行するために、プロセッサによって実行される命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述のシステムの機能を実行する方法を含むことができる。

開示された技術の他のシステムの実施態様は、メモリと接続した１以上のプロセッサを含む。メモリには、プロセッサ上で実行されると、フェデレーテッド・シングル・サインオン（ＳＳＯ）認証中に二重暗号化を引き起こすコンピュータ命令がロードされている。システムはアサーション・プロキシを含む。

このシステムは、サービス・プロバイダ（ＳＰ）の公開鍵に代えて、アサーション・プロキシの公開鍵を用いてアサーションを暗号化するようアサーション・プロキシＩＤＰを構成する。

このシステムは、アサーション・プロキシの補完的プロキシ秘密鍵を用いてアサーション・プロキシにおいて暗号化されたアサーションを復号化する。

このシステムは、アサーション・プロキシにおいてＳＰの公開鍵を用いて復号化されたアサーションを再暗号化し、再暗号化されたアサーションをＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）に転送する。

他の実施態様は、上述のシステムの機能を実行するために、プロセッサによって実行される命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述のシステムの機能を実行する方法を含むことができる。

開示された技術の他のシステムの実施態様は、メモリと接続した１以上のプロセッサを含む。メモリには、プロセッサ上で実行されると、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入型のセキュリティ実施を引き起こすコンピュータ命令がロードされている。システムはアサーション・プロキシを含む。

最初に、ＳＰにおいてＩＤＰのＳＳＯ統合リソースロケータ（ＵＲＬ）及び公開鍵を構成し、ＩＤＰにおいてＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）−ＵＲＬを構成することによって、ＳＰとＩＤＰとの間に信頼関係が確立される。ユーザがＳＰにログインするときに、ＩＤＰにおいてアサーションが生成される。生成されたアサーションにおいてＳＰのＡＣＳ−ＵＲＬが識別される。生成されたアサーションはそして、ＩＤＰ証明書を使用してディジタル署名される。

このシステムはそして、アサーション・プロキシのプロキシ公開鍵を使用して署名されたアサーションを暗号化し、ＳＰのＡＣＳ−ＵＲＬではなくアサーション・プロキシのプロキシＵＲＬに暗号化されたアサーションを転送するようにＩＤＰを構成する。

これに続いて、暗号化されたアサーションはアサーション・プロキシにおいて補完的プロキシ秘密鍵で復号化され、復号化されたアサーションは、復号化されたアサーションにおいて識別されたＳＰのＡＣＳ−ＵＲＬを使用してＳＰのＡＣＳに転送される。

最後に、アサーション・プロキシを介してフェデレーテッドＳＳＯ認証セッションを確立するために、ＩＤＰの公開鍵を使用して、ＳＰにおいて復号化されたアサーションを検証することによって、ＳＰとＩＤＰとの間の信頼関係が保持される。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、この特定の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述のシステムの機能を実行するために、プロセッサによって実行される命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述のシステムの機能を実行する方法を含むことができる。

開示された技術の更に他のシステムの実施態様は、メモリと接続した１以上のプロセッサを含む。メモリには、プロセッサ上で実行されると、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入型のセキュリティ実施を引き起こすコンピュータ命令がロードされている。システムはアサーション・プロキシを含む。

最初に、ＳＰとＩＤＰとの間に信頼関係が確立される。

次に、このシステムは、ユーザがＳＰにログインする時に生成されたアサーションを、ＳＰのアサーション・コンシューマ・サービスに代えて、アサーション・プロキシに転送するよう、ＩＤＰを構成する。

これに続いて、アサーション・プロキシを用いて１以上のセキュリティ・ポリシーと対照してアサーションを評価し、評価したアサーションをＳＰに転送する。

最後に、アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、ＩＤＰの証明書を用いてＳＰにおいて評価されたアサーションを検証することによりＳＰとＩＤＰ間の信頼関係を保持する。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、この特定の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述のシステムの機能を実行するために、プロセッサによって実行される命令を非一時的に格納するコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述のシステムの機能を実行する方法を含むことができる。

開示された技術の方法の実施態様は、フェデレーテッド・シングル・サインオン（ＳＳＯ）認証のための非侵入型セキュリティ実行を含む。この方法は、ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）−ＵＲＬの代わりに、ユーザがサービス・プロバイダ（ＳＰ）にログインするときに生成されるアサーションを転送するために、プロキシ統合リソースロケータ（ＵＲＬ）を使用し、プロキシ公開鍵を使用してアサーションを暗号化するように、アイデンティティ・プロバイダ（ＩＤＰ）を構成することを含む。これらのステップは、請求項６９に記載のシステムのＩＤＰ構成手段において具現化される。

この方法は、引き続き、転送用にＳＰのＡＣＳ−ＵＲＬを用いるために、プロキシＵＲＬにおいてアサーション・プロキシを構成する。これらのステップは、請求項６９に記載のシステムのアサーション・プロキシ構成手段において具現化される。

その後、この方法は、アサーション・プロキシにおいて暗号化されたアサーションを受け取り、補完的プロキシ秘密鍵を用いて暗号化されたアサーションを復号化することを含む。これらのステップは、請求項６９に記載のシステムの受信手段において、また、請求項６９に記載のシステムの復号化手段において、それぞれ具現化される。

最後に、この方法は、ＳＰのＡＣＳ−ＵＲＬへ復号化されたアサーションを転送することにより、ユーザのクライアントとＳＰのＡＣＳの間にアサーション・プロキシを挿入し、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）の認証されたセッションを確立することを含む。これらのステップは、請求項６９に記載のシステムの挿入手段において具現化される。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の方法を実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の方法を実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。

開示された技術の別の方法の実施態様は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入的にセキュリティを実行することを含む。この方法は、ＳＰにおいてＩＤＰのＳＳＯ統合リソース・ロケータ（ＵＲＬ）と公開鍵を構成し、ＩＤＰにおいてＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬを構成することにより、ＳＰとＩＤＰ間の信頼関係を確立することを含む。

この方法は、引き続き、ユーザがＳＰにログインする時にＩＤＰにおいてアサーションを生成し、生成されたアサーション内のＳＰのＡＣＳ−ＵＲＬを識別し、且つ、ＩＤＰ証明書を用いて生成されたアサーションにディジタル署名する。

これに続いて、この方法は、アサーション・プロキシのプロキシ公開鍵を用いて署名されたアサーションを暗号化し、ＳＰのＡＣＳ−ＵＲＬに代えてアサーション・プロキシのプロキシＵＲＬに暗号化されたアサーションを転送するようにＩＤＰを構成することを含む。

次に、この方法は、補完的プロキシ秘密鍵を用いてアサーション・プロキシにおいて暗号化されたアサーションを復号化し、復号化されたアサーション内で識別されたＳＰのＡＣＳ−ＵＲＬを用いてＳＰのＡＣＳに復号化されたアサーションを転送することを含む。

最後に、この方法は、アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、ＩＤＰの公開鍵を用いてＳＰにおいて復号化されたアサーションを検証することによりＳＰとＩＤＰ間の信頼関係を保持することを含む。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の方法を実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の方法を実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。

開示された技術の別の方法の実施態様は、サービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中に非侵入的にセキュリティを実行することを含む。

先ず、この方法は、ＳＰとＩＤＰ間の信頼関係を確立することを含む。

この方法は、引き続き、ユーザがＳＰにログインする時に生成されたアサーションを、ＳＰのアサーション・コンシューマ・サービスに代えて、アサーション・プロキシに転送するよう、ＩＤＰを構成する。

これに続いて、この方法は、アサーション・プロキシを用いて１以上のセキュリティ・ポリシーと対照してアサーションを評価し、評価したアサーションをＳＰに転送することを含む。

最後に、この方法は、アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、ＩＤＰの証明書を用いてＳＰにおいて評価されたアサーションを検証することによりＳＰとＩＤＰ間の信頼関係を保持することを含む。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の方法を実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の方法を実行するために、メモリ及びメモリ内に格納された命令を実行するように動作可能な１または複数のプロセッサを含むシステムを含むことができる。

本技術が開示したコンピュータ可読媒体（ＣＲＭ）の実施態様は、プロセッサ上で実行されることで上述した方法を実施するコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体を含む。

第１のシステム実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、このＣＲＭの実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

一実施態様では、開示された技術は、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証のため非侵入的にセキュリティを実行するシステムを備える。

このシステムは、ユーザがサービス・プロバイダ（ＳＰ）にログインする時に生成されたアサーションを転送するために、ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬに代えて、プロキシ統合リソース・ロケータ（ＵＲＬ）を用い、且つ、プロキシ公開鍵を用いてアサーションを暗号化するように、アイデンティティ・プロバイダ（ＩＤＰ）を構成するＩＤＰ構成手段を備える。

このシステムは、転送用にＳＰのＡＣＳ−ＵＲＬを用いるために、プロキシＵＲＬにおいてアサーション・プロキシを構成するアサーション・プロキシ構成手段を備える。

このシステムは、アサーション・プロキシにおいて暗号化されたアサーションを受け取る受信手段を備える。

このシステムは、補完的プロキシ秘密鍵を用いて暗号化されたアサーションを復号化する復号化手段を備える。

このシステムは、ＳＰのＡＣＳ−ＵＲＬへ復号化されたアサーションを転送することにより、ユーザのクライアントとＳＰのＡＣＳの間にアサーション・プロキシを挿入する挿入手段を備え、挿入されたアサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）の認証されたセッションを確立する。

前の方法及びシステムの実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、このシステムの実施態様に対して等しく適用される。上述したように、全ての方法及びシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述のシステムのアクションを実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。

別の一実施態様では、開示された技術は、フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中にサービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく非侵入的にセキュリティを実行するシステムを備える。

このシステムは、ＳＰのＳＰ公開鍵に代えて、アサーションを暗号化するために、アサーション・プロキシのプロキシ公開鍵を用いるようにＩＤＰを構成する構成手段を備える。

このシステムは、アサーション・プロキシの補完的プロキシ秘密鍵を用いてアサーション・プロキシにおいて暗号化されたアサーションを復号化する復号化手段を備える。

このシステムは、ＳＰ公開鍵を用いてアサーション・プロキシにおいて復号化されたアサーションを再暗号化し、再暗号化されたアサーションをＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）に転送する再暗号化手段を備える。

前の方法及びシステムの実施態様のためにこの特定の実施態様セクションで議論した特徴のそれぞれは、このシステムの実施態様に対して等しく適用される。上述したように、全ての方法及びシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述のシステムのアクションを実行するために、プロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。
［コンピュータ・システム］

図１４は、開示された技術を実施するために使用できるコンピュータ・システムの簡略ブロック図である。コンピュータ・システム１４１０は、典型的には、バス・サブシステム１４１２を介して幾つかの周辺装置と通信する少なくとも１つのプロセッサ１４１４を含む。これらの周辺装置は、例えば、メモリ装置及びファイル・ストレージ・サブシステムを含むストレージ・サブシステム１４２４、ユーザ・インターフェイス入力装置１４２２、ユーザ・インターフェイス出力装置１４１８、及びネットワーク・インターフェイス・サブシステム１４１６を含むことができる。入力及び出力装置は、コンピュータ・システム１４１０とのユーザ対話を可能にする。ネットワーク・インターフェイス・サブシステム１４１６は、他のコンピュータ・システム内の対応するインターフェイス装置へのインターフェイスを含む、外部ネットワークへのインターフェイスを提供する。

一実施態様では、Ｎ−ＣＡＳＢ１６０は、記憶サブシステム１４２４及びユーザ・インターフェイス入力装置１４２２に通信可能にリンクされる。

ユーザ・インターフェイス入力装置１４２２は、キーボード、マウス、トラックボール、タッチパッド、またはグラフィックス・タブレット等のポインティングデバイス、スキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム及びマイクロフォン等のオーディオ入力装置、並びに他のタイプの入力装置を含むことができる。一般に、「入力装置」という用語の使用は、コンピュータ・システム１４１０に情報を入力するためのすべての可能なタイプの装置及び方法を含むことが意図される。

ユーザ・インターフェイス出力装置１４１８は、ディスプレイ・サブシステム、プリンタ、ファックスマシン、またはオーディオ出力装置等の非視覚ディスプレイを含むことができる。ディスプレイ・サブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）等のフラットパネル装置、投影装置、または可視画像を生成するための他の何らかのメカニズムを含むことができる。ディスプレイ・サブシステムはまた、オーディオ出力装置等の非視覚ディスプレイを提供することができる。一般に、「出力装置」という用語の使用は、コンピュータ・システム１４１０からユーザに、または別の機械もしくはコンピュータ・システムに情報を出力するためのすべての可能なタイプの装置及び方法を含むことが意図される。

ストレージ・サブシステム１４２４は、本明細書で説明するモジュール及び方法の一部または全部の機能を提供するプログラミング及びデータ構造を記憶する。これらのソフトウェア・モジュールは、一般に、プロセッサ１４１４によって単独で、または他のプロセッサと組み合わせて実行される。

ストレージ・サブシステムで使用されるメモリ１４２６は、プログラム実行中に命令及びデータを格納するためのメインランダムアクセスメモリ（ＲＡＭ）１４３４と、固定命令が格納される読み取り専用メモリ（ＲＯＭ）１４３２とを含む、幾つかのメモリを含むことができる。ファイル・ストレージ・サブシステム１４２８は、プログラム及びデータファイルのための永続的ストレージを提供することができ、ハードディスク・ドライブ、関連するリムーバブル・メディアと共にフロッピー（商標）ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、光ドライブ、またはリムーバブル・メディア・カートリッジを含むことができる。特定の実施態様の機能を実施するモジュールは、ストレージ・サブシステム１４２４内のファイル・ストレージ・サブシステム１４２８によって、またはプロセッサによってアクセス可能な他のマシン内に格納することができる。

バス・サブシステム１４１２は、コンピュータ・システム１４１０の様々なコンポーネント及びサブシステムに、意図されたように互いに通信させるためのメカニズムを提供する。バス・サブシステム１４１２は、単一のバスとして概略的に示されているが、バス・サブシステムの他に採り得る実施態様は、多数のバスを使用することができる。アプリケーション・サーバ１４２０は、ハードウェア及び／またはソフトウェア、例えば、オペレーティング・システム等、コンピュータ・システム１４１０のアプリケーションを実行することを可能にするフレームワークとすることができる。

コンピュータ・システム１４１０は、ワークステーション、サーバ、コンピューティング・クラスタ、ブレード・サーバ、サーバ・ファーム、または任意の他のデータ処理システムもしくはコンピューティング・デバイスを含む様々なタイプのものとすることができる。コンピュータ及びネットワークの絶えず変化する性質のために、図１４に示されるコンピュータ・システム１４１０の説明は、一例としてのみ意図される。コンピュータ・システム１４１０の多くの他の構成は、図１４に示されたコンピュータ・システムよりも多いまたは少ないコンポーネントを有することが可能である。

開示される技術は、データベースシステム、マルチテナント環境、または、Ｏｒａｃｌｅ（商標）と互換性のあるデータベース実施態様、ＩＢＭ ＤＢ２ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒ（商標）と互換性のあるリレーショナル・データベース実施態様、ＭｙＳＱＬ（商標）またはＰｏｓｔｇｒｅＳＱＬ（商標）と互換性のあるリレーショナル・データベース実施態様またはＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ（商標）と互換性のあるリレーショナル・データベース実施態様等のリレーショナル・データベース実施態様、または、Ｖａｍｐｉｒｅ（商標）と互換性のある非リレーショナル・データベース実施態様、Ａｐａｃｈｅ Ｃａｓｓａｎｄｒａ（商標）と互換性のある非リレーショナル・データベース実施態様、 ＢｉｇＴａｂｌｅ（商標）と互換性のある非リレーショナル・データベース実施態様、またはＨＢａｓｅ（商標）またはＤｙｎａｍｏＤＢ（商標）と互換性のある非リレーショナル・データベース実施態様、等のＮｏＳＱＬ（商標）の非リレーショナル・データベース実施態様を含む何かのコンピュータ実装システムという状況下で実施され得る。更に、開示された技術は、ＭａｐＲｅｄｕｃｅ（商標）、バルク同期プログラミング、ＭＰＩプリミティブ等の様々なプログラミングモデル、または、Ａｐａｃｈｅ Ｓｔｏｒｍ（商標）、Ａｐａｃｈｅ Ｓｐａｒｋ（商標）、Ａｐａｃｈｅ Ｋａｆｋａ（商標）、Ａｐａｃｈｅ Ｆｌｉｎｋ（商標）、Ｔｒｕｖｉｓｏ（商標）、Ａｍａｚｏｎ Ｅｌａｓｔｉｃｓｅａｒｃｈ Ｓｅｒｖｉｃｅ（商標）、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）（商標）、ＩＢＭ Ｉｎｆｏ‐Ｓｐｈｅｒｅ（商標）、Ｂｏｒｅａｌｉｓ（商標）、及びＹａｈｏｏ！ Ｓ４（商標）等の様々なスケーラブルなバッチ及びストリーム管理システムを使用して実施され得る。

上記で説明または参照された如何なるデータ構造及びコードも、多くの実施態様に基づいて、コンピュータ・システムによる使用のためにコード及び／またはデータを保存できる任意のデバイスまたは媒体であり得るコンピュータ可読記憶媒体上に保存される。コンピュータ可読記憶媒体は、揮発性メモリ、不揮発性メモリ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、ディスク・ドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（ディジタル・ヴァーサタイル・ディスクまたはディジタル・ビデオ・ディスク）等の磁気及び光学記憶装置、または、既知または今後開発されるコンピュータ可読媒体を保存可能な他の媒体、但し、これらに制限されないものを含む。

以上の説明は、開示された技術の作成及び使用を可能にすべく提示された。説明した実施態様に対する種々の変形は明白であり、ここに規定された一般的原理は、開示された技術の精神と範囲から逸脱することなく、他の実施態様及びアプリケーションに適用し得る。従って、開示された技術は、示された実施態様に限定されることを意図されておらず、ここに開示された原理及び特徴に合致する最大範囲が与えられる。開示された技術の範囲は、添付の請求項により規定される。

Claims (15)

1. フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中にサービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく非侵入的にセキュリティを実行するコンピュータによって実行される方法であって、
   前記ＳＰにおいて前記ＩＤＰのＳＳＯ統合リソース・ロケータ（ＵＲＬ）と公開鍵を構成し、前記ＩＤＰにおいて前記ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬを構成することにより、前記ＳＰと前記ＩＤＰ間の前記信頼関係を確立すること、
   ユーザが前記ＳＰにログインする時に前記ＩＤＰにおいてアサーションを生成し、前記生成されたアサーション内の前記ＳＰのＡＣＳ−ＵＲＬを識別し、且つ、ＩＤＰ証明書を用いて前記生成されたアサーションにディジタル署名すること、
   アサーション・プロキシのプロキシ公開鍵を用いて前記署名されたアサーションを暗号化し、前記ＳＰのＡＣＳ−ＵＲＬに代えて前記アサーション・プロキシのプロキシＵＲＬに前記暗号化されたアサーションを転送するように前記ＩＤＰを構成すること、
   補完的プロキシ秘密鍵を用いて前記アサーション・プロキシにおいて前記暗号化されたアサーションを復号化し、前記復号化されたアサーション内で識別された前記ＳＰのＡＣＳ−ＵＲＬを用いて前記ＳＰのＡＣＳに前記復号化されたアサーションを転送すること、及び、
   前記アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、前記ＩＤＰの公開鍵を用いて前記ＳＰにおいて前記復号化されたアサーションを検証することにより前記ＳＰと前記ＩＤＰ間の前記信頼関係を保持すること、
   を含む方法。
2. 前記ユーザのクライアントが非管理デバイスであると判断したことに応答して、
   前記アサーション・プロキシにおいて追加されたリバース・プロキシ・ドメインを用いて前記ＳＰのＡＣＳ−ＵＲＬを符号化し、検証トークンと共に前記ユーザのクライアントを介してリバース・プロキシに前記復号化されたアサーションを転送すること、
   前記検証トークンを検証した後、前記リバース・プロキシにおいて前記リバース・プロキシ・ドメインを取り除き、前記復号化されたアサーションをネットワーク・セキュリティ・システムに転送すること、
   １以上のセキュリティ・ポリシーに基づいて前記ネットワーク・セキュリティ・システムにおいて前記復号化されたアサーションを評価し、前記評価したアサーションを前記ＳＰのＡＣＳに転送すること、及び、
   前記リバース・プロキシを介した前記フェデレーテッドＳＳＯの認証されたセッションの間、前記ユーザのクライアントから後続のトラフィックをリダイレクトする書き換えられたＵＲＬを用いて、前記リバース・プロキシにおいて、前記ＳＰにより供給されたページ内に含まれるＵＲＬを書き換えること、
   を更に含む請求項１に記載のコンピュータによって実行される方法。
3. 前記アサーション・プロキシにおいて構成された前記ＩＤＰの公開鍵に従った前記アサーション・プロキシによるＩＤＰのアイデンティティの前記アサーション及びベリフィケーションにおけるＩＤＰの提供された情報に基づいて、前記ＳＰへのアクセスを許可または阻止することを含んで、前記アサーション・プロキシにおいて前記セキュリティ・ポリシーが実行される請求項２に記載のコンピュータによって実行される方法。
4. 前記アサーション・プロキシと前記リバース・プロキシが結合され、単一のプロキシとしてホストされる請求項２または３に記載のコンピュータによって実行される方法。
5. １以上のセキュリティ・ポリシーに基づいて前記リバース・プロキシにおいて前記復号化されたアサーションを評価し、前記評価したアサーションを前記ＳＰのＡＣＳに転送することを更に含む請求項２〜４の何れか１項に記載のコンピュータによって実行される方法。
6. 前記ユーザのクライアントが非管理デバイスであると判断したことに応答して、
   前記ＳＰへの前記ユーザのクライアントのアクセス許可を阻止することを更に含む請求項１〜５の何れか１項に記載のコンピュータによって実行される方法。
7. 前記非管理デバイスが、トラフィックがポリシー実行サーバを介してトンネリングされていない個人保有デバイスの持ち込み（ＢＹＯＤ）、及び／または、オフ・ネットワーク・デバイスである請求項２〜６の何れか１項に記載のコンピュータによって実行される方法。
8. 前記ユーザのクライアントが管理されていると判断したことに応答して、
   前記フェデレーテッドＳＳＯの認証されたセッションを確立するためにフォワード・プロキシを介して、前記アサーション・プロキシから前記ＳＰのＡＣＳへ前記復号化されたアサーションを転送することを更に含む請求項１〜７の何れか１項に記載のコンピュータによって実行される方法。
9. 前記ＩＤＰが、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）プロトコルを使用する請求項１〜８の何れか１項に記載のコンピュータによって実行される方法。
10. 前記ユーザのクライアントを介して前記アサーション・プロキシにおいて前記暗号化されたアサーションを受け取ることを更に含む請求項１〜９の何れか１項に記載のコンピュータによって実行される方法。
11. 前記ＩＤＰが、アクティブ認証のためにウェブ・サービス（ＷＳ）・フェデレーション・プロトコルを使用する請求項１〜１０の何れか１項に記載のコンピュータによって実行される方法。
12. 前記アサーション・プロキシにおいて前記ＩＤＰから前記暗号化されたアサーションを受け取ることを更に含む請求項１〜１１の何れか１項に記載のコンピュータによって実行される方法。
13. 前記アサーション・プロキシが、クラウド・アクセス・セキュリティ・ブローカ（ＣＡＳＢ）によりホストされるクラウド・サービスである請求項１〜１２の何れか１項に記載のコンピュータによって実行される方法。
14. フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証中にサービス・プロバイダ（ＳＰ）とアイデンティティ・プロバイダ（ＩＤＰ）間の信頼関係を変更することなく非侵入的にセキュリティを実行するためのコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体であって、
    前記命令がプロセッサ上で実行されることにより、
    前記ＳＰにおいて前記ＩＤＰのＳＳＯ統合リソース・ロケータ（ＵＲＬ）と公開鍵を構成し、前記ＩＤＰにおいて前記ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬを構成することにより、前記ＳＰと前記ＩＤＰ間の前記信頼関係を確立すること、
    ユーザが前記ＳＰにログインする時に前記ＩＤＰにおいてアサーションを生成し、前記生成されたアサーション内の前記ＳＰのＡＣＳ−ＵＲＬを識別し、且つ、ＩＤＰ証明書を用いて前記生成されたアサーションにディジタル署名すること、
    アサーション・プロキシのプロキシ公開鍵を用いて前記署名されたアサーションを暗号化し、前記ＳＰのＡＣＳ−ＵＲＬに代えて前記アサーション・プロキシのプロキシＵＲＬに前記暗号化されたアサーションを転送するように前記ＩＤＰを構成すること、
    補完的プロキシ秘密鍵を用いて前記アサーション・プロキシにおいて前記暗号化されたアサーションを復号化し、前記復号化されたアサーション内で識別された前記ＳＰのＡＣＳ−ＵＲＬを用いて前記ＳＰのＡＣＳに前記復号化されたアサーションを転送すること、及び、
    前記アサーション・プロキシを介してフェデレーテッドＳＳＯの認証されたセッションを確立するために、前記ＩＤＰの公開鍵を用いて前記ＳＰにおいて前記復号化されたアサーションを検証することにより前記ＳＰと前記ＩＤＰ間の前記信頼関係を保持すること、
    を含む方法が、前記命令により実行される非一時的なコンピュータ可読記憶媒体。
15. フェデレーテッド・シングル・サインオン（ＳＳＯ）の認証に対し非侵入的にセキュリティを実行するシステムであって、
    ユーザがサービス・プロバイダ（ＳＰ）にログインする時に生成されたアサーションを転送するために、前記ＳＰのアサーション・コンシューマ・サービス（ＡＣＳ）ＵＲＬに代えて、プロキシ統合リソース・ロケータ（ＵＲＬ）を用い、且つ、プロキシ公開鍵を用いて前記アサーションを暗号化するように、アイデンティティ・プロバイダ（ＩＤＰ）を構成するＩＤＰ構成手段、
    転送用に前記ＳＰのＡＣＳ−ＵＲＬを用いるために、前記プロキシＵＲＬにおいてアサーション・プロキシを構成するアサーション・プロキシ構成手段、
    前記アサーション・プロキシにおいて前記暗号化されたアサーションを受け取る受信手段、
    補完的プロキシ秘密鍵を用いて前記暗号化されたアサーションを復号化する復号化手段、及び、
    前記アサーション・プロキシを介してフェデレーテッド・シングル・サインオン（ＳＳＯ）の認証されたセッションを確立するために、前記ＳＰのＡＣＳ−ＵＲＬへ前記復号化されたアサーションを転送することにより、前記ユーザのクライアントと前記ＳＰのＡＣＳの間に前記アサーション・プロキシを挿入する挿入手段、
    を備えるシステム。

Images