The question: Can CXF automatically configure WS-Security for a client based on a WS-SecurityPolicy file?
If so, is there any documentation on actually doing so? I've spent several hours looking at the CXF site and doing searches without finding an answer.
The CXF documentation says "CXF 2.2 introduced support for using WS-SecurityPolicy to configure WSS4J instead of the custom configuration documented on the WS-Security page", and also says "In CXF 2.2, if the cxf-rt-ws-policy and cxf-rt-ws-security modules are available on the classpath, the WS-SecurityPolicy stuff is automatically enabled." Finally, there's a listing of the properties that may need to be configured (keystore locations, etc). All of that I understand, but the documentation doesn't actually explain what enabling WS-SecurityPolicy does. Is it just for policy generation, or does it actually help configure clients?
The reason I'm asking is that I'm working on an application that uses CXF (JAX-WS front end) via Camel to consume a SOAP service secured with WS-Security. Because of the existing structure of our application, I've been trying to configure the client with WSS4J interceptors, but have been having a tough time actually implementing what they've described.
After a couple of days working on this, the provider mentioned that they had a WS-SecurityPolicy file they could send to me (why they didn't mention this up front is a mystery). Now that I have their policy, I'd really like to figure out a less code-driven way of configuring the security.
Having a WS-SecurityPolicy configures "most" of the security requirements for a client. You still need to specify JAX-WS properties to configure users, passwords, keys etc. I would recommend checking out the CXF source and looking at the systests/ws-security-examples tests.
Related
My client suggests that implementing a web service using WS-Policy entries inside the WSDL (using WS-SecurityPolicy standard, which seems to be the recommended way) might cause incompatibility issues with clients that call the web service. My first question is, are his concerns correct? If not, how can I prove to my client that it is safe to use WS? I could not find anything on the subject.
If compatibility issues can indeed occur, I need to find a different way to implement WS-Security requirements (like signing parts etc.) without Spring, using JavaEE APIs. I could not find anything on that subject either. The only thing I could find is about standalone web services but I do not want that, I want a web application and I need to use JavaEE APIs (so no Spring).
Any help will be appreciated.
If you have pre-existing clients already using this webservice, then yes it will break compatibility if you add WS-Security.
But if no one is using it, or it hasn't been developed yet, how will this cause compatibility issues?
Personally I see WS-Security as rather complex, particular in the area of signing and encryption, so if your client had said that some clients might not have the skills to implement the web service I would have been inclined to agree with him.
Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.
I came across an issue where a customer is able to open a SAP wsdl using net-beans as well as in .Net but not in soap UI.
When i checked the wsdl i found that service as well as binding tags are not defined or no such tags included. wsdl ends with port-type information.
In soap UI i got an error like no content in the file and when i try to open it in eclipse i am able to open it using web explorer window, but service as well binding information fields are empty. I could see ws-policy elements in customers wsdl.
How he might have produced a wsdl without binding and service information ?
What would be the reason he is telling it is working in .Net?
I am not sure about .Net tools.
Is there any web service client tool which can open the operations without endpoint /service information and send request/response ?..
please help
thank you for your time.
I only know a bit about the first question, can't help you with the other ones...
You can request two "flavors" of WSDL from a NW/ABAP system. This is related to the fact that the implementation (programming) of the service is usually performed on a different system and by different people than the configuration of the service.
After the service (or rather a service definition) has been implemented, you can get what's called a "design-time WSDL document". This document does not include the endpoint information - it cannot, because that would require technical information about the target system landscape and its configuration that is simply not available yet.
From the service definition, an administrator can create a configuration. This includes the binding information as well as stuff like base URL, security settings, transport layer settings and so on. With this configuration, you can generate a second WSDL document that contains the actual endpoint configuration.
is there any best practice to version every release of my jax-ws based web services build ? I have seen a few ways to version REST based services (for example to include the version information in URL etc.) Is there any other different way of versioning JAX-WS based web services. .
To version my services, I use a different targetNamespace.
For instance, I add the annotation to my interface :
#WebService(name = "YourService", targetNamespace = "http://whatever/you/want/VersionNumber")
Running wsgen you will end up with a different targetNamespace in you xsd. All old clients won't be able to use your webservice, with a clean, "fail fast" error.
However, as this is quite annoying, I only update this version when the signature of the service has changed, to prevent from wierd, hard to debug, errors
We currently have an application that runs an embedded jetty 6.1.14 server to which we need to add authentication via Kerberos. I'm new to Kerberos, which makes the task about 100x harder that maybe it should be. I've scoured the internet and have found conflicting reports as to whether or not it is even possible but nothing much to provides guidance as to how to proceed.
I've managed to have the server basically be able to authenticate the users via kerberos but can't find away to have the client automatically send its kerberos ticket: I have to use the from auth-method, though there are hints that this may be using filters, which are very poorly documented.
My question - and I apologize for it being a bit vague, I've not been this exasperated in quite a long time - is to request some guidance for plugging in kerberos authentication without login forms in Jetty 6? Or am I just out of luck? Has anyone added this type of authentication to jetty 6?
If Jetty supports Servlet Filters (JSR-53), then this open source project http://spnego.sourceforge.net might be what you are looking for.
You have to prepare your domain environment first. Make sure that your server if part of your domain (joined it). Then you have to create an machine account and assign an SPN. If you have done that, create a keytab for that account. From now on a client will be able to search for the host in the domain and create a ticket for. Then comes Jetty into play.