| Oracleセキュリティ開発ツール・リファレンス 10gリリース3（10.1.3） B28615-01 |
|
 戻る |
 次へ |
セキュリティ・ツールは、現在のアプリケーション開発プロジェクトにとって重要な構成要素です。市場のニーズや政府の規制により、重要なデータを機密保護し、改ざんや変更を防ぐことが求められます。
Oracleセキュリティ開発ツールによって、安全なメッセージングなどの基本タスクから、サービス指向アーキテクチャの安全な実装といった複雑なプロジェクトに及ぶ、堅牢なセキュリティ・アプリケーションの開発に必要な暗号ビルディング・ブロックが提供されます。これらのツールは、暗号化、公開鍵インフラストラクチャ、Webサービス・セキュリティおよびフェデレーテッドID管理を基盤として構築されています。
この章では、このような基礎を形成するセキュリティ・テクノロジについて詳しく説明し、Oracleセキュリティ開発ツールのコンポーネントを紹介します。この項に含まれる内容は次のとおりです。
データは信頼できない通信チャネルを経由するため、暗号化により、侵入者による傍受（受動的攻撃）または変更（能動的攻撃）から送信されるメッセージを守ります。メッセージを保護するには、発信者が暗号化ツールを使用して、読取り可能なプレーン・メッセージ、すなわち平文を暗号化された暗号文に変換します。元のテキストは存在しますが、傍受されたとしても解読できない形式に変更されています。メッセージの受信者も暗号化ツールを使用し、暗号文を元の読取り可能な形式に復号化します。
暗号化では、次の機能が提供され、インターネットなどネットワークを介した通信が保護されます。
認証: 情報の発信元が信頼できることを受信者に保証します。通常、認証は、メッセージ認証コード（MAC）、デジタル署名およびデジタル証明書を使用して達成されます。
機密保護: 意図した受信者のみがメッセージを読み取ることを保証します。通常、機密保護は暗号化によって実現されます。
整合性: 受信したメッセージが元のメッセージから変更されていないことを保証します。通常、整合性は暗号化ハッシュ関数を使用して保証されます。
否認防止: 所定の送信者が特定のメッセージを実際に送信したことを証明する方法です。通常、否認防止はデジタル署名を使用して達成されます。
平文と暗号文をマップするために使用される数学的な演算は、暗号化アルゴリズム（または暗号）と呼ばれます。暗号化アルゴリズムでは、マップ対象のテキストの他に、少なくともマッピング・プロセスを制御する値が必要です。この値は、鍵と呼ばれます。
基本的には3つのタイプの暗号化アルゴリズムがあり、暗号化と復号化に使用される鍵の数と、適用方法や使用方法によって分類されます。基本タイプの暗号化アルゴリズムを次に示します。
各タイプは特定の用途に最適化されています。ハッシュ関数はデータの整合性の保証に適しています。対称暗号化はメッセージの暗号化に最適です。非対称暗号化は、鍵の安全な交換、認証および否認防止に使用されます。また、非対称暗号化はメッセージの暗号化にも使用できますが、頻繁ではありません。対称暗号化は非対称暗号化の約1000倍の速度で処理されるため、非対称暗号化よりも暗号化に適しています。
対称暗号化アルゴリズム（または秘密鍵暗号化）は、暗号化と復号化の両方で1つの鍵を使用します。送信者が鍵を使用して平文を暗号化し、暗号文を受信者に送信します。受信者は同じ鍵を使用してメッセージを復号化し、平文に戻します。送信者と受信者の両方が鍵を知っている必要があります。対称暗号化の最大の問題は、鍵を安全に配布することです。
一般的に、対称暗号化スキームはブロック暗号とストリーム暗号に分類されます。ブロック暗号では、固定サイズのデータ・ブロック（通常は64ビット）が一度に1つずつ暗号化され、各ブロックには同じ鍵が使用されます。現在使用されている一般的なブロック暗号には、Blowfish、AES、DESおよび3DESがあります。
ストリーム暗号では、一度に1ビットが処理され、絶え間なく鍵が変化するためのフィードバック・メカニズムが実装されます。RC4はストリーム暗号の一例です。これは、SSLプロトコルを使用した安全な通信のために使用されます。
非対称暗号化アルゴリズム（または公開鍵暗号化）では、平文の暗号化と暗号文の復号化にそれぞれ別の鍵が使用されます。どちらの鍵を先に適用してもかまいませんが、暗号が機能するためには両方の鍵が必要です。
非対称暗号化では、1つの鍵が公開鍵として指定され、広く使用されます。もう1つの鍵は秘密鍵に指定され、第三者には公開しません。このスキームでメッセージを送信する場合、送信者は受信者の公開鍵を使用して情報を暗号化します。受信者は自らの秘密鍵を使用して暗号文を復号化します。この方法は、メッセージの送信者を証明する場合にも使用できます（否認防止）。送信者は自らの秘密鍵を使用して平文を暗号化できます。受信者は、送信者の公開鍵を使用してメッセージを復号化するため、メッセージがその送信者から実際に送信されたことがわかります。
現在使用されている一般的な非対称アルゴリズムには、RSA、DSA、Diffie-Hellmanおよび楕円曲線暗号（ECC）があります。
ハッシュ関数（またはメッセージ・ダイジェスト）は、本質的に鍵を使用しない一方向暗号化アルゴリズムです。かわりに、平文に基づいて固定長のハッシュ値を計算します。この値から、平文の内容または長さを復元することはできません。通常、ハッシュ・アルゴリズムは、ファイルの内容のデジタル・フィンガープリントを提供するために使用されます。ファイルが侵入者やウイルスによって変更されていないことを確認するためによく使用されます。また、ハッシュ関数は、一般に多くのオペレーティング・システムでパスワードの暗号化に利用されています。ハッシュ関数は、ファイルの整合性の保持にも有用です。一般的なハッシュ関数としては、MD2、MD4、MD5およびSHAがあります。
公開鍵インフラストラクチャ（PKI）は、パブリック・ネットワークおよびプライベート・ネットワークでの安全な通信を実現するために設計されています。データの安全な送信と格納のみでなく、PKIによって、電子メールの安全性、デジタル署名およびデータの整合性が実現されます。
このような機能は公開鍵暗号化を介して提供されます。これは、関連する1組の暗号鍵を使用して、送信者のID確認（デジタル署名）や、メッセージのプライバシ確保（暗号化）を行う数学的な技術です。PKIの機能によって、インターネットなど安全性の低いネットワークでの安全な情報交換がサポートされます。
PKIの目的を達成するためには、次の要素が必要です。
通信を保護する暗号化アルゴリズムと鍵
公開鍵を所有者のIDに関連付けるデジタル証明書
暗号化を広く安全に使用できるようにする鍵の配布方法
鍵とその正当な所有者の関係を保証する、認証局（CA）と呼ばれる信頼できるエンティティ
CAに対する証明書リクエストの情報を確認する登録局（RA）
利用者は、CAが発行した証明書とそれに含まれる公開鍵を使用して、デジタル証明書を確認し、データを暗号化します。
暗号化技術では、送信者と受信者のみが知っている鍵と呼ばれるテキストまたは数値がよく使用されます。
両者が同じ鍵を使用する暗号化スキームは対称と呼ばれます。対称システムを利用する際の難点として、鍵を傍受されずに両者に渡すことや、1組の受信者と送信者ごとに個別の鍵が必要になるため、各ユーザーが多数の鍵（受信者ごとに1つずつ）を管理する必要があることがあげられます。
公開鍵暗号化では、数学的に関連する暗号鍵（公開鍵と秘密鍵）の鍵ペアが使用されます。鍵ペアの使用方法は、「非対称暗号化アルゴリズム」を参照してください。
表1-1に、公開鍵と秘密鍵の利用者と目的をまとめています。
認証局（CA）は、公開鍵の所有者のIDを保証する、信頼できるサード・パーティです。Oracle認証局もそのようなエンティティの1つです。他にはVerisign社やThawte社があります。
認証局は、デジタル証明書を作成して、公開鍵と特定のエンティティとの関係を検証します。このデジタル証明書には、公開鍵、鍵所有者および署名する認証局の情報が含まれます。エンティティのIDを証明するためにPKI証明書を使用することは、運転免許証やパスポートで身分を証明することと似ています。
多数の規格やプロトコルで、PKI証明書の実装がサポートされています。
暗号メッセージ構文
暗号メッセージ構文（CMS）は、Internet Engineering Task Force（IETF）によって開発されたデータ保護の一般的な構文です。署名付きデータ、エンベロープ・データ、ダイジェスト、暗号化データなど、様々なコンテンツ・タイプがサポートされます。CMSでは複数のカプセル化が可能になるため、たとえば、事前に署名されているデータを、受け取った相手がエンベロープに入れることができます。
CMSで生成される値は、X.509基本エンコーディング規則（BER）を使用してエンコードされます。つまり、値は8ビット文字列として表されます。
Secure/Multipurpose Internet Mail Extension
Secure/Multipurpose Internet Mail Extension（S/MIME）は、デジタル署名と暗号化を使用することでMIMEデータを保護するInternet Engineering Task Force（IETF）の規格です。
S/MIMEでは、電子メッセージ・アプリケーションのために次の暗号化セキュリティ・サービスが提供されます。
認証
メッセージ整合性と発信元の否認防止（デジタル署名の使用）
プライバシとデータ・セキュリティ（暗号化の使用）
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol（LDAP）は、一般的に使用されているディレクトリ・サーバーとの間で情報の取得とポストを行うためのオープン規格です。公開鍵インフラストラクチャ（PKI）システムでは、多くの場合、ユーザーのデジタル証明書はLDAPディレクトリに格納されます。必要な場合には、リクエスト・アプリケーションやリクエスト・サービスによってアクセスされます。
タイムスタンプ・プロトコル
タイムスタンプ・プロトコル（TSP）システムでは、信頼できるサード・パーティのタイムスタンプ局（TSA）がデジタル・メッセージのタイムスタンプを発行します。タイムスタンプによって、メッセージが特定のエンティティから特定の時刻に送信されたことが証明され、オンライン・トランザクションに否認防止機能が提供されます。
タイムスタンプ・プロトコルでは、RFC 3161に指定されているように、デジタル・メッセージのタイムスタンプに関連するエンティティ、メッセージ書式および転送プロトコルが定義されます。
タイムスタンプ・システムが機能する方法を確認するために、Sallyが文書に署名し、タイムスタンプを必要とする場合について説明します。Sallyが安全なハッシュ関数を使用して文書のメッセージ・ダイジェストを計算し、メッセージ・ダイジェスト（文書そのものではなく）をTSAに送信すると、TSAからデジタル・タイムスタンプが返されます。これは、メッセージ・ダイジェスト、メッセージ・ダイジェストがTSAサーバーで受信された日時、およびTSAの署名で構成されます。メッセージ・ダイジェストからは文書の内容に関する情報はわからないため、TSAがタイムスタンプの際に文書を傍受することはありません。その後、Sallyは文書とタイムスタンプを一緒に示して、文書の作成時刻を証明することができます。ベリファイアは、文書のメッセージ・ダイジェストを計算し、タイムスタンプのダイジェストと一致することを確認して、タイムスタンプのTSAの署名を検証します。
Online Certificate Status Protocol
デジタル証明書の有効性をチェックする一般的な方法は2つあります。Online Certificate Status Protocol（OCSP）が、その1つです。もう1つの方法は、以前からある証明書失効リスト（CRL）です。状況によってはOCSPの方が優れています。
OCSPでは、クライアント側でリストを最新に保つために、更新分を頻繁にダウンロードする必要があるというCRLの大きな制限が解消されています。ユーザーがサーバーにアクセスしようとすると、OCSPによって証明書ステータス情報に対するリクエストが送信されます。サーバーは、レスポンス（有効、失効または不明）を返信します。このプロトコルによって、サーバー（証明書ステータスを格納する）とクライアント・アプリケーション（ステータスが通知される）の間の通信の構文が指定されます。
Certificate Management Protocol
Certificate Management Protocol（CMP）を使用すると、証明書の作成および管理に関連する処理のすべてを実行できます。CMPでは、公開鍵インフラストラクチャ（PKI）の構成要素（認証局（CA）、登録局（RA）、証明書発行先のエンド・エンティティなど）間の相互作用がサポートされます。
安全で信頼できるユーザーの認証
信頼できる認証は次の2つの要因に基づきます。1つは、公開鍵と秘密鍵のペアの秘密鍵部分の所有を証明することです。これは、公開鍵を使用する自動手順で確認されます。もう1つは、特定のIDへの公開鍵の所属が認証局によって検証されることです。PKIに基づくデジタル証明書では、鍵ペアに基づいてこのIDの接続が検証されます。
データ整合性
公開鍵と秘密鍵のペアの秘密鍵を使用してデジタル・トランザクションに署名すると、送信中にデータを変更することが困難になります。このようなデジタル署名は、送信者の秘密鍵で暗号化された元のメッセージのダイジェストがコード化されたものです。受信者は、送信者の対応する公開鍵を使用して、メッセージの送信者、およびメッセージが変更されていないことを確認できます。メッセージまたはダイジェストの変更があると、公開鍵を使用した検証が失敗するため、メッセージを信頼できないことが受信者に伝わります。
否認防止
PKIは、メッセージの送信者を証明する場合にも使用できます。送信者が自らの秘密鍵を使用して平文を暗号化し、デジタル署名を作成します。受信者が送信者の公開鍵を使用してメッセージを復号化する際、受信者には、メッセージがその送信者によって実際に送信されたことがわかります。このため、メッセージの発信者がメッセージを否認することは困難です。この機能は否認防止と呼ばれます。
送信または格納されている情報への未許可アクセスの防止
公開鍵から秘密鍵を導出するためにはかなりの時間と労力が必要になるため、鍵ペアの所有者以外がメッセージを復号化することは考えられません。
Webサービスによって、会社などの組織はWebベース・アプリケーションを統合する標準的な方法を得ます。これには、XML、SOAPおよびWSDLといったオープンな標準テクノロジが使用されます。
SOAPは、サービス指向環境で情報を交換するための軽量プロトコルです。このような環境では、アプリケーションは、他のアプリケーションで使用するように選択した機能（ビジネス・ロジックなど）を公開できます。SOAPは、アプリケーションがこれらのサービスを提供および消費するための手段を提供します。これは分散非集中管理Webサービス・アプリケーション環境でのメッセージ転送のためのXMLベースのプロトコルです。
コア仕様のSOAPによってXMLやWebサービスに関連する多くの問題が解決されますが、機密保護、整合性、メッセージ認証、否認防止など、メッセージ・セキュリティ要件に対処する手段は提供されません。SOAPを保護するニーズが高まったため、OASISは次のようなWebサービス・セキュリティの規格を提唱しています。
SOAPメッセージの署名と暗号化を可能にする拡張機能の指定
セキュリティ・トークンとメッセージを関連付ける汎用メソッドの指定
メッセージに組み込まれるトークンの特徴を指定するための、その他の手段の提供
Security Assertions Markup Language（SAML）は、インターネット上でセキュリティ情報を交換するためのXMLベースのフレームワークです。SAMLを使用すると、通常は相互運用できない様々なセキュリティ・サービス・システム間で、認証や認可の情報を交換できます。
SAML 1.0仕様は、2002年にOrganization for the Advancement of Structured Information Standards（OASIS）に採用されました。OASISは、E-Business規格の開発、統合および採用を促進する国際的な非営利団体です。
SAMLは、ID（電子メール・アドレスまたはディレクトリのリスト）をサブジェクト（ユーザーまたはシステム）に関連付けて、特定のドメインでのアクセス権を定義します。すべてのSAML文書にはアサーション要素が含まれます。SAMLでは、4種類のアサーションが定義され、それぞれはサブジェクトの1つ以上の事実の宣言です。
サブジェクトのアサーション。特定のユーザーまたはシステムを識別するために使用されます。
認証のアサーション。特定の方法で特定の日時にユーザーがIDを証明したことを示します。
属性のアサーション。ユーザーの特定の詳細情報（従業員番号や口座番号など）を含みます。
認可のアサーション。ユーザーがアクセスできるリソースとその条件を指定します。
アサーションは、すでに発生したイベントに関して生成される、コード化された文です。SAMLによって資格証明に関するアサーションが作成されますが、実際にユーザーの認証や許可が行われるわけではありません。例1-1に、SAMLPレスポンス・メッセージにラップされた典型的なSAMLの認証アサーションを示します。
例1-1 SAML認証アサーションを含むサンプルSAMLPレスポンス
<samlp:Response MajorVersion="1" MinorVersion="0" RequestID="128.14.234.20.90123456" InResponseTo="123.45.678.90.12345678" StatusCode="/features/2004/05/Success"> <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="123.45.678.90.12345678" Issuer="IssuingAuthority.com" IssueInstant="2004-01-14T10:00:23Z" > <saml:Conditions NotBefore="2004-01-14T10:00:30Z" NotAfter="2004-01-14T10:15:00Z" /> <saml:AuthenticationStatement AuthenticationMethod="Password" AuthenticationInstant="2004-01-14T10:00: 20Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="RelyingParty.com" Name="john.smith" /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response>
アサーションを発行する機関は、発行局と呼ばれます。発行局は、サード・パーティのサービス・プロバイダまたは、民間の企業連合内で発行局の役割を果す企業です。発行局を信頼してサービスを利用するSAML準拠のアプリケーションおよびサービスは、利用者と呼ばれます。
典型的なSAMLサイクルでは、特定のクライアント・リクエストの認証を必要とする利用者が、SAMLリクエストを発行局に送信します。発行局は、リクエストされたセキュリティ情報を利用者に提供する、SAMLアサーションで応答します。このサイクルを図1-1に示します。
たとえば、あるユーザーが利用者のSAML準拠サービスにサインオンすると、そのサービスによって認証アサーションのリクエストが発行局に送信されます。発行局は、ユーザーが特定の方法で特定の日時に認証されたことを示す認証アサーションの参照先を返します。次に、サービスは、ユーザーの資格証明の検証用に、このアサーションの参照先を他の利用者のサイトに渡すことができます。認証を必要とする別のSAML準拠サイトにユーザーがアクセスすると、そのサイトは参照先の情報を使用して発行局に認証アサーションをリクエストします。認証アサーションにより、ユーザーがすでに認証されていることが通知されます。
発行局では、アサーション・レイヤーが、SAMLプロトコルを使用してリクエストおよびレスポンス・メッセージを処理します。このプロトコルは、通信や転送の様々なプロトコル（HTTP、SOAPなど）にバインドできます。クライアントは常にアサーションを消費しますが、発行局はアサーションの作成と検証の両方を行うためプロデューサおよびコンシューマとして機能できることに注意してください。
SAMLでは、アサーションのリクエストおよび取得のためのプロトコル（SAMLP）が定義されます。バインディングにより、SAMLメッセージと標準通信プロトコルのマッピングが提供され、SAMLのリクエスト・メッセージとレスポンス・メッセージが発行局と利用者の間で転送される標準的な方法が定義されます。たとえば、SAMLのリクエストおよびレスポンスのために定義された転送メカニズムとしては、HTTP上のSimple Object Access Protocol（SOAP）があります。これにより、複数のWebサービス間で標準的な方法でSAML情報を交換できるようになります。
プロファイルでは、標準のフレームワークおよびプロトコルでのSAMLアサーションの埋込みと抽出の方法が指定されます。プロファイル定義の例としては、シングル・サインオンのためのWebブラウザのプロファイルや、SOAPペイロードを保護するSOAPプロファイルがあります。
国際的な企業は、供給業者や顧客にいっそう緊密な関係を求めるようになり、これまで以上に密接でしかも安全性の高い取引関係を形成するという課題に直面しています。
商取引を行う関係者は、取引先の個人または代理店のIDを確認する必要があります。また、取引をする企業のために行動する権限をその個人または代理店が持っていることも確認する必要があります。
従来、企業が提携して業務を行う場合は、提携企業のために行動するすべてのエンティティの名前、職責、その他の関連情報を収集していました。特に大企業においては役割や職責は変化するため、データの維持や管理のコストが急速にきわめて高くなり、ロジスティック上の問題を引き起こすことがあります。
複雑性の解消のみでなく、コストの管理、従業員と顧客のためにリソースへの安全なアクセスを実現すること、法規制の順守なども課題です。
このような要件が、フェデレーテッドID管理への動きを促進しています。フェデレーテッドID管理では、関係者の間にフェデレーテッド関係が確立されている場合、一方が他方にアサーションというプロセスを使用して資格証明を示します。受取り側は、信頼できる取引相手から合意した形式で発行された資格証明を認識します。
フェデレーションの重要な用語は次のとおりです。
サービス・プロバイダ - プリンシパルまたはその他のエンティティにサービスを提供するエンティティ。たとえば、旅行代理店は、パートナの従業員（プリンシパル）に対してはサービス・プロバイダとして機能できます。
シングル・サインオン - あるシステム・エンティティ（IDプロバイダ）で認証し、他のエンティティ（サービス・プロバイダ）がその認証を認めるようにする、プリンシパルの機能。
Liberty Allianceは、フェデレーテッドID管理のテクノロジとビジネスの規格を確立して、相互運用可能なIDサービスを促進するためのオープンな組織です。
詳細は、ホワイト・ペーパー『Federated Identity Management』を参照してください。Oracle Secure Federation Serviceのページ（http://www.oracle.com/technology/products/id_mgmt/osfs/index.html）で入手できます。
この項では、Oracleセキュリティ開発ツールを紹介します。これは、様々なセキュリティ・プロジェクトやタスクを作成または実行するためのPure Javaツールです。
図1-2は、Oracleセキュリティ開発ツールのコンポーネントの階層です。一番下には基本ビルディング・ブロックがあり、各レイヤーは前のレイヤーを利用してその上に構築されています。それぞれが、特定のセキュリティ・アプリケーションのためのツールを提供しています。
Oracle CryptoおよびOracle Security Engineが、このセットの基本的な暗号化ツールです。次のレイヤーには、Oracle CMS（メッセージ構文）、Oracle XML Security（署名の暗号化）、Oracle PKI SDK（Oracle PKI SDK LDAP、Oracle PKI SDK TSP、Oracle PKI SDK OCSPおよびOracle PKI SDK CMPで構成されるPKIツール・スイート）があります。Oracle S/MIMEは、Oracle CMSを利用して安全な電子メールのためのツールセットを提供します。次のレイヤーには、Oracle SAMLとOracle Liberty SDKがあります。構造化アサーション・マークアップとフェデレーテッドID管理の機能が提供されます。最後に、Oracle Web Services Securityがあり、Webサービス・セキュリティが提供されます。
各ツールの説明を次に示します。
Oracle CMSでは、CMSオブジェクトの読取りと書込みのツールや、安全なメッセージ・エンベロープを開発するためのサポート・ツールなど、豊富なツールが提供されます。
Oracle CMSでは、RFC 2630に規定されているIETF暗号メッセージ構文が実装されます。Oracle CMSでは、RFC 2630のコンテンツ・タイプがすべて実装されます。
Oracle S/MIMEでは、次のSecure/Multipurpose Internet Mail Extension（S/MIME）の機能が提供されます。
Oracle PKI SDKには、LDAPディレクトリへのアクセス、デジタル・メッセージの日付スタンプ、証明書の検証および証明書の管理など、デジタル証明書を扱うための一連のツールが含まれます。次のツールキットがあります。
Oracle PKI SDK LDAPでは、LDAPディレクトリ内のデジタル証明書にアクセスする機能が提供されます。Oracle PKI SDK LDAPを使用して実行できるタスクの一部を次に示します。
LDAPディレクトリにあるユーザーの証明書の検証
LDAPディレクトリへの証明書の追加
LDAPディレクトリからの証明書の取出し
LDAPディレクトリからの証明書の削除
Oracle PKI SDK TSPの特徴と機能は次のとおりです。
Oracle PKI SDK TSPはRFC 3161に準拠し、このタイムスタンプ・プロトコル（TSP）仕様に準拠する他の製品と互換性があります。
Oracle PKI SDK TSPでは、TSAサーバーのサンプル実装が提供されます。これは、TSPリクエスト・メッセージをテストするため、または独自のタイムスタンプ・サービスを開発する基礎として使用できます。
Oracle PKI SDK OCSPの特徴と機能は次のとおりです。
Oracle PKI SDK OCSPは、RFC 2560に準拠し、この仕様に準拠する他の製品（Valicert社のValidation Authorityなど）と互換性があります。
Oracle PKI SDK OCSPのAPIでは、OCSPリクエスト・メッセージを構成するためのクラスとメソッドが提供されます。このメッセージは、HTTPを介してRFC 2560に準拠する任意の検証局に送信できます。
Oracle PKI SDK OCSPのAPIでは、OCSPリクエスト・メッセージのレスポンスを構成するためのクラスとメソッドが提供されます。また、発行した証明書の有効性をチェックするための独自のOCSPサーバーを開発する基礎として使用可能なOCSPサーバー実装が提供されます。
Certificate Management Protocol（CMP）メッセージでサポートされる一連の機能を次に示します。
エンティティの登録（証明書の発行よりも先に行われる）
初期化（鍵ペアの生成など）
認証（証明書の発行）
鍵ペアのリカバリ（なくした鍵の再発行）
鍵ペアの更新（証明書が失効し、新しい鍵ペアと証明書を発行する必要が生じた場合）
CAへの失効リクエスト（CRLへの証明書の組込み）
2つのCAでのクロス認証
Oracle PKI SDK CMPはRFC 2510に準拠し、Certificate Management Protocol（CMP）仕様に準拠する他の製品と互換性があります。また、RFC 2511にも準拠し、この証明書要求メッセージ・フォーマット（CRMF）仕様に準拠する他の製品と互換性があります。
Sun社のJava暗号化拡張機能（JCE）は、暗号化、鍵生成と鍵合意の実装、およびメッセージ認証コード（MAC）アルゴリズムのためのフレームワークです。
Oracle JCE Providerパッケージでは、JCEで定義された暗号化サービスのサブセットの具体実装が提供されます。
XMLセキュリティとは、XML文書の共通データ・セキュリティ要件（機密保持、整合性、メッセージの認証、否認防止など）を意味します。
Oracle XML Securityは、次の機能を提供してこれらのニーズを満たします。
W3C XML署名規格のサポート
XML暗号化規格案のサポート
復号化変換規格案のサポート
XML正規化規格のサポート
排他的XML正規化規格のサポート
JAXP 1.1準拠の様々なXMLパーサーおよびXSLTエンジンとの互換性
Oracle SAMLのAPIでは、SAML準拠のJavaセキュリティ・サービスの開発を支援するツールやドキュメントが提供されます。Oracle SAMLを、アプレット、アプリケーション、EJB、サーブレット、JSPなどの既存のJavaソリューションに統合することができます。
Oracle SAMLでは次の機能が提供されます。
SAML 1.0/1.1仕様のサポート
Liberty Allianceプロジェクトで指定したようなSAMLベースのシングル・サインオン（SSO）およびフェデレーテッドIDプロファイルのサポート
Oracle Web Services Securityでは、OASIS仕様に基づく認証と認可のフレームワークが提供されます。Oracle Web Services Securityでは次の機能が提供されます。
SOAPメッセージ・セキュリティ規格のサポート
ユーザー名トークン・プロファイル規格のサポート
X.509証明書トークン・プロファイル規格のサポート
SAMLアサーション・トークン規格案（ドラフト15）のサポート
Java開発者は、Oracle Liberty SDKを使用することで、Liberty Alliance仕様に基づくシングル・サインオン（SSO）およびフェデレーテッドIDソリューションを設計および開発することができます。Oracle Liberty SDKリリース1.1および1.2は、Liberty Alliance 1.1および1.2の仕様に準拠するシステムの開発と統合のあらゆる面の統一、単純化および拡張を目的としています。
Oracle Liberty SDKでは次の機能が提供されます。
Liberty Allianceプロジェクト・バージョン1.1および1.2仕様のサポート
Libertyベースのシングル・サインオンとフェデレーテッドIDのサポート
