| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WSDL with security policies in MB 7 |
« View previous topic :: View next topic » |
| Author |
Message
|
| MB_Naveen_Kumar |
 Posted: Mon Apr 05, 2010 10:20 pm Post subject: WSDL with security policies in MB 7 |
 |
|
Novice
Joined: 25 Mar 2010
Posts: 16
|
Hi ,
I am trying to create a WSDL with security policies implimented in it. also i should be able to get WSSE headers and username tokens in the SOAP request message when the WSDL is loaded into a client like soap UI.
How can i produce such a wsdl ? is it posible from Broker toolkit ?
the basic need is message authentication based on user name tokens in wsse headers ..
pls provide guidance and links for research.. if anyone have such a sample wsdl or have a link to find one pls share. |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Mon Apr 05, 2010 10:52 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi MB_Naveen_Kumar,
The WS-Security headers are part of the SOAP standards and apply at the message level, so probably they are not the responsibility of the WSDL, but that of the 'message' linked to the WSDL.
In SoapUI I know that the WSSE headers get added when you select the appropriate check boxes, maybe you should try an export of the WSDL from there.
I'm sure the broker understands WS standards, but not sure if and how the Broker toolkit would make the WSDL with the headers for you...you could try to do an export from a SOAPNode flow once you've made the correct configuration for security on it...it might work.
In terms of documentation, the w3 covers the security headers well, that is what you should first read to define your enterprise WS-Security standard, and not depend on soapUI or Broker.
Regards. |
|
| Back to top |
|
|
| Herbert |
| Posted: Tue Apr 06, 2010 2:45 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| elvis_gn wrote: |
| The WS-Security headers are part of the SOAP standards and apply at the message level, so probably they are not the responsibility of the WSDL, but that of the 'message' linked to the WSDL. |
Indeed, I have done a POC about Web Services with WS-Security in WMB , in our solution we did not add any information about the WS-Security in the WSDL. It's done at a other level in WMB (Policy sets)
"Technology samples" -> "Web Services" -> "Address Book Sample with optional WS-Security" -> "Extend the sample" is a good starting point to see how WS-Security is implemented in WMB
hgj |
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Apr 06, 2010 12:32 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| elvis_gn wrote: |
Hi MB_Naveen_Kumar,
...so probably they are not the responsibility of the WSDL... |
They absolutely can (and some would say *should* be part of the WSDL since this is the technical interface specification for the message exchange. Otherwise these details would need to be provided by some other 'out of bad' means.
That said, as per Herbert's reply Message Broker does appear to implement this via 'Policy Sets'.
Fraser. |
|
| Back to top |
|
|
| MB_Naveen_Kumar |
| Posted: Tue Apr 06, 2010 8:50 pm Post subject: |
|
|
Novice
Joined: 25 Mar 2010
Posts: 16
|
| Quote: |
goffinf wrote: They absolutely can (and some would say *should* be part of the WSDL since this is the technical interface specification for the message exchange. Otherwise these details would need to be provided by some other 'out of bad' means.
That said, as per Herbert's reply Message Broker does appear to implement this via 'Policy Sets |
[/list]
when u say "they absolutely can", can you tell how they can ? , is it as simple as creating a normal wsdl and manually hard code security headers or policies ? this is one of the ideas that struck to me , correct me if needed here ..
and coming to herbert's reply , doing message authentication based on policy sets is not first priority but to create wsdl which creates this request message so that common man can just populate fields to this wsse headers and send his request .. would there be any impact on wsdl if we implement policy sets .. ? its kind of confusing me , because i first implemented a webservice to use HTTPS login using Public key infrastucture(PKI) and now for mesage authenticaton first i am trying to convert the normal wsdl to generate the wsse headers so that i can populate the username tokens or use x509 certificates and send it to broker in these headers .. pls help |
|
| Back to top |
|
|
| Herbert |
| Posted: Wed Apr 07, 2010 1:40 am Post subject: |
|
|
Centurion
Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands
|
| Quote: |
| and coming to herbert's reply , doing message authentication based on policy sets is not first priority but to create wsdl which creates this request message so that common man can just populate fields to this wsse headers and send his request .. would there be any impact on wsdl if we implement policy sets .. ? its kind of confusing me , because i first implemented a webservice to use HTTPS login using Public key infrastucture(PKI) and now for mesage authenticaton first i am trying to convert the normal wsdl to generate the wsse headers so that i can populate the username tokens or use x509 certificates and send it to broker in these headers .. pls help |
For sure I'm not a WSDL expert, I did only look at the things needed for the POC.
As I see it, WSDL is not bounded/limited to SOAP, WSDL with REST must also be possible. And, as elvis_gn said, WS-Security is part of SOAP, so it make sence that it is not specifield at WSDL level but at SOAP level.
If you want to give the WS-Security fields a place, then a possible solution is to compose a ws-security.xsd, something like below, that includes those parts of WS-Security you want. Then you include this ws-security.xsd in the SOAP header in your own soap.xsd, and that soap.xsd can be used in the WSDL.
We have done it like this and give it to our clients. This way our clients did know how to compose a SOAP message.
| Code: |
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Security" type="wsse:SecurityType">
<xs:annotation>
<xs:documentation>Security header, subset van WS-Security</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="SecurityType">
<xs:annotation>
<xs:documentation>Security header, subset van WS-Security</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="UsernameToken">
<xs:complexType>
<xs:sequence>
<xs:element name="Username">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="9"/>
<xs:maxLength value="12"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Password">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="25"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema> |
|
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Apr 07, 2010 2:47 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi,
| Herbert wrote: |
As I see it, WSDL is not bounded/limited to SOAP, WSDL with REST must also be possible. And, as elvis_gn said, WS-Security is part of SOAP, so it make sence that it is not specifield at WSDL level but at SOAP level.
If you want to give the WS-Security fields a place, then a possible solution is to compose a ws-security.xsd, something like below, that includes those parts of WS-Security you want. Then you include this ws-security.xsd in the SOAP header in your own soap.xsd, and that soap.xsd can be used in the WSDL. |
Exactly what I was talking about...
You could put the whole text from the soap.xsd into the WSDL, but that's not a good practice...the XSD should only be linked from the WSDL.
Coming to the policy sets, yes that is where you do the configuration, but does the 'Generate WSDL' option in broker, lookup the policy sets to create a WSDL and related XSDs with the security headers ? I doubt it....For this, I suggested you understand the WS standard security headers and first create your XSD standard in SoapUI, for example.
Regards. |
|
| Back to top |
|
|
| MB_Naveen_Kumar |
| Posted: Wed Apr 07, 2010 3:14 am Post subject: |
|
|
Novice
Joined: 25 Mar 2010
Posts: 16
|
| Thank you herbert .. i will create a wsdl using the cues provided by all of you .. |
|
| Back to top |
|
|
| goffinf |
| Posted: Wed Apr 14, 2010 2:59 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Herbert wrote: |
| As I see it, WSDL is not bounded/limited to SOAP, WSDL with REST must also be possible. And, as elvis_gn said, WS-Security is part of SOAP, so it make sence that it is not specifield at WSDL level but at SOAP level. |
Sure, but WSDL is a vocabulary that is deliberately designed to allow abstract message definitions to bind to concrete protocols (i.e. everything up to portType = abstract, whereas binding and service provide the concrete serialisation and network details (assuming WSDL 1.1).
SOAP 1.x is an example of a binding protocol. So if you *are* binding are to SOAP then it seems to me to be reasonable to include other parts of the composable set of standards that work with it such as WS-Security, WS-Addressing et al. Personally I prefer to maintain the technical contract as far as posssible in the WSDL. As you go on to say, providing this to your consumers gives them a much better clue about how to call your service succesfully, and thats the real point of the exercise right ? Without it, how would a client know what your service interface expects !
| Herbert wrote: |
| If you want to give the WS-Security fields a place, then a possible solution is to compose a ws-security.xsd, something like below, that includes those parts of WS-Security you want. Then you include this ws-security.xsd in the SOAP header in your own soap.xsd, and that soap.xsd can be used in the WSDL. |
Why not just import the *offical* ws-sec XSD into your WSDL (remove bits that you don't support if you want (i.e. just UsernameToken if thats all you allow, nonce or no nonce etc, etc ..), and add the appropriate <soap:header .... element(s) into the <binding><input> and/or <output> part of your WSDL. If you want to minimise the number of files to make available to service consumers then by all means embed the ws-sec schema inside the WSDL (not all tools handle imports well).
| Herbert wrote: |
| We have done it like this and give it to our clients. This way our clients did know how to compose a SOAP message. |
Agreed, and moreover, it can allow them to get a head start from tooling that can consume the WSDL and create at least a starting point client-side application for consuming your service.
| Code: |
<xs:element name="UsernameToken">
<xs:complexType>
<xs:sequence>
<xs:element name="Username">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:minLength value="9"/>
<xs:maxLength value="12"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
|
Interesting constraints on the size of your Username element !
HTHs
Fraser.[/quote] |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Apr 14, 2010 8:02 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi goffinf,
| goffinf wrote: |
| SOAP 1.x is an example of a binding protocol. So if you *are* binding are to SOAP then it seems to me to be reasonable to include other parts of the composable set of standards that work with it such as WS-Security, WS-Addressing et al. Personally I prefer to maintain the technical contract as far as posssible in the WSDL. As you go on to say, providing this to your consumers gives them a much better clue about how to call your service succesfully, and thats the real point of the exercise right ? Without it, how would a client know what your service interface expects ! |
To know what the service interface expects you need to request WSDL to generate the input interface structure...which is generated using the linked XSD...this is not really a problem.
| goffinf wrote: |
| Why not just import the *offical* ws-sec XSD into your WSDL (remove bits that you don't support if you want (i.e. just UsernameToken if thats all you allow, nonce or no nonce etc, etc ..), and add the appropriate <soap:header .... element(s) into the <binding><input> and/or <output> part of your WSDL. If you want to minimise the number of files to make available to service consumers then by all means embed the ws-sec schema inside the WSDL (not all tools handle imports well). |
Say you have 100 WSDL based services in your organisation. One bright morning they decide to change the Security standards and the GBO objects, say for compliance....Will you want to change 100 WSDLs or change 1 security.xsd and 1 gbo.xsd ?
Regards. |
|
| Back to top |
|
|
| goffinf |
| Posted: Thu Apr 15, 2010 10:24 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Hi Elvis,
| elvis_gn wrote: |
| To know what the service interface expects you need to request WSDL to generate the input interface structure...which is generated using the linked XSD...this is not really a problem. |
I think we're agreeing here. I'm advocating providing the WSDL as a specification of the technical interface. This might be in multiple parts, for example, the message parts might be declared in one or more XML schema files which are imported, and the WSDL itself might be separated in multiple parts and imported as is common practice to allow for modularity and reuse. I think you are saying the same ?
The real point was that the more complete the WSDL (including all of its external imports/includes) the better chance a caller has of making a successful call. I'm not a great fan of informal 'out of band' methods of passing interface specs (all to often I've been faced with ' ... oh we don't have a spec, here's an XML message which is roughly what you need ... sighs in frustration'.
| elvis_gn wrote: |
| Say you have 100 WSDL based services in your organisation. One bright morning they decide to change the Security standards and the GBO objects, say for compliance....Will you want to change 100 WSDLs or change 1 security.xsd and 1 gbo.xsd ? |
Again I think we're agreeing. I did say *import*, as in an XML schema import to an external uri/url. Admittedly I did add a comment about embedding the whole lot in the WSDL and I would agree that in some cases that is bad practice because of the reason you mention.
That said, support for XSD and WSDL imports in tooling is not 100% and lots of folk still use this approach for getting started with consumer and provider implementations.
There are other tools around that can automate the process of producing a 'flattened' schema that embeds all related parts from each include/import that can prove useful in such cases.
Regards
Fraser. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
