9 Understanding Security

This chapter describes Oracle Application Integration Architecture (AIA) support for all security-related functions.

This chapter includes the following sections:

• Section 9.1, "Introduction to Security"

• Section 9.2, "Oracle AIA Methodology"

• Section 9.3, "Introduction to Application Security Context"

For more information about security, see "Working with Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

9.1 Introduction to Security

Oracle Application Integration Architecture (AIA) provides support for all security-related functions including:

• Identification

• Authentication (verification of identity)

• Authorization (access controls)

• Privacy (encryption)

• Integrity (message signing)

• Non-repudiation

• Logging

The service-oriented architecture (SOA)-based integration approach allows for clear separation between the interface and the actual business logic. This provides the security architect with a number of choices in deploying security for SOA and web services.

For example, a SOAP web service interface such as CreateSalesOrder can be hosted as a proxy instead of the real endpoint that hosts the business logic implementation. The gateway proxies communication to and from the web service and performs security functions on behalf of the service endpoint. The actual endpoint is virtualized. Even though the client thinks it is talking directly to the service provider, it communicates through the proxy.

Oracle AIA leverages web service administration tools such as Oracle Web Services Manager (OWSM) in a nonintrusive manner to ensure the validity as well as safety of the XML messages exchanged between services. This methodology ensures that no enforcement of web services security is in silo mode. Integration architects and developers can focus on integration logic, and the security architects and administrators can focus on security and management. Having security policies enforced through a centralized tool enables the administrators to ensure that the corporate rules are applied as well as to apply the policy changes centrally instead of applying them in each of the web services. With tools such as OWSM, an administrator creates security and management policies using a browser-based tool as and when needed during deployment. Security should be avoided unless it is absolutely needed as it degrades performance. A typical web service security can have multiple policies attached that can:

• Decrypt the incoming XML message

• Extract the user's credentials

• Perform an authentication for this user

• Perform an authorization check for this user and this web service

• Write a log record of the preceding information

• Pass the message to the intended web service, if all steps are successful

• Return an error and write an exception record, if all of the steps are not successful

To apply the security policy, OWSM intercepts every incoming request to a web service and applies any one of the policy items listed previously. As the policy is executed, OWSM collects statistics about its operations and sends them to a monitoring server. The monitor displays errors, service availability data, and so on. As a result, each web service in an enterprise network can automatically gain security and management control, without the service developer coding extra logic.

9.1.1 Point-to-Point or End-to-End Security

Because a typical interaction in the Oracle AIA framework is part of multiple discrete interactions involving a service requester, client-specific Application Business Connector Service (ABCS), Enterprise Business Service (EBS), server-specific ABCS and the service provider, choosing a security model plays a critical role.

Oracle AIA provides support for point-to-point and end-to-end security models. The architecture enables you to choose one over the other at the implementation time for each of the transactions.

To choose a specific security model and implementation technique, the following issues should be discussed:

• Can an entire transaction be considered as secured as long as the individual discrete transactions are secured?

• Can the trusted model expressed previously be agreed to in principle, or must it be enforced using certificates provided by a certificate authority for the discrete interactions?

• Can the communication-level security methods such as SSL encryption be used to secure the individual discrete transactions within a trusted model?

Adoption of the industry-standard WS-Security security model is possible, provided that all participating applications in the transactions provide inherent support.

9.1.2 Transport-Level Security

Existing technologies such as SSL can be used to secure the transport channel. SSL enables two applications to securely connect over a network and authenticate each other. It also enables you to encrypt the data exchanged between the applications. In Oracle's Web Services Security model, this transport security mechanism can be used to provide point-to-point security, data integrity, and data confidentiality.

9.1.3 Message-Level Security

Oracle AIA places strong emphasis on message-level security. For a web service, XML encryption provides security for applications that require a secure exchange of data. While SSL was considered the standard way to secure data exchanges, it has limitations. For example, assume that a document visits several web services before hitting its eventual endpoint. By using XML encryption, the document can be encrypted while at rest or in transport. Encrypting only portions of a document instead of the whole document is also possible.

9.2 Oracle AIA Methodology

AIA strongly recommends securing all services. The general approach is to apply policies globally rather than constraining policy attachment only at the individual service level.

In some cases, it is imperative to override the globally attached client as well as service policies with directly attached local policies. General guidelines are given below.

• Global authentication policies delivered:

  • Global Service Policy to be applied - oracle/wss_saml_or_username_token_service_policy

  • Global Service Client Policy applied- oracle/wss10_saml_token_client_policy

• Services found in the PIPs might be further hardened based on the business needs. Further hardening of the services is done by associating local policies.

• Applications invoking secured AIA Web Services need to send credentials.

• Inter-composite communication is generally handled by the Global Service Client Policy.

• AIA services invoking non-protected as well as protected application services need to have the relevant client policy applied to the reference components present in the service.

By applying default global policies, all Oracle AIA services are secured by default and propagate security identity across all locally invoked services. It is the responsibility of the service developers to override default functionality by disabling or attaching a different policy as required invoking services on applications.

9.3 Introduction to Application Security Context

The Oracle AIA application security context model allows Oracle AIA to integrate participating applications with different security representations in a standard way by eliminating point-to-point security.

The participating applications are developed at different times with different concepts and implementations of authentication and authorization. When applications are integrated, you must pass authentication and authorization information between applications. Oracle AIA application security context standardizes the exchange of participating applications' authentication and authorization information between various applications so that any application can be integrated with any other application.

App Context is any information that needs to be sent to the provider application to process the message sent from requester application or vice versa. This includes but is not limited to authentication and authorization information. Oracle AIA addresses the exchange of authorization information in app context, but the design supports adding other context information.

Oracle AIA identified XACML Context Request as the best standard to represent authorization information. XACML is an OASIS standard for managing access control policy. Released in 2003 and based on XML, XACML is designed to become a universal standard for describing who has access to which resources. XACML includes a policy language and a query language that results in a Permit, Deny, Intermediate (error in query), or Not Applicable response. The query language is expressed in XACML context that is recommended by Oracle AIA for exchanging authorization information.

For more information about security, see "Working with Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.