I'm trying to add SAML assertions to a SOAP web service that is built on the axis2 engine. I'm having a little trouble wrapping my head around how the two would interact. Could someone help point me in the right direction to add a SAML assertion to a response message from Axis2?
Thanks,
Tom
You'll need to include the rampart module as an extra module. The relevent section for configuring SAML support appears to be here
If you want more platform support then I'd recommend deploying your web service onto the Web services application server produced by the authors of Axis2. It has GUI driven screens that assist in configuring the Rampart module.
Related
I need to develop a REST client application that consumes a REST based web service written in some non-Axis2 framework like Apache Slign or Jersey. As far as I can think, this should not be possible as from what I've read from online docs is that Axis2 treats a REST request internally as a SOAP message. If the server side is also Axis2, then it would understand this and handle it gracefully but a non-Axis2 framework should not understand it as a valid REST call and therefore should fail.
Can someone suggest or atleast provide some pointers?
I was part of an Enterprise Service Bus(ESB) development where it had numerous web-services written in Axis2 , Weblogic etc . Also we had various clients which were non-Axis2 as well invoking the services in the ESB .
That is why strongly support my answer .
My friend asked to explain me what's the difference between Spring, axis2 and Jersey. Here I listed down a few differences that I'm aware of. Please comment/respond if you know more differences
Spring webservices:
A java web application with a servlet configured in
web.xml(org.springframework.ws.transport.http.MessageDispatcherServlet).
You can use spring annotated POJOs for creating web services
Supports both RESTful and SOAP based web services.
Since it’s a web application you can use http authentication mechanisms
for enabling security
Axis2:
The webservice application is a .aar file that will be deployed in
axis2.war
Use AXIOM for using non-primitive type arguments to web service calls
You can use JSR181 annotations to create webservices
You can use spring-dependency injection using axis2 extensions.
Supports both RESTful and SOAP based web services.
I guess you have to use ws-security implementation for
providing security
to your web services>
They claim hot deployment of webservices works but I haven’t seen
it working.
Jersey:
A regular web application with a servlet configured in web.xml.
Write custom message readers/writers for using
non-primitive type arguments to web
service calls
Since it’s a web application you can use http authentication mechanisms
for enabling security
Supports only RESTful implementation of web services
I have seen hot deployment working may be because it’s a web application
and the container can do hot
deployment
I'm not familiar with Jersey and Axis, but I can tell you something about Spring-WS.
You cannot use Spring-WS for restful webservices. Spring-WS is intended to be used for contract first webservices. You can however use the features of Spring 3.x and Spring-MVC for REST services.
As for authorization, you can easily wire in any sort of security (with Spring-Security for instance).
I'm a big fan of the 'automatic' (de) marshalling features of Spring-WS. Just annotate your methods with the correct types and it'll know what to do.
I have a WSDL which I need to trigger some commands from. I need to do this as part of a Maven Plugin (Mojo)
I'm a relative newbie to SOAP so what I want to know is this:
1) Is this possible? Can the SOAP calls be run from a Maven Plugin or does it require a container or something else?
2) If so, what tools should I use to do this? I've read about Apache Axis and have seen that it's capable of building a lot of things from the WSDL itself. Is this the sort of tool I should use? Do Mojos have a built in SOAP executor?
3) If not, what are my alternatives?
Is this possible? Can the SOAP calls be run from a Maven Plugin or does it require a container or something else?
Yes, that's possible, you do not require any kind of container to run a SOAP client.
If so, what tools should I use to do this? I've read about Apache Axis and have seen that it's capable of building a lot of things from the WSDL itself. Is this the sort of tool I should use? Do Mojos have a built in SOAP executor?
I would consider using a JAX-WS stack like JAX-WS RI which is included in Java 6. Much easier and much more elegant. Here are some tutorials to get started:
Introducing JAX-WS 2.0 With the Java SE 6 Platform, Part 1
Creating a Simple Web Service and Client with JAX-WS
Getting Started with JAX-WS Web Services
Developing JAX-WS Web Service Clients
In short, use wsimport to generate and compile the web service artifacts needed to connect to the service and use them from the Mojo.
I was tasked with implementing either a SAML authentication service, or a EWS (Entitlement Web Service Authentication) service, and I was wondering if anyone has any samples or documentation on such options. I am almost 100% sure that SAML is out of the question due to the time frame of the project.
EWS has been difficult to find online, I can't seem to find any good samples or documentation on implementing such service.
You have not stated which platform you are using, but there are open source SAML implementations that you can use. In php there is SimpleSAMLphp and for java there's Shibboleth.
Is there a clean way to expose a WCF REST service that requires basic authentication, but where we handle the actual validation of the username/password ourselves? It seems that when you tell WCF in config that you want to use basic authentication, it forces you to turn on basic authentication in IIS and IIS can only do basic authentication against window accounts.
The only hack we have found is to lie to WCF and tell it there is no security on the service and then do authentication outside of the WCF stack using a generic IHttpModule (which has a proprietary config file to indicate which URLs have which authentication/authorization requirements).
It seems like there should be a better way. Anyone have one?
The WCF REST Contrib library enables this functionality:
http://github.com/mikeobrien/WcfRestContrib
It also allows you to secure individual operations.
is the username and password set on the client like:
cc.ClientCredentials.UserName.UserName = ReturnUsername();
cc.ClientCredentials.UserName.Password = ReturnPassword();
Or are they embedded in the body of the REST message?
If the former, you can use a custom UserNamePasswordValidator:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
If the latter, you can set the service to no security, and use a custom ServiceAuthorizationManager to validate the contents of the message:
http://msdn.microsoft.com/en-us/library/ms731774.aspx
Hope one or the other helps! I'd try to post sample code & config, but I'm # home and dont have access to code, which is all # work.
See Custom Basic Authentication for RESTful services. Pablo's approach uses the interceptor functionality that is provided via the REST starter kit to solve the problem. If you do not want to depend on the REST starter kit, then you can create your own service host and use the inteceptor functionality provided.
If you host it on IIS, using custom http module is the way to go. You can bring over the principal over to WCF side to do code access security. See HTTP Basic Authentication against Non-Windows Accounts in IIS/ASP.NET (Part 3 - Adding WCF Support). Also see Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.
If you are not using IIS, you should be able to implement userNameAuthentication. See Finally! Usernames over Transport Authentication in WCF.
Yes absolutely there is a way. You need to configuring a custom userNamePasswordValidationMode value for your service and point it to a class with an overridden method that can inspect and validate the credentials provided. When making a RESTful call, these credentials when using Basic authentication in its proper form should be in the request header. With this custom method you can inspect the credentials and then authenticate the client to your service. No Windows accounts or domain even needed.
The nice thing is you can then take that security context to the next level and provide fine-grained authrization at the method level. You might have instances where a large pool of clients are able to access the service, but not all methods within (i.e. paid clients vs. unpaid). In this case you can also provide authorization at the method level as well if needed.
Below is a step-by-step solution (with too many steps to embed) by me that contains both the needed configuration and security required to have a complete solution. The problem is often Basic authentication is used without securing the Transport with a SSL certificate and this is bad. Make sure to follow all the steps and you will implement Basic authentication without the need of any type of Windows accounts or configuration on your WCF RESTful based service.
RESTful Services: Authenticating Clients Using Basic Authentication