28 Working with Security

28.1.1 Securing Service to Service Interaction

By securing service to service interaction, you:

• Identify clients through authentication.

• Secure messages through encryption.

• Avoid message tampering with digital signatures.

• Encrypt the channel through SSL.

Figure 28-1 illustrates the high-level security structure for AIA.

Figure 28-1 High-level Security Architecture

AIA recommends using Oracle WSM to configure Web service security in Oracle AIA. To enable security on an AIA service you use Oracle WSM to assign the appropriate service policy. To call a secured service, you assign the appropriate client side policy.

28.1.2 Oracle AIA Recommendations for Securing Services

AIA makes the following recommendations for securing services:

• All Web Services must be secured. This includes:

  • AIA services such as Application Business Connector Services (ABCS), Enterprise Business Services (EBS), and Transport Adapter Services

  • Other application services hosted on Oracle Fusion Middleware

• The standard installation should deploy the services with security policies applied.

• In this release, the minimum protection provided by AIA services is authentication.

• You should further harden the services with message protection in the production environment.

28.1.3 Introduction to Web Service Security Using Oracle Web Services Manager

Oracle Web Services Manager (WSM) security and management is integrated into the Oracle WebLogic Server.

For more information about Oracle Web Services Manager, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

AIA recommends decoupling security logic from service development by configuring Web service security declaratively using Oracle WSM during deployment. You should use Web service security rather than SSL unless you have a compelling reason, such as participating applications that do not support it.

In AIA, Oracle WSM is installed as part of SOA Suite, and there are delivered policies for most commonly used security use cases. Oracle WSM has policies for adding a particular security function as a standalone or in combination with other security functions.

The policies are globally attached to services with varying degree of granularity such as:

• Domain - all services in a domain

• Instance - all services in a WLS server instance

• Based on SOA Composite name - all services in a composite

For a list of the delivered policies, see "Predefined Policies" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

28.2.1 Enabling Security for AIA Services

To enable security in AIA services:

1. Determine what type of security is needed.

   AIA recommends using WS-security for authentication, encryption and integrity.

2. Check if the global security policy is sufficient for the web service.

3. Find the WS-policy with the appropriate combination of features.

   For example, if you need encryption and integrity, then you must find the policy which does both encryption and integrity.

4. Attach policy to service to enable security for a service.

   For more information about how to attach policies, see "Attaching Policies to Web Services" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

5. Configure policies.

   You may perform additional configurations for each policy.

   For more information about how to configure each policy, see "Configuring Policies" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

6. Diagnose problems.

   For more information about how to diagnose problems, see "Diagnosing Problems" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

28.2.2 Invoking Secured Application Services

To invoke a secured web service:

1. Determine what type of security is needed.

   AIA recommends using WS-security for authentication, encryption and integrity.

2. Check if the global security policy is sufficient for the web service.

3. Find the WS-policy with the appropriate combination of features.

   For example, if you need encryption and integrity, then you must find the policy which does both encryption and integrity.

4. Attach policy to service to enable security for a service.

   For more information about how to attach policies, see "Attaching Policies to Web Services" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

5. Configure policies.

   You may perform additional configurations for each policy.

   In the case of WS-Security client side basic authentication policy, you must do the following:

   1. Configure credential store.

   2. Add the UserID and password associating with a key into the store.

   3. Use the key in the policy.

   For more information about how to configure each policy, see "Configuring Policies" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

6. Diagnose problems.

   For more information about how to diagnose problems, see "Diagnosing Problems" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

28.2.3 Overriding Policies Using a Deployment Plan

AIA Foundation Pack provides infrastructure to override the global policies in a declarative way. To override the policy, service developers must:

1. Create service configuration file as described in section Section 28.6.3, "AIA Security Configuration Properties."

2. Place it in the project folder.

28.2.4 Testing Secured Services using CAVS

To test secured services using CAVS, the element <cavs:CAVSRequestInput_1> should have the element shown in Example 28-1 under the <soap:Envelope>.

<soapenv:Header>
      <wsse:Security 
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd" 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd">
         <wsse:UsernameToken>
            <Username>[user name]</Username>
            <Password>[pwd]</Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>

If you are using a default user in the Identity store, then [user name] = weblogic and [pwd] = weblogic#1.

28.3.1 Enabling Security in Application Services

You can use the built-in capabilities of participating applications to enable security for services. To choose a product for enabling security, check if Oracle WSM has agent support for the application, and if it has, use Oracle WSM.

If the applications can enable any kind of security, use Web service security for authentication, encryption, and integrity. Otherwise, you can use SSL to secure the connection.

28.3.2 Invoking Secured AIA Services

When interacting with an AIA 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 on AIA service. Based on the security of the AIA service, you must add information for any combination of authentication, encryption and integrity.

Example 28-2 is a sample of a security header for authentication.

<wsse:Security  env:mustUnderstand="1">
<wsse:UsernameToken  wsu:Id="UsernameToken-dXtD14011QZUTlfIaSrMhw22">
<wsse:Username>weblogic</wsse:Username>
<wsse:Password  
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-
profile-1.0#PasswordText">weblogic1</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>

If the AIA service requires SSL, then the application should configure SSL for both one way and two-way SSL.

28.4.1 Oracle AIA Recommendations for Policies

In general, determining which policies to use depends on the basic requirements of your organization's security policy. The following questions help determine which policies can be used.

• Is there a need only to authenticate users?

• Is there a need for message protection?

• Will the token be inserted in the transport layer or in a SOAP header?

• Should you use a particular type of token?

The following policies should be attached globally to the AIA Services:

• oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON

• aia_wss_saml_or_username_or_http_token_service_policy_OPT_ON

• oracle/aia_wss10_saml_token_client_policy_OPT_ON

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 composite are co-located.

This policy authenticates users using credentials provided either in SAML tokens in the WS-Security SOAP header or in the UsernameToken WS-Security SOAP header. The credentials in a SAML token are authenticated against a SAML login module, while the credentials in a UsernameToken are authenticated against the configured identity store. Only plain text mechanism is supported for the UsernameToken. This policy can be applied to any SOAP-based endpoint.

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 webservices security can call this service using http basic authentication.

This is only attached to AIAAsyncErrorHandlerBPEL service.

oracle/aia_wss10_saml_token_client_policy_OPT_ON

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

This policy includes SAML tokens in outbound SOAP request messages.

28.5.1 Naming Conventions for Global Policy Sets

Naming convention for service-specific global policy sets

• AIA_[ServiceType]_WSServicePolicySet

• Possible values for Service Type:

  • ABCS

  • EBS

  • EBF

  • Adapter

  • Producer

  • Consumer

• Example: AIA_ABCS_WSServicePolicySet

Naming convention for client-specific global policy sets

• AIA_[ServiceType]_WSClientPolicySet

• Possible values for Service Type:

  • ABCS

  • EBS

  • EBF

  • Adapter

  • Producer

  • Consumer

• Example: AIA_ABCS_WSClientPolicySet

28.5.2 Naming Conventions for Overriding Config Params

Naming convention for config param - csf key

• AIA_APPSHORTNAME_ServiceName_PortTypeName

  • APPSHORTNAME: Application short name as defined in the service registry

  • ServiceName: Value of the attribute 'name' of the element 'service' in the WSDL of the External Web Service

  • PortTypeName: Value of the attribute 'name' of the element 'portType' in the WSDL of the External Web Service

28.6.1 What Default Policies are Attached to a Service?

The deployment of global policies is handled during the Foundation Pack installation. A set of global services and client policies are attached to the WLS domain at the time of Foundation Pack installation. The result is automatic securing of all services (matching the pattern) deployed on that server.

Foundation Pack installer creates both service-specific and client-specific global policy sets for the composite name patterns:

• ABCS

• EBS

• EBF

• Adapter

• Producer

• Consumer

Foundation Pack Installer creates the following policy sets:

• Global PolicySets attached to Composite Services

  • AIA_ABCS_WSServicePolicySet

  • AIA_EBS_WSServicePolicySet

  • AIA_EBF_WSServicePolicySet

  • AIA_Adapter_WSServicePolicySet

  • AIA_Consumer_WSServicePolicySet

  • AIA_Producer_WSServicePolicySet

• Global PolicySets attached to Composite References

  • AIA_ABCS_WSClientPolicySet

  • AIA_EBS_WSClientPolicySet

  • AIA_EBF_WSClientPolicySet

  • AIA_Adapter_WSClientPolicySet

  • AIA_Consumer_WSClientPolicySet

  • AIA_Producer_WSClientPolicySet

28.6.2 How Can the Global Policy be Overridden for an Individual Service?

Composites that must interact with protected application services needing a different security policy, have local policies attached, overriding the global polices at the time of deployment.

Similarly, the NoClientAuthenticationPolicy is attached, overriding the global policy sets for composites that must interact with non-protected application services.

The AIA Deployment Driver provides support, in general, for attaching any overriding local security policy, but supports configuration-overriding only for saml-token and username-token client policies.

When a different client (local) policy is used, the AIA Deployment Driver attaches the policy but its configuration is a manual task.

The structure of the XML file is shown in Example 28-3.

28.6.3 AIA Security Configuration Properties

Composites that require local policies attached to either service endpoints or reference endpoints or both, must furnish the information to the Foundation Pack tool. These composites must have an associated xml-based security configuration file. This file is named AIASecurityConfigurationProperties.xml.

The Foundation Pack tool needs the following information:

• Name of the composite

• Name of all service endpoints that require local policies

• Name of all reference endpoints that require local policies

• Name of the policies that must be locally attached

The associated AIASecurityConfigurationProperties.xml of the composite that requires a local policy attachment must furnish listed above. This file is placed along with the project artifacts in the same folder as the composite.xml.

This file should be source-controlled.

When a composite does not require a local policy attachment, then it is not necessary to have this xml file defined for that composite.

Example 28-3 shows a sample AIASecurityConfigurationProperties.xml.

<?xml version="1.0" encoding="UTF-8"?>
<!--Note: the attribute 'compositeName' is the name of the AIA Service 
composite preprended by {namespace of the AIA service as defined 
in its wsdl} --> 
<SecurityConfiguration xmlns="http://xmlns.oracle.com/fp/core/security/V1" 
version="1.0" 
compositeName="{http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/
SamplesCreateCustomerSiebelReqABCSImpl/V1}SamplesCreateCustomerSiebel
ReqABCSImpl">
<!-- the following element is repeated for each service end point of this 
Composite ,which requires a direct (local) policy attachement -->
<Service resourceType='SOA-Service' >
<!-- It is the service endpoint. It should be same as attribute 'name' of 
element  'service' in composite.xml -->
<Name>SamplesCreateCustomerSiebelReqABCSImpl</Name> 
<!-- This is the port name. For BPEL-based references, its value is Name of the 
Porttype as given in the WSDL of this AIA service  
For Mediator-based reference, this is [Name of the Porttype element as given in 
the WSDL]_pt This example assumes a scenario when services and wsdls are coded 
by following the AIA naming conventions.In other scenarios, the value might be 
slightly different. Look at the hint below to come up with the correct value 
for the element PortName.-->
<PortName>SamplesCreateCustomerSiebelReqABCSImpl</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_service_
policy</WSPolicyName>
</WSPolicies>
</Service>
<!-- the following element is repeated for each reference end point of this 
Composite ,which requires a direct (local) policy attachement -->
<Reference resourceType = 'SOA-Reference'>
<!-- should be same as attribute 'name' of element  'reference' in 
composite.xml -->
<Name>SamplesCustomerPartyEBS</Name>
<!-- port name. 
For BPEL-based references, its value is name of the Porttype element as given 
in the WSDL of this AIA service.  
For Mediator-based reference, the value is [Name ofthe Porttype element as 
given in the WSDL]_pt
-->
"This example assumes a scenario when services and wsdls are coded by following 
the AIA naming conventions. In other scenarios, the value might be slightly 
different. Look at the hint below to come up with the correct value for the 
element PortName. Hint: In the composite.xml, for the binding.ws of the 
'service' element, the attribute 'port' takes value of the following form. 
<binding.ws port="[namespace of the service as defined in the 
wsdl]/V1#wsdl.endpoint(<Service>/<Port>" Make sure that the PortName provided 
by you here, is same as <Port> in the composite.xml"
<PortName>CustomerPartyEBS_pt</PortName>
<WSPolicies>
<WSPolicyName policyType ="authentication">oracle/wss_username_token_client_
policy</WSPolicyName>
<ConfigParams>
 <!-- Param could be a repeating element- Future use only -->
 
  <!-- APPSHORTNAME should be same as application's short name  -->
 
  <!-- ServiceName and PortTypeName are as given in the APP's web service WSDL  
-->
 <Param paramName="csf-key">APPSHORTNAME_ServiceName_PortTypeName</Param>
 
</ConfigParams>
</WSPolicies>
</Reference>
</SecurityConfiguration>

Points to note for a composite:

• If no service endpoint requires a direct policy attachment, but a reference endpoint requires one, then the AIASecurityConfigurationProperties.xml need not have a 'service' element.

• If no reference endpoint requires a direct policy attachment, but a service endpoint requires one, then the AIASecurityConfigurationProperties.xml need not have a 'reference' element.

• If there are two or more service endpoints, but only one of them requires a direct policy to be attached, then only one 'service' element must be present in the AIASecurityConfigurationProperties.xml.

• If there are two or more reference endpoints, but only one of them requires a direct policy to be attached, then only one 'reference' element must be present in the AIASecurityConfigurationProperties.xml.

28.7.1 Introduction to Application Security

The Oracle AIA application security model allows 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. 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.

Figure 28-2 illustrates the high-level security functional flow.

Figure 28-2 Security Functional Flow

28.7.2 How To Exchange Security Context Between Participating Applications and ABCS

App Context is any information that must 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. AIA addresses the exchange of authorization information in app context, but the design supports adding other context information.

AIA determined 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 AIA for exchanging authorization information.

28.7.2.1 Requester Applications

The preferred approach is to let the requester application send application context information as an XACML request to the Requester ABCS. If the applications are not capable of formulating context information in an XACML request, then the participating application send application context information in a SOAP header or as part of business message content.

AIA recommends the use of a protocol specific adapter if the participating application does not use a SOAP interface. In that scenario, the adapter receives the application context in a custom way, prepares the participating application specific XACML request, and sends it to the ABCS.

Figure 28-3 illustrates the requester application flow.

Figure 28-3 Requester Application Flow

28.7.2.2 Provider Applications

The preferred approach is to let the provider ABCS send the application context as an XACML request to the provider application. If the provider application cannot receive an XACML request, but has a SOAP interface, then the provider ABCS sends the application security context in a custom XML format inside a SOAP header or as part of a business document. If the provider application does not support a SOAP interface, then the provider ABCS sends the application context in an XACML request format to the adapter service that sets the appropriate security context needed for the security mechanism in use.

Figure 28-4 illustrates the provider application flow.

Figure 28-4 Provider Application Flow

28.7.3 Mapping Application Security Context in ABCS To and From Standard Security Context

The requester ABCS either receives the application security context in XACML format or converts it into XACML format. The requester ABCS calls an external service to map application security context to standard security context. The ABCS passes the application security context in XACML format and receives application neutral security context in XACML format.

28.7.4 Using the AppContext Mapping Service

AIA recommends using one external service per application. This service is also responsible for populating additional values needed in the standard or application context that is returned. This service can be implemented as XPath functions or web service with these names:

• Request TransformToAppContext (EBMHeader)

• Request TransformToAppNeutralContext (Request)

Example 28-4 shows a sample of the AppContextMappingService.

<definitions
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService"   
xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2"
          xmlns:xacml-context="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd" 
xmlns="http://schemas.xmlsoap.org/wsdl/"              
xmlns:tacs="http://www.oracle.com/AIA/AppContextTransformService"              
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"              
xmlns:xsd="http://www.w3.org/2001/XMLSchema"              
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">  
   <types>
   <xsd:schema 
targetNamespace="http://www.oracle.com/AIA/AppContextTransformService" 
elementFormDefault="qualified">
<xsd:import namespace="http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd" 
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/access_control-xacml-2.0-context-schema-cd-04.xsd" />
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2" 
schemaLocation="http://[HOST:PORT]/AIAComponents/EnterpriseObjectLibrary/Release2
/Core/Common/V2/Meta.xsd" />
</xsd:schema>
   </types>
   <message name="Request">
     <part name="Request" element="xacml-context:Request"/>
   </message>
   <message name="EBMHeader">
     <part name="EBMHeader" element="corecom:EBMHeader"/>
   </message>
   <portType name="TransformAppContext">
     <operation name="TransformToAppContext">
       <input message="EBMHeader"              name="EBMHeader"/>
       <output message="Request"/>
     </operation>
     <operation name="TransformToAppNeutralContext">
       <input message="Request"              name="Request"/>
       <output message="Request"/>
     </operation>
   </portType>
 </definitions>

This service is implemented for the participating application and meets any integration scenario using that application.

AIA recommends using BPEL with co-location to implement this service. ABCS should call this service using a dynamic partner link so that you can plug in other implementations of this service.

TransformAppContextService is the property used to load the service implementation from AIAConfig property file. By default this property is not configured and the default implementation is used.

The default implementation of this service is based on DVM and cross-reference. Whenever a new application or integration scenario is added, new DVM values must be populated but the service need not be changed.

28.7.5 Understanding the Structure for Security Context

The XACML Request element is used as the parameter to the app context structure. This request element carries participating application information and calling service information in addition to authorization information.

Figure 28-5 illustrates the structure of XACML Request.

Figure 28-5 Structure of XACML Request

Figure 28-6 illustrates the structure of XACML Subject.

Figure 28-6 Structure of XACML Subject

Figure 28-7 illustrates the structure of XACML Resource.

Figure 28-7 Structure of XACML Resource

Figure 28-8 illustrates the structure of XACML Action.

Figure 28-8 Structure of XACML Action

Figure 28-9 illustrates the structure of XACML Environment.

Figure 28-9 Structure of XACML Environment

Example 28-5 shows the SEBL AppContext information that is sent to the security service.

<AIAAppContext xmlns=http://www.oracle.com/AIA/AppContext>
  <ServiceInfo>
     <ServiceName>O2C2SeibelABCS</ServiceName>
  </ServiceInfo>
  <ParticipatingAppInfo>
     <Name>Siebel</Name>
     <Version>8.0</Version>
  </ParticipatingAppInfo>
  <Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:cd:04" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" 
urn:oasis:names:tc:xacml:2.0:context:schema:cd:04 
http://docs.oasis-open.org/xacml/access_
control-xacml-2.0-context-schema-cd-04.xsd">
     <Subject>
      <Attribute AttributeId="siebel:user" DataType="xs:string">
        <AttributeValue>SAdmin</AttributeValue>
      </Attribute>
      <Attribute AttributeId="siebel:org" DataType="xs:string">
        <AttributeValue>siebl1</AttributeValue>
      </Attribute>
     </Subject>
     <Resource>
     </Resource>
     <Action>
     </Action>
     <Environment/>
  </Request>
</AIAAppContext>

28.7.6 Using Attribute Names

Use these guidelines for attribute names:

• Service information attributes:

  AIA:Service:Name - Name of the service calling the transform service

• Participating application information attributes:

  AIA:ParticipatingApp:Name - Name of the participating application

  AIA:ParticipatingApp:Version - Version of the participating application

  AIA:ParticipatingApp:SystemID - unique identifier of participating application

• Application attributes:

  AIA recommends using this convention for naming the attributes for all the applications: Application name: attribute name.

• Application neutral attributes:

  AIA recommends using AIA as prefix for all the application neutral attributes. These are the application neutral attributes identified so far:

  User: to represent user

  BusinessUnit: to represent organization or operating unit

28.7.7 Propagating Standard Security Context through EBS and EBF

The standard security context is inserted into the Enterprise Business Message (EBM). As an EBM is propagated through various EBSs and EBFs to the destination ABCS, the security context is propagated along with the EBM to the target ABCS where it is used to propagate to the target application

28.7.8 Implementing Application Security Context

The following section provides the high level steps for implementing application security context on both the requester side and the provider side.