XWS-Security, modify namespace location
Hi,
we are using JWSDP 2.0 and xws-security for sign our SOAP message.
We need to save the payload and the signature in a database and need
to to validate it on some occations. So have to save the <Signature>
Tag. The Problem is it is not valid due to missing namespace
declarations.
Is it possible to modify the placing of namespace, or to modifiy the
defining of namespaces as default ns ?
SECURITY INFO GENERATED BY XWSS:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/w...">
---CUT HERE BEGIN---
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo> ... </ds:SignedInfo>
<ds:SignatureValue> ... </ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference
wsu:Id="XWSSGID-1168439423391-1452886180"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<ds:X509Data> ... </ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
---CUT HERE END---
</wsse:Security>
===> IF WE CUT THE SINGATURE PART, THE NS-PREFIX wsse IS NOT BOUND
A BETTER SOLUTION WOULD BE:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/w...">
---CUT HERE BEGIN---
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> ... </SignedInfo>
<SignatureValue> ... </SignatureValue>
<KeyInfo>
<SecurityTokenReference
xmlns="http://docs.oasis-open.org/w...">
<X509Data xmlns="http://www.w3.org/2000/09/xmldsig#"> ... </X509Data>
</SecurityTokenReference>
</KeyInfo>
</Signature>
---CUT HERE END---
</wsse:Security>
Any idea how to resolve this problem ?
Thanks for help.
Simil.
no it is not possible to change the namespace
Similar Messages
-
Hi guys,
I finished running the xws-security samples in the JWSDP, and start trying to build a web services with xws-security feature.
I copied the "config" folder containing config xml files, and the build.properties file from the sample to my own netbeans project folder. The build file was modified as well. I simply added the "-security" option followed by the path of the config file to the <wscompile> tag in the build file.
<wscompile sourceBase="${build.generated.dir}/wsservice" features="${wscompile.service.sec.features}" config="${sec.config.name}"
mapping="${build.web.dir.real}/WEB-INF/${sec.mapping}" classpath="${wscompile.classpath}:${build.classes.dir.real}:${javac.classpath}"
nonClassDir="${build.web.dir.real}/WEB-INF/wsdl"
verbose="true" xPrintStackTrace="true" base="${build.generated.dir}/wsbinary"
keep="true"
fork="true"
define="true"
security="${client.security.config}"/>No errors came out during the Build process. However, I looked in to the wsdl file created, and found that it seemed the xws-security did not take any effects.
Did I miss something? Is adding the -security option of the wscompile command the only step I should take while deploying the xws-security?Hi,
i am a new user of xws security.Since you have already done the simple example,I rather ask you a question about it.i am getting the following message..........wher'e build is failed!!!! i am using jdk1.5, app server 8....if you know the solution plz help me.
C:\Sun\jwsdp-1.6\xws-security\samples\simple>asant run-sample
Buildfile: build.xml
clean:
[delete] Deleting directory C:\Sun\jwsdp-1.6\xws-security\samples\simple\buil
d
[delete] Deleting directory C:\Sun\jwsdp-1.6\xws-security\samples\simple\dist
as8-check:
[mkdir] Created dir: C:\Sun\jwsdp-1.6\xws-security\samples\simple\build\clie
nt\classes
[mkdir] Created dir: C:\Sun\jwsdp-1.6\xws-security\samples\simple\build\serv
er\WEB-INF\classes
[mkdir] Created dir: C:\Sun\jwsdp-1.6\xws-security\samples\simple\dist
ws-check:
tc-check:
compile-handler-code:
[echo] Compiling the handler source code
[javac] Compiling 1 source file to C:\Sun\jwsdp-1.6\xws-security\samples\sim
ple\build\server\WEB-INF\classes
[javac] C:\Sun\jwsdp-1.6\xws-security\samples\simple\src\sample\SecurityEnvi
ronmentHandler.java:44: package com.sun.org.apache.xml.internal.security.utils d
oes not exist
[javac] import com.sun.org.apache.xml.internal.security.utils.RFC2253Parser;
[javac] ^
[javac] C:\Sun\jwsdp-1.6\xws-security\samples\simple\src\sample\SecurityEnvi
ronmentHandler.java:351: cannot find symbol
[javac] symbol : variable RFC2253Parser
[javac] location: class sample.SecurityEnvironmentHandler
[javac] RFC2253Parser.normalize(x509Cert.getIssuerDN().g
etName());
[javac] ^
[javac] C:\Sun\jwsdp-1.6\xws-security\samples\simple\src\sample\SecurityEnvi
ronmentHandler.java:410: cannot find symbol
[javac] symbol : variable RFC2253Parser
[javac] location: class sample.SecurityEnvironmentHandler
[javac] RFC2253Parser.normalize(x509Cert.getIssuerDN().g
etName());
[javac] ^
[javac] 3 errors
BUILD FAILED
C:\Sun\jwsdp-1.6\xws-security\samples\simple\build.xml:68: Compile failed; see t
he compiler error output for details.
Total time: 10 seconds -
Hi everyone,
I am trying to deploy the simple sample for xws-security in the JWSDP 1.4 on redhat 9.0, I have done all the configurations as suggested by the tutorial and the readme file in the sample. But when I tried to run the sample by running "asant run-sample", I got a "wsdeploy failed" error. It looks like the following and happened at the "process-war" stage: (The earlier targets including "clean", "prepare", "gen-server", "compile-server", " set-web-inf", "raw-war" etc. work fine).
[snip]
process-war:
[echo] Running wsdeploy...
[wsdeploy] Exception in thread "main" java.lang.NoSuchMethodError: org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.<init>(Lorg/apache/xml/dtm/DTMManager;Ljavax/xml/transform/Source;ILorg/apache/xml/dtm/DTMWSFilter;Lorg/apache/xml/utils/XMLStringFactory;ZIZZ)V
[wsdeploy] at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2.<init>(SAX2DTM2.java:1901)
[wsdeploy] at org.apache.xalan.xsltc.dom.SAXImpl.<init>(SAXImpl.java:767)
[wsdeploy] at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:324)
[wsdeploy] at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:267)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:477)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:637)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.DeployTool.defineServletsAndListeners(DeployTool.java:553)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.DeployTool.run(DeployTool.java:255)
[wsdeploy] at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:43)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.Main.main(Main.java:22)
[wsdeploy] Command invoked: /work/nzw3/SUNWappserver/jdk/jre/bin/java -classpath /work/nzw3/SUNWappserver/lib/endorsed/dom.jar:/work/nzw3/SUNWappserver/lib/endorsed/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/endorsed/xalan.jar:/work/nzw3/SUNWappserver/lib/ant/lib/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/ant/lib/ant.jar:/work/nzw3/SUNWappserver/lib/ant/lib/xml-apis.jar:/work/nzw3/SUNWappserver/lib/ant/lib/optional.jar:/work/nzw3/SUNWappserver/lib/soapprocessor.jar:/work/nzw3/SUNWappserver/lib/jaxr-api.jar:/work/nzw3/SUNWappserver/lib/saaj-api.jar:/work/nzw3/SUNWappserver/lib/activation.jar:/work/nzw3/SUNWappserver/lib/security-plugin.jar:/work/nzw3/SUNWappserver/lib/jaxb-xjc.jar:/work/nzw3/SUNWappserver/lib/jax-qname.jar:/work/nzw3/SUNWappserver/lib/jhall.jar:/work/nzw3/SUNWappserver/lib/xmlsec.jar:/work/nzw3/SUNWappserver/lib/j2ee-svc.jar:/work/nzw3/SUNWappserver/lib/deployment/sun-as-jsr88-dm.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-sec.jar:/work/nzw3/SUNWappserver/lib/mail.jar:/work/nzw3/SUNWappserver/lib/appserv-admin.jar:/work/nzw3/SUNWappserver/lib/jaxb-impl.jar:/work/nzw3/SUNWappserver/lib/appserv-cmp.jar:/work/nzw3/SUNWappserver/lib/appserv-jstl.jar:/work/nzw3/SUNWappserver/lib/jaxb-libs.jar:/work/nzw3/SUNWappserver/lib/jwsdp-tools-lib/jax-qname.jar:/work/nzw3/SUNWappserver/lib/jwsdp-tools-lib/namespace.jar:/work/nzw3/SUNWappserver/lib/jaxr-impl.jar:/work/nzw3/SUNWappserver/lib/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-spi.jar:/work/nzw3/SUNWappserver/lib/verifier/verifierhelp.jar:/work/nzw3/SUNWappserver/lib/xalan.jar:/work/nzw3/SUNWappserver/lib/appserv-upgrade.jar:/work/nzw3/SUNWappserver/lib/appserv-assemblytool.jar:/work/nzw3/SUNWappserver/lib/deployhelp.jar:/work/nzw3/SUNWappserver/lib/j2ee.jar:/work/nzw3/SUNWappserver/lib/xmldsig.jar:/work/nzw3/SUNWappserver/lib/commons-logging.jar:/work/nzw3/SUNWappserver/lib/saaj-impl.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-impl.jar:/work/nzw3/SUNWappserver/lib/appserv-tags.jar:/work/nzw3/SUNWappserver/lib/appserv-ext.jar:/work/nzw3/SUNWappserver/lib/relaxngDatatype.jar:/work/nzw3/SUNWappserver/lib/admin-cli.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-api.jar:/work/nzw3/SUNWappserver/lib/jsf-api.jar:/work/nzw3/SUNWappserver/lib/jaxb-api.jar:/work/nzw3/SUNWappserver/lib/install/applications/__cp/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/__ds/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/__xa/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/jmsra/imqjmsra.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/cc.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admingui-jsp.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/framework.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/jato.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin-en.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin-xml.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/framework-en.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/help.jar:/work/nzw3/SUNWappserver/lib/install/applications/samples.jar:/work/nzw3/SUNWappserver/lib/install/applications/com_sun_web_ui/WEB-INF/lib/registrationservlet.jar:/work/nzw3/SUNWappserver/lib/install/applications/jaxr-ra/jaxr-ra.jar:/work/nzw3/SUNWappserver/lib/commons-launcher.jar:/work/nzw3/SUNWappserver/lib/jsf-impl.jar:/work/nzw3/SUNWappserver/lib/sun-appserv-ant.jar:/work/nzw3/SUNWappserver/lib/appserv-rt.jar:/work/nzw3/SUNWappserver/lib/xsdlib.jar:/work/nzw3/j2sdk1.4.2_04/lib/tools.jar com.sun.xml.rpc.tools.wsdeploy.Main -keep -tmpdir /work/nzw3/jwsdp-1.4/xws-security/samples/simple/build/server -o /work/nzw3/jwsdp-1.4/xws-security/samples/simple/dist/securesimple.war /work/nzw3/jwsdp-1.4/xws-security/samples/simple/dist/simple-portable.war
BUILD FAILED
file:/work/nzw3/jwsdp-1.4/xws-security/samples/simple/build.xml:108: wsdeploy failed
If anyone has any idea about this problem, please let me know.
Many thanks,
JakeHello again,
I got progress today, but still have some errors for the simple sample in the xws-security . (I am running on Redhat 9.0 and with Sun Java System Application Server 8) Looks like the sending message is ok, but at the receiving message stage, I got the following errors when running "asant run-sample":
[snip]
run-sample:
[echo] Running the simple.TestClient program....
[java] Service URL=http://giga15.ncl.ac.uk:8080/securesimple/Ping
[java] Sep 8, 2004 1:14:19 AM com.sun.xml.wss.filter.DumpFilter process
[java] INFO: ==== Sending Message Start ====
[java] <?xml version="1.0" encoding="UTF-8"?>
[java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[java] <env:Header>
[java] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
[java] <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="Id4487442798885738858">MIIFKDCCBBCgAwIBAgICBl4wDQYJKoZIhvcNAQEEBQAwcDELMAkGA1UEBhMCVUsxETAPBgNVBAoT
[java] CGVTY2llbmNlMRIwEAYDVQQLEwlBdXRob3JpdHkxCzAJBgNVBAMTAkNBMS0wKwYJKoZIhvcNAQkB
[java] Fh5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMudWswHhcNMDQwMjEwMTQzMDUyWhcNMDUwMjA5
[java] MTQzMDUyWjBcMQswCQYDVQQGEwJVSzERMA8GA1UEChMIZVNjaWVuY2UxEjAQBgNVBAsTCU5ld2Nh
[java] c3RsZTEPMA0GA1UEBxMGTkVSZVNDMRUwEwYDVQQDEwxqYWtlIHpoZW5nd3UwgZ8wDQYJKoZIhvcN
[java] AQEBBQADgY0AMIGJAoGBAO7B3texMjuzdA6zT6/F/hx3U4a+iWglhNWptB3JerhHHu7El0HkWky0
[java] 9AzYVKZ7Y3n5qpgmSOe16a2MKySii5ud44DABj+3qkRBzkb/LDgNuF02X/XORbFbuZYEWwCHckZI
[java] xQ50vJpdxJQqLOwrhMP48RXNBzrdXo9iYfcWP5cnAgMBAAGjggJiMIICXjAMBgNVHRMBAf8EAjAA
[java] MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA+gwLAYJYIZIAYb4QgENBB8WHVVLIGUt
[java] U2NpZW5jZSBVc2VyIENlcnRpZmljYXRlMB0GA1UdDgQWBBRlyb19GkybkmGa6QnQ9fPZ7mQ+NzCB
[java] mgYDVR0jBIGSMIGPgBQCOKsRo5aAiw3TFSsIpY4w2rLaqKF0pHIwcDELMAkGA1UEBhMCVUsxETAP
[java] BgNVBAoTCGVTY2llbmNlMRIwEAYDVQQLEwlBdXRob3JpdHkxCzAJBgNVBAMTAkNBMS0wKwYJKoZI
[java] hvcNAQkBFh5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMudWuCAQAwKQYDVR0SBCIwIIEeY2Et
[java] b3BlcmF0b3JAZ3JpZC1zdXBwb3J0LmFjLnVrMBkGA1UdIAQSMBAwDgYMKwYBBAHZLwEBAQEEMD0G
[java] CWCGSAGG+EIBBAQwFi5odHRwOi8vY2EuZ3JpZC1zdXBwb3J0LmFjLnVrL2NnaS1iaW4vaW1wb3J0
[java] Q1JMMD0GCWCGSAGG+EIBAwQwFi5odHRwOi8vY2EuZ3JpZC1zdXBwb3J0LmFjLnVrL2NnaS1iaW4v
[java] aW1wb3J0Q1JMMDwGCWCGSAGG+EIBBwQvFi1odHRwOi8vY2EtcmVuZXcuZ3JpZC1zdXBwb3J0LmFj
[java] LnVrL3JlbmV3Lmh0bWwwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDovL2NhLmdyaWQtc3VwcG9ydC5h
[java] Yy51ay9jZ2ktYmluL2ltcG9ydENSTDANBgkqhkiG9w0BAQQFAAOCAQEAgdN714aoC53Wef9JGaDD
[java] PDJkmgmwVbL8ZuovBpORFsgy2GOPgIdtw15qTQx1NFbsFqW2I7d/9AteeXAk3sUGUODOvq8loeYB
[java] iA+QofduwJ0VWO8TZ0e+7+J3cDQKbsukptRJd2L2W8PeCNPojCRkfiV/nT6BiF5yjh4Ui5e+pWGw
[java] t3oN1qFDZViCFOTiB6Koi0MB+cu47gOEIxBQfP8jTEyf/SSy4RzjI+7C1LpDYCZpO/jqXMb67j9b
[java] KdcmlWhMrzNOyRDM7A11rt5nBMABgRVAJsdBZIDevfKJ/kRGxUHGHqf8Pg+3qK22mNwMN8U2plr7
[java] TgORAx6aOn4EQP2AzA==</wsse:BinarySecurityToken>
[java] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[java] <ds:SignedInfo>
[java] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[java] <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[java] <ds:Reference URI="#Id5553294937503469412">
[java] <ds:Transforms>
[java] <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[java] </ds:Transforms>
[java] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[java] <ds:DigestValue>AcRqiIoxfOWauZ/FDnng4D1C5WU=</ds:DigestValue>
[java] </ds:Reference>
[java] </ds:SignedInfo>
[java] <ds:SignatureValue>
[java] omVS7TF+IqESZuMcRdsFfet8INaU4J9Vall1oGaPMRoEkc9xks+YK2ew4nG7hSekITwJrQLx42hH
[java] Vb6HvEdWgsIrjOJslqQILQkYU7qdoptb6OEgY5lHQpjUJaTKNn4krsDXgpwZieQE45Gcu/zuP4eY
[java] v8yMhUwVUE8xHy+6dLs=
[java] </ds:SignatureValue>
[java] <ds:KeyInfo>
[java] <wsse:SecurityTokenReference>
[java] <wsse:Reference URI="#Id4487442798885738858" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
[java] </wsse:SecurityTokenReference>
[java] </ds:KeyInfo>
[java] </ds:Signature>
[java] </wsse:Security>
[java] </env:Header>
[java] <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id5553294937503469412">
[java] <ns0:Ping>
[java] <ns0:ticket>SUNW</ns0:ticket>
[java] <ns0:text>Hello !</ns0:text>
[java] </ns0:Ping>
[java] </env:Body>
[java] </env:Envelope>
[java] ==== Sending Message End ====
[java] Sep 8, 2004 1:14:23 AM com.sun.xml.wss.filter.DumpFilter process
[java] INFO: ==== Received Message Start ====
[java] <?xml version="1.0" encoding="UTF-8"?>
[java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[java] <env:Body>
[java] <env:Fault>
[java] <faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ans1:InvalidSecurityToken</faultcode>
[java] <faultstring>Certificate validation failed</faultstring>
[java] </env:Fault>
[java] </env:Body>
[java] </env:Envelope>
[java] ==== Received Message End ====
[java] Sep 8, 2004 1:14:23 AM com.sun.xml.wss.filter.ProcessSecurityHeaderFilter process
[java] WARNING: Message does not contain wsse:Security header
[java] Exception in thread "main" javax.xml.rpc.soap.SOAPFaultException: Certificate validation failed
[java] at com.sun.xml.rpc.client.StreamingSender._raiseFault(StreamingSender.java:515)
[java] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:294)
[java] at simple.PingPort_Stub.ping(PingPort_Stub.java:80)
[java] at simple.TestClient.main(TestClient.java:37)
[java] Java Result: 1
I don't know if I have configured anything wrong. Basically, i just want to sign the outgoing soap message with my own p12 format certificate, hence I have chosen the following in the $JWSDP_HOME/xws-security/samples/simple/build.properties :
client.security.config=config/sign-client.xml
server.security.config=config/dump-server.xml
Also, according to the last section of the jWSDP release notes at http://java.sun.com/webservices/docs/1.4/ReleaseNotes.html#KnownIssues
I added these two changes,
1. In the <jwsdp.home>/xws-security/samples/buildconfig/sjsas-config.xml file, delete the original .... app.classpath element definition and replace it with the following definition:
<path id="app.classpath">
<fileset dir="${sjsas.home}/lib/endorsed">
<include name="dom.jar"/>
</fileset>
<fileset dir="${sjsas.home}/lib">
<include name="*.jar"/>
</fileset>
<fileset dir="${javahome}/lib">
<include name="tools.jar"/>
</fileset>
</path>
2. In the <as.home>/domains/domain1/config/server.policy file, add the following configurations to the server.policy file, for the securesimple sample and pingservice samples, respectively.
// These permissions apply to securesimple webapp grant codeBase "file:${com.sun.aas.instanceRoot}/applications/j2ee-modules/securesimple/WEB-INF/-" {
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
permission javax.security.auth.AuthPermission "getSubject";
permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential * \"*\"","read";
permission java.security.SecurityPermission "putProviderProperty.BC";
Moreover, has the sent message really been signed correctly? how can I tell the message has been signed by my own certificate? I have done the following:
1. In the $JWSDP_HOME/xws-security/samples/simple/config/sign-client.xml, change to
<xwss:SecurityConfiguration
xmlns:xwss="http://com.sun.xml.wss.configuration" dumpMessages="true">
<xwss:Sign/>
</xwss:SecurityConfiguration>
2. In the $JWSDP_HOME/xws-security/samples/simple/config/build.xml, change to something like the following in the run-sample target,
<sysproperty key="javax.net.ssl.keyStore" value="/work/nzw3/jakenew.p12"/>
<sysproperty key="javax.net.ssl.keyStorePassword" value="jake"/>
<sysproperty key="javax.net.ssl.keyStoreType" value="pkcs12"/>
I didn't change anything about truststore.
What was the problem? What have I done wrong?
Many thanks,
Jake -
Xws-security and fault messages
Hi,
I have a problem with xws-security and fault messages.
It seems that the security policy is not applied to fault messages. This results in a "javax.xml.rpc.soap.SOAPFaultException: Message does not conform to configured policy: No Security Header found" exception whenever a fault message is thrown.
As a result I can not use any meaningful application-specific fault messages as they violate the security policy. Is this correct? Surely a fault message is a SOAP message just like any other and should have the security policy applied to it as usual, or am i missing something here?
If anyone can shed any light on this i'd really appreciate it.XWS-Security is not integrated with Sun Java Studio Enterprise. However, if you would like to implement message level security in a web service in the Java Studion Enterprise environment, you may find this article useful:
http://developers.sun.com/prodtech/javatools/jsenterprise/downloads/ea/jse8/reference/techart/security.html
Rico -
Xws-security returns always HTTP 200
Hi,
I am using libraries of JWSDP 2.0, jaxws and xws-security.
My web service was generated from a WSDL schema and works so
far fine. I need to secure the transportation with a xml signature.
For that I am using the xws libraries.
My problem is that xws-security and jaxws returns always HTTP 200. I
would expect a negative HTTP status code if the signature validation
fails, such as HTTP 401 or HTTP 500 or whatever.
Is this a bug or any idea what my problem might be ?
Thanks,
Simel.Hi,
I am using libraries of JWSDP 2.0, jaxws and xws-security.
My web service was generated from a WSDL schema and works so
far fine. I need to secure the transportation with a xml signature.
For that I am using the xws libraries.
My problem is that xws-security and jaxws returns always HTTP 200. I
would expect a negative HTTP status code if the signature validation
fails, such as HTTP 401 or HTTP 500 or whatever.
Is this a bug or any idea what my problem might be ?
Thanks,
Simel. -
Compilation error- xws-security sample aplication for signing
hi
I tried to run the sample application (xws-security) in JWSDP 1.6 but i am getting the following error.
[echo] Running wscompile....
[wscompile] C:\Sun\jwsdp-2.0\xws-security\samples\simple\build\server\WEB-INF\c
asses\simple\PingService.java:10: cannot access java.lang.Object
[wscompile] bad class file: C:\Sun\AppServer\jdk\jre\lib\rt.jar(java/lang/Objec
.class)
[wscompile] class file has wrong version 49.0, should be 48.0
[wscompile] Please remove or make sure it appears in the correct subdirectory o
the classpath.
[wscompile] public interface PingService extends javax.xml.rpc.Service {
[wscompile] ^
[wscompile] 1 error
[wscompile] error: compilation failed, errors should have been reportedit worked ....thank you ghstark
-
Script to modify the location attribute in an existing subnet registered on AD sites
Could anyone help me to make an script to modify the location attribute in an existing subnet registered on AD sites and services.
Using the script to create subnet, like this one below, occurs error because the subnet already exist:
Set objRootDSE = GetObject("LDAP://RootDSE")
strConfigurationNC = objRootDSE.Get("configurationNamingContext")
strSiteObjectDN = strSiteObjectRDN & ",cn=Sites," & strConfigurationNC
strSubnetsContainer = "LDAP://cn=Subnets,cn=Sites," & strConfigurationNC
'-- Create Subnet --
Set objSubnetsContainer = GetObject(strSubnetsContainer)
Set objSubnet = objSubnetsContainer.***MODIFY/UPDATE***("subnet", strSubnetRDN)
objSubnet.Put "siteObject", strSiteObjectDN
objSubnet.Put "description", strDescription
objSubnet.Put "location", strLocation
objSubnet.SetInfo
Thanks,Just get the subnet by name:
subnet = "192.168.1.0\/24"
Set objRootDSE = GetObject("LDAP://RootDSE")
strConfigurationNC = objRootDSE.Get("configurationNamingContext")
strSiteObjectDN = strSiteObjectRDN & ",cn=Sites," & strConfigurationNC
strSubnet = "LDAP://CN=" & subnet & ",cn=Subnets,cn=Sites," & strConfigurationNC
Set objSubnet = GetObject(strSubnet)
objSubnet.Put "description", strDescription
objSubnet.Put "location", strLocation
objSubnet.SetInfo
¯\_(ツ)_/¯ -
XWS-Security and Sun Java Studio Enterprise
Hi,
Does anyone knows whether XWS-Security API is integrated into Sun Java Studio Enterprise?
I can't find the information anywhere in the java site. If there happens to be one, could you let me know about it?
Thanks in advance :)XWS-Security is not integrated with Sun Java Studio Enterprise. However, if you would like to implement message level security in a web service in the Java Studion Enterprise environment, you may find this article useful:
http://developers.sun.com/prodtech/javatools/jsenterprise/downloads/ea/jse8/reference/techart/security.html
Rico -
XWS-Security: Is XWSSecurityConfiguration thread-safe?
Hello, there. Can I read the security config file once into an XWSSecurityConfiguration object and use that same object over and over for each stub/port? I am hoping so as I wouldn't want to read the config file each time.
(Btw, I am using the XWS-Security packaged in JWSDP 2.0.)
Thanks,
EverAny takers? (hopefully, bumping this up the list will catch the attention of someone who knows.)
-
Are there any tutorials or examples demonstrating how to setup a webservice and client using XWS-Security from scratch? I've setup the sample applications that come with JWSDP, but I would like a tutorial that walks through the process of setting up a web service, using callbacks, to validate a user login.
I'm glad I'm not the only one that finds the JWSDP documentation obtuse and difficult to translate into my own situation. If anyone knows of any good "how-tos" that really explain how to use XWS-Security, then please post them. I'm struggling mightily with it.
-
Errors trying to run the xws-security sample app
Hi all,
I'm geting errors trying to compile the xws-security sample app, does anyone have any advice? Thanks in advance!
[kerzhner@kerzhner]~/jwsdp-1.5/xws-security/samples/simple% ant run-sample Buildfile: build.xml
clean:
[delete] Deleting directory /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/build
[delete] Deleting directory /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/dist
as8-check:
ws-check:
tc-check:
[mkdir] Created dir: /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/build/client/classes
[mkdir] Created dir: /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/build/server/WEB-INF/classes
[mkdir] Created dir: /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/dist
compile-handler-code:
[echo] Compiling the handler source code
[javac] Compiling 1 source file to /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/build/server/WEB-INF/classes
[javac] /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/src/com/sun/xml/wss/sample/SecurityEnvironmentHandler.java:0: error: malformed .zip archive in CLASSPATH: /home/kerzhner/jdk1.5.0_03/lib/tools.jar/
[javac] /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/src/com/sun/xml/wss/sample/SecurityEnvironmentHandler.java:25: error: Class or interface `java.security.cert.X509CertSelector' not found in import.
[javac] import java.security.cert.X509CertSelector;
[javac] ^
[javac] /home/kerzhner/jwsdp-1.5/xws-security/samples/simple/src/com/sun/xml/wss/sample/SecurityEnvironmentHandler.java:535: error: Type `X509CertSelector' not found in the declaration of the local variable `certSelector'.
[javac] X509CertSelector certSelector = new X509CertSelector();
[javac] ^
[javac] 2 errors
BUILD FAILED
file:/home/kerzhner/jwsdp-1.5/xws-security/samples/simple/build.xml:68: Compile failed; see the compiler error output for details.Resolved. It was a space issue. Deleted a couple of old apps and have now installed the Sample Websheet Application.
-
JWSDP 1.6 xws-security Simple fails with "block not properly padded"
Environment:
- Windows 2000
- Tomcat50-jwsdp
- JAVA_HOME=C:/Progra~1/Java/jdk1.5.0_05
- Security environment handler: SecurityEnvironmentHandler.java supplied with JWSDP 1.6 (Hello, Ron!)
I get the following in the Tomcat Window:
==== Received Message End ====
Nov 13, 2005 10:38:56 AM com.sun.org.apache.xml.internal.security.encryption.XMLCipher decryptKey
INFO: Decryption of key type http://www.w3.org/2001/04/xmlenc#tripledes-cbc OK
Nov 13, 2005 10:38:56 AM com.sun.xml.wss.impl.apachecrypto.DecryptionProcessor decryptElementWithCipher
SEVERE: WSS_ENC0004: Exception [ Given final block not properly padded ] while trying to decrypt message
Nov 13, 2005 10:38:56 AM com.sun.xml.wss.impl.filter.DumpFilter process
INFO: ==== Sending Message Start ====
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/enco
ding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.or
g/2001/XMLSchema-instance">
<env:Body>
<env:Fault>
<faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ans1:Fail
edCheck</faultcode>
<faultstring>Unable to decrypt message</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
==== Sending Message End ====
Please help!
GeorgeHi, I got the xws-security/samples/simple application
working successfully with my own keystores. I have 2
questions regarding this sample application.
1) When running the application with the
encrypt-server.xml and encrypt-client.xml
configuration, why is it necessary to import the
client's certificate into the server's truststore and
the server's certificate into client's truststore when
their certificates have already been signed by a
trusted root CA (e.g. Verisign), whose certificate is
in both truststores? Shouldn't their certificates
containing their public keys get automatically
exchanged during the connection request? It's a pain
to publish a web service and expect a manual public
certificate import for each client wanting to use the
service.Certificates are sent only when the keyReferenceType is "Direct" which is the default. It's possible that our code is checking the certificate sent with one found in the KeyStore, but a quick scan of the code doesn't show it. If that's what's happening it's a bug. All of the other key reference strategies send only a referece to the sender's certificate in which case the reciever must have a copy of that certificate in its keystore.
2) I use Tomcat to run the sample application and did
set up the SSL connector to point to the keystores.
When the client connects to the server, it uses a
http endpoint not https. I'm aware that htpps is
needed for SSL support but not clear on where does
https come into play during the client's
request/server's response process.We share the SSL keystore so that certificates don't have to be stored in more than one place. The functionality of XWS-Security and SSL is logically the same so it make sense to use the same keystore. XWS-Security operates completely separately from the transport and never knows whether HTTPS is in use or not.
Phil Goodwin
Technical Lead
XWS-Security -
JWSDP 1.5: Certificates for XWS-Security samples expired April 9
The digitial certificates supplied with the XWS-Security samples in JWSDP 1.5 (e.g., JWSDP_HOME/xws-security/etc/client-truststore.jks) expired April 9, 2005. The XWSS sample programs now fail because the certificates are invalid. Are newer versions of the truststores available to replace the existing truststores, or do I need reinstall JWSDP to get newer certificates?
Thanks,
MikeI am having the same problem. I tried creating my own RSA keys with the same aliases, self signing them and putting them into the key/trust stores but still get errors. What procedure is there to replace them? Included below are my steps for dropping the certs and adding in new self signed ones, that I tried.
Josh
keytool -delete -keystore server-keystore.jks -alias s1as -storepass changeit
keytool -delete -keystore client-truststore.jks -alias s1as -storepass changeit
keytool -genkey -keyalg RSA -alias s1as -keystore server-keystore.jks -dname "cn=Client" -keypass changeit -storepass changeit
keytool -selfcert -alias s1as -keystore server-keystore.jks -keypass changeit -storepass changeit
keytool -export -keystore server-keystore.jks -alias s1as -storepass changeit -file s1as
keytool -import -alias s1as -keystore client-truststore.jks -storepass changeit -file s1as
keytool -delete -keystore client-keystore.jks -alias xws-security-client -storepass changeit
keytool -delete -keystore server-truststore.jks -alias xws-security-client -storepass changeit
keytool -genkey -keyalg RSA -alias xws-security-client -keystore client-keystore.jks -dname "cn=Client" -keypass changeit -storepass changeit
keytool -selfcert -alias xws-security-client -keystore client-keystore.jks -keypass changeit -storepass changeit
keytool -export -keystore client-keystore.jks -alias xws-security-client -storepass changeit -file xws-security-client
keytool -import -alias xws-security-client -keystore server-truststore.jks -storepass changeit -file xws-security-client -
Hi, I got the xws-security/samples/simple application working successfully with my own keystores. I have 2 questions regarding this sample application.
1) When running the application with the encrypt-server.xml and encrypt-client.xml configuration, why is it necessary to import the client's certificate into the server's truststore and the server's certificate into client's truststore when their certificates have already been signed by a trusted root CA (e.g. Verisign), whose certificate is in both truststores? Shouldn't their certificates containing their public keys get automatically exchanged during the connection request? It's a pain to publish a web service and expect a manual public certificate import for each client wanting to use the service.
2) I use Tomcat to run the sample application and did set up the SSL connector to point to the keystores. When the client connects to the server, it uses a http endpoint not https. I'm aware that htpps is needed for SSL support but not clear on where does https come into play during the client's request/server's response process.Hi, I got the xws-security/samples/simple application
working successfully with my own keystores. I have 2
questions regarding this sample application.
1) When running the application with the
encrypt-server.xml and encrypt-client.xml
configuration, why is it necessary to import the
client's certificate into the server's truststore and
the server's certificate into client's truststore when
their certificates have already been signed by a
trusted root CA (e.g. Verisign), whose certificate is
in both truststores? Shouldn't their certificates
containing their public keys get automatically
exchanged during the connection request? It's a pain
to publish a web service and expect a manual public
certificate import for each client wanting to use the
service.Certificates are sent only when the keyReferenceType is "Direct" which is the default. It's possible that our code is checking the certificate sent with one found in the KeyStore, but a quick scan of the code doesn't show it. If that's what's happening it's a bug. All of the other key reference strategies send only a referece to the sender's certificate in which case the reciever must have a copy of that certificate in its keystore.
2) I use Tomcat to run the sample application and did
set up the SSL connector to point to the keystores.
When the client connects to the server, it uses a
http endpoint not https. I'm aware that htpps is
needed for SSL support but not clear on where does
https come into play during the client's
request/server's response process.We share the SSL keystore so that certificates don't have to be stored in more than one place. The functionality of XWS-Security and SSL is logically the same so it make sense to use the same keystore. XWS-Security operates completely separately from the transport and never knows whether HTTPS is in use or not.
Phil Goodwin
Technical Lead
XWS-Security -
Need help using XWS-Security with EJB service endpoint
I am trying to use XWS-Security along the lines of the JWSDP 1.6 examples, but with an EJB endpoint deployed in an ejb-jar file rather than a typical service endpoint deployed in a WAR.
Any information on how to do this would be appreciated. I believe I'm close to getting an example working- the details on the problem I've encountered are below.
I use WSCompile to generate stubs and ties for my WS, and XDoclet to generate the ejb-jar.xml. I deploy the ejb-jar on JBoss 4.0.2.
The problem I'm having is that the security features are handled in the Stubs and Ties generated by WSCompile, and my server-side refuses to use the WSCompile generated Tie. Previously the web service had used the WSCompile argument 'import="true"', which generated no tie, and the web service worked (this was before I tried to add security features). Whatever mechanism had been used to direct messages to my EJB then is still being used now (JNDI, I believe, facilitated by the ejb-jar.xml and webservices.xml files), and bypassing the Tie class that I now generate using 'server="true"'.
There must be some way I can reconfigure my webservice so that the WSCompile generated Tie is used, but I can't find any help on the topic.
Can anyone tell me how to make sure my webservice will use the Tie class on the server side? Is it even possible when using EJBs instead of servlets?Burn your CD using iTunes. Then rip the music off of the CD using any "ripping" program. Just make sure the program you use has the "save as .wav" option available. Im not familiar with MusicMatch but I'm sure you would be able to use it.
Maybe you are looking for
-
Export choice for non-compressed clip backup
I'm ripping some of my movie DVDs with songs in them and editing out all the content other than the songs and creating a new "song-only DVD". If I want to dispose of the original movie DV Streams (to save storage space) and just keep the song clips f
-
Remove RFFOEDI1 and RFFOAVIS program in F110
Dear Expert, As in FBZP, i just maintain RFFOUS_C in Pmnt methods in country > Country X > Pmnt method X > Payment medium, how come there was another 2 program RFFOEDI1 and RFFOAVIS which maintain in? I would like to ask how to remove these 2 program
-
What else causes my MBP to log out on its own?
Using 10.9.2 on a MacBook Pro, the MBP's begun logging itself out when unattended. I return after a while to find the login screen. Any processes I'd left running or scheduled (e.g., Audio Hijack Pro to record from Firefox) either never started or we
-
CSS: background is missing on live site
I've just relaunched a new version of www.modbury-heritage.co.uk and the background image is missing in my masthead in IE and FF. However when I preview in either browser locally, it shows up fine! Please could someone cast their eye over the site an
-
Flatbed white and black copy very faint but color copy is ok.
Flatbed of HP officejet pro 8600 black and white copy very faint but color copy is good. I am also able to print from my desktop and other devices fine. I have all Hp inks and they are full.