Apache Santuario
- Home
- Download
- Security Advisories
- FAQ
- Team
- Contributing
- Mailing Lists
- Issue Tracking
- History
- Old News
Apache XML Security for Java
- Index
- Download
- Release Notes
- FAQ
- API
- Interoperability
Table of Contents |
---|
...
The logging is configured in the config.xml file which either in the xmlsec.jar file or in the class path. This is a little bit complicated as config.xml is used both for library wide configurations like algorithms as well as for the user setting about log4j. This will be changed someday )
In the config.xml file, there is an element called <log4j:configuration>. This element contains the XML style configuration information as defined in the log4j DOMConfigurator class . You can find examples Apache Santuario XML Security for Java uses Apache Commons Logging. For more information see here.
...
Example: Imagine that you want to create a signature to store it on a web server as http://www.acme.com/signatures/sig1.xml. So BaseURI="http://www.acme.com/sig1.xml". This means that if you create a Reference with URI="./index.html", the library can easily use it's HTTPResourceResolver to fetch http://www.acme.com/index.html without that you have to say URI="http://www.acme.com/index.html".
...
The samples divide into two groups: Samples that create and samples that verify Signatures. Eventually, you should adjust the verifying program to another filename if you get FileNotFoundExceptions.
...
...
...
...
Putting this JAR to another location like lib/ext WILL NOT WORK.
For more on that, you can also check the Unofficial JAXP FAQ.
...
Often, this problem is caused by using DOM1 calls like createElement(), setAttribute(), createAttribute(). These are non-namespace-aware and will cause XPath and C14N errors. Always use the DOM2 create(Attribute|Element)NS(...) methods instead, even if you're creating an element without a namespace (in that case, you can use null as a namespace).
The Xalan-J Team told us that DOM1 calls are deprecated and are not to be used in code. xml-security has been reviewed and is DOM1 clean now. The Xalan folks told us that if you create Elements or attributes using DOM1 calls which are not namespace aware, they do not care about any problem you have because of incorrect hehaviour of Xalan.
...
After you have created the XMLSignature object, before you sign the document, you must embed the signature element in the owning document (using a call to XMLSignature.getElement() to retrieve the newly created Element node from the signature) before calling the XMLSignature.sign() method,
...
Of course, there are cross-dependencies: e.g. a KeyResolver named RetrievalMethodResolver uses the ResourceResolver framework to retrieve a public key or certificate from an arbitrary location.
A property was added in the 1.5.0 release to enable "secure validation". This property is true by default from the 2.3.0 release, but false for earlier releases. When set to true, it enforces the following processing rules:
This functionality is supported in the core library through additional method signatures which take a boolean, and in the JSR-105 API via the property "org.apache.jcp.xml.dsig.secureValidation, e.g.:
Code Block | ||||
---|---|---|---|---|
| ||||
XMLValidateContext context = new DOMValidateContext(key, elem);
context.setProperty("org.apache.jcp.xml.dsig.secureValidation", Boolean.TRUE); |
Warning |
---|
Secure Validation should be enabled in production as otherwise various attacks might be possible |