BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT
	e-docs.bea.com   |   Site Map   |   Search   |   Download Documentation   |   Contact   |   Glossary
|     WebLogic Server Doc Home   |     Administration Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index   |   View as PDF

Managing Security

The following sections describe how to implement security in WebLogic Server:

• Steps for Configuring Security

• Changing the System Password

• Specifying a Security Realm

• Defining Users

• Defining Groups

• Defining ACLs

• Configuring the SSL Protocol

• Configuring Mutual Authentication

• Configuring RMI over IIOP with SSL

• Protecting Passwords

• Installing an Audit Provider

• Installing a Connection Filter

• Setting Up the Java Security Manager

• Modifying the weblogic.policy File for Third Party or User-Written Classes

• Using the Recording Security Manager Utility

• Configuring Security Context Propagation

• SSL Certificate Validation

Steps for Configuring Security

Implementing security in a WebLogic Server deployment largely consists of configuring attributes that define the security policy for that deployment. WebLogic Server provides an Administration Console to help you define the security policy for your deployment. Using the Administration Console, you specify security-specific values for the following elements of your deployment:

• Security realms

• Users and Groups

• Access Control Lists (ACLs) and permissions for WebLogic Server resources

• SSL protocol

• Mutual authentication

• Host Name verification

• Audit providers

• Custom filters

• Security context propagation

Because security features are closely related, it is difficult to determine where to start when configuring security. In fact, defining security for your WebLogic Server deployment may be an iterative process. Although more than one sequence of steps may work, BEA Systems recommends the following procedure:

1. Change the password of the system User to protect your WebLogic Server deployment. See Changing the System Password.

2. Specify a security realm. By default, WebLogic Server is installed with the File realm in place. However, you may prefer an alternate security realm or a custom security realm. See Specifying a Security Realm.

3. Define Users for the security realm. You can organize Users further by implementing Groups in the security realm. See Defining Users.

4. Define ACLs and permissions for the resources in your WebLogic Server deployment. See Defining ACLs.

5. Protect the network connection between clients and WebLogic Server by implementing the SSL protocol. When SSL is implemented, WebLogic Server uses its digital certificate, issued by a trusted certificate authority, to authenticate clients. This step is optional but BEA recommends it. See Configuring the SSL Protocol.

6. Further protect your WebLogic Server deployment by implementing mutual authentication. When mutual authentication is implemented, WebLogic Server must authenticate itself to the client and then the client in turn, must authenticate itself to WebLogic Server. Again, this step is an optional but BEA recommends it. See Configuring Mutual Authentication.

For a complete description of WebLogic Server security features, see Introduction to WebLogic Security and Security Fundamentals.

Note: All configuration steps in this topic are based on the use of the Administration Console.

For information about assigning security roles to WebLogic EJBs, see WebLogic Server 6.1 Deployment Properties.

For information about security in WebLogic web applications, see Assembling and Configuring Web Applications.

Changing the System Password

During installation you specify a password for the system User. The specified password is associated with the system User in WebLogic Server and is stored in the fileRealm.properties file in the \wlserver6.1\config\domain directory where domain is the name specified as the WebLogic Administration domain name during installation. The specified password corresponds to the Administration Server for the domain and all the Managed Servers associated with that Administration Server.

Note: The system User is the only user account under which WebLogic Server can be started.

The password of the system User is encrypted and is further protected when WebLogic Server applies a hash to it. To improve security, BEA recommends frequently changing the system password that was set during installation. Each WebLogic Server deployment must have a unique password.

To change the system password, do the following:

1. In the Administration Console under the Security node, click Users to open the Users.

2. Under Change a User's Password, enter system in the Name attribute field.

3. Enter password you specified when installing WebLogic Server in the Old Password attribute field.

4. Enter a new password in the New Password attribute field.

5. Enter the new password again in the Confirm the Password attribute field.

6. Click Change.

7. Click the Changes You Have Made Must Be Saved to the Realm Implementation link.

8. Submit the change.

9. Reboot WebLogic Server.

When you use an Administration Server and Managed Servers in a domain, the Managed Server must always use the password for the Administration Server in the domain. Always change the password for the Administration Server through the Administration Console. After changing the password, restart all servers in the domain. The process is as follows:

1. Shutdown all the Managed Servers in the domain.

2. Change the system password on the Administration Server following the steps in this section.

3. Shutdown the Administration Server.

4. Reboot the Administration Server using the new system password.

5. Login into the Administration Console using the new system password.

6. Restart all the Managed Servers in the domain.

Maintaining the secrecy of WebLogic passwords is critical to keeping your WebLogic Server deployment and data secure. For your protection, BEA recommends keeping the password of WebLogic Server secret.

Specifying a Security Realm

This section describes configuring a security realm for your WebLogic Server deployment. For an introduction of security realms and how they are used in WebLogic Server, see Security Realms in Programming WebLogic Security. The following sections describe specifying a security realm:

• Configuring the File Realm

• Configuring the Caching Realm

• Configuring the LDAP Security Realm

• Configuring the Windows NT Security Realm

• Configuring the UNIX Security Realm

• Configuring the RDBMS Security Realm

• Installing a Custom Security Realm

• Migrating Security Realms

Configuring the File Realm

By default WebLogic Server is installed with the File realm in place. Before using the File realm, you need to define several attributes that govern the use of the File realm. You set these attributes on the Filerealm tab in the Security window of the Administration Console.

The following table describes each attribute on the Filerealm tab.

Table 14-1 File Realm Attributes

Use the Manage Caching Realm button to clear the user, group, and ACL caches.

Caution: If the fileRealm.properties file becomes corrupted or is destroyed, you must reconfigure the security information for WebLogic Server. WebLogic Server cannot boot without a fileRealm.properties file.

The fileRealm.properties file contains default ACLs used to boot WebLogic Server. Even if you write a custom security realm, you still need a fileRealm.properties file to boot WebLogic Server since the custom security realm is not initially called during the start-up sequence.

Therefore, BEA recommends that you take the following steps:

Make a backup copy of the fileRealm.properties file and put it in a secure place.

Set the permissions on the fileRealm.properties file such that the administrator of the WebLogic Server deployment has write and read privileges and no other users have any privileges.

Note: Also make a backup copy of the SerializedSystemIni.dat file for the File realm. For more information about the SerializedSystemIni.dat file, see Protecting Passwords.

If, instead of the File realm, you want to use one of the alternate security realms provided by WebLogic Server or a custom security realm, set the attributes for the desired realm and reboot WebLogic Server.

Caution: If you use one of the alternate security realms, you must configure and enable the Caching realm; otherwise the alternate security realm will not work.

For more information about security realms in WebLogic Server, see Security Realms.

Configuring the Caching Realm

The Caching realm works with the File realm, alternate security realms, or custom security realms to fulfill client requests with the proper authentication and authorization. The Caching realm stores the results of both successful and unsuccessful realm lookups. It manages separate caches for Users, Groups, permissions, ACLs, and authentication requests. The Caching realm improves the performance of WebLogic Server by caching lookups, thereby reducing the number of calls into other security realms. For more information about security realms in WebLogic Server, see Security Realms.

The Caching realm is installed automatically when you install WebLogic Server: the cache is set up to delegate to the other security realms however caching is not enabled. You have to enable caching through the Administration Console.

Caution: If you use one of the alternate security realms, you must configure and enable the Caching realm; otherwise the alternate security realm will not work.

When you enable caching, the Caching realm saves the results of a realm lookup in its cache. Lookup results remain in the cache until either the specified number of seconds defined for the time-to-live (TTL) attributes has passed (the lookup result has expired) or the cache has filled. When the cache is full, new lookup results replace the oldest cached results. The TTL attributes determine how long a cached object is valid. The higher you set these attributes, the less often the Caching realm calls the secondary security realm. Reducing the frequency of such calls improves the performance. The trade-off is that changes to the underlying security realm are not recognized until the cached object expires.

Note: When you obtain an object from a security realm, the object reflects a snapshot of the object. To update the object, call the object's get() method again. For example, the membership of a Group is set when the Group is retrieved from the security realm with a call to the getGroup() method. To update the members of the Group, you must call the getGroup() method again.

By default, the Caching realm operates on the assumption that the alternate security realm is case-sensitive. In a case-sensitive security realm, the owners of usernames bill and Bill, for example are treated as two distinct Users. The Windows NT Security realm and the LDAP Security realm are examples of security realms that are not case-sensitive. If you are using a security realm that is not case-sensitive, you must disable the CacheCaseSensitive attribute. When this attribute is set, the Caching realm converts usernames to lowercase so that WebLogic Server gives correct results for the security realm when it performs case-sensitive comparisons. When defining or referencing Users or Groups in a case-sensitive security realm, type usernames in lowercase.

To configure the Caching realm:

1. Go to the Security—>Caching Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New Caching Realm link.

3. Define the attributes on the General tab in the Caching Realm Configuration window.

   The following table describes the attributes you set on the General tab.

   Table 14-2 Caching Realm Attributes on the General Tab

   Attribute	Description
   Name	Displays the active security realm as defined in the Administration Console. This attribute can not be changed.
   Basic Realm	Name of the class for the alternate security realm or custom security realm to be used with the Caching realm. The names of the configured realms appear on the pull-down menu.
   Case Sensitive Cache	Defines whether the specified security realm is case-sensitive. By default, this attribute is enabled: the realm is case-sensitive. To use a realm that is not case-sensitive (such as the Windows NT and LDAP security realms), you must disable this attribute.

   
    

4. Click Create.

5. Configure and enable the ACL cache by defining values for the attributes shown on the ACL tab in the Caching Realm Configuration window.

   The following table describes the attributes you set on the ACL tab.

   Table 14-3 ACL Cache Attributes

   Attribute	Description
   Enable Cache	Option for enabling the ACL cache.
   ACL Cache Size	Maximum number of ACL lookups to cache. This attribute should be a prime number for best lookup performance. The default is 211.
   ACL Cache Positive TTL	Number of seconds to retain the results of a successful lookup. The default is 60 seconds.
   ACL Cache Negative TTL	Number of seconds to retain the results of an unsuccessful lookup. The default is 10 seconds.

   
    

6. To save your changes, click the Apply button.

7. To enable and configure the Authentication cache, define values for the attributes shown on the Authentication tab in the Caching Realm Configuration window.

   The following table describes the attributes you set on the Authentication tab.

   Table 14-4 Authentication Cache Attributes

   Attribute	Description
   Enable Authentication Cache	Option for enabling the Authentication cache.
   Authentication Cache Size	Maximum number of Authenticate requests to cache. This attribute should be a prime number for best lookup performance. The default is 211.
   Authentication Cache TTLPositive	Number of seconds to retain the results of a successful lookup. The default is 60 seconds.
   Authentication Cache TTLNegative	Number of seconds to retain the results of an unsuccessful lookup. The default is 10 seconds.

   
    

8. To save your changes, click the Apply button.

9. To enable and configure the Group cache, define values for the attributes shown on the Groups tab in the Caching Realm Configuration window.

   The following table describes the attributes you set on the Group tab.

   Table 14-5 Group Cache Attributes

   Attribute	Description
   Enable Group Cache	Option for enabling the Group cache.
   Group Cache Size	Maximum number of Group lookups to cache. This attribute should be a prime number for best lookup performance. The default is 211.
   Group Cache TTLPositive	Number of seconds to retain the results of a successful lookup. The default is 60 seconds.
   Group Cache TTLNegative	Number of seconds to retain the results of an unsuccessful lookup. The default is 10 seconds.
   Group Membership Cache TTL	Number of seconds to store the members of a group before updating it. The default is 300 seconds.

   
    

10. To save your changes, click the Apply button.

11. To enable and configure the User cache, define values for the attributes shown on the User tab in the Caching Realm Configuration window.

    The following table describes the attributes you set on the User tab.

    Table 14-6 User Cache Attributes

    Attribute	Description
    Enable User Cache	Option for enabling the User cache.
    User Cache Size	Maximum number of User lookups to cache. This attribute should be a prime number for best lookup performance. The default is 211.
    User Cache TTLPositive	Number of seconds to retain the results of a successful lookup. The default is 60 seconds.
    User Cache TTLNegative	Number of seconds to retain the results of an unsuccessful lookup. The default is 10 seconds.

    
     

12. To save your changes, click the Apply button.

13. To enable and configure the Permission cache, define values for the attribute shown on the Permission tab in the Caching Realm Configuration window. T

    The following table describes each attribute on the Permission tab.

    Table 14-7 Permission Cache Attributes

    Attribute	Description
    Enable Permission Cache	Option for enabling the Permission cache.
    Permission Cache Size	Maximum number of Permission lookups to cache. This attribute should be a prime number for best lookup performance. The default is 211.
    Permission Cache TTLPositive	Number of seconds to retain the results of a successful lookup. The default is 60 seconds.
    Permission Cache TTLNegative	Number of seconds to retain the results of an unsuccessful lookup. The default is 10 seconds.

    
     

14. To save your changes, click the Apply button.

15. When you finish defining attributes for the Caching realm, reboot WebLogic Server.

Configuring the LDAP Security Realm

The LDAP security realm provides authentication through a Lightweight Directory Access Protocol (LDAP) server. This server allows you to manage all the users for your organization in one place: the LDAP directory. The LDAP security realm supports Open LDAP, Netscape iPlanet, Microsoft Site Server, and Novell NDS.

In this release of WebLogic Server, you can choose between two versions of the LDAP security realm:

• LDAP realm V1—The LDAP security realm packaged in previous releases of WebLogic Server. With the exception of Microsoft Site Server, the LDAP security realm V1 works with all the supported LDAP servers and is provided for BEA customers that are currently using the LDAP security realm in an older release of WebLogic Server. However, the LDAP realm V1 is deprecated in this release and BEA recommends users upgrade to the LDAP realm V2.

• LPAP realm V2—An updated LDAP security realm with improved performance and configurability. This is the same LDAP security realm provided in WebLogic Server 6.0 Service Pack 1.0. LDAP realm V2 does not support getUsers() or getGroups() due to the fact that allocating memory to fulfill those requests can cause a denial of service vulernability. If you want to use those functions, BEA recommends using LDAP realm V1 When running Windows 2000, BEA recommends using LDAP realm V2 to authenticate against the Windows 2000 User and Group store.

Note: When using LDAP realm V1 you can view Users and members of a Group stored in the LDAP directory server through the Administration Console. However, when using LDAP realm V2, you can only view the Groups stored in the LDAP directory server through the Administration Console.

You need to use the administration tools available with the LDAP server to manage Users and Groups (for example, adding or deleting Users or Groups or adding members to Groups). If you make a change in the LDAP directory store, reset the User cache and the Group cache to immediately view your changes in the Administration Console.

The following suggestions are ways to improve the performance of the LDAP Security realm:

• Use the filters in the ldaprealm.props file to obtain smaller and more specific results sets from the LDAP server (supported for LDAP realm V2 only).

• Have the LDAP server index all of the attributes that you use as search keys in your LDAP realm search filters. Not indexing the attributes could cause linear search performance.

• Use the Caching realm carefully. Changes in the LDAP server's information will not be propagated to the LDAP Security realm until the cache is cleared.

Configuring the LDAP security realm involves defining attributes that enable the LDAP Security realm in WebLogic Server to communicate with the LDAP server and attributes that describe how Users and Groups are stored in the LDAP directory. The LDAP tree and schema is different for every LDAP server. Therefore, the LDAP realm V2 provides a set of templates that define default attributes for the supported LDAP servers.

Restrictions When Using the LDAP Security Realm

The LDAP security realm has the following restrictions:

• When the LDAP server in Microsoft Site Server is installed and the root of the LDAP directory is created, a number of organizational units are created by default. Under Groups there is a default organization unit called NTGroups with a default Group named Administrators, which is empty. By default, WebLogic Server also provides a Group called Administrators that contains a member System which is the User under which WebLogic Server is started. If you use the defaults in Microsoft Site Server and start creating your own Groups under the default organizational unit, WebLogic Server will not start. In order to start WebLogic Server with the LDAP security realm, you need to create your own unique organizational unit in the LDAP directory and create Groups for your WebLogic Server deployment under that organizational unit.

• If you have two Groups within the LDAP directory with the same name, WebLogic Server cannot properly authenticate the Users in the second Group that it locates. The LDAP security realm uses the Group's distinguished name (DN) to locate Groups in the LDAP directory. If you create more than one group with the same name, WebLogic Server only authenticates the Users in the first Group it locates. You must use unique Group names when using the LDAP security realm.

• The LDAP realm V2 does not provide the following functionality provided in LDAP realm V1:

  • Listing all Users

  • Listing the members of a Group

  • The authProtocol and userAuthentication mechanisms have been removed. You need to use the JNDI bind mechanism to pass security credentials to the LDAP server.

• The LDAP realm V2 has issues with the Open LDAP Server when running the getGroups() method for large numbers of groups (more than 300). This problem is due to caching bugs in Open LDAP.

Locating Users and Groups in the LDAP Directory

The LDAP security realm needs to know where the Users and Groups are stored in the LDAP directory used with the security realm. This is done by specifying the distinguished names (DNs) of the LDAP directories that contain the Users and Groups.

In LDAP, a DN starts with a leaf node and goes to the root node. For example:

			root
			  |
			  |
			  |
			o=acme.com
			  |
			  |
			  |
			ou=Groups

The DN for this branch would be specified as ou=Groups, o=acme.com.

In LDAP realm V1, you specify DNs via the GroupDN and UserDN attributes when configuring the security realm. However, you must reverse the DNs. For example, the sample DN would be specified as groupDN="o=acme.com, ou=Groups".

In LDAP realm V2, you specify DNs by adding user.dn and group.dn properties to the Configuration attribute of the CustomRealm MBean. Unlike LDAP realm V1, you do not have to reverse the DN. For example, the user.dn and group.dn properties for a LDAP realm V2 are specified as follows:

ConfigurationData="..., group.dn=ou=Groups, o=acme.com, ..."

A common error when switching between the LDAP realm V1 and LDAP realm V2 is copying over the reverse DNs thus causing the LDAP security realm to stop working. Check your DN specifications when migrating from LDAP realm V1 to LDAP realm V2.

Configuring an LDAP Realm V1

To use the LDAP Security realm V1 instead of the File realm:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New LDAP Realm V1 link.

   The name of the class that implements the LDAP Security realm is displayed.

3. Click Create.

4. To enable communication between the LDAP server and WebLogic Server define values for the attributes shown on the LDAP Realm V1 tab in the LDAP Realm Create window.

   The following table describes the attributes you set on the LDAP Realm V1 tab.

   Table 14-8 LDAP Security Realm Attributes on the LDAP Tab

   Attribute	Description
   LDAPURL	Location of the LDAP server. Change the URL to the name of the computer on which the LDAP server is running and the number of the port at which it is listening. For example: ldap://ldapserver:385. If you want WebLogic Server to connect to the LDAP server using the SSL protocol, use the LDAP server's SSL port in the URL.
   Principal	Distinguished name (DN) of the LDAP User used by WebLogic Server to connect to the LDAP server. This user must be able to list LDAP Users and Groups.
   Credential	Password that authenticates the LDAP User defined in the Principal attribute.
   Enable SSL	Option for enabling the SSL protocol to protect communications between the LDAP server and WebLogic Server. Keep in mind the following guidelines: Disable this attribute if the LDAP server is not configured to use the SSL protocol. If you set the UserAuthentication attribute on the LDAP Users tab to external, this attribute must be enabled.
   AuthProtocol	The type of authentication used to authenticate the LDAP server. Set this attribute to one of the following values: None for no authentication Simple for password authentication CRAM-MD5 for certificate authentication Netscape iPlanet supports CRAM-MD5. Microsoft Site Server, Netscape iPlanet, and OpenLDAP and Novell NDS support Simple.

   
    

5. To save your changes, click the Apply button.

6. To specify how Users are stored in the LDAP directory define the attributes shown on the Users tab in the LDAP Realm Create window.

   The following table describes the attributes you set on the Users tab.

   Table 14-9 LDAP Security Realm Attributes on the Users Tab

   Attribute	Description
   User Authentication	Determines the method for authenticating Users. Set this attribute to one of the following values: Bind specifies that the LDAP security realm retrieves user data, including the password for the LDAP server, and checks the password in WebLogic Server. External specifies that the LDAP security realm authenticates a User by attempting to bind to the LDAP server with the username and password supplied by the WebLogic Server client. If you choose the External setting, you must also use the SSL protocol. Local specifies that the LDAP security realm authenticates a User by looking up the UserPassword property in the LDAP directory and checking it against the passwords in WebLogic Server. If you are using Netscape iPlanet, set this attribute to Bind.
   User Password Attribute	If the User Authentication attribute is set to Local, this attribute is used to find out what LDAP property contains the passwords for the LDAP users.
   User DN	A list of attributes and their values that, when combined with the attributes in the User Name Attribute attribute, uniquely identifies an LDAP User.
   User Name Attribute	The login name of the LDAP User. The value of this attribute can be the common name of an LDAP User but usually it is an abbreviated string, such as the common name.

   
    

7. To save your changes, click the Apply button.

8. To specify how Groups are stored in the LDAP directory, assign values to the attributes shown on the Groups tab in the LDAP Realm Create window.

   The following table describes the attributes you set on the Groups tab.

   Table 14-10 LDAP Security Realm Attribute on the Groups Tab

   Attribute	Description
   Group DN	List of attributes and values that, combined with the Group Name Attribute attribute, uniquely identifies a Group in the LDAP directory. For example, "o=acme.com, ou=Groups".
   Group Name Attribute	Name of a Group in the LDAP directory. It is usually a common name.
   Group Is Context	Boolean checkbox that specifies how Group membership is recorded in the LDAP directory. Check this checkbox if each Group entry contains one User. By default, the box is selected. Uncheck this checkbox if one Group entry contains an attribute for each Group member.
   Group Username Attribute	Name of the LDAP attribute that contains a Group member in a Group entry.

   
    

9. To save your changes, click the Apply button.

10. When you have finished defining all the attributes, reboot WebLogic Server.

11. Configure the Caching realm. For more information, see Configuring the Caching Realm.

    Note: When you use an LDAP Security realm, you must configure and enable the Caching realm; otherwise, the LDAP Security realm will not work.

    When configuring the Caching realm, select LDAP Realm from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the LDAP Realm V1).

12. Go to the Security node.

13. Choose the Filerealm tab.

14. In the Caching Realm attribute, choose the name of the Caching Realm to be used with the LDAP Security realm. A list of configured Caching Realms appears on the pull-down menu.

    Note: When you use an LDAP Security realm, you must configure and enable the Caching realm; otherwise, the LDAP Security realm will not work.

15. Reboot WebLogic Server.

The Caching realm caches Users and Groups internally to avoid frequent lookups in the LDAP directory. Each object in the Users and Groups caches has a TTL attribute that you set when you configure the Caching realm. If you make changes in the LDAP directory, those changes are not reflected in the LDAP Security realm until the cached object expires or is flushed from the cache. The default TTL is 10 seconds for unsuccessful lookups and 60 seconds for successful lookups. Unless you change the TTL attributes for the User and Group caches, changes in the LDAP directory should be reflected in the LDAP Security realm in 60 seconds.

If some server-side code has performed a lookup in the LDAP Security realm, such as a getUser() call on the LDAP Security realm, the object returned by the realm cannot be released until the code releases it. Therefore, a User authenticated by WebLogic Server remains valid as long as the connection persists, even if you delete the user from the LDAP directory.

Configuring an LDAP Realm V2

Configuring the LDAP Realm V2 involves defining attributes that enable the security realm to communicate with the LDAP server and describe where users and groups are stored in the LDAP directory. The LDAP tree and schema is different for every LDAP server. WebLogic Server provides templates for the supported LDAP servers. These templates specify default configuration information used to represent Users and Groups in each of the supported LDAP servers. For more information, see Supported LDAP Server Templates.

To configure a LDAP security realm V2, you choose the template that corresponds to the LDAP server you want to use and modify it to specify information about your specific configuration.

To use a LDAP Security realm V2:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. Choose the LDAP server you want to use with WebLogic Server. The following options are available:

   • defaultLDAPRealmforOpenLDAPDirectoryServices

   • defaultLDAPRealmforNovellDirectoryServices

   • defaultLDAPRealmforMicrosoftSiteServer

   • defaultLDAPRealmforNetscapeDirectoryServer

     The configuration window for the chosen LDAP server appears.

3. Modify the following information in the Configuration Data box:

   • server.host—The host name of the LDAP server.

   • server.port—The port number on which the LDAP server listens.

   • useSSL—Specifies whether or not to use SSL to protect communications between the LDAP server and WebLogic Server. Set the value to true to enable the use of SSL.

   • server.principal—The LDAP user used by WebLogic Server to connect to the LDAP server.

   • server.credential—The password of the LDAP user used by WebLogic Server to connect to the LDAP server.

   • user.dn—The base DN of the tree in the LDAP directory that contains users.

   • user.filter—The LDAP search filter for finding a user given the name of the user.

   • group.dn—The base DN of the tree in the LDAP directory that contains groups.

   • group.filter—The LDAP search filter for finding a group given the name of the group.

   • membership.filter—The LDAP search filter for finding the members of a group given the name of the group.

     For more information, see Supported LDAP Server Templates.

Note: When using the LDAP v2 realm for Microsoft Site server, you must also specify membership.search=true and the following must be added to the user.filter value so that Microsoft Site server does not authenticate disabled users:

user.filter=(&(sAMAccountName=%u)(objectclassname=user)
(!userAccountControl:1.2.840.113556.1.4.803:=2))

1. To save your changes, click the Apply button.

2. Go to the Security node.

3. Choose the Filerealm tab.

4. Configure the Caching realm. For more information, see Configuring the Caching Realm.

   Note: When you use an LDAP Security realm, you must configure and enable the Caching realm; otherwise, the LDAP Security realm will not work.

   When configuring the Caching realm, select the defaultLDAPRealmforLDAPserver (for example, defaultLDAPRealmforOpenLDAPDirectoryServices) from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the LDAP Realm).

5. Reboot WebLogic Server.

Supported LDAP Server Templates

Listing  14-1 through Listing  14-5 are templates used to configure LDAP servers supported by the LDAP V2 Realm.

Warning: Each line in the following code examples must appear on a single line. The code in the code examples has been formatted to fit the margins of this document and some lines have been broken to facilitate that formatting.

Listing 14-1 Default Netscape Directory Server Template

<CustomRealmName="defaultLDAPRealmForNetscapeDirectoryServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=uid=admin,
ou=Administrators,ou=TopologyManagement,o=NetscapeRoot;
server.credential=*secret*;
user.dn=ou=people,o=beasys.com;
user.filter=(&amp;(uid=%u)(objectclass=person));
group.dn=ou=groups,o=beasys.com;
group.filter=(&amp;(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&amp;(uniquemember=%M)
      (objectclass=groupofuniquenames));

"Notes="Before enabling the LDAP V2 security realm, edit the 
configuration parameters for your environment."/>

Listing 14-2 Default Microsoft Site Server Template

<CustomRealmName="defaultLDAPRealmForMicrosoftSiteServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Administrator,ou=Members,
      o=ExampleMembershipDir;
server.credential=*secret*
user.dn=ou=Members, o=ExampleMembershipDir;
user.filter=(&amp;(cn=%u)(objectclass=member)
      (!userAccountControl:1.2.840.113556.1.4.803:=2)));
group.dn=ou=Groups, o=ExampleMembershipDir;
group.filter=(&amp;(cn=%g)(objectclass=mgroup));
membership.scope.depth=1;microsoft.membership.scope=sub;
membership.filter=(|(&amp;(memberobject=%M)
(objectclass=memberof))(&amp;(groupobject=%M)
(objectclass=groupmemberof)));
membership.search=true;

"Notes="Before enabling the LDAP V2 security realm, edit the 
configuration parameters for your environment."/>

Listing 14-3 Default Novell Directory Services Template

<CustomRealmName="defaultLDAPRealmForNovellDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Admin, DC=BEASYS
server.credential= *secret*;
user.dn=ou=people,o=example.com;
user.filter=(&amp;(cn=%u)(objectclass=person));
group.dn=ou=groups,o=example.com;
group.filter=(&amp;(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&amp;(member=%M)
      (objectclass=groupofuniquenames));"

"Notes="Before enabling the LDAP V2 security realm, edit the 
configuration parameters for your environment."/>

Listing 14-4 Default Open LDAP Directory Services Template

<CustomRealmName="defaultLDAPRealmForOpenLDAPDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
ConfigurationData=
"server.host=ldapserver.example.com;
server.port=700;
useSSL=true;
server.principal=cn=Manager, dc=example, dc=com;
server.credential= *secret*;
user.dn=ou=people, dc=example,dc=com;
user.filter=(&amp;(uid=%u)(objectclass=person));
group.dn=ou=groups,dc=example,c=com;
group.filter=(&amp;(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&amp;(uniquemember=%M)     
(objectclass=groupofuniquenames));"

"Notes="Before enabling the LDAP V2 security realm, edit the 
configuration parameters for your environment."/>

Using Microsoft Active Directory with WebLogic Server

By default, WebLogic Server does not support Microsoft Active Directory LDAP server. To use Microsoft Active Directory with WebLogic Server, perform the following steps:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. Choose the defaultLDAPRealmforMicrosoftSiteServer option.

   The configuration window for the chosen LDAP server appears.

3. Modify the following information in the Configuration Data box with information specific to the Microsoft Active Directory LDAP server:

   • server.host—The host name of the LDAP server.

   • server.port—The port number on which the LDAP server listens.

   • useSSL—Specifies whether or not to use SSL to protect communications between the LDAP server and WebLogic Server. Set the value to true to enable the use of SSL.

   • server.principal—The LDAP user used by WebLogic Server to connect to the LDAP server.

   • server.credential—The password of the LDAP user used by WebLogic Server to connect to the LDAP server.

   • user.dn—The base DN of the tree in the LDAP directory that contains users.

   • user.filter—The LDAP search filter for finding a user given the name of the user.

   • group.dn—The base DN of the tree in the LDAP directory that contains groups.

   • group.filter—The LDAP search filter for finding a group given the name of the group.

   • membership.filter—The LDAP search filter for finding the members of a group given the name of the group.

     WebLogic Server authenticates by binding to the LDAP server and passing the DN and password of the user. Even if you have disabled a user account by setting the LDAP userAccountControl attribute to ACCOUNTDISABLE, the authentication will succeed unless you have modified the user.filter value to ignore accounts that have been disable. Modify the user.filter value to only return accounts that do not have the UF_ACCOUNTDISABLE bit set. For example:

     user.filter=(&(sAMAccountName=%u)(objectclassname=user)
(!userAccountControl:1.2.840.113556.1.4.803:=2))

     When specifying the group.filter value, CN must be specified as CN=%G otherwise the filter fails to find the members of a group.

4. To save your changes, click the Apply button.

5. Go to the Security node.

6. Choose the Filerealm tab.

7. Configure the Caching realm. For more information, see Configuring the Caching Realm.

   Note: When you use an LDAP Security realm, you must configure and enable the Caching realm; otherwise, the LDAP Security realm will not work.

   When configuring the Caching realm, select the defaultLDAPRealmforLDAPserver (for example, defaultLDAPRealmforOpenLDAPDirectoryServices) from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the LDAP Realm).

8. Reboot WebLogic Server.

Configuring the Windows NT Security Realm

The Windows NT Security realm uses account information defined for a Windows NT domain to authenticate Users and Groups. You can view Users and Groups in the Windows NT Security realm through the Administration Console, but you must manage Users and Groups through the facilities provided by Windows NT.

The Windows NT Security realm provides authentication (Users and Groups) but not authorization (ACLs). To update the ACL information in the filerealm.properties file that WebLogic Server uses, click the Refresh button on the General tab in the Security node after you change an ACL. If you use Groups with your ACLs, you can reduce the frequency with which you must refresh the information in WebLogic Server. Changing the members of a Windows NT Group allows you to manage individual Users' access to WebLogic Server resources dynamically.

It is possible to use the Windows NT Security realm to authenticate against a Windows 2000 Active Directory primary domain controller. However, the authentication must be from a machine which is a member of the domain not the domain controller itself. There is no way to authenticate to the local User and Group store if the machine running the Windows NT Security realm is a member of another domain.

The Windows NT Security realm can be run on the primary domain controller, on a machine that is a member of a Windows NT domain, or on a machine that is a member of the Windows NT domain and wants to use a mutually trusted domain.

To use the Windows NT Security realm:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New NT Realm link.

3. Configuring the Windows NT Security realm involves setting attributes that define a name for the realm and the computer on which the Windows NT domain is running. To specify a realm name and computer, you must define values for the attributes shown the NT Realm Create window of the Administration Console.

   The following table describes the attributes you set in the NT Realm Configuration window.

   Table 14-11 Windows NT Security Realm Attributes

   Attribute	Description
   Name	The name of the Windows NT Security realm, such as, AccountingRealm
   Primary Domain	The host and port number of the computer where Users and Groups are defined for the Windows NT domain. If you enter multiple host and port numbers, use a comma delineated list.

   
    

4. To save your changes, click the Apply button.

5. When you have finished defining the attributes, reboot WebLogic Server.

6. Configure the Caching realm. For more information, see Configuring the Caching Realm.

   Note: When you use an Windows NT Security realm, you must configure and enable the Caching realm; otherwise, the Windows NT Security realm will not work.

   When configuring the Caching realm, select your Windows NT Security realm from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the Windows NT Security realm).

7. Go to the Security node.

8. Choose the Filerealm tab.

9. In the Caching Realm attribute, choose the name of the Caching Realm to be used with the Windows NT Security realm. A list of configured Caching Realms appears on the pull-down menu.

   Note: When you use an Windows NT Security realm, you must configure and enable the Caching realm; otherwise, the Windows NT Security realm will not work.

10. Reboot WebLogic Server.

Use the following command to verify that you have the correct privileges to run WebLogic Server as the specified Windows NT user:

java weblogic.security.ntrealm.NTRealm username password

where username and password are the username and password of the Windows NT account under which WebLogic Server runs.

The output from this command will tell if the specified username and password authenticated properly.

If the test comes up with an immediate failure stating that the client or user running WebLogic Server does not have the privileges to run the Windows NT Security realm, you need to update the permissions (referred to as rights) for the Windows user running WebLogic Server.

To update the rights in Windows NT:

1. Go to Programs—>Administrative Tools.

2. Select User Manager.

3. Under the Policies menu, choose the User Rights option.

4. Check the Show Advanced Users Rights option.

5. Give the following rights to the Windows user running WebLogic Server:

   • Act as part of the operating system

   • Create a token object

   • Replace a process level token

6. Verify that the Windows user running WebLogic Server is a member of the Administrators group.

7. Reboot Windows NT to ensure all the modifications take effect.

8. Verify that the Logon as System Account option is checked. Note that the Allow System to Interact with Desktop option does not need to be checked. Running the Windows NT Security realm under a specific Windows NT user account does not work.

To update the rights in Windows 2000:

1. Go to Programs—>Administrative Tools.

2. Select Local Security Policy.

3. Go to Local Policies—>User Rights Assignment.

4. Give the following rights to the Windows user running WebLogic Server:

   • Act as part of the operating system

   • Create a token object

   • Replace a process level token

5. Verify that the Windows user running WebLogic Server is a member of the Administrators group.

6. Reboot Windows 2000 to ensure all the modifications take effect.

7. Verify that the Logon as System Account option is checked. Note that the Allow System to Interact with Desktop option does not need to be checked. Running the Windows NT Security realm under a specific Windows NT user account does not work.

The following are common Windows NT error codes that occur when using the Windows NT Security realm:

A full explanation of the Windows NT error codes is found in the winerror.h file.

Configuring the UNIX Security Realm

Note: The UNIX Security realm runs only on the Solaris platform.

The UNIX Security realm executes a small native program, wlauth, to look up Users and Groups and to authenticate Users on the basis of their UNIX login names and passwords. The wlauth program uses PAM (Pluggable Authentication Modules) which allows you to configure authentication services in the operating system without altering applications that use the service.

In UNIX, a user is defined as a member of a group in the following ways:

• The user is defined in a default group in etc/passwd.

• The user ID for a user is included in the etc/group entry for a specific group. The UNIX Security realm supports only this method of determining the members of a group.

After you change an ACL, click the Refresh button on the General tab in the Security to update the information in the filerealm.properties file that WebLogic Server uses. If you use Groups with your ACLs, you can reduce the frequency with which you must refresh the information in WebLogic Server. Changing the members of a UNIX Group allows you to manage individual Users' access to WebLogic Server resources dynamically.

It is possible to run wlauth to verify authentication. At a UNIX command prompt:

1. Enter wlauth.

2. Enter -user_auth username, password.

If the command returns a 0, the authentication check was successful. If the command returns a 1, the authentication check failed.

To use the UNIX Security realm:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New UNIX Realm link.

3. Configuring the UNIX Security realm involves setting attributes that define a name for the realm and the program that provides authentication services for the UNIX Security realm. To define these names, specify values for the attributes on the UNIX Realm Create window of the Administration Console.

   The following table describes the attributes you set in the UNIX Realm Create window.

   Table 14-12 UNIX Security Realm Attributes

   Attribute	Description
   Name	The name of the UNIX Security realm, such as AccountingRealm
   AuthProgram	The name of the program used to authenticate users in the UNIX security realm. In most cases, the name of the program is wlauth.
   Realm Classname	The name of the Java class that implements the UNIX Security realm. The Java class needs to be in the class path of WebLogic Server.

   
    

4. To save your changes, click the Apply button.

5. When you have finished defining the attributes, reboot WebLogic Server.

6. Configure the Caching realm. For more information, see Configuring the Caching Realm.

   Note: When you use an UNIX Security realm, you must configure and enable the Caching realm; otherwise, the UNIX Security realm will not work.

   When configuring the Caching realm, select your UNIX Security realm from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the UNIX Security realm).

7. Go to the Security node.

8. Choose the Filerealm tab.

9. In the Caching Realm attribute, choose the name of the Caching Realm to be used with the UNIX Security realm. A list of configured Caching Realms appears on the pull-down menu.

   Note: When you use an UNIX Security realm, you must configure and enable the Caching realm; otherwise, the UNIX Security realm will not work.

10. Reboot WebLogic Server.

If wlauth is not in the WebLogic Server class path or if you have given the program a name other than wlauth, you must add a Java command-line property when you start WebLogic Server. Edit the script you use to start WebLogic Server and add the following option after the java command:

-Dweblogic.security.unixrealm.authProgram=wlauth_prog

Replace wlauth_prog with the name of the wlauth program, including the full path if the program is not in the search path. Start WebLogic Server. If the wlauth program is in the WebLogic Server path and is named wlauth, this step is not needed.

Configuring the RDBMS Security Realm

The RDBMS Security realm is a BEA-provided custom security realm that stores Users, Groups and ACLs in a relational database.The RDBMS Security realm is an example and is not ment to be used in a production environment. You can perform the following managment functions on the RDBMS Security realm through the Administration Console:

SQL scripts that populate a database are used to create Groups for the RDBMS Security realm

The RDBMS Security realm can be used as a starting point for creating a production security realm. You can extend the RDBMS Security realm by using the following interfaces in the weblogic.security.acl package to add management capabilities to the RDBMS Security realm:

• ManageableRealm—Create Groups, create and delete ACLs, and perform lookups of Users, Groups, and ACLs.

• User—Change the password.

• ACL—Add and remove permissions for Users and Groups.

If you extend the RDBMS Security realm with any of these interfaces, you may also need to update the database schema.

Note: The RDBMS example does not work with databases that have an autocommit feature enabled. If you use the RDBMS example as a starting point for your RDBMS implementation, use explicit commit statements in your code and make sure the autocommit feature in the database you are using is disabled.

To use the RDBMS Security realm:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New RDBMS Realm link.

3. Define information about the class that implements the RDBMS Security realm.

   The following table describes the attributes you set on the General tab.

   Table 14-13 RDBMS Security Realm Attributes on the General Tab

   Attribute	Description
   Name	Name of the RDBMS Security realm, such as, AccountingRealm
   Realm Class	Name of the WebLogic class that implements the RDBMS Security realm. The Java class needs to be in the CLASSPATH of WebLogic Server.

   
    

4. To save your changes, click the Apply button.

5. Define attributes for the JDBC driver being used to connect to the database.

   The following table describes the attributes you set on the Database tab.

   Table 14-14 RDBMS Security Realm Attributes on the Database Tab

   Attribute	Description
   Driver	Full class name of the JDBC driver. This class name must be in the CLASSPATH of WebLogic Server.
   URL	URL for the database you are using with the RDBMS realm, as specified by your JDBC driver documentation.
   User Name	Default user name for the database.
   Password	Password for the default user of the database.

   
    

6. To save your changes, click the Apply button.

7. Define the schema used to store Users, Groups, and ACLs in the database in the Schema Properties box on the Schema tab.

   Listing  14-5 contains the database statements entered in the Schema properties for the RDBMS code example shipped with WebLogic Server in the /samples/examples/security/rdbmsrealm directory.

   Listing 14-5 Sample Schema for RDBMS Security Realm

   "getGroupNewStatement=true;getUser=SELECT U_NAME, U_PASSWORD FROM 
   users WHERE U_NAME = ?;
   getGroupMembers=SELECT GM_GROUP, GM_MEMBER from groupmembers WHERE 
   GM_GROUP = ?;
   getAclEntries=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM 
   aclentries WHERE A_NAME = ? ORDER BY A_PRINCIPAL;
   getUsers=SELECT U_NAME, U_PASSWORD FROM users;
   getGroups=SELECT GM_GROUP, GM_MEMBER FROM groupmembers;
   getAcls=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM aclentries 
   ORDER BY A_NAME, A_PRINCIPAL;
   getPermissions=SELECT DISTINCT A_PERMISSION FROM aclentries;
   getPermission=SELECT DISTINCT A_PERMISSION FROM aclentries WHERE 
   A_PERMISSION = ?;
   newUser=INSERT INTO users VALUES ( ? , ? );
   addGroupMember=INSERT INTO groupmembers VALUES ( ? , ? );
   removeGroupMember=DELETE FROM groupmembers WHERE GM_GROUP = ? AND 
   GM_MEMBER = ?;
   deleteUser1=DELETE FROM users WHERE U_NAME = ?;
   deleteUser2=DELETE FROM groupmembers WHERE GM_MEMBER = ?;
   deleteUser3=DELETE FROM aclentries WHERE A_PRINCIPAL = ?;
   deleteGroup1=DELETE FROM groupmembers WHERE GM_GROUP = ?;
   deleteGroup2=DELETE FROM aclentries WHERE A_PRINCIPAL = ?"
   

8. To save your changes, click the Apply button.

9. When you have finished defining the attributes, reboot WebLogic Server.

10. Configure the Caching realm. For more information, see Configuring the Caching Realm.

    Note: When you use an RDBMS Security realm, you must configure and enable the Caching realm; otherwise, the RDBMS Security realm will not work.

    When configuring the Caching realm, select the RDBMS Security realm from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the alternate security realm (in this case, the RDBMS Security realm).

11. Go to the Security node.

12. Choose the Filerealm tab.

13. In the Caching Realm attribute, choose the name of the Caching Realm to be used with the RDBMS Security realm. A list of configured Caching Realms appears on the pull-down menu.

    Note: When you use an RDBMS Security realm, you must configure and enable the Caching realm; otherwise, the RDBMS Security realm will not work.

14. Reboot WebLogic Server.

Installing a Custom Security Realm

You can create a custom security realm that draws from an existing store of Users such as directory server on the network. To use a custom security realm, you create an implementation of the weblogic.security.acl.AbstractListableRealm interface or the weblogic.security.acl.AbstractManageableRealm interface and then use the Administration Console to install your implementation.

To install a custom security realm:

1. Go to the Security—>Realms node in the left pane of the Administration Console.

2. In the right pane of the Administration Console, click the Configure a New Custom Realm link.

3. Define a name for the custom security realm, specify the interface that implements the realm, and define how the Users, Groups, and optionally ACLs are stored in the custom security realm on the Configuration window.

   The following table describes the attributes you set on the Custom Security Realm Configuration window.

   Table 14-15 Custom Security Realm Attributes

   Attribute	Description
   Name	Name of the Custom Security realm, such as AccountingRealm
   Realm Class Name	Name of the WebLogic class that implements the Custom Security realm. The Java class needs to be in the CLASSPATH of WebLogic Server.
   Configuration Data	Information needed to connect to the security store.
   Password	Password for the Custom Security realm. If a password is supplied, WebLogic Server encrypts it.

   
    

4. To save your changes, click the Create button.

5. When you have finished defining the attributes, reboot WebLogic Server.

6. Configure the Caching realm. For more information, see Configuring the Caching Realm.

   Note: When you use an custom security realm, you must configure and enable the Caching realm; otherwise, the custom security realm will not work.

   When configuring the Caching realm, select the Custom Security realm from the pull-down menu for the Basic attribute on the General tab. The Basic attribute defines the association between the Caching realm and the custom security realm.

7. Go to the Security node.

8. Choose the Filerealm tab.

9. In the Caching Realm attribute, choose the name of the Caching Realm to be used with the custom security realm. A list of configured Caching Realms appears on the pull-down menu.

   Note: When you use an custom security realm, you must configure and enable the Caching realm; otherwise, the custom security realm will not work.

10. Reboot WebLogic Server.

For information about writing a custom security realm, see Writing a Custom Security Realm.

Migrating Security Realms

WebLogic Server provides a management architecture for security realms. The management architecture implemented through MBeans allows you to manage security realms through the Administration Console. If you have a security realm from a previous release of WebLogic Server, use the following information to migrate to the new architecture:

• If you are using the Windows NT, UNIX, or LDAP security realms, use the Convert weblogic.properties option in the Administration Console to convert the security realm to the new architecture. Note that you can view Users, Groups, and ACLs in a Windows NT, UNIX, or LDAP security realm in the Administration Console. However, you still need to use the tools in the Windows NT, UNIX, or LDAP environments to manage Users and Groups.

• If you are using a custom security realm, follow the steps in Installing a Custom Security Realm to specify information about how the Users, Groups, and optionally ACLs are stored in your custom security realm.

• The Delegating security realm is no longer supported. If you are using the Delegating security realm, you will have to use another type of security realm to store Users, Groups, and ACLs.

• If you are using the RDBMS security realm, use one of the following options to convert the security realm:

  • If you did not change the source for the RDBMS security realm, follow the steps in Configuring the RDBMS Security Realm to instantiate a new class for your existing RDBMS security realm and define information about the JDBC driver being used to connect to the database and the schema used by the security realm. In this case, you are creating a MBean in WebLogic Server for the RDBMS security realm.

  • If you customized the RDBMS security realm, convert your source to use the MBeans. Use the code example in the \samples\examples\security\rdbmsrealm directory as a guide to converting your RDBMS security realm. Once you have converted your RDBMS security realm to MBeans, follow the instructions inConfiguring the RDBMS Security Realm to define information about the JDBC driver being used to connect to the database and the schema used by the security realm.

Defining Users

Note: This section explains how to add Users to the File realm. If you are using an alternate security realm, you must use the administration tools provided in that realm to define a User.

User and group names must be unique. You can use multibyte characters and all special characters except a comma (,) in user and group names.

Users are entities that can be authenticated in a WebLogic Server security realm. A User can be a person or a software entity, such as a Java client. Each User is given a unique identity within a WebLogic Server security realm. As a system administrator you must guarantee that no two Users in the same security realm are identical.

Defining Users in a security realm involves specifying a unique name and password for each User that will access resources in the WebLogic Server security realm in the Users window of the Administration Console.

WebLogic Server has two special users, system and guest:

• The system User is the administrative user who controls system-level WebLogic Server operations, such as starting and stopping servers, and locking and unlocking resources. The system User and its password are defined during the WebLogic Server installation procedure. As a security precaution, BEA recommends changing the password for the system User. For more information, see Changing the System Password.

• The guest User is automatically provided by WebLogic Server. When authorization is not required, WebLogic Server assigns the guest identity to a client, thus giving the client access to any resources that are available to the guest user. A client can log in as the guest User by entering guest as the username and guest as the password when prompted by a Web browser or by supplying the guest username and password in a Java client. By default, the guest account is enabled.

  For a more secure deployment, BEA recommends running WebLogic Server with the guest account disabled. To disable the guest account, select the Guest Disabled attribute on the General tab of the Security Configuration window. Disabling the guest account just disables the ability to log in into the account guest; it does not disable the ability for unauthenticated users to access a WebLogic Server deployment.

Warning: Be advised it is still possible to access a deployment through an anonymous user if the ACLs on the anonymous user are not set properly. Set ACLs so that unauthorized access is not possible.

The system and guest Users are like other Users in a WebLogic Server security realm:

• To access WebLogic Server resources, they must have appropriate ACLs.

• To execute an operation on a WebLogic Server resource, they must provide a username and password (or digital certificate).

To define a User:

1. Go to the Security—>Users node in the left pane of the Administration Console.

   The User Configuration window appears.

2. In the User Configuration window, enter the name of the User in the Name attribute.

3. Enter the a password for the User in the Password attribute.

4. Enter the password again in the Confirm Password attribute.

5. Click Create.

To delete a User:

1. Enter the name of the User in the Delete Users box on the User Configuration window.

2. Click Delete.

To change the password of a User:

1. Enter the name of the User in the Name attribute on the User Configuration window.

2. Enter the old password in the Old Password attribute.

3. Enter the new password in the New Password attribute.

4. Enter the new password again to confirm the password change.

While using WebLogic Server, you may have Users that are locked. Perform the following steps to unlock a User:

1. Open the Users window in the Administration Console.

2. Click on the Unlock Users link.

3. Enter the names of the Users you want to unlock in the Users to Unlock field.

4. Choose the servers on which you want the Users unlocked.

5. Click Unlock.

For more information about Users and the access control model in WebLogic Server, see Introduction to WebLogic Security and Security Fundamentals.

Defining Groups

Note: This section describes how to add Groups to the File realm. If you are using an alternate security realm, you need to use the management tools provided in that realm to define a Group.

User and group names must be unique. You can use multibyte characters and all special characters except a comma (,) in user and group names.

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 permission in an ACL, all members of the Group effectively receive that permission. BEA recommends assigning permissions to Groups rather than to individual Users.

By default, WebLogic Server has the following Groups:

• All Users defined in the security realm are automatically members of the everyone Group.

• All Users defined in the security realm except the guest user are automatically members of the users Group.

• The system User is a member of the Administrators Group. This Group should be given the permissions appropriate for a user responsible for starting and stopping servers and maintaining a running WebLogic Server deployment. Access to this group should be limited.

You can register a Group with the WebLogic Server security realm by performing the following steps:

1. Go to the Security—>Groups node in the left pane of the Administration Console.

2. Click the Create a New Group link.

   The Group Configuration window appears.

3. Enter the name of the Group in the Name attribute on the Group Configuration window. BEA recommends naming Groups in the plural. For example, Administrators instead of Administrator.

4. Click on the Users attribute and select the WebLogic Server Users you want to add to the Group.

5. Click on the Groups attribute and select the WebLogic Server Groups you want to add to the Group.

6. Click on the Apply button to create a new Group.

To delete Groups, enter the name of the Group in the Remove These Groups list box on the Group Configuration window and click Remove.

For more information about Groups and the access control model in WebLogic Server, see Introduction to WebLogic Security and Security Fundamentals.

Defining ACLs

Users access resources in a WebLogic Server security realm. Whether or not a User can access a resource is determined by the access control lists ACLs for that resource. An ACL defines the permissions by which a User can interact with the resource. To define ACLs, you create an ACL for a resource, specify the permission for the resource and then grant the permission to a specified set of Users and Groups. BEA recommends assigning ACLs to Groups.

Each WebLogic Server resource has one or more permissions that can be granted. The following table summarizes the functions for various WebLogic Server resources for which permissions can be restricted with an ACL.