If you use Apache XML Security or JSR 105 in your applications and products, please download it and test it and report any bugs or issues that you find on the Apache XML Security mailing list.
]]>This configuration works if you are using the JSR 105 bundled with JDK 6. However, if you are using JSR 105 as bundled with Apache XML Security, you need to make a tweak to the configuration file because some of the packages are named differently. Here are the diffs you should apply:
]]>< com.sun.org.apache.xml.internal.security.level = FINER
---
> org.apache.xml.security.level = FINER
If you do this, however, be aware that the JSR 105 service provider implementation is not included by default with JDK 1.4 or JDK 1.5, so you may get some exceptions when instantiating an XMLSignatureFactory:
XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
javax.xml.crypto.NoSuchMechanismException: Mechanism type DOM not available
at javax.xml.crypto.dsig.XMLDSigSecurity.getEngineClassName(Unknown Source)
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source)
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source)
at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance
The easiest workaround is to just instantiate and specify the service provider implementation (bundled with Apache XMLSec) as a parameter as follows:
XMLSignatureFactory factory =
XMLSignatureFactory.getInstance
("DOM", new org.jcp.xml.dsig.internal.dom.XMLDSigRI());
Alternatively, you can register the provider in the java.security file, or use the java.security.Provider API. See http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#ProviderInstalling
"Registering a Provider" for more details.
This will be a great opportunity to learn more about the new Java APIs for XML Signature and Encryption. I'll be showing you programming examples using the new APIs, discussing tips from my blog, and taking a look at the future of XML Signature and Encryption. My session is on Thursday, December 13th at 2PM in Room 6.
]]>SignedInfo.getCanonicalizedData
This method will return an InputStream containing the canonicalized bytes of the SignedInfo element. This method is very useful for debugging signature verification failures; often these are due to subtle changes in the canonicalized bytes, such as XML marshallers that format or "pretty-print" the XML, inserting newlines and other whitespace that break the signature. Here's an example of how to use this API:
System.out.println("Canonicalized SignedInfo:");
InputStreamReader isr =
new InputStreamReader(si.getCanonicalizedData());
char[] cbuf = new char[1024];
while (isr.read(cbuf, 0, 1024) != -1) {
System.out.print(cbuf);
}
System.out.println();
You should compare the SignedInfo element that is output with the SignedInfo element in the Signature.
Reference.getDigestInputStream
This method returns the Reference's pre-digested input stream. Because this data can be potentially large and expensive to keep in memory, you must first enable reference caching. The data returned is the input to the digest operation during a validation or signing operation. This method is very useful for debugging reference validation failures as well as showing the user exactly what was signed, which is very important. The usage of this API is similar to SignedInfo.getCanonicalizedData:
// enable reference caching in your validation context
valContext.setProperty
("javax.xml.crypto.dsig.cacheReference", Boolean.TRUE);
System.out.println("Pre-digested Input:");
InputStreamReader isr =
new InputStreamReader(ref.getDigestInputStream());
char[] cbuf = new char[1024];
while (isr.read(cbuf, 0, 1024) != -1) {
System.out.print(cbuf);
}
System.out.println();
]]>
This is a bugfix release that contains a major fix to the canonicalization engine. This bug was introduced in the 1.4.0 release, so it is highly recommended that anyone using 1.4.0 upgrade to the 1.4.1 version. The bug is that signatures containing non ascii characters created by the 1.4.0 library are not generated according to the standard.
Several other important bugs were fixed in 1.4.1. See the changelog for more information. ]]>
1. Ask the Experts about Java Security in the Java Pavilion (booth #1538)
Time: Tuesday, 12:30 - 1:30 PM
2. Session ID: TS-2594
Session Title: Secure Coding Guidelines, Continued: Preventing Attacks and Avoiding Antipatterns
Time: Wednesday, 9:35 AM - 10:35 AM
3. Session ID: BOF-2516
Session Title: Stump the (Security) Band
Time: Thursday, 8:55 PM - 9:45 PM
This article introduces you to the new XML Digital Signature API in JDK 6 and shows you how to generate and validate an XML Signature using the API. If you want to know more about XML Signatures and how to process them in Java, then start with this article. And let me know if you have any feedback. Thanks!]]>
Let us know your suggestions for features in the security area including topics such as crypto, PKI, SSL, Kerberos, security manager + policy, authorization + JAAS, SASL, XML security, secure coding, performance, ease of use and administration, and everything else related to security. Or if you don't have a specific suggestion but find that there are some things that really annoy you or that you cannot do, we want to hear about that us well.
So I am posing the same question on my blog. Feel free to send your suggestions as comments on my or Andreas blog or directly to me at sean.mullan@sun.com, and together we'll collect all the feedback. As Andreas mentions, due to our limited resources, we will not be able to accomodate all requests. And of course, all Java SE platform features are subject to JCP approval.
Thanks for your feedback!]]>
javax.xml.crypto.URIDereferencer interface, ex:
public class MyURIDereferencer implements URIDereferencer {
...
URIDereferencer that you need to provide an implementation for: the dereference method:
Data dereference(URIReference uriReference,
XMLCryptoContext context)
throws URIReferenceException
URIReference object describing the URI to be dereferenced and an XMLCryptoContext object that may contain additional information (such as the base URI) that is helpful in dereferencing the URI. The method returns a Data object containing the dereferenced data. The API defines two subclasses of Data: OctetStreamData for holding byte streams, and NodeSetData for holding node-sets.
Once you have implemented your URIDereferencer, it can be set as the default URIDereferencer by invoking the XMLCryptoContext.setURIDereferencer method (which takes a URIDereferencer argument), ex:
context.setURIDereferencer(new MyURIDereferencer());
Does this mean MyURIDereferencer is responsible for dereferencing all URI types? Yes. But what if I want to continue to use the built-in support and only add support for new types? Well you can do that too. In your URIDereferencer implementation, you should add some code to fallback to the built-in URIDereferencer for URI types that you do not support. You can do this by calling the XMLSignatureFactory.getURIDereferencer method which returns a reference to the XMLSignatureFactory's built-in implementation of URIDereferencer.
You can get the reference implementation of JSR 105 from the Java Web Service Developer's Pack v2.0, the beta 2 release or latest snapshot of JDK 6 (Mustang), or GlassFish.
]]>Well then, good news. The reference implementation of XML DSig has extensive logging support, that when enabled, will provide you with lots of additional information. The log messages use the JDK logging facility (java.util.logging) so if you are familiar with how to format and configure that, you should breeze through the rest of my blog.
I'll show you two different ways to enable this logging, first if you are running your application from the command-line, and second if you are running it inside a J2EE container, in this case - Sun's Java System Application Server.
If you are running your application from the java command line, you need to configure the logging facility so that the XML DSig logging messages are emitted. You can do this by editing the JRE's default logging.properties file directly, or by creating your own file and set it with the java.util.logging.config.file property, ex:
java -Djava.util.logging.config.file=logging.properties ...
where logging.properties contains:
handlers= java.util.logging.ConsoleHandler .level= INFO java.util.logging.ConsoleHandler.level = FINER java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter org.jcp.xml.dsig.internal.level = FINER com.sun.org.apache.xml.internal.security.level = FINER
This will emit XML DSig log messages of level FINER and higher to the console. All other components will emit log messages of level INFO and higher.
With Sun's Application Server, enable logging using the Application Server admin console:
- In the tree component, select the Application Server node.
- Click the Logging tab.
- On the Logging Settings page, click the Log Levels tab.
- Add a new property named "org.jcp.xml.dsig.internal" with value "FINER"
- Add a new property named "com.sun.org.apache.xml.internal.security" with value "FINER"
- Click Save to save the changes
The log messages will be written to the application server log file.
I won't describe each and every log message in detail, but some of the most helpful are the following:
[java] FINER: Pre-digested input: ...
[java] FINE: Expected digest: ...
[java] FINE: Actual digest: ...
[java] FINE: Canonicalized SignedInfo: ...
You can get the reference implementation of JSR 105 from the Java Web Service Developer's Pack v2.0, an early access snapshot of JDK 6 (Mustang), or GlassFish.
]]>