|bea.com | products | dev2dev | support | askBEA|
|e-docs > WebLogic Server > Managing WebLogic Security > Configuring WebLogic Security|
Managing WebLogic Security
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.
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.
BEA recommends using initial cap, plural names for groups. Group names must be unique.
To define a group:
The Groupstab appears. This tab displays the names of all groups defined in the Weblogic Authentication provider.
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.
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:
The Groupstable appears. This table displays the names of all groups defined in the WebLogic Authentication provider.
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:
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:
The Userstable appears. This table displays the names of all users defined in the WebLogic Authentication provider.
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.
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:
The Users table appears. This table displays the names of all users defined in the WebLogic Authentication provider.
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:
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.
The following table describes each attribute on the User Lockout tab.
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.
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.
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 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:
The Details tab describes the event that occurred when the user was locked out.
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:
The CredMaps tab displays all the credential maps defined in the configured Credential Mapper.
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
[This section to be replace by new section from Jen Hocko.]
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.
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.)
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:
The Rolestab appears. This tab displays the names of all roles defined in the default Role Mapping provider.
Select the Roles-->Conditions tab. Use the following options available in the Role Condition table to grant a role to users and/or groups:
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.
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
Deleting Global Roles
To delete a global role:
The Roles table appears. This table displays the names of the global roles defined in the security realm.
A confirmation window appears.
Creating Scoped Roles
To create a scoped role for a WebLogic resource:
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.
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:
The Policy Conditions tab appears.
The expressions in the Policy statement are deleted.
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:
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:
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.
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.
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: