|Oracle® Fusion Middleware Reference for Oracle Security Developer Tools
11g Release 1 (11.1.1)
Part Number E10037-01
This preface introduces the new and changed features of Oracle Security Developer Tools 11g Release 1 (11.1.1). This information is primarily useful for users who have developed applications with the tools in previous releases of Oracle Application Server, including Oracle Application Server 10g Release 2 (10.1.2.0.2) and Oracle Application Server 10g (10.1.4.0.1).
Topics in this section include:
The new features of Oracle Security Developer Tools include the following:
All higher level toolkits now take JCE keys and certificates as parameters instead of Oracle crypto keys and certificates.
This lets you use any JCE provider, in particular a hardware-based JCE provider.
Note:Due to this change, the 11g Release 1 (11.1.1) APIs are not compatible with pre-11g Release 1 (11.1.1). Your existing code will need to be changed to compile with 11g Release 1 (11.1.1) Oracle Security Developer Tools.
Support for Web Services Security 1.1. This includes:
implementation of Kerberos and SAML 2.0 profiles
WS-i BSP conformance
Upper layers of the toolkit hierarchy that called the Oracle Security Engine now call the new JCE Provider for cryptographic functions
Figure 1-2 depicts the relationships between tools in the toolkit.
Oracle Fusion Middleware 11g contains updates to most classes in the SAML2 library. The fixes fall into a few broad categories:
These include issues such as incorrectly spelled XML element or attribute names, incorrect namespace URIs, or incorrect ordering of child elements.
Many classes were outputting both a default declaration and a prefix-bound declaration for the same namespace. This causes issues for some XML parsers and SOAP implementations, which can cause XML signature verification errors in some 3rd-party SAML software.
The fixes remove the extra default namespace declarations, leaving only the prefix-bound declarations.
Some of the SAML classes needed to have a namespace prefix declared.
Many classes had both a concrete XML element type name and an
xsi:type declaration. This is redundant and confusing; only extension XML types should declare the
xsi:type of the element.
Some classes that implement XML elements with attribute of type
xsd:boolean recognized only the values "true" and "false", while the values "1" and "0" should also be allowed.