Skip Headers
Oracle® Access Manager Access Administration Guide
10g (10.1.4.2.0)

Part Number B32420-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Protecting Resources with Policy Domains

The Access System enables you to control who can access resources such as Web content and traditional applications by defining policy domains. Policy domains are usually one or more URL prefixes that identify resources on the Web. Policy domains contain authentication and authorization rules that determine who can access the resources, and at what time. Additionally, a policy domain can protect non-Web based resources.

You can also create policies within a policy domain to define fine-grained protection for resources, for example, to protect a specific Web page or set of pages.

For each policy domain and policy, you can define audit rules to monitor and record system events, successful and failed user authentications, successful and failed authorization of users, and so on.

This chapter explains how to configure policy domains, policies, and auditing rules. This chapter discusses the following topics:

4.1 Prerequisites

Oracle Access Manager should be installed and running, as described in the Oracle Access Manager Installation Guide.

You should also read the following before creating a policy domain:

In addition, a Master Administrator must complete the tasks described in the following task overview before any policy domains can be created.

Task overview: Prerequisite tasks for a Master Administrator

  1. Define the policy base during Policy Manager setup, as described in "About the Policy Base".

    To review the policy base from the Access System Console, System Configuration, View Server Settings page, look for the Policy Data Configuration section to obtain machine name, port, root DN, directory server security, and policy base.

  2. Define the policy domain root during Policy Manager setup, as described in "About the Policy Domain Root".

  3. Create a Master Access Administrator to create policy domains, resource types, and access control schemes, and to assign the role of Delegated Administrator of a policy domain to other people:

4.1.1 About the Policy Base

During Policy Manager installation, the Master Administrator specifies where to store policy data. During Policy Manager setup, a policy base is also created. The policy base is the top node in the directory tree for object classes for policy domains and their policies.

All information about a policy domain is stored in relation to the policy base. All information about a policy domain, including its rules and the resources it protects, is stored at the same level under the policy base.

The Master Administrator must define a policy before you can configure a policy domain or policies. See the Oracle Access Manager Installation Guide for details.

4.1.2 About the Policy Domain Root

During Policy Manager setup, the Master Administrator specifies a policy domain root. The policy domain root is a URL prefix under which all resources are protected. The default policy domain root must be broad to encompass all of your resources. The default root is /.

See also:

For details about URLs, see "Configuring URLs for Resources".

For information on defining the policy domain root during Policy Manager setup, see the Oracle Access Manager Installation Guide.

4.2 About Policy Domain Administration

To protect resources, you create policy domains. A policy domain consists of:

The rest of this section discusses the following topics:

Note:

Before you can protect a resource, a Master Administrator must define the policy domain root and policy base, as described in "Prerequisites". The Master Administrator must also define a Master Access Administrator as described in "Configuring Master Access Administrators".

4.2.1 About Creating the First Policy Domain

A Master Access Administrator must create the first policy domain after the policy domain root is defined. He or she can then create policy domains for URLs beneath the first one and delegate administration of those policy domains to other administrators.

For details about the policy domain root, see "About the Policy Domain Root".

Task overview: Creating the first policy domain

  1. Define the resource types for any resources to be included in the domain whose types are not already defined by default.

    See "Configuring Resource Types" for details.

  2. Create the Master Audit Rule.

    See "About the Master Audit Rule" for details.

  3. Create the Authentication Scheme for the policy domain.

    See "About Authentication and Authentication Schemes" and "Managing Authentication Rules" for details.

  4. Create the Authorization Scheme for the policy domain.

  5. Configure the URLs for the resources of the first policy domain.

    See "Configuring Resource Types" for details.

  6. Create the Authentication Rule for the policy domain.

    See "Managing Authentication Rules" for details.

  7. Create actions for the Authentication Rule.

    See "Managing Authentication Actions" for details.

  8. Create one or more Authorization Rules.

    See "About Authorization Rules" for details.

  9. Create actions for the Authorization Rules.

    See "Setting Actions for Authorization Rules" for details.

  10. Create an authorization expression for the policy domain containing one or more authorization rules.

    See "About Authorization Expressions" for details.

  11. Create the audit rule for the policy domain.

    See "Creating an Audit Rule for a Policy Domain" for details.

  12. Test the policy domain.

    See "Using Access Tester" for details.

  13. Delegate management of the domain to a Delegated Access Administrator.

    See "Delegating Policy Domain Administration" for details.

4.2.2 About Managing a Policy Domain

As a Delegated Access Administrator, you can manage a policy domain for which you have been granted administrative rights.

The following task overview describes tasks you can perform as a Delegated Access Administrator. You perform these tasks as needed; none is required.

Task overview: Managing a policy domain

  1. Replace the authentication rule for the policy domain or its policies.

    To do this, you must first delete the policy domain's or the policy's existing authentication rule.

    To create an authentication rule, you select an authentication scheme that was created by a Master Access Administrator, and configure the rule's actions. See "Managing Authentication Rules". for details

  2. Replace the authorization expression for the policy domain or its policies.

    To do this, you must first delete the content of the policy domain's or the policy's existing authorization expression.

    To create an authorization expression for the policy domain or any of its policies, you combine one or more authorization rules created at the policy domain level. See "About Authorization Expressions".

  3. Create audit rules derived from the Master Audit Rule.

    See "Creating an Audit Rule for a Policy Domain" and "Defining an Audit Rule for a Policy".

  4. Test the policy domain.

    See "Using Access Tester".

4.2.3 Overview of Creating a Policy Domain

As a Delegated Access Administrator with a particular set of privileges, you can create policy domains. See Table 4-4 for details.

The following task overview summarizes the procedures for creating a policy domain.

Task overview: Creating a policy domain

  1. Configure the URLs for the resources of the policy domain.

    See "Configuring URLs for Resources" for details.

  2. Create the authentication rule for the policy domain.

    See "Managing Authentication Rules" for details.

    You include an authentication scheme created by a Master Access Administrator in the rule.

  3. Create actions for the authentication rule.

    See "Managing Authentication Actions" for details.

  4. Create one or more authorization rules for the policy domain.

    See "About Authorization Rules" for details.

  5. Define actions to be taken for the authorization rule, if the rule fails or if it succeeds.

    See "About Authorization Actions" for details.

  6. Create the authorization expression for the policy domain containing one or more authorization rules.

    See "About Authorization Expressions" for details.

  7. Create actions to be taken for the authorization expression, depending on the evaluation of the expression: success, failure, or inconclusive.

    See "About Actions For Rules and Expressions" for details.

  8. Create the audit rule for the policy domain.

    See "Creating an Audit Rule for a Policy Domain" for details.

  9. Test the policy domain.

    See "Using Access Tester" for details.

  10. Configure policies for the policy domain, if any.

    See "Configuring Policies" for details.

Note:

You can configure a policy domain resource URL that is already covered by a resource definition in another policy domain for which you have administrative rights. For details, see "How the Policy Domain or Policy for a Resource Is Determined".

4.3 About Policy Domains and Their Policies

Policy domains are logical structures defined for resources that you want to protect in the same way. Particular policies provide different and more specific coverage for a subset of the policy domain's resources.

When users request access to resources protected by a policy domain, their requests are evaluated according to the domain's authentication rule and its authorization expression.

There are several ways that users can attempt to access a resource that is protected by a policy domain, for example, by entering a URL in a browser, by running an application, or by calling some other external business logic.

The rest of this section discusses the following topics:

4.3.1 Parts of a Policy Domain

A policy domain consists of the following parts:

  • URLs that define paths to resources that are protected by the domain's authentication rule and authorization expression

    A policy domain can include multiple URLs that are independent of one another. Resources under one URL can reside on a different host from resources under another URL in the same policy domain. The policy domain's default rules apply to the resources it contains, unless the resource is protected by a specific policy.

  • The host identifier

    You identify all resources that you add to a policy domain by the host where the resources reside and their URLs. A host can be known by multiple names. To ensure that it recognizes the URL for a resource, the Access System must know the various ways used to refer to that resource's host machine.

    The Host Identifiers feature enables you to enter the official name for the host and every other name by which the host can be addressed by users. A request sent to any address on the list is mapped to the official host name. For details about the host identifier, see Chapter 3, "Configuring WebGates and Access Servers".

    It is possible to use the Host Identifiers feature to set up a host context for adding resources to the same policy domain on different machines. For details describing what a host context is and why you may want to use one, see "Using Host Identifiers and Host Contexts".

  • Rules and expressions for protection

    Rules for authentication determine how the identity of a user attempting to access a resource is to be proven. Authentication rules contain authentication schemes. Authorization rules determine whether the user has the right to access the resource. Authorization rules contain authorization schemes and are contained in authorization expressions. An authorization expression can contain one or more authorization rules. Auditing rules determine the information to be recorded in the audit log for operations pertaining to the policy domain or policy (audit). Auditing rules are derived from a Master Audit Rule. For details, see the following information:

  • Policies for URL patterns and the operations allowed for the type of resource to which the pattern applies

    Policies for resources within a policy domain allow you to create finer-grained ways to protect specific resources in the domain. You can specify a URL pattern or an explicit URL to identify resources. Different types of resources have their own operations. You can specify the operations—also known as request methods—that are allowed for resources of a type. Requests for resources whose URLs match the pattern are further processed against the rules of the policy.

    For details about policies, see "Configuring Policies".

Figure 4-1 provides a conceptual view of the parts of a policy domain. In this figure, only Web-based resources are shown. However, Access System policy domains can also protect resources other than Web-based ones.

Figure 4-1 Policy Domain Structure

Conceptual view of the parts of a policy domain

A policy domain can contain different types of 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

For details describing resource types, see "Configuring Resource Types".

4.3.2 How the Policy Domain or Policy for a Resource Is Determined

A resource may fit the definition of more than one policy domain. It may fall within a broad policy domain such as /mydomain. It may also fall within a more specific policy domain such as /mydomain/myresources. The Access Server checks all policy domain definitions to find the URL prefix that most closely matches the resource's URL.

Unlike the way that the Access Server checks policy domains, the Access Server checks policies in the order that you specified when you configured them. It uses the first matching policy regardless of how many more policies there are. The closest match to a requested resource may not be checked because a previous policy provided a match. For an intended policy to be used and for processing efficiency, consider the order that you assign to policies.

4.3.3 Preconfigured Policy Domains

You can configure policy domains to protect Identity System and Policy Manager resources (URLs) during installation. The policy domains created during installation are:

  • Identity Domain: Protects Oracle Access Manager Identity URLs.

  • Access Domain: Protects Oracle Access Manager Policy Manager URLs.

You must configure a WebGate and Access Server for these policy domains, and then enable or disable them together.

Tip:

See the Oracle Access Manager Installation Guide for information about configuring authentication schemes and policies during installation.

4.3.4 Who Creates Policy Domains?

Delegation of policy domain administration enables you to scale administration, enabling those closest to the resources and most knowledgeable about them to manage them. You can distribute policy domain creation and administration across administrators. Or, you can centralize policy creation and decentralize management and enforcement of it. A Master Access Administrator can create several policy domains and delegate administration of them to Delegated Access Administrators. The Delegated Access Administrators can manage the domains and create policy domains for resources whose URLs are more specific than those of the domain.

Examples

  • A Web Master who maintains a corporate Web site is assigned the position of Delegated Access Administrator for the policy domain for a resource. The policy domain includes other resources the Web Master also manages.

  • A Delegated Access Administrator may manage a particular resource, such as an enterprise-level application, for example, an airline's passenger check-in verification system. Instances of the application may run on many servers.

    Because a related, smaller application called Upgrade requires the same protection and is managed by the same administrator, both applications could belong to the same policy domain. Additionally, all instances of each application could be protected by the same policy domain.

See also:

For details about Master Access Administrators and Delegated Access Administrators, see "Delegating Policy Domain Administration".

4.3.5 Examples of Policy Domains and Policies

Organizations use policy domains and policies for different purposes and in different ways.

Here are some examples of use policy of domains:

Policy Domain for Human Resources and Marketing: This example illustrates using policies to provide enhanced authorization for a resource in a policy domain. A policy domain protects human resources information made public to employees and a branch of the marketing Web site. Both sets of resources require the same kind of protection.

The following two URLs define the policy domain's logical structure:

/AreteAirlines/marketing/reports/

/AreteAirlines/HR/

If resources of either organization in the policy domain require protection rules that are more specific than the policy domain's default rules, policies can be defined to protect those resources. For example:

  • The default Authorization rule for /AreteAirlines/HR/ grants all users weekday access only.

    A policy could be defined to remove weekend access restrictions from a set of human resource files for human resources managers who tend to work on weekends.

  • The same policy domain includes resources in a private directory that should be viewed only by regular employees, for example, analysts' reports.

    The private directory is subordinate to the reports directory. Resources in the private directory are protected by the default rules of the policy domain unless a policy is used to provide them different protection. A policy that restricts access to the resources in the private directory exists; it stipulates that only regular full-time employees may see the reports in the following private directory:

    /AreteAirlines/marketing/reports/private/

  • The policy domain's URLs encompass a resource that is an application called badgit. The application enables HR employees to register employees of the organization for access badges. The main application processes the request and obtains information from a backend application. A policy is used to protect only this application. The policy applies to the following specific URL:

    /AreteAirlines/HR/badges/badgit.exe

Policy Domain for a University: This example illustrates the use of policies to provide relaxed authorization requirements for a resource in a policy domain. A university provides information to its students, but not to outsiders. The URL for the policy domain protecting the resources is:

/GlobalUniv/

Two policy domains with more specific URLs are created to include resources otherwise covered by the /GlobalUniv/ policy domain.

  • One of these policy domains includes the URL /GlobalUniv/physics/.

  • The other policy domain includes the URL /GlobalUniv/philosophy/.

The policy domain /GlobalUniv/physics/ allows only physics students to access the policy domain's resources.

  • All physics students can access resources in the /GlobalUniv/physics/feynman/diagrams/ directory because the default rules of the /GlobalUniv/physics/ policy domain apply, and there are no specific policies applied to these resources.

  • A policy can be created to allow only those students who meet the authorization criteria of the policy protecting the testResults.html page to see it. The students who took a quiz may be able to view the following Web page:

    /GlobalUniv/physics/feynman/diagrams/testResults.html

The college presents a suite of applications animating the world of black holes. The applications are available to all students, not just physics students. The URL for one of these Enterprise JavaBean (EJB) applications is /GlobalUniv/physics/wheeler/blackHoles/explore/styx.ejb.

Because the application is in a directory called wheeler, which is subordinate to the physics directory, a policy must be used to remove access to the wheeler directory, providing the resources to all students.

4.3.6 About Allocating Responsibility for a Policy Domain

You can assign administrative roles and give the administrators responsibilities for managing policy domains for resources of the same or a different type on the same or a different host. It is a good idea to define policy domains along the lines of the resources they protect and who manages them. Who can access them is secondary, and is expressed through the access control rules of the policy domain.

The following are some examples why it may be useful to decentralize management of resources:

  • You want to provide your employees with faster and better service for your online applications.

    For example, improved service helps to make applications more readily available initially and more easily recoverable if a failure of the host system occurs.

  • You may want to keep your informational Web sites for employees operational and current with as little disturbance as possible.

4.4 Configuring Resource Types

A resource type describes the kind of resource to be protected, including its associated operations. Operations associated with a resource are tied to its type.

Before you can add resources to a policy domain, you must define their types and the operations associated with them that you want to protect.

The Access System provides several default resource types. A Master Access Administrator can define other resource types from the Access System Console.

By giving you the ability to define more resource types than the default ones provided, the Access System enables you to protect more than just Web-based resources.

The rest of this section discusses the following topics:

Note:

You can configure custom AccessGates to protect non-Web resources. See Oracle Access Manager Developer Guide for details.

4.4.1 About Resource Types

The Access Manager expects resources to be directory or file level resources, for example:

http://server.domain.com:port/this/path/to/the/app?param1=x&param2=y

Any URL that contains query strings is escaped and the entire URL is considered a directory or named resource. In the previous example, the string app?param1=X&param2=Y is escaped and treated differently from other types of URLs. For example, suppose a user requests the following resource:

http://server.domain.com:port/this/path/to/the/app?param2=y&param1=x

In theory, this is the same resource as the previous one. However, the policy domain evaluation performed by the Access System will miss this resource, and will fail to protect it. Similarly, if the user requests the following URL, the Access System will miss this resource, and as a result will fail to protect it:

http://server.domain.com:port/this/path/to/the/app?param1=x&param2=y&param3=z

In these cases, you should define the policy domain for the resource at the URL path level, for example:

http://server.domain.com:port/this/path/to/the/app

You can add one or more policies under the policy domain to handle more specific URLs. A policy can contain a query string pattern of *param1=X&param2=Y* or separate query string value pairs.

4.4.2 Default Resource Types

The Access System provides the following resource types:

  • Enterprise Java Beans (EJB): The EJB resource type is not required.

    You can delete it if you do not plan to protect EJB resources.

  • HTTP (HTTPS): The HTTP resource type definition is required, whether or not you protect resources of this type.

    You cannot delete the HTTP resource type or modify its operations.

You must define the type for any other types of resources that you want to protect.

4.4.3 Supported HTTP Operations

The Access System supports the following HTTP operations:

  • CONNECT: Handshakes with a URL

  • DELETE: Deletes information from the URL, or deletes the URL itself

  • GET: Retrieves information from the URL

  • HEAD: Obtains information about the resource without making changes to the URL

  • OPTIONS: Obtains information about HTTP methods available to and from the URL

  • OTHER: Non-standard, custom operation

  • POST: Copies information to the URL

  • PUT: Replaces a file or document in the URL

  • TRACE: Views information about what the URL is receiving

4.4.4 Supported EJB Operation

The Access System supports the EJB EXECUTE operation, which executes a bean. You can add other EJB operations.

4.4.5 Supported Resource Types

A policy domain can protect these types of resources and their operations:

  • EJB Resources

    EXECUTE

  • HTTP Resources

    GET, POST, PUT, TRACE, HEAD, CONNECT, OPTIONS, and others

    You can define policies to protect a specific operation.

  • RDBMS Resources

    ADD, DELETE, and UPDATE

  • Servlet resource types

Table 4-1 shows examples of HTTP resources, Java 2 Enterprise Edition (J2EE) resources, and other online application resources identified by their URLs.

Table 4-1 Application Resources and Their URLs

Resource Type Examples

HTTP Resources

  • Directories

    /mydirectory

  • Pages

    /mydirectory/index.html

  • Web applications

    /applications/myexe.exe

  • Query strings

    www.wwm.com/sales/result/pricelist1,2,0-a-00,000.htm?st.dl.search.qs.results

J2EE Application Server Resources

  • Java Server Pages JSPs

  • Servlets

  • Enterprise Java Beans

Other Resources

  • Standalone programs

    Java, C, C++ application programs

  • ERP applications

  • CRM applications


4.4.6 Defining a Resource Type

To define a resource type, use the Define a New Resource Type page.

To define a resource type

  1. From the landing page for the Access System, click the Access System Console link.

    If you are working with the Policy Manager, click the link for the Access System Console at the top of the page.

  2. From the Access System Console, click the Access System Configuration tab, then click the Common Information Configuration link in the left navigation pane.

  3. Click the Resource Type Definitions sub-tab.

    The List All Resource Types page appears.

  4. On the List All Resource Types page, click Add.

    The Define a new Resource Type page appears.

    Image of the Define a New Resource Type page
  5. In the Resource Name field, enter a unique name for the new resource type.

  6. In the Display Name field, enter the name of the resource type.

  7. In the Resource Matching field, specify whether the resource type can be read as case sensitive or case insensitive.

  8. In the Resource Operation field, specify the operations this resource type can perform.

    You can define custom operations, but not for HTTP resource types.

    To add or delete fields as necessary, click the plus (+) and minus (–) icons.

  9. Click Save to save your changes (or click Cancel to exit the page without saving).

4.5 Configuring URLs for Resources

To use the Access System to protect your resources—for example, your business applications and content—you must create a policy domain whose URL prefixes and URL patterns identify the resources.

URL Prefixes: You use URL prefixes to define the policy domain content. For policies, you use URL patterns to identify resources protected by the policy.

You can create URL prefixes that define a broad scope of content, for example:

//sales/humanresources

In this example of a policy domain, the resources to be protected exist on three different hosts. All resources under the URL prefixes are protected by the default rules of the policy domain:

Policies: You can create policies for resources within a policy domain. For example, resources for two other groups reside under /. They are engineering and marketing.

URL Patterns: You can create policies with granular URL patterns. Here is an example of a URL pattern:

/.../update.html

This URL pattern matches these resources:

/humanresources/benefits/update.html/corporate/news/update.htmlupdate.html

Figure 4-2 illustrates how URL prefixes and URL patterns are used to define the resources for policy domains and their policies.

Figure 4-2 URL Prefixes and Patterns

URL prefixes and patterns in policy domains and policies.

4.5.1 About URL Prefixes

The URL prefix is the starting point for resources in a policy domain. A URL prefix defines the beginning boundary of a policy domain, that is, its first resource. A URL prefix maps to a directory on the file system of one of your application servers or Web servers.

All resources under a URL prefix are protected by the default rules of a policy domain unless more specific rules are applied to them through policies. You can assign one or more URL prefixes to a policy domain, but each URL prefix can belong to one policy domain only.

The trade-off in creating many granular policy domains is that you achieve greater security at the cost of increased overhead. The cost is incurred because the Access Server must evaluate all policy domains to find the one that is most specific to the resource. Use of policies affords you the same benefit without the overhead.

The following is a screen shot of a page where you define a primary URL prefix for a resource, as described in "To add resources to a policy domain". This screen shot shows a policy domain that protects the Identity System:

Image of the Resources tab.

Process overview: How a URL prefix is used

  1. An end user requests a resource by specifying the URL for the resource in a browser.

    For example, a user enters the following URL in her browser to request access to a data page displaying information about a specific corporate partner:

    www.AreteAirlines.com/Partners/mycorp.html

    If the user's own Web site is set up accordingly, the user may select a link which represents the resource (and the URL for it).

  2. The Access System locates the requested resource.

    The Access Server assesses all of the policy domains to ascertain the one having the URL prefix most specific to the incoming URL for the resource. (The Access Server determines if the resource is covered by a policy within the domain, whose rules would then apply.)

  3. If no policy applies, the Access System uses the rules of the policy domain to determine whether to allow or deny the user access to the HTML page.

A policy domain can protect content other than Web-based content, although the policy domain in Figure 4-2 covers Web-based resources.

You can specify individual policies for resources of a given type whose URLs match a URL pattern. You can also specify the kinds of operations that can be performed on the resources.

4.5.2 About URL Patterns

A URL pattern is an Access System-supported mechanism for identifying different resources of a certain type that are protected by a single policy. A URL pattern can be a directory, query string pattern, or query string variable. If it is an explicit fully qualified URL, then it refers to a single resource.

An example of a URL pattern that covers many resources is a URL for all HTML pages (*.html) of a department's Web site. In this case, the policy may remove restrictions imposed by the policy domain's default rules. An example of a URL pattern for a specific file is an explicit fully qualified path (URL) of a single instance of an application. Resource operations are the functions available for each configured type of resource. For example, HTTP has GET, POST, PUT and other operations.

The following is a screen shot of a page where you configure a URL pattern for a fine-grained policy, as described in "Adding a Policy". In particular, the following screen shot shows a policy that protects the Lost Password Management application in the Identity System. This policy is configured for the Identity domain:

Policies tab for the Identity domain

When appended to the URL prefix of /identity, the URL pattern shown in the previous screen shot forms a pattern that protects resources located in the following URL path:

/identity/oblix/apps/lost_pwd_mgmt/.../*

The following screen shot illustrates the result of defining multiple URL patterns for a policy domain. In particular, the screen shot shows a list of policies and their URL patterns in the Identity domain. These URL patterns protect various applications and data directories in the Identity System:

Sample page with list of policies.

4.5.3 How URL Patterns are Used

URLs for policies specify the fine-grained portion of a resource's namespace. To fully identify the URL, the host identifier and URL prefix for the policy domain are concatenated with the policy's URL pattern.

Process overview: How URL patterns are used

  1. A user specifies the URL for a requested resource.

  2. Based on the policy domain's host and URL prefix information, the Access Server creates a fully qualified URL that includes the URL pattern.

  3. The Access Server compares the incoming URL for the requested resource to the fully qualified URL constructed from the policy domain information and the policy's URL pattern.

    • If there is a match, the policy's various rules are evaluated to determine whether the requester should be allowed or denied access to the resource.

    • If requester is allowed access, the resource is served to the user.

Figure 4-1 shows the structure of a policy domain called Partners that includes the following URL pattern:

/Ace/.../*

To get the fully qualified name of the URL pattern for the policy, the policy domain's URL prefix, /Partners, is prepended. The name of the host where the resources of the policy domain reside is specified before the URL prefix, resulting in the following URL:

myhost/Partner/Ace/.../*

For information on configuring a policy and its URL patterns, see "To add a policy".

4.5.4 URL Pattern Matching Symbols

The Access System expresses URL patterns through a type of filtering called globbing. This filtering method combines different Unix shell (sh, csh or tcsh) support for patterns in file names with Access System-provided patterns such as "..." (three periods), which let you span multiple directories.

Table 4-2 shows the supported patterns.

Table 4-2 Supported patterns

Pattern Description Examples

?

Matches any one character other than /.

a?b matches aab and azb but not a/b.

*


Matches any sequence of zero or more characters. Does not match /.

a*b matches ab, azb, and azzzzzzb but not a/b.

[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 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.)

{pattern1,pattern2,...}

Matches one from a set of patterns. The patterns inside the braces may themselves include any other special characters except for braces (sets of patterns may not be nested).

  • a{ab,bc}b matches aabb and abcb.

  • a{x*y,y?x}b matches axyb, axabayb, ayaxb, and so on.

/.../:

Matches any sequence of one or more characters that starts and ends with the forward slash character (/).

  • 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.

  • abc\*d only matches abc*d

  • abc\\d only matches abc\d


4.5.5 Invalid Patterns

Patterns with the following attributes are invalid:

  • A '[' without a closing ']'

  • A '{' without a closing '}'

  • Unescaped '{' inside {}

  • Unescaped '/' inside [ ]

4.5.6 Access System Patterns

A policy can contain one or more of the following types of patterns. If multiple patterns are specified in one policy, they all must match to the incoming URL. If they do not, the policy does not apply to the URL.

This example uses the following incoming URL:

http://www.myserver.com/oblix/sales/index.html?user=J.Smith&dept=sales

The policy includes the following URL patterns:

  • Pattern for the absolute path of the URL

    This pattern is the part of the URL that does not include the scheme (http) and host/domain (www.myserver.com), and that appears before a ? character. In this example, the absolute path is: /oblix/sales/index.html.

  • Pattern for name value pairs in the URL

    A set of these pairs may be configured as a pattern. The pairs apply to query data that appears after the ? character in the URL—if the operation is GET. If the operation is POST, query data appears after the POST data. For a pair, name specifies a name value, not a pattern. The value element of the pair is configured as a pattern. For example:

    Name Pattern
    user *Smith
    dept *sales*

    If multiple name-value pairs are specified, they all must match the incoming URL. Therefore, the following URL does not match the pattern:

    http://www.myserver.com/oblix/sales/index.html?user=J.Smith &dept=engg

    The important difference between this pattern and the next one is that there is no priority to these name-value pairs. The following URL satisfies the pattern:

    http://www.myserver.com/oblix/sales/index.html?dept=sales&user=J.Smith

    Note the reverse order of "dept" and "user". This is important and useful because it is commonly difficult to control the order of name-value pairs in the GET/ POST query data.

  • Pattern on the entire query string:

    This is useful if you want to enforce an order on the query string. For example, a pattern:

    user=*Smith*sales*
    

    matches the query string

    user=J.Smith&dept=sales
    

4.6 About Schemes

Schemes allow the Master Access Administrator to define methods that are used to authenticate users and to verify a user's right to access a resource. Schemes are reusable templates. You create schemes in the Access System Configuration area of the Access System Console.

An authentication scheme contains one or more steps, each of which can include one or more plug-ins. A policy domain must have at least one authentication rule and therefore one authentication scheme.

An authorization scheme is included in an authorization rule. You can use the default authorization scheme, or you can provide a custom one. A policy domain must have an authorization expression containing at least one authorization rule.

After you define a scheme, Delegated Access Administrators for different policy domains can use the same scheme in rules for their domains or in rules for policies within their domains.

You can define all of the schemes you and your Delegated Access Administrators will need for policy domains and policies at one time. Or, you can define schemes as they are required.

4.7 About Plug-Ins

Plug-ins are dynamically loaded shared libraries executed to perform authentication and authorization processes. They are contained in schemes, and they are used to request and process the information necessary to authenticate a user or authorize a user to access a resource.

Plug-ins perform specific tasks. For example:

You can create plug-ins for the following supported platforms:

For information describing how to create custom plug-ins, see the Oracle Access Manager Developer Guide.

4.8 About Rules and Expressions

Rules contain schemes that define how the resources of a policy domain are to be protected, including:

You include one or a combination of authorization rules to form an authorization expression. Rules can include actions to be executed depending on the result of the evaluation of user information against the specifications of the rule.

A policy domain can include policies, which can contain their own rules and authorization expressions. Therefore, a policy domain can contain two levels of rules:

Authorization expressions include authorization rules and the operators used to combine them. You combine rules within expressions to create from simple to complex means of specifying who is allowed or denied access to the protected resources.

Authorization rules are reusable within a policy domain. You can use the same rule in an authorization expression more than once. Also, you can use the same rule in the expression for the policy domain and in expressions for any of its policies.

Table 4-3 defines the four types of rules for a policy domain or a policy.

Table 4-3 Types of Rules

Rule Description

Authentication Rule

Specifies the method used to challenge and authenticate users requesting access to protected resources.

Can specify actions to be taken if authentication is successful or if it fails.

Note: Only one default authentication rule can be included in a policy domain. Each of its policies, however, can have its own authentication rule.

Authorization Rule

Allows or denies a user access to requested resources within a policy domain or policy.

Can specify actions to be taken if authentication is successful or if it fails.

These rules are included in authorization expressions.

Note: If more than one rule is included in an expression, the order of evaluation of the rules is determined by the logic you specify to form the expression.

Can also specify conditions for access.

Note: Only one default authentication rule can be included in a policy domain. Each of its policies, however, can have its own authentication rule.

Authorization Expression

Includes authorization rules. A policy domain must have one and only one authorization expression.

Note: A policy within a domain can have a single authorization expression. If it does not include one, the resources of the policy are protected by the authorization expression of the policy domain.

Audit Rule

Captures attributes and information about specific events pertaining to the policy domain.

  • It modifies and overrides events and information specified in the Master Audit Rule.

  • If no specific audit rules are applied, the Master Audit Rule is enforced by default.


Note:

Authentication rules are applied before authorization rules because a user's identity must be proven before he or she is granted access to a resource.

Figure 4-3 illustrates a policy domain containing a default set of rules and a default authorization expression applied to the domain's resources. For the resources defined by the policy, the default rules and expression are overridden by those of the policy.

Figure 4-3 Rules and Authorization Expression for a Policy Domain and Policy

Policy domain with rules and authorization expression.

4.8.1 Lessening or Increasing Controls with Rules

By default, the Access System allows access to a resource that is not explicitly protected by a policy domain rule or a policy. You can begin to create policy domains from this condition—all resources unprotected. You can take the opposite position and reverse the default state so that all resources are protected at the outset.

4.8.1.1 Beginning with All Resources Unprotected

If you begin to create policy domains from a position in which all resources are unprotected, you must apply access controls to those resources. You can do this at a broad level by creating policy domains with default rules which are more or less restrictive:

  • If you use restrictive default rules to impose tight controls across all resources of a domain, you can use policies to remove or change restrictions for subgroups of resources.

  • If you use lenient default rules as a starting point, you can use policies to provide tighter, specific controls on subgroups of resources within a domain.

4.8.1.2 Beginning with All Resources Protected

To start from a state in which all resources are protected, you set the parameter DenyOnNotProtected. If this switch is set to true, DenyOnNotProtected denies access to all resources not explicitly allowed by a policy domain's rules or policies.

If all resources are protected, you must create policy domains and policies to remove protection from those resources you want to make available to various users. In this sense, you are uncovering resources to a greater or lesser degree to make them available.

You can do this at a broad level by providing default rules for a policy domain:

  • If you use lenient default rules to lessen controls across all resources of a policy domain, you can use policies to apply particular restrictions for subgroups of resources.

  • If you use tighter default rules as a starting point—perhaps rules that are stringent but less so than the current default state of complete denial of access—then you can use policies to lessen access control for subgroups of resources in various ways.

Note:

If DenyOnNotProtected is set to false, this switch allows access to all resources not explicitly denied by a policy domain's rules or policies.

For information describing how to use the DenyOnNotProtected switch, see Chapter 3, "Configuring WebGates and Access Servers".

4.9 Creating and Managing Policy Domains

This section describes how to create policy domains, enable or disable them, and manage their resources. It addresses the following set of tasks:

4.9.1 Creating a Policy Domain

Both Master Access Administrators and Delegated Access Administrators can create policy domains. Master Access Administrators can create policy domains at any level. Delegated Access Administrators can create policy domains that are subordinate to any policy domains delegated to them for administration.

You use the Policy Manager to create policy domains, add resources to a domain, and protect the resources, using authentication rules and authorization rules and expressions.

Note:

By default, a policy domain is not enabled by default. Do not enable a domain until you have added resources to it. Be aware that if you enable a policy domain that does not contain resources, the domain cannot be used.

To create a policy domain

  1. From the landing page for the Access System, click the Policy Manager link.

    If you are working with the Access System Console, click the link for the Policy Manager at the top of the page.

  2. From the Policy Manager, click Create Policy Domain in the left navigation pane.

    The Create Policy Domain page appears, as illustrated in the following.

    Image of the Create Policy Domain page
  3. In the Name field, enter a short alphanumeric string identifying the domain.

    You can use spaces in this field.

  4. In the Description field, type a brief description of this policy domain.

    The Name and Description appear in pages showing lists of policy domains. A description is optional.

  5. Click Save.

    • To view currently defined information about your policy domain, click View as Page.

    • To return to the General page, click the name of your domain at the upper left part of the View as Page page.

  6. When you are ready to enable a new policy domain, click Modify in the General page, select Yes in the Enabled field in the next page, then click Save.

    The General page reappears.

  7. To add a resource to this policy domain, see "Configuring Resource Types", "Configuring URLs for Resources", and "To add resources to a policy domain".

  8. If you need to add a new resource type to this policy domain, add the new resource type in the Access System Console, then return to the Policy Manager.

    See "Defining a Resource Type" for details.

4.9.2 Modifying a Policy Domain

You can modify a policy domain after creating it. Modifying a policy domain includes changing any aspect of it— adding or removing resources, and modifying, removing, or adding rules.

Be sure to disable the policy domain before you modify it. See "Enabling and Disabling Policy Domains" for details about enabling and disabling policy domains.

To modify a policy domain

  1. From the Policy Manager, click My Policy Domains in the left navigation pane.

    The My Policy domains page appears, displaying a list of policy domains.

  2. Select the check box before the name of the policy domain you want to modify and click the domain's name.

  3. On the general page, click Modify at the bottom of the page.

  4. Change any values you want to modify, and click Save.

4.9.3 Deleting a Policy Domain

You can delete a policy domain entirely without first removing its resources and rules. Before you delete a domain, disable it. See "Enabling and Disabling Policy Domains" for details.

To delete a policy domain

  1. From the Policy Manager, select My Policy Domains.

    The My policy domains page appears, displaying a list of policy domains.

  2. Select the check box before the name of the policy domain you want to delete.

  3. Click Delete at the bottom of the page.

4.9.4 Enabling and Disabling Policy Domains

You must enable a policy domain before you can use it. You must disable a policy domain before you can modify its configuration.

The Access System provides two default policy domains that protect /identity and /access URLs. Both of these default policy domains must be enabled for the Access System to operate correctly. Only disable the default domains to modify them. Re-enable them after you have finished modifying them.

Important:

Disable a domain before modifying its rules or policies.

To enable a policy domain

  1. From the Policy Manager, select My Policy Domains.

  2. In the My Policy Domains page, select the check box next to the domain you want to enable.

  3. Click Enable.

    Yes appears in the Enabled column.

To disable a policy domain

  1. From the Policy Manager, select My Policy Domains.

  2. In the My Policy Domains page, select the check box next to the domain you want to disable.

  3. Click Disable.

    No appears in the Enabled column.

4.9.5 Searching for Policy Domains and Policies

You can search for and display existing policy domains and policies. Master Access Administrators can search for and see all policy domains and policies. Delegated Access Administrators can see only the policy domains for which they have been delegated administrative rights. For their policy domains, they can also see the policies which they have defined along with those defined by a Master Access Administrator.

You use the Search function to search for policy domains and policies.

To search for existing policy domains or policies

  1. From the Policy Manager, click Search in the left navigation pane.

    The Search window appears.

  2. In the Search list at the top left of the page, select either Policy Domain Name or Policy.

  3. Select an entry from the list of search criteria in the middle, then type a text string in the right column.

    To find all entries that match the selected search criterion, leave the right column blank.

  4. Click Go.

    The results display on your page.

4.9.6 Viewing General Information about Policy Domains

You can display a list of policy domains and view configured information for an individual domain. The My Policy Domains page displays a list of domains for which you have administrative rights. Master Access Administrators can see information about all policy domains. Delegated Access Administrators can see only the policy domains for which they have been delegated management.

To view policy domains and configuration information

  1. From the Policy Manager, click My Policy Domains in the left navigation pane.

  2. Click the domain's link to view a domain's configuration settings.

    The General page displays the name and description of the policy domain and whether or not it is enabled. You can click other tabs to view configured information.

4.9.7 Adding Resources to Policy Domains

The Access System defines some resource types by default. A Master Access Administrator can define others. After a resource type is defined, both Master Access Administrators and Delegated Access Administrators can add resources of that type to policy domains they administer. When a Delegated Access Administrator is granted administrative rights for a policy domain, that administrator can add resources to the domain.

4.9.7.1 Using Host Identifiers and Host Contexts

The Master Access Administrator defines host identifiers on the List All Host Identifiers page (Access System Console, Access System Configuration, Host Identifiers link). See "ObPERM cookie" for details.

When you add a resource to a policy domain, you select the host identifier for the machine hosting the resource. If the Master Access Administrator has configured host identifiers for machines, you can select the appropriate one from the list labeled Host Identifiers on the Resource (add) page.

You can use the Host Identifiers feature to create a host context. A host context consists of multiple hosts identified in relation to a single name, a host context name. Instead of adding to a host identifier name the various ways to reference one host, the Master Access Administrator can add corresponding information for multiple hosts to create a context in which all of these hosts share.

A host context is useful if you want to add to a policy domain resources that have the same URL paths on different machines.You want to protect all of these resources in the same way in the same policy domain. In this case, the only variable that distinguishes one set of resources from another is identification of its host machine. Use of a host context provides an efficient way to add the resources for all hosts to the policy domain at once. From the Host Identifiers list, you select the host context name. The rest of the information you enter is the same for all of the sets of resources, so you need only specify it once.

You use the Resources tab page to add resources to a policy domain after you create the domain.

To add resources to a policy domain

  1. From the Policy Manager, click My Policy Domains in the left navigation pane, then click the policy domain link.

  2. Click the Resources tab.

    If resources have been added to this domain, they are listed on this page, otherwise the message appears, "There Are No Resources Defined."

  3. Click the Add button.

    The Resources page appears, as illustrated in the following.

    Image of the Resources page
  4. In the Resource Type field, select an entry.

    The Access System provides two default resource types, HTTP and EJB. Others may be available if your administrator defined them through the System Console.

    Note:

    HTTP covers both HTTP and HTTPS resources.

    If host identifiers were created for individual servers, the Host Identifiers field appears. If no Host Identifiers were defined, this field does not appear on this page.

  5. If a Host Identifiers field appears, select a Host Identifier for the resource.

    The Host Identifier enables the Access System to distinguish between otherwise identical URL prefixes for resources that might exist on multiple hosts.

  6. Select an existing URL prefix to be the basis for the new URL.

    You can see the URL prefixes for existing resources only if you are a Master Access Administrator or if you are a Delegated Access Administrator with rights to view or manage the URL prefix.

  7. You can optionally enter a more specific URL prefix string.

    Enter the URL prefix for the resource using an acceptable format. To add a specific resource, enter the remainder of the URL for that resource in the field, for example:

    • Directory (/marketing/.../)

    • Directory with wildcards (subfolder/*.html)

    • Specific file (marketing/subfolder/marketing.html)

  8. In the next field, enter the name of a region to be appended to the URL prefix.

    For example, if the prefix you selected in the previous step was /your_company, you might enter /sales in this field.

    Note:

    You need to add the / in front of your entry unless you specified / as the policy root during setup.

    You can later reuse the same prefix but add a different appended region, for example:

    /your_company/marketing
    

    After the newly defined region is saved, it appears in the URL Prefix field.

    Note:

    By default, The Access System reads URL prefixes and regions as case-insensitive. To change to case-sensitive, the Access Administrator should use the resource matching feature in the Common Information Configuration/Resource Type Definition function within the Access System Console. If you change this setting, you must restart the Access Servers and AccessGates.
  9. In the Description field, enter a description of the protected region (whether a policy domain or a policy).

    Completing this field is optional.

  10. Determine when you want Access Server caches to be updated:

    • Immediately: Select Update Cache to update all Access Server caches immediately with information about this new prefix.

    • Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.

  11. Click Save.

    The Resource page appears again and displays the name of the new resource.

  12. Click OK to confirm your change.

  13. Repeat these steps to add more resources to this policy domain.

4.9.8 Modifying a Resource's Description

Only the Master Access Administrator can modify a resource's description.

You can modify only the Description field of a resource. If you want to change the resource itself, you must delete it and create a new one.

To change a resource description

  1. From the Policy Manager, select My Policy Domains.

  2. In the My Policy Domains page, click a policy domain's link.

    The policy domain's General page appears.

  3. Click the Resources tab.

    The Resource page appears with a list of resource types included in this policy domain.

  4. Click a resource's link.

    The next page shows the type and prefix of the resource.

  5. Click Modify.

    A new page appears.

  6. Change the Description as needed.

  7. Click Save.

4.9.9 Deleting a Resource

Only the Master Access Administrator can delete resources.

To delete a resource

  1. From the Policy Manager, click My Policy Domains, and select a policy domain's link.

    The General page displays the Name, Description, and Enabled status of the domain.

  2. Click Resources.

    The Resource page appears.

  3. Select the check box for the resource you want to delete and click Delete.

    A message asks you to confirm your decision.

  4. Select or deselect the Update Cache field.

  5. Click OK to delete the prefix (or click Cancel to exit the page without saving).

4.10 About the Master Audit Rule

The Access System enables you to capture and record user activities for protected resources, including user identity information and information about various authentication and authorization activities. You use auditing information to monitor activity for a specific policy domain.

The Access System provides a Master Audit Rule that can be configured by a Master Access Administrator. Delegated Access Administrators can use the Master Audit Rule to create their own audit rules for policy domains and policies. The Access System does not log any audit information to the audit log file until the Master Administrator or Master Access Administrator creates a Master Audit Rule.

The Master Audit Rule contains the following information:

Master Administrators and Master Access Administrators use the Access System Console to configure a Master Audit Rule, using the Add the Master Audit Rule page.

The rest of this section discusses the following topics:

Note:

Making most parameters unchangeable enforces common auditing parameters across all Access Servers.

4.10.1 Configuring the Master Audit Rule

The following procedure describes configuring the Master Audit rule for a server. A Master Access Administrator configures this rule.

To configure a server's Master Audit rule

  1. From the Access System Console, click the Access System Configuration tab, then click Common Information Configuration in the left navigation pane.

  2. Click the Master Audit Rule sub-tab.

  3. Click the Add button on the No Master Audit Rule found page to create the master audit rule.

    The Add the Master Audit Rule page appears, as illustrated in the following.

    Image of Add the Master Audit Rule page
  4. In the Profile Attributes field, enter the identity profile attributes you want to capture.

    These attributes are written to the log file when the event happens. In most cases, cn is the best choice.

    Click the plus (+) and minus (–) icons to add or remove attribute fields.

    The Master Access Administrator can add attributes to this field, but cannot delete the ones you select.

  5. In the Audit Events field, select the events you want to capture.

    Master Access Administrators and Delegated Access Administrators can add or delete events when configuring policy domains.

  6. In the Audit Event Mapping field, enter the strings logged for each event.

    For example, Authentication Success maps to AUTHENT_SUCCESS.

  7. In the Audit Date Type field, select the format in which dates are logged.

  8. In the Audit Escape Character field, type a character that separates fields and ensures that logged information appears correctly in reports.

    If no escape character is specified, audit records will not be escaped.

  9. In the Audit Record Format field, enter data types associated with authentication and authorization activities.

    Note:

    Supported data types for output to a file are shown in the following list. You may want to output to a database (using audit-2-db, for example). In this case, the format string for audit output must be replaced, as described in the auditing information in the Oracle Access Manager Administration Guide.
    • ob_ip: Corresponds to the IP address of the machine making the request.

    • ob_datetime: Corresponds to date and time. The date is logged in the format specified in the master audit policy. The time is logged as hh:mm:ss. The time is always the GMT time on the host that received the request, followed by the host's offset from GMT.

    • ob_serverid: Corresponds to the ID of the Access Server that is auditing this information.

    • ob_url: Request URL.

    • ob_operation: HTTP operation, such as GET, PUT, POST, or others.

    • ob_event: A string corresponding to the event that occurred. The event can be one of the following: Authentication Success, Authentication Failure, Authorization Success, or Authorization Failure.

    • ob_userid: Contains the user's distinguished name, if the user was successfully authenticated.

      If the user is authenticated and has an entry in the directory, in addition to the distinguished name, the log may contain other information that the authentication module of the Access Server is configured to audit. If the user does not exist in the directory, the only information that can be audited is the user name. If the user exists in the directory but enters an incorrect password, there is no way to confirm the user's identity. As a result, this information is not audited. Passwords are never written to the audit log for users who do not log in as Anonymous.

    • ob_wgid: ID of the AccessGate that received the request.

    • ob_date: Corresponds to date only. It does not include the time of the event unless the date format is ISO.

    • ob_time: Corresponds to the GMT time at which the event occurred on the host. Time is always logged as hh:mm:ss+/-<offset from GMT on host>.

    • ob_time_no_offset: Corresponds to the GMT time on the AccessGate, but no GMT offset is logged. Time is logged as hh:mm:ss. Master Access Administrators and Delegated Access Administrators cannot change these settings.

    • ob_reason: Returns information for authentication success, authentication failure, authorization success, and authorization failure events. The overall reason is either ALLOW (for success) or DENY (for failure). However, in the case of DENY, any of the following reasons, which are given by the minor status code, can be the cause for denial of access. Also, a code indicating that there is no reason may be provided when the event is authentication success or authorization success.

      These reasons are returned to clarify the cause of denial, and they are represented by the following integers:

      • 40: An invalid password was provided as input to the authentication process.

      • 68: The overall result of evaluation of the authorization expression was inconclusive.

      • 2: No reason is provided. This code is returned for authentication success and authorization success events.

  10. Determine when you want Access Server caches to be updated.

    • Immediately: Select Update Cache to update all Access Server caches immediately with this auditing information.

    • Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read the new auditing information from the directory server.

  11. Click Save to implement your changes (or Cancel to leave this page without saving).

4.10.2 Modifying the Master Audit Rule

Master Administrators and Master Access Administrators use the Access System Console to modify a Master Audit Rule. You use the Modify the Master Audit Rule page to change the configuration of the Master Audit Rule.

To modify the Master Audit Rule

  1. From the Access System Console, click the Access System Configuration tab, then click Common Information Configuration in the left navigation pane.

  2. Click the Master Audit Rule tab.

  3. Click the Modify button on the Master Audit Rule page.

    The Modify the Master Audit Rule page appears.

  4. Change the parameters as necessary.

  5. Click Save.

4.10.3 Deleting the Master Audit Rule

Master and Master Access Administrators can delete the existing Master Audit Rule from the Master Audit Rule page.

To delete the Master Audit Rule

  1. From the Access System Console, select Access System Configuration, Common Information Configuration, Master Audit Rule

  2. In the Master Audit Rule page, click Delete.

    You are prompted to confirm your decision.

  3. Click OK to delete the rule (or Cancel to exit without saving).

4.11 Configuring Policies

Policies enable you to differentiate how subsets of resources in a domain are protected. You can use policies to establish more or less stringent protection for a subgroup of resources of a policy domain.

A policy can include:

If a resource is not covered by a policy, the default rules of the domain apply.

The following example of a policy domain includes two policies. Boggle Games, Inc. provides human resources information to three categories of personnel: regular employees, part-time employees, and contracted employees. The policy domain includes one URL: /mycompany/HR. Other details of the policies are:

The rest of this section discusses the following topics:

4.11.1 Policies with Overlapping Patterns

If you have multiple policies with overlapping patterns, the order of the policies within the policy domain becomes important. In this case, you should order the policies from the most granular to the least granular.

4.11.2 Adding a Policy

You use the Policies tab page to add a policy to resources of a policy domain. Note that this section assumes that you have created a policy domain, as explained in "To create a policy domain", and added a resource to the policy domain, as explained in "To add resources to a policy domain".

Note:

On some directory servers, adding a very large number of policies and resources may cause a size limit error. In lab conditions, this maximum has only been reached when multiple thousands of resources have been added to the policies.

To add a policy

  1. From the Policy Manager, click My Policy Domains in the left navigation pane.

  2. Click the policy domain that you want to add the policy to.

  3. Select the Policies sub-tab and click Add.

    The policy configuration page appears.

    Policy configuration page. Details follow the image.
  4. Fill in information for the policy.

  5. Click Save.

4.11.3 Modifying a Policy

You use the Policies page to modify a policy.

To modify a policy

  1. From the Policy Manager, click My Policy Domains in the left navigation pane.

  2. Click the link for the policy domain whose policy you want to modify.

  3. Select the Policies tab, select the policy, and click Modify.

  4. On the Policies tab modification page, change the policy information.

  5. Click Save.

4.11.4 Setting the Order in which Policies Are Checked

If you create two or more policies, you can specify the order in which the Access Server checks them. By default, a new policy is checked last.

To set the order of policies within a domain

  1. From the Policy Manager, select My Policy Domains, and click the link for the policy domain.

  2. Select the Policies tab.

  3. Click Order.

  4. Select the name of the policy you want to move within the current order.

    Click the Up and Down arrows to relocate the policy.

    Repeat this process for each of the policies whose order you want to change.

  5. Determine when you want Access Server caches to be updated.

    • Immediately: Select Update Cache to update all Access Server caches immediately with this auditing information.

    • Later: If you do not select Update Cache, the Access Server caches are updated when they time out and read the new auditing information from the directory server.

  6. When you are satisfied with the order of the list of policies, click Save.

4.11.5 Deleting a Policy

You delete a policy directly from the list of policies for the policy domain it belongs to.

To delete a policy

  1. From the Policy Manager tab, select My Policy Domains, click a link for a policy domain, then select the Policies tab.

  2. Select the check box before the name of the policy you want to delete.

  3. Click Delete.

4.11.6 Deploying a Policy into Production

After you have tested a policy domain that you administer, and you are satisfied that resource protection is enacted as planned, you can deploy the domain for production use. To deploy a policy domain, you enable it.

You must also enable a policy domain to test it. See "Using Access Tester" for information describing how to test a policy domain.

4.12 Auditing User Activity for a Policy Domain

Auditing is the process of collecting information about users' activities in relation to the resources of a policy domain or its policies. The Access System automatically audits administrative events, such as clearing information from caches. Audit policies set in the Master Audit Rule and audit rules derived from it determine what is tracked.

You can configure audit policies for:

You can customize audit output to include user profile attributes.You can use audit trails for reporting, history, or any purpose you see fit. For example, you can collect the cn and other attributes of user profiles to maintain detailed information about policy domain usage. This information can be searched and used to generate reports.

The rest of this section discusses the following topics:

4.12.1 Creating an Audit Rule for a Policy Domain

You can create audit rules for a policy domain. A policy domain's audit rule serves as the default rule for all resources of the domain unless you define an audit rule for any of the domain's policies.

You must derive this rule from a Master Audit Rule created by a Master Access Administrator. For details about creating a Master Audit Rule, see "About the Master Audit Rule".

To create an audit rule for a policy domain

  1. From the Access System Console, select Policy Manager, My Policy Domains, and click a link for a policy domain.

    The selected policy domain appears, with the General tab selected.

  2. Click the Default Rules tab.

    The Default Rules tab, when selected, displays sub-tabs for Authentication Rule, Authorization Expression, and Audit Rule.

  3. Click Audit Rule sub-tab.

    A page appears either showing the audit rule defined for the policy domain or reporting that there is no rule defined. If the page states that there is no Master Audit Rule defined, a Master Access Administrator must create one before you can define an audit rule for the policy domain.

  4. Click Add to start the audit rule.

    The Audit Rule page appears. If the Master Audit Rule exists, its values are shown as defaults.

  5. Select the events to be audited and the audit profile attributes.

  6. Click Save.

4.12.2 Modifying an Audit Rule for a Policy Domain

For a policy domain, you can modify existing audit rules, which are derived from the Master Audit Rule.

To modify an audit rule for a policy domain

  1. From the Access System Console, select Policy Manager, My Policy Domains, and click a link for a policy domain.

    The General page for the selected policy domain appears.

  2. Select Default Rules, Audit Rule.

    The General page appears.

  3. Click Default Rules, Audit Rule tab.

    The Audit Rule page appears.

  4. Select the audit rule to be modified.

    A page with the rule's information appears.

  5. Click Modify.

    The rule's page with editable text fields appears.

  6. Modify the information and click Save.

4.12.3 Defining an Audit Rule for a Policy

If you define an audit rule for a policy, it overrides the default one defined for the policy domain. Before you can define a policy's audit rule, a Master Access Administrator must create a Master Audit Rule.

To define an audit rule for a policy

  1. From the Access System Console, select Policy Manager, My Policy Domains, and click a link for a policy domain.

    The General page for the selected policy domain appears.

  2. Click the Policies tab.

  3. Select the policy for which you want to create an audit rule.

  4. Click Audit Rule.

    A page appears either showing the audit rule defined for the policy domain or reporting that there is no rule defined. If the page states that there is no Master Audit Rule, a Master Access Administrator must create one before you can define an audit rule for the policy.

  5. Click Add to start an audit rule.

    The Audit Rule page appears. Values for the Master Audit Rule, if one exists, are shown as defaults.

  6. Select the events to be audited and the audit profile attributes.

  7. Click Save.

4.12.4 Modifying an Audit Rule for a Policy

You can modify the audit rules for the policies of a policy domain. These rules are derived from the Master Audit Rule created by a Master Access Administrator.

To modify an audit rule for a policy

  1. From the Access System Console, select Policy Manager, My Policy Domains, and click a link for a policy domain.

    The General page for the selected policy domain appears.

  2. Click the Policies tab.

  3. Select the policy for which you want to create an audit rule.

  4. Click Audit Rule.

    The Audit Rule page appears.

  5. Select one of the audit rules.

    A page with the rule's information appears.

  6. Click Modify.

    A page with the rule's information in editable text fields appears.

  7. Modify the information, and click Save.

4.12.5 About the Audit Log File

An audit rule causes event-based data to be written to the audit log file. There is one audit log for each Access Server. You can configure the size of the audit log file and the rotation interval for each server. Depending on events recorded, the audit log may contain some duplicate audit entries.

Note:

To audit to a database, by using audit-2-db for example, the format string used for audit output must be replaced, as documented in the Oracle Access Manager Administration Guide. Also, you need to have a supported database installed and specific configuration in the Access System.

4.13 Using Access Tester

Use the Access Tester to verify that the authentication and authorization rules and authorization expressions you created for a policy domain produce the results you expect. You should test the policy domain before you make it available for production. After you select various parameters for your rules and compare the results to what you expect, you may need to make adjustments to your rules.

Note:

You must enable the policy domain before you can test it. See "Enabling and Disabling Policy Domains" for details.

To run Access Tester

  1. From the Policy Manager, click the Access Tester link in the left navigation pane.

  2. In the URL field of the Access Tester page, type the full path to the application or content you want to check.

    The path (with the addition of an http:// or https:// prefix) should bring up a landing page when entered in a browser.

  3. In the Resource Type field, select an entry from the list.

    You can only select a type that has been defined in the Access System Console.

  4. In the Resource Operation field, select the request methods you want to test for this URL.

    Note:

    The operations available in this field depend on the resource type you selected in the previous step.

    If you select none of these, they all are tested.

  5. If you want to know if a particular computer can access the resource (URL), type the computer's IP address into the From this IP Address field.

    You must enter a complete IP address. Wildcards are not allowed in this field.

  6. In the Date/Time of access list, do one of the following:

    • Click the button beside "any" to test this resource without timing restrictions.

    • Click the button beside "specific date and time" and fill in the following Date and Time fields.

  7. In the Check access for the following user(s) field, do one of the following:

    • Click the button beside "all users."

      If you select all users, the Access Tester processes the authentication and authorization information for all users. If there are a great many user entries in your database, this could take a considerable amount of time.

    • Click the button beside "selected users," then click the Select User button to display the Sector page where you can select specific users.

    Note:

    Do not select groups. Access Tester can only test access control for individual users, not groups. Also, it will not resolve groups to the individual level.
  8. In the Show Administrators field, select the number of end users you want to display at one time.

  9. From the list, select the button beside the option that describes the appropriate user access:

    • show only users who are allowed

    • show only users who are

    • show both

    Policy and Rule options are also listed:

    • show matching Policy—If this resource (URL) is protected by a policy, and you want it to display the policy, select the button beside show matching Policy.

    • show matching Rule—If you want the authorization rule for this resource (URL) to be displayed, select the button beside show matching Rule.

  10. Click Submit.

    The results appear.

4.14 Delegating Policy Domain Administration

When a Master Access Administrators creates a policy domain, he or she assumes the role of default Delegated Access Administrator. This default Delegated Access Administrator has all management rights within that domain, and can delegate administration of that domain to others who then become Delegated Access Administrators.

There are three levels of rights for Delegated Access Administrators:

Only Delegated Access Administrators who have rights to a specific domain—or the Master Access Administrator—can view a policy domain.

Delegated Access Administrators can manage policy domains that are delegated to them. They can also create policy domains for resources that fall under the URL prefixes of the policy domains that are delegated to them.

Table 4-4 summarizes the rights of the different types of administrator:

Table 4-4 Types of administrators and their rights

Type of Administrator Policy Domain Rights

Master Administrator

  • Creates Master Access Administrators.

  • Creates the policy root.

  • Creates the policy base.

Master Access Administrator

  • Creates the first policy domain and adds resources to it.

  • Defines resource types.

  • Creates, deletes, and manages authentication and authorization schemes.

  • Creates the Master Audit Rule.

  • Delegates management of policy domains to Delegated Access Administrators.

  • Retains all rights delegated to other users.

Delegated Access Administrator with delegate rights

For that policy domain only, a Delegated Access Administrator with delegate rights can:

  • View the domain.

  • Create authentication and authorization rules.

  • Create an authorization expression for the policy domain and for any policies it contains.

  • Create audit rules based on the Master Audit Rule.

  • Define Delegated Access Administrators with grant or basic rights.

  • Enable or disable the policy domain.

  • Test the policy domain.

Important: The Delegated Access Administrator cannot redefine the attributes of the Master Audit Rule.

Delegated Access Administrator with grant rights

Created by a Master Access Administrator or a Delegated Access Administrator with delegate rights.

For that policy domain only, a Delegated Access Administrator with grant rights can:

  • View the domain.

  • Create and delete authorization rules.

  • Create or modify an authorization expression for the policy domain and for any policies it contains.

  • Create audit rules based on the Master Audit Rule, or change the events to be audited, removing existing events or including other ones.

  • Create and delete policies for resources in the policy domain.

  • Define Delegated Access Administrators with grant or basic rights.

  • Enable or disable the policy domain.

  • Test the policy domain.

Delegated Access Administrator with basic rights

Created by a Master Access Administrator or a Delegated Access Administrator with delegate or grant rights.

A Delegated Access Administrator with basic rights cannot create or delete policy domains. For the specified policy domain, this administrator can:

  • View the domain.

  • Create or delete authentication and authorization rules.

  • Create or modify an authorization expression for the policy domain or any of its policies.

  • Create audit rules based on the Master Audit Rule.

  • Redefine the events to be audited, removing existing events or including other events.

  • Add new attributes to the Master Audit Rule. However, this administrator cannot redefine existing attributes.

  • Create and delete policies for resources.

  • Enable or disable the domain.

  • Using Access Tester, verify access to the resources protected by the policy domain.


4.14.1 Configuring Policy Domain Administrators

Both Master Access Administrators and Delegated Access Administrators can administer policy domains. For details about creating Master Access Administrators, see "Configuring Access Administrators". To create and view Delegated Access Administrators for a policy domain and to modify delegated rights, see the following paragraphs.

To view Delegated Access Administrators for a policy domain

  1. From the Policy Manager, select My Policy Domains and click the policy domain.

  2. Select the Delegated Access Admins tab.

  3. On the Delegated Access Admins page, in the Show Administrators with field, select the Delegate Rights, Grant Rights, or Basic Rights radio button.

    The page is refreshed to display the current users and groups with the selected administrative right for this policy domain. If no users have this right, you receive the message "There are no Delegated Access Admins with this right."

  4. Click the administrator link to display the profile for the user or group.

To delegate rights for a policy domain

  1. From the Policy Manager, select My Policy Domains and click the policy domain.

  2. Select Delegated Access Admins.

  3. Click the radio button for the kind of right that you want to grant.

  4. Click the Modify button at the bottom of the Delegated Access Admin page.

  5. Click Select User.

  6. Use the Search process to display a list of users to select from, and click Done.

  7. Click Save.

To modify policy domain rights

  1. From the Policy Manager, select My Policy Domains.

  2. Click the policy domain.

  3. Select the Delegated Access Admins tab.

  4. Click Modify.

  5. Modify the field values for the rights you want to change.

  6. Click Save.