1 Introduction to Oracle Security Developer Tools
This chapter introduces the tools that comprise the Oracle Security Developer Tools.
Security tools are a critical component for application development projects. Commercial requirements and government regulations dictate that sensitive data be kept confidential and protected from tampering or alteration.
Oracle Security Developer Tools provide you with the cryptographic building blocks necessary for developing robust security applications, ranging from basic tasks such as digital signatures and secure messaging to more complex projects such as securely implementing a service-oriented architecture. The tools build upon the core foundations of cryptography, public key infrastructure, web services security, and federated identity management.
A wide range of Oracle products utilize the Oracle Security Developer Tools, including:
-
the Oracle JDeveloper integrated service environment
-
Oracle Platform Security Services, which include SSL configuration features for system components, and Oracle Wallet, which is utilized in multiple components including Oracle Database
-
system components like Oracle Web Services Manager (OWSM); Business Integration (B2B); and Oracle Identity Federation
This chapter takes a closer look at the underlying security technologies and introduces the components of the Oracle Security Developer Tools. It covers these topics:
1.1 About Cryptography
As data travels across untrusted communication channels, cryptography protects the transmitted messages from being intercepted (a passive attack) or modified (an active attack) by an intruder. To protect the message, an originator uses a cryptographic tool to convert plain, readable messages or plaintext into encrypted ciphertext. While the original text is present, its appearance changes into a form that is unintelligible if intercepted. The message recipient likewise uses a cryptographic tool to decrypt the ciphertext into its original readable format.
Cryptography secures communications over a network such as the internet by providing:
-
Authentication, which assures the receiver that the information is coming from a trusted source. Authentication is commonly achieved through the use of a Message Authentication Code (MAC), digital signature, and digital certificate.
-
Confidentiality, which ensures that only the intended receiver can read a message. Confidentiality is commonly attained through encryption.
-
Integrity, which ensures that the received message has not been altered from the original. Integrity is commonly ensured by using a cryptographic hash function.
-
Non-repudiation, which is a way to prove that a given sender actually sent a particular message. Non-repudiation is typically achieved through the use of digital signatures.
1.1.1 Types of Cryptographic Algorithms
The mathematical operations used to map between plaintext and ciphertext are identified by a cryptographic algorithm (also known as a cipher). Cryptographic algorithms require the text to be mapped, and, at a minimum, require some value which controls the mapping process. This value is called a key.
Essentially, there are three types of cryptographic algorithms categorized by the number of keys used for encryption and decryption, and by their application and usage. The basic types of cryptographic algorithms are:
Each type is optimized for certain applications. Hash functions are suited for ensuring data integrity. Symmetric cryptography is ideally suited for encrypting messages. Asymmetric cryptography is used for the secure exchange of keys, authentication, and non-repudiation. Asymmetric cryptography could also be used to encrypt messages, although this is rarely done. Symmetric cryptography operates about 1000 times faster, and is better suited for encryption than asymmetric cryptography.
1.1.1.1 About Symmetric Cryptographic Algorithms
A symmetric cryptography algorithm (also known as secret key cryptography) uses a single key for both encryption and decryption. The sender uses the key to encrypt the plaintext and sends the ciphertext to the receiver. The receiver applies the same key to decrypt the message and recover the plaintext. The key must be known to both the sender and receiver. The biggest problem with symmetric cryptography is the secure distribution of the key.
Symmetric cryptography schemes are generally categorized as being either a block cipher or stream cipher. A block cipher encrypts one fixed-size block of data (usually 64 bits) at a time using the same key on each block. Some common block ciphers used today include Blowfish, AES, DES, and 3DES.
Stream ciphers operate on a single bit at a time and implement some form of feedback mechanism so that the key is constantly changing. RC4 is an example of a stream cipher that is used for secure communications using the SSL protocol.
1.1.1.2 About Asymmetric Cryptographic Algorithms
An asymmetric cryptography algorithm (also known as public key cryptography) uses one key to encrypt the plaintext and another key to decrypt the ciphertext. It does not matter which key is applied first, but both keys are required for the process to work.
In asymmetric cryptography, one of the keys is designated the public key and is made widely available. The other key is designated the private key and is never revealed to another party. To send messages under this scheme, the sender encrypts some information using the receiver's public key. The receiver then decrypts the ciphertext using her private key. This method can also be used to prove who sent a message (non-repudiation). The sender can encrypt some plaintext with her private key, and when the receiver decrypts the message with the sender's public key, the receiver knows that the message indeed came from that sender.
Some of the common asymmetric algorithms in use today are RSA, DSA, and Diffie-Hellman.
1.1.1.3 Understanding Hash Functions
A hash function (also known as a message digest) is a one-way encryption algorithm that essentially uses no key. Instead, a fixed-length hash value is computed based upon the plaintext that makes it impossible for either the contents or length of the plaintext to be recovered. Hash algorithms are typically used to provide a digital fingerprint of a file's contents, often used to ensure that the file has not been altered by an intruder or virus. Hash functions are also commonly employed by many operating systems to encrypt passwords. Hash functions help preserve the integrity of a file. Some common hash functions include MD2, MD4, MD5 and SHA.
1.1.2 Additional Cryptography Resources
For more information, refer to the cryptography resources listed in Appendix A.
1.2 About Public Key Infrastructure (PKI)
A public key infrastructure (PKI) is designed to enable secure communications over public and private networks. Besides secure transmission and storage of data, PKI enables secure e-mail, digital signatures, and data integrity.
These facilities are delivered using public key cryptography, a mathematical technique that uses a pair of related cryptographic keys to verify the identity of the sender (digital signature), or to ensure the privacy of a message (encryption). PKI facilities support secure information exchange over insecure networks, such as the Internet.
Critical elements for achieving the goals of PKI include:
-
Encryption algorithms and keys to secure communications
-
Digital certificates that associate a public key with the identity of its owner
-
Key distribution methods to permit widespread, secure use of encryption
-
A trusted entity, known as a Certificate Authority (CA), to vouch for the relationship between a key and its legitimate owner
-
A Registration Authority (RA) that is responsible for verifying the information supplied in requests for certificates made to the CA
Relying third parties use the certificates issued by the CA and the public keys contained in them to verify digital certificates and encrypt data.
1.2.1 Understanding Key Pairs
Encryption techniques often use a text or number called a key, known only to the sender and recipient.
When both use the same key, the encryption scheme is called symmetric. Difficulties with relying on a symmetric system include getting that key to both parties without allowing an eavesdropper to get it, too; and the fact that a separate key is needed for every two people, so that each individual must maintain many keys, one for each recipient.
Public key cryptography uses a key pair of mathematically related cryptographic keys - the public key and the private key. For an explanation of the use of key pairs, see "About Asymmetric Cryptographic Algorithms".
Table 1-1 summarizes who uses public and private keys and when:
1.2.2 About the Certificate Authority
A Certificate Authority (CA) is a trusted third party that vouches for the public key owner's identity. Examples of certificate authorities include Verisign and Thawte.
1.2.3 What are Digital Certificates?
The certification authority validates the public key's link to a particular entity by creating a digital certificate. This digital certificate contains the public key and information about the key holder and the signing certification authority. Using a PKI certificate to authenticate one's identity is analogous to identifying oneself with a driver's license or passport.
1.2.4 Related PKI Standards
A number of standards and protocols support PKI certificate implementation.
Cryptographic Message Syntax (CMS) is a general syntax for data protection developed by the Internet Engineering Task Force (IETF). It supports a wide variety of content types including signed data, enveloped data, digests, and encrypted data, among others. CMS allows multiple encapsulation so that, for example, previously signed data can be enveloped by a second party.
Values produced by CMS are encoded using X.509 Basic Encoding Rules (BER), meaning that the values are represented as octet strings.
Secure/Multipurpose Internet Mail Extension
Secure/Multipurpose Internet Mail Extension (S/MIME) is an Internet Engineering Task Force (IETF) standard for securing MIME data through the use of digital signatures and encryption.
S/MIME provides the following cryptographic security services for electronic messaging applications:
-
Authentication
-
Message integrity and non-repudiation of origin (using digital signatures)
-
Privacy and data security (using encryption)
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP) is the open standard for obtaining and posting information to commonly used directory servers. In a public key infrastructure (PKI) system, a user's digital certificate is often stored in an LDAP directory and accessed as needed by requesting applications and services.
In a Time Stamp Protocol (TSP) system, a trusted third-party Time Stamp Authority (TSA) issues time stamps for digital messages. Time stamping proves that a message was sent by a particular entity at a particular time, providing non-repudiation for online transactions.
The Time Stamp Protocol, as specified in RFC 3161, defines the participating entities, the message formats, and the transport protocol involved in time stamping a digital message.
To see how a time-stamping system can work, suppose Sally signs a document and wants it time stamped. She computes a message digest of the document using a secure hash function and then sends the message digest (but not the document itself) to the TSA, which sends her in return a digital time stamp consisting of the message digest, the date and time it was received at the TSA server, and the signature of the TSA. Since the message digest does not reveal any information about the content of the document, the TSA cannot eavesdrop on the documents it time stamps. Later, Sally can present the document and time stamp together to prove when the document was written. A verifier computes the message digest of the document, makes sure it matches the digest in the time stamp, and then verifies the signature of the TSA on the time stamp.
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP) is one of two common schemes for checking the validity of digital certificates. The other, older method, which OCSP has superseded in some scenarios, is known as the certificate revocation list (CRL).
OCSP overcomes the chief limitation of CRL: the fact that updates must be frequently down-loaded to keep the list current at the client end. When a user attempts to access a server, OCSP sends a request for certificate status information. The server sends back a response of good, revoked, or unknown. The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status).
Certificate Management Protocol
The certificate management protocol (CMP) handles all relevant aspects of certificate creation and management. CMP supports interactions between public key infrastructure (PKI) components, such as Certificate Authorities (CAs), Registration Authorities (RAs), and end entities that are issued certificates.
1.2.5 Benefits of PKI
PKI provides users with the following benefits:
-
Secure and reliable authentication of users
Reliable authentication relies on two factors. The first is proof of possession of the private key part of the public/private pair, which is verified by an automatic procedure that uses the public key. The second factor is validation by a certification authority that a public key belongs to a specific identity. A PKI-based digital certificate validates this identity connection based on the key pair.
-
Data integrity
Using the private key of a public/private key pair to sign digital transactions makes it difficult to alter the data in transit. This "digital signature" is a coded digest of the original message encrypted by the sender's private key. Recipients can readily use the sender's corresponding public key to verify who sent the message and the fact that it has not been altered. Any change to the message or the digest would have caused the attempted verification using the public key to fail, telling the recipient not to trust it.
-
Non-repudiation
PKI can also be used to prove who sent a message. The sender encrypts some plaintext with her private key to create a digital signature, and when the receiver decrypts the message with the sender's public key, the receiver knows that the message indeed came from that sender, making it difficult for the message originator to disown the message; this capability is known as non-repudiation.
-
Prevention of unauthorized access to transmitted or stored information
The time and effort required to derive the private key from the public key makes it unlikely that the message would be decrypted by anyone other than the key pair owner.
1.3 About Web Services Security
Web services provide a standard way for organizations to integrate Web-based applications using open standards technologies such as XML, SOAP, and WSDL.
SOAP is a lightweight protocol for exchange of information in a service oriented environment. In such an environment, applications can expose selected functionality (business logic, for example) for use by other applications. SOAP provides the means by which applications supply and consume these services; it is an XML-based protocol for message transport in a distributed, decentralized Web Services application environment.
While the core SOAP specification solves many problems related to XML and Web Services, it does not provide a means to address message security requirements such as confidentiality, integrity, message authentication, and non-repudiation. The need for securing SOAP prompted OASIS to put forward the Web Services Security standard, which:
-
Specifies enhancements to allow signing and encryption of SOAP messages.
-
Describes a general-purpose method to associate security tokens with messages.
-
Provides additional means for describing the characteristics of tokens that are included with a message.
1.4 About SAML
Security Assertions Markup Language (SAML) is an XML-based framework for exchanging security information over the Internet. SAML enables the exchange of authentication and authorization information between various security services systems that otherwise would not be able to interoperate.
The SAML 1.0, 1.1, and 2.0 specifications were adopted by the Organization for the Advancement of Structured Information Standards (OASIS) in 2002, 2003, and 2005 respectively. OASIS is a worldwide not-for-profit consortium that drives the development, convergence, and adoption of e-business standards.
SAML 2.0 marks the convergence of the Liberty ID-FF, Shibboleth, and SAML 1.0/1.1 federation protocols.
1.4.1 Understanding SAML Assertions
SAML associates an identity, such as an e-mail address or a directory listing, with a subject, such as a user or system, and defines the access rights within a specific domain. The basic SAML document is the Assertion, which contains declarations of facts about a Subject (typically a user). SAML provides three kinds of declarations, or Statements:
-
AuthnStatementasserts that the user was authenticated by a particular method at a specific time. -
AttributeStatementasserts that the user is associated with particular attributes or details, for example an employee number or account number. -
AuthzDecisionStatementasserts that the user's request for a certain access to a particular resource has been allowed or denied.
Assertions are XML documents generated about events that have already occurred. While SAML makes assertions about credentials, it does not actually authenticate or authorize users. Example 1-1 shows a typical SAML authentication assertion wrapped in a SAMLP response message:
Example 1-1 Sample SAMLP Response Containing a SAML 1.0 Authentication Assertion
<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="123.45.678.90.12345678"
IssueInstant="2005-12-14T10:00:23Z"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success" />
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="123.45.678.90.12345678"
Issuer="IssuingAuthority.com"
IssueInstant="2005-12-14T10:00:23Z" >
<saml:Conditions
NotBefore="2005-12-14T10:00:30Z"
NotAfter="2005-12-14T10:15:00Z" />
</saml:Conditions
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2005-12-14T10:00:20Z">
<saml:Subject>
<saml:NameIdentifier NameQualifier="RelyingParty.com">
john.smith
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>
1.4.2 Understanding SAML Requests and Responses
The authority that issues assertions is known as the issuing authority or identity provider. An issuing authority can be a third-party service provider or an individual business that is serving as an issuing authority within a private federation of businesses. SAML-compliant applications and services, which trust the issuing authority or identity provider and make use of its services, are called relying parties or service providers.
1.4.2.1 About the SAML Request and Response Cycle
In a typical SAML cycle, the relying party (or service provider), which needs to authenticate a specific client request, sends a SAML request to its issuing authority or identity provider. The identity provider responds with a SAML assertion, which supplies the relying party or service provider with the requested security information.
For example, when a user signs into a SAML-compliant service of a relying party or identity provider, the service sends a "request for authentication assertion" to the issuing authority (identity provider). The issuing authority returns an "authentication assertion" reference stating that the user was authenticated by a particular method at a specific time. The service can then pass this assertion reference to other relying party/identity provider sites to validate the user's credentials. When the user accesses another SAML-compliant site that requires authentication, that site uses the reference to request the "authentication assertion" from the issuing authority or identity provider, which states that the user has already been authenticated.
At the issuing authority, an assertion layer handles request and response messages using the SAML protocol, which can bind to various communication and transport protocols (HTTP, SOAP, and so on). Note that while the client always consumes assertions, the issuing authority or identity provider can act as producer and consumer since it can both create and validate assertions.
This cycle is illustrated in Figure 1-1.
This figure shows a SAML request and response cycle, and shows a user, boxes for relying parties, and a box for the issuing authority. The user or client request first goes to the relying party, which sends a SAML request to its issuing authority. The issuing authority responds with a SAML assertion, which supplies the relying party with the requested security information. Two-way arrows denote the client communication with the relying party (there can be more than one relying party), and also denote the request-response communication between the relying party and issuing authority.
Finally, the box for the issuing authority separates out the assertion layer (SAML) from the transport layer (HTTP, SOAP, and so on) to show that the communication between these layers enables the issuing authority to create and validate assertions.
1.4.2.2 About SAML Protocol Bindings and Profiles
SAML defines a protocol, SAMLP, for requesting and obtaining assertions. Bindings define the standard way that SAML request and response messages are transported between the issuing authorities (identity providers) and relying parties (identity providers) by providing mappings between SAML messages and standard communication protocols. For example, the defined transport mechanism for SAML requests and responses is Simple Object Access Protocol (SOAP) over HTTP. This enables the exchange of SAML information across several Web services in a standard manner.
A profile describes how SAML assertion and protocol messages are combined with particular transport bindings to achieve a specific practical use case. Among the most widely-implemented SAML profiles, for example, are Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads.
1.4.2.3 How SAML Integrates with XML Security
In addition, SAML was designed to integrate with XML Signature and XML Encryption, standards from the World Wide Web Consortium for embedding encrypted data or digital signatures within an XML document. This support for XML signatures allows SAML to handle not only authentication, but also message integrity and nonrepudiation of the sender. See Chapter 8 for more information about Oracle XML Security.
1.5 About Identity Federation
As global businesses strive for ever-closer relationships with suppliers and customers, they face challenges in creating more intimate, yet highly secure trading relationships.
Parties conducting a business transaction must be certain of the identity of the person or agent with whom they are dealing; they must also be assured that the other has the authority to act on behalf of the business with whom the transaction is being conducted.
Historically, in the course of doing business with partners, companies have resorted to acquiring names, responsibilities, and other pertinent information about all entities who might act on behalf of the partner company. With changing roles and responsibilities, and particularly in large enterprises, this can create significant logistical problems as the data quickly becomes very costly to maintain and manage.
Besides complexity, other challenges include cost control, enabling secure access to resources for employees and customers, and regulatory compliance, among others.
These requirements are driving the move toward Federated Identity Management, in which parties establish trust relationships that allow one party to recognize and rely upon security tokens issued by another party.
Key federation concepts include:
-
Principal - the key actor in a federated environment, being an entity that performs an authorized business task
-
Identity Provider - a service that authenticates a Principal's identity
-
Service Provider - an entity that provides a service to a principal or another entity. For example, a travel agency can act as a Service Provider to a partner's employees (principals).
-
Single Sign-on - the Principal's ability to authenticate with one system entity (the Identity Provider), and have other entities (the Service Providers) honor that authentication
Note:
For additional information about the standards mentioned here, see Appendix A, "References".1.6 About Oracle Security Developer Tools
This section provides an introduction to the Oracle Security Developer Tools, which are java tools that enable you to implement a wide range of security tasks and projects using the standards we described earlier in this chapter.
1.6.1 Understanding Toolkit Architecture
It is useful to consider the tools in the toolkit as a whole, and then to look at functional subsets of tools for different applications.
Figure 1-2 shows the components of the Oracle Security Developer Tools. Typically, a tool will utilize functions provided by the tool immediately below it in the stack. For example, the Oracle SAML tool leverages functions provided by the Oracle XML Security tool.
Note that:
-
Conceptually, the tools are arranged in layers with the fundamental building blocks at the bottom layer; each additional layer utilizes and builds upon the layer immediately below, to provide tools for specific security applications.
-
The figure is not intended as a hierarchy or sequence diagram. Rather, it illustrates the relationship among components and the progression from low-level tools to more specialized and application-specific components higher up the stack.
Oracle Crypto and Oracle Security Engine are the basic cryptographic tools of the set. The next layer consists of Oracle CMS for message syntax, Oracle XML Security for signature encryption, and Oracle PKI SDK, which is a suite of PKI tools consisting of Oracle PKI LDAP SDK, Oracle PKI TSP SDK, Oracle PKI OCSP SDK, and Oracle PKI CMP SDK. Oracle S/MIME exploits Oracle CMS to provide a toolset for secure e-mail. The next layer contains Oracle SAML and Oracle Liberty SDK, which provides structured assertion markup and federated identity management capabilities. Finally, Oracle Web Services Security facilitates secure interactions with web services.
For a description of each tool, see these sections:
Tools for XML, SAML, and Web Services Security Applications
In addition to providing security for XML documents, the Oracle XML Security package provides the foundation for these components of the toolkit:
-
Oracle Web Services Security
-
Oracle SAML for developing SAML 1.0 and 2.0-compliant Java security services
-
Oracle Liberty SDK for single sign-on (SSO) and federated identity applications based on Liberty Alliance specifications
This graphic shows that Oracle SAML, Oracle Web Services Security, and Oracle Liberty tools are built on Oracle XML Security.
Note:
A diagram like this is necessarily simplified; in practice the jar relationships between the Oracle Security Developer Tools are complex and dependent upon implementation details. For example, to use the SAML libraries, you actually need several components:-
The Oracle XML Security library is needed as SAML requires signatures.
-
Oracle Security Engine provides certificate and CRL management features
See Figure 1-2, "The Oracle Security Developer Tools" for a more complete picture of dependencies. See the subsequent tool chapters in this guide for instructions on setting up the classpath for each tool, so that you have the correct environment for each type of application.
Tools for Public Key Cryptography (PKI) Applications
The Oracle PKI package consists of tools for working with digital certificates within an LDAP repository, for developing timestamp services conforming to RFC 3161, for OCSP messaging compliant with RFC 2560, and tools for the certificate management protocol (CMP) specification. The Oracle PKI package also provides the foundation for Oracle XKMS, which enables you to develop XML transactions for digital signature processing.
This graphic shows that Oracle's XKMS tool is built on Oracle PKI tools, which consist of Oracle LDAP, Oracle TSP, Oracle OCSP, and Oracle CMP.
Tools for E-mail Security Applications
Oracle CMS provides tools for reading and writing CMS objects, as well as the foundation for the Oracle S/MIME tools for e-mail security, including certificate parsing and verification, X.509 certificates, private key encryption, and related features.
This graphic shows that Oracle's S/MIME tool is built on Oracle CMS.
Tools for Low-level Cryptographic Applications
Oracle Crypto provides a broad range of cryptographic algorithms, message digests, and MAC algorithms, as well as the basis for the Oracle Security Engine for X.509 certificates and CRL extensions.
This graphic shows that Oracle Security Engine is built upon the Oracle Crypto tool.
1.6.2 About Supported Standards
The Oracle Security Developer Tools support the standards and protocols shown in Table 1-2.
| Feature/Component | Standard |
|---|---|
|
SAML |
|
|
XML Security Transforms |
The following transforms are supported:
|
|
WS-Security |
WS-Security 1.1, including:
|
Note:
By way of clarification, note that SAML token profile 1.1 applies to SAML 2.0, while SAML token profile 1.0 applies to SAML 1.0 and SAML 1.1.1.6.3 About Oracle Crypto
The Oracle Crypto toolkit provides the following features:
-
Public key cryptography algorithms such as RSA
-
Digital signature algorithms such as Digital Signature Algorithm (DSA) and RSA
-
Key exchange algorithms such as Diffie-Hellman
-
Symmetric cryptography algorithms such as Blowfish, AES, DES, 3DES, RC2, and RC4
-
Message digest algorithms such as MD2, MD4, MD5, SHA-1, SHA-256, SHA-384, and SHA-512
-
MAC algorithms such as HMAC-MD5 and HMAC-SHA-1
-
Methods for building and parsing ASN.1 objects
1.6.4 About Oracle Security Engine
The Oracle Security Engine toolkit provides the following features:
-
X.509 Version 3 Certificates, as defined in RFC 3280
-
Full PKCS#12 support
-
PKCS#10 support for certificate requests
-
CRLs as defined in RFC 3280
-
Implementation of Signed Public Key And Challenge (SPKAC)
-
Support for X.500 Relative Distinguished Name
-
PKCS#7 support for wrapping X.509 certificates and CRLs
-
Implementation of standard X.509 certificates and CRL extensions
1.6.5 About Oracle CMS
Oracle CMS provides an extensive set of tools for reading and writing CMS objects, and supporting tools for developing secure message envelopes.
Oracle CMS implements the IETF Cryptographic Message Syntax specified in RFC-2630. Oracle CMS implements all the RFC-2630 content types.
1.6.6 About Oracle S/MIME
Oracle S/MIME provides the following Secure/Multipurpose Internet Mail Extension (S/MIME) features:
-
Full support for X.509 Version 3 certificates with extensions, including certificate parsing and verification
-
Support for X.509 certificate chains in PKCS#7 and PKCS#12 formats
-
Private key encryption using PKCS#5, PKCS#8, and PKCS#12
-
An integrated ASN.1 library for input and output of data in ASN.1 DER/BER format
1.6.7 About the Oracle PKI SDK
Oracle PKI SDK contains a set of tools for working with digital certificates, including access to LDAP directories, date stamping of digital messages, certificate validation, and certificate management. It includes the following toolkits:
1.6.7.1 About Oracle PKI LDAP SDK
Oracle PKI LDAP SDK provides facilities for accessing a digital certificate within an LDAP directory. Some of the tasks you can perform using the Oracle PKI LDAP SDK are:
-
Validating a user's certificate in an LDAP directory
-
Adding a certificate to an LDAP directory
-
Retrieving a certificate from an LDAP directory
-
Deleting a certificate from an LDAP directory
1.6.7.2 About Oracle PKI TSP SDK
The Oracle PKI TSP SDK provides the following features and functionality:
-
Oracle PKI TSP SDK conforms to RFC 3161 and is compatible with other products that conform to this time stamp protocol (TSP) specification.
-
Oracle PKI TSP SDK provides an example implementation of a TSA server to use for testing TSP request messages, or as a basis for developing your own time stamping service.
1.6.7.3 About Oracle PKI OCSP SDK
The Oracle PKI OCSP SDK provides the following features and functionality:
-
The Oracle PKI OCSP SDK conforms to RFC 2560 and is compatible with other products that conform to this specification, such as Valicert's Validation Authority.
-
The Oracle PKI OCSP SDK API provides classes and methods for constructing OCSP request messages that can be sent through HTTP to any RFC 2560 compliant validation authority.
-
The Oracle PKI OCSP SDK API provides classes and methods for constructing responses to OCSP request messages, and an OCSP server implementation that you can use as a basis for developing your own OCSP server to check the validity of certificates you have issued.
1.6.7.4 About Oracle PKI CMP SDK
Certificate management protocol (CMP) messages support the following set of functions:
-
Registration of an entity, which takes place prior to issuing a certificate
-
Initialization, such as the generation of a key pair
-
Certification (issuing certificates)
-
Key pair recovery for reissuing lost keys
-
Key pair updates when a certificate expires and a new key pair and certificate needs to be generated
-
Revocation requests to the CA to include a certificate in a CRL
-
Cross-certification between two CAs
The Oracle PKI CMP SDK conforms to RFC 2510 and is compatible with other products that conform to this certificate management protocol specification. In addition, it conforms to RFC 2511 and is compatible with other products that conform to this certificate request message format (CRMF) specification.
1.6.8 About Oracle XML Security
XML Security refers to the common data security requirements of XML documents, such as confidentiality, integrity, message authentication, and non-repudiation.
Oracle XML Security fulfills these needs by providing the following features:
-
Support for the Decryption Transform proposed standard
-
Support for the XML Canonicalization standard
-
Support for the Exclusive XML Canonicalization standard
-
Compatibility with a wide range of JAXP 1.1 compliant XML parsers and XSLT engines
1.6.9 About Oracle SAML
The Oracle SAML API provides tools and documentation to assist developers of SAML-compliant Java security services. You can integrate Oracle SAML into existing Java solutions including applets, applications, EJBs, servlets, and JSPs.
Oracle SAML provides the following features:
-
Support for the SAML 1.0/1.1 and 2.0 specifications
-
Support for SAML-based single sign-on (SSO), Attribute, Metadata, Enhanced Client Proxy, and federated identity profiles
1.6.10 About Oracle Web Services Security
Oracle Web Services Security provides an authentication and authorization framework based on Organization for the Advancement of Structured Information Standards (OASIS) specifications. Oracle Web Services Security provides the following features:
-
Support for the SOAP Message Security standard (SOAP 1.1, 1.2)
-
Support for the Username Token Profile standard (UsernameToken Profile 1.1)
-
Support for the X.509 Certificate Token Profile standard
-
Support for the WSS SAML Token Profile (version 1.0)
Note:
The WSS SAML Token Profile version is different from the SAML version.
1.6.11 About Oracle Liberty SDK
Oracle Liberty SDK allows Java developers to design and develop single sign-on (SSO) and federated identity solutions based on the Liberty Alliance specifications. Oracle Liberty SDK, available in versions 1.1 and 1.2, aims to unify, simplify, and extend all aspects of development and integration of systems conforming to the Liberty Alliance 1.1 and 1.2 specifications.
Oracle Liberty SDK provides the following features:
-
Support for the Liberty Alliance Project version 1.1 and 1.2 specifications
-
Support for Liberty-based Single Sign-on and Federated Identity
Note:
For additional information about the standards and specifications mentioned in this chapter, see Appendix A, "References".1.6.12 About Oracle XKMS
Oracle XKMS (XML Key Management Specification) provides a convenient way to handle public key infrastructures by allowing developers to write XML transactions for digital signature processing. Oracle XKMS implements the W3C XKMS standard and avoids some of the cost and complexity involved with public key infrastructures.
1.6.13 About Oracle JWT
Oracle JWT (JSON Web Token) provides support for the JSON Web Token standard. Using Oracle JWT, you can construct and maintain JSON objects to represent claims being transferred between parties using a compact token format.
1.7 References
For details about the documents and specifications supporting the standards mentioned in this chapter, see Appendix A, "References".
For example code demonstrating usage of Oracle Security Developer Tools, see My Oracle Support Knowledge Database Doc ID 1333968.1. (Note: This article is provided for reference only, and is applicable to Release 10g only unless adapted for use with later API versions.)