| Application Integration Architecture: Agile PLM PIP for SAP Security Guide Release 3.5 E73104-01 |
|
 Previous |
 Next |
| Application Integration Architecture: Agile PLM PIP for SAP Security Guide Release 3.5 E73104-01 |
|
Previous |
Next |
This chapter describes the fundaments of security related to Agile PIP for SAP.
The integration between Agile PLM and SAP is designed to enable the product development process and address the primary use cases around the synchronization of product content information between Agile Product Collaboration and SAP. This allows for rapid implementation of Oracle's next-generation integrated enterprise PLM processes that help the customers reduce costs and any risks associated with typical third-party and custom integrations.
The Agile PLM pre-built integration for SAP includes the following functions:
Manufacturing release of new product definition and product launch.
Change management of previously launched products.
Bidirectional synchronization of engineering change status and material attribute information from SAP to Agile PLM.
Monitoring and control of the change processing and validation queues.
Figure 2-1 illustrates the Agile PLM to SAP integration architecture.
For more information, see the Oracle Application Integration Architecture Agile Product Lifecycle Management Integration Pack for SAP: Design to Release Implementation Guide.
Agile PIP for SAP is based on the Foundation Pack. The Foundation Pack is a part of the AIA framework, so AIA security can be applied to Oracle Agile PIP for SAP.
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 ProcessEngineeringChangeOrderAgileReqABCS, 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.
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, server-specific ABCS and the service provider, choosing a security model plays a critical role.
Oracle AIA architecture enables you to choose one over the other at the implementation time for each of the transactions.
Adoption of the industry-standard WS-Security security model is possible, provided that all participating applications in the transactions provide inherent support.
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.
See Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack for more information.
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.
Oracle AIA leverages web service administration tools such as Oracle Web Services Manager (OWSM) in a non-intrusive 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.
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
