Web Services Security

A common question that is asked is how security is implemented in Web Services.

I am copying the overview from this article

Overview of Information Security
It is important to have a general understanding of information security prior to addressing elements of web services security. There are six general security services that encompass the various functions required of a security facility. These can also be considered as requirements that define information security:

1. Authentication: Ensures that the sender and receiver are who they claim to be. Mechanisms such as username/password, smart cards, and Public Key Infrastructure (PKI) can be used to assure authentication.
2. Authorization or Access Control: Ensures that an authenticated entity can access only those services they are allowed to access. Access control lists are used to implement this.
3. Availability: Requires that uninterrupted services are provided to authenticated and authorized users.
4. Confidentiality: This assures that information in storage and in-transit are accessible only for reading by authorized parties. Encryption is used to assure message confidentiality.
5. Integrity: Ensures that information, either in storage or in-transit cannot be modified intentionally or unintentionally. Digital signatures are used to assure message integrity.
6. Nonrepudiation: Requires that neither the sender nor the receiver of a message be able to legitimately claim they didn't send/receive the message.

I am listing some of the other interesting articles that I found on  this subject

• This article is a good place to start at.
• This one by Axis covers the different types of attacks.
• This one shows the solution in code.

 Some important excerpts from this article are copied below

WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.

Security Assertion Markup Language (SAML) from OASIS provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved.

Adapters - Database and File Adapters

Oracle SOA Suite comes along with some adapters that adapt the underlying Component and wraps it as a Service. Some of the Adapters that are shipped with the application are Database Adapter, File Adapter, JMS Adapter, etc.
Oracle makes the access to the underlying Services easy by wrapping them as Web Services.(There is a WSDL created for each operation you make). It is very tempting to use these adapters. But,thought should be applied if this is the best design. For example, in the case of Database Adapters, it is always better to use the existing Web Services to retrieve the required data. If the Web Service does not exist and if it is in our control then it would be better to write the business logic and expose that as a Web Service. This will increase the maintainablity and reusability of this Service. I think the Database Adapter should be used when all the above options are not feasible. Even when used, it may be a better practice to create this a Web Service and assign them a suitable namespace so that they can be categorised properly.

I was recently asked if a Database Adapter can be used to poll for Orders in the Order table. My solution would be to first see if a trigger can be written on the table to publish a JMS message on the receipt of a new order. I heard that this was possible and found some information here. (Haven't tried it yet though).

SOA Suite 11g Components

The SOA Suite primarily comprises of BEA Application Server(J2EE) where the following Service Engines are embedded

• BPEL
• Mediator
• Business Rules
• Human Workflow

Oracle Service Bus is another important part of the SOA Suite but comes as a separate application.

The other helpful components/frameworks are

• Web Service Manager - where policies are defined and enforced
• B2B - A protocol engine that provides Business to Business communicaton over a variety of protocols like EDI, HL7, etc.
• Adapters - Adapts non service based components as services. Examples are Database Adapter, File Adapter, JMS Adapter, eBusiness Suite Adapter.

Managing/Monitoring Tools

• Enterprise Manager - A web based console to manage all fusion mddleware components
• Business Activity Monitoring(BAM) - activity monitoring tool

The IDE to develop the SOA application is Java Developer. There is also an Eclipse plugin.

Mediator

Mediator is a new component(originally Oracle Service Bus before it was replaced by the AcquaLogic Bus)that has been added to Oracle SOA Suite 11g.

This article explains the difference between Mediator and OSB.
The "The Big BPEL-ESB-OSB cook-off" by ToddBiske analyses the role of each one.


What does the Mediator do?

• It mediates components/services within an SOA Composite Application.
• Routes the requests to the Services
• Data Transformation between formats and protocols
• It DOES NOT do service localisation and it cannot act as a Gateway to the Services.

How is it different from Oracle Service Bus?

• The main difference is in the scope. Mediator performs intra-composite mediation while Oracle Service Bus performs inter-composite mediation which means that it mediates different composites together.

What should be done by a Mediator?

• In Oracle, every BPELProcess is a Composite Service. This Composite could be invoking multiple BPEL Processes or Components. The Contract is defined at the Composite Service and the Mediator plays the role of mediation between this Contract and the various contracts for other components within the Composite. 
• I think that it is a good practice to create a Mediator in all Composites even if the Composite has a single BPEL Process. The Mediator will help take care of additional operations that could be added to this Service in future.
• I think that it is a good practice to do all data transformations at the Mediator.
• Mediator can also perform routing of requests to different Services. But, I think that one should explore if this can be delegated to BPEL as its core stength is to orchestrate the services.
• Anything that does not belong to a process has to be extracted out and put in the Mediator. For example, if the process needs the data in a certain format then that transformation can be done at the Mediator or the OSB but not in the BPEL.