Web Service Security – Oracle Web Service Manager Quick Start – Simple Steps

Here I choose to install OWSM in stand-alone mode.

Installation steps (windows OS):

• Install Oracle Web service manager soa_windows_x86_ws_mgr_101310.zip. Unzip and install.
• Start–> Programs, make sure you’ve Oracle WSM – OWSMHome1
• Your OWSM setup is ready
• Start–>Programs–>Oracle WSM – OWSMHome1–>Start Server
• To stop server, Start–>Programs–>Oracle WSM – OWSMHome1 –> Developer Prompt. Type the command  wsmadmin stop <password>

Integration Steps:

• I prepared a web service and deployed it into Tomcat [Building a web service is out of scope of this post, you may google around to find good examples]
• Log into web service gateway manager with credentials: admin/oracle
• In this example, OWSM is running on a stand-alone OC4J server and web service running on Tomcat Server. Idea is to use OWSM as security gateway for web services of Tomcat.
• First create a gateway by filling a simple form from Policy Management Tab:
• 
• After successful registration of Gateway. Now ‘am gonna use this gateway for my sample web service running on tomcat
• 
• Click on creating Policies now
• Default Policies for Request would by ‘logging’ mechanism, click on “Add Step Below” to add File Authenticator

• 
• On successful policy creation you should click on ‘Commit’ for the changes to take place (this is important otherwise policies will not be enforced). Now you should see a policy link adjacent to gateway. Click on it to see the just created policy. Now you are done!
• Note: OWSM is capable of authenticating against: LDAP, Siteminder, File, Active directory, Oracle Access Manager. It is capable of SAML token based authentication, Certificate/Signature verification, encryption/decryption and lot many things. Guess what! you don’t need to make a single line of code change or add any code to provide security to your web services. That’s the best part of it… For this post, we just considered file authenticator

• Now since we’ve used File Authenticator, you should prepare a file from where you would want to validate username and password against.
• You may store password in simple plain-text or MD5. For simplicity, store user credentials in simple plain text in a file say .htpwd stored at c:\ in a format (username:password).

first:java1
username:password123

OWSM builds a a new WSDL URL, which should be exposed to the client but not the endpoint web service wsdl url. So that, client uses OWSM WSDL to access web services. Original web service link should never be exposed, doing so clients would be able to access the endpoint bypassing gateway! ‘am sure you don’t want to do that…
From Tools–>Test Page in OWSM, write a sample client to connect to the web service by pointing the URL to OWSM WSDL. Run the client that’s it!
Helpful links:

Here is a step-by-step quick start guide

Best things about OWSM:

• security code is separate from web services, this is really good and provides high cohesion and less coupling. However there is additional overhead of running a separate server for security
• Audit logging mechanism to know who accessed my web service, what was the request and what was the response delivered
• Overall latency of my web services
• Custom Reports on security issues

More Here

Courtesy:http://dailyraaga.wordpress.com/2010/12/03/web-service-security-oracle-web-service-manager-quick-start-simple-steps/

How do I secure my services?

We started with the bit of advice "only make them as secure as you need to". In other words the "HelloWorld" service probably doesn't need an encrypted request with a signed SAML Assertion over a mutually authenticated SSL channel on a private, physically disconnected network segment. And the "launch nuclear weapon" service should probably be secured with something other than a simple username token.

Figuring out what sort of security your services require takes time and effort and lots of information. So I'm not going even try to give you a recommendation here. Instead I guess I'm going to tell you what I told them...

This customer has requests coming in from the Internet. Their users do NOT have individual certificates but do have a username and password. The plan, in as much as there is one, is to have OSB in the DMZ accept the SOAP request from the user and then route it to the real service behind the firewall. So the customer asked us what they should do to secure the services.

They tossed around a bunch of ideas including:

• using an STS - the client would go to the STS and get a SAML assertion, then use that assertion to send the request to OSB.
• using an STS with WS-Secure Conversation - same as above, but instead of just getting a SAML Assertion the client would do the more advanced session "stuff" that spec describes.
• Publishing a certificate issuance SOAP endpoint. The SOAP client would call over to that service with a username and password and get a Certificate issued. The username and password would then be locked out and the Certificate would be the only way the user could authenticate after that point.

All of these solutions work - that is to say that they all provide some aspects of security and thus make the service more secure in some way. But they're all a bit heavy handed and require quite a bit of smarts on the client side. So we had a conversation about what they were actually trying to accomplish.

Turns out their requirements were that the data had to be transmitted securely - meaning nobody else could listen in and see the data. And they wanted to make sure that nobody could inject requests that didn't come from a real user into the flow. And that's it.

Those of you playing along at home know that one way SSL with the username and password in a WS-Security header meets those requirements. Plus it's really lightweight and simple to implement.

Sometimes simpler is better. And in this case turning all of the security levers up to 10 wouldn't have bought them anything but trouble.

So that's what they're going to go with - at least initially. In the future they'll revisit this solution and if things change they can always add new Proxy Services on the bus for other authentication methods.


Behind the bus was a whole 'nother story. They're going to use SAML assertions with the Sender Vouches confirmation method to pass identity down to the real services. But that's a story for another day.

More Here

Courtesy:http://fusionsecurity.blogspot.com/2011/01/how-do-i-secure-my-services.html

Multiple webservice implementation classes available at the same time under WAS7

If you want to experiment with webservices by providing several alternative implementations of the same webservice (represented by the element), each having its own URL, and you’re using Websphere 7 and JAX-WS, then:

1. For each alternative implementation, add with a unique name under the element in the WSDL file. Beware: This is essential to enable multiple implementations.
2. For each alternative implementation, define a servlet and servlet mapping in web.xml like this:
view source
print?
1
2 $IMPLEMENTATION_CLASS_NAME$
3 $IMPLEMENTATION_CLASS_NAME$
4 1
5
6
7 $IMPLEMENTATION_CLASS_NAME$
8 /$DESIRED_UNIQUE_URL$
9
3. Create the implementations – likely as POJOs denoted with the @WebService annotation – and set the corresponding portName for each of them (@WebService(portName=””, …))
4. Deploy and use

1. Define a unique wsdl:port for each implementation

As mentioned, it’s necessary to define a unique wsdl:port for each implementation.

We define two ports, LearningActivityPort1 and LearningActivityPort2, using the same port type (i.e. the same transport protocol etc.).

LearningActivity.wsdl:
view source
print?
01
02
03 ...
04 ...
05 ...
06 ...
07
08
09
10
11
12
13
14
15
2. Define a servlet and servlet mapping for each implementation

Next we need to declare each of the webservice implementation classes as a servlet and define a servlet mapping to assign a unique URL to that implementation as described in WAS help:
web.xml:
view source
print?
01
02
05 pokusWeb4was7
06
07
08 LearningActivityHttpBindingImpl
09 example.LearningActivityHttpBindingImpl
10 1
11
12
13 LearningActivityHttpBindingImpl
14 /LearningActivityJaxbService
15
16
17
18 LearningActivityRawXmlServiceImpl
19 example.LearningActivityRawXmlServiceImpl
20 1
21
22
23 LearningActivityRawXmlServiceImpl
24 /LearningActivityRawXmlService
25
26
27 ...
28

When deployed, the two implementation will be thus available under http://localhost:9080/pokusWeb4was7/LearningActivityHttpService and http://localhost:9080/pokusWeb4was7/LearningActivityRawXmlService.
3. Create each implementation linking it to its port name

Finally we write the two implementation, each being assigned to a different port name:
example.LearningActivityHttpBindingImpl:
view source
print?
1 @javax.jws.WebService (serviceName="LearningActivityHttpService", portName="LearningActivityPort1")
2 public class LearningActivityHttpBindingImpl{
3
4 public TransactionResponseMessage updateLearningActivity(LearningActivityMessage learningActivityMsg) {
5 //...
6 return response;
7 }
8 }

example.LearningActivityRawXmlServiceImpl:
view source
print?
1 @javax.jws.WebService (serviceName="LearningActivityHttpService", portName="LearningActivityPort2")
2 public class LearningActivityRawXmlServiceImpl{
3
4 public TransactionResponseMessage updateLearningActivity(LearningActivityMessage learningActivityMsg) {
5 //...
6 return response;
7 }
8 }
Closing notes

Notice that with JAX-WS

* You don’t need webservice.xml – all the necessary information is (may be) provided via annotations
* You don’t need to declare the web services in web.xml unless you need some special configuration (as we do here)

More Here

Courtesy:http://theholyjava.wordpress.com/2010/12/29/tip-multiple-webservice-implementation-classes-available-at-the-same-time-under-was7/