|
»
WSIT - How to sign without encryption?
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
Re: WSIT - How to sign without encryption?
by Wim Vandenhaute
::
Rate this Message:
You'll have to set the protectionlevel of the endpoint contract to
ProtectionLevel.Sign so client.Endpoint.Contract.ProtectionLevel = ProtectionLevel.Sign On 23 Dec 2008, at 15:48, metro@... wrote: > I have a requirement for a webservice client to do soap message body > signing (using RSA-SHA) but no header encryption. And can't figure > out how to write the appropriate WS-Policy for that. Signing the > body is easy with the combination of an AsymmetricBinding and a > signedPart/Body declaration. However, the generated messages seem to > always have their headers encrypted (same when using > SymmetricBinding). How can tell Metro to leave the headers > unencrypted? I.e. the final message should look roughly like this: > > <soapenv:Envelope ...> > <soapenv:Header> > <wsse:Security ...> > <wsse:UsernameToken...> > ... > </wsse:UsernameToken> > <wsse:BinarySecurityToken...>XXXXXXXXXXXX</ > wsse:BinarySecurityToken> > <ds:Signature ...> > .... > </ds:Signature> > </wsse:Security> > </soapenv:Header> > <soapenv:Body ...> > ... > </soapenv:Body> > </soapenv:Envelope> > > I have read through some of the specs and I can't figure out how to > configure this. On the other hand the service I need to talk to has > this requirement and the provider claims that it is WS-Security > compliant. > > Thanks > > Manuel > [Message sent by forum member 'malm' (malm)] > > http://forums.java.net/jive/thread.jspa?messageID=323101 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: WSIT - How to sign without encryption?
by Wim Vandenhaute
::
Rate this Message:
Hmm my apologies, I seem to have mistaken this for another mailing list.
The suggestion I gave is indeed specifically for WCF clients. Not sure on how to accomplish this using metro tho. Apologies for causing confusion ;-) On 23 Dec 2008, at 16:29, metro@... wrote: >> You'll have to set the protectionlevel of the >> endpoint contract to >> ProtectionLevel.Sign >> >> so client.Endpoint.Contract.ProtectionLevel = >> ProtectionLevel.Sign >> > Thanks for the suggestion but I am confused now - how do I do that > in a WS-Policy? I searched the WS-Policy specification for the word > ProtectionLevel and I couldn't find it. Further digging seems to > indicate that "Contract.ProtectionLevel" is a WCF concept. How do I > translate this into the Java world? My apologies if I missed > something obvious here. > [Message sent by forum member 'malm' (malm)] > > http://forums.java.net/jive/thread.jspa?messageID=323110 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: WSIT - How to sign without encryption?
by Glen Mazza
::
Rate this Message:
Manuel, like I said I have not done this before, but the client-side configuration is actually *summed* (combined) between the client-side config files *and* the local WSDL file hardcoded into the *Service.java jax-ws generated class (in my blog entry[1], DoubleItService.java). It would be good for you to open that *Service.java generated file to see the hardcoded WSDL reference, so you'll know what I'm referring to.
Further, if you look at the bottom two of the three ws:policy sections in the service-side WSDL[1] (which, again, is also read by the client via that *Service.java class), you'll see that there are operation-level policies (not the binding-level policy which is the *first* of the three--look in the wsdl:binding section of the service-side WSDL to see how the three are referenced at different locations) Those latter two specify what needs to be encrypted and/or signed both on input and output. What does this mean? If you remove the encrypted element from the output policy from your *local* WSDL, the client will probably just sign things without encrypting them. (Alternatively, you can remove all policies from your local WSDL and instead add them to your client-side config files. Just be careful--one of the weaknesses of my tutorial is that the client-side and service-side are using the same *Service.java class, and as a result share the same WSDL by default.) Also, you will probably need to modify the input policy, to take into account that the client possibly may not be receiving encrypted and/or signed data from the web service provider. If you do not modify it, the client will complain if what it gets back from the web service provider is not encrypted and/or signed in adherence to the input policy. HTH, Glen [1] http://www.jroller.com/gmazza/entry/implementing_ws_security_with_pki#MetroPKI3
|
|
|
Re: WSIT - How to sign without encryption?
by Glen Mazza
::
Rate this Message:
First of all, I'm assuming of course that you're using SSL if you don't want the username/password token encrypted--furthermore, your web service provider will *not* accept non-SSL requests if it indeed wants the username/password to be unencrypted. Otherwise, there's something wrong with your web service provider and you probably shouldn't be interacting with it until that problem is resolved. The client of my username token example[1], in Step #6, is *not* encrypting the username token--you can see "alice" and "clarinet" in the soap:header. So this at least can be done--I think the problem occurs when you either (a) specify Asymmetric or symmetric binding and/or (b) add in the two operation-level Policy statements used in X.509 but not the username token profile. I would forget about the signatures for a moment and try to isolate what--either (a) or (b)--causes the username token to become encrypted--the more precise you can get about what causes encryption to occur, that might help a bit in troubleshooting. Note there's a chance Asymmetric and Symmetric-binding *always* encrypts the SOAP headers because that is Message-Level security (instead of the "normal" transport-level security provided by SSL.) Message-level security is designed to allow you to remove the need for using SSL, hence there is a good chance that username tokens would always be encrypted as a safety measure. (Even if not mandated by the spec, Metro may very well have such safety guards to protect against less skilled developers accidentally sending username/passwords out unencrypted, because message-level security implies that you may not be using SSL.) Besides asymmetric and symmetric, there is a third option, TransportBinding[2] I believe that just requires SSL, that might not encrypt your username tokens as a result. But can you still do signatures with that third option? Perhaps, but I don't know the syntax. If you're really about-to-join-the-circus desperate, you can try CXF, it is more primitive in its configuration but can be more flexible when you're trying to do weirdo stuff like here. It may not be that much work because thankfully you're just doing a SOAP client and not a web service provider. In Step #5, Substep #1 of here[3] you'll have an action of "UsernameToken Signature" and you'll want to keep the encryptionParts field blank (username configuration info is here[4]). Will it work? I have no idea. Caution though--if you get spurned by a second web service stack you might start bouncing off the walls, so try to protect your sanity if you go this route. Glen [1] http://www.jroller.com/gmazza/entry/implementing_ws_security_using_usernametokens [2] http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826558 [3] http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the [4] http://www.jroller.com/gmazza/entry/using_cxf_and_wss4j_to |
|
|
Re: WSIT - How to sign body without header encryption?
by Jiandong Guo
::
Rate this Message:
Can you try the following policy with TransportBinding:
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:TransportToken> <wsp:Policy> <sp:HttpsToken RequireClientCertificate="false"/> </wsp:Policy> </sp:TransportToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> </wsp:Policy> </sp:TransportBinding> <sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssUsernameToken10/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SignedSupportingTokens> <sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/AlwaysToRecipient"> <wsp:Policy> <sp:RequireDerivedKeys /> <sp:RequireThumbprintReference /> <sp:WssX509V3Token10 /> </wsp:Policy> </sp:X509Token> <sp:SignedParts> <sp:Body/> </sp:SignedParts> </wsp:Policy> </sp:EndorsingSupportingTokens> metro@... wrote: > Yes, its all over SSL. And I have no idea what the original designers of the service had in mind by using this particular setup. Using (A)symmetricBinding I get always an encrypted UsernameToken in the header. Using TransportBinding I get the clear UsernameToken in the header but no signature on the body. Tried various permutations without luck. > > I guess its time to take a Christmas break here. Changing the web services stack is not a pleasant thought especially as we already have a plethora of web services clients in the same system all based on JAX-WS. > > Wonder if any of the relevant Sun developers are reading these forums and could chime in with a quick 'Yes -can be done and here is how' or 'No - this is not a Metro 1.4 supported scenario'. > [Message sent by forum member 'malm' (malm)] > > http://forums.java.net/jive/thread.jspa?messageID=323170 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
