|
|
Oracle Data Service Integrator provides two types of security:
This chapter explains how you can configure and manage runtime security and access control for different users through the Oracle Data Service Integrator Administration Console. It contains the following sections:
To work with Oracle Data Service Integrator security features, you must first define and create users who will access the Oracle Data Service Integrator Administration Console. For more information about creating users, refer to Create Users in WebLogic Server Administration Console Online Help.
To secure Oracle Data Service Integrator artifacts you can create runtime security policies. Oracle Data Service Integrator artifacts or resources include dataspaces, services, operations, library procedures, and data elements.
For more information on runtime security policies, refer to Understanding Runtime Security Policies
After creating users in an Oracle Data Service Integrator-enabled WebLogic Server domain, you can control administrative access of these users by applying administrative access control policies. Access control on Oracle Data Service Integrator Administration Console is based on user entitlements. Entitlements are assigned to users by a domain user, who is a super user for a particular domain. A domain user is created when you create an Oracle Data Service Integrator domain and specify the user name and password for it.
For more information on administrative access control, refer to Working with Administrative Access Control Policies.
The runtime security feature enables you to configure access to resources such as dataspaces, data services, operations, and data elements. For a secured resource, a requesting client must meet the condition of the runtime security policy applicable to that resource, whether accessing the resource through the typed mediator API, an ad hoc query, or any data access interface. Oracle Data Service Integrator exposes its deployed artifacts as resources that can be secured through runtime security policies.
For example, you can control access to an entire Oracle Data Service Integrator dataspace or just to a credit card number element within Customer_Order.ds.
When a request comes to a running Oracle Data Service Integrator instance for a secured resource, Oracle Data Service Integrator passes an identifier for the resource to WebLogic Server. WebLogic Server, in turn, passes the resource identifier, user name, and other context information to the authorization provider, such as XACMLAuthorizer. The provider evaluates the policy that applies to the resource. As a result of the evaluation, access to the resource is either permitted or blocked.
If the user does not satisfy the requirements of an element-level policy, the element is redacted from the result object, and therefore does not appear.
| Note: | By default, WebLogic Server security uses the XACML Authorization Provider. Other authenticators can use any external resource necessary to implement the policy evaluation. |
A securable resource is an Oracle Data Service Integrator artifact, such as a data service, operation, or element, to which you can apply a runtime security policy. The resources you can protect using runtime security include:
After you secure individual resources, you can enable or disable security for the dataspace. Security policies are inherited. This means that security enabled at the dataspace level applies to all data services, operations, and elements within the dataspace.
However, if several policies apply to a particular resource, the more specific policy prevails. For example, a policy on an element supercedes a policy for the data service.
The hierarchy of Oracle Data Service Integrator artifacts is as follows:
Figure 5-2 illustrates the securable resources in an Oracle Data Service Integrator dataspace.
At the dataspace level, you can enable anonymous access by creating a policy. If you apply this policy, all users, including unauthenticated users, can access resources by default. For more information on creating runtime policies at the dataspace level, refer to Configuring Dataspace-Level Security.
The anonymous access policy works only with the WebLogic Authorization provider. The Oracle Data Service Integrator security policies are intended to work with the default WebLogic Authorization provider. If you are using another authorization provider, you will need to create policies using the facilities of the other provider. For more information, see WebLogic Authorization Provider: Provider Specific in the Administration Console Online Help.
The Security Configurations tab on Oracle Data Service Integrator Administration Console provides the configurable runtime security policies. Setting up runtime security in Oracle Data Service Integrator Administration Console involves the following tasks:
Oracle Data Service Integrator directly supports runtime security policies for its resources. The WebLogic Platform supports extensive security features that can be applied to your implementation as well, including encryption-based, transport-level security. For runtime security configuration, Oracle Data Service Integrator provides the following policies, called predicates, in Oracle Data Service Integrator Administration Console:
The security policies in the Oracle Data Service Integrator Administration Console are similar to the conditions used by WebLogic Server security. For more information on WebLogic Server security policies and conditions, refer to Securing WebLogic Resources Using Roles and Policiesin the WebLogic Server documentation.
In addition to creating runtime security policies, you can create service accounts to map security configurations of external data sources such as web services and Java functions. This feature ensures secure storage of the credentials of external data sources and allows runtime identity mapping.
Before you start creating and applying runtime policies, make sure that the Enable Access Control checkbox in the General tab is selected, as shown in Figure 5-3. This activates the security policy configurations. If access control is not selected, then security is not enabled for your dataspace. The General tab is available only at the dataspace level.
The steps to create and apply runtime security policy for a dataspace, data service, and operations are the same. However, you must make sure that you select the Oracle Data Service Integrator resource from the navigation pane. To create and apply the runtime security policy:
| Note: | If you select the User predicate, it implies that you are allowing a particular user to access the dataspace. Make sure that this user is authenticated by WebLogic Server. |
You can configure runtime policies that would ensure access to users who are assigned entitlements to access the entire dataspace. At the dataspace level, the Security Configuration tab provides the following tabs:
| Note: | If an access policy is time-dependent or is changed and the metadata access control option is enabled, you may not be able to access the tables and procedures that had been listed. |
For more information, refer to Exporting Access Control Resources.
If a third-party authorization provider is used, then this tab displays a message as follows:
“Policies for Oracle Data Service Integrator domain have to be defined in the configured external policy provider.”
For more information about creating and applying security policies, refer to Creating and Applying Runtime Security Policies.
Service accounts enable you to create a mapping between local WebLogic users and remote external data source users. This enables you to use Oracle Data Service Integrator to store user credentials to external data sources. You can create service accounts using Oracle Data Service Integrator Console.
You can assign service accounts to physical sources such as delimited files, Java functions, web services, and XML files using the Oracle Data Service Integrator Console
| Note: | You do not need to assign service accounts to physical sources based on relational databases. Oracle Data Service Integrator uses built-in support in WebLogic Server to provide JDBC identity mapping between local WebLogic users and remote data source users. |
You can use the Oracle Data Service Integrator Console to assign the following types of service accounts to physical sources:
For a web service-based data source any of the following combinations are acceptable. (The list is not exhaustive.)
To specify the service account for a physical source:
You can specify service accounts for delimited files, Java functions, web services, and XML files.
XQuery security functions allow data-driven security of Oracle Data Service Integrator resources. At the dataspace level, you can create and maintain XQuery functions to ensure that data elements are returned only when the conditions are met. However, to associate these functions to data service elements, go to the data service and specify the element for which the function applies.
| Note: | If both a standard security policy and an XQuery function applies to a given data element, the results of both policy evaluations must be true for access to be permitted (logical and is applied to the results). |
Applying data-driven security policies involves the following steps:
You can create one or more XQuery functions to apply to data elements within a dataspace.
To create an XQuery function for security:
import schema namespace t1 = 'ld:DataServices/CUSTOMER_ORDER' at
'ld:DataServices/Schema/CUSTOMER_ORDER.xsd';
declare namespace f1 = "ld:CUSTOMER_ORDER";
declare function f1:secureOrders($order as
element(f1:CUSTOMER_ORDER)) as xs:boolean {
if (fn-bea:is-access-allowed("CUSTOMER_ORDER/LimitAccess",
"ld:CUSTOMER_ORDER.ds")) then
fn:true()
else if ($order/TotalOrderAmount lt
(fn-bea:get-property("total_order_amount", "1000000") cast as
xs:decimal)) then
fn:true()
else
fn:false()
};
Notice that the function uses the Oracle extension XQuery function is-access-allowed(). This function tests whether a user associated with the current request context can access the specified resource, which is denoted by an element name and a resource identifier.
Oracle Data Service Integrator provides the following additional convenience functions for security purposes:
is-user-in-group ($arg as xs:string) as xs:boolean Checks whether the current user is in the specified group.
is-user-in-role ($arg as xs:string) as xs:boolean Convenience method that checks whether the current user is in the specified role.
userid() as xs:string Returns the identifier of the user making the request for the protected resource.
| Note: | For details on creating XQuery functions, see the XQuery and XQSE Developer’s Guide. |
| Note: | A security XQuery function must be applied to a data element for it to take effect. For more information, see Applying an XQuery Function for Security on page 5-16. The functions are applied to elements by qualified function name. The only requirement for the function is that it returns a Boolean value and that the name should be qualified by a namespace URI. |
You can use XQuery functions for security to control access to data elements. After you define the XQuery function for security, as described in Creating an XQuery Function for Security on page 5-14, you must apply the function to the corresponding data element for it to take effect. In addition, you define policies for securing the data elements, which provide additional security along with the XQuery functions for security. For more information, refer to Configuring Data Element-level Security.
To make any changes to the security configurations of a data element, you must first acquire the lock by clicking Lock & Edit. To apply the XQuery function for security to a data element:
This option allows you to assign a constant value for the element or attribute. However, it supports only primitive types, so you cannot have a default value for complex types.
| Note: | If you select this check box, then it is mandatory to specify the default value for the resource. |
Data redaction is the process of obscuring or removing information from a data result prior to displaying the result. Oracle Data Service Integrator offers the following forms of data redaction for secured elements and attributes:
The first two forms map originally distinct fields in multiple data instances to the same redacted representation. This means that these methods are not suitable for certain applications, such as data analytics, which require that fields maintain their identity so that standard operations such as GroupBy or Join can be performed based on the fields.
The third form, encrypting the data, preserves the identity of the field enabling you to perform a wider range of operations on the data. Oracle Data Service Integrator offers secure encryption-based data redaction that you can use to encrypt elements in the results of read and navigate functions declared in entity data services.
The following describes the conditions related to selecting a data redaction option:
You can specify the redaction behavior for data elements to secure information against unauthorized access.
To specify the redaction behavior for a data element:
This section provides several examples showing how encryption-based data redaction works when performing common operations.
The examples in this section make use of the following data services:
Entity data service CustomerDS—The data service returns information about a customer conforming to the following schema:
CUSTOMER
SSN: xs:string
FIRST NAME: xs:string
LAST NAME: xs:string
CUSTOMER_SINCE: xs:date
The information is exposed through the public read function getCUSTOMERS(), which returns data similar to the following:
<SSN>123-45-6789</SSN>
<FIRST_NAME>John</FIRST_NAME>
<LAST_NAME>Smith</LAST_NAME>
<CUSTOMER_SINCE>2007-10-10</CUSTOMER_SINCE>
</CUSTOMER>
Entity data service OrderDS—The data service returns information about a customer order conforming to the following schema:
ORDER
ORDER_ID: xs:integer
CUSTOMER_SSN: xs:string
DATE: xs:date
STATUS: xs:string
The information is exposed through the public read function getORDERS(), which returns data similar to the following:
<ORDER>
<ORDER_ID>1000</ORDER_ID >
<CUSTOMER_SSN>123-45-6789</CUSTOMER_SSN>
<DATE>2007-10-10</DATE>
<STATUS>CLOSED</STATUS>
</ORDER>
<ORDER>
<ORDER_ID>2000</ORDER_ID >
<CUSTOMER_SSN>123-45-6789</CUSTOMER_SSN>
<DATE>2007-11-11</DATE>
<STATUS>OPEN</STATUS>
</ORDER>
This section provides examples of encryption-based data redaction.
Projection of an Encrypted Field
Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS, the direct function call getCUSTOMERS() returns the following:
<CUSTOMER>
<SSN>sjdlkggdlaklakskjfgk</SSN>
<FIRST_NAME>John</FIRST_NAME>
<LAST_NAME>Smith</LAST_NAME>
<CUSTOMER_SINCE>2007-10-10</CUSTOMER_SINCE>
</CUSTOMER>
Note that the value of the SSN field is encrypted and unique for each distinct SSN.
Predicate Against an Encrypted Field
Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS, the following XQuery query returns ():
for $x in p:getCUSTOMERS()
where $x/SSN eq "123-45-6789"
return $x
This is because a match is attempted between an unencrypted value and the encrypted SSN value.
Outer Join on Encrypted Fields
Consider the following XQuery query that performs an outer join:
for $x in p:getCUSTOMERS()
return
<CUSTOMER>
<SSN>{fn:data($x/SSN)}</SSN>
{
for $y in q:getORDERS()
where $x/SSN eq $y/CUSTOMER_SSN
return
<ORDER_ID>{fn:data($y/ORDER_ID)}</ORDER_ID>
}
</CUSTOMER>
Assuming that encryption-based data redaction has been configured for both the SSN field in CustomerDS and the CUSTOMER_SSN field in OrderDS, the query returns the following:
<CUSTOMER>
<SSN>sjdlkggdlaklakskjfgk</SSN>
<ORDER_ID>1000</ORDER_ID >
<ORDER_ID>2000</ORDER_ID >
</CUSTOMER>
Notice that the outer join is performed as if encryption was not set. Note also that the value of the secured element in the result is encrypted.
Join Encrypted Field With Non-Encrypted Field
Assuming that encryption-based data redaction has been configured for the SSN field in data service CustomerDS but not on data service OrderDS, consider the following XQuery query that joins an encrypted field with a non-encrypted field:
for $x in p:getCUSTOMERS()
return
<CUSTOMER>
<SSN>
{fn:data($x/SSN)}
</SSN>
{
for $y in q:getORDERS()
where $x/SSN eq $y/CUSTOMER_SSN
return
<ORDER_ID>
{fn:data($y/ORDER_ID)}
</ORDER_ID>
}
</CUSTOMER>
Note that the outer join fails to return any results because the encrypted value of SSN does not match the non-encrypted value of CUSTOMER_SSN.
Consider the following SQL query that includes a group by clause:
SELECT CUSTOMER_SSN, COUNT(*y)
FROM ORDERS
GROUP BY CUSTOMER_SSN
Assuming that encryption-based data redaction has been configured for the CUSTOMER_SSN field in data service OrderDS and the getOrders() function has been mapped to the SQL table ORDERS, the SQL query returns the following:
(sjdlkggdlaklakskjfgk, 2)
Notice that the group by clause performs as if encryption was not set. Note also that the value of the secured column in the result is encrypted.
Service accounts provide the option to store user credentials for external data sources. It provides a mapping between the local WebLogic user and a remote external data source user by configuring the user credentials within the Oracle Data Service Integrator Administration Console.
You can configure service accounts for web services and Java functions. For JDBC identity mapping, Oracle Data Service Integrator depends on Oracle WebLogic Server built-in support.
Service accounts provide different types of mappings, which include:
| Note: | After you create and define the type of a service account, you cannot change it. If you have to change a service account type, delete the account and create a new one. |
| Note: | Based on the selected resource type, the Next button is enabled. |
On this page, you can define the remote (external data source) users.
On this page, you can define the authorized remote (external data source) users, and add them as authenticated external data source users.
Authorization is the process whereby the interaction between users and resources are limited to ensure integrity, confidentiality, and availability. WebLogic uses resource identifiers to identify deployed Oracle Data Service Integrator artifacts, such as dataspaces, data services, and operations. This identifier is used to associate a client request to any security policies configured for the requested resource.
Resource identifiers are managed for you when you use the default WebLogic Authorization provider and the Oracle Data Service Integrator Administration Console to configure your policies. In particular, resource identifiers already exist for Oracle Data Service Integrator dataspaces, data services, and data service operations. In addition, when you choose elements to be secured in the console, an identifier is generated for the element.
However, when using a custom authorizer, you must know the resource identifiers for your deployment and configure policies for the resources in the form expected by the other authorization module. This means that you need to identify the element resources that need to be protected.
| Note: | The WebLogic security documentation provides details on how to connect another security authenticator to WebLogic Server. For more information, see WebLogic Authorization Provider in the Administration Console Online Help. |
You can view the list of resource identifiers by exporting the access control resources from the Oracle Data Service Integrator Administration Console.
An example of a portion of the file follows:
<ld type="admin"><app>DOMAIN</app></ld>
<ld type="admin"><app>ADMIN</app></ld>
<ld type="admin"><app>MONITOR</app></ld>
<ld type="admin"><app>BROWSER</app></ld>
<ld type="admin"><app>ADMIN</app><ds>DSP_TEST</ds></ld>
<ld type="admin"><app>MONITOR</app><ds>DSP_TEST</ds></ld>
<ld type="admin"><app>BROWSER</app><ds>DSP_TEST</ds></ld>
<ld type="app"><app>DSP_TEST</app></ld>
<ld type="service"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}CREDIT_CARD:0</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}createCREDIT_CARD:1</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}deleteCREDIT_CARD:1</res></ld>
<ld type="function"><app>DSP_TEST</app><ds>ld:CREDIT_CARD.ds</ds><res>{ld:CREDIT_CARD}updateCREDIT_CARD:1</res></ld>
<ld type="service"><app>DSP_TEST</app><ds>ld:CUSTOMER.ds</ds></ld>
The format of a resource identifier is shown in Figure 5-13.
The type can be admin, service, or function. The resource can be any of the following:
These are generated when you select an element in the Secured Element tab of the Oracle Data Service Integrator Administration Console.
A data service has several operations, including one or more read, create, update, delete, navigation, and library operations. The security policies that you apply at the data service level apply to data service operations and data elements. You can also select the data elements that you want to secure at the data service level.
Operation-level security policies enable you to control:
| Note: | Make sure that you configure policies on the data service resources that are accessed directly by the user. Security policies on data services that are used by other data services are not inherited by the calling data service. This means that if a data service with a secured resource is accessed through another data service, the policy is not evaluated against the caller. For more information, refer to Creating and Configuring Security Policies for Operations. |
| Note: | Data service operations are identified by name and number of parameters for setting security configurations. If you modify the number of parameters, you will need to reconfigure the security settings for the operation. |
The steps to create the security policy at the data service and operation level are the same as the dataspace level. Refer to Creating and Applying Runtime Security Policies for details.
At the data service level, you can select all the data elements in a data service by selecting the top-level element (Customers in Figure 5-14) or individual data elements that you want to secure using the Secured Elements tab.
For example, if you create an XQuery function for security and you want to associate it with a data element, you can select the data element from the Secured Elements tab and then configure the data-element level security. (For more information about XQuery function for security, refer to Working with XQuery Functions for Security.)
| Note: | You should only secure the root element of a data service if you are confident that none of the elements used by read functions in the service must return a value. Since a secured element does not return a value, a schema which requires that one or more values be returned will fail with a runtime error. Alternatively, you can modify the schema so that elements are optionally returned. |
To select the data element to be secured:
To apply security policy to the data element, select the element from the navigation tree. You can also select the secured element using the Secured Elements tab. For more information, refer to Configuring Data Element-level Security.
Using the Oracle Data Service Integrator Administration Console, you can select the data elements that you want to secure at the data service level. When selecting a complex node, Oracle Data Service Integrator further enables you to optionally cascade the selection to all child elements and attributes of the complex node.
To select a complex node and cascade the selection:
| Note: | The cascade functionality is just a user interface usability feature. All the elements secured in this way are still independent of the parent element. You will have to configure security policies, redaction modes for all of them separately. |
To set runtime security policy for an operation:
This setting ensures that every time this operation is accessed, the runtime policy is adhered to. Consider the following example:
In this scenario, if you access fn1 using user1, then access will be denied because the runtime security policy configuration does not allow user1 to access fn2.
If you do not select the Always Secured check box for fn2, then you will be able to access fn1 if using either user1 or user2 because the system will check the security policy for fn1 only and not fn2.
Element-level security associates a security policy with a data element for the Return type within a data service. If the policy condition is not met, the corresponding data is not included in the result.
When configuring element-level security, you first identify the element as a securable resource, then set a policy on the resource.
The data element security policy can be configured using the steps described in Creating and Applying Runtime Security Policies.
To associate an XQuery function for security with a corresponding data element, select the Secured Elements Configuration tab and follow the steps mentioned in Applying an XQuery Function for Security.
| Note: | Element-level security is only applied when all of the following conditions are met: |
To ensure the security of elements, you need to manage and layer data services properly. This means being careful not to create insecure holes in the layers and not depending on security settings for data services which are not being directly invoked by the client.
| Note: | Secured elements, in general, should never offer public read or navigate functions that accept a secured element value as an input argument as this can permit guessing-style attacks to reveal otherwise secure data. |
You can set the security policies for native web services using the Basic Auth Required property in the Eclipse IDE. You can create runtime security policies for a native web service and then set this property to true. This applies the security policy for the native web service. For more information about the Basic Auth Required property, refer to the Add Security Resources to Data Services topic in the Designing Logical Data Services section of the Data Services Developer’s Guide.
The Service Explorer in Oracle Data Service Integrator Administration Console allows you to check if the Basic Auth Required property is set to true or false.
To view information about this property in the Service Explorer:
User-defined security resources are created in the Eclipse IDE Property Editor, as shown in Figure 5-17.
For more information about setting the security resource values, refer to Declare a Security Resource in Data Services Developer’s Guide.
After you assign a value to the security resource, you can create runtime security policies for the user-defined security resource. In the preceding figure, ordertime is the value of the security resource. After you deploy the dataspace, this resource is displayed in Oracle Data Service Integrator Administration Console. Figure 5-18 shows the ordertime security resource in the navigation tree for the customerorder data service.
You can create a runtime security policy for the ordertime security resource using the console.
Administrative roles require entitlements to access Oracle Data Service Integrator Administration Console. These entitlements can be assigned through the Administrative Access Control category, as shown in Figure 5-19.
A domain user, who is the super user for the console, assigns entitlements to users. In addition to the domain entitlement, other predefined entitlements are admin, monitor, and browser, which allow access to information for different categories and resources. The hierarchical structure of the entitlements is as follows:
This hierarchy implies that the domain entitlement allows you to perform all the tasks on Oracle Data Service Integrator Administration Console, depending on whether the domain entitlement is for all the dataspaces within a domain or a particular dataspace. However, other entitlements cannot perform all the tasks that can be performed by a user with domain entitlement.
For example, you can set the administrative access control policies only if you have domain entitlement. Similarly, the admin entitlement allows you to perform more tasks on a dataspace than monitor or browser entitlements.
| Note: | Entitlements can be assigned at the dataspace level or for all the dataspaces. For example, for User A, you can assign admin entitlement for DS1, monitor entitlement for DS2, and browser entitlement for DS3. Alternatively, you can assign the Admin entitlement for all the dataspaces within the domain to User A. For more information, refer to Assigning Entitlements. |
A default domain user is created on WebLogic Server when you create the Oracle Data Service Integrator domain. There can be more than one domain user for the console and one domain user can create other domain users.
| Note: |
By default, an Admin role is created for a domain user in Oracle Data Service Integrator Administration Console which is mapped from WebLogic Server Administrator role, as shown in Figure 5-19.
Table 5-3 lists the tasks that can be performed by a user for each entitlement.
Entitlements are created for users that are created on WebLogic Server 10gR3 and can be managed through the WebLogic Server Administration Console.
You can also assign an entitlement to a user for all dataspaces within the domain. For example, if you want to assign the Admin entitlement for dataspaces DS1, DS2, and DS3 to a user, then select the Admin entitlement option. Similarly, you can assign, monitor and browser entitlements to a user for all dataspaces by selecting the Monitor or Browser option from the navigation tree.
| Note: | In this case, the Admin entitlement is selected for the dataspace DS1. |
| Note: | You can also select other options from the list of predicates. For more information, refer to Understanding Runtime Security Policies. |
A user views the category-list based on the entitlement assigned to that user for that dataspace. For example, User A with admin entitlement for DS1 can view the Security Configurations tab, however, if User A has monitor entitlement for DS2, then the Security Configuration tab for DS2 will not appear for User A.
Security policies configured for assigning Admin entitlement to a user may get deleted inadvertently. If that is the only Admin user entitlement for Oracle Data Service Integrator Administration Console, then the Admin user is locked out of the console.
In this case, you can configure the com.bea.dsp.security.admin.bootstrap system property for WebLogic Server. This property allows you to specify a user name, who gains domain access rights. However, this property should only be used if the Oracle Data Service Integrator Administration Console is locked due to some policy editing.
To configure this system property:
setDomainEnv.cmd file located in: <BEA_HOME>\user_projects\domains\
base_domain\bincom.bea.dsp.security.admin.bootstrap system property. For example:set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES%-Dwlw.iterativeDev=%iterativeDevFlag%
-Dwlw.testConsole=%testConsoleFlag%
-Dwlw.logErrorsToConsole=%logErrorsToConsoleFlag%
-Dcom.bea.dsp.security.admin.bootstrap=<username>where <username> is the place to specify the Admin user for Oracle Data Service Integrator Administration Console.
| Note: | The user name specified in the com.bea.dsp.security.admin.bootstrap system property should be a user that has already been created using the WebLogic Server Administration Console. |
A domain user can take back the control of the lock from Oracle Data Service Integrator Administration Console. The lock may need to be taken back from a user in cases where a user, such as an admin user, has acquired the lock but has not released it for a long period and another admin user needs to acquire the lock to modify configurations. One domain user can acquire the lock from another domain user also.
When lock is acquired by a user, the Take Lock & Edit option is enabled for the domain user as shown in Figure 5-21.
The domain user can click the Take Lock & Edit option from the change center to acquire the lock. In this case, the user whose lock is acquired will see the core configuration values on the console and the domain user or the other admin user will be able to view all the changes made by the other user using the pending changelist. For more information about pending changelist, refer to “Pending Changelist” on page 2-11.
|