I'm new to web-services and i would like to know the answer to some questions.
First, i know that REST APIS can be consumed just by having the URL of the rest endpoint, on the other side (SOAP), you can't consume any distant SOAP WS unless you develop a client. Is it correct? And if it is, is it the only difference between the 2 big families ?
Second, i would like to apply XACML on some SOAP Web Services for security purpose of course. I made a figure that resumes the entire process of XACML.
I developed some basic SOAP web services with simple 2 methods, and i don't know from where should i start the XACML code and configuration. I'm asking you guys for some good and helpful links to apply the XACML security filter.
You can find an example of CXF interceptor doing XACML-based (XACML 3.0) authorization on Colm O hEigeartaigh's blog (Colm is one of the main CXF developers). The actual source code of the CXF Interceptor: XACML3AuthorizingInterceptor. It is using OpenAZ as XACML implementation, but you can adapt it to use another XACML implementation, such as Axiomatics mentioned here by David Brossard, or AuthzForce (supporting embedded or remote RESTful PDP modes), or other implementations mentioned at the end of the XACML TC's page.
The first important part of the CXF Interceptor is at the beginning of the handleMessage(Message message) method:
SecurityContext sc = message.get(SecurityContext.class);
The SecurityContext gives you information about the authenticated user such as the user roles, which you can use as XACML subject attributes in the XACML request.
The code further creates the XACML Request using the DefaultXACML3RequestBuilder class, that extracts other information from the CXF Message using CXFMessageParser - that you can find in the cxf-rt-security-saml library - such as the SOAP service name, operation name (as defined in the WSDL), and the endpoint URI:
CXFMessageParser messageParser = new CXFMessageParser(message);
...
String actionToUse = messageParser.getAction(action);
...
QName serviceName = messageParser.getWSDLService();
QName operationName = messageParser.getWSDLOperation();
...
Related
I have exposed some rest api using Jersey 2(Tomcat server) and successfully implemented Basic authentication(only needed authentication stuff not authorization) using ContainerRequestFilter filter as below
public class AuthFilter implements ContainerRequestFilter{
#Context
HttpServletRequest request;
#Override
public void filter(ContainerRequestContext context) {
............................
//getting username/password authorization header and validating
When I told the same to my Lead, he said don't use filters as every time your rest api is hit, this filter will get invoked.Therefore, implement basic authentication security at container level.I am using Tomcat server.
In web.xml, this is defined
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
Is the above he is referring to?
Can anyone please guide me how to implement the way my lead is saying?
The documentation gives you examples on how to configure this via web.xml. You'll need to configure this using a login-config that belongs to a realm. The web container then takes care of securing resources based on URL patterns.
Note that the data is sent in plain text (in encoded form) via a HTTP header, so you'll need to think of ways to ensure that is not snooped on (like HTTPS).
Whether you check this header on a filter or on the container does not relieve you of the overhead required for making the check (which is probably negligible, but I've never profiled this area of the code to quote numbers).
I am very much confused about the concept behind the QName.
lets take for example (I have taken these examples from http://www.mkyong.com/):
ServerInfoService sis = new ServerInfoService();
ServerInfo si = sis.getServerInfoPort();
System.out.println(si.getServerName());
And with QName :
URL url = new URL("http://localhost:8888/ws/image?wsdl");
QName qname = new QName("http://ws.mkyong.com/", "ImageServerImplService");
Service service = Service.create(url, qname);
ImageServer imageServer = service.getPort(ImageServer.class);
Now my question is :
1) Is there any concepts based on which we have to decide which type of client we can write
2) What is the purpose or additional benefits in using QName because all I can see here is that it increases complexity as compared to simple client.
Here is what i know:-
It depends on how you would want to make use of your client to invoke the web service.
The first approach
ServerInfoService sis = new ServerInfoService();
ServerInfo si = sis.getServerInfoPort();
is the plain simple proxy generation approach; where-in you use a tool like wsimport to generate proxies/stubs to your SEI(Service Endpoint Interface)/web-service interfaces and invoke methods on it like any other java method call. Is mostly used in clients where you simply need to invoke methods on the web-service without getting into granular details.
The QName or rather the Service approach offer finer controls over how the client and webservice communicate. JAXWS 2.0 introduced something called as a Provider interface which was an alternative to your SEI which basically let a client communicate at the XML message level and provide a dynamic representation/view of your web-service to the client. More here. The primary use of Service API is mostly to create Dispatch instances which basically let a client dispatch to a speicific port(method qualified using QName api) using JAXB messages as XML payloads.
Other uses of Service api let a client call methods on the webservice asynchronously; provide access to handlers; etc. A good example of using the Service and QName approach to help you understand further and to relate to what i have said is this link here:- Dispatching Web Service Calls.
This being said there is a lot more to know and understand; but hope this gives you a start.
I have found numerous academic answers to this question, but I would like one from practitioners in the field.
Background
I would like to create a Java-based RESTful API, using the Grails framework for a variety of mobile clients (iOS and Android) to access protected resources through my service. I require authentication on certain requests, and I already have SSL setup over the wire (so all requests occur over https). My web API will eventually be exposed as a service to other web applications.
Problem
What authentication method do people recommend for a web service that is to be consumed by mobile devices, and eventually other web applications?
These are what I see as my choices. Can you tell me when would be appropriate use cases for each one?
I can do HTTP Basic authentication
I can do HTTP Digest authentication
I can implement OAuth authentication (1.0 or 2.0)?
I can pass the credentials as parameters in my request
I can use an authentication method above, and then pass a delegate/token around for authentication
I can implement my own custom HTTP authentication headers
I can use cookies and pass those to the server on each request
Other...?
Need
If you have one leaning one way or another, I'd like to know why you would choose that method. Better yet, if you're doing this in Grails, I'm very interested.
I already know...
I've already read through the excellent answers here and Richardson and Ruby's book, Restful Web Services.
REST is stateless protocol, thus using "work sessions" - I mean login/work/(auto)logout concept is somewhat questionable. Sending credentials as a parameter with each request seems to be the most often used method due to its simplicity. Just keep in mind that
1) The api url must be SSL only - it makes sense to use a dedicated domain AND ip address, e.g. api.example.com and configure your web server to handle SSL only for this address and domain. Just to avoid accidental disclosure of credentials.
2) Avoid using login/password with the request if possible, use "API key" (a shared secret) instead. You always may use "API key" instead of login/password if authentication is all you need, that is you do not need authorization (all users share the same permissions) and no need for logging (who did what).
3) Rather than sending the API key with each request, it is better to "sign" the request using shared secret and supply the signature. With the key long enough you may use this technique over plain unencrypted http.
=== responding to a comment ===
If you need authorization, just use basic authentication:
HTTPBuilder builder = new HTTPBuilder("https://api.example.com/v1/foo/bar")
builder.auth.basic(login, password)
builder.headers.put('Accept', 'application/json')
def result = builder.request(POST, JSON) { req ->
body = [
....
]
response.'201' = { resp, json ->
....
}
response.success = { resp, json ->
....
}
response.failure = { resp ->
log.error "failure, ${resp.statusLine}"
}
}
The requirement is to include security attributes in header of Soap Message in every WebService request. One way to include is:
#WebService
#SOAPBinding
(
style = javax.jws.soap.SOAPBinding.Style.DOCUMENT,
use = javax.jws.soap.SOAPBinding.Use.LITERAL
)
public interface UserService
{
#WebMethod
public AuthenticateResponse authenticateUser(AuthenticateRequest request, #webParam(header=true) ApplicationCredential appcredential);
#WebMethod
public UserDetailResponse getUserDetail(UserDetailRequest request, #webParam(header=true) ApplicationCredential appcredential);
}
But, with the above mentioned approach, I need to include ApplicationCredential at every operation. It doesn't look good. I am looking for if we can include this ApplicationCredential class in BaseRequest Class and mention there that it is going to be a part of Soap Header(through some annotaion), that would be really helpful. For ex:
public class BaseRequest
{
#SomeAnnotation which states that Appcedential is a part of Soap Header
ApplicationCredential appcredential;
}
So far, I am unable to find any way to do this. Any help would be highly appreciated.
I know it's a while ago you asked that question, and you may have found out yourself already, but I answer to it anyway: Try to avoid to create your own authentication handshake for Web Services - instead use either Web Service message level security if your server and client provide it, or just use transport level security, e.g. Basic Authentication and/or SPNEGO.
The selection of the authentication mechanism depends mainly on your context: If you provide the service within a company network, use whatever is provided there, or Basic Authentication if no central authentication infrastructure is in place. If you provide your Web Service to the Internet, the easiest way to do authentication is again Basic Authentication (via SSL), but that again depends on the kind of service consumers you envision.
This answer creates more questions, I guess, sorry about that. My main point is that you should not try to reinvent the wheel again =:-)
Is there any way to use soap-rpc web services such that the client is generated via a shared interface? Restful web services do it this way, but what about soap based? Do you always have to use a tool like Axis or CXF to generate your stubs and proxies, or is there something out there that will set it up dynamically?
Thanks.
EDIT #1:
To clarify, I'm looking to do something like this:
Common interface:
#WebService
public interface MyWebService {
#WebMethod
String helloWorld();
}
This common interface can already be used to create the server side component. My question is: can this type of common interface be used on the client side to generate dynamic proxies? Restful web services do it this way (Restlets & CXF) and it seems the .Net world has this type of functionality too.
I would see this tutorial of JAX-WS useful for your purposes:
In the example code the Web Services Client is configured by adding an annotation #WebServiceRef with a property pointing to the WSDL location to the client implementation class and no tools are needed to access the stuff from the Web Service that is referenced.
Was this the way you would like to have it, or did this even answer to right question?
Not exactly sure what you're looking for, but if you don't want to rely on JAX-WS/JAXB-generated artifacts (service interfaces and binding objects), you can make use of the Service and Dispatch APIs. For example:
QName serviceName = new QName(...);
Service service = Service.create(serviceName);
QName portName = new QName(...);
String endpointAddress = "...";
service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);
SOAPMessage request = ...;
SOAPMessage response = dispatch.invoke(request);
Check Apache CXF. Configuring a Spring Client (Option 1).
When you want to call a webservice, you must have knowledge of methods implemented on it. For that, We need to make stubs OR we can read it from WSDL.
I have created a WS client, using AXIS2 libraries, which is without stubs. The thing is, for each diff. WS we need to create response handles.
You can call any WS method using SOAP envelops and handle the response.
//common interface for response handlers...
//implement this for diff. web service/methods
public interface WSRespHandler{
public Object getMeResp(Object respData);
}
//pass particular handler to client when you call some WS
public class WebServiceClient {
public Object getResp(WSRespHandler respHandler) {
...
return repHandler.getMeResp(xmlData);
}
}
Please check the link below, which shows the example interface for WS client.
http://javalibs.blogspot.com/2010/05/axis2-web-service-client-without.html
For every diff. WS method we can have diff. implementation for WSRespHandler interface, which will help parsing the response.
Not knowing java so well, but being forced to learn some to accomplish a task that I was given, I needed to consume a .Net service that I have already written, I had to do a little research.
I found that 99% of the examples/samples/problems with invoking a method call against a .Net service, or any service for that matter involved using J2EE (ServiceManager) or build classes and a proxy that reflect the service being invoked. Unfortunately for me, none of this would work. I was working "in a box". I could not add new classes, could not WSDL references, did not have J2EE, but DID have access to the standard java libs.
I am used to doing this sort of thing in pretty much every other language but java, but now there was no choice, and java it was.
A lot of digging and figuring out all new terminology, methods, classes, etc, I knew I was getting close, but was having issues with some small items to complete the task.
Then I came across this post: http://www.ibm.com/developerworks/xml/library/x-jaxmsoap/
As long as you have some sort of idea of what you need to send the soap service in term of the soap envelope, the above link will give you the information you need to be able to invoke a service without the classes, wsdl class generators and J2EE, apache or other dependencies.
In an hour from the time I read the mentioned article, I had a class working and about 10 minutes later, converted the code to the "in the box" solution.
Hope this helps
Apache Tuscany might help you, although it may be heavier than you want
http://tuscany.apache.org/