Oracle Web Services Manager

By Sitaraman Lakshminarayanan
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to Web Services Security

About this book

Web services (WS) provide a simple, standardized way to connect applications over the Internet, however they require management of security and other run-time operations to work effectively. Oracle Web Services Manager is a software solution for managing the operations of web services and the interactions between these services.

This book explains the business reasons why web services security is required and gives an architectural overview of WS Security for an enterprise. It then provides details about the Oracle Web Service Manager product and how it can be leveraged to address the key security issues of Confidentiality, Integrity, Authentication, and Authorization. Whilst addressing these key issues, the book describes them fully with examples. It ends with a couple of unique features: one is the various options available for a successful deployment and the other is an explanation, in depth, of how the security components work.

Publication date:
July 2008
Publisher
Packt
Pages
236
ISBN
9781847193834

 

Chapter 1. Introduction to Web Services Security

Web services have become an integral part of software development and with the increased adoption of Service Oriented Architecture, business functionalities are being exposed as services within and outside the organization. While web services can expedite the integration process, business owners also need to understand the risk of Service Oriented Architecture from the security point of view and should make every attempt to mitigate that risk. This chapter will give an introduction to web services security—the need for it, what the security options are, and will even give a look quickly into the return on investment in web services security.

The Need for Web Services Security

Application integrations have gone through different phases from traditional file transfer to distributed systems, such as Distributed Component Object Model (DCOM) or Common Object Request Broker Architecture (CORBA) to the current platform independent standards based on Web Services (SOAP). Web services expedite the process of integrating different applications in different platforms without changing much of the underlying business process.

While web services can help the business, the data which was accessible only to that application is now available for integration with any other application. This leads to security concerns in exposing business functionality as web services. The most common questions asked by service providers and consumers in web services architecture regarding security are:

  • Service provider:

    • How secure is the data being exchanged? How do I control access to the service?

    • How do I ensure the confidentiality and integrity of the message, while still maintaining the interoperability benefits of web services?

    • How do I manage the enhancements and fixes to the service without affecting the consumers?

    • How do I monitor the performance of the service, its availability, and so on? (various parameters of Service Level Agreement)

  • Consumers:

    • How do I access multiple web services with their own unique security requirements?

    • How can I decouple the service invocation from the client application so that I can switch to a different service without affecting the client application?

There are some questions that are common to both service providers and service consumers, such as:

  • How can I externalize the security so that I need not worry about various security implementations for the underlying business application or service?

  • How can I define and enforce the governance around publishing web services, consuming service, security, and so on?

 

The Need for Web Services Security


Application integrations have gone through different phases from traditional file transfer to distributed systems, such as Distributed Component Object Model (DCOM) or Common Object Request Broker Architecture (CORBA) to the current platform independent standards based on Web Services (SOAP). Web services expedite the process of integrating different applications in different platforms without changing much of the underlying business process.

While web services can help the business, the data which was accessible only to that application is now available for integration with any other application. This leads to security concerns in exposing business functionality as web services. The most common questions asked by service providers and consumers in web services architecture regarding security are:

  • Service provider:

    • How secure is the data being exchanged? How do I control access to the service?

    • How do I ensure the confidentiality and integrity of the message, while still maintaining the interoperability benefits of web services?

    • How do I manage the enhancements and fixes to the service without affecting the consumers?

    • How do I monitor the performance of the service, its availability, and so on? (various parameters of Service Level Agreement)

  • Consumers:

    • How do I access multiple web services with their own unique security requirements?

    • How can I decouple the service invocation from the client application so that I can switch to a different service without affecting the client application?

There are some questions that are common to both service providers and service consumers, such as:

  • How can I externalize the security so that I need not worry about various security implementations for the underlying business application or service?

  • How can I define and enforce the governance around publishing web services, consuming service, security, and so on?

 

Security Challenges in a Web Services Environment


Web services actually expose the data and the business process without the need to have access to the user interface of that application. The security requirements in the web service environment can be best illustrated by an example.

Consider a scenario where a bank acquires information about its customer including a Social Security Number to open a credit card account. One critical requirement to open a credit card account is to have certain minimum credit history. The business process can be defined as:

  • Obtain the customer's personal information, including Social Security Number.

  • Perform credit check with an external agency via web service.

  • Upon the approval of credit history, open the credit card account.

The picture shows the interaction between different systems. From the picture, it is clear that the security at the front end layer, that is at the application layer alone, is not enough.

When there is critical business information exchanged within web services, the service should:

  • Identify the service consumer: Authentication

  • Validate that the service consumer is authorized to access the service: Authorization

  • Protect the message integrity: Signature

  • Protect the confidential data: Encryption

  • Track who accessed and when: Auditing

 

The Need for Identity Propagation from Calling Application to Web Services


Security at the application layer can show the pages for which the user has the privileges to view. It can even control the operations allowed on that web page, such as Add, Modify, Delete, and so on. This is typically done by means of a web access management product such as Oracle Access Manager. However, the application actually does certain operations on behalf of the user, such as accessing the database, accessing web services, and so on. Consider the scenario where the user at the travel department of your company makes travel reservations. The user will login to the application and when the user actually makes the reservation, the application makes the web service calls to reserve the tickets and charge the credit card. In this scenario, the web application has the following capabilities (but not limited to):

  • Accept credit card information

  • Charge the credit card

  • Make the reservation

In the above scenario, the application layer can only protect the information based on the user who logged in, and can only protect someone from accessing a web page that they are not supposed to. However, the application needs to call a few web services to complete the travel reservation. In that scenario, the challenges are:

  • How do I propagate the identity of the logged-in user to the web services? How do I translate the SSO token that was established when the user logged into the system to one of the security tokens required by the web service provider?

  • How do I add any additional information to the web service request so that the service provider can authenticate and authorize the request?

  • How do I enforce security that may be different for different services without writing security-specific code within my application?

Since the web services are easily accessible, it is important to make sure that it is very well secured, not only to protect the confidentiality and integrity, but also to allow access only to the authorized users. The following figure shows the reason why web layer security is not enough for database application.

The next section looks at why network security isn't sufficient, and also provides an overview of different web service security components.

 

Why HTTPS Based Security Is Not Enough


One common security practice is to implement network level security, such as HTTPS for transport layer security. Secure Socket Layer (SSL) is the de-facto standard way of communicating over HTTP, commonly used as HTTPS, so that the data is encrypted over the network between the client (for example, web service consumer) and the web server (for example, web service provider). While HTTPS offers transport layer security by encrypting the data over the wire, it does not validate the user actually accessing the URL by default. HTTPS only assures the clients (consumers) that they are talking to the legitimate web site (by means of digital certificate). However, there is an option available to validate the client—by means of client certificate validation. In this case, the client application has to attach the client certificate while invoking the HTTPS URL, and the web server can validate the authenticity of the client certificate before actually granting access to the URL. HTTPS with the client certificate validation will ensure that the server knows exactly who the consumer is.

In our example application scenario, one easy way to enforce secure access to the web service is to enable HTTPS along with client certificate validation between the web service provider and the web service consumer. The following diagram shows how the web service is given access only to a trusted organization, and the intruder is prevented from accessing the web service.

Certain network level security such as HTTPS, client certificate validation can be applied even to web services. However, each has its own pros and cons, and a detailed discussion is beyond the scope of this book. We will describe the network level security for web services in depth here:

Network level security

Description

What it doesn't do for web services

HTTPS (SSL)

It creates a secure connection with server and thus encrypts the data transmitted over the network.

HTTPS access alone does not validate the client/consumer of the web service.

HTTPS (SSL) with Mutual Authentication

It encrypts the data over the network after performing client certifi cate validation.

Even though it can encrypt and identify the client or the consumer, it does not ensure the integrity of the message that actually left the server.

While network level security is a great place to start, for web services to secure the transaction at the network layer, the data or the message itself should be protected once the message leaves or reaches the destination. The next section will provide an overview of the different components of web services security, and why it is important to address them.

 

Components of Web Services Security


The various components of web services security are:

Authentication

Authentication is the process of verifying the credentials of the user accessing the system. Webservices should authenticate the user requesting the service before it can execute the request. Without any proper identification of the user, it will be impossible to perform an audit of any unauthorized access.

Authorization

Authorization is the process of validating who has access to what before granting access to perform an operation. Web services security should not only authenticate the user, but should also validate if the user has enough privileges to perform the operation.

Confidentiality

Web services exchange critical business information in XML; certain information can be confidential and it should be protected from any intruder or unauthorized access. XML messages should be encrypted by the service, or the consumer, depending on the sensitivity of the message being exchanged.

Integrity

Since web services exchange XML messages, the integrity of the message should be ensured. Message integrity can be ensured by means of digital signature. Digitally signing the XML messages in the web services can ensure that the message was not tampered by the intruder in transit.

 

Return on Investment


Investment in security is not easily quantifiable as any other IT system investment. While there is a technology component to the security implementation, it is often the risk that the business is willing to take that drives the security implementation, and securing the web services is no different.

Implementing web services security does require certain investment, either in terms of buying an off-the-shelf product such as Oracle Web Service Manager, or implementing a custom security framework across all the web services and the clients. In either case, the investment should be justified for the business owners. While calculating the ROI on web services security implementation, the following factors should be considered from the business stand point:

  • How much of the confidential data is being exposed on services?

  • Is it fine not to have any data integrity checks on those web service messages?

  • What would be the business impact? Lost monetory value, lost productivity, reputation, and so on.

  • Should the service authenticate the user? Is it okay for anyone to access this service?

  • Is it okay for everyone to perform all the operations exposed by the service?

  • Is it required to satisfy any government regulations?

If the business owners decide to make sure that the web services should be secured, then the IT department should consider the following while defining the ROI:

  • How many web services are deployed in a single server, or multiple servers?

  • Is there a potential for many more services in the future?

  • Are those services in different platforms such as Microsoft .NET and Java?

  • Are there any web services behind the firewall that need to be exposed to external vendors?

When there are many web services in different platforms, and that require the understanding of multiple authentication tokens, encryption, signature and so on, the cost of custom development and maintenance of security should be considered and compared with the cost of the product and its performance benefits.

 

Summary


This chapter gives an introduction to why web services should be secured in an organization and explains the different components of web services security that should be addressed. The next chapter will describe the various standards in web services security, the importance of centralized policy manager, and will also explain the web services security from an architect's point of view.

About the Author

  • Sitaraman Lakshminarayanan

    Sitaraman Lakshminarayanan is an Enterprise Architect with over 11 years of IT experience in implementing Software solutions based on Microsoft and Java platforms. His area of interest is in Enterprise Architecture, Application Integration, and Information security and he specializes in Identity & Access Management, Web Services, and SOA. He is a co-author of ASP.NET Security (Wrox publications) and has presented at regional and International conferences on Web Services Security and Identity Management.

    Browse publications by this author
Oracle Web Services Manager
Unlock this book and the full library FREE for 7 days
Start now