Administration Console Online Help

Create root level
policies

Before you begin

Web applications (URLs) and EJBs that are using the DDOnly security
model will ignore root level policies. Modules deployed with this model
use only policies from the deployment descriptors. See Manage security for Web
applications and EJBs.

The policy of a narrower scope overrides policy of a broader scope.
For example, if you create a security policy for an EAR and a policy for
an EJB that is in the EAR, the EJB will be protected by its own policy
and will ignore the policy for the EAR.

To create a root level policy:

In the left
pane of the Administration Console, select Security
Realms.

On the Summary of Security Realms page,
select the name of the realm in which you want to create the policy
(for example, myrealm).

On the Settings page, select the
Roles and Policies tab. Then select the
Policies subtab.

The Roles and Policies: Policies page
organizes all of the domain's resources and corresponding policies
in a tree control.

In the
Policies table, in the
Name column, expand the Root Level
Policies node.

The Root Level Policies node lists all
resource types. For a description of the types of resources that
root level policies secure, see Column Display.

To display the Edit Root Level Policies page
for a resource type, do one of the following:

If the Policy column for a resource
type contains a View Policy link, click the
link. The presence of this link means that a policy has already been
created for the resource type. You can modify this policy to suit
your needs.

Otherwise, click the radio button next to the resource type.
Then click the Create Policy button.

On the Edit Root Level Policies page, if you
have configured more than one authorization provider for the realm,
from the Providers list, select the provider
you want to use to secure this resource.

On the Edit
Root Level Policies page, click Add
Conditions.

On the Choose a Predicate page, in the
Predicate List, select a condition.

Oracle recommends that you use the Role
condition where possible. Basing conditions on security roles
enables you to create one security policy that takes into account
multiple users or groups, and is a more efficient method of
management.

If you selected Role, click
Next, enter the name of a security role in
the argument field, and click Add. If the
security role that you name does not already exist, create one by
that name.

If you selected Group or
User, click Next ,
enter a name in the argument field, and click
Add. If the user or group that you name does
not already exist, create one by that name.

If you selected a boolean predicate (Server is in
development mode , Allow access to
everyone, or Deny access to
everyone), there are no arguments to enter. Click
Finish and go to step 14.

If you selected a context predicate, such as
Context element's name equals a numeric
constant, click Next and enter
the context name and an appropriate value. It is your responsibility
to ensure that the context name and/or value exists at
runtime.

If you selected a time-constrained predicate, such as
Access occurs between specified hours, click
Next and provide values for the
Edit Arguments fields.

Click Finish.

(Optional)
Create additional conditions.

(Optional) The WebLogic Security Service evaluates conditions in
the order they appear in the list. To change the order, select the
check box next to a condition and click the Move
Up or Move Down button.

(Optional)
Use other buttons in the Policy Conditions
section to specify relationships between the conditions:

Select And/Or between expressions to
switch the and /
or
statements.

Click Combine or
Uncombine to merge or unmerge selected
expressions. See Combine Conditions.

Click Negate to make a condition
negative; for example, NOT Group Operators
excludes the Operators group from the role.

Click
Save.

Result

The policy appears on the Roles and Policies:
Policies page in the Policies
table.