Marshalling RequestSecurityToken
Gina Choi
Per your direction, I check out unit tests for openws and they were very
helpful. Now, I have RequestSecurityToken object and need to marshal it. When
I marshal AuthnRequest I used following code, but if I pass
RequestSecurityToken to the following code, it returns null(marshaller ==
null).
Marshaller marshaller = org.opensaml.Configuration
.getMarshallerFactory().getMarshaller(authnRequest);
Do we marshal RequestSecurityToken in different way?
Thanks.
Gina Choi
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
Brent Putman
On 3/15/12 4:03 PM, Gina Choi wrote:
> Hi Brent,
>
> Per your direction, I check out unit tests for openws and they were very
> helpful. Now, I have RequestSecurityToken object and need to marshal it. When
> I marshal AuthnRequest I used following code, but if I pass
> RequestSecurityToken to the following code, it returns null(marshaller ==
> null).
>
>
> Marshaller marshaller = org.opensaml.Configuration
>
> .getMarshallerFactory().getMarshaller(authnRequest);
>
>
> Do we marshal RequestSecurityToken in different way?
>
No, it's actually the same for any of the XMLObjects. I looked into it,
and it appears we have a small bug. Somehow we never registered the
WS-Trust and WS-Policy schema configs into the DefaultBootstrap process,
so those providers aren't being configured when you run
DefaultBootstrap.bootstrap().
I will fix this for the next release, but in the meantime you can just
manually load them. Wherever you are calling DefaultBootstrap, just add
some calls to load the configs explicitly, after you call bootstrap(),
similar to this:
DefaultBootstrap.bootstrap();
XMLConfigurator configurator = new XMLConfigurator();
InputStream isTrust =
Configuration.class.getResourceAsStream("/wstrust-config.xml");
configurator.load(isTrust);
InputStream isPolicy =
Configuration.class.getResourceAsStream("/wspolicy-config.xml");
configurator.load(isPolicy);
That begs the question however of how you were able build the RST object
in the first place, since you couldn't have been getting a builder for
it. You must be just new()-ing the -Impl class directly, which we don't
advise or support. You should really be getting the new instance via a
Builder, otherwise your code might break if we change something up in
the future with how the library works.
--Brent
Gina Choi
Thanks for providing me temp fix for marshaling issue. I really appreciate
your quick fix. It worked. I built following RequestSecurityToken using
openws. I know that I need to add some more content and try to figure it out.
<?xml version="1.0" encoding="UTF-8"?>
<wst:RequestSecurityToken
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wsp:AppliesTo
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Address>https://yourcompany.com</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer</wst:Key
Type>
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:
RequestType>
<wst:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</wst:TokenType>
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity
-utility-1.0.xsd">
<wsu:Created>2012-03-16T14:06:01.067Z</wsu:Created>
</wsu:Timestamp>
</wst:RequestSecurityToken>
I used following code to build RequestSecurityToken(Please let me know if I
am in wrong direction). In same way, I was able to find corresponding
builders for each element inside RequestSecurityToken.
//Build RequestSecurityToken
RequestSecurityTokenBuilder rstBuilder = new
RequestSecurityTokenBuilder();
RequestSecurityToken rst= rstBuilder.buildObject();
//Build AppliesTo and add it to RST
AppliesToBuilder appliesToBuilder = new AppliesToBuilder();
AppliesTo appliesTo = appliesToBuilder.buildObject();
rst.getUnknownXMLObjects().add(appliesTo);
I guess next step is that I need to put this RST inside SOAP envelope, but I
haven't deal with SOAP much before. Any ideas?
Thanks.
Gina
------------------------------
Message: 2
Date: Thu, 15 Mar 2012 08:03:59 -1200
From: Gina Choi <gc...@sdl.com>
Subject: Marshalling RequestSecurityToken
To: <d...@shibboleth.net>, <put...@georgetown.edu>
Message-ID:
<199C35CD64E44140A34...@wakemail0303.global.sdl.corp>
Content-Type: text/plain; charset="us-ascii"
Hi Brent,
Per your direction, I check out unit tests for openws and they were very
helpful. Now, I have RequestSecurityToken object and need to marshal it. When
I marshal AuthnRequest I used following code, but if I pass
RequestSecurityToken to the following code, it returns null(marshaller ==
null).
Marshaller marshaller = org.opensaml.Configuration
.getMarshallerFactory().getMarshaller(authnRequest);
Do we marshal RequestSecurityToken in different way?
Thanks.
Gina Choi
------------------------------
Message: 3
Date: Thu, 15 Mar 2012 17:52:56 -0400
From: Brent Putman <put...@georgetown.edu>
Subject: Re: Marshalling RequestSecurityToken
To: d...@shibboleth.net
Message-ID: <4F6264B8...@georgetown.edu>
Content-Type: text/plain; charset=ISO-8859-1
--Brent
------------------------------
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
End of dev Digest, Vol 9, Issue 12
**********************************
Brent Putman
On 3/16/12 11:00 AM, Gina Choi wrote:
> I used following code to build RequestSecurityToken(Please let me know if I
> am in wrong direction). In same way, I was able to find corresponding
> builders for each element inside RequestSecurityToken.
>
> //Build RequestSecurityToken
> RequestSecurityTokenBuilder rstBuilder = new
> RequestSecurityTokenBuilder();
Well, that's not really correct either. It "works", but is not how the
library is intended to be used. You should always obtain builders,
marshallers and unmarshallers from the factories that are exposed by the
Configuration singleton. See this page in the wiki for the builder
examples:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreateFromScratch
>
>
> I guess next step is that I need to put this RST inside SOAP envelope, but I
> haven't deal with SOAP much before. Any ideas?
The SOAP support in OpenSAML is very low-level. You just build an
Envelope object, then create a Body and add it to the Envelope; and
inside the Body you put your payload (e.g. the RST). If you need
headers (as you almost certainly will with any of this WS-* stuff), then
you create a Header and add it to the Envelope, and then add the various
header objects as children of the Header. This is illustrated by the
SOAP client example in the wiki that I previously sent:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaSOAPClientExample
Gina Choi
>Actually, I forgot to mention that we do have a rudimentary SOAP client,
>based on Apache HttpClient. There is a basic example of its use here in
>the wiki:
>https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaSOAP
ClientExample
>It basically just takes a complete Envelope XMLObject, sends it and
>provides the the Envelope object that is the received back as the
>response. So it doesn't do anything fancy with Envelope handling, like
>generate or process headers, that's something that needs to be done by
>the caller.
I went URL that you mentioned above and following is part the of
HttpSOAPClient example you implemented previously. I try to send
RequestSecurityToken to STS(ADFS2.0) over soap client. Do I need
clientBuilder.setHttpsProtocolSocketFactory(
new TLSProtocolSocketFactory(keyManager, new
DelegateToApplicationX509TrustManager())) ?
What is "client.key" and "client.crt" about?
String clientTLSPrivateKeyResourceName = "client.key";
String clientTLSCertificateResourceName = "client.crt";
Envelope envelope = buildSOAP11Envelope(request);
// SOAP context used by the SOAP client
BasicSOAPMessageContext soapContext = new BasicSOAPMessageContext();
soapContext.setOutboundMessage(envelope);
// This part is for client TLS support
X509Credential clientTLSCred =
getClientTLSCred(clientTLSPrivateKeyResourceName,
clientTLSCertificateResourceName);
StaticClientKeyManager keyManager =
new StaticClientKeyManager(clientTLSCred.getPrivateKey(),
clientTLSCred.getEntityCertificate());
// Build the SOAP client
HttpClientBuilder clientBuilder = new HttpClientBuilder();
clientBuilder.setHttpsProtocolSocketFactory(
new TLSProtocolSocketFactory(keyManager, new
DelegateToApplicationX509TrustManager()));
HttpSOAPClient soapClient = new
HttpSOAPClient(clientBuilder.buildClient(), parserPool);
// Send the message
try {
soapClient.send(serverEndpoint, soapContext);
} catch (SOAPException e) {
e.printStackTrace();
} catch (SecurityException e) {
e.printStackTrace();
}
Thanks.
Gina
------------------------------
Date: Wed, 14 Mar 2012 16:28:29 -0400
From: Brent Putman <put...@georgetown.edu>
Subject: Re: Does openws1.4.2 support RequestSecurityToken?
To: d...@shibboleth.net
Message-ID: <4F60FF6D...@georgetown.edu>
Content-Type: text/plain; charset=ISO-8859-1
On 3/14/12 1:35 PM, Gina Choi wrote:
> I built AuthnRequest using OpenSAML libraries recently. Is this same
concept?
Yes, it's exactly the same concept. You use builders to create new
instances of the desired XMLObjects, mutate them as you like, build up a
tree that represents the XML you need and then marshall the XMLObject
tree to a DOM.
> Can I find some sample code from anywhere? By the way, my STS is ADFS2.0.
I don't think we have any sample code for the WS-Trust and other WS-*
schemas per se. Possibly there is something in the openws unit tests.
But as I said above, it's exactly the same concept and procedure to
build and marshall a WS-Trust RST XML structure as a SAML 2 AuthnRequest
one.
> I guess that I need to implement SOAO call by myself.
Actually, I forgot to mention that we do have a rudimentary SOAP client,
based on Apache HttpClient. There is a basic example of its use here in
the wiki:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaSOAPC
lientExample
It basically just takes a complete Envelope XMLObject, sends it and
provides the the Envelope object that is the received back as the
response. So it doesn't do anything fancy with Envelope handling, like
generate or process headers, that's something that needs to be done by
the caller.
------------------------------
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
End of dev Digest, Vol 9, Issue 11
**********************************
Brent Putman
On 3/16/12 7:18 PM, Gina Choi wrote:
>
> I went URL that you mentioned above and following is part the of
> HttpSOAPClient example you implemented previously. I try to send
> RequestSecurityToken to STS(ADFS2.0) over soap client. Do I need
> clientBuilder.setHttpsProtocolSocketFactory(
> new TLSProtocolSocketFactory(keyManager, new
> DelegateToApplicationX509TrustManager())) ?
>
> What is "client.key" and "client.crt" about?
>
I think it's mentioned in the notes at the top of the page, but those
things are about doing client TLS to the HTTP SOAP endpoint. If you
don't want or need to do client TLS, then you can omit those. The
client.key and client crt are the filenames of the private key and X.509
certificate respectively, that the client would use in client TLS.
Whether you need client TLS or not, I can't say. You'd need to consult
profile specs or documentation for the ADFS STS and its requirements.
I'd venture a guess that they probably don't want client TLS, providing
authN of the sender on the communications channel. Instead they probably
want to authenticate the sender of the RST with some SOAP message
security mechanims, e.g. via a WS-Security token, perhaps even a
key-bearing token along with an associated WS-Security signature over
the SOAP message. But I haven't worked with ADFS, so not sure.
The client TLS example in the wiki is there because Shibboleth does
support (and indeed usually prefers) to secure its backchannel SOAP
communication for things like AttributeQuery via client TLS, as opposed
to SOAP message security mechanisms.
Gina Choi
>Well, that's not really correct either. It "works", but is not how the
>library is intended to be used. You should always obtain builders,
>marshallers and unmarshallers from the factories that are exposed by the
>Configuration singleton. See this page in the wiki for the builder
>examples:
>https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreat
eFromScratch
Does the following code fit to your original design?
// Get the builder factory
XMLObjectBuilderFactory builderFactory =
Configuration.getBuilderFactory();
//Build RequestSecurityToken
RequestSecurityTokenBuilder rstBuilder =
(RequestSecurityTokenBuilder)
builderFactory.getBuilder(RequestSecurityToken.ELEMENT_NAME);
RequestSecurityToken rst= rstBuilder.buildObject();
//Build AppliesTo and add it to RST
AppliesToBuilder appliesToBuilder = (AppliesToBuilder)
builderFactory.getBuilder(AppliesTo.ELEMENT_NAME);
AppliesTo appliesTo = appliesToBuilder.buildObject();
rst.getUnknownXMLObjects().add(appliesTo);
>The SOAP support in OpenSAML is very low-level. You just build an
>Envelope object, then create a Body and add it to the Envelope; and
>inside the Body you put your payload (e.g. the RST). If you need
>headers (as you almost certainly will with any of this WS-* stuff), then
>you create a Header and add it to the Envelope, and then add the various
>header objects as children of the Header. This is illustrated by the
>SOAP client example in the wiki that I previously sent:
>https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaSOAP
ClientExample
I need to build Header similar to the following example. User name and
password is used to get RequestSecurityToken, but I am looking for solutions
to get RequestSecurityTokenrResponse in exchange of existing assertion token
that I have. Suppose, that I want to build following Header, which package of
the OpenSAML should I use to build Header elements?
Header header = envelope.getHeader();
<s:Header>
<a:Action
s:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Iss
ue
</a:Action>
<a:To
s:mustUnderstand="1">https://yourcompany.com/adfs/services/trust/13/UsernameM
ixed</a:To>
<o:Security s:mustUnderstand="1" mlns:o="...">
<o:UsernameToken u:Id="uuid-6a13a244-dac6-42c1-84c5-cbb345b0c4c4-1">
<o:Username>Leandro Boffi</o:Username>
<o:Password Type="...">P@ssw0rd!</o:Password>
</o:UsernameToken>
</o:Security>
</s:Header>
Thanks.
Gina
------------------------------
Message: 2
Date: Fri, 16 Mar 2012 13:05:50 -0400
From: Brent Putman <put...@georgetown.edu>
Subject: Re: Marshalling RequestSecurityToken
To: d...@shibboleth.net
Message-ID: <4F6372EE...@georgetown.edu>
Content-Type: text/plain; charset=ISO-8859-1
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreate
FromScratch
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaSOAPC
lientExample
--
Brent Putman
On 3/19/12 12:22 PM, Gina Choi wrote:
>
> Does the following code fit to your original design?
>
Yes, that looks correct.
>
> I need to build Header similar to the following example. User name and
> password is used to get RequestSecurityToken, but I am looking for solutions
> to get RequestSecurityTokenrResponse in exchange of existing assertion token
> that I have. Suppose, that I want to build following Header, which package of
> the OpenSAML should I use to build Header elements?
>
>
> Header header = envelope.getHeader();
>
>
>
> <s:Header>
> <a:Action
> s:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Iss
> ue
> </a:Action>
> <a:To
> s:mustUnderstand="1">https://yourcompany.com/adfs/services/trust/13/UsernameM
> ixed</a:To>
> <o:Security s:mustUnderstand="1" mlns:o="...">
> <o:UsernameToken u:Id="uuid-6a13a244-dac6-42c1-84c5-cbb345b0c4c4-1">
> <o:Username>Leandro Boffi</o:Username>
> <o:Password Type="...">P@ssw0rd!</o:Password>
> </o:UsernameToken>
> </o:Security>
> </s:Header>
>
It's the same as all the other stuff. You build a Header, you set it on
the Envelope. You build a WS-Addressing Action, then add it as a child
of the Header, etc.
We do have support for all of those elements above, from the
WS-Addressing and WS-Security specs. All are in openws. So you
shouldn't have a problem generating the above XML with OpenSAML.
Gina Choi
Message: 2
Date: Mon, 19 Mar 2012 04:22:55 -1200
From: Gina Choi <gc...@sdl.com>
Subject: Re: Marshalling RequestSecurityToken
To: <d...@shibboleth.net>, <put...@georgetown.edu>
Message-ID:
<199C35CD64E44140A34...@wakemail0303.global.sdl.corp>
Content-Type: text/plain; charset="us-ascii"
Hi Brent,
>Well, that's not really correct either. It "works", but is not how the
>library is intended to be used. You should always obtain builders,
>marshallers and unmarshallers from the factories that are exposed by the
>Configuration singleton. See this page in the wiki for the builder
>examples:
>https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreat
>eFromScratch
Last time you mentioned marshalling RequestSecurityToken, but I wasn't quite
understand at that time. Marshalling makes sense when we send SAMLRequest to
STS since we are going to invoke following code.
response.sendRedirect(actionURL + "?SAMLRequest="
+ encodedRequestMessage + "&RelayState=" +
relayUrl);
But when we send RequestSecurityToken to STS over SOAP, we add
RequestSecurityToken to Body. Following code is based on your wiki link. I
did marshaled RequestSecurityToken, but it's purpose was to see xml structure
of the RequestSecurityToken that I build. Just checking with you in case I
missed something.
Body body = (Body)
bf.getBuilder(Body.DEFAULT_ELEMENT_NAME).buildObject(Body.DEFAULT_ELEMENT_NAM
E);
body.getUnknownXMLObjects().add(RequestSecurityToken);
envelope.setBody(body);
// SOAP context used by the SOAP client
BasicSOAPMessageContext soapContext = new BasicSOAPMessageContext();
soapContext.setOutboundMessage(envelope);
HttpClientBuilder clientBuilder = new HttpClientBuilder();
HttpSOAPClient soapClient = new
HttpSOAPClient(clientBuilder.buildClient(), parserPool);
// Send the message
soapClient.send(serverEndpoint, soapContext);
Thanks.
Gina
Brent Putman
On 3/19/12 6:02 PM, Gina Choi wrote:
> Last time you mentioned marshalling RequestSecurityToken, but I wasn't quite
> understand at that time. Marshalling makes sense when we send SAMLRequest to
> STS since we are going to invoke following code.
>
> response.sendRedirect(actionURL + "?SAMLRequest="
> + encodedRequestMessage + "&RelayState=" +
> relayUrl);
>
>
Well, don't confuse "marshalling" with "serializing". In OpenSAML,
marshalling is defined as converting the XMLObject tree model into a DOM
model. Serializing is converting the DOM representation into a byte
sequence, i.e. for transmission of a communication channel, storage in a
file, etc.
Ultimately some code, somewhere, is going to have to do both of those
things. Whether or not you explicitly have to do either depends on how
you handle the processing of the XMLObject that you create (see below
for SOAP client info).
And the same is tree when you receive the XML, as pertains to
deserializing/parsing the XML into a DOM, and then unmarshalling an
XMLObject tree from the DOM.
> But when we send RequestSecurityToken to STS over SOAP, we add
> RequestSecurityToken to Body. Following code is based on your wiki link. I
> did marshaled RequestSecurityToken, but it's purpose was to see xml structure
> of the RequestSecurityToken that I build. Just checking with you in case I
> missed something.
>
>
>
> Body body = (Body)
> bf.getBuilder(Body.DEFAULT_ELEMENT_NAME).buildObject(Body.DEFAULT_ELEMENT_NAM
> E);
>
> body.getUnknownXMLObjects().add(RequestSecurityToken);
> envelope.setBody(body);
> // SOAP context used by the SOAP client
> BasicSOAPMessageContext soapContext = new BasicSOAPMessageContext();
>
> soapContext.setOutboundMessage(envelope);
>
> HttpClientBuilder clientBuilder = new HttpClientBuilder();
>
> HttpSOAPClient soapClient = new
> HttpSOAPClient(clientBuilder.buildClient(), parserPool);
>
> // Send the message
> soapClient.send(serverEndpoint, soapContext);
>
Yes, on first glance that looks correct.
I had to go and take a look at it b/c it's been a long time, but the
SOAP client does take care of marshalling and serializing the outbound
XMLObject, and deserializing and unmarshalling the response. So you
don't generally need to marshall the SOAP Envelope that you are sending
before you invoke the client. One exception would be if you were doing
anything with XML signatures - in that case you have to marshall first
before the actual signing operation, since the signature process
operates on the DOM level.
Gina Choi
Thanks for your response.
>Well, don't confuse "marshalling" with "serializing". In OpenSAML,
>marshalling is defined as converting the XMLObject tree model into a DOM
>model. Serializing is converting the DOM representation into a byte
>sequence, i.e. for transmission of a communication channel, storage in a
>file, etc.
>Ultimately some code, somewhere, is going to have to do both of those
>things. Whether or not you explicitly have to do either depends on how
>you handle the processing of the XMLObject that you create (see below
>for SOAP client info).
>And the same is tree when you receive the XML, as pertains to
>deserializing/parsing the XML into a DOM, and then unmarshalling an
>XMLObject tree from the DOM.
I looked at AuthnRequest that I am sending to ADFS over HTTP POST, I do have
code that marshalling and serializing.
>Yes, on first glance that looks correct.
>I had to go and take a look at it b/c it's been a long time, but the
>SOAP client does take care of marshalling and serializing the outbound
>XMLObject, and deserializing and unmarshalling the response. So you
>don't generally need to marshall the SOAP Envelope that you are sending
>before you invoke the client. One exception would be if you were doing
>anything with XML signatures - in that case you have to marshall first
>before the actual signing operation, since the signature process
>operates on the DOM level.
I didn't know that SOAP client takes care of marshalling and serializing
role. Now I am clear. Thank you.
Gina
-----Original Message-----
From: dev-b...@shibboleth.net [mailto:dev-b...@shibboleth.net] On
Behalf Of dev-r...@shibboleth.net
Sent: Wednesday, March 21, 2012 8:00 AM
To: d...@shibboleth.net
Subject: dev Digest, Vol 9, Issue 17
Send dev mailing list submissions to
d...@shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/dev
or, via email, send a message with subject or body 'help' to
dev-r...@shibboleth.net
You can reach the person managing the list at
dev-...@shibboleth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."
Today's Topics:
1. Re: Marshalling RequestSecurityToken (Brent Putman)
2. Re: Apache 2.4 (Cantor, Scott)
3. Re: Apache 2.4 (Michael R. Gettes)
4. Requesting new Assertion to STS (Gina Choi)
5. Re: Requesting new Assertion to STS (Cantor, Scott)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Mar 2012 11:53:35 -0400
From: Brent Putman <put...@georgetown.edu>
Subject: Re: Marshalling RequestSecurityToken
To: d...@shibboleth.net
Message-ID: <4F68A7FF...@georgetown.edu>
Content-Type: text/plain; charset=ISO-8859-1
Gina Choi
I try to set mustUnderstand attribute in Security element of the soap header.
Somehow, I couldn't find related API from open-ws library. Perhaps, this
attribute is set in different way?
<S11:Envelope>
<S11:Header>
<wsse:Security S11:actor="..." S11:mustUnderstand="...">
</wsse:Security>
</S11:Header>
</S11:Envelope>
Thanks.
Gina
Gina Choi
soap12 envelope using following code. Same way, I created Header and Body for
soap12, but it doesn't seem right. When I try marshal the Envelope, I am
getting null pointer exception. Is there other way to create soap12 envelope?
XMLObjectBuilderFactory builderFactory = Configuration
.getBuilderFactory();
EnvelopeBuilder envelopeBuilder = (EnvelopeBuilder)
builderFactory.getBuilder(Envelope.DEFAULT_ELEMENT_NAME);
org.opensaml.ws.soap.soap11.Envelope envelope =
envelopeBuilder.buildObject(new QName(SOAPConstants.SOAP12_NS,
Envelope.DEFAULT_ELEMENT_LOCAL_NAME, SOAPConstants.SOAP12_PREFIX));