Skip Headers
Oracle® Security Developer Tools Reference
10g (10.1.4.0.1)

Part Number B28165-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

1 Introduction to Oracle Security Developer Tools

Security tools are a critical component for today's 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 like 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.

This chapter takes a closer look at these underlying security technologies and introduces the components of the Oracle Security Developer Tools. It covers these topics:

1.1 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:

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 which can be 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 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 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 was indeed sent by that sender.

Some of the common asymmetric algorithms in use today are RSA, DSA, Diffie-Hellman, and Elliptic Curve Cryptography (ECC).

1.1.1.3 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 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:

Relying third parties use the certificates issued by the CA and the public keys contained therein to verify digital certificates and encrypt data.

1.2.1 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 "Asymmetric Cryptographic Algorithms".

Table 1-1 summarizes who uses public and private keys and when:

Table 1-1 Summary of Public and Private Key Usage

Function Key Type Whose Key

Encrypt data for a recipient

Public key

Receiver

Sign data

Private key

Sender

Decrypt data received

Private key

Receiver

Verify a signature

Public key

Sender


1.2.2 Certificate Authority

A Certificate Authority (CA) is a trusted third party that vouches for the public key owner's identity. Oracle Certificate Authority is one such entity. Others include Verisign and Thawte.

1.2.3 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

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.

Time Stamp Protocol

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 was indeed sent by 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 Web Services Security

Web services provide a standard way for businesses and other 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:

1.4 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 and 2.0 specifications were adopted by the Organization for the Advancement of Structured Information Standards (OASIS) in 2002 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 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. Every SAML document contains an assertion element. SAML defines four kinds of assertions, which are declarations of one or more facts about a subject:

  • Subject assertions, which are used to identify a particular user or system.

  • Authentication assertions, which state that the user has proven his identity by a particular method at a specific time.

  • Attribute assertions, which contain specific details about the user such as an employee number or account number.

  • Authorization assertions, which state the resources a user can access and under what conditions.

Assertions are coded statements 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 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 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. This cycle is illustrated in Figure 1-1.

Figure 1-1 SAML Request-Response Cycle

Description of Figure 1-1 follows
Description of "Figure 1-1 SAML Request-Response Cycle"

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.

1.4.2.2 SAML Protocol Bindings and Profiles

SAML defines a protocol for requesting and obtaining assertions (SAMLP). Bindings define the standard way that SAML request and response messages are transported across 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 assertions are embedded into and extracted out of standard frameworks and protocol. Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads are some of the profiles defined.

1.4.2.3 SAML and 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 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 a federated relationship is established between parties when one party presents its credentials to the other using a process known as "assertions." The receiving party recognizes credentials issued by a trusted trading partner and in an agreed-upon format.

Key federation terminology includes:

The Liberty Alliance is an open organization which establishes technology and business standards for Federated Identity Management to facilitate interoperable identity services.

To learn more about this topic, read the white paper Federated Identity Management, which is available on the Oracle Identity Federation page at http://www.oracle.com/technology/products/id_mgmt/osfs/index.html.


Note:

For additional information about the standards mentioned here, see Appendix A, "References".

1.6 Overview of Oracle Security Developer Tools

This section provides an introduction to Oracle Security Developer Tools, which are pure java tools that enable you to complete a wide range of security projects and tasks.

Figure 1-2 The Oracle Security Developer Tools

Description of Figure 1-2 follows
Description of "Figure 1-2 The Oracle Security Developer Tools"

Figure 1-2 shows the components of the Oracle Security Developer Tools, arranged in layers with the fundamental building-blocks at the bottom layer; each additional layer utilizes and builds upon the previous layers to provide tools for specific security applications.

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 SDK LDAP, Oracle PKI SDK TSP, Oracle PKI SDK OCSP, and Oracle PKI SDK CMP. 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 provides web services security.

A description of each tool follows:

1.6.1 Oracle Crypto

The Oracle Crypto toolkit provides the following features:

1.6.2 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.3 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.4 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.5 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.5.1 Oracle PKI SDK LDAP

Oracle PKI SDK LDAP provides facilities for accessing a digital certificate within an LDAP directory. Some of the tasks you can perform using the Oracle PKI SDK LDAP 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.5.2 Oracle PKI SDK TSP

The Oracle PKI SDK TSP provides the following features and functionality:

  • Oracle PKI SDK TSP conforms to RFC 3161 and is compatible with other products that conform to this time stamp protocol (TSP) specification.

  • Oracle PKI SDK TSP 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.5.3 Oracle PKI SDK OCSP

The Oracle PKI SDK OCSP provides the following features and functionality:

  • The Oracle PKI SDK OCSP conforms to RFC 2560 and is compatible with other products that conform to this specification, such as Valicert's Validation Authority.

  • The Oracle PKI SDK OCSP 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 SDK OCSP 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.5.4 Oracle PKI SDK CMP

The set of functions supported by certificate management protocol (CMP) messages are:

  • 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 SDK CMP conforms to RFC 2510 and is compatible with other products that conform to this certificate management protocol (CMP) 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.6 Oracle JCE Provider

Java Cryptography Extension (JCE) from Sun Microsystems is a framework for implementing encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms.

The Oracle JCE Provider package supplies a concrete implementation of a subset of the cryptographic services defined in JCE.

1.6.7 Oracle XML Security

XML Security refers to 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 W3C XML Signature standard

  • Support for the XML Encryption proposed standard

  • 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.8 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.9 Oracle Web Services Security

Oracle Web Services Security provides an authentication and authorization framework based on OASIS specifications. Oracle Web Services Security provides the following features:

  • Support for the SOAP Message Security standard

  • Support for the Username Token Profile standard

  • Support for the X.509 Certificate Token Profile standard

  • Support for the SAML Assertion Token proposed standard (Draft 15)

1.6.10 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.11 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.