25.5 Adding and Managing Policy Resource Definitions

Protecting resources requires an Application Domain containing definitions of the specific resources.

With OAM, you can protect different types of resources, including non-HTTP/HTTPS-based resources and HTTP/HTTPS-based resources such as:

An entire external Web site
Specific pages in a Web site
Partner portals
A parts order application
Invoice applications
A benefits enrollment application on Web servers of an enterprise in many countries

Once you have defined a resource in this container, you can add it to a policy in the Application Domain. This section provides the following topics:

25.5.1 Resources in an Application Domain

Each resource must be defined separately in an Application Domain. Within an Application Domain, resource definitions exist as a flat collection of objects. Each resource is defined as a specific type, and the URL prefix that identifies the resource (document or entity) stored on a server and available for access by a large audience.

The location is specified using an existing shared Host Identifier.

Note:

If a resource that is not explicitly marked as excluded, is not associated with a policy, then access is denied to all users because there is no policy match.

Resource Definition Guidelines

No URL prefixes. Resource definitions are treated as complete URLs.
Pattern matching (with limited features) for:

' * ' and '...' are supported
Resources need not be unique across domains.
Query-string protection for HTTP URLs.
Each HTTP resource is defined as a URL path, and associated with a host identifier. However, resources of other types are associated with a specific name (not a host identifier).
Non-HTTP resource types are supported, with definition of specific operations. Non-HTTP resource types are never associated with a host identifier.
Resources can designated as either Protected, Unprotected, or Excluded.
Custom resource types are allowed.

Figure 25-10 illustrates the Create Resource page.

Figure 25-10 Create Resource Page in the Application Domain

Description of "Figure 25-10 Create Resource Page in the Application Domain"

Table 25-1 describes elements that comprise a resource definition.

Table 25-1 Resource Definition Elements

Elements	Description
Type	The `HTTP` type is the default; it covers resources that are accessed using either the HTTP or HTTPS protocol. Policies that govern a particular resource apply to all operations defined for the resource. The `wl_authen` resource type is used for Fusion Middleware application scenarios, as described in the Securing Applications with Oracle Platform Security Services. The `TokenServiceRP` resource type is used to represent the Token Service Relying Party as described in "Managing TokenServiceRP Type Resources". Any custom resource type that has been defined is listed with default resource types when you add a resource definition (or search for resources). See Also: "Resource Type in a Resource Definition".
Description	An optional unique description for this resource.
Host Identifier	A list of host identifiers is available, which contains all identifiers that were defined as a shared component. You must choose a host identifier to assign this resource. Note: The combination of the host identifier and URL string that make up a resource definition must be unique across all Application Domains. See Also: "Managing Host Identifiers".
URI Section	Information will differ depending on the selected Resource Type.
Query Name-Value list	For HTTP resource types only. You can provide a list of Name and Value pairs for use in access policies. See Also: "Query String Name and Value Parameters for Resource Definitions".
Query String	For HTTP resources, you can provide a query string for literal full query string matching within access policies. See Also: "Literal Query Strings in Resource Definitions".
Resource URL	The value must be expressed as a single relative URL string that represents a path component of a full URL composed of a series of hierarchical levels separated by the '/' character. The URL value of a resource must begin with / and must match a resource value for the chosen host identifier. Based on its contents, a URL is matched in response to an incoming request as a literal or a wild card pattern. The special characters available to define a pattern, if included, are: The asterisk (*) is allowed only at the lowest, terminating level of the path. The asterisk matches zero or more characters. An ellipses (…) is allowed at any level of the path except the terminating level. The ellipses represents a sequence of zero or more intermediate levels. See Also Table 25-2.
Operations Section	You can define specific allowed operations to customize you own resource definitions. Note: Oracle-provided Resource Types are read-only. Operations associated with Oracle-provided Resource Types need not be defined and cannot be modified. Policies developed and applied to resources of Oracle-provided types apply to all operations.
Operations Available	Identify all HTTP operations that are allowed for this resource definition. Policies developed and applied to this customized resource apply to only the operations you identify. Unless explicitly noted, all of the following possible operations are for HTTP resource types: Connect Options Put Post Trace Head Delete Connect Login (wl_authen resource type only) Issue (TokenServiceRP resource type only) Note: During Agent registration, if no operation is specified for the resource definition itself, then All operations for that resource type are supported. See Also: "Resource Types and Their Use".
Protection	Using the controls in this section of the Resource Definition, you can identify the desired level of protection for this resource and name the policies to be used.
Protection Level	Choose the appropriate protection level from the following: Protected (the default) Protected resources are associated with a protected-level Authentication policy that uses a variety of authentication schemes (LDAP, or example). Authorization policies are allowed for protected resources. Responses, conditions, auditing, and session management are enabled for protected resources using a policy that protects the resource. Unprotected Unprotected resources are associated with an unprotected-level Authentication policy (level 0) that can use a variety of authentication schemes (LDAP, for example). Authorization policies are allowed for unprotected resources, and a basic one is needed to allow such access. However, an elaborate policy with conditions and responses is irrelevant. Responses, conditions, and auditing are enabled for Unprotected resources using a policy that protects the resource. Only Session Management is not enabled. Access to Unprotected resources incur an OAM Server check from Webgate, which can be audited. Excluded (these are public) Only HTTP resource types can be excluded. Typically security insensitive files like Images (.jpg, .png), protection level Excluded resources do not require an OAM Server check for Authentication, Authorization, Response processing, Session management, and Auditing. Excluded resources cannot be added to any user-defined policy in the console. While allowing access to excluded resources, Webgate does not contact the OAM Server.Therefore, such access is not audited. Most regular resource validations apply to Excluded resources. However, excluded resources are not listed when you add resources to a policy. There is no Authentication or Authorization associated with the resource.
Authentication Policy	A list of Authentication policies based on the specified resource protection level becomes available. Only policies within this domain, and that match the specified protection level, are listed.
Authorization Policy	A list of authorization policies defined in the domain become available from which you can choose the one to protect this resource.

After adding the resource, it is grouped under the Resources node of the named Application Domain. When you create policies all defined resources for the domain are listed and you can choose one or more for inclusion in the policy.

For more information about different specifications within a resource definition, see the following topics:

25.5.1.1 Resource Type in a Resource Definition

When adding a resource definition to an Application Domain, Administrators must choose from a list of defined Resource Types. Native Resource Types are read-only cannot be modified or deleted; these include HTTP, TokenserviceRP, and wl_authen.

See Also:

"Resource Types and Their Use"

When adding an HTTP type resource to an Application Domain, Administrators choose from a list of existing host identifiers and then add the resource URL. Operations associated with the HTTP resource type need not be defined by an Administrator. Instead, policies apply to all HTTP operations.

Table 25-2 shows sample URL values for resources. For more information, see "Resource URL, Prefixes, and Patterns".

Table 25-2 HTTP Resources Sample URL Values

Resource	Sample URL Values
Directories	/mydirectory /mydirectory/**
Pages	/mydirectory/projects/index.html /mydirectory/projects/.html /mydirectory/.../.html
Web applications	/mydirectory/projects/example.exe /mydirectory/projects/.exe /mydirectory/*

25.5.1.2 Host Identifier in a Resource Definition

Administrations identify resources in an Application Domain by the host where the resources reside and the resource URL.

Note:

Non-HTTP resource types are not associated with a host identifier. Instead, Administrators must enter the type's name into the Resource URL field of the resource definition page.

Host identifiers create a context for each resource, which is useful when adding resources that have the same URL paths on different computers. Administrations can protect all of these resources in the same way within the same Application Domain. The only variable that distinguishes one set of resources from another is identification of its host computer.

All defined host identifiers appear on the Host Identifiers list on the Resources page. When adding a resource to an Application Domain, administrations must choose one host identifier for the computer hosting the resource.

To ensure that Access Manager recognizes the URL for a resource, Access Manager must know the various ways used to refer to that resource's host computer.

25.5.1.3 Resource URL, Prefixes, and Patterns

During automated Application Domain generation, a URL prefix is defined under which all resources are protected. The Access Manager policy model does not support a resource prefix. Administrators can create granular URL patterns.

Resources are linear, not hierarchical. Resource definitions are treated as complete URLs.

Note:

No host identifier is associated with a non-HTTP resource type.

Administrations identify individual resources in the Application Domain using a specific resource URL. Individual resource URLs need not be unique across domains. However, the combination of a resource URL, Query String, and a host identifier must be unique across domains.

An HTTP type resource is expressed as a single relative URL string representing a path. The string is composed of a series of hierarchical levels separated by the '/' character. Based on its content, a URL is matched in response to an incoming request as a literal or a wild card pattern.

URL Prefixes

The Access Manager policy model does not support a resource prefix. In other words, there is no policy inheritance.

If a policy is defined for /mydirectory/projects/, it only applies to this URL (and does not apply to /mydirectory/projects/index.html, for example).

If you need a policy for all resources with the same prefix string, you can define the resource using special characters (three periods ... (ellipsis) or * (asterisk) for instance: /mydirectory/projects/.../*.

Note:

There is no policy inheritance in the Access Manager policy model.

URL Patterns, Matching, and Precedence

The granular URL patterns specify the fine-grained portion of a resource's namespace. All matching is case insensitive.

Supported wildcard matching is provided for the patterns in Table 25-3
Sample Resource URLs and their correctness are shown in Table 25-4

Table 25-3 Supported Wildcards in Resource URL Patterns (Precedence Order)

Pattern	Description	Example
/**	The default. Matches any sequence of zero or more characters that starts with the forward slash character (/). You can use this pattern to protect a path under a specific, named directory. Note: This is not an existing 10g wildcard. In 10g, the /.../* pattern yielded an exclusive match that did not include the root of the level at which the pattern was defined. For example, /foo/.../* matched /foo/bar and the root directory /foo/ itself, but it wouldn't match foo/ or /foo. 10g had the notion of a prefix (the "root"), and most evaluation occurred after striping off the prefix.	· /** Matches /foo/bar /foo/
Literals	The resource's pattern contains no special characters.
{pattern1,pattern2,...}	Matches one from a set of patterns. The patterns inside the braces can themselves include any other special characters (except braces; sets of patterns cannot be nested).	a{ab,bc}b matches aabb and abcb. a{x*y,y?x}b matches axyb, axabayb, ayaxb, and so on.
[range or set]	Matches one from a set of characters. A set can be specified as a series of literal characters or as a range of characters. A range of characters is any two characters (including -) with a hyphen (-) between. A range of characters is any two characters (including -) with a hyphen (-) between them. The forward slash character (/) is not a valid character to include in a set. A set of characters will not match / even if a range that includes / is specified.	[nd] matches only n or d. [m-x] matches any character between m and x, inclusive. [--b] matches any character between - and b inclusive (except for /; see /usr/pub/ascii for order of punctuation characters). [abf-n] matches a, b, and any character between f and n, inclusive. [a-f-n] matches any character between a and f inclusive, -, or n. (The second - is interpreted literally because the f preceding it is already part of a range.)
Single Character Wildcard ?	The ? (question mark) matches any one character other than /. This is not treated as a query string delimiter.	a?b matches aab and azb but not a/b.
Wildcard *	The * (asterisk) wildcard matches any sequence of zero or more characters. However, the * (asterisk) does not match the forward slash character (/).	a*b matches ab, azb, and azzzzzzb but not a/b.
*	The * (asterisk) can be used only at the lowest, terminating level of the path. It matches zero or more characters. Every character in a URL pattern must match the corresponding character in the URL path exactly. Exceptions: At the end of a pattern, /* matches any sequence of characters from that point forward. The pattern *.extension matches any file name ending with the named extension. Does not match /.	The following URL pattern: /.../update.html Matches: /humanresources/benefits/update.html /corporate/news/update.html update.html See Also: Table 25-4
/.../ Hierarchy /.../* Host wide	Matches any sequence of one or more characters that starts and ends with the forward slash character (/). Evaluation descends from the root /. At each directory level, resources matching the highest precedence level are selected as candidates for continued evaluation and then descend to the next level. This continues until resources representing the best match possible, based solely on the path information, is obtained. Host wide; the entirety of the pattern.	The pattern /.../index.html matches: /index.html/oracle/index.html/oracle/sales/index.htmlindex.html It does not match xyzindex.html or xyz/index.html. /oracle/.../*.html matches: /oracle/index.html/oracle/sales/order.html, and so on.
\	The backslash character is used to escape special characters. Any character preceded by a backslash matches itself. Escaped special characters need to be ignored if putting the pattern in wildcard buckets Escaped special characters are matched literally to the special characters, if any, within the incoming URL	abc\d only matches abcd abc\\d only matches abc\d

Table 25-4 illustrates a number of resource definitions within an Application Domain, organized alphabetically according to the Host Identifier and Resource URL. The right-hand column in Table 25-4 declares whether the form is correct or not.

Table 25-4 Sample Resource URLs

Resource URL	Correct Form
/bank/accounts/*	Yes
/bank/accounts/*.jsp	Yes
/bank/accounts/checking	Yes
/bank/.../checking.jsp	Yes
/.../*.jsp	Yes
/bank/accounts/checking*.jsp	No
/bank/accounts/c*.jsp	No
/bank/.../accounts/def.gif	No

25.5.1.4 Query String Name and Value Parameters for Resource Definitions

The Policy Model supports Query String Name and Value parameters in a Resource pattern definition

Name: A string literal that can contain any characters, including symbols; all characters are treated as literal.
Value: Can be a string literal with any characters and can contain a wildcard (* only) to match a sequence of 0 or more characters. Asterisk (*) is treated as a wildcard.
Amount: There is no limit to the number of name and value pairs in a query string. However, for a single resource there will be only a few pairs.
Order: Any order can be used for name and value pairs because at run time these might come in any order as part of the query string.

Resource Matching and Precedence: Query String Name and Value Parameters

Access Manager uses an algorithm that locates the least specific match and continues to the most specific possible resource. When you have candidates defined with both a single-query string and query parameters, those with the single string take precedence.

For resources containing parameter lists, the best match is determined as follows:

Path Matching: Access Manager attempts to match the path of the requested resource. There may be multiple candidates matched, differing by query component and/or operations declared.
Query String Matching: For matches obtained, Access Manager attempts to match the query string (if present in the requested URL). If candidates are defined with both single query string and query parameters, those with the literal string take precedence. There may be multiple candidates remaining, differing by operation.
Operation Matching: For matches obtained, attempt to match the requested operation. If there is no exact match present, then check for resources for which no specific operation(s) have been defined. In other words, they apply to any operation defined as part of the resource's type. In either case, this yields a single, best match.

Path Matching: Defined resources are evaluated for potential match, against the requested URL's path component, in the following precedence order:

Literals (as in, the resource's pattern contains no special characters)
Choice: {pattern1,pattern2,...} , each of which may itself contain the below special characters and is evaluated, in turn, using this same precedence order
Range: [ ]
Single-char wildcard: ?
Wildcard: *
Hierarchy: /.../
Hostwide: /…/* is the entirety of the pattern

Evaluation descends from the root '/'. At each directory level, resource(s) matching with the highest precedence level are selected as candidates for continued evaluation and then descent to the next level occurs. This continues until resource(s) representing the best match possible, based solely on the path information, is obtained.

Note:

All matching in 11g has been, and remains, case insensitive.

Table 25-5 illustrates the matching pattern for each of several requested URLs.

Table 25-5 Pattern Matching for Requested URLs

Requested URL	Matching Pattern
/oam/sales/oam/page8.html	/oam/.../*.html
/oam/Dept1/page8.html	/oam/Dept?/page8.html
/oam/DeptQ/page8.html	/oam/Dept[A-Z]/page[1-8].html
/oam/DeptQ/page8.html	/oam/Dept[A-Z]/page?.html
/oam/saals/foo/aba/zzz/indexp.html	/oam/sa{,le,l?,a[k-m],[a-f-m]}s/.../{b,?a}{a,/../ii}/.../{index,test}[pa].?tml

Query String Matching:

When you have candidates defined with both single query string and query parameters, those with the single string take precedence. Single query strings are scored using the algorithm already-mentioned.

For resources containing parameter lists, the best match is determined as follows:

Resources with parameter values without wildcards are given higher order of precedence; the combined length of the parameter names and values is used to determine the best match among the set of such resources.
As for query string literals, if there are two or more matches with the same combined length, then matching will fail.
Resources with parameter values containing wildcards are considered next. The total number of wildcards within each resource is used to determine the best match among such resources. If there are two or more matches having same number of wildcards, then the combined length of the parameter names and values determines the best match
Matching fails if multiple resources contain the same combined length.

Query String Matching Patterns: Second and subsequent patterns use parameter lists:

/oam/index.html::a=*d (a single query string)
/oam/index.html::a:b
/oam/index.html::a:b,c:d
/oam/index.html::a:b*
/oam/index.html::a:b*,c:d
/oam/index.html::a:b*,c:d*
/oam/index.html::a:b*,c:*d*

Table 25-6 illustrates the matching pattern for each of several requested URLs.

Table 25-6 Query String Matching: Examples

Requested URL	Matching URL Pattern	Matching Query String Pattern
/oam/index.html?a=b&c=d	/oam/index.html	a=*d
/oam/index.html?a=b1&c=d	/oam/index.html	a:b*,c:d
/oam/index.html?a=b1,c=d1	/oam/index.html	a:b,c:d
/oam/index.html?a=b1,c=1d1	/oam/index.html	a:b,c:d*

Operation Matching Examples: At this point in request processing, there are one or more candidate resources, all of which match the requested URL path and query string components equally. Access Manager now matches the requested operation to one of those candidates: a resource defined to protect that operation specifically (as well as other, specific operations). As only a single resource can be defined to protect any given operation, this will give the single best match.

Note:

If this does not give a match, verify that the candidate exists protecting all operations (meaning it has been defined using “All", and protects no specific operations).

Run Time Evaluation: Name value pairs are evaluated at run time as follows:

NAME VALUE
a ab
a a*

Same Resource URL Specified Differently: Resources with the same URL and with the same characters in the query string (although specified differently in the console (one as a key and value and the other as a single string)) are considered different and are allowed. For example, the two following resource patterns are considered as different:

Resource URL: /test.html
Query string: area=*&dept=*
Resource URL: /test.html
Query NAME VALUE
area *
dept *

Resource Matching During Policy Evaluation: The order in which name and value pairs arrive at run time does not matter. As long as all the names and values match the query string, the match is successful. The incoming request can have more name and value parameters than defined and still have a successful match.

Example 1: The following pattern matches the incoming URL if no other pattern is defined with the same URL, query string variables, and the extra query string variable (revenue=1000):

Incoming URL => /test.html?area=emea&dept=engg&revenue=1000
resource pattern => /test.html
Query String NAME VALUE
area emea
dept engg

Example 1: For a resource with the same resource URL and the same query string, with one defined as a single string and the other defined as name and value pairs, the policy evaluation preference matches the literal query string before considering name and value pairs. For instance, in the following example, a) is matched:

Runtime Request: URL => /test.html?area=emea&dept=engg
Resource Patterns:
a)
Resource:/test.html
Query string: area=emea&dept=engg
b)
Resource:/test.html
Query String NAME VALUE
area emea
dept engg

Best Match, Multiple Resources: When you have multiple resources with query string name and value pairs defined, the best resource match is the pattern that matches the most number of query string parameters. When wildcard values are used, this is followed by how closely each parameter value matches.

For example: With the following two query string patterns defined:

Query String NAME VALUE
area e*
dept e*
and
area em*
dept en*
Run Time Query String Parameters:
area emea
dept engg
Result: The second name and value pattern match order is higher.

Figure 25-11 shows the resource definition page. Here, "rev*" is a valid name (the asterisk character is allowed and treated as a literal character, which is equivalent to 10g behavior). The Oracle Access Management Console enables you to add query strings as name and value pairs. You can also add the query string as a literal string. If If you select a literal query string, then the name and value option is disabled (and vice versa).

Figure 25-11 HTTP Resources, Query String Resource URL Controls

Description of "Figure 25-11 HTTP Resources, Query String Resource URL Controls"

Behavior When Migrating to Access Manager: If you upgrade to Access Manager (from 10g), previous query strings are created in 11g appropriately (whether a single string or a name and value pair). The appropriate type of query string is created in Access Manager.

25.5.1.5 Literal Query Strings in Resource Definitions

The Policy Model supports resource protection based on matching literal, full query-string-based HTTP resource definitions within Access Policies. A single Query String Pattern that would be matched against the entire input Query string (as opposed to matching only portions—selected name and value pairs—of the query string).

For example:

status=active&adminrole=*

A Query String pattern specified as a regular free form string with these extra features:

Optional: Special character (*) that matches zero or more characters, which is applied to a set of names in the run time Query String.
Two resource definitions can exist with same URL base path pattern and different Query String patterns. These two are independent and non-equal resources. For example, these are all valid and can exist at same time:
```
/foo
/foo?bar=true
/foo?bar=false
```

The Query String is free form with no restriction in terms of format or characters. It is not required to specify Query String as key/value pairs

At run time, only the Query String that is part of HTTP GET requests is processed; Query String pattern does not apply to HTTP POST data.

Resource Matching at run time:

The base URL path is matched and then the Query String is matched
Multiple resource patterns that contain matching Query Strings: The best match is determined based on the number of tokens (pattern delimited by '*') and the length of the token at each position. Patterns with longer tokens in the beginning are preferred and then the pattern that contains more number of tokens. (If there are matching patterns that contain same number of tokens and same length at each position then the match would fail.)

Conflicts:

Super Set: The input resource definition contains a set of name-value Query String patterns that are a super set of patterns of an existing resource definition in the policy store.
Overlap: The input resource specification contains a set of name-value Query string patterns that overlap a set of patterns of an existing resource definition in the policy store.

Remote Registration: For OAM Agents, the remote registration tool (oamreg) accepts Query-string based HTTP resource definitions and generates the relevant policy objects for securing access of these resources. If any conflicts are encountered during policy provisioning, only policies for resources that do not have any conflicts are provisioned. This feature does not apply to 10g OSSO agent-based partners and applications. OSSO agents are not capable of enforcing authentication scheme per resource. Instead, a single authentication scheme is applied to all resources of an application.

25.5.1.6 Run Time Resource Evaluation

While processing requests for resources, an evaluation is made to ensure that the proper policy is invoked for the resource.

See Also:

Other processing details in the following topics:

Process overview: Resource evaluation

A user specifies the URL for a requested resource.
Access Manager creates a fully qualified URL that includes the URL pattern, based on the host identifier and URL.
Access Manager compares the incoming URL for the requested resource to the fully-qualified URL constructed from Application Domain information and the policy's URL pattern:
- If there is a match, the various policies are evaluated to determine whether the requester should be allowed or denied access to the resource.
- If the requester is allowed access, the resource is served.

Table 25-7 describes the possible outcomes.

Table 25-7 Resource Evaluation Outcomes

Outcome	Description
Best Match	The best match is when a resource definition has the least resource scope compared to other possible matches to the run time resource. The term resource scope represents all possible resources that could be matched using a particular resource definition
No Match1	If no match is found, the default evaluation outcome is FAILURE. Depending on what kind of policy was being evaluated, this could mean no authentication is attempted, or no resource access is granted.

Look Up Mechanism Examples

The default resource URL in an Application Domain defines the broadest scope of content possible (all directories and below):

/.../*
The pattern /.../index.html matches:
```
/index.html
/oracle/index.html
/oracle/sales/index.html
```
It does not match, for example, xyzindex.html.

/oracle/.../*.html matches:

/oracle/index.html
/oracle/sales/order.html
and so on

Resource Scope Examples

Resource scope of the following resource definition (includes the asterisk):

/mybank/…/*

includes all URLs prefixed with "/mybank/"
Resource scope of the following resource definition (no special characters in the definition):

/mybank/account.html

includes only one URL: "/mybank/account.html"

25.5.2 Defining Resources in an Application Domain

Users with valid Administrator credentials can add the resource definitions to protect to the corresponding Application Domain.

Resource protection based on a list of discrete query parameters is more secure and easier to administer than literal query strings. You might want to create a policy based on resource URL with query parameters (string and name-value pairs).

Note:

An error can occur if you specify a host identifier value that is invalid: The challenge URL is invalid.

Prerequisites

The Resource Type must be defined as a Shared Component. Several elements in the Resource definition page are based on the defined and selected Resource Type. For details, see "Managing Resource Types".

See Also:

"Resources in an Application Domain"

To add resource definitions to an Application Domain

In the Oracle Access Management Console, locate and view the desired Application Domain, as described in "Searching for an Existing Application Domain".
In the Application Domain, click the Resources tab, then click the New Resource button in the upper-right corner of the Search page.
On the Resource Definition page:
1. Select or enter your details for a single resource (Table 25-1):
  - Type
  - Description
  - Host Identifier
  - Resource URL (Table 25-4)
  - Operations
  - Query String (Table 25-6)
  - Protection Level
  - Authentication Policy (if level is Protected)
  - Authorization Policy (if level is Protected and Authentication Policy is chosen)
2. Click Apply to add this resource to the Application Domain.
3. Repeat this procedure to add other resources to this Application Domain.
Proceed by adding defined resources to specific policies in the Application domain as described in:

25.5.3 Searching for a Resource Definition

This section provides the following topics:

25.5.3.1 Search Elements and Results for Resource Definitions in an Application Domain

You can simply click the Search button using the defaults or refine your search by supplying information needed to find the resource.

Figure 25-12 shows the default Search elements and Search Results table for resource definitions in an Application Domain.

Figure 25-12 Resource Search within an Application Domain

Description of "Figure 25-12 Resource Search within an Application Domain"

Table 25-8 lists out the search elements and details.

Table 25-8 Search Elements for a Resource in an Application Domain

Search Elements	Description
Resource Type	Provides a list of defined resource types from which you can choose. You can also leave this blank. Default: HTTP
Host Identifier	Enter a host identifier here, if desired. You can leave this blank Default: blank
Resource URL	Enter a resource URL, if desired. You can leave this blank Default: blank
Query String	Enter a query string for the resource, or leave this blank. You can include this in the search criteria if a query string was defined for the resource when it was added to the Application Domain. Default: blank
Authentication Policy	Provides a list of defined authentication policies for this Application Domain. You can choose one or leave the space blank. Default: blank
Authorization Policy	Provides a list of defined authorization policies for this Application Domain. You can choose one or leave the space blank. Default: blank

You can click Reset to clear the form or Search to initiate the search. Each resource listed includes everything specified when it was added to the domain. The Actions and View menus are available for use with the table. Also you can click the Create command button to add a new resource definition to this domain.

25.5.3.2 Searching for a Specific Resource Definition

Users with valid Administrator credentials can search for a specific resource definition.

To find a resource definition:

In the Oracle Access Management Console, locate and view the desired Application Domain, as described in "Searching for an Existing Application Domain".
Click the Resources tab to display Resources Search controls.
Fill in your search criteria (Table 25-8), and click the Search button.
In the Search Results table, click the desired resource definition and take the desired action:
- Actions Menu: Select an item to Create, Edit, or Delete the selected resource.
- View Menu: Select an item to alter the appearance of the results table.
- Edit Button: Click the button in the tool bar to display the configuration page.
- Delete: See "Viewing, Editing, or Deleting a Resource Definition".
- Detach: Click Detach in the tool bar to expand the table to a full page.

25.5.4 Viewing, Editing, or Deleting a Resource Definition

Users with valid Administrator credentials can modify resource definitions within a specific Application Domain.

If a resource protection level is modified from "Protected" to "Excluded" while it is associated with a policy, the modification will fail. First, remove the resource from the policy, make the change, and add the resource to the policy.

Note:

During a Delete, you are alerted if the resource is associated with a policy. Without a policy association, the resource is deleted.

Prerequisites

You must have the desired resource type defined as a shared component. For details, see "Managing Resource Types".

See Also:

"Resources in an Application Domain"

To view, modify, or delete resource definitions

Find the Resource, as described in "Searching for a Resource Definition".
- View Only: Close the page when you finish.
- Modify: Alter the definition as desired and then click Apply to submit changes (or close the page without applying changes).
- Delete:
  - Open the resource definition and confirm this is the one to be deleted, then close the page.
  - Click the name of the desired resource definition and then click the Delete button in the tool bar.
  - In the Confirmation window, click Delete (or click Cancel to dismiss the window).
    
    If the Resource is associated with a policy, remove it from the policy first.
  - Repeat as needed to delete other resources in the Application Domain.