I have a question regarding authorization for SOAP services. Please note I am asking for authorization, not authentication which I know how to do using WS-Policy specification.
What I would like to do is to define access rights for different SOAP operations. For example: getMeSomeData operation is accessible to simpleUser but getMeSomeSecretData operation is not, but it is accessible to adminUser.
I was assuming this is possible since SOAP standard is quite complex. Is there anyone well oriented in SOAP who knows if it is? And if it is possible, could you give me any guidance or article I could read about how to do it?
Based on my extensive googlig, this is not possible.
About the only way to do this would be with some kind of server integration with whatever the back-end of the soap may be. But this wouldn't be a soap functionality as much as a 'hack' sitting behind it using whatever your authentication layer may happen to be.
Related
I have searched for use of WSDL, but I am not able to fully comprehend what would happen if WSDL hadn't existed.
A example explaining the scenario would be nice.
Thank you.
THe WSDL is the "contract" which describe the objet use to call or response a WS and the service and operation expose.
In SOAP architecture, if you don't have this you d'ont know how to dialogue with the WS.
Additionnaly, in many language, it used to generate class that represent the objet.
there is plugin for maven or graddle for example.
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 SOAP over HTTP a subset of XML over HTTP since I assume SOAP also an xml that confirms to a schema (SOAP schema)? I assume XML over HTTP service can either be accessed using GET or POST method. Does SOAP over HTTP always use POST method? In case of XML over HTTP I assume the disadvantage is that schema file has to be shared with all the consumers whereas in case of SOAP over HTTP it will be a single WSDL file. Would it be possible to help in letting me know the difference and also advantage of one over the other?
SOAP is a specialization of XML, as it has a schema, such as http://www.xmlsoap.org/soap/envelope/, whereas XML is more general.
For using GET, you can read through this discussion: http://www.coderanch.com/t/463869/Web-Services/java/SOAP-request-HTTP, but basically SOAP is done via POST, though Axis2 appears to have support for GET, as a way to have SOAP work in a world where REST seems to rule.
And, according to this IBM article (http://www.ibm.com/developerworks/xml/library/x-tipgetr/index.html) SOAP 1.2 introduces GET.
As you mentioned, SOAP is a standard, so there are tools that can easily work with it, including dynamic client generation, as shown in this question, dynamic proxy soap web service client in java?, whansere the client generates the stubs needed upon connection.
If you use XML over http, it may be better, depending on the need, as a way to transfer data, but in the use cases I can think of it would seem better to just use JSON and REST, but, if you want to transfer XML, or send XML, then you could look at using REST.
POST would be the better option though as GET has size limitations (maximum length of HTTP GET request?), which is probably why SOAP is almost always POST.
The WSDL is not necessarily a single file, in WCF, if I remember, there are many xml files that need to be put together for the WSDL to be complete.
The advantage depends on what your use case is, but I find that use REST and allowing the user to select the type is useful as it can be trivial to switch between JSON and XML, for example, and is the better choice for XML over HTTP.
SOAP is best when integrating with older technologies as that may be all they can easily use. For example, when I have made webservices for SAP integration, it can be more work to have it not use SOAP, depending on the ability of the ABAP programmer.
You may find this question of use:
How SOAP and REST work with XML/JSON response?
and for a discussion about JSON and XML in webservices you may find this helpful:
http://digitalbazaar.com/2010/11/22/json-vs-xml/
I forgot this link, as they do a brief comparison, but in the end you can easily support both. In WCF I had a controller that had the business logic, and had to .aspx files, one for SOAP and one for REST, and some webservices supported both, as it was just a matter of handling the request and response differences. So, if you want to provide support for both, and have a business case showing it makes sense, then pick a framework that will make it easy to do.
http://digitalbazaar.com/2010/11/22/json-vs-xml/
Basically, the goal is to provide services to clients via the web. What clients are going to connect? How will the clients find it easiest to reach out? How much data is being passed in the request?
These types of questions will lead to the best solution for your needs.
Please can anyone explain briefly about concepts involved in WS security to protect soap from intermediate web services...
WS-Security does not implement anything new. It says how to use XML Encryption and XML Signature specifications in the SOAP world.
WS-Security is transport independent and provides message level security.
Since it's message level security - when we use encryption the message will be encrypted from a key known to the ultimate receiver, so intermediaries cannot view the message.
Thanks...
It is difficult to provide a simplistic answer unless we know what you are interested in (as Tim mentioned in his comment)
Have a quick read at this to get an idea.
http://www.ibm.com/developerworks/webservices/tutorials/ws-understand-web-services4/
This is not the only reference but think of it as a place to start.
Once you have an idea you will able to ask specific questions and the folks here would be able to help you out with their answers
HTH
Manglu
JSR 109: Implementing Enterprise Web Services
... is also an interesting read. the doc has some further references on the topic.
I thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck