28 Working with Security
This chapter describes how to secure service endpoints for remote communication and application security context which is used for passing authorization context from the source application to the target application through the AIA layer.
This chapter includes the following sections:
28.1 Introduction to Oracle AIA Remote Security
By default all Oracle AIA services are secured. All adapter based services are security enabled using JNDI. All composite service and references using SOAP over http are secured using Oracle Web Services Manager (WSM).
You can override the security if the delivered security is not sufficient for your usecase.
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.
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 Implementing Security
This section includes the following topics:
28.2.1 Enabling Security for AIA Services
To enable security in AIA services:
-
Determine what type of security is needed.
AIA recommends using WS-security for authentication, encryption and integrity.
-
Check if the global security policy is sufficient for the web service.
-
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.
-
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.
-
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.
-
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.1.1 Should You Secure All AIA Services?
Security can have a negative impact in terms of performance so it must be carefully used. AIA mandates securing services whose interaction with other services cross organizational boundaries. Any AIA service that is being called from clients outside corporate network must be secured. For A2A integration where all the services are within the same organization and inside the firewall, you may decide it is not necessary to secure all the services.
All AIA services out of the box are secured, so if you think security is not needed for your deployment, you must disable.
28.2.2 Invoking Secured Application Services
To invoke a secured web service:
-
Determine what type of security is needed.
AIA recommends using WS-security for authentication, encryption and integrity.
-
Check if the global security policy is sufficient for the web service.
-
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.
-
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.
-
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:
-
Configure credential store.
-
Add the UserID and password associating with a key into the store.
-
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.
-
-
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:
-
Create service configuration file as described in section Section 28.6.3, "AIA Security Configuration Properties."
-
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>.
Example 28-1 <soap:Envelope> Content
<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 Security for Applications
This section contains the following topics:
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.
Example 28-2 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 Deploying Security Policies
AIA recommends applying policies globally rather than constraining policy attachment at the individual service level. The global policies are applied when the Foundation Pack is installed.
In some cases, it is imperative to override the globally attached client policies with directly attached local policies. General guidelines are given below.
-
Global Authentication Policies are delivered
-
Eliminates the need to define policies at the composite level.
-
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.
-
Global Service Client Policy applied: 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.
-
-
Assess your individual flow needs and harden the services if necessary.
Further hardening can be done by associating local policies.
-
Applications invoking secured AIA Web Services must send credentials.
-
Inter-AIA communication is handled by the Global Service Client Policy.
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
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 Policy Naming Conventions
This section includes the following topics:
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 How Does AIA Foundation Pack Help in Securing AIA Services?
AIA Foundation Pack automatically:
-
Creates the recommended global policy sets
-
Attaches the local policies for the composites when required.
This section includes the following topics:
-
Section 28.6.1, "What Default Policies are Attached to a Service?"
-
Section 28.6.2, "How Can the Global Policy be Overridden for an Individual 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.
Example 28-3 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>
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]/V1#wsdl.endpoint(<Service>/<Port>"
Ensure that the PortName provided by you here, is the same as <Port> in the composite.xml.
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 Application Security Context
This section includes the following topics:
-
Section 28.7.2, "How To Exchange Security Context Between Participating Applications and ABCS"
-
Section 28.7.3, "Mapping Application Security Context in ABCS To and From Standard Security Context"
-
Section 28.7.5, "Understanding the Structure for Security Context"
-
Section 28.7.7, "Propagating Standard Security Context through EBS and EBF"
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.
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.
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.
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.
Example 28-4 Example of AppContext Mapping Service
<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-6 illustrates the structure of XACML Subject.
Figure 28-7 illustrates the structure of XACML Resource.
Figure 28-8 illustrates the structure of XACML Action.
Figure 28-9 illustrates the structure of XACML Environment.
Example 28-5 shows the SEBL AppContext information that is sent to the security service.
Example 28-5 Example of SEBL AppContext information 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
-
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.
28.7.8.1 How to Implement Requester-Side Application Security Context
To implement requester-side application security context:
-
If an adapter is used, convert application security context information into XACML format in the adapter service.
-
If the application is sending information in data directly to the requester ABCS, convert the application's security context information to XACML format.
-
If new standard attributes are needed, work with internal architecture team.
-
Implement application context mapping service.
-
In the Requester ABCS, call the application mapping service to convert application specific app context information to application neutral app context information.
-
Call EBS.
28.7.8.2 How to Implement Provider-Side Application Security Context
To implement provider-side application security context:
-
Implement application context mapping service.
-
In the Provider ABCS, call application context mapping service to convert application neutral app context information to application specific app context information.
-
To send information in data directly to provider application, convert applications security context information from XACML data to required form.
-
If an adapter is used, convert application security context information from XACML format to the required form in the adapter service.