bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search
e-docs > WebLogic Server > Managing WebLogic Security > Configuring WebLogic Security

Managing WebLogic Security

 Previous Next Contents View as PDF  

Configuring WebLogic Security

The following sections describe the security configuration steps in WebLogic Server 7.0:

Note: If you are customizing the default security configuration, follow the procedures in Customizing the Default Security Configuration then complete the relevant procedures in this chapter.

 

Defining Groups

Note: This section applies to the WebLogic Authentication provider only. If you customize the default security configuration to use another authentication provider, you must use the administration tools supplied by that provider to define a group.

When upgrading to the WebLogic Authentication provider, there is no automatic way to load existing groups into the provider. For WebLogic Server 7.0, defining existing groups in the WebLogic Authentication provider is a manual step. If you have a large number of existing users, consider using the Realm Adapter Authentication provider.

A group represents a set of users who usually have something in common, such as working in the same department in a company. Groups are a means of managing a number of users in an efficient manner. When a group is granted a role or is used to create a security policy, the role or security policy is assigned to all members of the group. For more efficient management, BEA recommends using groups to manage large numbers of users.

By default, WebLogic Server has groups listed in Table 2-1.

Table 2-1 Default WebLogic Groups

Group Name

Permissions

Users

If you identity yourself when you log in (for example, you logged in through a Web page), you are a member of the Users group

Everyone

Regardless of whether you identity yourself when you log in, you are in the Everyone group. (The Everyone group includes the Users group.)

Administrators

View and modify all resource attributes and perform start and stop operations. In order to boot WebLogic Server, a user must be in this group.

Operators

View all resource attributes and perform server lifecycle operations. By default, this group is empty.

Deployers

View all resource attributes and deploy applications such as EJBs. By default, this group is empty.

Monitors

View all resource attributes, modify resource attributes, and perform operations that are not restricted by a role. By default, this group is empty.

 

BEA recommends using initial cap, plural names for groups. Group names must be unique.

To define a group:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Groups.

    The Groupstab appears. This tab displays the names of all groups defined in the Weblogic Authentication provider.

  4. Click the Configure a New Group... link.
  5. On the Groups-->General tab, enter the name of the group.
  6. Enter a short description of the group (for example, Product Managers for Code Examples).
  7. Click Apply to save your changes.
  8. Click the Membership tab to add existing groups to the new group.
    • All the available groups appear in the Possible Groups table.
    • All the groups currently defined for the group appear in the Current Groups table.

    To add a group to another group, highlight the desired group name and click the right arrow to move the group name to the Current Groups table.

  9. Click Apply to save your changes.

If you have a large number of groups, use the Filter option on the Groupstab to search the embedded LDAP server and list the groups that match the search criteria. The Filter option uses the asterisk (*) as the wildcard character. Use the Filter option if you have more than 48 groups.

To delete a group:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Groups.

    The Groupstable appears. This table displays the names of all groups defined in the WebLogic Authentication provider.

  4. To delete a group, click the trash can icon in the corresponding row of the Groups table.

 

Defining Users

Note: This section applies to the WebLogic Authentication provider only. If you customize the default security configuration to use another authentication provider, you must use the administration tools supplied by that provider to define a user.

When upgrading to the WebLogic Authentication provider, there is no automatic way to load existing users into the provider. For WebLogic Server 7.0, adding existing users to the WebLogic Authentication provider is a manual step. If you have a large number of existing users, consider using the Realm Adapter Authentication provider.

Users are entities that can be authenticated. A user can be a person or software entity, such as a Java client. Each user is given a unique identity within a security realm. The minimum password length for a user in the WebLogic Authentication provider is 8 characters. As a system administrator you must guarantee that no two users in the system are identical. For more efficient management, BEA recommends adding users to groups. User names must be unique.

The guest user is no longer supplied by default in WebLogic Server 7.0. To use the guest user, use Compatibility security or define the guest user as a user in the Authentication provider in the default security realm. For more information, see Upgrading Security in the Upgrade Guide for BEA WebLogic Server 7.0.

In WebLogic Server 6.x, any unauthenticated user (anonymous user) was identified as a guest user. WebLogic Server allowed the guest user access to WebLogic resources. However, this functionality presented a potential security risk so the functionality was modified. In 7.0, WebLogic Server distinguishes between the guest user and an anonymous user. To use the guest user as you did in WebLogic Server 6.x, add the guest user to the Authentication provider in the default security realm by setting the following argument when starting WebLogic Server:

-Dweblogic.security.anonymousUserName=guest

Without this argument, an anonymous user has the name <anonymous>. This command-line argument was added to assist existing WebLogic Server customers to upgrade their security functionality. You should take great caution when using the guest user in a production environment.

Note: Do not use the username/password combination weblogic/weblogic in production.

To define a user:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Users.

    The Userstable appears. This table displays the names of all users defined in the WebLogic Authentication provider.

  4. Click the Configure a New User... link.
  5. On the User-->General tab, enter the name of the user.
  6. Enter a password for the user.
  7. Click Apply to save your changes.
  8. Select the Groups tab to add the user to a group.
    • All the available groups appear in the Possible Groups table.
    • All the groups to which the user belongs appear in the Current Groups table.

    To add a user to a group, highlight the desired group name and click the right arrow to move the group name to the Current Groups table.

  9. Click Apply to save your changes.

If you have a large number of users, use the Filter option on the Users tab to search the store and list the users that match the search criteria. The Filter option uses the asterisk (*) as the wildcard character. Use the Filter option if you have more than 48 users.

To delete a user:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Users.

    The Users table appears. This table displays the names of all users defined in the WebLogic Authentication provider.

  4. To delete a user, click the trash can icon in the corresponding row of the Users table.

 

Protecting User Accounts

Weblogic Server provides a set of attributes to protect user accounts from intruders. By default, these attributes are set for maximum protection. As a system administrator, you have the option of turning off all the attributes, increasing the number of login attempts before a user account is locked, increasing the time period in which invalid login attempts are made before locking the user account, and changing the amount of time a user account is locked. Remember changing these attributes lessens security and leaves user accounts vulnerable to security attacks.

To set the User Lockout attributes:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Select the User Lockout tab.
  4. Define the desired attributes on this tab by entering values at the appropriate prompts and selecting the required checkboxes. (For details, see the following table).

    If a user account exceeds the values set for the attributes on this tab, the user account becomes locked and the Users table has the word Details in the table row for the user.

  5. To save your changes, click Apply.
  6. Reboot WebLogic Server.

The following table describes each attribute on the User Lockout tab.

Table 2-2 User Lockout Attributes

Attribute

Description

Lockout Enabled

Requests the locking of a user account after invalid attempts to log in to that account exceed the specified Lockout Threshold. By default, this attribute is enabled.

Lockout Threshold

Number of failed user password entries that can be tried before that user account is locked. Any subsequent attempts to access the account (even if the username/password combination is correct) raise a Security exception; the account remains locked until it is explicitly unlocked by the system administrator or another login attempt is made after the lockout duration period ends. Invalid login attempts must be made within a span defined by the Lockout Reset Duration attribute. The default is 5.

Lockout Duration

Number of minutes that a user's account remains inaccessible after being locked in response to several invalid login attempts within the amount of time specified by the Lockout Reset Duration attribute. The default is 30 minutes.

Lockout Reset Duration

Number of minutes within which invalid login attempts must occur in order for the user's account to be locked.

An account is locked if the number of invalid login attempts defined in the Lockout Threshold attribute happens within the amount of time defined by this attribute. For example, if the value in Lockout Reset Duration attribute is 5 minutes, the Lockout Threshold is 3, and 3 invalid login attempts are made within a 6 minute interval, then the account is not locked. If 3 invalid login attempts are made within a 5 minute period, however, then the account is locked.

The default is 5 minutes.

Lockout Cache Size

Specifies the intended cache size of unused and invalid login attempts. The default is 5.

Lockout GC Threshold

The maximum number of invalid login records that the server keeps in memory. If the number of invalid login records is equal to or greater than the value of this attribute, the server's garbage collection purges the records that have expired. A record expires when the user associated with the record have been locked out. The default is 400 records.

 

Note: The UserLockout attributes apply to the security realm and all its security providers. If you are using an Authentication provider that has its own mechanism for protecting user accounts, disable the Lockout Enabled attribute.

If a user account becomes locked and you delete the user account and add another user account with the same name and password, the UserLockout attribute will not be reset.

 

Unlocking a User Account

To unlock a user account:

  1. Click the Details link in the Users table.

    The Details tab describes the event that occurred when the user was locked out.

  2. Click Unlock.

 

Providing WebLogic Server Users Access to Other Applications

Resource adapters defined by the J2EE Connector Architecture can acquire the credentials necessary to authenticate WebLogic Server users to another application. The Connector container in WebLogic Server can retrieve the appropriate set of credentials for a WebLogic user using a credential map defined in a Credential Mapping provider. A credential map creates an association between a WebLogic Server user and an identity (by default, a username and password combination) used to authenticate that WebLogic Server user to a remote application such as an Oracle database, a SQL server, or a SAP application.

To create a credential map:

  1. Expand the Connectors node.
  2. Right-click on the resource adapter for the remote application.
  3. Click the CredMaps... link.

    The CredMaps tab displays all the credential maps defined in the configured Credential Mapper.

  4. Click the Configure a New Cred Map... link.
  5. Enter a username/password combination name for the remote application.
  6. Click Apply. The information is stored in the embedded LDAP server.
  7. Click the RoleMaps... link.
  8. On the RoleMaps tab, click the Configure a New Role Map... link.
  9. In the WLS User attribute, enter a WebLogic Server user name.
  10. In the Remote User attribute, enter the user name that provides access to the remote application (the user you defined when creating a credential map).
  11. Click Apply.

For more information about resource adapters, credential maps, and the WebLogic Server implementation of the J2EE Connector Architecture, see Programming the J2EE Connector Architecture.

 

Protecting WebLogic Resources

TBS

[This section to be replace by new section from Jen Hocko.]

Understanding Roles

Roles are an abstract, logical collections of users similar to a group. The difference between groups and roles is a group is a static identity that a system administrator assigns, while membership in a role is dynamically calculated based on data such as username, group membership, or the time of day. Roles are granted to individual users or to groups. For more efficient management, BEA recommends granting roles to groups rather than to individual users. Once you create a role, you define an association between the role and a WebLogic resource. This association (called a security policy) specifies who has what access to the WebLogic resource.

WebLogic Server supports two types of roles:

In WebLogic Server 6.x, roles were used to protect EJBs and Web applications only. WebLogic Server version 7.0 expands the use of roles to protect all of the defined WebLogic Server resources. For a list of the defined WebLogic resources, see WebLogic Resources.

Multiple roles (either scoped or global) can be applied to a WebLogic resource. Both scoped and global roles are stored in the default Role Mapping provider. To use a role to create a security policy for a WebLogic resource, the role must be in the Role Mapping provider configured in the default security realm. By default, the WebLogic Role Mapping provider is the configured Role Mapping provider.

Default Global Roles and Permissions

Table 2-3 lists the default global roles provided by WebLogic Server.

Table 2-3 Global Roles and Permissions

Global Role

Permissions

Admin

View and modify the server configuration. Deploy applications, EJBs, startup and shutdown classes, J2EE Connectors, and Web Service components, and edit deployment descriptors.

Deployer

View the server configuration.

Deploy applications, EJBs, startup and shutdown classes, J2EE Connectors, and Web Service components, and edit deployment descriptors.

Operator

View the server configuration.

Start, resume, and stop servers by default.

Monitor

View the server configuration.

anonymous

All users (the group Everyone) are granted this role. This convenience role can be specified in security deployment descriptors in weblogic.xml and weblogic-ejb-jar.xml files.


 

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

Default Group Associations

By default, WebLogic Server grants four of the default groups a global role. By adding a user to one of these groups, the user is automatically granted the global role. (See Table 2-4.)

Table 2-4 Default Group Associations

Members of This Group

Are In This Role

Administrators

Admin

Deployers

Deployer

Operators

Operator

Monitors

Monitor

 

What Is a Role Statement?

A Role statement contains expressions that define who is granted the role. The use of and or in these expressions is important. (You create Role statements when you define roles in the Administration Console.)

For example, the following Role statements are different:

Donna is member of group BankTeller
and Donna is member of group BankManagers

Donna is member of group BankTeller
or Donna is member of group BankManagers

The first expression specifies that user Donna must be a member of the BankTeller group and the BankManager group to be granted the role.

The second expression specifies that user Donna must be either a member of the BankTeller group or the BankManager group to be granted the role.

When granting users and groups roles, the ordering of expressions in a Role statement is important. More restrictive expressions should come later in the Role statement. The entire Role statement must be true in order for the user or group to be granted the role.

Defining Global Roles

Note: BEA recommends using initial cap, singular names for global roles, for example, SecurityEng.

To define a global role:

  1. Expand the Security-->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Roles.

    The Rolestab appears. This tab displays the names of all roles defined in the default Role Mapping provider.

  4. Click the Configure a New Role... link.
  5. On the Roles-->General tab, enter the name of the role. (For example, SecurityEng).
  6. Click Apply.
  7. Grant the role to users and/or groups.

    Select the Roles-->Conditions tab. Use the following options available in the Role Condition table to grant a role to users and/or groups:

    • User name of the caller—Grants a user the role. Multiple users can be granted the same role, however, BEA recommends adding the users to a group and then granting the group the role. The user must be defined in the Authentication provider configured in the default security realm.
    • Caller is member of group—Grants a group the role. Multiple groups can be granted the same role. The group must be defined in the Authentication provider in the default security realm.
    • Hours of Access are between—Specifies a time period in which the role is in effect.
  8. Chose an option and click Add.
  9. On the Add window, enter the name of the user or group that is to be granted the role.

    Use the Add window to grant multiple users or groups a role. As you grant users and groups a role, the users or groups are listed on the Add window.

  10. Click Add.
  11. Use the buttons on the Add window to modify the Role statement:
    • Move Up and Move Down change the ordering of expressions in the Role statement.
    • Change switches the and and or statements in the highlighted expression.
    • Remove deletes the highlighted expression.
  12. Click OK.
  13. In addition to granting a role to users or groups, specify a time period (called a time constraint) in which the role is in effect. For example, you might create a BankTeller role that is only in effect when the bank is open. To associate a time constraint with a role, choose the Hours of Access Are Between option on the Role Condition tab.
  14. In the Time Constraint window, specify the hours during which this role is to be active.
  15. Click OK.
  16. The expressions for the users and groups granted the role and the time constraints for the role appear in the Role statement on the Role Conditions tab. Use Move Up, Move Down, Change, and Edit to modify the Role statement. Reset clears the Role statement.
  17. When you have finished making changes to the users, groups, and time constraints for a role, click Apply to grant the global role.

    The information is stored in a Role Mapping provider. By default, the WebLogic Role Mapping provider is configured and the role information is stored in the embedded LDAP server.

Removing a User, Group, or Time Constraint From a Global Role

  1. Highlight the expression for the user, group, or time constraint in the Role statement on the Role Conditions tab.
  2. Click Remove.
  3. Click Apply to save your change.

Deleting Global Roles

To delete a global role:

  1. Expand the Security -->Realms nodes.
  2. Click the name of the realm you are configuring (for example, myrealm).
  3. Click Roles.

    The Roles table appears. This table displays the names of the global roles defined in the security realm.

  4. To delete a role, click the trash can icon in the corresponding row of the Roles table.

    A confirmation window appears.

  5. Click Yes to delete the global role.

Creating Scoped Roles

To create a scoped role for a WebLogic resource:

  1. Expand the node that contains the WebLogic resource for which you want to create a role and highlight the resource.
  2. Click the right mouse button.
  3. Select the Define Role... link.
  4. Grant users and groups the scoped role as you granted a global role. For more information, see Step 7 in Defining Global Roles. The role applies only to the highlighted resource.
  5. Click Apply.

Understanding WebLogic Security Policies

In the previous release of WebLogic Server, ACLs were used to protect WebLogic resources. In WebLogic Server 7.0, security policies replace ACLs and answer the question "who has access" to a WebLogic resource. A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or roles. You can optionally define a time constraint for a security policy. A WebLogic resource has no protection until you assign it a security policy.

You assign security policies to any of the defined WebLogic resources (for example, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a WebLogic resource (an EJB method or a servlet within a Web Application). If you assign a security policy to a type of resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of resource.

Security policies are stored in an Authorization provider. By default, the WebLogic Authorization provider is configured and security policies are stored in the embedded LDAP server.

To use a user or group to create a security policy, the user or group must be defined in the Authentication provider configured in the default security realm. To use a role to create a security policy, the role must be defined in the Role Mapping provider configured in the default security realm. By default, the WebLogic Authentication and Role Mapping providers are configured.

Default Security Policies

By default, WebLogic Server has defined security policies for the WebLogic resources. These security policies are based on roles and groups. You also have the option of basing a security policy on a user. BEA recommends basing security policies on roles rather than users or groups. Basing security policies on roles allows you to manage access based on a role a user or group is granted, which is a more efficient method of management.

Table 2-5 lists the default security policies.

Table 2-5 Default Security Policies for WebLogic Resources

WebLogic Resource

Security Policy

Administrative resources

Role Admin, Role Deployer, Role Operator, Role Monitor

COM resources

Role jCOMRole

EIS resources

Group Everyone

EJB resources

Group Everyone

JMS resources

Group Everyone

JDBC resources

Group Everyone

JNDI resources

Group Everyone

MBean resources

Group Everyone

Server resources

Role Admin, Role Operator

Web Service resources

Group Everyone

 

What Is a Policy Statement?

A policy statement contains expressions that define who is granted access to the WebLogic resource. The use of and and or in these expressions as well as the ordering of the expressions is important.

More restrictive expressions should come later in the policy statement. The entire policy statement must be true in order for security policy to be created.

Deleting a Security Policy

To delete a security policy:

  1. Navigate to and highlight the WebLogic resource you want to protect with a security policy.
  2. Click the right mouse button.
  3. Select the Define Policy... link.

    The Policy Conditions tab appears.

  4. Click Delete.

    The expressions in the Policy statement are deleted.

  5. Click Apply.

    The security policy is deleted from the Authorization provider.

Removing a User, Group, or Time Constraint From a Policy Statement

To remove a specific user, group, or time constraint from a Policy statement:

  1. Highlight the user, group, or time constraint in the Policy statement on the Policy Conditions tab.
  2. Click Remove.
  3. Click Apply to make the change.

 

Configuring the Embedded LDAP Server

The embedded LDAP server contains user, group, group membership, role, security policy and credential information. The WebLogic Authentication, Authorization, Role Mapping, and Credential Mapping providers use the embedded LDAP server as a storage mechanism. If you use any of these WebLogic security providers, you need to configure the embedded LDAP server.

To configure the embedded LDAP server:

  1. Expand the Domain node (for example, Examples).
  2. Select the Security-->Embedded LDAP tabs.
  3. Configure the attributes on this tab by entering values at the appropriate prompts and selecting the required checkboxes. (See Table 2-6 for a description of the attributes on the Embedded LDAP tab.)
  4. Click Apply to save your changes.
  5. Reboot WebLogic Server.

    Table 2-6 Embedded LDAP Server Attributes

    Attribute

    Description

    Credential

    The credential (usually a password) used to connect to the embedded LDAP server.

    Backup Hour

    The hour at which to backup the embedded LDAP server. The default is 23.

    Backup Minute

    The minute at which to backup the embedded LDAP server. This attribute is used in conjunction with the Back Up Hour attribute to determine the time at which the embedded LDAP server is backed up. The default is 5 minutes.

    Backup Copies

    The number of backup copies of the embedded LDAP server. The default is 7.

    Cache Enabled

    Specifies whether or not a cache is used with the embedded LDAP server.

    Cache Size

    The size of the cache (in K) that is used with the embedded LDAP server. The default is 32K.

    Cache TTL

    The time-to-live (TTL) of the cache in seconds. The default is 60 seconds.

    Refresh Replica At Startup

    Specifies whether or not a Managed Server should refresh all replicated data at boot time. This attribute is useful if you have made a large number of changes while the Managed Server was not active and you want to download the entire replica instead of having the Admin Server push each change to the Managed Server. The default is false.

    Master First

    Specifies that connections to the master LDAP server should always be made instead of connections to the local replicated LDAP server.

     

When you use the embedded LDAP Server in a WebLogic Server domain, updates are sent to a master LDAP server. The master LDAP server maintains a log of all changes. The master LDAP server also maintains a list replicated servers and the current change status for each one. The master LDAP server sends appropriate changes to each replicated server and updates the change status for each server. This process occurs every 30 seconds. The master LDAP server is the embedded LDAP server on the Admin server. The replicated servers are all the Managed Servers in the WebLogic Server domain.

Note: The WebLogic Securiy providers stored their data in the embedded LDAP server. When you delete a WebLogic Security provider, the security data in the embedded LDAP server is not automatically deleted. The security data remains in the embedded LDAP server in case you want to use the provider again. Use an external LDAP browser to delete the security data from the embedded LDAP server.

 

Configuring Backups for the Embedded LDAP Server

To configure the backups of the embedded LDAP server:

  1. Expand the Domain node (for example, Examples).
  2. Click the Security-->the Embedded LDAP tabs.
  3. Set the Backup Hour, Backup Minute, and Backup Copies attributes on the Embedded LDAP Server tab.
  4. Click Apply to save your changes.
  5. Reboot WebLogic Server.

 

Back to Top Previous Next