Introduction to Application Security How To Exchange Security Context Between Participating Applications and ABCS

Working with Security 26-11 Param paramName=csf-keyAPPSHORTNAME_ServiceName_PortTypeNameParam 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.

26.7 Application Security Context

This section includes the following topics: ■ Section 26.7.1, Introduction to Application Security ■ Section 26.7.2, How To Exchange Security Context Between Participating Applications and ABCS ■ Section 26.7.3, Mapping Application Security Context in ABCS To and From Standard Security Context ■ Section 26.7.4, Using the AppContext Mapping Service ■ Section 26.7.5, Understanding the Structure for Security Context ■ Section 26.7.6, Using Attribute Names ■ Section 26.7.7, Propagating Standard Security Context through EBS and EBF ■ Section 26.7.8, Implementing Application Security Context

26.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. Tip: In the composite.xml, for the binding.ws of the reference element, the attribute port takes value of the following form. binding.ws port=[namespace of the service as defined in the wsdl]V1wsdl.endpointServicePort Ensure that the PortName provided by you here, is the same as Port in the composite.xml. 26-12 Developers Guide for Oracle Application Integration Architecture Foundation Pack 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 26–2 illustrates the high-level security functional flow. Figure 26–2 Security Functional Flow

26.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. Working with Security 26-13

26.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 26–3 illustrates the requester application flow. Figure 26–3 Requester Application Flow

26.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 26–4 illustrates the provider application flow. 26-14 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 26–4 Provider Application Flow

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