3 Security Implementation for Agile PIP for SAP

This chapter gives a general picture of PIP security, and describes how PIP security interacts with Agile and SAP Web Services.

3.1 Overview of PIP Security

The AIA framework provides the following methods to secure the service-to-service interaction:

• Identify clients through authentication.

• Secure messages through encryption.

• Avoid message tampering with digital signatures.

• Encrypt the channel through SSL.

Figure 3-1 High-level Security Architecture

Agile PIP for SAP 3.6 is shipped with this security implemented, except SSL, which needs manual configuration. OWSM already helps PIP to implement the security methods, and OWSM provides multiple policies to protect web services. The following sections focus on which policies are used in Agile PIP for SAP, and how to operate with Agile/ SAP security.

3.2 PIP Security Policy

SSince PIP is based on the AIA framework, all AIA policies can be used by PIP. The following is a list of policies which are used in Agile PIP for SAP:

• Global Service Policy applied:

  oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON - This is a cloned copy of oracle/wss_saml_or_username_token_service_policy with Local Optimization set to ON. This is needed for local optimization to work when both client and service composites are co-located.

• Global Service Client Policy applied:

  oracle/aia_wss10_saml_token_client_policy_OPT_ON

• Other Service Policies applied:

  • oracle/aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON - This is a cloned copy of oracle/wss_saml_or_username_token_service_policy with Local Optimization set to ON and HTTP basic authentication added as an additional option. Clients such as ODI that do not have the infrastructure to use web services security can call this service using HTTP basic authentication.

  • oracle/no_authentication_service_policy - The oracle/no_authentication_service_policy policy is to those services that do not need authentication.

• Other Service Client Policies applied:

  • oracle/aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON

  • oracle/aia_wss10_saml_token_client_policy_OPT_ON

  • oracle/wss_username_token_client_policy

  • oracle/wss_http_token_client_policy

3.3 Interoperability with Agile Web Service Security

Agile 9.3.5 and 9.3.6 provide a tool to enable security for Web Services in running time. Refer to the Agile Product Lifecycle Management Security Guide and follow the steps to enable/disable the security for Agile PLM web services. XXXX

When interacting with an Agile web service that is enabled for WS-security, you must add a security header in the SOAP header with all the information needed for security functions. Based on the security of the Agile service, you must add information for any combination of authentication, encryption and integrity. The following table lists the certified policies:

Table 3-1 Certified Policies

Composite Name	Service Name	Certified Policies
ProcessEngineeringChangeOrderAgileReqABCSImpl	ChangeABSService TableService	oracle/wss_http_token_client_policy oracle/wss_username_token_over_ssl_client_policy
UpdateEngineeringChangeOrderListAgileProvABCSImpl	ChangeABSService ChangeStatusService MergeABSService	oracle/wss_http_token_client_policy oracle/wss_username_token_over_ssl_client_policy

Note: The out-of-box policy for Agile web services is oracle/wss_ http_token_client_policy. If you are running Agile PLM in a non-Web Services Security environment, the Web Services Security Configurator does not need to be run. For more detailed steps, refer to the Oracle AIA Agile PLM for SAP: Design to Release Install Guide.

3.4 Interoperability with SAP

The SAP API's are generated from the WLS adapter for SAP with the secured login Non-Dialog/Communication user credentials. Therefore, none of the SAP services require security policies and are applied with service policy.