|
 |
| e-docs > WebLogic Server > Administration Console Online Help > Compatibility Security |
|
Administration Console Online Help
|
This topic describes configuring and managing security when using Compatibility security. For more information, see Using Compatibility Security in Managing WebLogic Security. For information about using the security features in WebLogic Server 7.0, see Security in the Administration Console online help and Managing WebLogic Security.
Compatibility security refers to the capability of running security configurations from WebLogic Server 6.x in WebLogic Server 7.0. In the Compatibility security, you configure security realms, define users, groups, and ACLs as you did in WebLogic Server 6.x.
To use Compatibility security:
For more information, see theUpgrade Guide for BEA WebLogic Server 7.0.
To verify if you are correctly running Compatibility security, do the following:
In addition, a CompatibilitySecurity node will appear in the WebLogic Server Administration Console.
Configuring the Identity Assertion Provider in the Realm Adapter Authentication Provider
The Realm Adapter Authentication provider includes an Identity Assertion provider.The Identity Assertion provider provides backward compatibility for implementations of the weblogic.security.acl.CertAuthenticator class. The identity assertion is performed on X.509 tokens. By default, the Identity Assertion provider is not enabled in the Realm Adapter Authentication provider.
To enable identity assertion in the Realm Adapter Authentication provider:
Configuring a Realm Adapter Auditing Provider
The Realm Adapter Auditing provider allows you to use implementations of the weblogic.security.audit.AuditProvider class when using Compatibility security. In order for the Realm Adapter Auditing provider to work properly, the implementation of the weblogic.security.audit.AuditProvider class must have been defined in the Audit Provider class attribute on the Domain-->Security-->General tab.
To configure a Realm Adapter Auditing provider:
To change the system 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 WebLogic Server Administration Console. When WebLogic Server is rebooted, the new password is propagated to all the Managed Servers in the domain.
Configuring the File Realm in the CompatibilityRealm
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. If you use one of the alternate security realms, you must configure the Caching realm.
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. Therefore, BEA recommends that you take the following steps:
Note: Also make a backup copy of the SerializedSystemIni.dat file for the File realm.
Configuring the Caching Realm in the CompatibilityRealm
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.
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.
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 Cache Case Sensitive 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:
Enabling the Authentication Cache
Adding a Note to the Caching Realm
Configuring an LDAP Realm V1 in the CompatibilityRealm
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 directory servers.
To configure an LDAP V1 security realm:
Defining Attributes for the LDAP Directory Server
Specifying How Users Are Stored in the LDAP V1 Security Realm
Specifying How Groups Are Stored in the LDAP V1 Security Realm
Adding a Note to the LDAP V1 Security Realm
Configuring an LDAP V2 Realm in the CompatibilityRealm
Configuring the LDAP realm V2 involves defining attributes that enable the security realm to communicate with the LDAP server and attributes that describe how users and groups are stored in the LDAP directory. In Compatibility security, the LDAP realm V2 is configured as a custom security realm.
The LDAP tree and schema is different for every LDAP server. The Supported Server Templates has 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.
The following table describes the attributes you set on the Custom Security Realm Configuration window.
|
Name of the LDAP realm V2, such as defaultLDAPRealmForNetscapeDirectoryServer. |
|
|
Name of the WebLogic class that implements the LDAP V2 realm such as weblogic.security.ldaprealmv2. |
|
|
Specify information specific to your LDAP configuration for the following:
See Supported Server Templates for sample values for the supported LDAP servers. |
Listing 21-1 through Listing 21-4 are templates used to configure LDAP servers supported in the LDAP realm V2. Copy these templates directly into the config.xml file for your application.
Warning: Each line in the following code examples must appear on a single line. The examples in the code examples have been formated to fit the margins of this document and some lines have been broken to facilitate that formatting. If you paste this text into the config.xml file, be sure to concatentate the lines that are broken so that they appear on a single line in your code.
Listing 21-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=(&(uid=%u)(objectclass=person));
group.dn=ou=groups,o=beasys.com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(uniquemember=%M)
(objectclass=groupofuniquenames));
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
Listing 21-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=(&(cn=%u)(objectclass=member)
(!userAccountControl:1.2.840.113556.1.4.803:=2)));
group.dn=ou=Groups, o=ExampleMembershipDir;
group.filter=(&(cn=%g)(objectclass=mgroup));
membership.scope.depth=1;microsoft.membership.scope=sub;
membership.filter=(|(&(memberobject=%M)
(objectclass=memberof))(&(groupobject=%M)
(objectclass=groupmemberof)));
membership.search=true;
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
Listing 21-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=(&(cn=%u)(objectclass=person));
group.dn=ou=groups,o=example.com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(member=%M)
(objectclass=groupofuniquenames));"
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
Listing 21-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=(&(uid=%u)(objectclass=person));
group.dn=ou=groups,dc=example,c=com;
group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(uniquemember=%M) (objectclass=groupofuniquenames));"
"Notes="Before enabling the LDAP V2 security realm, edit the configuration parameters for your environment."/>
Adding a Note to the LDAP V2 Security Realm
Configuring the Windows NT Security Realm in the CompatibilityRealm
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:
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,then it may be necessary to do one of two things:
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.
Adding a Note to the Windows Security Realm
Configuring the UNIX Security Realm in the CompatibilityRealm
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:
Adding a Note to the UNIX Security Realm
Configuring the RDBMS Security Realm in the CompatibilityRealm
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. SQL scripts that populate a database are used to create groups for the RDBMS Security realm.
To configure the RDBMS Security realm:
Listing 21-5 contains the database statements entered in the Schema properties for the RDBMS security realm shipped with WebLogic Server.
Listing 21-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 = ?"
Adding A Note to the RDBMS Security Realm
Installing a Custom Security Realm in the CompatibilityRealm
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.
Adding A Note To A Custom Security Realm
Defining Users in the CompatibilityRealm
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.
Changing the Password of a User
For a more secure deployment, BEA recommends running WebLogic Server with the guest account disabled.
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.
Defining Groups in the CompatibilityRealm
Note: This section describes how to add groups to the version 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.
If you are using Compatibility mode and the performance time for authenticating users and groups is taking longer, set the Group Membership Cache TTL attribute for your LDAP server to 0. This should improve performance. If you do not notice improved lookup times, BEA recommends upgrading to one of the Authentication providers.
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 CompatibilityRealm
You can 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.
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:
There are two sets of attributes available to protect user accounts, one set at the domain and one set at the security realm. You may notice that if you set one set of attributes (for example, the attributes for the security realm) and exceed any of the values, the user account is not locked. This happens because the user account attributes at the domain override the user account attributes at the security realm. To avoid this situation, disable the user account attributes at the security realm.
To disable the user account attributes at the security realm:
Warning: If you disable the user lockout attribute at the security realm, you must set the user attributes on the domain otherwise the user accounts will not be protected.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
