Securing WebLogic Resources
The following sections describe the features and functions of security policies:
A security policy is an association between a WebLogic resource and one or more users, groups, or security roles and is designed to protect the WebLogic resource against unauthorized access.
Note: Security policies replace the access control lists (ACLs) and permissions that were used to protect WebLogic resources in previous releases of WebLogic Server.
Security policies are always scoped to a WebLogic resource, but because WebLogic resources are hierarchical, the level at which you define a security policy is up to you. For example, you can define security policies on an entire enterprise application (EAR), an EJB JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.
If you create a security policy for a type of WebLogic resource (for example, EJB resources), all new instances of that WebLogic resource inherit the security policy. This inheritance of security policies means that you can secure multiple WebLogic resources efficiently. Out of the box, WebLogic Server secures each WebLogic resource type with a default security policy that is inherited by all instances of that WebLogic resource. For more information, see Default Security Policies.
A security policy created for a specific instance of a WebLogic resource will override any security policy assigned to the WebLogic resource type. So, if you create a security policy for a particular EJB, this security policy (and not the one you created for the EJB resource type) will be used.
Security policies are stored in the security provider database of the Authorization provider that is configured in the default (active) security realm. By default, the WebLogic Authorization provider is configured, and security policies are stored in the embedded LDAP server.
When creating a security policy with a user or group, the user or group must be defined in the security provider database of the Authentication provider that is configured in the default security realm. When creating a security policy with a security role, the security role (whether global or scoped) must be defined in the security provider database of the Role Mapping provider that is configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured, and the default groups and default global roles are stored in the databases for these security providers (also the embedded LDAP server).
For more information about the WebLogic Authentication, Authorization, and Role Mapping providers, see The WebLogic Security Providers in Introduction to WebLogic Security.
By default, WebLogic Server defines the security policies shown in Table 6-1. These security policies are defined for each type of WebLogic resource described in Types of WebLogic Resources, and are based on the default global roles and default groups.
Note: You can access default security policies in the Administration Console. See Access root-level policies in Administration Console Online Help.
Caution: Do not modify the default security policies for Administrative and Server resources to make them more restrictive. Eliminating some of the existing security roles might negatively impact the functioning of WebLogic Server. However, if you like, you can make the default security policies more inclusive (for example, by adding new security roles).
The WebLogic Server Administration Console, the WebLogic Scripting Tool (WLST), and MBean APIs are secured using the default security policies, which are based on the default global roles and default groups described in Table 5-2. Therefore, to use the Administration Console, a user must belong to one of these default groups or be granted one of these global roles. Additionally, administrative operations that require interaction with MBeans are secured using the MBean protections described in MBean Protections. Therefore, interaction with the following protected public interfaces typically must satisfy both security schemes.
For information about using this public interface, see the Administration Console Online Help.
weblogic.management.NoAccessRuntimeException
, which developers can catch explicitly in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out. For information about using this public interface, see WebLogic Scripting Tool.
Note: WLST is a convenience utility that abstracts the interaction with the MBean APIs (described next). Therefore, for any administrative task you can perform using WLST, you can also perform using the MBean APIs.
weblogic.management.NoAccessRuntimeException
, which developers can catch explicitly in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out. For information about using these APIs, see Protected MBean Attributes and Operations and Managing Security Realms with JMX in Developing Custom Management Utilities with JMX.
A policy condition is a condition under which a security policy will be created. WebLogic provides three kinds of built-in policy conditions. You can use these conditions in any logical combination:
The basic policy conditions that are available in this release of WebLogic Server are:
Role
—Creates a condition for a security policy based on a security role. For example, you might create a condition indicating that only users and groups in the BankTeller
security role can access the Deposit
EJB.For some WebLogic resources, WebLogic server assigns a default security policy based on one of the built-in global security roles. For more information, see Default Global Roles and Default Security Policies.
User
—Creates a condition for a security policy based on a user name. For example, you might create a condition indicating that only the user John
can access the Deposit
EJB.Group
—Creates a condition for a security policy based on a group. When a group is used to create a security policy, the security policy is assigned to all members of the group. For example, you might create a condition indicating that only users in the group FullTimeBankEmployees
can access the Deposit
EJB.Server is in Development Mode
—Creates a condition for a security policy based on whether the server is running in development mode.Allow access to everyone
—Creates a condition for a security policy that includes all users and groups.Deny access to everyone
—Creates a condition for a security policy that excludes all users and groups. Element requires signature by
—Creates a condition for a security policy based on who has digitally signed an element in the SOAP request message that invokes a Web Service operation. For example, you might create a condition that says the getBalance
operation can only be invoked if the AccountNumber
element in the incoming SOAP request has been digitally signed by the BankTeller
security role. Note: This policy condition is used only when securing Web Services and individual Web Service operations.
When you use any of the date and time conditions, the security policy grants access to all users for the date or time you specify, unless you further restrict the users by adding one of the other role conditions. The date and time policy conditions available in this release of WebLogic Server are:
Access occurs between specified hours
—Creates a condition for a security policy based on a specified time period. For example, you might create a condition granting access to users only during business hours. Access occurs after
—Creates a condition for a security policy based on a time after a specified time. For example, you might create a condition that grants access to users after the business opens or after a certain date and time.Access occurs before
—Creates a condition for a security policy based on a time before a specified time. For example, you might create a condition that grants access to users before the business closes or before a certain date and time.Access occurs on specified days of the week
—Creates a condition for a security policy based on specified days. For example, you might create a condition that grants access to users on week days.Access occurs on the specified day of the month
—Creates a condition for a security policy based on an ordinal day of the month. For example, you might create a condition that grants access to users only the first day of each month. Access occurs after the specified day of the month
—Creates a condition for a security policy based on a time after an ordinal day in the month. For example, you might create a condition indicating that grants access to users after the 15th day of the month.Access occurs before the specified day of the month
—Creates a condition for a security policy based on a time before an ordinal day in the month. For example, you might create a condition that grants access to users before the 15th day of the month.You can use the context element conditions to create security policies based on the value of HTTP Servlet Request attributes, HTTP Session attributes, and EJB method parameters. WebLogic Server retrieves this information from the ContextHandler object and allows you to defined policy conditions based on the values. When using any of these conditions, it is your responsibility to ensure that the attribute or parameter/value pairs apply to the context in which you are using them. For more information, see ContextHandlers and WebLogic Resources in Developing Security Providers for WebLogic Server.
The context element role conditions available in this release of WebLogic Server are:
Context element defined
—Creates a condition for a security policy based on the existence of a specified attribute or parameter.Context element's value equals a numeric constant
—Creates a condition for a security policy based on a specified attribute or parameter's number value (or string representing a double number) being equal to a specified double
number.Context element's value is greater than a numeric constant
—Creates a condition for a security policy based on a specified attribute or parameter's number value (or string representing a double number) being greater than a specified double
number.Context element's value is less than a numeric constant
—Creates a condition for a security policy based on a specified attribute or parameter's number value (or string representing a double number) being less than a specified double
numberContext element's value equals a string constant
—Creates a condition for a security policy based on a specified attribute or parameter's string value being equal to a specified string.Policy conditions, combined with specific information you supply for the condition (such as an actual role name, or start/stop times), are called expressions. One or more expressions that define the policy are known collectively as a policy statement (see next section). For example: only users who are included in the BankTeller
security role and during regular banking hours can access a business Web application.
A policy statement is a collection of expressions that define how a security role is granted. The ability to use multiple expressions means that you can create complex security roles that meet your organization's security requirements. You can also use and
or
operators between expressions, and you can reorder and negate expressions. For details, see Create Security Policies in Administration Console Online Help.
The entire role statement must be true in order for a user, group, or security role to be granted the security role. More restrictive expressions should come later in a policy statement.
You can use the WebLogic Administration Console to access WebLogic resources for creating and modifying security policies. For more information, see Manage Security Policies in Administration Console Online Help.