41.3 セキュリティ・トークン・サービスの主な用語と概念について

セキュリティ・トークンには、信頼をアサートするために使用される要求と文が含まれます。Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。こうした資格証明は、信頼しているセキュリティ・トークン・サービスから取得できます。

ノート:

相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSecurity Token Serviceを信頼している必要があります。

今日のIT環境には、WebアプリケーションのSSOおよびセッション管理を容易にするための数多くのタイプのセキュリティ・トークン(ほとんどがブラウザCookieに基づいています)があります。その他のトークン・タイプには、Kerberos (主にWindowsネイティブ認証用)、Security Assertion Markup Language (SAML)アサーションに加えてデジタル証明書もあります。

表41-2は、セキュリティ・トークン・サービスの一般的な用語について説明しています。

表41-2 セキュリティ・トークン・サービスの用語

用語	説明
セキュリティ・トークン	メッセージの完全性と機密性を保護するために、信頼するセキュア・トークン・サービスにより発行されたトークンを使用してメッセージを保護するセキュリティ・メカニズム。発行されたトークンに含まれるキーは、サーバー用に暗号化され、署名用および暗号化用の新しいキーを導出するために使用されます。 サービス・プロバイダとコンシューマが潜在的に異なる管理対象環境にいる場合は、単一のセキュリティ・トークン・サービスを使用して信頼のチェーンを確立できます。サービスはクライアントを直接信頼するのではなく、指定されたセキュリティ・トークン・サービスにより発行されたトークンを信頼します。セキュリティ・トークン・サービスは第2のサービスの役割を担い、このサービスによりクライアントが安全に認証されることになります。
セキュリティ・トークン・サービス	サーバーとの明示的な信頼関係(およびクライアントとの信頼関係)がある、信頼されたサード・パーティ。Security Token Serviceはその一例です。
Secure Token Service	様々なアイデンティティ・ドメインとインフラストラクチャ層との間における信頼の仲介に関して標準ベースの統合されたメカニズムを提供する共有Webサービス。 このサービスは、それ自体が信頼する証拠に基づいてアサーションを作成することにより、そのサービスを信頼する他者(または特定の受信者)に対して、WS-Trust仕様で定義されたプロトコルを実装します。このプロトコルは、セキュリティ・トークンの発行、更新、取消および検証のために、メッセージ書式およびメッセージ交換パターンを定義します。 信頼を伝達するために、サービスは、セキュリティ・トークンまたはセキュリティ・トークンのセットに関する知識を証明するものを必要とします。たとえば、XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは送信者の秘密キーを使用して署名され、その署名は送信者の公開キーを使用して検証されます。
リクエスト・セキュリティ・トークン(RST)	セキュリティ・トークンのリクエスト。
リクエスト・セキュリティ・トークン・レスポンス(RSTR)	セキュリティ・トークンのリクエストへのレスポンスとして、リクエストしたユーザーの要求を使用して、Security Token Serviceにより生成されたレスポンス。
代理(OBO)	OBOリクエスト・セキュリティ・トークン(RST)は、本来のクライアントのアイデンティティのみが重要な場合に使用されます。OBO RSTは、リクエスタが必要としているトークンに、次の1つのエンティティのみに関する要求が含まれているをことを示します。 トークンのOnBehalfOf要素で表された外部エンティティ。
ActAs	ActAs RSTは、複合的な委任を必要とします。発行されたトークンの最終受信者が、(クライアントのみでなく)委任チェーン全体を検査できます。ActAs RSTは、リクエスタが必要としているトークンに、次の異なるエンティティに関する要求が含まれているをことを示します。 リクエスタ トークンのActAs要素で表された外部エンティティ。
トークン交換	あるセキュリティ・トークンと別のセキュリティ・トークンの交換。リクエスタは、(Webサービスを開始するために)特定のトークンを必要とします。リクエスタは、Security Token Serviceを使用して着信トークンとサービスが必要とするトークンを交換します。
WS-Security	Web Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。 WS-Securityで使用される最も一般的なセキュリティ・トークンは、Username、X.509証明書、SAMLアサーション、およびKerberosチケットです(すべてがOracle Web Service Managerによりサポートされています)。 WS-Securityには、タイプの異なるバイナリとXMLのセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。 WS-*仕様は、多くの場合、互いに依存しています。たとえば、WS-Policyは、WS-Securityとともに使用されます。WS-*仕様は、非WS-*仕様も利用します。たとえば、WS-Securityは、XML暗号化およびXML署名を使用します。 WS-Securityでは、SAMLアサーションのみ使用されます。プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。 ノート: WS-Security、WS-Trust、WS-Policyは、Organization for the Advancement of Structured Information Standards (OASIS)またはWorld Wide Web Consortium (W3C)などの標準化団体に移管されています。
WS-Trust	Web Services Trust Language (WS-Trust)は、WS-Securityの安全なメッセージング・メカニズムを使用して信頼関係を円滑化する仕様です。 WS-Trustは、アプリケーションが信頼されたSOAPメッセージの交換を構成できるようにするリクエスト・プロトコルおよびレスポンス・プロトコルを定義します。信頼は、セキュリティ・トークンの交換および仲介によって示されます。 WS-Securityのみを使用したメッセージ交換では、交換に関与する両当事者がセキュリティ情報の共有のために使用する必要があるセキュリティ・トークンのタイプについて事前に合意していることを前提としています。両当事者間にそうした合意がない場合でも、結果的に、メッセージを交換する前に信頼を確立する必要があります。SOAP/WS-Securityベースのメッセージを交換する両当事者間の信頼は、WS-Trust仕様を実装することにより確立されます。
WS-Policy	Web Services Policy (WS-Policy)。WS-Securityとともに、WS-Policyは、Oracle Fusion Middlewareセキュリティのもう1つの主要な業界標準です。 WS-Policyは、WS-Securityとともに使用されます。Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義できます。WS-Policyフレームワークを使用すると、Oracle Web Services ManagerなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。 ポリシーは、Webサービスの機能または要件を表す1つ以上のポリシー・アサーションとして表されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストを暗号化することを規定できます。同様に、ポリシー・アサーションでは、Webサービスで許容できる最大メッセージ・サイズを定義できます。
証明書	Security Token Serviceによって使用される証明書は自己署名済です。サブジェクトと発行者のフィールドは同一です。追加設定なしで、Security Token ServiceをホストするOAMサーバーは一意に識別されます。
キーストア	Security Token Serviceのキーストアに含まれるものを次に示します。 システム・キーストア 信頼キーストア パートナ・キーストア 関連項目: セキュリティ・トークン・サービスの証明書とキーの管理
ユーザー名トークン(UNT)	リクエスタをそのユーザー名で識別し、オプションでパスワード(または共有シークレットあるいはパスワードに相当するもの)を使用してそのアイデンティティを認証します。ユーザー名トークンを使用する場合は、そのユーザーをデフォルトのユーザー・アイデンティティ・ストアで構成する必要があります。
X.509証明書	受信当事者に公開キーを送信するために設計された署名付きデータ構造。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開キーなどの標準フィールドが含まれています。 証明書は、Verisignなどの認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密キーで署名します。CAは、公開キーが含まれる独自の証明書を発行します。 各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。
SAML (Security Assertion Markup Language) SAMLアサーション	XMLドキュメントを使用してインターネット上でセキュリティ情報を共有するオープン・フレームワーク。SAMLにより提供されるものを次に示します。 認証および認可の情報を定義するアサーション。 必要なアサーションの要求(SAMLリクエスト)および取得(SAMLレスポンス)を行うプロトコル。 SAMLプロトコルを業界標準のトランスポート(HTTPなど)およびメッセージング・フレームワーク(SOAPなど)に組み込む方法を定義するバインディング。 特定のユースケースをサポートするために、SAMLプロトコルおよびバインディングを組み合せる方法を定義するプロファイル。 WS-Securityでは、SAMLアサーションのみ使用されます。ただし、プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。 SAMLアサーションには、次の3つのタイプの文が含まれます。 認証文: サブジェクトの認証の成功時、認証局により発行されます。サブジェクトSが手段Mによって時間Tに認証されたことをアサートします。 属性文: ポリシーに基づいて属性認証局により発行されます。サブジェクトSが、値a、bなどを持つ属性A、Bなどに関連付けられていることをアサートします。 認可決定文(SAML 2.0では非推奨で、現在はXACMLでサポートされています): サブジェクトSによる(ファイル、アプリケーション、Webサービスなどの)リソースRに対する(読取り、書込みなどの)アクションAのための証拠Eに基づくリクエストを許可するかどうかを決定する認証局によって発行されます。
Kerberos	クロス・プラットフォーム認証のシングル・サインオン・システム。Kerberosプロトコルを使用すると、共有の秘密キー(対称キー)に依存する2つのエンティティ間で相互認証を実行できます。Kerberos認証では、クライアント、サーバーの他、それらを仲介するための、キー配布センター(KDC)と呼ばれる信頼された当事者が必要になります。その他必要なものを次に示します。 プリンシパル: ユーザーのアイデンティティ(ユーザーにプリンシパルが割り当てられます)、またはKerberosサービスを提供するアプリケーションのアイデンティティ。 レルムとはKerberosサーバー環境のことで、EXAMPLE.COM(表記規則により大文字で表現)などのドメイン名とすることも可能です。各Kerberosレルムには、少なくとも1つのWebサービス・セキュリティKDCがあります。 WS-SecurityのKerberos Token Profileを使用すると、ビジネス・パートナがサービス指向アーキテクチャ(SOA)でKerberosトークンを使用できるようになります。