| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Managing WebLogic Security > Using Compatibility Security |
|
Managing WebLogic Security
|
The following sections describe how to set up Compatibility Security and manage an existing 6.x security configuration:
Note: Compatibility security is deprecated in WebLogic Server 7.0. You should only use Compatibility security while upgrading your WebLogic Server deployment to the security features in WebLogic Server 7.0.
Setting Up Compatibility Security: Main Steps
To set up Compatibility security:
For more information, see theUpgrade Guide for BEA WebLogic Server 7.0.
To verify whether you are correctly running Compatibility security, do the following:
During installation WebLogic Server does the following to the File realm in mydomain:
These steps ensure that a system user is defined in the 7.0 version of the File realm and that the SerializedSystemIni.dat file is created.
To improve security, BEA recommends frequently changing the system password that was set during installation. Each WebLogic Server deployment must have a unique password.
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. The new password is propagated to 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 Compatibility Security Realm
The following sections describes configuring a security realm for your WebLogic Server deployment:
Note: The File realm, Caching realm, LDAP, Windows NT, UNIX, and RDBMS security realms are deprecated in WebLogic Server 7.0. In addition, the use of WebLogic Server 6.x custom security realms is deprecated in WebLogic Server 7.0.
By default WebLogic Server is installed with the File realm in place. The File Realm stores user and group data for the purpose of Authentication. Before using the File realm, you need to define several attributes that govern the use of the File realm.
The following table describes each attribute on the File Realm tab.
Table 4-1 File Realm Attributes
All user and group data for the File realm is stored in the fileRealm.properties file. If the fileRealm.properties file becomes corrupted or is destroyed, you must reconfigure the security information for WebLogic Server. Compatibility security cannot run without a fileRealm.properties file. Even if you write a custom security realm, you still need a fileRealm.properties file to boot WebLogic Server because the custom security realm is not initially called during the start-up sequence. Therefore, BEA recommends that you take the following steps:
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 User Accounts
If, instead of the File realm, you want to use one of the alternate security realms provided by WebLogic Server, or use a custom security realm, set the attributes for the desired realm and reboot WebLogic Server. If you use one of the alternate security realms, you must enable the Caching realm. Alternate security realms include the LDAP, Windows NT, UNIX, and RDBMS security realms
The Caching realm works with 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.
The Caching realm is installed automatically when you run Compatibility security: 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. If you are using an alternate security realm or a custom security realm, you must configure and enable the Caching realm after you configure an alternate or custom security realm.
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:
The following table describes the attributes you set on the General tab.
Table 4-2 Caching Realm Attributes on the General Tab
The following table describes the attributes you set on the ACL tab.
The following table describes the attributes you set on the Authentication tab.
The following table describes the attributes you set on the Group tab.
The following table describes the attributes you set on the User tab.
The following table describes each attribute on the Permission tab.
Configuring the LDAP V1 Security Realm
The Lightweight Directory Access Protocol (LDAP) V1 security realm provides authentication through an LDAP server. This server allows you to manage all the users for your organization in one place: the LDAP directory. The LDAP V1 security realm supports Open LDAP, Netscape iPlanet, Microsoft Site Server, and Novell NDS.
Configuring the LDAP V1 security realm involves defining attributes that enable the LDAP V1 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 V2 security realm provides a set of templates that define default attributes for the supported LDAP servers.
The Difference between the LDAP V1 and LDAP V2 Security Realms
Choose between two versions of the LDAP security realm:
Note: LDAP V1 security realm allows you to view users and members of a group stored in the LDAP directory server through the Administration Console. However, with LDAP V2 security realm, 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.
To improve LDAP Security realm performance:
Restrictions When Using the LDAP Security Realm
The LDAP security realm has the following restrictions:
Configuring an LDAP V1 Security Realm
To use the LDAP V1 security realm instead of the File realm:
The following table describes the attributes you set on the LDAP Realm V1 tab.
The following table describes the attributes you set on the Users tab.
The following table describes the attributes you set on the Groups tab.
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 V1 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 when you configured the Caching realm, changes in the LDAP directory should be reflected in the LDAP V1 security realm in 60 seconds. For more information about TTL attributes, see Configuring the Caching Realm.
If some server-side code has performed a lookup in the LDAP V1 security realm, such as a getUser() call on the LDAP V1 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 V2 Security Realm
When using the LDAP V2 security realm, 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. You choose the template that corresponds to the LDAP server you want to use and then fill in the host and port of the LDAP server, and the GroupDN, the UserDN, Principal, and Credential attributes. For information about these attributes, see Configuring an LDAP V1 Security Realm.
To use a LDAP V2 security realm:
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 Refresh on the General tab in the Security node after you change an ACL. If you use groups with your ACLs, 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 from 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:
The following table describes the attributes you set in the NT Realm Configuration window.
When configuring the Caching realm, select your Windows NT Security realm from the pull-down menu for the Basic Realm attribute on the General tab. The Basic Realm attribute defines the association between the Caching realm and the alternate security realm (in this case, the Windows NT Security realm).
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 indicates if the specified username and password authenticated properly.
|
The entered username and password did not authenticate 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.
Updating Users Permissions for Windows NT and Windows 2000
To update the rights in Windows NT:
To update the rights in Windows 2000:
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 and Linux platforms.
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 Pluggable Authentication Modules (PAM), which allow you to configure authentication services in the operating system without altering applications that use the service.
After you change an ACL, click Refresh 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, 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.
The wlauth program runs setuid root. You need root permissions to modify the ownership and file attributes on the wlauth program and to set up the PAM configuration file for wlauth.
To set up the wlauth program for the UNIX Security realm:
# chown root wlauth
# chmod +xs wlauth
Solaris—Add the following lines to your /etc/pam.conf file:
# Setup for WebLogic authentication on Solaris machines
#
wlauth auth required /usr/lib/security/pam_unix.so.1
wlauth password required /usr/lib/security/pam_unix.so.1
wlauth account required /usr/lib/security/pam_unix.so.1
Linux—Create a file called /etc/pam.d/wlauth containing the following:
#%PAM-1.0
#
# File name:
# /etc/pam.d/wlauth
#
# If you do not use shadow passwords, delete "shadow".
auth required /lib/security/pam_pwdb.so shadow
account required /lib/security/pam_pwdb.so
To configure the UNIX Security realm:
If wlauth is not in the WebLogic Server 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
Note: If your implementation of the RDBMS security realm uses the getActiveDomain() method, you need to edit and recompile your RDBMSDelegate class in order to use the RDBMS security realm with Compatibility security. Replace the getActiveDomain() method with the getSecurityConfig() method in the weblogic.server package.
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 meant to be used in a production environment. You can perform the following managment functions on the RDBMS Security realm.
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. 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:
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 configure the RDBMS Security realm:
The following table describes the attributes you set on the Database tab.
Listing 4-1 contains the database statements entered in the Schema properties for the RDBMS code example shipped with WebLogic Server in the \samples\server\src\examples\security\rdbmsrealm directory.
Listing 4-1 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 = ?"
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. For more information, see Writing a Custom Security Realm.
To install a custom security realm:
The following table describes the attributes you set on the Custom Security Realm Configuration window.
Defining Users in the Compatibility Realm
Note: This section explains how to add users to a manageable security realm (for example, the File realm) in the Compatibility realm. If you are using a security realm that is not manageable through the Administration Console, you must use the administration tools provided in that realm to define a user.
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 accesses resources in the WebLogic Server security realm in the users window of the Administration Console.
For information about how to upgrade the guest users, see Guest User in the WebLogic Server 7.0 Upgrade Guide.
WebLogic Server has two special users:
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 of unauthenticated users to access a WebLogic Server deployment.
The system and guest users are like other users in a WebLogic Server security realm:
To change the password of a user:
While using WebLogic Server, you may have users that are locked. Perform the following steps to unlock a user:
Defining Groups in the Compatibility Realm
Note: This section explains how to add groups to a manageable security realm (for example, the File realm) in the Compatibility realm. If you are using a security realm that is not manageable through the Administration Console, you must use the administration tools provided in that realm to define a group.
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:
To define a group in the Compatibility realm:
To delete groups, enter the name of the group in the Remove These Groups list box on the Group Configuration window and click Remove.
Defining ACLs in the Compatibility Realm
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.
|
Note: To add ACLs through the Administration Console, you need to define weblogic.admin.acl.modify. |
||
Note: ACLs on MBeans are not supported in WebLogic Server 7.0. For more information, see Protecting System Administration Operations in the BEA WebLogic Server Administration Guide.
To create ACLs for a WebLogic Server resource, open the Administration Console and perform the following steps:
Either create separate ACLs for each permission available for a resource or one ACL that grants all the permissions for a resource. For example, you can create three ACLs for the JDBC connection pool, demopool: one with reserve permission, one with reset permission, and one with shrink permission. Or you can create one ACL with reserve, reset, and shrink permissions.
When creating ACLs for resources in WebLogic Server, you need to use the syntax in Table 4-19 to refer to the resource. For example, the JDBC connection pool named demopool would be specified as weblogic.jdbc.connectionPool.demopool.
If you modify an existing ACL, click Refresh on the General tab in the Security node to update the information in the filerealm.properties file that WebLogic Server uses.
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 that changing the attributes lessens security and leaves user accounts vulnerable to security attacks.
To protect the user accounts in your WebLogic Server domain, perform the following steps:
The following table describes each attribute on the Passwords tab.
Using a 6.x Auditor with Compatibility Security
If your WebLogic Server 6.x security configuration uses an implementation of the weblogic.security.audit.AuditProvider class, the Auditor is not automatically configured in Compatibility security. Configure a Realm Adapter Auditing provider in the Compatibility realm to access the 6.x Auditor.
java weblogic.Admin -url t3://localhost:7001 -username
adminusername -password adminpassword CREATE -mbean Security:
Name=CompatibilityRealmRealmAdapterAuditor -type
weblogic.security.providers.realmadapter.RealmAdapterAuditor commotype
java weblogic.Admin -url t3://localhost:7001 -username
adminusername -password adminpassword SET -mbean Security:
Name=CompatibilityRealmRealmAdapterAuditor -property Realm Security:Name=CompatibilityRealm commotype
java weblogic.Admin -url t3://localhost:7001 -username
adminusername -password adminpassword SET -mbean Security
Name=CompatibilityRealm -property Auditors
Security:Name=CompatibilityRealmRealmAdapterAuditor commotype
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
