Protecting WebLogic Server Applications

In this section, we start with how to secure applications using the default WebLogic Server security providers. We see how these providers work with the J2EE security model and demonstrate how to manage and configure these providers.

Selecting a Realm

To start off, we will use the default realm named myrealm. This realm is configured with WebLogic Server–supplied security providers. When a new domain is created, myrealm is the only realm in that domain and it's the default realm for the new domain as well, as shown in Figure 28.1. Applications running in this domain use myrealm for their security unless another realm is created and set as the default.

Defining Users and Group

The way users, groups, roles, and security policies are configured in this section is particular to the WebLogic default security providers. When using a different provider, please refer to that provider's manual.

The first step in securing applications is to define WebLogic Server users and groups. To define user and groups in a realm, it must have a configured authentication provider. Our default realm starts off configured with the WebLogic authentication provider named DefaultAuthenticator, as shown in Figure 28.2. This provider enables us to set the minimum password required for users.

This provider uses an embedded LDAP server to store user and group information. Together with the WebLogic authorization provider, DefaultAuthenticator introduced in WebLogic 7.x replaces the File realm that was available in WebLogic Server 6.x.

Defining Users

If you already have users and groups defined externally, you won't want to enter them by hand. Please refer to the sections later in this chapter concerning configuring other authentication providers, specifically the section "Using External LDAP Servers."If you're migrating from an older version of WebLogic Server, refer to the section "Migrating Security from Previous WebLogic Server Versions." Also note that if you're migrating, there's no predefined user named guest in WebLogic Server.

To display registered WebLogic Server users, open the Console and click on the Users tab in the left panel. The right panel will display the current users. Although you haven't created any users yet, you'll see a default user is already present. This is the administrator user that boots up WebLogic Server in this domain—it was set up when the domain was created. This user must be part of the Administrators group in order for it to be able to boot WebLogic Server.

New users are created by clicking the Users tab in the left panel and then clicking on the Configure a New User link in the right panel. This will display the Create User form shown in Figure 28.3. Enter the user information and click the Apply button. The username must be unique for the realm. Be sure to enter at least the minimum number of characters for the password.

Users can be added to a group by selecting the user and then clicking on the Groups tag in the right panel. This will display the Groups form as shown in Figure 28.4. To add a user to one or more groups, select the groups in the Possible Groups column and click the highlighted right arrow. To remove a user from one or more groups, select those groups from the Current Groups list and click the highlighted left arrow.

When there are many users, you can display only users whose names meet a filter condition. Type a username in the Filter By: text box and click the Filter button. Only that user will be displayed. You can use the asterisk (*) only as a wildcard character, as shown in Figure 28.5.

A user can be deleted by clicking on the trashcan icon next to his name, as shown in Figure 28.6. Before the user is deleted, you'll have a chance to confirm this action.

Defining Groups

Groups allow collections of users to be categorized according to some common characteristics such as job title, department, and physical location. The choice of groupings should be based on security requirements of applications that will use this realm. When assigning security roles and policies to groups to determine resource access, every member of the group will be assigned the same role and policy. This makes assigning security to large numbers of users a manageable task. You're strongly encouraged to use groups and to choose correct groupings according to your application's security needs. Groups can contain other groups in a hierarchical fashion.

To display registered WebLogic Server groups, click the Groups tab in the left panel—the right panel will display the current groups. WebLogic Server starts with a number of default groups as shown in Table 28.1.

Table 28.1. Default WebLogic Server Groups

Group Name	Description
Administrators	These users can view and change all resource attributes and start and stop WebLogic Server. By default, this group includes the user who started WebLogic Server in this domain.
Operators	These users can view all resource attributes and can start and stop WebLogic Server. This group is initially empty.
Deployers	These users can view all resource attributes and deploy applications and EJBs. This group is initially empty.
Monitors	These users can view and modify all resource attributes and perform unrestricted operations. This group is initially empty.

To crate a new group, click on the Groups tab in the left panel and then click on the Configure a New Group link in the right panel. This displays the Create Group form shown in Figure 28.7. Enter a group name and (optionally) a description, and click the Apply button. Group names must be unique within a realm.

After a group has been created, it can be included in other groups. Groups can be added to other groups by selecting the group and then clicking on the Membership tag in the right panel. This displays the Membership form shown in Figure 28.8. To add a group to one or more groups, select one or more groups in the Possible Groups column and click the highlighted right arrow. To remove a group from one of more groups, select the group from the Current Groups list and click the highlighted left arrow. Creating a group hierarchy allows for easier management of security policies, but only if the hierarchy lends itself to the security requirements of the application the users will be accessing.

When there are many groups, you can display only groups whose names meet a filter condition. Type the group name in the Filter By: text box and click the Filter button. Only that group will be displayed. You can also use the asterisk (*) as a wildcard character as shown in Figure 28.9.

A group can be deleted by clicking on the trashcan icon next to its name, as shown in Figure 28.10. Before the group is deleted, you have a chance to confirm this action.

Granting Global Roles

A role represents a collection of users who share permissions to access restricted resources. Although WebLogic Server groups are static collections whose membership is defined by system administrators, the membership of a role is determined dynamically based on information such as username, group membership, or time of the day. Roles can be assigned to both WebLogic Server users and groups. Security policies are then assigned to roles to determine access to restricted resources. For efficient management, it's recommended to assign roles to groups rather than individual users. WebLogic Server has two different types of roles:

• Global roles— These are roles that span many different resources. We'll later see how global roles can be used to grant permissions to access your applications' components. WebLogic Server ships with a number of default roles, as depicted in Table 28.2. These roles have been granted to WebLogic Server groups by default. Although you can create as many roles as necessary for WebLogic Server applications, only the roles in Table 28.2 can view or change WebLogic Server configuration information.

  Table 28.2. Default WebLogic Server Global Roles

  Role Name	Permissions Granted
  Admin	View and modify server configuration. Deploy most resources. Start and stop WebLogic Server. Includes members from Administrators group.
  Deployer	View nonencrypted server configuration attributes and deploy most resources. Includes members from Deployers group.
  Operator	View nonencrypted server configuration attributes. Start, stop, and resume WebLogic Server. Includes members from Operators group.
  Monitor	View nonencrypted server configuration attributes. Includes members from Monitors group.
  Anonymous	All users are granted this role.

• Scoped Roles— A role that's associated with a specific resource such as access to a JMS connection factory or a JDBC connection pool.

Creating Global Roles

In the administrator console, click on the Globals Roles tab in the left panel and the Configure a New Global Role link in the right panel. Enter the name of a role and click the Apply button. Names of global roles must be unique.

The role statement for a role is a set of conditions that determines membership for that role. To set the role statement for a role, select the role and then click the Conditions tab in the right panel. A role statement is composed of one or more role conditions. Each role condition can be based on username, group membership, and time of the day. Although a role can be based on individual username, it's a much better practice to base it on group membership.

To add a role condition to the role statement, select the role condition in the right panel and click the Add button. A window will open to enable you to further specify the condition.

If you base the new condition on group membership, you can select one or more groups, as shown in Figure 28.11. Type the name of each group and click the Add button. These groups must be defined with the new authentication provider of the realm.

If more than one group is added, you can decide whether a user needs to be in all the groups or at least one of them, as shown in Figure 28.12. Select the word or in the Groups list and click the Change button; doing so changes the word or to the word and.

The connecting word between group names can be one of the following:

• And— Implies that the user must be a member of every group

• Or— Implies that a user must be a member of at least one group

For more complex conditions, ors and ands can be mixed together. If this is done, WebLogic Server evaluates the expression from top to bottom. More restrictive statements should be toward the bottom. Selecting a statement and then clicking the Move Up or the Move Down button changes the order of that statement.

Adding a new condition based on username is essentially the same process as adding a condition based on group membership. A new condition based on time enables you to set the starting and ending times that users are granted this role.

Combining Conditions

As was the case with complex group conditions, a role statement can consist of many individual conditions that are connected with ands and ors, as shown in Figure 28.13. Each and can be changed to an or and vice versa. Click on the line that starts with this word and press the Change button. When creating complex role statements, more restrictive conditions should come later because WebLogic will evaluate these conditions from top to bottom and left to right.

Role information is stored with that user and group information. In the case of the WebLogic authentication and authorization providers, this information is stored in an embedded LDAP server.

Granting Scoped Roles

Scoped roles apply to only a single resource, such as a branch of the server JNDI tree. To grant a scoped role to a resource, highlight the resource in the administrator console, press the right mouse button, and select the Define Scoped Role link, and then click on the Configure a New Scoped Role link. The Create Role form will then be displayed as shown in Figure 28.14. Enter the name of the role and click the Apply button. Then create a role statement in the same way you created a global role. Scoped roles can be applied to many resources, including the JNDI tree, EJB methods, Web services, and Web application components.

Creating Security Policies

After an application client has been successfully authenticated, the process of determining access levels for restricted resources is referred to as authorization. WebLogic Server uses security policies to answer the question of "Who has access?" Instead of using the access control lists (ACLs) employed in previous versions, WebLogic Server now utilizes security policies. Security policies specify access rights for a user, group, or role with a specific resource or type of resource. Out of the box, security policies can also be based on the time of the day. Because the WebLogic Server security framework is very flexible, custom security policies could be based on virtually any data and business logic.

Security policies are used to answer the question of who has access to a restricted resource. A security policy enables us to define a link between a WebLogic Server resource and a user, group, role, or time constraint. Policies can be associated with a type of resource or an individual resource. If assigned to a type, new instances of that type will inherit the same security policy.

WebLogic Server comes with predefined security policies for its resources, as shown in Table 28.3. The policies are based on groups and roles. Although policies can be based on individual users, basing them on roles and groups is highly recommended for efficient management.

Table 28.3. Default WebLogic Server Security Policies

WebLogic Server Resource	Security Policy
Administrative	Admin, Deployer, Operator, and Monitor roles
COM	jCOMRole role
EIS	Everyone group
EJB	Everyone group
JMS	Everyone group
JDBC	Everyone group
JNDI	Everyone group
Mbean	Everyone group
Server	Admin, Operator roles
Web Service	Everyone group

Creating a security policy is like creating a scoped role. First highlight the resource you're interested in. This can be either an individual resource such as a specific EJB or a type of resource such as all EJB deployments. Press the right mouse button and select the Define Security Policy link. Figure 28.15 shows what the security policy screen looks like.

Now create the policy statement based on policy conditions. The instructions for doing this are the same as for roles, with the exception that security policies can be based on username, group membership, role membership, and time of the day. Security policies can be applied to many resources, including the JNDI tree, EJB methods, Web services, and Web application components. Security policies specified in J2EE deployment descriptors can be viewed and modified in the admin console.

The Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) is a universal mechanism for storing virtually any type of information, including information required for ACLs. LDAP provides for a hierarchy of information. Examples of this are that users can be grouped by department, and ZIP Codes can be grouped by county and then by state. There is virtually no limit to the levels of information that can be stored in LDAP. Many software vendors have adopted LDAP for storing user and group information in their products.

Configuring the Embedded LDAP Server

The WebLogic authentication, authorization, role mapping, and credential mapping providers use an embedded LDAP server to store user, group, role, and security policies. Information from these providers is stored in the admin server and replicated to all managed servers in the domain. At the present time, this LDAP server can only be used internally by WebLogic Server. In the future, BEA might open up the LDAP subsystem that would allow applications to store their information there as well.

To change attributes for the embedded LDAP server, click the domain name in the left panel of the admin console. Click on the View Domain Wide Security Settings link at the bottom of the screen, and then click the Embedded LDAP tab. You will then see the Embedded LDAP configuration form, as shown in Figure 28.16. From here, you can change backup, cache, and cluster information.

Using External LDAP Servers

In addition to the default authentication provider, WebLogic Server comes with several other authentication providers that can use Novell's LDAP server, Sun's iPlanet LDAP server, Microsoft's Active Directory LDAP server, and the Open LDAP server. Each of these security providers requires configuration information including the following:

• Host and port of the LDAP server

• WebLogic Server principal and password used to connect to LDAP server

• How users and groups are stored and where they're stored in the LDAP server

To use an external LDAP server, click on the Authentication tab, found under Providers in the appropriate realm in the left pane of the administration console, and select the appropriate LDAP vendor you want to connect with. You then have an opportunity to enter configuration information. An example of this is shown in Figure 28.17.

Migrating Security from Previous WebLogic Server Versions

In the current version of WebLogic Server, the File, Caching, LDAP, Windows NT, Unix, RDBMS, and custom security realms have been deprecated. WebLogic Server now ships with compatibility security to enable you to continue to use your 6.x security realms. The only security realm available in compatibility security is the Compatible realm. The Compatible realm comes with realm adapter providers that allow 6.x security realms to be used. It's important to remember that the realm adapter providers have been deprecated and should not be relied upon for future security. They should be used only until your applications have been upgraded to work with the latest version.

Customizing the Default Realm

So far, we've been using the default realm, myrealm, with all the default WebLogic Server security providers. However, there are many cases in which this configuration will not be sufficient:

• Custom security provider— There are times when the WebLogic security providers won't do. This could involve tapping into an existing security mechanism, such as an external role mapper, or building a more complex provider, such as an advanced adjudicator. For instance, if you already have or want to store user and group information in a database, you need a custom security provider.

• Additional security providers— Your application's security requirements might necessitate additional security providers. For instance, you might want to authenticate against an external LDAP server in addition to the WebLogic Server–embedded LDAP server.

• Migration from a previous WebLogic Server version— When you're ready to upgrade from the Compatible realm, you might need to customize the default security realm. When migrating from the Compatible realm, creating a brand-new realm for testing purposes is recommended. In that realm, you can configure security providers and populate it with security data (user, groups, roles, and security providers). When the new realm is thoroughly tested, set it as the default realm.

Choosing a Default Realm

Every WebLogic Server domain can have one or more security realms. However, only one can be the default realm. To set a realm as the default, click on the domain name in the left panel of the admin console. Click on the View Domain-wide Security Settings link on the bottom right and then click on the General tab underneath. This will display the General Security form shown in Figure 28.18. Select the default realm and click the Apply button.