Security Vs Weblogic Domain

Never use development mode for production servers; development mode relaxes the security constraints for all servers in a domain. When using compatibility security, disable guest logins in production, so that guest logins cannot be used to access WebLogic resources in a WebLogic Server domain.
When you are creating a security policy, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them. Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Configure additional administrative users to roles such as admin, deployer, monitor or operator.
SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of boot.properties file, you cannot restart servers.
Tips

1. Store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.

2. BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; first assign users to groups, then create role statements.

3. Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use post-bind UID or post-bind GID in the WebLogic machine configuration.

4. Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.