This chapter describes Oracle Application Integration Architecture (AIA) support for all security-related functions.
This chapter includes the following sections:
For more information about security, see "Working with Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
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
Service-oriented architecture (SOA) separates interfaces and business logic. The security architect has several security deployment choices for SOA and web services.
For example, you can host a SOAP web service interface such as CreateSalesOrder as a proxy instead of hosting the real endpoint of the business logic implementation. The gateway handles communication to and from the web service and performs security functions on behalf of the service endpoint. The actual endpoint is virtualized. The client behaves as if it communicates with the service provider, when it actually communicates through the proxy.
Web service administration tools such as Oracle Web Services Manager (OWSM) ensure the validity and safety of XML messages exchanged between services. Integration architects and developers focus on integration logic, while security architects and administrators focus on security and management. Enforcing security policies through a centralized tool ensures corporate rule compliance and applies policy changes centrally instead of in each web service. Administrators create security and management policies using a browser-based tool as needed during deployment. Security degrades performance, so administrators should use it only when needed. Typical web service security can have multiple policies attached. These policies can:
Decrypt the incoming XML message
Extract the user's credentials
Authenticate this user
Authorize this user and web service
Log 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 the relevant 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.
A typical interaction in Oracle AIA involves discrete interactions between a service requester, client-specific Application Business Connector Service (ABCS), Enterprise Business Service (EBS), server-specific ABCS, and service provider. Choosing a security model plays a critical role in these interactions.
Oracle AIA supports point-to-point and end-to-end security models. You can choose either at implementation time for each transaction.
To choose a specific security model and implementation technique, consider:
Is an entire transaction secured if the individual discrete transactions are secured?
Is the trusted model adequate, or do the discrete interactions require certificates from a certificate authority?
Can communication-level security methods such as SSL encryption secure individual discrete transactions within a trusted model?
You can adopt the industry-standard WS-Security model if all participating applications in the transactions provide inherent support.
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 encrypted data exchange. In Oracle's Web Services Security model, SSL can provide point-to-point security, data integrity, and data confidentiality.
Oracle AIA strongly emphasizes on message-level security. XML encryption secures web service data exchanges. In comparison, SSL has limitations. For example, suppose a document visits several web services before reaching its eventual endpoint. XML encryption can process the document while at rest or in transport. It also allows encryption of portions of a document instead of the whole.
AIA strongly recommends securing all services. Applying policies globally is preferable to constraining policy attachment only for individual services.
However, you must override globally attached client and service policies with directly attached local policies in these cases:
Global authentication policies delivered:
Global Service Policy applied - oracle/wss_saml_or_username_token_service_policy
Global Service Client Policy applied- oracle/wss10_saml_token_client_policy
Services in Pre-Built Integrations may be further hardened based on business needs.
Applications invoking secured AIA Web Services must send credentials.
The Global Service Client Policy handles inter-composite communication.
AIA services invoking non-protected and protected application services must have the relevant client policy applied to the reference components present in the service.
Applying default global policies secures all Oracle AIA services and propagates security identity across all locally invoked services. Service developers can override default functionality as needed by disabling or replacing a policy for a locally invoked service.
The application security context model integrates participating applications with different security representations in a standard way by eliminating point-to-point security.
Participating applications are often 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 them. The application security context standardizes authentication and authorization between applications so any application can be integrated with any other.
App Context includes any message processing information sent between the provider and requester applications. This includes but is not limited to authentication and authorization information. Oracle AIA supports authorization in app context. It also supports adding other context information.
Oracle recommends XACML Context Request as the best authorization information standard. 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.
For more information about security, see "Working with Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.