Security Roles

The following sections describe the features and functions of security roles:

 

Overview of Security Roles

A security role is a privilege granted to users or groups based on specific conditions. Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. Security roles differ from groups as follows:

  • Security roles are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day. Groups are static.
  • Security roles can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).

Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is "in" the security role. For example, an administrator may define a security role called AppAdmin, which has write access to a particular Web Application's resources. Any user or group granted the AppAdmin security role would then have write access to that URL (Web) resource. Multiple users or groups can be granted a single security role. (For more information about users and groups, see Users and Groups.)

Note: In WebLogic Server 6.x, security roles applied to Web Applications and EJBs (Enterprise JavaBeans) only. This version of WebLogic Server expands the use of security roles to all of the defined WebLogic resources. For more information, see Types of WebLogic Resources.

 

Dynamic Role Mapping

At runtime, the WebLogic Security Service compares users or groups against a role condition to determine whether they should be dynamically granted a security role. This process is referred to as role mapping, and occurs just prior to when the WebLogic Security Service renders an access decision for a protected WebLogic resource. An access decision is the component of an Authorization provider that determines whether a subject has permission to perform a given operation on a WebLogic resource.

Note: For more information about role conditions and access decisions, see Components of a Security Role: Role Conditions, Expressions, and Role Statements and Access Decisions" in Developing Security Providers for WebLogic Server, respectively.

This dynamic mapping of security roles to users or groups provides a very important benefit: users or groups can be granted a security role based on business rules, or the context of the request. For example, a user may be allowed to be in a Manager security role only while the actual manager is away. Dynamically granting this security role means that you do not need to change or redeploy your application to allow for such a temporarily arrangement. You simply specify the hours between which the temporary manager should have special privileges. Further, you do not need to remember to revoke these special privileges when the actual manager returns, as you would if you temporarily added the user to a management group.

 

Types of Security Roles: Global Roles and Scoped Roles

There are two types of security roles in WebLogic Server: global roles and scoped roles. A security role that applies to all WebLogic resources deployed within a security realm (and thus the entire WebLogic Server domain) is called a global role. A security role that applies to a specific instance of a WebLogic resource deployed in a security realm (such as a method on an EJB or a branch of a JNDI tree) is called a scoped role. Multiple roles (either global or scoped) can be used to create a security policy for a WebLogic resource. (For more information, see Security Policies.)

While BEA recommends creating security roles and using them (rather than users or groups) to secure WebLogic resources, you do not need to use a particular type of security role. BEA provides several default global roles that you can use out of the box to secure your WebLogic resources; these are described in Default Global Roles. You may never need to use scoped roles. (Scoped roles are provided for their flexibility and are an extra feature for advanced customers.)

 

Using the Administration Console to Create Security Roles

The way you use the WebLogic Server Administration Console to create security roles differs, depending on whether you want to create a global role or a scoped role.

Because global roles apply to all WebLogic resources in a security realm, you create global roles at the security realm level. In the left pane of the Administration Console, expand Security - > Realms - > myrealm (or the name of a security realm you created). Then click Global Roles to display the page that allows you to create a global role. This navigation path is shown on the left side of Figure 4-1, and the resulting page is shown on the right.

Figure 4-1 Creating a Global Role

Creating a Global Role

Because they apply only to a particular WebLogic resource in a security realm, you create scoped roles at the WebLogic resource level. Deployed modules (that is, Web Applications, EJBs, and so on) for which you can create scoped roles show a Define Scoped Role... option when you right-click on them in the Administration Console's navigation tree. Select the Define Scoped Role... option to display the page that allows you to create a scoped role. This navigation path - using the basic-ejbapp JAR as the WebLogic resource - is shown on the left side of Figure 4-2, and the resulting page is shown on the right.

Figure 4-2 Creating a Scoped Role

Creating a Scoped Role

 

Default Global Roles

By default, WebLogic Server defines the global roles shown in Table 4-1. The table also lists the privileges that users or groups in these security roles are granted.

The default global roles are used in the default security policies that protect most types of WebLogic resources. In addition, the default global roles are used to provide additional security for Server resources that are exposed as MBeans. For more information, see Security Policies, and MBean Protections.

Global Role

Privileges

Anonymous All users (the group everyone) are granted this global role.

Note: This global role is provided as a convenience, and can be specified in the weblogic.xml and weblogic-ejb-jar.xml deployment descriptors.

Admin

  • View the server configuration, including the encrypted value of encrypted attributes.

  • Modify the entire server configuration.

  • Deploy Enterprise Applications, startup and shutdown classes, and Web Application, EJB, J2EE Connector, and Web Service modules.

  • Start, resume, and stop servers by default.
Deployer

  • View the server configuration, except for encrypted attributes.

  • Deploy Enterprise Applications, startup and shutdown classes, and Web Application, EJB, J2EE Connector, and Web Service modules.
Operator

  • View the server configuration, except for encrypted attributes.

  • Start, resume, and stop servers by default.
Monitor View the server configuration, except for encrypted attributes.This security role effectively provides read-only access to the WebLogic Server Administration Console, weblogic.Admin utility and MBean APIs.

Note: If you are working directly with WebLogic Server MBeans and want more detailed information about the global roles and their privileges than is shown in Table 4-1, see Protected MBean Attributes and Operations.

You can add to the default global roles by creating your own security roles (global or scoped) as described in Creating Global Roles.

 

Protected MBean Attributes and Operations

Table 4-2 lists the immutable privileges given to users or groups who are granted the Admin default global role, for various WebLogic Server MBeans. In other words, users or groups who are granted the Admin default global role have permission to access the MBean attributes listed in Table 4-2.

Note: Users or groups who are granted the Admin default global role are also given the privileges described in Table 4-3 through Table 4-5.

MBeans

Accessible Attributes

BridgeDestinationCommonMBean UserPassword
BridgeDestinationMBean UserPassword
JDBCConnectionPoolMBean Password, XAPassword
JDBCDataSourceFactoryMBean Password
JMSBridgeDestinationMBean UserPassword
NetworkChannelMBean DefaultIIOPPassword
NodeManagerMBean CertificatePassword
SecurityConfigurationMBean Credential, EncryptedSecretKey, Salt
SecurityMBean Salt, EncryptedSecretKey
ServerMBean SystemPassword,DefaultIIOPPassword, DefaultTGIOPPassword, CustomIdentityKeyStorePassPhrase, CustomTrustKeyStorePassPhrase, JavaStandardTrustKeyStorePassPhrase
ServerStartMBean Password
SSLMBean ServerPrivateKeyPassPhrase
WLECConnectionPoolMBean UserPassword, ApplicationPassword

The MBeans shown in Table 4-2 are all in the weblogic.management.configuration package. For more information on MBeans used to configure WebLogic Server, see System Administration Infrastructure" in the WebLogic Server Administration Guide.

Table 4-3 lists the immutable privileges given to users or groups who are granted the Admin or Deployer default global roles, for various WebLogic Server MBeans. In other words, users or groups who are granted the Admin or Deployer default global roles have permission to access the MBean operations listed in Table 4-3.

MBeans

Accessible Operations

Application, ApplicationConfig All
ConnectorComponent, ConnectorComponentConfig All
DeployerRuntime, DeploymentTaskRuntime All
EJBComponent, EJBComponentConfig All
WebAppComponent, WebAppComponentConfig All
WebServiceComponent, WebServiceComponentConfig All
WebServer, WebServerConfig All
JDBCConnectionPool, JDBCConnectionPoolConfig All
JDBCDataSourceFactory, JDBCDataSourceFactoryConfig All
JDBCMultiPool, JDBCMultipoolConfig All
JDBCDataSource, JDBCDataSourceConfig All
JDBCTxDataSource, JDBCTxDataSourceConfig All
JDBCPoolComponent, JDBCPoolComponentConfig All
JMSBridgeDestination, JMSBridgeDestinationConfig All
JMSConnectionConsumer, JMSConnectionConsumerConfig All
JMSConnectionFactory, JMSConnectionFactoryConfig All
JMSDestination, JMSDestinationConfig All
JMSDistributedDestination, JMSDistributedDestinationConfig All
JMSDistributedDestinationMember, JMSDistributedDestinationMemberConfig All
JMSDistributedTopic, JMSDistributedTopicConfig All
JMSDistributedTopicMember, JMSDistributedTopicMemberConfig All
JMSDistributedQueue, JMSDistributedQueueConfig All
JMSDistributedQueueMember, JMSDistributedQueueMemberConfig All
JMSFileStore, JMSFileStoreConfig All
JMSDestinationKey, JMSDestinationKeyConfig All
JMSServer, JMSServerConfig All
JMSStore, JMSStoreConfig All
JMSSessionPool, JMSSessionPoolConfig All
JMSTemplate, JMSTemplateConfig All
JMSQueue, JMSQueueConfig All
JMSTopic, JMSTopicConfig All
JMSJDBCStore, JMSJDBCStoreConfig All
WTCServer, WTCServerConfig All
WTCBridgeGlobal, WTCBridgeGlobalConfig All
WTCResources, WTCResourcesConfig All
WTCExport, WTCExportConfig All
WTCImport, WTCImportConfig All
WTCLocalTuxDom, WTCLocalTuxDomConfig All
WTCRemoteTuxDom, WTCRemoteTuxDomConfig All
WTCPassword, WTCPasswordConfig All
WTCtBridgeGlobal, WTCtBridgeGlobalConfig All
WTCtBridgeRedirect, WTCtBridgeRedirectConfig All
EJBDescriptor, ConnectorDescriptor, WebDescriptor All
Server addDeployment, lookupServerLifeCycleRuntime, lookupServerRuntime, removeDeployment, sendNotification
ServerConfig addDeployment, lookupServerLifeCycleRuntime, removeDeployment, sendNotification

Table 4-4 lists the immutable privileges given to users or groups who are granted the Admin or Monitor default global roles, for various WebLogic Server MBeans. In other words, users or groups who are granted the Admin or Monitor default global roles have permission to access the MBean operations listed in Table 4-4.

MBeans

Accessible Operations

Machine lookupNodeManagerRuntime
NodeManagerRuntime getStateForAll, register
Server lookupServerLifeCycleRuntime, lookupServerRuntime

Table 4-5 lists the immutable privileges given to users or groups who are granted the Admin or Operator default global roles, for various WebLogic Server MBeans. In other words, users or groups who are granted the Admin or Operator default global roles have permission to access the MBean operations listed in Table 4-5.

MBeans

Accessible Operations

ServerLifeCycleRuntime All
ServerLifeCycleTaskRuntime All
ServerStart All
Server ExpectedToRun, lookupServerLifeCycleRuntime, lookupServerRuntime, sendNotification, start, suspend
ServerConfig ExpectedToRun, lookupServerLifeCycleRuntime, sendNotification
ServerRuntime forceShutdown, resume, shutdown, start, stop

 

Default Group Associations

By default, WebLogic Server grants four default global roles to four default groups. When you add a user to one of these groups, the user is automatically granted the global role. These default group associations are shown in Table 4-6.

Members of This Group

Are In This Global Role

Administrators Admin
Deployers Deployer
Operators Operator
Monitors Monitor

 

Components of a Security Role: Role Conditions, Expressions, and Role Statements

A role condition is a condition under which a security role (global or scoped) will be granted to a user or group. The role conditions that are available in this release of WebLogic Server are:

  • User Name of the Caller - Creates a condition for a security role based on a user name. For example, you might create a condition indicating that only the user John can be granted the BankTeller security role.
  • Caller is a Member of the Group - Creates a condition for a security role based on a group. For example, you might create a condition indicating that only users in the group FullTimeBankEmployees can be granted the BankTeller security role. BEA recommends this role condition for more efficient security management.
  • Hours of Access are Between - Creates a condition for a security role based on a specified time period. For example, you might create a condition indicating that the BankTeller security role can only be granted to users when the bank is open.

    When you use the Hours of Access are Between role condition, the security role will be granted to all users during the hours you specify, unless you further restrict the users by adding one of the other role conditions.

These role conditions, along with the specific information you supply for the condition (such as an actual user name, group, or start/stop times), are called expressions. An example of an expression that you may see in the WebLogic Server Administration Console is shown in Figure 4-3.

Figure 4-3 Expression Example

Expression Example

In this expression example, the first line is the role condition, the second line is the specific information you supply for the condition - in this case, a group called FullTimeBankEmployees.

A role statement is a collection of expressions that define how a security role is granted, and is therefore the main part of any security role you create. The ability to use multiple expressions means that you can create complex security roles that meet your organization's security requirements. The use of and and or between these expressions, as well as the ordering of the expressions, is also an important feature:

  • And is used to specify that all the expressions must be true in order for the security role to be granted.
  • Or is used to specify that at least one of the expressions must be true in order for the security role to be granted.

The entire role statement must be true in order for a user or group to be granted the security role. More restrictive expressions should come later in a role statement.

An example of a role statement that you may see in the Administration Console is shown in Figure 4-4.

Figure 4-4 Role Statement Example

Role Statement Example

In this role statement example, there are two expressions: the first and second lines contain an expression based on the Caller is a Member of the Group role condition, and the third and fourth lines contain another expression based on the Hours of Access are Between role condition.

 

Working with Global Roles

The following sections provide instructions for working with global roles:

Note: This section describes how to create, modify, and delete global roles. Because they are always scoped to a WebLogic resource, instructions for creating, modifying, and deleting scoped roles are provided under Working with Scoped Roles.

 

Creating Global Roles

Notes: The section Using the Administration Console to Create Security Roles may also be helpful to review before creating security roles. If you are creating global roles that will be used to secure Server resources, be sure to adhere to the advice given in Maintaining a Consistent Security Scheme.

To create a new global role:

  1. In the left pane of the WebLogic Server Administration Console, expand Security - > Realms.
  2. Expand the security realm for which you are creating a global role (for example, myrealm).
  3. Click Global Roles to display the Global Roles page and table of currently defined global roles.
  4. Click Configure a new Global Role....

    Note: If multiple WebLogic Role Mapping providers are configured in the security realm, an intermediate page will list them in a table. From the table,select which WebLogic Role Mapping provider's database should store information for the new global role before performing step 5.

  5. On General tab, enter the name of the global role in the Name field.

    Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list: \t, < >, #, |, &, ~, ?, ( ), { }. Security role names are case sensitive. All security role names are singular and the first letter is capitalized, according to the BEA convention.

    The proper syntax for a security role name is as defined for an Nmtoken in the Extensible Markup Language (XML) Recommendation.

  6. Click Apply to save your changes.
  7. Select the Conditions tab to display the Role Editor page (see Figure 4-5).

    Figure 4-5 Role Editor Page

    Role Editor Page

  8. In the Role Condition list box, click one of the conditions. (For more information about the different role conditions, see Components of a Security Role: Role Conditions, Expressions, and Role Statements.)

    BEA recommends that you create expressions using the Caller is a Member of the Group condition where possible. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

  9. Click Add to display a customized window. (See Figure 4-6.)

    Figure 4-6 Customized Window for Caller is a Member of the Group Condition

    Customized Window for Caller is a Member of the Group Condition

  10. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, then click OK. The window closes and an expression appears in the Role Statement list box. (See Figure 4-7 for an example.)

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, then click Add. An expression appears in the list box.

      You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      Move Up and Move Down change the ordering of the highlighted user or group name, and therefore the order in which they are evaluated. Change switches the highlighted and and or statements between expressions. Remove deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement. The window closes and the expression appears in the Role Statement list box. (See Figure 4-7.)

      Figure 4-7 Example Expression in Role Statement List Box

      Example Expression in Role Statement List Box

  11. If desired, repeat steps 8-10 to add expressions based on different role conditions.
  12. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • Move Up and Move Down change the ordering of the highlighted expression, and therefore the order in which they are evaluated.
    • Change switches the highlighted and and or statements between expressions.
    • Edit... reopens the customized window for the highlighted expression and allows you to modify the expression.
    • Remove deletes the highlighted expression.
  13. When all the expressions in the Role Statement list box are correct, click Apply.

    The General tab appears.

    Note: You can also click Reset at the bottom of the Role Editor page to restore the page to its original state (that is, to undo any of your changes).

 

Modifying Global Roles

The procedure for modifying global roles is, for the most part, the same as the procedure for creating a new global role.

  1. In the left pane of the WebLogic Server Administration Console, expand Security - > Realms.
  2. Expand the security realm from which you are modifying a global role (for example, myrealm).
  3. Click Global Roles.

    The Global Roles page displays all the global roles currently defined in the WebLogic Role Mapping provider's database.

  4. From the table, select the global role that you want to modify.

    A table that lists all the scoped roles for the WebLogic resource appears in the right pane.

  5. Select the Conditions tab to display the Role Editor page.
  6. Make your changes, using steps 8- 12 in Creating Global Roles as a guide.
  7. Click Apply to save your changes.

 

Deleting Global Roles

To delete a global role:

  1. In the left pane of the WebLogic Server Administration Console, expand Security - > Realms.
  2. Expand the security realm from which you are deleting a global role (for example, myrealm).
  3. Click Global Roles.

    The Global Roles page displays all the global roles currently defined in the WebLogic Role Mapping provider's database.

  4. Click the trash can icon that is located in the same row as the global role you want to delete.
  5. Click Yes to confirm the deletion.
  6. Click Continue.

    The Global Roles page no longer shows the deleted global role in the table.

 

Working with Scoped Roles

The following sections provide instructions for working with scoped roles for the various types of WebLogic resources:

 

Creating Scoped Roles

To create a scoped role for a WebLogic resource:

Note that the instructions for working with scoped roles vary slightly from WebLogic resource to WebLogic resource. Be sure to follow any variations noted in this procedure that pertain to the type of WebLogic resource with which you are working. For more information, see Types of WebLogic Resources.

 

Step 1: Select the WebLogic Resource

Follow the instructions in the appropriate section to select the type of WebLogic resource for which you will be creating a scoped role:

 

Administrative Resources

In the left pane of the WebLogic Server Administration Console, right-click the name of the WebLogic Server domain (for example, examples), and choose Define Scoped Role... to display the Scoped Roles page.

If available, a table of currently defined scoped roles appears in the right pane.

 

Application Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments - > Applications.

    Optionally expand the Enterprise Application (EAR) for which you are creating a scoped role to see the different types of WebLogic resources it contains.

  2. Right-click the name of an Enterprise Application (EAR) and choose Define Scoped Role... to display the Scoped Roles page.

    If available, a table of currently defined scoped roles appears in the right pane.

 

COM Resources

If a package of EJB classes (such as ejb20.basic.beanManaged.*) will be accessed by a COM client:

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments, then EJB.

    The EJB node expands to show the EJB JARs that are currently deployed.

  2. Right-click the name of an EJB JAR containing the EJB that will be used to access the package, and choose Define Policies and Roles for Individual Beans... to display a list of EJBs.
  3. Click the [Define JCOM Roles] link that is located in the same row as the EJB that will be used to access the package.

    The General tab's COM Class field already shows the name of the package to which you want to scope the security role.

    The value in the COM class field is a Java class or package name that is exposed to COM via the jCOM bridge.

  4. Click the Define Role... button to display the Select Roles page.

    If available, a table of currently defined scoped roles appears in the right pane.

If a package of Java classes (such as java.util.*) or individual classes (such as java.util.Collection) will be accessed by a COM client:

  1. In the left pane of the WebLogic Server Administration Console, expand Services.
  2. Right-click the JCOM node and choose Define Role....
  3. On the General tab, in the COM class field, enter the name of the Java class or package to which you want to scope the security role.

    The value you enter in the COM class field is a Java class or package name that is exposed to COM via the jCOM bridge.

  4. Click the Define Role... button to display the Select Roles page.

    If available, a table of currently defined scoped roles appears in the right pane.

 

EIS Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of WebLogic resources that can be deployed.

  2. Right-click at the level of the EIS resource for which you want to create the scoped role, and choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating a scoped role for all Connectors, right-click Connector Modules in the navigation tree. If you will be creating a scoped role for a particular Connector, expand Connector Modules, then right-click the name of a Connector. Figure 4-8 illustrates where you might click, using the basic-connector as an example.

    Figure 4-8 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

    If available, a table of currently defined scoped roles appears in the right pane.

 

EJB Resources

Note that these instructions also apply to Message-driven Beans (MDBs).
  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of WebLogic resources that can be deployed.

  2. Right-click at the level of the EJB resource for which you want to create the scoped role.

    If you will be creating a scoped role for all EJB JARs, right-click EJB Modules in the navigation tree. If you will be creating a scoped role for a particular EJB JAR, or for an EJB within a JAR, expand EJB Modules, then right-click the name of an EJB JAR. Figure 4-9 illustrates where you might click, using the basic-ejbapp JAR as an example.

    Figure 4-9 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

  3. If you will be creating the scoped role for all EJB JARs or for a particular EJB JAR (that is, for all the EJBs in the JAR), choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating the scoped for a particular EJB in an EJB JAR, follow these steps:

    1. Choose Define Policies and Roles for Individual Beans... to display a list of EJBs.
    2. Click the [Define Scoped Roles] link that is located in the same row as the EJB for which you want to create the scoped role.

    If available, a table of currently defined scoped roles appears in the right pane.

 

JDBC Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Services - > JDBC.

    The JDBC node expands to show nodes for various JDBC components (connection pools, MultiPools, and data sources).

  2. Right-click at the level of the JDBC resource for which you want to create the scoped role, and choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating a scoped role for all connection pools, right-click Connection Pools in the navigation tree. If you will be creating a scoped role for a particular connection pool, expand Connection Pools, then right-click the name of a connection pool. To create a scoped role for an individual MultiPool, expand MultiPools, then right-click the name of the MultiPool.

    Note: You cannot create a scoped role that encompasses all MultiPools.

    Figure 4-10 illustrates where you might click, using various connection pools and a MultiPool as an example.

    Figure 4-10 Services Portion of the Administration Console Navigation Tree

    Services Portion of the Administration Console Navigation Tree

    If available, a table of currently defined scoped roles appears in the right pane.

 

JMS Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Services - > JMS.

    The JMS node expands to show nodes for various JMS components (connection factories, templates, destination keys, and so on).

  2. Right-click at the level of the JMS resource for which you want to create the scoped role, and choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating a scoped role for all JMS components, right-click JMS in the navigation tree. If you will be creating a scoped role for a particular destination on a JMS server, expand Servers, then the JMS server and the Destinations node, then right-click the name of a destination. Figure 4-11 illustrates where you might click, using various destinations on the examplesJMSServer as an example.

    Figure 4-11 Services Portion of the Administration Console Navigation Tree

    Services Portion of the Administration Console Navigation Tree

    If available, a table of currently defined scoped roles appears in the right pane.

 

JNDI Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Servers.

    The Servers node expands to show the servers available in the current WebLogic Server domain.

  2. Right-click the name of a server that contains the JNDI resource for which you want to create the scoped role. (For example, myserver.)
  3. From the menu that appears, select the View JNDI Tree option.

    The JNDI tree for the server appears in a new Administration Console window.

  4. In the new Administration Console window, right-click at the level of the JNDI tree at which you want to create the scoped role, and choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating a scoped role for a group of objects, right-click the node in the navigation tree that represents that object type. If you will be creating a scoped role for a particular object, expand the node that represents that object, then right-click the name of an object.

    Figure 4-12 illustrates where you might click, using the examplesServer JNDI tree as an example.

    Figure 4-12 New Administration Console Window for examplesServer JNDI Tree

    New Administration Console Window for examplesServer JNDI Tree

    If available, a table of currently defined scoped roles appears in the right pane.

 

Server Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Servers.

    The Servers node expands to show the different Server resources for which a scoped role can be created.

  2. Right-click at the level of the Server resource at which you want to create the scoped role, and choose Defined Scoped Role... to display the Scoped Roles page.

    If you will be creating a scoped role for all servers, right-click Servers in the navigation tree. If you will be creating a scoped role for a particular server, expand Servers, then right-click the name of a server. Figure 4-13 illustrates where you might click, using the examplesServer as an example.

    Figure 4-13 Servers Portion of the Administration Console Navigation Tree

    Servers Portion of the Administration Console Navigation Tree

    If available, a table of currently defined scoped roles appears in the right pane.

 

URL Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.

    The Deployments node expands to show the types of WebLogic resources that can be deployed.

  2. Right-click at the level of the URL (Web) resource at which you want to create the scoped role.

    If you will be creating a scoped role for all Web Applications (WARs), right-click Web Application Modules in the navigation tree. If you will be creating a scoped role for a particular WAR or a component in a WAR (for example, a specific servlet or JSP), expand Web Application Modules, then right-click the name of a Web Application (WAR). Figure 4-14 illustrates where you might click, using the basic-webapp WAR as an example.

    Figure 4-14 Deployments Portion of the Administration Console Navigation Tree

    Deployments Portion of the Administration Console Navigation Tree

  3. If you will be creating the scoped role for all Web Applications (WARs), choose Define Scoped Role... to display the Scoped Roles page.

    If you will be creating the scoped role for a particular WAR, or a component within a WAR, follow these steps:

    1. Choose Define Scoped Role... to display the General tab.
    2. Enter a URL pattern in the text field.

      A URL pattern is a path to a specific component within a Web Application. Or, you can use /* to associate the scoped role with all components (servlets, JSPs, and so on) within the Web Application.

    3. Click the Define Scoped Role... button to display the Scoped Roles page.

    If available, a table of currently defined scoped roles appears in the right pane.

 

Web Service Resources

  1. In the left pane of the WebLogic Server Administration Console, expand Deployments.
  2. If the Web Service is packaged as an EAR file, expand Applications, then expand the name of the application that contains the Web Service. The application expands to show the components that make up the application, including the Web Service Web Application.

    If the Web Service is packaged as a stand-alone Web Application, expand Web Application Modules. Note that the Web Services icon designates a Web Service.

  3. Right-click the name of the Web Service and choose Define Scoped Role... to display the Scoped Roles page.

    If available, a table of currently defined scoped roles appears in the right pane.

 

Step 2: Create the Scoped Role

  1. On the Scoped Roles page, click Configure a new Scoped Role....

    Note: If multiple WebLogic Role Mapping providers are configured in the security realm, an intermediate page will list them in a table. From the table,select which WebLogic Role Mapping provider's database should store information for the new scoped role before performing step 5.

  2. On the General tab, enter the name of the scoped role in the Name field.

    Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list: \t, < >, #, |, &, ~, ?, ( ), { }. Security role names are case sensitive. All security role names are singular and the first letter is capitalized, according to BEA convention.

    The proper syntax for a security role name is as defined for an Nmtoken in the Extensible Markup Language (XML) Recommendation.

    Warning: If you create a scoped role with the same name as a global role, the scoped role takes precedence over the global role.

  3. Click Apply to save your changes.

 

Step 3: Create the Role Conditions

  1. Select the Conditions tab to display the Role Editor page (see Figure 4-15).

    Figure 4-15 Role Editor Page

    Role Editor Page

  2. In the Role Condition list box, select one of the conditions. (For more information about the different role conditions, see Components of a Security Role: Role Conditions, Expressions, and Role Statements.)

    BEA recommends that you create expressions using the Caller is a Member of the Group condition where possible. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

    Because the JMS subsystem performs its security check only once and the Hours of Access are Between condition requires a subsequent security check, you should not use the Hours of Access are Between condition if you are creating a scoped role for a JMS resource.

  3. Click Add to display a customized window. (See Figure 4-16.)

    Figure 4-16 Customized Window for Caller is a Member of the Group Condition

    Customized Window for Caller is a Member of the Group Condition

  4. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, then click OK. The window closes and an expression appears in the Role Statement list box. (See Figure 4-17 for an example.)

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, then click Add. An expression appears in the list box.

      You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      Move Up and Move Down change the ordering of the highlighted user or group name, and therefore the order in which they are evaluated. Change switches the highlighted and and or statements between expressions. Remove deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement. The window closes and the expression appears in the Role Statement list box. (See Figure 4-17.)

      Figure 4-17 Example Expression in Role Statement List Box

      Example Expression in Role Statement List Box

  5. If needed, repeat steps 2- 4 to add expressions based on different role conditions.
  6. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • Move Up and Move Down change the ordering of the highlighted expression, and therefore the order in which they are evaluated.
    • Change switches the highlighted and and or statements between expressions.
    • Edit... reopens the customized window for the highlighted expression and allows you to modify the expression.
    • Remove deletes the highlighted expression.
  7. When all the expressions in the Role Statement list box are correct, click Apply.

    The General tab is displayed.

    Note: You can also click Reset at the bottom of the Role Editor page to restore the page to its original state (that is, to undo any of your changes).

 

Modifying Scoped Roles

To modify a scoped role for a WebLogic resource:

  1. Navigate to the Scoped Roles page for the WebLogic resource, as described in Step 1: Select the WebLogic Resource.
  2. From the table, select the scoped role that you want to modify.

    A table that lists all the scoped roles for the WebLogic resource appears in the right pane.

  3. Select the Conditions tab.
  4. Make your changes, using the instructions in Step 3: Create the Role Conditions as a guide.
  5. Click Apply to save your changes.

 

Deleting Scoped Roles

To delete a scoped role for a WebLogic resource:

  1. Navigate to the Scoped Roles page for the WebLogic resource, as described in Step 1: Select the WebLogic Resource.

    A table that lists all the scoped roles for the WebLogic resource appears in the right pane.

  2. Click the trash can icon that is located in the same row as the scoped role you want to delete.
  3. Click Yes to confirm the deletion.
  4. Click Continue.

    The Scoped Roles page no longer shows the deleted scoped role in the table.

Skip navigation bar  Back to Top Previous Next